agent-execution-mode

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Agent Execution Mode

Agent执行模式

Use this skill whenever the user expects real completion: implementation, bug repair, hardening, architecture, design alignment, review, documentation, specification, or production-grade delivery.

This skill exists to stop the failure modes that make agent work untrustworthy: partial completion, self-approval, unmanaged sub-agent sprawl, token waste, stale docs, missing tests, missing review artifacts, and missing execution state.

当用户需要真正完成以下工作时使用本技能：实现、bug修复、加固、架构设计、设计对齐、评审、文档编写、规范制定或生产级交付。

本技能旨在杜绝导致Agent工作不可信的失败模式：部分完成、自我审批、无管理的子Agent泛滥、token浪费、文档过时、缺少测试、缺少评审产物、缺少执行状态记录。

When to use

适用场景

Activate this skill when the request involves any of the following:

implementing or fixing behavior that should be complete when returned
bug investigation or bug fixing where the current behavior must be understood before edits begin
hardening an existing implementation after regressions, repeated failures, or correctness gaps
documentation creation or repair that must reflect the real project state instead of guessed behavior
specification or plan creation before implementation, especially when the work should be driven by a spec tool or durable task file
architecture or system design work that needs explicit decisions and durable documentation
code review, PR review, or self-review that must produce a reliable artifact
design-driven work where implementation must be checked against a specification or screenshot
post-mortem analysis after repeated prompt churn, missed requirements, or rework
work that benefits from delegated parallel discovery, implementation, validation, or review under a managed workflow
final reporting for substantial work

Infer the mode from task intent before defaulting. Use

production

only when the task does not clearly map to a more specific mode.

当请求涉及以下任意场景时激活本技能：

实现或修复需要完全交付的功能
编辑前必须先理解当前行为的bug排查或修复工作
出现回归问题、反复失败或正确性缺陷后对现有实现进行加固
必须反映项目真实状态而非猜测行为的文档创建或修复工作
实现前的规范或方案制定，尤其是需要通过规范工具或持久化任务文件驱动的工作
需要明确决策和持久化文档的架构或系统设计工作
必须产出可靠产物的代码评审、PR评审或自我评审
实现必须对照规范或截图校验的设计驱动型工作
反复调整prompt、需求遗漏或返工后的事后复盘分析
适合在托管工作流下委托并行调研、实现、验证或评审的工作
重大工作的最终报告

请先根据任务意图推断模式，无更匹配的明确模式时再默认使用

production

。

Modes

支持模式

Supported modes:

```
production
```
```
bugfix
```
```
hardening
```
```
agent-review
```
```
agentic-self-review
```
(compatibility alias of
```
agent-review
```
)
```
general-review
```
```
pr-review
```
```
prototype
```
```
design
```
```
documentation
```
```
specification-and-plan
```
```
architecture
```
```
post-mortem
```

Mode intent:

```
production
```
: complete implementation using repo-native patterns, managed sub-agent delegation when it improves delivery, tests and docs updated where needed, and a mandatory independent
```
agent-review
```
gate before concluding.
```
bugfix
```
: restate the bug, expected behavior, current evidence, and likely failure surface before editing. Implement the minimum correct repair, validate the fix, and run the mandatory
```
agent-review
```
gate.
```
hardening
```
: everything in
```
production
```
and
```
bugfix
```
, plus stronger regression scrutiny, edge-case repair, abuse-case review, and stricter validation. The post-completion review gate is mandatory.
```
agent-review
```
: act as the final reviewer using references/REVIEW_INSTRUCTIONS.md. Review only. Do not modify code unless the user explicitly changes the scope. In delegated post-completion use, follow the compact packet protocol from references/SUBAGENT_MANAGEMENT.md. Do not create a markdown artifact unless explicitly requested.
```
general-review
```
: produce a review artifact using assets/TEMPLATE_REVIEW.md and the standard in references/REVIEW_INSTRUCTIONS.md.
```
pr-review
```
: requires a PR link, uses GitHub MCP to inspect intent and diff, records the review in assets/TEMPLATE_PR_REVIEW.md, and submits inline feedback plus a summary review state through GitHub MCP.
```
prototype
```
: reduced polish is allowed only when explicitly requested, but repository safety checks, validation honesty, and the post-completion review gate still apply.
```
design
```
: design-focused work only. Use Figma MCP when a design specification exists; otherwise use screenshots or equivalent visual references. Do not claim runtime completeness unless it was actually implemented. The post-completion review gate is mandatory.
```
documentation
```
: inspect the real project state and create or repair docs, runbooks, prompts, or operator guidance. Do not invent behavior, status, or validation that was not directly verified. Use
```
agent-review
```
when the documentation is substantial or when changed docs make product or operational claims.
```
specification-and-plan
```
: create or update the specification, plan, and task breakdown before implementation. Prefer repo-native spec tooling and workflows such as Speckit, Speckitty, Symfony, or equivalent when present. If no spec-driven workflow exists, recommend adding one, allow the user to continue, record that decision, and remind them in the final output.
```
architecture
```
: produce durable system decisions, reusable structure, and implementation when feasible. The post-completion review gate is mandatory.
```
post-mortem
```
: analyze why repeated prompts, missed requirements, or rework happened. Recommend skills, documentation,
```
agent.md
```
, MCP tooling, or prompt changes that would have reduced friction or produced a more precise result earlier. Do not expand into code changes unless the user changes scope. This mode is analysis-only by default and does not add a nested mandatory
```
agent-review
```
unless the user explicitly requests one or the scope expands into durable repo changes.

