메뉴
Use to execute an implementation plan task-by-task by dispatching a fresh sub-agent per task with a review gate after each. Preferred when the agents feature is on - it keeps the main conversation's context lean and cheap. Works in an isolated git worktree.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use this when the user wants to draft a third-party vendor or product privacy and security review document for consumer use.
Use to execute an implementation plan yourself, inline in this conversation, with review checkpoints. The simpler alternative to subagent-driven-development - use it for small plans or when the agents feature is off. Works in an isolated git worktree.
Use when implementation is complete and tests pass, to integrate the work. Verifies the build/tests, then presents clear options - merge locally, open a pull request, keep as-is, or discard - and carries out the choice, including cleaning up the git worktree.
Use this before any creative or building work - new features, components, behavior changes, or non-trivial fixes. Explores intent, requirements, and design through dialogue, then writes an agreed spec before any implementation begins.
Use before implementing a plan, to set up an isolated git worktree to work in. Creates a linked worktree under .worktrees/ and changes into it, so the feature's work never touches the main checkout - and a second conversation can work a different feature in parallel.
Use when you have an agreed spec or requirements for a multi-step task, before touching code. Turns the spec into a bite-sized, test-driven implementation plan with exact files, code, and commands - then hands off to execution.
| name | Subagent-Driven Development |
| description | Use to execute an implementation plan task-by-task by dispatching a fresh sub-agent per task with a review gate after each. Preferred when the agents feature is on - it keeps the main conversation's context lean and cheap. Works in an isolated git worktree. |
Execute a plan by acting as a controller: for each task, dispatch a fresh plan-implementer sub-agent, then a task-reviewer sub-agent, loop fixes until the review is clean, record progress, and move on. After all tasks, run one whole-branch review, then finish the branch.
Why sub-agents: each runs in isolated context and returns only its final answer (the context firewall). You hand each one exactly what it needs — its task, the interfaces it touches, the constraints — and the bulk artifacts (briefs, reports, diffs) move as files, never pasted into your own context. That keeps the controller cheap and lets you run the implementation on a low-effort model while reviews run higher.
Announce at start: "I'm using the subagent-driven-development skill to execute this plan."
Requires: the agents feature enabled (so dispatch_agent is available) and the plan's three sub-agents — plan-implementer, task-reviewer, and doc-reviewer — installed (they ship with this plugin). If agents are off, use executing-plans instead.
open_skill → using-git-worktrees) to create and cd into .worktrees/<branch>. All the work happens there. Never start on main/master..xtra-powers/ folder in the worktree for briefs, reports, and the progress ledger, and add .xtra-powers/ to the worktree's .gitignore (commit that once) so this bookkeeping is never committed..xtra-powers/progress.md with one line per task, all unchecked.Before dispatching Task 1, scan the plan once for conflicts: tasks that contradict each other or the Global Constraints, or anything the plan mandates that a reviewer would treat as a defect (a test that asserts nothing, a verbatim-duplicated logic block). Present everything you find to the user as one batched question — each finding beside the plan text — and ask which governs, before execution begins. If the scan is clean, proceed without comment.
For each task in order:
Extract the task's full text from the plan into .xtra-powers/task-N-brief.md (with files__write) — the exact files, code, steps, test cases, and the Global Constraints. This file, not your context, is the implementer's source of requirements.
dispatch_agent the plan-implementer with a task that contains: (1) one line on where this task fits; (2) the brief path, introduced as "read this first — your requirements, use its exact values verbatim"; (3) the worktree path to cd into; (4) the interfaces/decisions from earlier tasks the brief can't know; (5) the report-file path .xtra-powers/task-N-report.md. Keep exact values (numbers, signatures, test cases) in the brief, not the dispatch.
Effort: the implementer's default is low — right for a task whose plan text contains the code (transcription + testing). Override to effort: high only for a genuinely design-heavy task (multi-file integration, non-obvious algorithm). Don't override otherwise; the default is tuned.
One implementer at a time — never dispatch implementers in parallel (they'd edit the same tree and conflict; in GxPT only read-only agents run in parallel anyway).
effort: high; too large → split the task; the plan itself is wrong → stop and ask the user. Never re-dispatch the same task unchanged.Record the commit you were at before the implementer ran (the BASE). After DONE, generate the task's diff against BASE — git__diff (or git__log/command__run git diff) for the BASE..HEAD range — and write it to .xtra-powers/task-N-diff.txt. Then dispatch_agent the task-reviewer with: the brief path, the report path, the diff-file path, the worktree path to cd into, and the Global Constraints copied verbatim. It returns a spec-compliance verdict and a code-quality verdict.
Effort: the reviewer's default is medium. Override to effort: high for a subtle or risky diff (concurrency, security, data handling); effort: low for a trivial mechanical diff. Don't pre-judge findings in the dispatch or tell the reviewer what not to flag.
If the review reports Critical/Important issues or spec gaps: dispatch_agent the plan-implementer (one fix dispatch with the complete findings list, not one per finding) to fix them in the same worktree, re-run the covering tests, and append to the report. Then regenerate the diff and re-dispatch the reviewer. Repeat until the review is clean. Resolve any "cannot verify from diff" items yourself — you hold the cross-task context — and treat a confirmed gap as a failed review.
Append one line to .xtra-powers/progress.md: Task N: complete (commits <base7>..<head7>, review clean). The ledger is your recovery map — after a context compaction, trust it and git log over your own memory, and resume at the first unchecked task (never re-dispatch a completed one).
After every task is complete, dispatch the task-reviewer once over the whole branch: generate the branch diff (MERGE_BASE..HEAD, where MERGE_BASE is where the branch started — e.g. git merge-base main HEAD via command__run) into .xtra-powers/branch-diff.txt, and dispatch with effort: high and a brief saying this is a whole-branch review against the spec. If it returns findings, dispatch one fix implementer with the complete list, then re-review.
Once the whole-branch review is clean, invoke the finishing-a-development-branch skill (open_skill → finishing-a-development-branch).
Everything you paste into a dispatch — and everything a sub-agent prints back — stays in your context for the rest of the session. So hand artifacts over as files: the brief carries requirements, the report carries the implementer's full write-up (it returns only status + commits + a one-line test summary + concerns), the diff file carries the change for the reviewer. A dispatch prompt describes one task — never paste accumulated "state after Tasks 1–3" summaries into later dispatches; a fresh sub-agent needs only its task, its interfaces, and the constraints.
Never:
main/master, or outside the worktree.