YasuakiOmokawa
UserAgent skills for improve AI driven development
Categories
Indexed Skills (23)
extract-figma-spec
Figma デザインをコードへ反映・適用する実装の前後、figma-dev-mode MCP で design-to-code を行うとき、または「Figma 通りに実装して」「デザインを反映して」「Figma の指定どおりに直して」と頼まれたときに使用。スクショ目視と人間が挙げた「指定 N 点」だけで反映すると、hex の微差・font weight(Bold)・アイコンや枠の有無・要素まるごとの欠落 といった Figma 指定を取りこぼす——この反映漏れ (デザイン崩れ・Figma 不一致) を防ぐ。差分は通常 /define-acceptance-criteria で AC 化し /qa-ui で検証する（PoC 等の使い捨て検証では省略可）。チェックリスト全行は atom ID 付きで `## 正本抽出結果` として分析ファイルに書き出し、/finalize-plan の正本カバレッジ・ゲートの入力になる。
create-pr
Creates a Conventional-Commits PR (draft by default; ready for review when the user explicitly requests it) from the current branch with generated title, body, labels, and milestone, without confirmation. Use when the user says "PR を作って" / "draft PR" / "PR 作成して" / "ready for review で PR を作って", optionally with `[base-branch]` and per-section detail-expansion instructions (e.g. "設計判断は詳しく") as arguments.
qa-ui
実装完了後の UI を検証したいとき、または「UI を確認して」「QA して」「画面の動作確認」と頼まれたときに使用。既定は人間委譲 — QA-ID 台帳の manual 項目ごとに前提・操作手順・確認点をまとめた実行手順書を組み立てて人間に依頼し、返答（PASS / FAIL+内容 / 検証不能）を台帳に記帳する（ChromeDevTools MCP は使わずトークン浪費を避ける。台帳が無い場合の AC 直接読込みフォールバック・正本抽出結果直接読込みフォールバック（`/extract-figma-spec` が PoC 等でプラン末尾に書き出す反映チェックリストを検証項目として採用する）・AC 無しモードは現行どおり automation で検証する）。ブラウザ automation（独立コンテキストの ui-evaluator による画面操作）は「automation で実行して」「ブラウザで検証して」等の明示指示があるときだけのオプション。いずれのモードでも Major/Minor 不合格は最小修正し、該当 QA-ID だけ再確認を依頼するループを回す (原則最大3ラウンド、root cause が1行で確定する場合のみ+1、Critical と未カタログの検証不能は即エスカレート、真の制約による検証不能は記帳のうえ他項目を止めない)。台帳がある場合は修正ループを抜けた後に auto 判定の再実行ゲートを1回はさみ、台帳の機械集計で完了判定する。
review-plan-diff
実装完了後に、確定プラン (finalize-plan 出力)、または DD 該当タスクを転記した簡易プランと実装後の diff を突き合わせ、実装漏れ・仕様逸脱・計画外差異を検出したいときに使用する。「プランと突き合わせて」「実装漏れがないか見て」「diffがプラン通りか確認して」等の依頼で起動する。
ai-prototype-flow
Use when starting or advancing a feature under the AI プロトタイプ駆動開発フロー (PoC → 設計確定 → DD 作成 → 出荷実装), when the user says "/ai-prototype-flow フェーズN", "プロトタイプ駆動で始めたい", "フローの続きをやって", names a phase (フェーズ0 / 1 / 2 / 2.5 / 3), reports a re-entry event (PRD/Figma changed after freeze, unknown sub-problem surfaced mid-implementation, 正本取り違え), initializes a new 案件 from a PRD gdocs URL ("/ai-prototype-flow 案件初期化 <gdocs URL>", or any gdocs URL + freeze-snapshot request like "初期凍結スナップショット保存して"), asks where a 案件 currently stands ("いまどこ", "<案件名>っていまどのフェーズだっけ", "進捗どうなってる"), or continues without naming a phase ("続きやって" or no arguments).
express-intent-in-code
Use on confirmed working code whose name stops at mechanism (`bbox_xhtml`) or shape (`word_coordinate_data` / `useFieldSaveState`) and whose purpose survives only in why-comments, when /review-code-quality hands off a naming / cohesion finding as needs-judgment, or when the user says 「意図が伝わる名前にして」「コメントなしで読めるコードにして」. ALSO use while WRITING new code (経路2 生成時), the moment you are about to (a) write a comment, (b) leave a bare mechanism or constraint-workaround justification in a public method body, or (c) explain a boolean / null-vs-undefined meaning in a comment. Do NOT drive-by rename outside the target nor scan a whole diff (that is /review-code-quality); this is the deep one-point transformer / generation-time recipe. The only self-run whole-diff pass is a mechanical screening for homonym collisions (e.g. auth `token` vs placeholder `token`), 段0 noise-word identifiers, and comment-heavy new/ported files (comment lines > ~25% of non-blank lines).
set-jira-story-points
JiraキーとStory Pointsのマップデータを受け取り、Jiraチケットに一括でStory Pointsを設定する。「ストーリーポイント設定」「SP設定」「story points」などのキーワードでトリガーされる。
translate-to-vision-story
プロジェクト活動 (commits/PRs/README/ADR) を `~/.claude/skills-config/vision.md` のビジョン要素と照合し、対話型 draft → revise loop で Zenn 記事下書きを生成する。プロジェクト単位の物語化・キャリアブランディング・月次記事執筆時に使用。
create-jira-issues
ユーザーストーリーマップやタスク分解プランからJiraチケットを一括作成する場合に使用。ストーリーマップ完成後のチケット化、プランファイルからの一括作成、計画済みストーリー・タスクのJiraへの移行が必要な場合にトリガーされる。
define-acceptance-criteria
Fills a matrix of 3 required categories (normal, error, edge) by controlled-vocabulary perspectives to enumerate acceptance criteria and technical risks into the analysis file, then appends a one-line summary to the plan file. Use when in plan mode before /mece-plan-review, when the user asks to write AC for a plan ("受け入れ条件を定義して" / "AC を書いて"), when an AC matrix is needed as MECE input, or when delegated to a subagent (Task tool) for the same purpose. Not typically invoked during PoC / throwaway-validation phases (the assumption ledger substitutes there).
dry-ssot-text
Collapses repeated explanations of one concept into a single source of truth plus cross-references, while keeping navigation aids like TOCs and progress tables. Use when an AI-generated document (plan / design doc / RFC / PR description) has grown long with the same concept explained in multiple places, when the same why-explanation is repeated across multiple code comments, or when the user says "この文書の重複をまとめて" / "この文書を DRY にして" / "同じ説明が何回も出てくるので整理して". Also use when a change set spans multiple files (code comments + changed/new docs) with the same explanation duplicated across them. Prose duplication inside code comments is in scope; code structure duplication / refactoring is out of scope.
finalize-plan
Turns AC and MECE results from the analysis file into a branch strategy and manual/auto QA steps appended to the plan file, then gates QA-ID coverage against any structured source-of-truth atoms, initializes the QA execution ledger (`<plan>.qa-ledger.md`), and generates the preflight contract (`<plan>.preflight.md`) so QA input-waiting moves before the loop starts. Use when the user has completed `/define-acceptance-criteria` + `/mece-plan-review` and is about to move from plan mode into implementation, or says "実装準備を追記して" / "ブランチ戦略を決めて" / "QA 手順をプランに書いて".
iterate-with-prototypes
Use when starting a complex feature where a PRD or spec exists but load-bearing assumptions (technical feasibility, UX effect, reuse of an existing API or data structure) are still unverified, most implementation is done by an AI agent, the work spans several design docs and a PR chain (potentially across multiple sessions or delegated subagent runs that resume from the assumption ledger), AND the change is reversible with a small blast radius. Do NOT use when the core risk is a hard-to-reverse decision (DB schema / migration, public API contract, cross-team boundary) — use design-first there. Symptom — about to design a complex feature on paper before any of it is proven to run, or confident-but-wrong design propagating across documents.
map-user-stories
設計書・プロジェクト仕様・Jira epic等からユーザーストーリーマップを作成し、タスク分解・スプリント計画まで行う場合に使用。新しいプロジェクトフェーズの計画、設計書の分析、大きな機能の実装単位への分解が必要な場合にトリガーされる。対象の設計書は DD がレビュー確定した後を想定する。
mece-plan-review
Verifies acceptance criteria for MECE coverage with parallel spec/code/wiki analysts and a fresh red-team judge, recording coverage gaps and duplicates in the analysis file. Use when AC is already defined in the analysis file via /define-acceptance-criteria and MECE verification is required before implementation, or when the user says "AC の網羅性を検証して" / "MECE 検証して". Not typically invoked during PoC / throwaway-validation phases (the assumption ledger substitutes there).
purge-private-vocab
Detects local-plan coinages, abbreviations, and number labels in reader-facing text and rewrites them so readers without the source plan can follow. Use after generating PR description, Jira ticket, design doc, RFC, reviewed code comments (plan-coinage residue left after implementation), or other reader-facing text from a local plan/spec file, when readers don't share the source plan, when a plan document itself must be checked because upstream analysis-file finding IDs (BB-N / WB-N / IM-N) leaked into it, or when the user says "造語チェックして" / "plan 用語を消して" / "PR 説明の語彙を点検して".
review-code-quality
Use when finishing self-review of an implementation, before requesting PR review, when inspecting someone else's PR or a PR not checked out locally (PR review mode), when a diff updates a domain model attribute (`plan_code` / `role` / `status` 等), or when the user says "コード品質をレビューして" / "品質レビュー". Analyzes the diff across cohesion and coupling (plus business-impact for domain-attribute changes — Ruby/Rails diffs only, skipped when the diff has no .rb/.rake files) and hands off every 🔴/🟠 finding to /polish-before-commit as needs-judgment without editing files. Readability-level fixes (minor renames, simplification, efficiency) are covered by the built-in /code-review skill, not this plugin.
review-design
Reviews code placement and pattern choices before implementation using selected architecture reviewers (anti-pattern plus DDD, Hexagonal, Clean, Deep-Module) and a mandatory adversarial critique, editing the plan directly on fatal findings. Use when starting a new feature, adding a file or module, designing a module's interface (deep vs shallow / where a seam goes), deciding "where should this code live", or when the user requests a design review with `/review-design`. ALSO use when the change touches auth / billing / payment / migration / security territory — run even if placement seems obvious (this territory rule overrides the skip conditions).
polish-before-commit
Auto-fixes convention and pattern-consistency issues, runs lint, and aggregates remaining judgment calls before stopping for the user (or, when explicitly delegated in orchestrated mode, escalating to a ledger and returning instead of waiting). Ingests leftover findings from the built-in `/code-review` skill run by the user just before this skill (this skill never invokes `/code-review` itself — its disable-model-invocation setting rejects Skill-tool launches). Use when finalizing a branch, just before `git commit` or `/create-pr`, when reviewing someone else's PR without editing files (review-only mode), or whenever the user says "仕上げて" / "polish" / "コミット前チェック" / "レビューのみで見て".
build-poc
やりたいこと (brief / PRD / gdocs URL) を技術調査して星取表を作り、最小実装でセルを裏どりして PoC を完成させるときに使用。「PoC を作って」「実現できるか検証して」「技術調査して星取表を作って」「案件を初期化して <gdocs URL>」「PRD の凍結スナップショットを取って」で起動。完了時に案件プランファイルへ /build-prototype 向けの申し送り節を追記する。
model-data
要求文書からDBML形式のER図を生成し、SQLアンチパターンを検出。DB設計、ER図作成、スキーマ正規化、既存設計レビュー時に使用。
build-prototype
PoC と案件プランファイルの申し送り節を受け取り、既存コードベースの慣習に合わせて DD (Design Doc) を起こせる水準のプロトタイプを実装するときに使用。「プロトタイプにして」「PoC を本���装の形に書き直して」「慣習に合わせて実装して」で起動。完了時にプランファイルへ /create-design-doc 向けの申し送り節を追記する。
create-design-doc
プロトタイプと案件プランファイルの申し送り節から DD (Design Doc) を作成するときに使用。「DD を作って」「デザインドックを起こして」「設計書にして」で起動。テンプレートは ~/.claude/skills-config/create-design-doc/dd_template.md を参照し、未配置なら「テンプレートなしで作成」と宣言して進める。
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.