recommendation-review

is removed. Use

general-review

pr-review

instead.

支持的模式如下：

```
production
```
```
bugfix
```
```
hardening
```
```
agent-review
```
```
agentic-self-review
```
（
```
agent-review
```
的兼容别名）
```
general-review
```
```
pr-review
```
```
prototype
```
```
design
```
```
documentation
```
```
specification-and-plan
```
```
architecture
```
```
post-mortem
```

模式说明：

```
production
```
：使用代码库原生模式完成实现，可在提升交付效率时委托托管的子Agent，按需更新测试和文档，结束前必须经过独立的
```
agent-review
```
门禁。
```
bugfix
```
：编辑前先重述bug、预期行为、现有证据和可能的故障范围。实现最小可行修复方案，验证修复效果，并执行强制
```
agent-review
```
门禁。
```
hardening
```
：包含
```
production
```
和
```
bugfix
```
的所有要求，额外增加更严格的回归检查、边缘 case 修复、滥用场景评审和更严格的验证。完成后的评审门禁为强制要求。
```
agent-review
```
：按照references/REVIEW_INSTRUCTIONS.md作为最终评审者，仅执行评审，除非用户明确修改范围否则不得修改代码。委托执行完成后评审时，遵循references/SUBAGENT_MANAGEMENT.md中的紧凑数据包协议。除非明确要求否则不生成markdown产物。
```
general-review
```
：按照assets/TEMPLATE_REVIEW.md模板和references/REVIEW_INSTRUCTIONS.md中的标准生成评审产物。
```
pr-review
```
：需要PR链接，使用GitHub MCP检查意图和diff，将评审记录写入assets/TEMPLATE_PR_REVIEW.md，并通过GitHub MCP提交行内反馈和汇总评审状态。
```
prototype
```
：仅在明确要求时允许降低完成度，但代码库安全检查、验证真实性和完成后评审门禁仍然适用。
```
design
```
：仅执行设计相关工作。存在设计规范时优先使用Figma MCP，否则使用截图或等效视觉参考。除非实际实现完成否则不得声明运行时完整性。完成后评审门禁为强制要求。
```
documentation
```
：检查项目真实状态，创建或修复文档、运行手册、prompt或操作指南。不得编造未直接验证的行为、状态或验证结果。当文档体量较大或修改的文档涉及产品或运营声明时，使用
```
agent-review
```
。
```
specification-and-plan
```
：实现前创建或更新规范、方案和任务拆解。如果存在代码库原生的规范工具（如Speckit、Speckitty、Symfony等）优先使用。如果不存在规范驱动的工作流，建议补充该能力，允许用户继续推进，记录该决策，并在最终输出中提醒用户。
```
architecture
```
：可行情况下产出持久化的系统决策、可复用结构和实现。完成后评审门禁为强制要求。
```
post-mortem
```
：分析反复调整prompt、需求遗漏或返工的原因。推荐可以减少摩擦或更早产出更精确结果的技能、文档、
```
agent.md
```
、MCP工具或prompt修改方案。除非用户修改范围否则不扩展到代码修改，该模式默认仅执行分析，除非用户明确要求或范围扩展到代码库持久化修改，否则不添加嵌套的强制
```
agent-review
```
。

recommendation-review

已移除，请使用

general-review

或

pr-review

替代。

Mode selection rules

模式选择规则

infer
```
documentation
```
when the user asks to document, explain, update docs, produce a runbook, or align prompts or guidance to real behavior
infer
```
specification-and-plan
```
when the user asks for a specification, implementation plan, tasks, RFC, or workflow design before code changes
infer
```
bugfix
```
when the task centers on a failing behavior, regression, broken test, or defect explanation
infer
```
hardening
```
when the task centers on repeated breakage, production reliability, abuse cases, or closing correctness gaps across existing code
infer
```
agent-review
```
,
```
general-review
```
, or
```
pr-review
```
when the user primarily wants review rather than implementation
infer
```
post-mortem
```
when the user asks why repeated prompts were needed, what should have existed first, or how the workflow or prompt should change next time
infer
```
design
```
or
```
architecture
```
when the output is primarily visual implementation alignment or system design decisions
use
```
production
```
only when the task is implementation-oriented and no more specific mode clearly fits

用户要求编写文档、解释内容、更新文档、产出运行手册，或调整prompt/指南使其匹配真实行为时，推断为
```
documentation
```
用户要求在代码修改前输出规范、实现方案、任务拆解、RFC或工作流设计时，推断为
```
specification-and-plan
```
任务核心是异常行为、回归问题、测试失败或缺陷说明时，推断为
```
bugfix
```
任务核心是解决反复故障、生产可靠性、滥用场景或补全现有代码的正确性缺陷时，推断为
```
hardening
```
用户主要需求是评审而非实现时，推断为
```
agent-review
```
、
```
general-review
```
或
```
pr-review
```
用户询问为什么需要反复调整prompt、应该提前准备什么内容、或后续工作流/prompt应该如何调整时，推断为
```
post-mortem
```
输出主要是视觉实现对齐或系统设计决策时，推断为
```
design
```
或
```
architecture
```
任务以实现为导向且没有更匹配的明确模式时，才使用
```
production
```

