Plan Linter(ゲート1 計画バリデータ)

開発着手前に、`tasks/` 配下のタスク契約とバンドルに対してゲート1の決定的静的チェックを実行します。タスク契約が存在し、ブラスト半径、差分予算、宣言ファイルトポロジ、トレーサビリティアンカー、仕様アンカーカバレッジ、継承ADR、機械検査可能な完了条件、DAG非循環性を検証する必要がある場合に使用します。コード実行、CIパイプライン構築、AST/複雑性チェック、テスト監査(品質エンジニアリング担当)には使用しないでください。

Plan Linter(ゲート1 計画バリデータ) とは?

Plan Linterは、開発着手前にタスク計画の品質と一貫性を機械的に検証するための決定的ツールです。ゲート1では、契約ファイルの存在、メタデータの妥当性、タスクIDの一意性、タッチファイル数、推定行数、仕様アンカー、ADR参照、完了条件、禁止プレフィックス、プレースホルダの有無、依存関係グラフの非循環性など、20以上のチェックを実行します。ゲート2は別途`review`スキルで提供される意味論的レビューであり、このスキルはその独立したフォールバックとして`references/gate-2-review.md`を保持します。このスキルはコード実行、CI構築、AST解析、テスト監査を一切行わず、純粋に計画文書の静的検証に特化しています。Pythonの標準ライブラリのみで動作し、オフラインでも使用可能です。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/formal-you/agent-skills-suite/tree/HEAD/.agents/skills/plan-linter

Installed? Explore more 生産性&コラボレーション skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Plan Linter(ゲート1 計画バリデータ) は何をしますか?

このスキルは、単一で厳密に境界付けられた責任を持ちます:開発着手前に tasks/ 配下の計画タスク契約とバンドルに対するゲート1の決定的静的検証を行うことです。

  • ゲート1 はこのスキル内の決定的スクリプトです:高速、オフライン、標準ライブラリのみ。
  • ゲート2 はプロンプトのみの意味論的レビュー(review スキル、フォールバックとして references/gate-2-review.md を使用)です。
  • 非目標:plan-linter はコードを実行せず、CIパイプラインを構築・実行せず、AST/コード複雑性分析を行わず、テストや 03-qa-verification.md に記録されたQA複雑性/ミューテーション証拠の監査(プレースホルダスキャンと存在チェックのみ)は行いません。すべてのCIパイプラインと検証ゲートは quality-engineering が担当し、ローカルテストは qa が担当します。

ゲート1:決定的チェック

チェックデフォルトオーバーライド可能
01-contract.md が存在し、有効なメタデータを持つ必須いいえ
task_id がディレクトリ名と一致する必須いいえ
task_id がバンドル間で一意必須いいえ
touch_files の数1..3max_touch_files
estimated_lines50..250min_diff_lines, max_diff_lines
origin_spec_anchor が #sec-[a-z0-9-]+ に一致必須require_anchor
adherence_adrs が少なくとも1つのADRをリスト必須require_adrs
dod.type_check, dod.lint, dod.test_file必須いいえ
dod.edge_cases の数最低2つmin_edge_cases
02-dev-workspace.md, 03-qa-verification.md, 04-process.md が存在必須require_docs
禁止タッチプレフィックスtests/acceptance/forbidden_touch_prefixes
01/02/03 内の未解決プレースホルダブロックscan_placeholders
03-qa-verification.md の内容レベルのQA証拠監査しない(ゲート3)いいえ
逆トポロジ:modifyパスの存在、createパスの非存在警告check_topology, strict_topology, --repo-root
size_class micro: change_id の存在、1つのタッチファイル、小さな予算micro の場合必須micro_min_diff_lines, micro_max_touch_files
change_id が変更ディレクトリ配下にオープンな提案を持つ--changes-dir が指定された場合必須--changes-dir
仕様アンカーカバレッジマトリックス(未カバーセクション)レポート; --require-full-coverage でエラー--spec, --coverage-out
契約アンカーが仕様にない警告; --strict-anchor でエラー--spec
依存関係グラフ非循環、欠落タスクなしいいえ

