hirokita117

Collect user's implicit knowledge (business context, technical constraints, past failures, hidden assumptions) through interactive dialogue and save as _interview-notes.yaml before executing feature documentation skills. Use when running /interview command or automatically before any start-teams-doc phase. Generic design allows use with skills beyond teams-docs.

Unified entry point for generating feature documentation in the teams/ directory. Automatically detects the current phase (Discovery, Design, QA, Operations) and delegates to the appropriate skill. Use when creating new feature docs, continuing existing feature docs, or when user says /start-teams-doc.

Generate Design phase documents (non-functional requirements, domain modeling, ADR, specifications) in the teams/ directory. Phase 2 of the /start-teams-doc workflow. Requires Discovery phase approval. Use when creating design documents, ADRs, ER diagrams, or non-functional requirements.

Generate Discovery phase documents (PRD and user stories) in the teams/ directory. Phase 1 of the /start-teams-doc workflow. Use when creating PRDs, user stories, or requirements definitions under teams/.

Generate Operations phase documents (SLO/SLA definitions, performance test records, operational runbooks) in the teams/ directory. Phase 4 of the /start-teams-doc workflow. Requires QA phase approval. Use when defining SLO/SLA, creating runbooks, or documenting operational procedures.

Generate QA phase documents (test plan, non-functional requirement tests, Gherkin scenarios) in the teams/ directory. Phase 3 of the /start-teams-doc workflow. Requires Design phase approval. Use when creating test plans, test scenarios, Gherkin .feature files.

ユーザーが指定したドキュメント（Markdown・テキスト・仕様書・設計書・README・議事録・PRD 等）を読み取り、 内容の構造・論点・関係を、固定ルールの DSL `document-map v1` テキストに落とす Skill。 Turn a document (Markdown, spec, design doc, README, meeting notes, PRD) into a fixed-grammar `document-map v1` DSL — generation only, no drawing. タイトル・主要セクション・重要概念・要件・決定事項・未決事項・リスク・関係者・外部依存と、 それらの関係を、意味層（ノード・エッジ）とレイアウト層に分けて出力する。深度（0/1/2）で 大きさを制御し、まず粗く、必要なら対象セクションを絞って深掘りする。全文要約はしない。 次のような発話で起動する: 「このドキュメントを図解して」「この仕様書を構造化して」「この Markdown を図にしたい」 「この PRD の論点マップを作って」「この議事録を関係図にして」「この設計書の構成を可視化して」 「添付ファイルを document-map DSL にして」「この要件定義の構造を地図にして」「ドキュメントの論点を整理して図に」 「README の全体像を図解」「会議メモの決定事項と宿題を関係図に」「この章だけ詳しく構造化して」。 出力は必ず `# document-map v1` で始まるテキスト。 禁止: DSL を出さずに Mermaid / SVG / HTML など図を直接生成しないこと（描画は `notation-render` の役割）。 ドキュメントの全行・全項目を網羅して詰め込まないこと（重要なものへ圧縮する）。リポジトリ解析はしないこと （それは `repo-map-notation`）。

巨大なリポジトリの構造を、固定ルールの DSL `repo-map v1` テキストに落とす Skill。 Turn a (possibly huge) repository into a fixed-grammar `repo-map v1` DSL — generation only, no drawing. ディレクトリ・パッケージ境界・代表的な依存関係を読み取り、認知負荷を下げる「地図の素」を 意味層（ノード・エッジ）とレイアウト層に分けて出力する。スコープ（root）と深度（0/1/2）で 大きさを制御し、まず粗く、必要に応じて範囲を絞って深掘りする。 次のような発話で起動する: 「このリポジトリを図解して」「アーキテクチャ地図を作って」「依存関係を DSL にして」 「モノレポの構造を可視化したい」「コードベースの全体像が欲しい」「repo-map を作って」 「構造をテキストで持ちたい」「どのパッケージが何に依存しているか地図にして」 「オンボーディング用の構造図を」「認知負荷を下げる地図がほしい」「この範囲を深掘りした地図に」。 出力は必ず `repo-map v1` テキスト。 禁止: DSL を出さずに Mermaid / Figma など図を直接生成しないこと（描画は `notation-render` の役割）。 リポジトリの全ファイルを列挙して DSL に埋め込まないこと（package / module 粒度に抽象化する）。