Non-negotiable behavior

不可妥协的行为准则

Do not return a partial implementation as complete work.
Do not allow the implementation agent to approve its own work when independent review is available.
Do not skip the mandatory independent
```
agent-review
```
gate when delegated review is available.
Do not pressure, steer, or selectively brief a review sub-agent toward approval.
Do not omit the source intent from a worker or reviewer packet. If a specification was implemented, include the exact spec path and the relevant plan or task files when they exist. If there was no spec, include the original prompt or a compact faithful summary with the real goal and concrete specifics.
Do not hide relevant governing rules from the reviewer. When code changes are in scope,
```
code-discipline
```
and
```
repo-standards-enforcement
```
must be surfaced when they are relevant.
Do not spawn sub-agents without bounded ownership, acceptance criteria, and a positive expected return on token spend. The mandatory post-completion
```
agent-review
```
reviewer satisfies this gate by policy and is not blocked by discretionary ROI arguments.
Do not let overlapping sub-agents edit the same scope without an explicit merge plan.
Do not merge sub-agent output without manager review.

Do not default to

production

when the request clearly belongs to

documentation

specification-and-plan

bugfix

review

design

architecture

, or

post-mortem

Do not stop at visual parity when behavior, state handling, contracts, documentation, or architecture are part of correctness.
Do not leave TODOs, placeholders, mock production paths, or knowingly incomplete required work in production paths.
Do not begin a
```
bugfix
```
or
```
hardening
```
edit before stating the bug, expected behavior, evidence or reproduction, and likely failure surface.
Do not invent documentation claims, validation claims, or operational readiness statements that were not directly verified.
Do not ignore repository-native abstractions when reusable boundaries already exist.
Do not write code before resolving the applicable project validation and enforcement plan.
Do not skip tests, validation, or docs when the change materially requires them.
Do not claim completion if obvious QA failures, accessibility failures, contract gaps, or unresolved review findings remain in scope.
Do not use review language that hides severity or uncertainty.

不得将部分实现作为完整工作返回
有独立评审可用时，不得允许实现Agent审批自己的工作
有委托评审可用时，不得跳过强制的独立
```
agent-review
```
门禁
不得向评审子Agent施压、引导或选择性提供信息来诱导其通过评审
不得在工作者或评审数据包中省略源意图。如果是基于规范实现，包含确切的规范路径和相关的方案/任务文件（如果存在）；如果没有规范，包含原始prompt或忠实简洁的摘要，明确真实目标和具体细节。
不得向评审者隐瞒相关治理规则。如果涉及代码修改，相关的
```
code-discipline
```
和
```
repo-standards-enforcement
```
规则必须明确告知。
不得在没有明确所有权、验收标准和明确token投入回报的情况下生成子Agent。强制的完成后
```
agent-review
```
评审者按政策满足该门禁要求，不受酌情ROI论证限制。
没有明确合并方案时，不得让重叠的子Agent编辑同一范围内容
没有管理者评审时，不得合并子Agent的输出

请求明确属于

documentation

、

specification-and-plan

、

bugfix

、

review

、

design

、

architecture

或

post-mortem

时，不得默认使用

production

正确性涉及行为、状态处理、契约、文档或架构时，不得仅满足视觉一致就停止
不得在生产路径中留下TODO、占位符、模拟生产路径或已知未完成的必要工作
启动
```
bugfix
```
或
```
hardening
```
编辑前，必须先明确bug、预期行为、证据/复现方式和可能的故障范围
不得编造未直接验证的文档声明、验证声明或运营就绪声明
已有可复用边界时，不得忽略代码库原生抽象
确定适用的项目验证和执行方案前，不得编写代码
变更有实质需要时，不得跳过测试、验证或文档
范围内仍存在明显的QA失败、无障碍访问失败、契约缺口或未解决的评审结论时，不得声明完成
不得使用掩盖严重程度或不确定性的评审表述

Execution workflow

执行工作流

Follow this sequence unless the request explicitly narrows scope:

