Harness Doc Lifecycle
MUST use when governing Harness document lifecycle: archive docs, stale docs, superseded docs, deprecated docs, invalidates, updates, superseded_by, old ADRs, old plans, old specs, old research, resolved discussions, fixed bug reports, completed Features, oversized active docs directories, 文档归档, 过期文档, 旧文档, 被替代, 废弃, or 生命周期.
Harness Knowledge Retrieval
MUST use when starting or resuming non-trivial work that may depend on project context, prior decisions, ADRs, Lessons, Features, specs, plans, Evidence, stale documents, rejected approaches, recovery context, 恢复上下文, 查历史决策, 查 ADR, 查 Lesson, 查 Feature, 查知识库, or 避免重复踩坑 before acting.
Using Harness
MUST use as the Harness entrypoint before non-trivial engineering work, behavior changes, reviews, commits, PRs, handoffs, or any completion claim; also use when the user mentions Harness, harness, gates, Evidence, ADRs, Lessons, Feature memory, patch churn, spec drift, stale spec, 知识沉淀, 收尾, 完成声明, 提交信息, or PR 描述.
Harness Knowledge Capture
MUST use before claiming engineering work is complete, fixed, verified, reviewed, ready to commit, ready for PR, ready for handoff, or safely closed; also use for Evidence, Feature state, ADR/Lesson decisions, Backlog or handoff state, patch churn, bugfix attribution, 知识沉淀, 经验沉淀, 完成声明, 收尾, 准备提交, 准备 PR, or 交接.
Harness Change Narrative
MUST use before explaining, summarizing, committing, handing off, or publishing a specific engineering change, including commit messages, PR descriptions, merge notes, release notes, progress summaries, root cause, rejected approaches, why not alternatives, verification context, historical intent, workaround decisions, future caution, 提交信息, PR 描述, 交接说明, 变更总结, 当前进展, 复盘, or 为什么这么改.
Harness Delegation Gate
MUST use when non-trivial or high-risk engineering work may benefit from implementation subagents, parallel exploration, independent code review, or independent Vision Gate review; use before coding, review, release, handoff, or completion to choose exactly one main-agent decision: single_agent, delegate, or blocked.
Harness Readiness Dashboard
MUST use before non-trivial review, merge, release, handoff, PR readiness, completion claims, progress assessment, maturity assessment, distance to target, roadmap gap, delivery gap, remaining modules, overall progress, 整体进展, 距离目标, 还差多少, 当前成熟度, 交付缺口, 功能模块缺口, ready 检查, 收尾前状态, 是否可以交付, 是否可以 review, 是否可以 handoff, 反复补丁, or 归零审视 when Codex needs a Harness readiness rollup without creating new artifacts.
Harness Spec Drift
MUST use when real cases, validation failures, user feedback, stale specs, outdated specs, acceptance criteria drift, SDD drift, or implementation follows spec but still wrong; triggers include old spec no longer trusted, spec vs reality conflict, repeated patches caused by wrong assumptions, 过期 Spec, 验收标准偏离, 真实案例推翻假设, or SDD 跑偏.
Harness Incident Learning
MUST use after a bug, incident, outage, regression, repeated process miss, recurring failure, repeated patch chain, patch churn, Fxxx.n follow-up sequence, or rule/keyword/filter growth has been fixed, stabilized, or grown enough to need root cause analysis, trigger analysis, recurrence-risk assessment, zero-base review, prevention, tests, gates, Lessons, ADRs, CI, scripts, permissions, durable E…
Harness Project Rules
MUST use when deciding whether a decision, lesson, incident learning, evidence pattern, recurring project constraint, patch-churn guardrail, zero-base review rule, or proposed agent instruction should be promoted into AGENTS.md or another project-level agent rule file. Guides rule promotion, rejection, wording, source linking, preventing AGENTS.md bloat, 项目军规, 写进 AGENTS.md, Agent 规则, 反复补丁, 归零审视,…
Harness Start Gate
MUST use before starting non-trivial AI-assisted engineering work, multi-file bugfixes, behavior changes, refactors, or implementation after task intake to decide whether the agent may implement now or must first clarify scope, retrieve project knowledge, run Vision Gate, run Spec Drift, run Delegation Gate, or create/update a Feature, spec, plan, ADR, Backlog, or handoff anchor; triggers include…
Harness Vision Gate
MUST use when non-trivial engineering work may drift from user intent before implementation, coding, refactoring, review, merge, done, acceptance, release, or handoff, including repeated patch chains where the current abstraction may be wrong; covers original-intent checks, scope alignment, acceptance-criteria drift, patch churn, product direction, user pain point, UI alignment, deliverable-goal…