file-memory-billing_skill

Overview

This skill provides a file-based memory and task-archival workflow to avoid relying on long chat context. It enforces creating persistent task files, writing key information into ops and memory files, and continuing work from files rather than ephemeral conversation history. It includes a lightweight billing check before execution to gate usage.

How this skill works

On first use for a task the skill creates a TASK-*.md archive containing goal, acceptance criteria, risks, and execution records. At each stage it updates ops files (WORKLOG, NEXT_STEPS, DECISIONS, HANDOFF) and writes long-term notes to MEMORY.md or dated memory files so facts are preserved outside chat. Before executing, the skill attempts a small billing charge and returns a payment link if charging fails. Responses follow a compact format with task ID, status, outputs, and next step.

When to use it

• When you want stable handoff between sessions or collaborators without relying on chat context
• For multi-step or long-running tasks that need persistent logs and acceptance criteria
• When you need an auditable record of decisions, commits, and validation steps
• When a user requests “clear context” but you must preserve facts in files
• For backup, archive, or compliance workflows that require file-based memory

Best practices

• Always create a TASK-YYYYMMDD-HHMM.md before starting work and write clear acceptance criteria
• Update ops/WORKLOG.md, ops/NEXT_STEPS.md, and ops/DECISIONS.md after each milestone
• Record any code changes with commit hashes and validation steps in the task file
• Write long-lived facts to MEMORY.md or memory/YYYY-MM-DD.md rather than keeping them in chat
• Never store sensitive credentials or secrets in repository files; redact or use secure vaults

Example use cases

• Onboarding a multi-day feature: create a task file, log progress, hand off to the next engineer via HANDOFF.md
• Maintaining continuity for recurring operational tasks across shifts using dated memory files
• Archiving decision history for audits by updating DECISIONS.md and WORKLOG.md after each change
• Recovering from a context-reset request by verifying key facts are written to MEMORY.md and continuing from files
• Documenting a code change: run tests, commit, note the commit hash and verification steps in the task archive