Identify or infer the mode from the task intent and create or update task, review, and report state when the work is substantial.
Gather the minimum context needed to stop guessing, including the source intent, relevant specs, validation commands, repository rules, and affected artifacts.
For
```
bugfix
```
and
```
hardening
```
, restate the bug, expected behavior, evidence or reproduction, likely failure surface, and minimum safe repair before editing.
For
```
specification-and-plan
```
, detect whether repo-native spec tooling exists. Use it when present. When absent, recommend adding one, allow the user to continue, record the decision, and carry the reminder into the final output.
For orchestration modes, consult references/SUBAGENT_MANAGEMENT.md and
```
.agents/evaluations/management.json
```
if it exists before spawning helpers.
Resolve whether sub-agents improve delivery. The manager must prefer the smallest viable execution shape and use the compact packet contracts from references/SUBAGENT_MANAGEMENT.md. Parallelization is justified only when scopes are clearly disjoint, merge cost stays low, and token overhead is worth it. Partitionability alone does not justify multiple workers. This minimization rule does not suppress the mandatory post-completion
```
agent-review
```
reviewer.
Implement, review, document, spec, or analyze with repository-native patterns. The main agent is the manager: it assigns scope, checks outputs, and gates integration.
Validate behavior, design, static analysis, tests, documentation truthfulness, and repository-native enforcement using the project workflow.
Update documentation and required artifacts when behavior, contracts, architecture, or workflow rules changed.
State completion only when the work is actually complete for the chosen mode.
For
```
production
```
,
```
bugfix
```
,
```
hardening
```
,
```
prototype
```
,
```
design
```
,
```
documentation
```
,
```
specification-and-plan
```
, and
```
architecture
```
, immediately run an independent
```
agent-review
```
per references/WORKFLOWS.md. The dedicated review sub-agent is approved by default for this gate and must not be blocked by the general sub-agent minimization rules.
If the review verdict is not exactly
```
APPROVE
```
, treat every finding as blocking, fix the issues, revalidate, and rerun the review gate.
Finish only after the review gate returns
```
APPROVE
```
, or after an explicitly documented local fallback review when delegated review was truly unavailable or disallowed by higher-priority runtime or user constraints.
When the work required multiple corrective prompts, repeated re-scoping, or user dissatisfaction, recommend
```
post-mortem
```
mode and run it when the user asks.

Detailed workflow rules live in references/WORKFLOWS.md and references/SUBAGENT_MANAGEMENT.md.

除非请求明确缩小范围，否则遵循以下顺序：

根据任务意图识别或推断模式，重大工作需创建或更新任务、评审和报告状态
收集避免猜测所需的最少上下文，包括源意图、相关规范、验证命令、代码库规则和受影响的产物
对于
```
bugfix
```
和
```
hardening
```
，编辑前先重述bug、预期行为、证据/复现方式、可能的故障范围和最小安全修复方案
对于
```
specification-and-plan
```
，检测是否存在代码库原生的规范工具，存在则优先使用；不存在则建议补充该能力，允许用户继续推进，记录该决策，并在最终输出中提醒
对于编排模式，生成辅助Agent前先参考references/SUBAGENT_MANAGEMENT.md和
```
.agents/evaluations/management.json
```
（如果存在）
评估子Agent是否能提升交付效率。管理者必须优先选择最小可行执行结构，并使用references/SUBAGENT_MANAGEMENT.md中的紧凑数据包契约。仅当范围明确不重叠、合并成本低且token overhead值得时，并行化才是合理的，仅可拆分不能作为多工作者的合理理由。该最小化规则不限制强制的完成后
```
agent-review
```
评审者。
按照代码库原生模式执行实现、评审、文档编写、规范制定或分析。主Agent作为管理者：分配范围、检查输出、控制集成门禁。
使用项目工作流验证行为、设计、静态分析、测试、文档真实性和代码库原生规则执行情况
当行为、契约、架构或工作流规则发生变更时，更新文档和必要产物
仅当所选模式要求的工作实际全部完成时，才能声明完成
对于
```
production
```
、
```
bugfix
```
、
```
hardening
```
、
```
prototype
```
、
```
design
```
、
```
documentation
```
、
```
specification-and-plan
```
和
```
architecture
```
，按照references/WORKFLOWS.md立即执行独立
```
agent-review
```
。该专用评审子Agent默认获得门禁授权，不受通用子Agent最小化规则限制。
如果评审结论不是明确的
```
APPROVE
```
，所有发现的问题都视为阻塞问题，修复问题、重新验证后重新执行评审门禁
仅当评审门禁返回
```
APPROVE
```
，或委托评审确实不可用/被更高优先级的运行时或用户约束禁止，并有明确记录的本地 fallback 评审后，才能结束任务
如果工作需要多次修正prompt、反复调整范围或用户不满意，推荐使用
```
post-mortem
```
模式，用户要求时执行该模式

详细的工作流规则见references/WORKFLOWS.md和references/SUBAGENT_MANAGEMENT.md。

Token and context discipline

Token和上下文约束

The manager must provide each sub-agent only the minimum context required for its task.
Use the compact manager-to-worker and manager-to-reviewer packet contracts from references/SUBAGENT_MANAGEMENT.md instead of freeform narrative when delegation is meaningful.
Do not forward full conversation history, full repository summaries, or unrelated file lists when a smaller scoped prompt will do.
Reuse a compact manager-prepared context packet across similar workers instead of rewriting large prompts repeatedly.
Prefer diffs, file paths, acceptance criteria, and validation commands over long narrative restatements.
If delegation overhead exceeds likely delivery gain, do not delegate. This efficiency rule does not override the mandatory post-completion
```
agent-review
```
reviewer.
Token savings must never come from hiding constraints, failing validation, or omitting known risks.