すべてがチェックされます。出力の順序は安定しています。

クイックスタート

# 標準レポートまたは機械可読JSON
python .agents/skills/plan-linter/scripts/plan_linter.py --tasks-dir ./tasks
python .agents/skills/plan-linter/scripts/plan_linter.py --tasks-dir ./tasks --json

# カスタム設定またはレガシーフォーマット
python .agents/skills/plan-linter/scripts/plan_linter.py --tasks-dir ./tasks --config plan-linter.json
python .agents/skills/plan-linter/scripts/plan_linter.py --tasks-dir ./tasks --legacy

# ゲート2ヒューリスティックとCIブロッキングモード
python .agents/skills/plan-linter/scripts/plan_linter.py --tasks-dir ./tasks \
  --repo-root . --spec .specs/02-tech-spec.md --changes-dir .specs/changes --json
python .agents/skills/plan-linter/scripts/plan_linter.py --tasks-dir ./tasks \
  --spec .specs/02-tech-spec.md --strict-topology --strict-anchor --require-full-coverage

このスクリプトはオプションです。Pythonが利用できない場合は、references/gate-2-review.md を手動チェックリストとして使用し、同じフィールドを手動でレビューしてください。

ゲート2は別の review スキルです。 ゲート1が終了コード0で終了した後、review スキル(plan-reviewモード)がインストールされている場合はそれを使用して独立した意味論的監査を行います。このスキルは、review スキルがインストールされていない場合の自己完結型フォールバックとして references/gate-2-review.md を保持します。ゲート1を置き換えることは決してありません。

終了コード

コード意味
0すべてのタスクバンドルでゲート1合格
1違反が見つかりました(または契約フロントマターを解析できません)
2使用法または設定エラー
3予期しない内部エラー

契約フォーマット

01-contract.md のYAMLフロントマターが権威です。以下の人間用テーブルはオプションの可読性補助です。

---
task_id: task-001-auth
title: "ユーザー認証"
module: auth
dependencies: [task-000-bootstrap]
estimated_lines: 120
touch_files:
  - action: create
    path: src/auth/service.py
  - action: modify
    path: src/auth/routes.py
origin_spec_anchor: "#sec-auth"
adherence_adrs: [ADR-001]
dod:
  type_check: "npm run type-check"
  lint: "npm run lint"
  test_file: "tests/acceptance/test_auth.ts"
  edge_cases:
    - "空の資格情報で400を返す"
    - "期限切れトークンで401を返す"
---

ルール:

  • task_id はタスクディレクトリ名と一致する必要があります。パスはリポジトリ相対で、フォワードスラッシュを使用します。
  • touch_files は禁止プレフィックス(デフォルトでは tests/acceptance/)を指してはいけません。
  • 01/02/03 にプレースホルダ({{...}}, [TBD], TODO)を残してはいけません。

レガシーフォールバック

YAMLフロントマターのない契約は、v2より前のレイアウト用にテーブルフォールバックを使用し、LEGACY_FORMAT 警告を出力します。--legacy を追加して強制的にフォールバックします。

設定

{
  "max_touch_files": 3,
  "min_diff_lines": 50,
  "max_diff_lines": 250,
  "require_anchor": true,
  "require_adrs": true,
  "min_edge_cases": 2,
  "require_docs": ["02-dev-workspace.md", "03-qa-verification.md", "04-process.md"],
  "forbidden_touch_prefixes": ["tests/acceptance/"],
  "scan_placeholders": true,
  "micro_min_diff_lines": 10,
  "micro_max_touch_files": 1,
  "check_topology": true,
  "strict_topology": false,
  "ignore_task_dirs": ["archive"]
}

しきい値はリポジトリの慣習であり、普遍的な法則ではありません。プロジェクトごとにオーバーライドしてください。未知のキーは警告を生成し、型が間違った値は終了コード2で終了します。

JSON出力

