com um clique
docs-drift-review
Review a pull request for concrete harness documentation drift.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Review a pull request for concrete harness documentation drift.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Repo-grounded ideation, research, and technical solution design before planning or implementation.
Research and define codebase issues before implementation planning. Use when the human explicitly invokes `$diagnose-issue`, or when an active documented workflow such as `planning-workflow`, `shape-requirements`, or `architect` routes a current-code question here. Do not select it directly from a generic bug, ticket, symptom, or design concern; enter through `planning-workflow` instead. Do not use when the user asks for a step-by-step implementation plan, direct implementation, or code review of an existing diff.
Coordinate planning from intent to implementation. Route through shape-requirements, diagnose-issue, review-spec, create-plan, plan-review, and handoff-work. Use when starting feature work, fixing a non-trivial issue, or running the full plan-build cycle.
Shape requirements before planning or implementing. Gate underspecified build, fix, or plan tasks. Interview when the user says "interview me about", "ask me questions about", "help me think through", "I need to spec out", "let's flesh out", or has a vague idea to turn into a brief.
Operate one manually stepped Harness Factory work item from intake through triage, planning, implementation, continuation, publication, and merge acknowledgement. Use when asked to run, resume, inspect, or recover Factory; interpret its next reaction or durable evidence; or apply guarded Linear projections.
Brief a code change, diff, branch, commit range, or pull request so the user can decide whether to approve, merge, revise, or build on it. Use when the user asks for a walkthrough of what changed or how it works, wants behavior or day-to-day impact, asks about API, contract, or boundary changes, questions diff size or complexity, or wants accepted tradeoffs.
| name | docs-drift-review |
| description | Review a pull request for concrete harness documentation drift. |
| disable-model-invocation | true |
Review only concrete documentation mismatches introduced by the pull request. "No drift" is a normal result.
AGENTS.md, then its linked contributor and harness documentation. Treat the closest document for the changed workflow as authoritative.dev/plans/ documents as present behavior unless the pull request itself is plan-only.Comment on the triggering pull request only. Do not push commits, open another pull request, or request changes for advisory findings.
For drift findings, use:
Summary: <harness-sensitive changes>
Must-fix drift:
- `<changed-file>` → `<affected-doc>`: <specific edit>
Advisory:
- <operator-doc bloat finding, if any>
Verification: `<relevant command>`
Use short, factual comments. Mark advisory or uncertain observations explicitly.