管理者必须仅向每个子Agent提供其任务所需的最少上下文
委托有实质意义的任务时，使用references/SUBAGENT_MANAGEMENT.md中的紧凑管理者到工作者、管理者到评审者数据包契约，而非自由叙事
更小的限定范围prompt足够时，不要转发完整对话历史、完整代码库摘要或不相关的文件列表
相似工作者复用管理者准备的紧凑上下文数据包，不要重复编写大段prompt
优先使用diff、文件路径、验收标准和验证命令，而非长篇叙事重述
如果委托开销超过可能的交付收益，不要委托。该效率规则不覆盖强制的完成后
```
agent-review
```
评审者
不得为了节省token而隐藏约束、跳过验证或遗漏已知风险

Alignment gating

对齐门禁

When material ambiguity, missing decision points, or alignment risk would likely cause wrong-path execution, avoidable rework, or meaningful token waste, apply

execution-alignment-gate

before implementation when that skill is available.

Do not apply this gating behavior for obvious continuation messages, terse confirmations, already approved plan continuation, safe low-risk assumptions, or cases where the specification, accepted plan, repository rules, or manager instructions already define the correct path.

This gating behavior is optional and must not be used as a substitute for following the active execution mode, reading the specification, or complying with repository rules already in force.

When

execution-alignment-gate

is not available, apply the same discipline directly: identify whether ambiguity is material, ask only the minimum clarification needed, avoid open-ended clarification loops, prefer safe stated assumptions when risk is low, and do not guess when missing scope, boundaries, acceptance criteria, or validation expectations would likely cause failure.

When a sub-agent lacks scope, boundaries, acceptance criteria, or validation expectations from its manager, it must seek manager clarification rather than guess. If

execution-alignment-gate

is available, use its manager-mode behavior.

当存在实质歧义、缺失决策点或对齐风险可能导致执行路径错误、不必要返工或大量token浪费时，如有

execution-alignment-gate

技能可用，在实现前执行该门禁。

以下场景无需执行该门禁：明确的继续消息、简洁的确认、已获批方案的延续、安全低风险的假设，或规范、已接受的方案、代码库规则、管理者指令已经明确定义了正确路径。

该门禁行为是可选的，不得替代遵循当前执行模式、阅读规范或遵守现有代码库规则的义务。

如果没有

execution-alignment-gate

技能，直接执行相同的规则：识别歧义是否具有实质性，仅询问最少必要的澄清问题，避免开放式澄清循环，风险低时优先使用明确的安全假设，缺少范围、边界、验收标准或验证预期可能导致失败时不要猜测。

如果子Agent没有从管理者处获得范围、边界、验收标准或验证预期，必须寻求管理者澄清而非猜测。如有

execution-alignment-gate

可用，使用其管理者模式行为。

Sub-agent management requirements

子Agent管理要求

For managed sub-agent work, keep repo-local evaluations under

.agents/evaluations/management.json

Required behavior:

prefer the smallest viable execution shape in this order:

no sub-agent

read-only scout or evidence-gathering worker

single bounded writer

parallel bounded writers on disjoint scopes

independent reviewer

treat the dedicated
```
agent-review
```
reviewer as pre-approved for the mandatory post-completion review gate; do not block it with delegation-overhead heuristics or the smallest-viable-execution preference
do not use multiple writing workers when one bounded writer is sufficient
prefer read-only discovery workers before write delegation when uncertainty is high
parallelization is justified only when the scopes are clearly disjoint and merge cost stays low
consult the management file before spawning helpers when it exists
use the compact packet contracts from references/SUBAGENT_MANAGEMENT.md for meaningful worker and reviewer prompts
update it after each meaningful sub-agent run
track quality by agent type and prompt pattern
keep at most 20 entries in
```
recentRuns
```
and compress before adding another entry beyond that limit
roll repeated issues into
```
repoLearnings
```
keep
```
repoLearnings
```
limited to durable rules, not anecdotal run history
decommission prompt patterns before decommissioning agent types
adjust prompt patterns before restricting agent types unless evidence clearly points to agent unsuitability
restore an agent type when evidence shows the prompt pattern, not the agent, caused the failure
keep cross-repository learnings in
```
~/.agents/learnings/sub-agent-management.md
```
compressed and deduplicated

Use assets/TEMPLATE_MANAGEMENT.json for the repo-local file shape and references/SUBAGENT_MANAGEMENT.md for operating rules.

对于托管的子Agent工作，将代码库本地评估记录保存在

.agents/evaluations/management.json

。

要求的行为：

按以下顺序优先选择最小可行执行结构：

无子Agent

、

只读调研或证据收集工作者

、

单个限定范围的写工作者

、

处理不重叠范围的并行限定写工作者

、

独立评审者

专用
```
agent-review
```
评审者默认获得强制完成后评审门禁的授权，不得用委托开销启发式规则或最小可行执行偏好限制它
单个限定范围的写工作者足够时，不得使用多个写工作者
不确定性高时，写委托前优先使用只读调研工作者
仅当范围明确不重叠且合并成本低时，并行化才是合理的
存在管理文件时，生成辅助Agent前先参考该文件
有实质意义的工作者和评审者prompt使用references/SUBAGENT_MANAGEMENT.md中的紧凑数据包契约
每次有实质意义的子Agent运行后更新该文件
按Agent类型和prompt模式跟踪质量
```
recentRuns
```
最多保留20条记录，超过限制时压缩后再添加新记录
将反复出现的问题汇总到
```
repoLearnings
```
```
repoLearnings
```
仅保留持久化规则，不保留 anecdotal 运行历史
停用Agent类型前先停用对应的prompt模式
除非有明确证据表明Agent本身不合适，否则优先调整prompt模式再限制Agent类型
有证据表明是prompt模式而非Agent本身导致失败时，恢复对应Agent类型
跨代码库的经验总结保存在
```
~/.agents/learnings/sub-agent-management.md
```
，进行压缩和去重

