القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when executing Patchmill implementation plans that require one plan implementation subagent and final full-worktree readiness review before landing
Use when executing Patchmill implementation plans that require final full-worktree readiness review before landing
Use when executing Patchmill implementation plans with Superpowers task-level development plus final validation and pull-request readiness, without extra Codex or thermo-nuclear full-worktree reviews
Decide when Patchmill may direct-land and when it must open a PR.
Use when Patchmill run-once changes visible UI and needs committed reference screenshot evidence in the final pr-created JSON.
Use when creating, editing, reviewing, or refactoring code modules to keep files focused, readable, and maintainable as code grows.
| 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. |
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.
../brainstorming/SKILL.md and follow the upstream
brainstorming workflow except where this wrapper or the Patchmill prompt gives
a stricter instruction.../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.
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.
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/.
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/.
Before planning a new automated test, apply Patchmill's Testing Value Gate:
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.