| name | internal-gateway-writing-plans |
| description | Use when repository-owned work needs an approved implementation plan written from an approved design or reviewed retained spec. |
Internal Gateway Writing Plans
Referenced skills
/superpowers-writing-plans: required owner for producing the retained plan.
/internal-gateway-execute-plans: required next owner after human review and
explicit execution approval.
When to use
- Use after the user approves implementation-plan writing from an approved
design or reviewed retained spec.
When not to use
- Retained-spec writing stays in the brainstorming lane.
- Route same-chat work, plan review, plan execution, and imported
superpowers-* maintenance to their existing owners.
Contract
- Capture the target, anti-scope, nearest owner, validation path, stop
conditions, and observable acceptance. Keep the no-version-control-mutation
rule in scope. Completion: all six facts and the no-mutation rule are
recorded before delegation.
- Load
/superpowers-writing-plans and produce one reviewable retained plan
under tmp/superpowers/plans/ with ordered actionable tasks, concrete file
targets, focused validation, and an execution handoff. Completion: one plan
exists at the retained path and contains those four artifact properties plus
one versioned ## Execution Contract fenced JSON object.
- Perform human review for task actionability, approved scope, focused
validation, safety, and handoff quality. The contract must declare native
authoritative validation commands and phases, equivalence policy, manual
obligations, and authority boundaries. It must not predict runtime
discovery results or recovery candidates. Completion: each review concern
is accepted or has a recorded revision.
- Report the retained plan path, name
/internal-gateway-execute-plans as
the next owner, and wait for explicit execution approval. Completion: the
path and next owner are reported and execution has not started without
approval.
Command Portability
- Write every baseline, focused, and final validation command in directly
executable native form. The command recorded in the plan is the
authoritative command and evidence label.
- Do not make
rtk, graphify, or another optional accelerator a prerequisite
or command prefix unless the task's actual subject is that tool.
- Executor-side optimization may accelerate an invocation, but must not alter
the recorded authoritative command or its validation meaning.
The executor owns the single mechanical plan validator. Do not add a
writer-local validator, draft-only lifecycle, or duplicate parser contract.
Before handoff, run the executor-owned preflight against the written plan and
revise it until there are zero blocking findings. Plans without the versioned
contract are not actionable.
No-Commit Rule
- Never run
git add, git commit, git push, or another Git mutation while
writing or handing off a plan. Retained artifacts stay uncommitted for user
review unless the user explicitly requests commit help.
- Do not put Git mutation steps or default commit advice in the produced plan.
Validation
- Confirm the delegated plan has ordered tasks, concrete file targets, focused
validation, clear scope and safety boundaries, and no duplicate owner.
- Confirm the handoff names
/internal-gateway-execute-plans and waits for
explicit approval.
- Run
git diff --check and confirm no Git mutation occurred.