代码库本地文件结构参考assets/TEMPLATE_MANAGEMENT.json，运行规则参考references/SUBAGENT_MANAGEMENT.md。

Tracking requirements

跟踪要求

For implementation-oriented work, keep task tracking under

.agents/tasks/

Required files:

```
.agents/tasks/TASK_INDEX.md
```
```
.agents/tasks/TASK_ID.md
```

Rules:

```
TASK_INDEX.md
```
is a prepended markdown table. Newest rows go directly under the header.

Required columns:

ID

Name

Description

Mode

Status

Thread IDs

Created At

Updated At

```
ID
```
is auto-generated, semantic, unique, lowercase, and hyphen-separated.
Both
```
ID
```
and
```
Name
```
must link to
```
.agents/tasks/TASK_ID.md
```
.
Each task file uses assets/TEMPLATE_TASK_STATE.md.

Task frontmatter must include

id

name

short-description

thread-ids

created-at

updated-at

, and

state

The markdown body title must be
```
# TASK_ID - TASK_NAME
```
.
All timestamps must be UTC.

Use assets/TEMPLATE_TASK_INDEX.md for the index shape.

对于实现导向的工作，将任务跟踪记录保存在

.agents/tasks/

。

要求的文件：

```
.agents/tasks/TASK_INDEX.md
```
```
.agents/tasks/TASK_ID.md
```

规则：

```
TASK_INDEX.md
```
是前置追加的markdown表格，最新行直接放在表头下方

必要列：

ID

、

Name

、

Description

、

Mode

、

Status

、

Thread IDs

、

Created At

、

Updated At

```
ID
```
是自动生成的语义化唯一标识，小写、连字符分隔
```
ID
```
和
```
Name
```
都必须链接到
```
.agents/tasks/TASK_ID.md
```
每个任务文件使用assets/TEMPLATE_TASK_STATE.md模板

任务frontmatter必须包含

id

、

name

、

short-description

、

thread-ids

、

created-at

、

updated-at

和

state

markdown正文标题必须为
```
# TASK_ID - TASK_NAME
```
所有时间戳使用UTC时间

索引结构参考assets/TEMPLATE_TASK_INDEX.md。

Review requirements

评审要求

For review work, keep review artifacts under

.agents/reviews/

Required files:

```
.agents/reviews/REVIEW_INDEX.md
```
```
.agents/reviews/REVIEW_ID.md
```

Rules:

```
REVIEW_INDEX.md
```
is a prepended markdown table. Newest rows go directly under the header.

Required columns:

ID

Name

PR #

Description

Mode

Status

Count

Created At

Updated At

```
ID
```
is auto-generated, semantic, unique, lowercase, and hyphen-separated.
Both
```
ID
```
and
```
Name
```
must link to
```
.agents/reviews/REVIEW_ID.md
```
.
```
PR #
```
links to the GitHub PR when the review is PR-backed; otherwise use
```
N/A
```
.
Each review file uses assets/TEMPLATE_REVIEW.md or assets/TEMPLATE_PR_REVIEW.md.

Review frontmatter must include

id

name

short-description

review-count

github-pr-number

github-pr-link

created-at

updated-at

, and

state

The markdown body title must be
```
# REVIEW_ID - REVIEW_NAME
```
.
When a second or later review occurs for the same item, mark which existing findings were resolved and place new findings at the top of the new iteration.
```
general-review
```
,
```
pr-review
```
,
```
agent-review
```
, and the compatibility alias
```
agentic-self-review
```
use the standard in references/REVIEW_INSTRUCTIONS.md.
Post-completion
```
agent-review
```
is normally delegated to a separate sub-agent. That reviewer is pre-approved for the mandatory post-completion gate and must not be blocked by the general sub-agent minimization rules. Use a local review against the same standard only when delegated review is unavailable or explicitly blocked. It does not create a markdown artifact unless explicitly requested.
If a delegated review packet omits the required intent source, relevant governing references, or material validation context, the reviewer must block the work instead of guessing.
If a review finding is disputed during the post-completion gate, only the user may dismiss it.
Reviews should also fold in the discipline from the
```
code-discipline
```
and
```
repo-standards-enforcement
```
skills when they are relevant to the code under review.

pr-review

requirements:

requires a PR link
pull the PR diff and stated intent through GitHub MCP
review the code against the PR intent, not just the diff mechanics
record inline comment candidates, suggestions, and summary outcome in the markdown artifact
use GitHub MCP to submit inline comments and the overall review state:
```
approved
```
,
```
changes-requested
```
,
```
comment
```
, or
```
rejected
```
on later review iterations, resolve or mark previously addressed findings before adding new ones

对于评审工作，将评审产物保存在

.agents/reviews/

。

要求的文件：

