菜单
Full execution protocol for MODE: PLAN -- plan creation, external plan ingestion, QA gate persistence, task granularity, and traceability checks.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
End-to-end CI monitor that takes an already-human-reviewed PR, exhaustively researches every CI failure, fixes it end-to-end, iterates until all required checks are green (max 5 fix cycles), then merges. Use only after human review is complete and the PR is approved. Composes ci-fix-monitor for failure-type-specific fix recipes. This is the first skill in the repo that executes a merge — invoke it deliberately.
Execute complex implementation work with a swarm-like workflow: parallel exploration, scoped planning, objective validation, mandatory independent implementation review for changed work, and final critic approval. Use for feature work, bug fixes, refactors, and multi-file changes.
Monitor a pull request after creation and act autonomously on pushed PR activity. Use when subscribing to a PR after opening it, when asked to watch, babysit, or autofix a PR until merge, or when a <pr-activity> wake message or [pr-monitor:...] advisory arrives for a subscribed PR. Owns event triage (fix / ask / skip), bounded-retry escalation, and terminal-state cleanup.
Cross-agent swarm-mode behavior model — a higher-rigor workflow using parallel investigation, independent reviewer validation, and critic challenge, plus the mandatory implementation closeout gate. Runtime adapters (.claude, .agents) add execution-specific notes and command wiring.
Full execution protocol for MODE: BRAINSTORM -- structured discovery dialogue, approach selection, spec drafting, QA gate selection, and transition handling.
Full execution protocol for MODE: CLARIFY-SPEC -- resolving spec clarification markers and maintaining spec/planning alignment.
| name | plan |
| description | Full execution protocol for MODE: PLAN -- plan creation, external plan ingestion, QA gate persistence, task granularity, and traceability checks. |
This protocol is loaded on demand by the architect stub in src/agents/architect.ts. The architect prompt keeps only activation, action, and hard safety constraints; the full execution details live here.
SPEC GATE (soft — check before planning):
An effective spec exists iff /swarm sdd status reports a resolved spec (it reflects readEffectiveSpecSync, which returns null for no sources, multiple competing sources, multi-feature Spec-Kit without a selected feature, or any unresolvable state). Do NOT enumerate these cases — defer to /swarm sdd status.
/swarm sdd status):
/swarm sdd status) and compare its first heading (or feature description) against the current planning context (the user's request and any existing plan.md title/phase names)This is a SOFT gate. When the user chooses "Skip and plan directly", proceed to the steps below exactly as before — do NOT modify any planning behavior.
SAVE_PLAN SPEC_REQUIRED RECOVERY:
When save_plan returns a SPEC_REQUIRED rejection (no effective spec found), the architect MUST:
/swarm sdd status to determine why no effective spec resolved.
/swarm sdd status shows NO sources → transition to MODE: SPECIFY./swarm sdd status shows multiple competing sources (e.g., openspec AND specify with no native) → ask the user which provider to use (openspec or speckit), then run /swarm sdd project --source <user_choice> (obtain explicit consent first; add --overwrite only if a native .swarm/spec.md already exists). Then re-attempt save_plan./swarm sdd status shows Spec-Kit with multiple features → ask the user which feature, then run /swarm sdd project --source speckit --feature <id> (obtain explicit consent first; add --overwrite only if a native .swarm/spec.md already exists). Then re-attempt save_plan./swarm sdd status shows a single resolvable source but it was not yet materialized: run /swarm sdd project (obtain explicit consent first; add --overwrite only if a native .swarm/spec.md already exists). Then re-attempt save_plan.Run CODEBASE REALITY CHECK scoped to codebase elements referenced in the effective spec or user constraints. Discrepancies must be reflected in the generated plan.
Before drafting or saving the plan, the architect MUST offer General Council advisory input when council.general.enabled is true in the resolved opencode-swarm config and a search API key is configured.
web_search queries grounded in the work being planned.the active swarm's council_generalist agent, the active swarm's council_skeptic agent, and the active swarm's council_domain_expert agent in PARALLEL with the RESEARCH CONTEXT.convene_general_council with mode general..swarm/context.md under ## Decisions.save_plan.save_plan rather than writing an ungrounded plan.General Council is advisory and distinct from council_mode, phase_council, and final_council. It is not a QA gate. Its purpose here is to make current external context available before the architect writes any plan and before any critic pre-plan review.
Before calling save_plan — whether creating a new plan or finalizing an external plan ingestion — the architect MUST run this four-stage clarification funnel. The goal is to limit unnecessary user interruption, not planning completeness.
Identify ALL uncertainties that could affect the plan. There is NO hard cap on the internal inventory. Cover at minimum:
Classify each item as exactly one of:
self_resolved: answered from the user request, spec, plan, codebase reality check, .swarm/context.md, repo conventions, or an informed default. If the default is not directly supported by user request, spec, or recorded context, classify as user_decision rather than self_resolved.critic_resolved: sent to Critic Sounding Board and resolved by the critic.research_needed: needs SME/explorer/domain lookup before user escalation. Important: If research is ongoing, monitor the timeout configured in .swarm/config.json under research_needed_timeout_ms (default: 300000ms / 5 minutes). If research does not complete before the timeout expires, automatically reclassify the item to user_decision with a note that research was incomplete, then surface it to the user. This prevents the clarification funnel from stalling while waiting for external research.user_decision: only the user can decide because it affects product scope, risk tolerance, policy, budget, UX, rollout, or destructive behavior.deferred_nonblocking: useful follow-up detail that does not block a correct initial plan and can be explicitly recorded as an assumption or follow-up.Before asking the user any planning clarification question, the architect MUST consult critic_sounding_board with the candidate question set and context.
For each item classified as research_needed or user_decision in Stage 2, send it to the critic. The critic responds with a verdict from SoundingBoardVerdict (see src/agents/critic.ts). The mapping between critic verdicts and funnel actions is:
| Critic Verdict (SoundingBoardVerdict) | Funnel Action | Meaning |
|---|---|---|
UNNECESSARY | DROP | Item is unnecessary or answerable from existing context |
RESOLVE | RESOLVE | Critic supplies the answer or recommended default |
REPHRASE | REPHRASE | Question is valid but should be clearer, narrower, or grouped |
APPROVED | ASK_USER | User decision is genuinely required |
Hard constraint: Items in the Always-Surface Categories list (below) MUST NOT receive UNNECESSARY/DROP from the critic — only REPHRASE or APPROVED/ASK_USER are allowed. If the critic attempts to UNNECESSARY/DROP an always-surface item, override to APPROVED/ASK_USER.
Overconfidence guard: If the critic attempts to self-resolve an item by supplying an answer (verdict RESOLVE) but the underlying default is not directly supported by user request, spec, or recorded context, the architect MUST classify the item as user_decision rather than self_resolved. Unsupported defaults must not be silently accepted.
Update classifications based on critic response:
UNNECESSARY/DROP → reclassify as self_resolved and record the reason.RESOLVE → reclassify as critic_resolved and record the answer as an assumption.REPHRASE → update the question wording and keep as candidate.APPROVED/ASK_USER → confirm as user_decision.The architect MUST update the plan's assumptions with all resolved items before proceeding to Stage 4.
Exception: QA gate selection questions are already mandatory user decisions (enforced by the save_plan tool itself) and do NOT need to go through the funnel. QA gate selection is always a direct user dialogue.
If any items remain classified as user_decision after Stage 3, present them as a structured decision packet — NOT as an arbitrary subset or a single question.
The packet MUST include for each decision:
The architect MAY ask questions one at a time in interactive mode, but MUST preserve and report the full unresolved list. The architect MUST NOT drop unresolved decisions because of a session question cap.
The critic may improve wording or confirm prior context, but these categories MUST be surfaced to the user unless already explicitly answered by the user or by recorded context:
All items resolved in Stages 2-3 (self_resolved, critic_resolved, deferred_nonblocking) MUST be recorded as explicit assumptions in .swarm/context.md under ## Decisions before calling save_plan. Silently dropping resolved uncertainties is a protocol violation — every uncertainty that entered the funnel must have a recorded outcome.
The plan generated by save_plan MUST include explicit assumptions and remaining unresolved decisions in the task descriptions or acceptance criteria — not silently omit them.
Implementation Note: The hard constraint against DROP on always-surface items (Stage 3 of the clarification funnel) is currently enforced via skill instructions to the architect. A lightweight runtime enforcement mechanism is recommended: when processing the critic sounding board verdict response in src/agents/critic.ts, validate that any items tagged as "always-surface" do not receive UNNECESSARY/DROP verdicts. If a DROP verdict is encountered on an always-surface item, override it to APPROVED/ASK_USER at the code level rather than relying solely on prompt-based enforcement.
This mechanical enforcement prevents the following failure mode: the architect prompt instructs the override, but due to parsing errors, context limits, or model behavior variance, the DROP verdict is mistakenly applied to an always-surface item and silently accepted. The validation should occur in the decision-packet assembly code (when building the final clarification packet to surface to the user) and should emit a warning log when an override is applied.
Use the save_plan tool to create the implementation plan. Required parameters:
title: The real project name from the spec (NOT a placeholder like [Project])swarm_id: The swarm identifier (e.g. "mega", "local", "paid")phases: Array of phases, each with id (number), name (string), and tasks (array)id (e.g. "1.1"), description (real content from spec — bracket placeholders like [task] will be REJECTED)size (small/medium/large), depends (array of task IDs), acceptance (string)Example call: save_plan({ title: "My Real Project", swarm_id: "mega", phases: [{ id: 1, name: "Setup", tasks: [{ id: "1.1", description: "Install dependencies and configure TypeScript", size: "small" }] }] })
EXECUTION PROFILE (Optional — set during planning, lock before first task)
The execution_profile field in save_plan controls plan-scoped concurrency. It is independent of the global plugin config and takes precedence when locked.
Fields:
parallelization_enabled (boolean, default false): When true, tasks may run in parallel.max_concurrent_tasks (integer 1–64, default 10): Maximum simultaneous tasks when parallel is enabled.council_parallel (boolean, default true): When true, council review phases may parallelise.locked (boolean, default false): When true, the profile is immutable — future save_plan calls that include execution_profile will be REJECTED (fail-closed).WHEN TO SET IT:
LOCK DISCIPLINE:
WRONG: Setting execution_profile after tasks have started (profile would not apply retroactively). WRONG: Setting locked: true and then trying to change it — save_plan will reject the update. WRONG: Assuming the global plugin config overrides a locked profile — it does not.
Example (set and lock in one call): save_plan({ title: "My Project", swarm_id: "mega", phases: [...], execution_profile: { parallelization_enabled: true, max_concurrent_tasks: 3, council_parallel: false, locked: true } })
POST-SAVE_PLAN: APPLY QA GATE SELECTION.
Auto-loop exception: when this PLAN step is running inside MODE: LOOP with
autonomy=auto, do not ask the gate/parallelism/commit-frequency question. Use
the balanced-speed defaults from the loop skill, call set_qa_gates with those
values after save_plan, keep phase-level commits, and set a locked
execution_profile automatically when the plan has dependency-ready,
file-disjoint tasks. Choose the largest safe count, clamped to the configured
limit (currently 6); use serial execution when scopes overlap or are unknown.
After save_plan succeeds, read .swarm/context.md:
## Pending QA Gate Selection section exists: parse the gate values, call set_qa_gates with those flags, confirm with the user ("QA gates applied: "), then remove the section from context.md.## Pending Parallelization Config section also exists: parse the values and call save_plan again with execution_profile set to { parallelization_enabled: <parsed>, max_concurrent_tasks: <parsed>, council_parallel: false, locked: true }. Then remove the section from context.md. If the plan already had execution_profile.locked: true, skip this step — the profile is already locked and immutable.## Task Completion Commit Policy section exists: preserve it in .swarm/context.md (do NOT remove). This section is execution-time guidance for optional per-task checkpoint commits after update_task_status(status="completed").CouncilMemberVerdict objects, and calls write_final_council_evidence. This does not require council.general.enabled.
Additionally, present these two sub-items as part of the same exchange:COMMON MISCONCEPTION: worktree isolation is baseline for standard parallel coders, governed by the parallel execution profile plus top-level
worktree.policy. It is not provided by Lean Turbo or Epic. Do not recommend Lean Turbo or Epic to obtain worktree isolation; recommend them only for what they add beyond baseline (Lean Turbo: lane planning, file locks, phase reviewer, integrated diff; Epic: co-change awareness and auto-decide). Worktrees also do not make overlapping scopes safe: dependency readiness, file-disjoint scopes, and merge-back ownership are still required.
## Pending Parallelization Config section to .swarm/context.md alongside the gate selection:## Pending Parallelization Config
- parallelization_enabled: true
- max_concurrent_tasks: <user's number>
- council_parallel: false
- locked: true
- recorded_at: <ISO timestamp>
.swarm/context.md:
## Task Completion Commit Policy
- commit_after_each_completed_task: true
- recorded_at: <ISO timestamp>
## Task Completion Commit Policy section already exists in context.md, honor it as execution-time guidance (do NOT remove).## Task Completion Commit Policy section exists AND pending gate/parallelization sections were pre-written, ask the commit-frequency question now. Write the section to context.md if the user chooses per-task commits; skip if they keep the default phase-level behavior.INLINE GATE SELECTION — no pending section found in context.md. You MUST ask now. ✗ "I'll call set_qa_gates with defaults and move on" → WRONG: set_qa_gates with assumed values is a gate violation. The user must answer first. ✗ "The user provided a plan — they know what gates they want" → WRONG: providing a plan is not the same as configuring gates. Always ask.
MANDATORY PAUSE: Present the gate question. Wait for the user's answer.
Do NOT call set_qa_gates until the user has responded.
Then call set_qa_gates with the user's chosen flags.
Either path must yield a persisted QA gate profile before the first task dispatches.
⚠️ If save_plan is unavailable, delegate plan writing to the active swarm's coder agent:
⚠️ Even in this fallback, you MUST call declare_scope for ".swarm/plan.md" BEFORE the coder delegation. Scope discipline applies to plan-writing delegations too. See Rule 1a.
TASK: Write the implementation plan to .swarm/plan.md
OUTPUT: .swarm/plan.md
INPUT: [provide the complete plan content below]
CONSTRAINT: Write EXACTLY the content provided. Do not modify, summarize, or interpret.
TASK GRANULARITY RULES:
TEST TASK DEDUPLICATION: The QA gate (Stage B, step 5l) runs test_engineer-verification on EVERY implementation task. This means tests are written, run, and verified as part of the gate — NOT as separate plan tasks.
DO NOT create separate "write tests for X" or "add test coverage for X" tasks. They are redundant with the gate and waste execution budget.
Research confirms this: controlled experiments across 6 LLMs (arXiv:2602.07900) found that large shifts in test-writing volume yielded only 0–2.6% resolution change while consuming 20–49% more tokens. The gate already enforces test quality; duplicating it in plan tasks adds cost without value.
CREATE a dedicated test task ONLY when:
If in doubt, do NOT create a test task. The gate handles it. Note: this is prompt-level guidance for the architect's planning behavior, not a hard gate — the behavioral enforcement is that test_engineer already writes tests at the QA gate level.
PHASE COUNT GUIDANCE:
Also create .swarm/context.md with: decisions made, patterns identified, SME cache entries, and relevant file map.
TRACEABILITY CHECK (run after plan is written, when an effective spec exists):
OBLIGATION TRACEABILITY — STRUCTURAL COMPLETENESS PRECONDITION The obligation-traceability mapping is a STRUCTURAL COMPLETENESS precondition. It MUST be evaluated BEFORE the critic begins its substantive 5-axis/7-dimension rubric. An unmapped MUST/SHALL obligation makes the plan structurally incomplete — it is not an afterthought.
FR-### MAPPING (existing requirement):
/swarm sdd status) MUST map to at least one task → unmapped FRs = coverage gap, flag to userSC-### MAPPING (MUST/SHALL obligations):
/swarm sdd status) for every SC-### line whose obligation text contains MUST or SHALL/SHALL NOTREPORT FORMAT: "TRACEABILITY: FRs mapped, unmapped FRs (gap), tasks with no FR mapping (gold-plating risk),
MUST/SHALL SCs mapped, unmapped MUST/SHALL SCs (structural gap)"
After the QA gate selection has been persisted via set_qa_gates and the TRACEABILITY CHECK is complete:
critic_pre_plan is enabled (default: ON): the plan MUST be reviewed by the critic before any implementation begins.