parallel-execution
Build-test orchestration protocol for choosing and running parallel or serial implementation lanes with shared requirement contracts, convergence gates, and triage routing. Use when coordinating multiple concurrent implementation paths, managing convergence gates, or running triage routing. DO NOT USE FOR: exploring ideas or trade-offs (use brainstorming) or evaluating architecture (use software-architecture).
- License 许可
- MIT
- 最近更新
- 2026-08-16
- Stars
- ★ 3
- Forks
- 0
01 前言 Front Matter
- name
- parallel-execution
- description
- Build-test orchestration protocol for choosing and running parallel or serial implementation lanes with shared requirement contracts, convergence gates, and triage routing. Use when coordinating multiple concurrent implementation paths, managing convergence gates, or running triage routing. DO NOT USE FOR: exploring ideas or trade-offs (use brainstorming) or evaluating architecture (use software-architecture).
02 资源文件 4
- 参考文档platforms/claude.md802 B
- 参考文档platforms/copilot.md396 B
- 参考文档references/error-handling.md8.2 KB
- 参考文档references/lean-dispatch-example.md1.5 KB
03 SKILL.md 正文
Parallel Execution Skill
Composite References
- references/error-handling.md: canonical R5 subagent-call resilience, common issue routing, escalation patterns, terminal non-interactive guardrails, and terminal lifecycle protocol.
- references/lean-dispatch-example.md: dispatch-prompt economy — lean before/after dispatch example for the canonical-source reference pattern.
Mode Declaration
Declare one mode before delegation: Execution Mode: parallel or Execution Mode: serial.
Record it in the progress-log header, step.metadata.execution_mode, the user-facing update, and any step-commit details tracked in the plan.
Requirement Contract (Mandatory)
Before delegation, define one shared Requirement Contract for the step:
Acceptance-criteria slice, explicit invariants and edge cases, and non-goals.
Both implementation and testing lanes must use the same contract.
Protocol
- Choose mode using stability/risk criteria.
- Create Requirement Contract before any lane starts.
- Run lanes:
parallel: launch Code-Smith and Test-Writer against the same contract.serial: run one lane first, then the second against the same contract.
- Run triage via Test-Writer after outputs are available.
- Classify failures as
code defect,test defect,harness/env defect, orrc-divergencewith evidence. - Route corrections bidirectionally until convergence:
code defect-> Code-Smithtest defect-> Test-Writerharness/env defect-> responsible specialist or tooling pathrc-divergence-> Code-Smith fixes implementation to match the Requirement Contract; CC re-evaluates; if divergence remains, Test-Writer re-derives assertions from the Requirement Contract, not the corrected implementation.
- Enforce convergence gate before advancing.
- Run RC conformance check: CC evaluates the step's Requirement Contract AC items against delivered code after convergence. Divergences route as
rc-divergenceusing step 6.
Convergence Gate (Mandatory)
Do not advance until Test-Writer explicitly confirms:
Green tests, valid assertions, and no brittle coupling.
After convergence, protocol step 8 verifies the Requirement Contract AC items before step advance.
Loop Budget
- Maximum 3 correction cycles per step.
- If exceeded, perform root-cause review and escalate with a recommended option.
- RC conformance correction gets 1 dedicated cycle outside the main 3-cycle budget. If still unresolved, escalate with the unresolved AC items and recommended options.
Anti-Test-Chasing Guardrail
Code-Smith must satisfy the Requirement Contract and architecture constraints, not merely optimize for current failing assertions.
If a property or test appears over-constrained or invalid, classify it as potential test defect and route it back for test review with evidence.
Post-Issue Checkpoint (Mandatory)
At issue/PR completion, record a short process checkpoint:
What slowed us down, what failed late, and what single guardrail should be added next?
Track this in the completion summary to improve future cycles. For subagent rate-limit handling, execution-time escalation, and terminal guardrails that pair with this execution contract, load references/error-handling.md.
Gotchas
| Trigger | Gotcha | Fix |
|---|---|---|
| Lanes start with different requirements | Parallel work diverges and convergence turns into rework or churn | Define one shared Requirement Contract before any lane starts |
Platform-specific invocation
This skill's methodology is tool-agnostic. Platform-specific routing lives alongside platforms/copilot.md and platforms/claude.md.
04 同仓库更多 Skills
webapp-testing
Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).
verification-before-completion
Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any "I'm finished" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).
validation-methodology
Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).
upstream-onboarding
Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.
ui-testing
Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).
ui-iteration
Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).