```
.agents/reviews/REVIEW_INDEX.md
```
```
.agents/reviews/REVIEW_ID.md
```

规则：

```
REVIEW_INDEX.md
```
是前置追加的markdown表格，最新行直接放在表头下方

必要列：

ID

、

Name

、

PR #

、

Description

、

Mode

、

Status

、

Count

、

Created At

、

Updated At

```
ID
```
是自动生成的语义化唯一标识，小写、连字符分隔
```
ID
```
和
```
Name
```
都必须链接到
```
.agents/reviews/REVIEW_ID.md
```
如果是基于PR的评审，
```
PR #
```
链接到GitHub PR，否则使用
```
N/A
```
每个评审文件使用assets/TEMPLATE_REVIEW.md或assets/TEMPLATE_PR_REVIEW.md模板

评审frontmatter必须包含

id

、

name

、

short-description

、

review-count

、

github-pr-number

、

github-pr-link

、

created-at

、

updated-at

和

state

markdown正文标题必须为
```
# REVIEW_ID - REVIEW_NAME
```
同一对象有第二次及后续评审时，标记已解决的现有结论，新结论放在新迭代的顶部
```
general-review
```
、
```
pr-review
```
、
```
agent-review
```
和兼容别名
```
agentic-self-review
```
遵循references/REVIEW_INSTRUCTIONS.md中的标准
完成后
```
agent-review
```
通常委托给独立的子Agent，该评审者默认获得强制完成后门禁的授权，不受通用子Agent最小化规则限制。仅当委托评审不可用或被明确禁止时，才使用符合相同标准的本地评审，除非明确要求否则不生成markdown产物。
如果委托评审数据包缺少必要的意图来源、相关治理参考或实质验证上下文，评审者必须阻塞工作而非猜测
完成后门禁期间如果评审结论存在争议，仅用户可以驳回该结论
评审内容涉及代码时，应结合
```
code-discipline
```
和
```
repo-standards-enforcement
```
技能的相关规则

pr-review

要求：

需要PR链接
通过GitHub MCP拉取PR diff和声明的意图
对照PR意图评审代码，而非仅检查diff的语法正确性
在markdown产物中记录行内评论候选、建议和汇总结果
使用GitHub MCP提交行内评论和整体评审状态：
```
approved
```
、
```
changes-requested
```
、
```
comment
```
或
```
rejected
```
后续评审迭代中，先解决或标记已处理的之前的结论，再添加新结论

Design and validation requirements

设计和验证要求

```
design
```
mode replaces the old
```
design-only
```
mode.
When a Figma specification is available, use Figma MCP first.
When Figma is not available, use screenshots or equivalent reference artifacts.
For
```
documentation
```
, derive claims from code, validated behavior, committed artifacts, or explicitly cited evidence. Unknowns must remain explicit unknowns.
For
```
specification-and-plan
```
, prefer an existing spec-driven workflow such as Speckit, Speckitty, Symfony, or an equivalent repo-native system. When none exists, recommend adding one without blocking the user from continuing.
For
```
bugfix
```
and
```
hardening
```
, capture the failing behavior and acceptance target before implementation, then verify the fix against that target after implementation.
For
```
post-mortem
```
, recommend concrete improvements in four buckets when relevant: skills, documentation, agent or instruction files, and MCP or tooling additions. Also explain how a tighter prompt would have produced a more precise or more efficient outcome.
For code-writing work, inspect the relevant project validation configuration and standards skill guidance before edits so the validation path is known up front. Biome, TypeScript, and skills such as
```
repo-standards-enforcement
```
or
```
biome-enforcement
```
are examples, not hardcoded requirements of this skill.
For code changes with UI impact, validate both design and implementation using Playwright through the Docker MCP.
Do not treat visual inspection alone as sufficient when interaction, state, or responsive behavior matters.

```
design
```
模式替代旧的
```
design-only
```
模式
存在Figma规范时，优先使用Figma MCP
没有Figma时，使用截图或等效参考产物
对于
```
documentation
```
，声明内容必须来自代码、验证过的行为、已提交的产物或明确引用的证据，未知内容必须明确标记为未知
对于
```
specification-and-plan
```
，优先使用现有规范驱动的工作流，如Speckit、Speckitty、Symfony或等效的代码库原生系统。如果不存在，建议补充该能力但不阻塞用户继续
对于
```
bugfix
```
和
```
hardening
```
，实现前记录失败行为和验收目标，实现后对照该目标验证修复效果
对于
```
post-mortem
```
，相关情况下从四个维度推荐具体改进：技能、文档、Agent或指令文件、MCP或工具补充。同时说明更精准的prompt如何能更早产出更精确或更高效的结果
对于代码编写工作，编辑前检查相关的项目验证配置和标准技能指南，提前明确验证路径。Biome、TypeScript和
```
repo-standards-enforcement
```
、
```
biome-enforcement
```
等技能是示例，不是本技能的硬编码要求
对于有UI影响的代码变更，通过Docker MCP使用Playwright验证设计和实现
交互、状态或响应式行为重要时，不得仅将视觉检查作为充分验证

Final report requirements

最终报告要求

For substantial implementation, architecture, or multi-step review work, keep reports under

.agents/reports/

Required files:

