一键导入
ways-of-working
Agent team best practices — philosophy, routing, execution model, adversarial loop, cost management, failure modes, and brief writing.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Agent team best practices — philosophy, routing, execution model, adversarial loop, cost management, failure modes, and brief writing.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Use when updating documentation, README sections, CHANGELOG entries, docstrings, or CLAUDE.md conventions after a feature is complete.
Use when the task involves server-side API routes, middleware, business logic, authentication, database queries, or infrastructure configuration.
Task and document management with Backlog.md. Use this skill whenever working with tasks, tracking work, creating subtasks, searching or viewing existing tasks, or any time work should be preserved across sessions or handed off. Triggers include: "create a task", "track this", "add to backlog", "what tasks do I have", "mark as done", "continue on task", "break this into tasks", or any request where the outcome has a concrete deliverable worth tracking. Always use this skill when a project includes a Backlog.md setup and work needs to be logged. Prefer CLI commands unless MCP tools are confirmed working in the current environment.
Use when adversarial code review is needed — actively constructing failure scenarios, edge cases, and security violations to break the implementation.
Run code review via an external LLM API using external-review.sh. Outputs structured JSON with verdict, summary, and per-file concerns.
Use when the task involves UI components, HTML, CSS, styling, React, Vue, Svelte, client-side state, accessibility, or browser APIs.
基于 SOC 职业分类
| name | ways-of-working |
| description | Agent team best practices — philosophy, routing, execution model, adversarial loop, cost management, failure modes, and brief writing. |
AskUserQuestion for discrete options (multiple choice, yes/no, A/B/C) — never plain text.The parent runs end-to-end. Subagents are used sparingly for specific roles only:
| When | Spawn | Mode |
|---|---|---|
/plan: repo >100 files AND entry points not read | explorer (read-only, ≤20 tool calls) | parallel if researcher also spawns |
/plan: domain-specific facts needed | researcher (web search) | parallel if explorer also spawns |
/plan: new external dep flagged | researcher (dependency validation) | parallel if explorer also spawns |
/build --strict or --loops N>0 | critic (adversarial review, once per loop) | sequential (depends on builder output) |
/review --strict or --loops N>0 | critic (adversarial review, once per loop) | parallel with external-review if both enabled |
Never spawn subagents outside these rules. Default tier (/build, /review) = zero spawns. /plan default tier may spawn explorer and/or researcher per the rules above.
run_in_background=True is allowed only for independent spawns. A spawn is independent iff its inputs do not depend on another spawn's outputs from the same pipeline stage.
explorer + researcher in /plan; critic + external-review in /build --strict or /review --strict (both consume the same diff).When combining independent and dependent spawns in one pipeline:
# 1. Launch independent spawns in background
Agent(subagent_type="A", run_in_background=True, ...) # write log marker immediately
Agent(subagent_type="B", run_in_background=True, ...) # write log marker immediately
# Both markers must appear in progress before either result is consumed.
# 2. Wait point — parent blocks until both report complete
# Stall detection applies per-spawn: A stalling does not cancel B. Partial completion allowed.
# 3. Dependent spawn runs sequentially, consuming A and B outputs
Agent(subagent_type="C", run_in_background=False, ...)
A subagent producing no output for its configured stall threshold triggers a cancel-and-retry. This applies identically to foreground (run_in_background=False) and background (run_in_background=True) spawns — same threshold, cancelled the same way, parent notified the same way. Parallel fan-out does not disable stall checks.
| Agent | Model | Role |
|---|---|---|
| critic | opus | Adversarial review — tries to break code |
| researcher | sonnet | Web research, docs, library investigation |
| explorer | haiku | Codebase navigation — read only, cheap |
/build)Use when correctness matters more than speed: security-critical paths, public APIs, data migrations. Full sequence: implement → critic loop → test → review → commit.
Use for everyday work: bug fixes, small features, single-file changes. Parent handles everything inline. No subagents unless using --strict.
parent builds → critic (FAIL) → parent fixes diff only → critic → ... → critic (PASS) → commit
Key rules:
--loops N to overrideSubagents multiply tokens 4-7x. Justified when focused context beats one bloated session. NOT justified for single-file tasks or simple bug fixes. Default to lite mode; escalate with --strict.
/build or /review. Reviews diff only. Passes ONLY when no failure scenario found.| Failure | Symptom | Fix |
|---|---|---|
| Parent applies fixes mid-critic-loop | Bonus refactoring beyond flagged items | Fix only what critic flagged — nothing more |
| Critic loop won't converge | New issues each iteration | Stop → redesign approach |
| Explorer over-reads | Context bloat | Cap explorer at 20 tool calls; output paths only |
| Researcher mid-build | Build pauses for research | Invoke researcher before build, not during |
Every brief must answer:
Task type → Route
─────────────────────────────────────────────────────
Single-file / small fix → lite (just ask naturally)
Multi-file feature, hard to undo → /build <brief>
Feature planning → /plan <idea>
Harden existing code → /review <files>
Codebase question → explorer
Library/API research → researcher
Decision rule: "Could this break something across multiple systems?" Yes → /build. Otherwise → lite.