Gabriel mode

Build one already precise ticket through bounded worker slices. Each implementing worker runs /review on its own contribution. The main agent independently checks correctness and omissions against the ticket and project rules, and returns fixes to that worker. Finish with review of the combined changes, then verification.

Inspired by pstack's poteto-mode. This skill owns orchestration only. Existing pack skills own implementation standards, tests, review evidence, verification, and shipping permissions.

Read when

• At entry: read the project's instructions, the ticket and relevant decisions, /task, its doctrine and reference, and the execution context.
• Before a delegation or correctness decision: open principles.md and main-context.md, then the applicable project rules. Pass those rule paths to workers. A verdict without checking the governing rules is incomplete.
• Before implementation or review: apply code-quality.md and code-structure.md. Open strong-foundation.md for a Feature, and user-experience.md plus the project's docs/design.md for user-facing work.
• When the ticket specifies tests or the user asked for them: read /verification, no-unrequested-tests.md, and testing.md.
• At each review or verification: follow /review or /verification, including their required reads.
• Before writing or asking: follow Plain language and Asking the user.

Local orchestration contract

Use the selected task route's contracts and standards, not a second complete /task run inside each worker. These differences apply only during an explicit /gabriel-mode run:

Do not change the defaults of /task, /verification, or /review outside this run. Preserve accepted test assertions, user refusals, rule ownership, and shipping.md. A worker never owns the branch, ticket, or shipping. Do not commit, push, create a PR, merge, deploy, or install as part of this workflow.

Process

1. Establish the run. Apply the shared ready-ticket preflight and handoff contract, reading the ticket as read-only context. Announce the current lock, decision sources and next phase.
2. Track the run in chat. Keep phase, slice owners and dependencies, evidence, fix backlog and drift in the execution context, with proposed changes marked apart from approved ones and their decision source. Update it at phase changes and handoffs. Write no process file.
3. Decompose and build code. Use the existing slice split and inline plan contract, with the planning rules for product plans. Apply the slice loop to each coding slice. Product workers write no tests. Work in dependency order; parallelize only independent slices with separate write ownership. Size delegation to the work and available harness, without fixed worker counts or model mandates.
4. Review the combined result. Once slices are accepted, run /review in local mode over all this run's changes, including tests and cross-slice seams, against the pinned run baseline. Use a fresh review subagent with the combined review context, including the whole ticket and factual slice evidence, without the implementation conversation or worker verdicts. The main agent then independently checks the actual combined diff for correctness and omissions against every Done when item and rule. Slice approvals alone cannot pass this gate. If either review or the main judgment finds a gap, return to coding decomposition with the bounded fix backlog, then review and judge the resulting combined changes again. Test defects follow the test rules and route back to their test owner when authorized.
5. Verify after whole approval. Launch /verification in a fresh subagent only after the combined review and main judgment pass. Supply the whole contract, the tests the ticket specified or the user accepted, combined diff, evidence, and selected verification scope. It runs applicable suites and real-path checks, expanding for shared/high-risk effects or an explicit full request. It writes those accepted tests under testing.md and proposes any others worth keeping. The main agent reads the evidence and judges it against the same project rules and Done when.
6. Assess readiness. Use the /task completion summary, naming the checked revision and working diff, accepted tests, review findings, verification evidence, and remaining blockers. Say ready for PR only when the actual combined result meets the ticket, applicable gates passed, and there are no unresolved blocking findings. Otherwise say blocked or incomplete and give the next action. Report any named user waiver separately from proof. Leave shipping to a separately authorized action under shipping.md.

Slice loop

1. Brief the worker. Use the shared handoff contract, including the slice's reason, concrete approach, public entry and the current contract.
2. Implement, then self-review. The implementing worker follows the selected task route within that brief. The same worker invokes /review in local mode, scoped to its contribution and relevant callers. Use initial Standards and Spec depth for a new contribution; use remediation mode for named fixes. Return its bounded diff, the review output, checks and outcomes, omissions or blockers, and proposed execution context updates. It does not run an independent task lifecycle or ship.
3. Judge in the main context. Read the relevant diff and evidence, consult the applicable project rules, and check both correctness and completeness against the slice contract. Do not accept the worker's verdict on trust. Record approval or specific gaps with rule or Done when references. Main judgment is an independent acceptance check, not a replacement for the worker's review.
4. Return bounded fixes to the same worker. The main agent owns remediation, including analysis as needed and promotion of named fixes. This invocation authorizes that in-scope loop. Repeat the same worker's scoped review and main judgment until accepted or blocked; do not add a generic reviewer per slice. If the worker cannot resume, give a replacement its bounded contribution, current contract and evidence.

Workers may raise questions whenever blocked or a ticket deviation is needed. The main agent batches user-owned decisions under Asking the user. Look up repository facts; do not guess approvals. Pause affected work while a required answer is pending. Record an approved change as the current decision, and refresh affected briefs before work resumes. Do not silently rewrite the source ticket or carry superseded options as current requirements.

Recovery and limits

• Verification finds a code defect: assign the bounded fix to its responsible worker, repeat the slice loop, then combined review and main judgment before running verification again on the changed result. A newly requested test still needs acceptance; changing an accepted assertion still needs the user's decision.
• Evidence, blockers and resume: follow shared handoffs and evidence and recovery and completion. Keep the execution context consistent with actual state.
• No subagents available: report that the requested worker workflow is unavailable and ask whether to use a serial alternative. Do not silently claim the multi-agent gates ran.