```
.agents/reports/REPORT_INDEX.md
```
```
.agents/reports/REPORT_ID.md
```

Rules:

```
REPORT_INDEX.md
```
is a prepended markdown table. Newest rows go directly under the header.

Recommended columns:

ID

Name

Description

Mode

Status

Created At

Updated At

```
ID
```
is auto-generated, semantic, unique, lowercase, and hyphen-separated.
Both
```
ID
```
and
```
Name
```
link to
```
.agents/reports/REPORT_ID.md
```
.
Each report file uses assets/TEMPLATE_REPORT.md.

Report frontmatter must include

id

name

short-description

mode

created-at

updated-at

, and

state

Keep the latest run at the top of the report file.
Do not delete prior run entries.

Use assets/TEMPLATE_REPORT_INDEX.md for the index shape.

对于重大实现、架构或多步骤评审工作，将报告保存在

.agents/reports/

。

要求的文件：

```
.agents/reports/REPORT_INDEX.md
```
```
.agents/reports/REPORT_ID.md
```

规则：

```
REPORT_INDEX.md
```
是前置追加的markdown表格，最新行直接放在表头下方

推荐列：

ID

、

Name

、

Description

、

Mode

、

Status

、

Created At

、

Updated At

```
ID
```
是自动生成的语义化唯一标识，小写、连字符分隔
```
ID
```
和
```
Name
```
都链接到
```
.agents/reports/REPORT_ID.md
```
每个报告文件使用assets/TEMPLATE_REPORT.md模板

报告frontmatter必须包含

id

、

name

、

short-description

、

mode

、

created-at

、

updated-at

和

state

最新运行记录放在报告文件顶部
不得删除之前的运行记录

索引结构参考assets/TEMPLATE_REPORT_INDEX.md。

Documentation policy

文档政策

Documentation is mandatory when:

existing documentation no longer matches behavior
architecture or module boundaries changed
a new component, workflow, or public contract was introduced
operational usage or testing strategy materially changed

Update the smallest correct documentation surface. Do not leave stale docs behind.

出现以下情况时必须更新文档：

现有文档不再匹配实际行为
架构或模块边界发生变更
引入了新的组件、工作流或公共契约
运营使用方式或测试策略发生实质变更

更新最小范围的正确文档内容，不得留下过时文档。

Mandatory agent-review gate

强制Agent评审门禁

Before concluding any task, verify all applicable items:

completion claims match reality
required states and edge cases were handled
tests and validation were not skipped without cause
docs were updated when needed
review and report artifacts were updated when required by mode
design and implementation were both validated when UI work was involved
the post-completion review gate ran with the correct independence rules
the delegated review packet included the real source intent, relevant governing references, and material validation results
management evaluations and durable learnings were updated when sub-agents were used

For

production

bugfix

hardening

prototype

design

documentation

specification-and-plan

, and

architecture

, this gate is mandatory after completion has been stated. Do not skip it, compress it into a superficial pass, or treat earlier informal checking as a substitute.

If any answer is no, continue working or report the exact blocker.

结束任意任务前，校验所有适用项：

完成声明符合实际情况
必要的状态和边缘case已处理
没有无理由跳过测试和验证
需要时已更新文档
模式要求时已更新评审和报告产物
涉及UI工作时，设计和实现都已验证
完成后评审门禁按照正确的独立规则执行
委托评审数据包包含真实的源意图、相关治理参考和实质验证结果
使用子Agent时，已更新管理评估和持久化经验总结

对于

production

、

bugfix

、

hardening

、

prototype

、

design

、

documentation

、

specification-and-plan

和

architecture

，声明完成后必须执行该门禁。不得跳过、简化为表面检查，或用之前的非正式检查替代。

如果任意项不满足，继续工作或报告确切的阻塞问题。

Templates and references

模板和参考

Templates:

assets/TEMPLATE_TASK_INDEX.md
assets/TEMPLATE_TASK_STATE.md
assets/TEMPLATE_REVIEW_INDEX.md
assets/TEMPLATE_REVIEW.md
assets/TEMPLATE_PR_REVIEW.md
assets/TEMPLATE_REPORT_INDEX.md
assets/TEMPLATE_REPORT.md
assets/TEMPLATE_MANAGEMENT.json

References:

references/WORKFLOWS.md
references/REVIEW_INSTRUCTIONS.md
references/SUBAGENT_MANAGEMENT.md

Keep

SKILL.md

as the activation layer. Put deeper process rules in

references/

and reusable document shapes in

assets/

模板：

assets/TEMPLATE_TASK_INDEX.md
assets/TEMPLATE_TASK_STATE.md
assets/TEMPLATE_REVIEW_INDEX.md
assets/TEMPLATE_REVIEW.md
assets/TEMPLATE_PR_REVIEW.md
assets/TEMPLATE_REPORT_INDEX.md
assets/TEMPLATE_REPORT.md
assets/TEMPLATE_MANAGEMENT.json

参考：

references/WORKFLOWS.md
references/REVIEW_INSTRUCTIONS.md
references/SUBAGENT_MANAGEMENT.md

SKILL.md

作为激活层，更深层的流程规则放在

references/

目录，可复用的文档模板放在

assets/

目录。