process

Use for development process decisions -- exploring intent, writing and executing plans, diagnosing failures, choosing proportionate tests, verifying outcomes, and integrating authorized work.

methodology

1. inspect the current code and owning contract; brainstorm only where a material design choice remains open. an explicit collaborative design request pauses implementation at the actual decision.
2. write a plan for coupled work, then execute in the current shared checkout. use orchestration when delegation has an independent boundary and is authorized.
3. diagnose failures from evidence before changing code. add tests when they prove a material behavior or regression, not for trivial reversible edits.
4. run fresh checks for the changed boundary, inspect the final diff, and integrate only within existing authority. review belongs to review.

contents

• trainedlearned layer -- read first
• brainstormingexploring intent, requirements, and design before any creative work
• writing-plansturning a spec or requirements into a written multi-step implementation plan
• executing-plansexecuting a written plan in a separate session with review checkpoints
• systematic-debuggingany bug, test failure, or unexpected behavior -- before proposing fixes
• test-driven-developmentimplementing any feature or bugfix -- red/green discipline before implementation code
• verification-before-completionabout to claim work is complete, fixed, or passing -- verified output before any success claim
• finishing-a-development-branchverified work needs an authorized commit, PR, merge, or handoff
• using-git-worktreesoperator explicitly authorized a worktree
• using-superpowersstarting a conversation -- the skill-discovery contract
• xiaextracting, porting, or adapting a feature from another repo into this project