メニュー
Harden a documentation/contract plan before adversarial review by mapping every issue-scope requirement to independent acceptance criteria and tests, especially for routing/indexing contracts.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/vamseeachanta/workspace-hub --skill documentation-contract-plan-hardeningコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | documentation-contract-plan-hardening |
| description | Harden a documentation/contract plan before adversarial review by mapping every issue-scope requirement to independent acceptance criteria and tests, especially for routing/indexing contracts. |
| version | 1.0.0 |
| category | workspace-hub-learned |
| tags | ["planning","adversarial-review","documentation","contract","routing","indexing"] |
Use when drafting a plan for a docs/standards/contract issue where the deliverable is a policy/contract/checklist rather than runtime code.
In issue #2460 (tier-1 indexing and code-placement contract), all three adversarial reviewers returned MAJOR because the plan looked reasonable at a high level but failed a stricter standard:
DATA_PLACEMENT.md but were not independently testableFor documentation-contract plans, every correctness-critical scope item from the issue body must map to:
If multiple issue-scope requirements are compressed into one generic test, adversarial reviewers will (correctly) call the plan under-specified.
Create a table in your notes before finalizing the plan:
| Issue requirement | Planned artifact section | Acceptance criterion | Test/validation |
|---|---|---|---|
| operator maps required | contract section "Required routing surfaces" | contract explicitly requires docs/maps/<repo>-operator-map.md | test_contract_requires_operator_maps |
| machine-readable registry | contract section "Required routing surfaces" | contract requires one canonical registry per repo | test_contract_requires_registry |
| code/tests/docs routing table | checklist + contract section | contract/checklist define routing-table semantics | test_contract_requires_routing_table |
repo vs /mnt/ace/data placement | code-placement section | contract encodes data-placement rule | test_contract_encodes_data_placement_rule |
| daily freshness | freshness section | contract states cadence and follow-through issue | test_contract_defines_daily_freshness_and_links_followup |
Do not proceed until each issue-scope bullet has its own row.
If the plan cites a baseline document such as:
docs/standards/CONTROL_PLANE_CONTRACT.mddocs/standards/FILE_STRUCTURE_TAXONOMY.mddocs/standards/DATA_PLACEMENT.mdthen the plan must say exactly what rule from that document becomes part of the new contract and how that rule will be tested.
Bad:
Good:
/mnt/ace/data decision rule and checklist rows must verify whether each tier-1 repo's routing guidance points large/generated outputs off-repo."If you need to retire a legacy pattern, do NOT write a test like:
test_contract_avoids_legacy_patternunless the plan defines:
Better pattern:
Example split:
test_contract_declares_legacy_product_doc_conventions_retiredtest_contract_does_not_recommend_<exact_legacy_pattern>If a plan cites a local artifact that may not exist on the canonical branch yet (for example a newly generated report in a dirty working tree), say so explicitly.
Use one of these two patterns:
If you don't disambiguate this, reviewers may flag the plan as coupled to unpublished state.
When the deliverable includes both a contract doc and a checklist doc, include tests for:
Otherwise the checklist can become an orphan artifact.
If the issue title says "indexing and code-placement contract" but the planned file is named only INDEXING_CONTRACT, reviewers may treat that as scope loss.
Either:
Prefer many small assertions over one umbrella test.
Bad:
test_contract_contains_required_sectionsBetter:
test_contract_requires_agents_mdtest_contract_requires_readmetest_contract_requires_docs_readmetest_contract_requires_operator_maptest_contract_requires_machine_readable_registrytest_contract_requires_routing_tabletest_contract_encodes_data_placement_ruletest_contract_declares_daily_freshness_ruletest_contract_links_followup_issue_2465Use before sending any documentation/contract plan to Codex/Gemini/Claude for adversarial review, especially when:
cat:documentation or cat:harnessA reviewer should be able to point at each issue-scope bullet and immediately see:
If not, the plan is still too soft for adversarial review.