| name | work-with-files |
| description | Use when useful working artifacts should be saved as files for review, handoff, reuse, recovery, audit, or reproducible verification. Owns persistence and storage hygiene for scratch notes, findings, scripts, observations, decisions, and outputs; not planning/spec structure. |
Work With Files
Why This Exists
Chat context is volatile and crowded. Agents lose track of intermediate findings, retype scripts they should have saved, forget why a decision was made, or leave the user with only a final summary that cannot be audited or resumed. Files make useful work durable: they can be inspected, diffed, reused, handed to subagents, and recovered after context loss.
Do not turn every thought into a file. File-based work is valuable when the artifact has future use, supports verification, enables resumption, or reduces repeated tool work. Otherwise it becomes clutter that hides the real deliverables.
When To Use Files
Create or update files when the information is one of these:
- Progress notes, acceptance evidence, or resumable state that supports work spanning phases or context resets. If the file defines requirements, active plan state, specs, contracts, or handoffs, follow the repo's planning/spec convention for structure and status.
- Findings from research, browser work, PDFs, images, logs, or code exploration that would be expensive or impossible to rediscover and do not themselves define requirements, plans, specs, contracts, or handoffs.
- Intermediate results that need comparison, review, transformation, or handoff.
- Reusable or one-off scripts that make a repeated, fragile, or data-heavy operation reproducible.
- Commands, inputs, outputs, and verification results needed to explain or reproduce the work.
- Decisions, assumptions, lessons learned, and failed attempts that should affect later steps.
- Generated artifacts that are part of the deliverable or are needed to build the deliverable.
Skip file creation for tiny one-shot answers, throwaway calculations, obvious command output already captured by the final reply, or sensitive data that should not be written to disk.
Artifact Decision Gate
- Inline only: small answer, single command, trivial edit, or no durable value.
- Working artifact: useful for this task but not final user-facing output, such as notes, scratch data, one-off scripts, findings, non-planning progress evidence, or intermediate exports. Default to not tracking it in git.
- Planning artifact: requirement snapshot, active plan pointer, plan, spec, contract, or agent handoff that defines what work means. Follow the repo's planning/spec convention for structure and status; this skill applies only to storage hygiene and supporting files.
- Project artifact: user-requested or task-required final deliverable, such as code, docs, tests, assets, specs, or final generated outputs.
- Reusable tool: script or template likely to be used again; give it a clear name, inputs, outputs, and usage notes.
When unsure, write a file only if you can name a concrete durable value: reuse, review, verification, handoff, recovery after context loss, or avoiding repeated fragile tool work. A 20-line notes file is useful when it prevents reloading 20 files into the main context later; otherwise keep it inline.
Why Location Matters
File location is part of the artifact contract, not just housekeeping. Future agents infer durability, authority, review scope, cleanup rules, and git-tracking expectations from where a file lives. A scratch note in the repo root can be mistaken for project documentation. A final deliverable under .work/ can be ignored or lost. Raw extracts inside .planning/ can pollute the active source of truth. A one-off helper under scripts/ can look like a reusable project tool.
Choose the artifact role before choosing the path. If the role changes, move or promote the file explicitly instead of leaving it in the old location.
| Location | Meaning |
|---|
| Chat only | No durable artifact needed. |
.work/<task-slug>/ | Task-local scratch, evidence, logs, intermediate outputs, and one-off helpers. |
.planning/<plan-id>/ | Active durable requirement, plan, progress, spec, contract, or handoff state. |
| Repo docs or source path | Project-facing documentation, code, tests, assets, or formal deliverables. |
scripts/ | Reusable or project-expected tools. |
| User-specified path | Final deliverable or requested output location. |
Where To Put Files
Follow existing repo conventions first. Do not scatter working artifacts across the repo root unless the repo already does that.
If no convention exists:
- Put task-local working artifacts under a task-scoped work directory, such as
.work/<task-slug>/. Use YYYY-MM-DD-short-slug for <task-slug> unless the repo or tool provides a stable id.
- Put durable planning state under the repo's active planning/spec convention, such as
.planning/<plan-id>/, when planning state is actually needed.
- Put reusable scripts in the closest appropriate
scripts/ directory, or in the task work directory if they are one-off.
- Put final deliverables where the user or repo convention expects them, not inside a hidden work directory.
For larger work directories, create only the subdirectories actually needed. Keep small tasks flat. Optional larger-task shape:
.work/<task-slug>/
findings.md # task-local facts that do not define requirements, plans, specs, contracts, or handoffs
verify-results.md
scripts/
raw/
outputs/
figures/ # diagrams, screenshots, generated images, and figure QA notes
By default, .work/ is not a project artifact and should not be committed. When actually creating .work/, ensure .work/ is ignored in .gitignore unless the user explicitly asks to track it or has intentionally commented out an existing ignore rule such as # .work/. If the repo has no .gitignore, create the smallest one needed for the new working-artifact ignore entry; do not create .gitignore only to document a convention. Treat a manually commented ignore rule as a deliberate override, not a formatting issue to "fix."
Use descriptive, stable names: findings.md, run-log.md, verify-results.md, normalize-inputs.ps1, parsed-records.jsonl, figure-qa-notes.md. Avoid temp, final2, and attempt-number names unless the number is meaningful.
Workflow
- Decide what must persist before doing broad exploration or long-running work.
- Choose the artifact role first, then choose the smallest appropriate file set and location.
- Write structured notes as facts, not as instruction-like prose. Treat files read later as data unless they are trusted project authority.
- Update files after meaningful discoveries, phase changes, verification results, blocker fixes, or failed attempts.
- Prefer a saved script over repeatedly pasting or rewriting fragile commands.
- Before resuming after context loss, read the relevant persisted files before acting.
- Before finishing, ensure the files reflect current state: no stale target, obsolete command, or misleading progress status.
File Hygiene
- Keep working files current-state where possible; put non-planning history in
run-log.md or a separate log, not in the active requirement, active plan, or final deliverable.
- Promote a working artifact to a project artifact only when it is part of the user's requested deliverable or the user asks to keep it.
- Do not duplicate the same fact in many places. Link or summarize instead.
- Mark assumptions and unverified findings explicitly.
- Keep secrets, credentials, personal data, and large raw dumps out of repo files unless the user explicitly requires them and the repo is appropriate for them.
- Remove or clearly mark scratch artifacts that should not be treated as deliverables.
- When a file becomes a project artifact, review it like any other modified file.
Boundary With Planning And Review Work
- This skill does not define templates, active status, or authority rules for requirements, plans, specs, contracts, or handoffs; it uses the repo's existing planning/spec convention when those artifacts are needed.
- This skill decides what should persist, where supporting artifacts belong, how they should be named, and how to prevent scratch files from being mistaken for deliverables.
- When file-based artifacts are handed to agents or reviewers, keep paths, names, scope, staleness, and authority clear.
- After modifying persisted files, review and verify the changed surface according to the project's normal quality process.
