YasuakiOmokawa
UserAgent skills for improve AI driven development
Categories
Indexed Skills (24)
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).
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への移行が必要な場合にトリガーされる。
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.
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" / "コミット前チェック" / "レビューのみで見て".
extract-figma-spec
Use before or during Figma-driven implementation to extract returned design properties into atomized checks, compare them with code, and write a canonical results table.
qa-ui
Use to verify implemented UI from finalized QA-ID instructions, or through browser fallback when no QA-ID source exists.
create-pr
Use to create or update a Conventional-Commits PR from the current branch; draft by default, ready only when explicitly requested.
dry-ssot-text
Use when reader-facing prose or code-comment explanations repeat across a document or change set; not for code structure or logic duplication.
map-user-stories
Use when a design, specification, Jira epic, page, or supplied text must become an implementation-ready user story map and delivery plan.
purge-private-vocab
Use when reader-facing text or plans contain plan-local coinages, abbreviations, layer labels, or finding IDs that may be opaque without their source plan.
review-design
Use before adding a feature, file, module, interface, or seam, or when deciding where code should live; always use for auth, billing, payment, migration, or security changes. Trigger on explicit design-review requests too.
express-intent-in-code
Use when a redundancy guard reports comments, suppressions, or sibling files; before adding a helper; or when reviewing abstraction names and cohesion after a substantial change.
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.
define-acceptance-criteria
Use when a plan needs acceptance criteria before MECE review; skip throwaway PoC validation.
finalize-plan
Use after a plan's acceptance criteria and MECE analysis are complete, immediately before implementation.
mece-plan-review
Use after acceptance criteria exist to check specification and code coverage, update the analysis, and update one plan quality-summary line before implementation. Trigger on "MECE 検証して" or "AC の網羅性を検証して".
apply-findings
Use after code review or before committing to apply mechanically safe findings and report judgment calls; use review-only when the user asks for no edits or for another PR to be inspected.
model-data
要求文書からDBML形式のER図を生成し、SQLアンチパターンを検出。DB設計、ER図作成、スキーマ正規化、既存設計レビュー時に使用。
build-poc
PoC、実現可能性の検証、技術比較、gdocs 案件の初期化または PRD 凍結を依頼されたときに使用。
create-design-doc
案件プランと取得可能なプロトタイプから DD (Design Doc) を作るときに使用。
build-prototype
PoC を既存コードベースの慣習に合わせたプロトタイプへ書き直すときに使用。
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.