working-docs
The _working/ directory is a scratch space purely for your use.
When to use
- Multi-step implementation, debugging, or investigation work.
- Tasks likely to span a long session or multiple handoffs.
- Cases where interim findings should be captured before final output.
When not to use
- One-shot requests that can be completed directly with no intermediate reasoning artifact.
- Final user-facing docs that belong in the repository outside
_working/.
Working notes convention
Use a stable path so notes are easy to find and continue:
_working/<topic>/notes.mdfor running notes and decisions_working/<topic>/scratch.mdfor temporary drafts/experiments
As you work through a problem, always write notes to _working/. Capture observations and the reasoning that connects those observations to the task or broader project. Keep notes structured so another agent (or a future session) can resume quickly.
You may delete files in the scratch space when you are done with them.
More from michael-f-bryan/skills
long-running-agent-harness
Plans and structures large-scale work for AI agents across many sessions. Human and AI iterate to produce a design doc; run an Initializer sub-agent once to create feature list, runbook, and backlog in _working/; then repeatedly run a Coding sub-agent until all features pass. At milestones (e.g. end of a work-unit group), pause for human check-in, re-run Initializer, then continue. Prompts are passed to sub-agents when spawning (no copying into .cursor/rules). Use when planning multi-session agent work, long-horizon coding from a design, or handoff between coding sessions.
31doc-coauthoring
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
23test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
19commit-messages
When suggesting or writing commit messages for this repo, follow these rules.
17code-like-michael
Write, refactor, and review code in Michael's style; explicit contracts, thin entrypoints, practical boundaries, anti-ceremony abstractions, deterministic tooling, and architecture that scales from function internals to repository shape.
14wikilinks
When generating or editing markdown content, actively look for existing pages to link to and incorporate relevant wikilinks so content is interconnected. Use when writing notes, docs, or any .md content.
13