notation（`repo-map v1` / `document-map v1` DSL）を、**DSL テキストだけ**を入力に、決定的に図へ変換する Skill。 Render a notation DSL (`repo-map v1` or `document-map v1`) into a deterministic diagram — input is the DSL text ONLY. 先頭行のバージョンで対応を分岐する（未知バージョンは描かず拒否）。 `parse → validate → layout → emit` の手順で、同じ DSL からは常に同じ図を出す。出力は HTML（既定・単一ファイルの インタラクティブ Viewer・クリック質問パネル付き・`data-*`＋凡例）、任意で Mermaid。色・フォント・配置は固定テーマと固定アルゴリズムで決まり、 実行ごとにブレない。 次のような発話で起動する: 「この DSL を HTML にして」「repo-map を描画して」「document-map を描画して」「notation を可視化して」「地図を HTML で見せて」 「DSL を図にして」「repo-map v1 をレンダリングして」「document-map v1 をレンダリングして」「この記法を絵にして」「構造図を HTML で出力」 「出力された DSL を描いて」「同じ DSL なら同じ図にして」「凡例つきの HTML プレビューで」。 禁止（重要・本文でも再掲）: 入力された DSL 以外（自然言語の要望・口頭のレイアウト・リポジトリの再走査）から 図を描かないこと。DSL が無ければ描かず、不足や矛盾は `repo-map-notation` に差し戻すこと。 同じ DSL から毎回異なるレイアウトを出さないこと。

`repo-map v1` から生成された HTML Viewer に、ローカル Claude Code 連携・プロンプトコピー・ Python ブリッジ起動手順を足して「対話できる地図」にする Skill。 Make a generated repo-map HTML viewer interactive: click a node, then ask local Claude Code about it — via a stdlib-only Python localhost bridge, or via prompt-copy fallback. 描画そのものではなく、生成済み HTML を使った理解補助・対話ビューアを担当する （描画は `notation-render`、DSL 生成は `repo-map-notation`）。 次のような発話で起動する: 「repo-map HTML をインタラクティブにしたい」「Claude Code と HTML Viewer をローカルでつなぎたい」 「Python ブリッジを使って Claude Code に質問したい」「生成済み repo-map HTML からコード理解を深めたい」 「プロンプトコピー方式または localhost bridge 方式で使いたい」「図のノードをクリックして質問したい」 「ローカルで repo-map を見ながら Claude に聞きたい」。 完全にローカル用途（外部サーバ・社内 Git にアップロードしない）。Node.js 不使用、Python 標準ライブラリのみ、 裏側は `claude` CLI。任意コマンド実行はさせない。

記法中心設計（Notation-first design / Mid Notation Pattern, MNP）の共通土台を提供する Skill。 Shared principles for notation-first design: keep a DSL as the single source of truth and split generation from rendering. リポジトリ図解に限らず「意味層を DSL として正本化し、生成（AI・人が編集）と 表現（描画）を分離する」設計の用語・原則・検証観を扱う。`repo-map-notation` と `notation-render` の 土台であり、初回や設計判断に迷ったときに参照する。 次のような発話で参照する: 「記法の設計原則を知りたい」「DSL と描画を分けたい」「中間記法で図解したい」 「MNP 的に状態をテキストで持ちたい」「記法中心設計とは何か」「DSL を正本にする設計にしたい」 「意味層とレイアウトを分けたい」「AI に決まった記法で出力させたい」「同じ入力なら同じ図にしたい」 「notation の共通ルールを決めたい」「新しい記法（DSL）を設計したい」「同期ループを設計したい」 「自由作図をやめて決まった記法にしたい」。 この Skill 自体は具体的な DSL 文法を定義しない（それは `repo-map-notation` の役割）。原則と用語のみを扱う。

