<skill_overview> Skills are mandatory when they apply, and substantial work must stay grounded in local task docs. </skill_overview>
<rigidity_level>
HIGH FREEDOM - The meta-process is rigid: check for skills, read them from disk, announce usage, and keep work anchored in plans/active/.
</rigidity_level>
<quick_reference>
- Check if any skill applies.
- Read the relevant
SKILL.mdfrom disk. - Announce which skill you are using.
- For substantial work, create or resume a local
plans/active/<slug>/. - Keep
plan.md,context.md, andtasks.mdcurrent. </quick_reference>
<when_to_use>
- At the start of every conversation
- Before starting any non-trivial task
- Before editing skills, hooks, docs, or code </when_to_use>
<the_process>
1. Check for skills first
- If a skill matches, use it.
- Never rely on memory; read the file from disk.
- Announce the skill before acting.
2. Ground large work in task docs
For features, rewrites, and multi-step tasks:
brainstormingshapes the workwriting-plansdistills it into task docsexecuting-plansimplements the currentNowslice
Use:
plans/active/<slug>/plan.mdplans/active/<slug>/context.mdplans/active/<slug>/tasks.md
These task directories are local working state. Delete the finished directory instead of archiving it.
3. Treat the docs as distinct tools
plan.mdis the approved intent and acceptance contractcontext.mdis the living discovery logtasks.mdis the rolling execution backlog
4. Verify before claiming completion
Use verification-before-completion before any completion claim.
</the_process>
<why_it_fails>
- The plan drifts out of memory
- Implementation learns things that never get written down
- Resumption after compaction becomes guesswork </why_it_fails>
<why_it_fails>
- Skills evolve
- Important steps get skipped
- The user cannot tell whether the workflow was actually followed </why_it_fails>