agentleFS
s977043s977043/PlanGate/.agents/skills/intent-classifier/SKILL.md

intent-classifier

Skill3 starsChanged 11 days agoMITView on GitHub

ユーザーの依頼文から開発 Intent を 8 分類し、structured JSON で返す。Use when: ユーザーの依頼を受け取った直後に意図を分類したい時。「この依頼は何を求めているか判定して」「Intent を分類して」「依頼の種別を教えて」。

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

Files
SKILL.md

Intent Classifier

正本(sync 元): .agents/skills/intent-classifier/SKILL.md。scripts/sync-plugin-plangate.sh が .agents/skills/ を読み取り plugin/plangate/skills/ を機械生成する。.claude/skills/ と .codex/skills/ は sync 対象外の配布先のため、正本更新時に同一内容を手動で追従させる。

ユーザーの依頼文を読み取り、開発 Intent を 8 分類のいずれかに判定して structured JSON で返す。

参照解決順(.claude/rules/*.md / 導入先で必ずこの順に探す)

本 Skill は責務境界の説明として .claude/rules/mode-classification.md を参照する (§責務境界)。このパスは上流リポジトリ基準のため、導入先では 次の順で探索する:

  1. 導入先リポジトリの .claude/rules/mode-classification.md
  2. 無ければ plugin root 配下 <plugin_root>/rules/mode-classification.md。 <plugin_root> は Bash で ls "${CLAUDE_PLUGIN_ROOT}/rules/" を実行して展開・確認した 絶対パス(Read ツールは絶対パスを要求し環境変数を展開しないため、${CLAUDE_PLUGIN_ROOT}/... という文字列をそのまま Read しない)。変数が空・未設定ならキャッシュを glob で推測せず 3 へ進む
  3. どちらにも無い場合は 「正本 mode-classification.md を参照できなかった」と明示し、 推測で内容を補わない

Iron Law

CLASSIFY BASED ON EXPLICIT SIGNALS, NOT ASSUMPTIONS

依頼文に存在しないシグナルで分類を変えてはならない。 曖昧な場合は confidence を下げて reasoning に根拠を示せ。

Common Rationalizations

こう思ったら現実
「文脈から明らかだから confidence=1.0 でいい」曖昧さは必ず confidence に反映しろ
「どちらにも取れるが多分 feature だろう」複数候補時は上位 2 件を candidates に列挙しろ
「short な依頼文だから判定できない」情報不足でも最良推定で判定し、confidence を下げる

Intent 分類定義

Intent説明キーワード例
feature新機能・新動作の追加追加, 実装, 作成, 新しい, 追加してほしい
bug既存機能の欠陥修正直す, 修正, エラー, バグ, 壊れている, 失敗する
refactor動作を変えずにコード構造を改善リファクタ, 整理, 整頓, 分割, 綺麗にする, 改善
research技術調査・設計調査・情報収集調査, 調べる, 比較, 評価, どうすべきか, 方針
reviewコード・設計・ドキュメントのレビューレビュー, 確認, チェック, 問題ないか, 品質
docsドキュメント・コメント・README の追加・更新ドキュメント, README, コメント, 説明, 記述
opsCI/CD・デプロイ・監視・インフラ・設定変更・PlanGate CLI 操作(render/approve/exec/doctor)デプロイ, CI, CD, インフラ, 設定, 環境, リリース, render, HTML 確認, C-3 確認, C-3 HTML, approve, plangate render, plangate approve, doctor
exploratory要件が未確定な探索的デバッグ・仮説検証ループ(「やってみて初めて問題が露呈する」タスク)→ WF-07 を推奨探索, デバッグ, 原因不明, 試す, 仮説, 段階的に, 入れ子, ビルド失敗, 何度も失敗, 検証しながら

PlanGate CLI 操作の認識(ops 補足)

「C-3 の確認を HTML で行いたい」「render して」「plangate render」「C-3 HTML を出して」などは ops に分類し、検出したら即座に以下を実行する:

ユーザー表現実行コマンド
C-3 確認を HTML / render / HTML 出力plangate render <TASK>
C-3 承認 / approveplangate approve <TASK>(別ターミナル必須)
doctor / 健全性確認plangate doctor
exec 開始 / exec してplangate exec <TASK>(C-3 APPROVED 確認後)

<TASK> はコンテキストから推定(不明なら確認)。intent=ops と判定した時点で plangate コマンドの候補を提示し、承認を待たずに実行する(render は読み取り専用)。

呼び出し表記と対象rootは分離して考える(#962)。上流 clone の cwd では bin/plangate、導入先で PATH を通した場合は plangate。対象 project root は --project-root → PLANGATE_PROJECT_ROOT → cwd git root → CLI root fallback の順で決まる。 したがって導入先repoの cwd から render / approve / read-only doctor を実行すれば その導入先を対象にする。downstream doctor --fix は #1144 解決まで rc=2 / no-write。 exec は selected project root の gate/artifact を使うが、agent runner 固有の相対パス契約に 注意し target repo の cwd から実行する。

CLI 不在時の degrade

前提(Human 決定 #1144): plugin / install.sh --claude / Codex が導入先へ配るのは 読み物層(skills / rules / agents / commands)だけであり、CLI(PlanGate CLI 本体)も enforcement 層(scripts/hooks/)も配布物に含まれない。上表のコマンドを実際に実行できるのは 上流リポジトリ(s977043/plangate)の clone がある環境だけである。CLI 実行に到達したら 「CLI が無いため実行できない/上流リポジトリの clone が必要」と明示して停止するか、 以下の代替へ置き換える。CLI が無いことを理由に手順を黙って省略し、実施済みと読める記録を 残してはならない。

plangate が PATH に無い環境(導入先では既定)でも Intent 分類そのものは CLI に依存しない ため、本 skill の判定手順・出力フォーマットは不変。変わるのは上表の「実行コマンド提示」だけで、 以下に置き換える(分類を ops 以外にすり替えない):

  • render → plan.md / review-self.md / review-external.md を直接読んでレビューする
  • approve → 人間が approvals/c3.json を発行する(AI は代理発行しない)
  • doctor → .claude/settings.json 等を直接確認する(未検証を「doctor PASS」と書かない。 検証観点の正本は plangate-setup skill)
  • exec → 手動で TDD 実行(ゲート確認の正本は ai-dev-exec skill)

ゲートの厳密な強制には CLI + hooks が必要であり、CLI 不在時は機械的な block が成立しない。 代替手順を実施した事実は status.md に記録し、CLI が無いことを理由にゲートを省略しない。

手順

Step 1: 依頼文の読み取り

ユーザーの依頼文(または直前の会話コンテキスト)を入力として受け取る。 依頼文が複数文の場合は全体を読み取り、主目的を抽出する。

Step 2: シグナル抽出

依頼文から以下のシグナルを特定する:

  1. 動詞シグナル: 「追加する」「修正する」「調査する」「レビューする」等
  2. 名詞シグナル: 「バグ」「機能」「ドキュメント」「設定」等
  3. 状態シグナル: 「壊れている」「存在しない」「改善したい」等

Step 3: 分類判定

シグナルを Intent 分類定義と照合し、最も一致する Intent を選択する。

優先順位ルール:

  • bug シグナル(エラー・壊れている・失敗)が明示されていれば bug を優先
  • 「追加」+ 「新しい」の組み合わせは feature を優先
  • 動作変更なしの「整理」「分割」は refactor を優先
  • 「どうすべきか」「比較」「評価」は research を優先
  • ドキュメント・コメントのみの変更は docs を優先
  • CI/CD・デプロイ・インフラ変更は ops を優先
  • 「原因不明」「試してみる」「何度も失敗」「段階的に調べる」は exploratory を優先(WF-07 を推奨する旨を出力に添える)

Step 4: confidence 算定

シグナル強度confidence 範囲
複数の一致シグナルあり0.85 〜 1.0
1 つの明確なシグナルあり0.65 〜 0.84
シグナルが弱い / 複数候補0.40 〜 0.64
ほぼ判断不能0.10 〜 0.39

Step 5: 出力生成

以下のフォーマットで structured JSON を出力する。

出力フォーマット

{
  "intent": "<feature|bug|refactor|research|review|docs|ops|exploratory>",
  "confidence": <0.0〜1.0>,
  "reasoning": "<判定根拠を1〜2文で説明>",
  "candidates": [
    {
      "intent": "<第2候補>",
      "confidence": <0.0〜1.0>
    }
  ]
}

フィールド仕様:

  • intent: 8 分類のいずれか(必須)
  • confidence: 0.0〜1.0 の実数(必須)
  • reasoning: 判定根拠の説明(必須)
  • candidates: confidence < 0.7 の場合は上位 2 件まで列挙(任意、省略時は空配列)

使用例

入力: 「ログイン機能を追加してほしい」

出力:

{
  "intent": "feature",
  "confidence": 0.95,
  "reasoning": "「追加してほしい」という動詞と「機能」という名詞から、新機能追加の依頼と判定した。",
  "candidates": []
}

入力: 「認証画面でエラーが出ているのを直してほしい」

出力:

{
  "intent": "bug",
  "confidence": 0.92,
  "reasoning": "「エラー」「直してほしい」というバグ修正シグナルが明示されている。",
  "candidates": []
}

責務境界(Mode / lite_eligible は判定しない)

intent-classifier は Intent 8 分類のみを担う。Mode 判定・lite_eligible 算定は行わない(それらは .claude/rules/mode-classification.md 正本 + 後段の mode 判定ステップが担当)。本スキルの出力 Intent は skill-policy-router の入力の一部となる(WF-00 advisory)。

関連 Skill

  • skill-policy-router: Intent + Mode を受け取り GatePolicy を返す。intent-classifier の出力をそのまま渡せる
  • breakdown-gate: タスク粒度の intake ゲート。intent-classifier のさらに前段で、分割が必要な粗粒度タスクを検出する(.agents/skills/breakdown-gate/)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.