{
  "gate": "1",
  "passed": true,
  "tasks_scanned": 3,
  "errors": [],
  "warnings": [],
  "coverage": {
    "spec": ".specs/02-tech-spec.md",
    "spec_anchors": 3,
    "covered": ["#sec-alpha", "#sec-beta"],
    "uncovered": ["#sec-gamma"],
    "contract_anchors_missing_from_spec": [],
    "coverage_ratio": 0.6667
  }
}

coverage は --spec が渡された場合のみ存在します。--coverage-out はそれをファイルに書き込みます。

各エラーオブジェクトには、task、code、message、file、line のキーがあります。エラーコードは安定した英語の識別子です(例:MISSING_DOC、TASK_ID_MISMATCH、DAG_CYCLE、PLACEHOLDER、TOUCH_FILE_MISSING、FORBIDDEN_TOUCH_FILE、BDD_MISSING_PRECONDITION、BDD_MISSING_ACTION、BDD_MISSING_OUTCOME、BDD_INVALID_SCENARIO、SPEC_SECTION_UNCOVERED)。アーカイブされた提案はエラーの代わりに CHANGE_ALREADY_ARCHIVED を生成し、ignore_task_dirs(tasks/archive)は保留中のバンドルとして決してスキャンされません。完全なエラーリファレンス:references/gate-2-review.md。

ゲート2:意味論的レビュー(プロンプトのみ)

ゲート1が合格した後、references/gate-2-review.md を独立したレビューアーとして従ってください。以下のいずれかで要約します:

  • Gate 2 Plan Review Passed: 0 omissions, 0 hallucinations;または
  • 発見リスト:タスクディレクトリ、汚染されたフィールド、違反したADR ID。

ゲート2は手動です。スクリプトは意味論的真実性を判断できません。レビューされるまでは合格としないでください。

移植性、境界、非目標

このスクリプトは標準ライブラリのみを使用し、自身のディレクトリからの相対パスを解決し、ファイルを書き込むことはありません。

厳密な境界と非目標:

  • コードを実行しない:DoDコマンド、アプリケーションコード、テストスイートを決して実行しません。
  • CIオーケストレーションをしない:CIパイプラインを構築、管理、実行しません(quality-engineering が担当)。
  • ASTまたは複雑性分析をしない:サイクロマティック複雑性 $V(G)$ を計算しません(quality-engineering が担当)。
  • テストまたは検証監査をしない:03 QA証拠を監査しません。4つのドキュメントの存在チェックと未解決プレースホルダスキャンだけが 03-qa-verification.md に触れます。複雑性、ベーシスパスカバレッジ、ミューテーションMSIはゲート3(quality-engineering/verification_linter.py)が監査します。
  • 意味論的判断をしない:意味論的真実性を判断しません(ゲート2はプロンプトレビューです)。
  • RBACの強制をしない:gitベースのRBAC監査を置き換えません。

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

formal-you/agent-skills-suite

Run a bounded brownfield change (bugfix, small feature, behavior tweak) against an existing spec or codebase: proposal -> one task bundle -> dev/QA -> converge -> archive. Use when an existing spec or codebase needs an incremental change (bugfix, small feature, behavior tweak) and a full PRD is overkill. Do not use for greenfield requirements (use prd-generator), architecture decisions (use spec-generator), or pure task slicing (use task-decomposition).

formal-you/agent-skills-suite

Fold confirmed implementation deviations back into the technical spec after a task reaches QA_PASSED, archive the task bundle and close the change proposal. Use when a task bundle records a checked QA_PASSED verdict and its 02-dev-workspace.md deviation log is ready to be written back. Do not use while implementation or QA is still running, and do not use to invent spec content.

formal-you/agent-skills-suite

Implement one planned task bundle as the Dev role: read the contract, change only touch_files, run the machine-checkable DoD, fill 02-dev-workspace.md and hand off to QA. Use when a task contract exists and you are assigned implementation. Do not use for planning, task slicing, architecture, or QA verification.

formal-you/agent-skills-suite

Use on Windows for unexpected DSH sandbox access denials: workspace writes or listing fail, or an ordinarily readable path cannot be read. One bundled command inspects the path and every ancestor and repairs the ACL problems it proves in that same run. Expected confinement denials need no ACL repair.

関連スキル