Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

Commencer

docs-drift-review

Étoiles3

Forks1

Mis à jour11 juillet 2026 à 01:49

Review a pull request for concrete harness documentation drift.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

ferueda

ferueda/harness

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

Explorateur de fichiers

2 fichiers

SKILL.md

readonly

name	docs-drift-review
description	Review a pull request for concrete harness documentation drift.
disable-model-invocation	true

Harness Doc Drift

Review only concrete documentation mismatches introduced by the pull request. "No drift" is a normal result.

Workflow

Resolve the pull request, repository, and base ref. Review the diff in base-branch context; do not audit unrelated existing content.
Read the repository's AGENTS.md, then its linked contributor and harness documentation. Treat the closest document for the changed workflow as authoritative.
Inspect changed harness-sensitive surfaces first:
- build manifests and task files;
- scripts, hooks, CI workflows, command surfaces, and self-tests;
- routing documentation adjacent to changed behavior.
Compare the changed behavior with its closest source-of-truth documentation. Check command existence and contracts, script inventories, mutability labels, routing links, and planned-versus-current wording.
Check operator-doc bloat only if the PR edits an agent-loaded or happy-path operator document. Flag a newly primary preview, scaffold, or non-default path; or newly duplicated caveat/command text. Keep this advisory.
Report only findings with a changed file, affected document, and precise suggested edit. Separate must-fix drift from advisory bloat. If no meaningful drift exists, post a brief no-drift comment or omit it when the PR does not touch harness surfaces.

Boundaries

Review the pull request's owning repository.
Do not treat standalone dev/plans/ documents as present behavior unless the pull request itself is plan-only.
Ignore cosmetic Markdown edits unless they alter commands, contracts, or routing.
Ignore product or feature docs unless they change harness workflow behavior.
Do not turn uncertain, theoretical, style-only, or bloat-only observations into requested changes.

Comment Contract

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.

Plus depuis ce dépôt

même dépôt

architect

ferueda/harness

Repo-grounded ideation, research, and technical solution design before planning or implementation.

2026-07-183

diagnose-issue

ferueda/harness

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.

2026-07-183

planning-workflow

ferueda/harness

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.

2026-07-183

shape-requirements

ferueda/harness

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.

2026-07-183

factory-operator

ferueda/harness

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.

2026-07-173

explain-change

ferueda/harness

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.

2026-07-153

Harness Doc Drift

Review only concrete documentation mismatches introduced by the pull request. "No drift" is a normal result.

Workflow

Resolve the pull request, repository, and base ref. Review the diff in base-branch context; do not audit unrelated existing content.

Read the repository's AGENTS.md, then its linked contributor and harness documentation. Treat the closest document for the changed workflow as authoritative.

Inspect changed harness-sensitive surfaces first:

build manifests and task files;
scripts, hooks, CI workflows, command surfaces, and self-tests;
routing documentation adjacent to changed behavior.

Compare the changed behavior with its closest source-of-truth documentation. Check command existence and contracts, script inventories, mutability labels, routing links, and planned-versus-current wording.

Check operator-doc bloat only if the PR edits an agent-loaded or happy-path operator document. Flag a newly primary preview, scaffold, or non-default path; or newly duplicated caveat/command text. Keep this advisory.

Report only findings with a changed file, affected document, and precise suggested edit. Separate must-fix drift from advisory bloat. If no meaningful drift exists, post a brief no-drift comment or omit it when the PR does not touch harness surfaces.

Boundaries

Review the pull request's owning repository.

Do not treat standalone dev/plans/ documents as present behavior unless the pull request itself is plan-only.

Ignore cosmetic Markdown edits unless they alter commands, contracts, or routing.

Ignore product or feature docs unless they change harness workflow behavior.

Do not turn uncertain, theoretical, style-only, or bloat-only observations into requested changes.

Comment Contract

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.