Diagnose a skill folder for best practices compliance based on the Agent Skills specification. Use when user says "check my skill", "validate this skill", "review skill quality", "skill lint", or wants to verify a SKILL.md follows naming, frontmatter, description, progressive disclosure, security, and structural best practices. Do NOT use for creating or editing skills (use skill-creator instead).

Perform automated code review on staged changes or branch diffs. Use when the user requests a code review, asks to review their changes, or invokes /code-review. Analyzes diffs for correctness, security, performance, maintainability, test coverage, and type safety issues. Adapts to the project's tech stack and conventions automatically.

Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.

turn core.yaml + view.yaml (the explainer's meaning + presentation strategy) — plus quiz.yaml when present — into a self-contained html bundle that helps users understand documents, repositories, pull requests, design notes, or specifications. the bundle has a light/dark shell whose right pane switches between multiple iframe view documents, and copyable prompt templates that ask a local-file-reading ai to add another switchable view. an interactive quiz tab (comprehension check with instant grading) is added by default unless the user explicitly declines. use when the user has (or wants) a core.yaml/view.yaml pair and wants a visual html explainer, or wants to add a new representation (table, worktree, cards, faq, beginner, engineer, pdm view, quiz, …) to an existing bundle. produce the yaml first with the generate-explainer-yaml skill.

analyze a document, repository summary, pull request, README, design note, or specification and produce (or refine) the intermediate yaml files that drive the explainer pipeline — core.yaml (the semantic structure / meaning), view.yaml (the presentation strategy for a particular reader), and, by default, quiz.yaml (comprehension-check questions derived from core.yaml; skipped only when the user explicitly declines a quiz). use when the user wants to capture what a target means and how to show it before generating an html explainer, or wants to edit/reshape an existing core.yaml / view.yaml / quiz.yaml. the generate-explainer-html skill then turns these yaml files into a switchable, light/dark html bundle.

Diagnose a skill folder for best practices compliance based on the Agent Skills specification. Use when user says "check my skill", "validate this skill", "review skill quality", "skill lint", or wants to verify a SKILL.md follows naming, frontmatter, description, progressive disclosure, security, and structural best practices. Do NOT use for creating or editing skills (use skill-creator instead).

仕様書・PRD・Design Doc から「仕様の複雑度」と「検証コスト」の2つを定量化するスキル。仕様複雑度はビジネスルール数、条件分岐・例外パス数、状態遷移数、影響ドメイン/チーム数、外部連携、データ移行、後戻り可能性(可逆性)から、検証コストは検証可能性(受け入れ基準の有無と機械検証への委譲可能性)、影響範囲の把握コスト、変更の凝集性から、LLMが構造化JSONとして抽出し決定論的スクリプトで採点、低/中/高のバンドと複雑度/検証コストのドライバーを報告する。「この仕様の複雑度を測って」「認知負荷スコアを出して」「レビューコスト/検証コストを見積もって」「リファインメント前に複雑さを評価して」「このPRDをスコアリングして」等の依頼、または `/scoring-spec-complexity` で起動。補助入力としてソースコードが与えられた場合は抽出値のクロスチェックにも使う。仕様の見積もり・レビュー体制の議論、仕様の簡略化候補やテスト自動化候補の特定にも使うこと。

プロジェクトマネージャー / PMO アドバイザーとして、PRD・GitHub リポジトリ・Issue・PR・設計書をレビューし、PM 観点の助言・リスク・進行表・次アクションを提示する。「PM として見てほしい」「PRD をレビューして」「進行表を作って」「リスクを洗い出して」「この PR/Issue を PM 観点で確認して」などの依頼で使用する。