菜单
Dispatches Claude Code Task subagents to run prompts from a vault plan note. Tracer-first execution, time-budgeted work, calibrated review rigor. Use when the user says "execute the plan", "run group A", "dispatch", or is ready to run prompts from a `Plans/Plan YYYY-MM-DD HHmm` note in the vault.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Sheshiyer/skill-clusters --skill conducty-execute命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Arcplume runs Grok through the Grok Build CLI's own OAuth-authenticated session (grok login) for image generation, with strict preflight validation, secret-safe handling, and headless CLI-driven execution -- no separate XAI_API_KEY billing. Video falls back to the billed xAI API. USE WHEN a user wants to generate an image via a locally logged-in Grok Build CLI session, e.g. 'generate an image with grok', 'use grok build', or 'use my logged-in grok session'.
Shared reference for the Selemene cluster: the two report surfaces (deterministic Rust reports vs. narrative witness-pipeline readings), the @selemene/bridge CLI contract, the output manifest format, and non-prescriptive witnessing tone. USE WHEN deciding which Selemene surface to invoke or when routing between birth/compatibility/transit reports and solo/dyadic readings.
Route Selemene Engine tasks to the right surface: deterministic reports (birth/compatibility/transit) via selemene-core and the @selemene/bridge CLI, or narrative witness readings via selemene-report. USE WHEN the user wants anything under the Selemene/Noesis umbrella but has not named the exact surface.
正在显示 SKILL.md
基于 SOC 职业分类
| name | conducty-execute |
| description | Dispatches Claude Code Task subagents to run prompts from a vault plan note. Tracer-first execution, time-budgeted work, calibrated review rigor. Use when the user says "execute the plan", "run group A", "dispatch", or is ready to run prompts from a `Plans/Plan YYYY-MM-DD HHmm` note in the vault. |
| aliases | ["conducty-execute","execute"] |
| tags | ["conducty/skill","conducty/execute"] |
| cluster | conductor |
| version | 1.0.0 |
| origin | robertbarclayy/conducty (MIT), patched for the skill-clusters resolver |
Execute prompts from the active plan note (in the Obsidian vault — see [[conducty-obsidian]]) by dispatching fresh Claude Code subagents (via the Task tool) with context curation, time budgets, and review rigor that scales with risk. The first prompt in each group runs as a tracer to validate plan assumptions before the rest execute.
Tracer-first: The prompt marked ★ TRACER in each group runs alone. If it succeeds, the plan's assumptions hold and the remaining prompts execute. If it fails, stop — the plan needs revision, not just a fix prompt. Tracers catch bad assumptions before they multiply across an entire group.
Time-budgeted: Each prompt has a time budget from the plan. If a subagent exceeds it, that's a signal — either the prompt is underscoped, the complexity was misjudged, or the agent is stuck. Treat it as a circuit breaker, not a hard kill.
Calibrated review: Not every prompt needs the same oversight. The plan assigns a review level based on complexity:
| Review Level | When | What Happens After Implementation |
|---|---|---|
verify-only | Low complexity | Run verification command. Pass? Done. |
spec-review | Medium complexity | Run verification + dispatch spec reviewer. |
full-review | High complexity | Run verification + spec reviewer + quality reviewer. |
Context curation: The orchestrator (you) constructs exactly what each subagent needs. Not your session history, not the entire project — precisely the prompt text, relevant context files, and scene-setting for where this work fits. This is the surgical team model: the surgeon thinks, the team executes with curated information.
1. Read the plan note from the vault, extract the tracer prompt for the target group
2. Dispatch tracer as a single implementer subagent (Task tool)
3. Handle the result:
- DONE → Run verification via [[conducty-verify]] → Pass? Proceed to Phase 2
- DONE → Verification fails → STOP. This is a plan problem, not a prompt problem.
Analyze: is the verification wrong, or is the plan's approach wrong?
- BLOCKED/NEEDS_CONTEXT → STOP. The plan's assumptions are wrong.
Don't execute the remaining prompts. Revise the plan.
4. Report tracer result to user before proceeding
The tracer is your early warning system. Respect its signal.
For each remaining prompt in the group:
1. Dispatch implementer subagent (see [[implementer-prompt]])
2. Handle implementer status (see below)
3. Apply review level from the plan:
- verify-only → Run verification. Pass? Mark complete.
- spec-review → Run verification + dispatch spec reviewer ([[spec-reviewer-prompt]])
- full-review → Run verification + spec reviewer + quality reviewer ([[quality-reviewer-prompt]])
4. If review fails → implementer fixes → re-review (same level)
5. Mark prompt complete with evidence
After all prompts → run [[conducty-checkpoint]] for the group
Gate: user confirms before next group
Integration patch (skill-clusters — the rest of this skill is upstream conducty, MIT). Stock conducty dispatches every prompt to a bare
general-purposesubagent. Here each prompt is first resolved to a skill-cluster, so the subagent runs loaded with the right capability hub — the one organ conducty lacks. Seeconductor-corefor the full contract.
Once per group, resolve the plan's tasks to clusters:
node ~/.agents/skill-clusters/scripts/resolve-task.mjs <tasks.md> <plan.md> --json
Returns, per task: {cluster, dispatch: <cluster>-orchestrator, tier, activate?, spokes[], confidence}.
Apply per prompt:
Classifier proposes, resolver validates. You (the conductor) are the classifier: from each
prompt's intent, propose its cluster — and optionally a specific skill. Feed your proposals back
to the resolver, which validates them against skill-index.json:
# proposals.json: { "T002": "rust", "T010": {"cluster":"supabase","skill":"supabase-postgres-best-practices"} }
node ~/.agents/skill-clusters/scripts/resolve-task.mjs <tasks.md> <plan.md> --propose proposals.json --json
# or inline: --propose "T002=rust,T010=supabase"
The resolver returns source: "classifier" when it accepts your proposal, ◇!/overrode when
your pick beat the keyword guess, and — crucially — rejects phantoms: a proposed cluster or
skill not in the index is dropped (phantoms/badSkills) and the keyword result is kept. This
is PAI's Capability-Name audit applied to dispatch. confidence < 0.34, cluster: null, or a
rejected phantom with no keyword fallback → escalate to the human, do not guess-dispatch.
Activate deferred clusters the wave touches, once:
node ~/.agents/skill-clusters/scripts/tier.mjs --activate <cluster> --apply.
Load the resolved hub into the subagent — add ~/.agents/skill-clusters/skills/<cluster>-orchestrator/SKILL.md
to the curated context (checklist item 1.5 below). The hub routes to its spoke on demand; you
never enumerate spokes — the subagent pulls the one it needs from the pointer.
Gate. The PAI SkillClusterResolver hook denies any non-enumerated skill with resolution
guidance, so a mis-resolved dispatch fails closed rather than running the wrong capability.
subagent_type stays general-purpose (or Explore for read-only review) — the capability
comes from the loaded <cluster>-orchestrator, not the subagent type.
Use Claude Code's Task tool. The default subagent_type is general-purpose (always available) — but in this repo the subagent runs loaded with the resolved <cluster>-orchestrator (see Resolve before dispatch above): the subagent type stays general-purpose, the capability comes from the loaded hub. If the harness exposes specialized subagents (e.g. Explore for read-only codebase analysis, Plan for architecture work), use them where their description fits — they don't replace the implementer model selection below.
Choose model by the prompt's complexity:
| Complexity | Model | Why |
|---|---|---|
| Low (isolated function, clear spec, 1-2 files) | haiku | Fast and cheap; sufficient for narrow work |
| Medium (multi-file, integration, pattern matching) | sonnet | Default for most implementation work |
| High (design judgment, broad codebase understanding) | opus | Reserve for genuinely hard problems |
For read-only review subagents (spec reviewer, quality reviewer, code-review lens subagents), use the Explore subagent type if available; otherwise general-purpose. Run them at haiku or sonnet — review is pattern matching, not generation.
Context curation checklist — provide exactly:
<cluster>-orchestrator SKILL.md — the capability hub for this task (see Resolve before dispatch); the subagent runs loaded with it and pulls spokes on demandDo not provide: Your session history, unrelated plan context, the entire project tree.
DONE: Apply the prompt's review level.
DONE_WITH_CONCERNS: Read the concerns. Correctness/scope concerns → address before review. Observational concerns (file getting large, questionable existing patterns) → note for future planning, proceed to review.
NEEDS_CONTEXT: The prompt was underspecified. Provide the missing context and re-dispatch. Check the project context file first. If the context doesn't exist, this is a prompt quality issue — note it for [[conducty-improve]].
BLOCKED: Assess the blocker:
opus)Never force-retry without changing something. If the agent said it's stuck, something about the prompt, the context, or the model needs to change.
When a subagent has been running significantly longer than the prompt's time budget:
Long plans burn the orchestrator's context window. Each subagent dispatch returns a result back into your session, plan-note reads accumulate, and verification output stacks up. Without management you run out of context mid-plan and lose conceptual integrity.
The orchestrator is a stateful coordinator, but its session is cache — durable state lives in the vault (plan notes, checkpoint notes, [[Prompt Log]]). Treat /compact as a normal phase boundary, not a panic move.
When to /compact:
full-review (three subagents per prompt — implementer + spec reviewer + quality reviewer — accumulates fast)Compact protocol:
[[Prompt Log]] has entries for each prompt in the group/compact summarizes the session[[Prompt Log]]Never compact mid-group. A compact between the tracer and the rest of a group risks losing the tracer's signal — the evidence that justified proceeding. Finish the group, checkpoint, then compact.
Subagents are unaffected. Each subagent dispatch is a fresh Task with a fresh window. Your /compact has no impact on already-dispatched or future subagents — they receive curated context per dispatch regardless.