| name | patchmill-planning |
| description | Use for Patchmill run-once spec and plan creation. Wraps sibling Superpowers brainstorming and writing-plans skills with Patchmill worktree, artifact path, and test-value policy. |
Patchmill Planning
Use this as the Patchmill planning entrypoint. It does not replace the upstream
Superpowers workflows; it annotates the installed sibling Superpowers skills
with Patchmill-specific rules.
Required sibling skills
- For design/spec work, read
../brainstorming/SKILL.md and follow the upstream
brainstorming workflow except where this wrapper or the Patchmill prompt gives
a stricter instruction.
- For implementation-plan work, read
../writing-plans/SKILL.md and follow the
upstream writing-plans workflow except where this wrapper or the Patchmill
prompt gives a stricter instruction.
Use paths relative to this skill directory. If those sibling skills or their
supporting files are missing, stop and ask instead of recreating them.
Patchmill modifications
Worktree invariant
Specs and plans are feature artifacts. Write them in the active Patchmill issue
worktree. If already running in a Patchmill issue worktree, use that worktree
and do not create another one. If working ad hoc outside an issue worktree, use
using-git-worktrees before writing the artifact.
Return artifact paths relative to the repository root.
Spec artifacts
When the Patchmill prompt asks for a design spec, use the sibling brainstorming
workflow as source material, but save the validated design to:
docs/specs/YYYY-MM-DD-<topic>-design.md
Do not save Patchmill specs under docs/superpowers/.
Plan artifacts
When the Patchmill prompt asks for an implementation plan, use the sibling
writing-plans workflow as source material, but save the plan to:
docs/plans/YYYY-MM-DD-<feature-name>.md
Do not save Patchmill plans under docs/superpowers/.
Testing Value Gate
Before planning a new automated test, apply Patchmill's Testing Value Gate:
- Will this test prove behavior rather than restate implementation or
configuration?
- Could it fail for a meaningful regression?
- Will future maintainers benefit from rerunning it?
- Is the behavior reusable or risky enough to justify test maintenance?
Use automated tests by default for production behavior changes, bug fixes,
reusable logic, parsing/validation, API contracts, error handling,
security-sensitive behavior, and regressions.
Do not add new tests merely to assert workflow YAML content, dependency
versions, package lock contents, static configuration values, documentation
text, or one-off script structure. Use direct verification instead, such as
linting, syntax checks, dry-runs, builds, or existing test suites. When skipping
a new automated test, state the verification used instead.
