Plans software work in small, test-driven increments with approval-gated commits.
npx skills add https://github.com/chloebrett/snitchos --skill planning-chloebrett
Please help me install this Agent Skill. Skill: planning Source: https://github.com/chloebrett/snitchos/tree/main/.claude/skills/planning Command: npx skills add https://github.com/chloebrett/snitchos --skill planning-chloebrett
plans/ directory, each with goals, acceptance criteria, and one-sentence steps that fit in a single commit. - TDD Enforcement: Every step follows a strict RED-GREEN-MUTATE-KILL MUTANTS-REFACTOR cycle, including mutation testing reports before any commit. - Approval Gates: Requires explicit human confirmation of acceptance criteria before code is written and explicit approval before any commit. - Use Case: When starting a new feature like email validation, use this Skill to draft a plan file, get it approved, then execute each step with failing tests first, mutation reports, and small reviewable PRs. ## Quick Start Ask the AI to create a plan in the plans directory for your next feature, broken into small test-driven steps with clear acceptance criteria.High-intent search queries and answers about installing and using this skill.
Create a plan file describing the goal and acceptance criteria, then split work into steps that each fit in a single commit and one sentence. A step is too big if it spans multiple commits, has multiple 'and's in its description, or takes more than one session.
Follow the RED-GREEN-MUTATE-KILL MUTANTS-REFACTOR cycle per step: write a failing test, make it pass with minimal code, run mutation testing to produce a report, kill surviving mutants with stronger tests, then refactor only if valuable.
Plans live in a plans/ directory at the project root, each as a self-contained descriptively named markdown file. Multiple plans can coexist without conflicts, and files are deleted once the plan is complete.
Splitting is wrong when changes are inherently coupled and separation would create broken intermediate states. The default should always be to ask whether a change can be split, but use judgement for genuinely atomic changes.
The workflow adds overhead through mandatory approval gates, mutation reports, and per-step confirmation, which can slow trivial changes. It also depends on a working test suite and human availability for reviews at each checkpoint.
sagittarasPlans milestones by drafting code-anchored issues and creating them in the issue tracker.
LudwigAJStructure software development tasks into approved, test-driven workflows with pull-request reviews.
pjherronInterviews users to sharpen plans while generating ADRs and glossary documentation.
Araara7Build throwaway prototypes to validate technical feasibility before committing to a real build.