Use when an AI-generated document (plan / design doc / RFC / PR description) has grown long with the same concept explained in multiple places and needs consolidation to a single source of truth while preserving navigation aids like TOC, progress tables, and…
EnglishUse on confirmed working code whose name stops at mechanism (bboxxhtml) or shape (wordcoordinatedata / 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).
EnglishTurns 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 ( .qa-ledger.md), and generates the preflight contract ( .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 手順をプランに書いて".
EnglishUse 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.
EnglishUse after generating PR description, Jira ticket, design doc, RFC, or other reader-facing text from a local plan/spec file, to detect and rewrite vocabulary that exists only in the source and would confuse readers without it. Triggers when output of /create-pr, Jira create, design doc draft, or similar derives from a local plan.
EnglishPoC と案件プランファイルの申し送り節を受け取り、既存コードベースの慣習に合わせて DD (Design Doc) を起こせる水準のプロトタイプを実装するときに使用。「プロトタイプにして」「PoC を本実装の形に書き直して」「慣習に合わせて実装して」で起動。完了時にプランファイルへ /create-design-doc…
Japaneseプロトタイプと案件プランファイルの申し送り節から DD (Design Doc) を作成するときに使用。「DD を作って」「デザインドックを起こして」「設計書にして」で起動。テンプレートは ~/.claude/skills-config/create-design-doc/ddtemplate.md…
Japaneseユーザーストーリーマップやタスク分解プランからJiraチケットを一括作成する場合に使用。ストーリーマップ完成後のチケット化、プランファイルからの一括作成、計画済みストーリー・タスクのJiraへの移行が必要な場合にトリガーされる。…
JapaneseFigma デザインをコードへ反映・適用する実装の前後、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…
Japaneseプランファイルの受け入れ条件(AC)に対しMECE完全性検証を実施し、ユースケース漏れ・技術的対応漏れ・ACの改善点を検出して分析ファイルに記録する。プランにACが定義済みで実装前にMECE検証が必要な時に使用。事前に /define-acceptance-criteria…
Japaneseコミット前やPR作成前に、プロジェクト規約への準拠・パターン一貫性・実装/spec 整合性 (Ruby の delegate / def 撤去後に残る dead mock の検出と削除を含む)…
Japanese実装完了後のセルフチェック時、PRレビュー前の品質確認時に使用。RuboCop/ESLintでは検出できない設計レベルの問題と、domain model attribute (plancode / role / status 等) を更新する変更時の caller 業務副作用 (機能フラグ復活 / 認可 bypass 等の 2 段階副作用 chain)…
Japanese実装完了後に、確定プラン (finalize-plan 出力)、または DD 該当タスクを転記した簡易プランと実装後の diff を突き合わせ、実装漏れ・仕様逸脱・計画外差異を検出したいときに使用する。「プランと突き合わせて」「実装漏れがないか見て」「diffがプラン通りか確認して」等の依頼で起動する。実案件 dogfood (2026-07-06) で実装漏れ2件 (計画済みテストの未実装)…
JapaneseJiraキーとStory Pointsのマップデータを受け取り、Jiraチケットに一括でStory Pointsを設定する。「ストーリーポイント設定」「SP設定」「story…
Japaneseプロジェクト活動 (commits/PRs/README/ADR) を ~/.claude/skills-config/vision.md のビジョン要素と照合し、対話型 draft → revise loop で Zenn…
Japanese
AGENT SKILLS ATLASIncludes Dry Ssot Text, Express Intent in Code, Finalize Plan, and other workflows.
Claude Code
Codex
Cursor
GitHub Copilot
Gemini CLISupported by the Atlas install prompt. Skill-specific requirements vary.
Pack stats
What’s included
Dry Ssot Text
Use when an AI-generated document (plan / design doc / RFC / PR description) has grown long with the same concept explained in multiple places and needs consolidation to a single source of truth while preserving navigation aids like TOC, progress tables, and checklists
Express Intent in Code
Use on confirmed working code whose name stops at mechanism (bboxxhtml) or shape (wordcoordinatedata / 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).
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 ( .qa-ledger.md), and generates the preflight contract ( .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.
Purge Private Vocab
Use after generating PR description, Jira ticket, design doc, RFC, or other reader-facing text from a local plan/spec file, to detect and rewrite vocabulary that exists only in the source and would confuse readers without it. Triggers when output of /create-pr, Jira create, design doc draft, or similar derives from a local plan.
Build Prototype
PoC と案件プランファイルの申し送り節を受け取り、既存コードベースの慣習に合わせて DD (Design Doc) を起こせる水準のプロトタイプを実装するときに使用。「プロトタイプにして」「PoC を本実装の形に書き直して」「慣習に合わせて実装して」で起動。完了時にプランファイルへ /create-design-doc 向けの申し送り節を追記する。
Create Design Doc
プロトタイプと案件プランファイルの申し送り節から DD (Design Doc) を作成するときに使用。「DD を作って」「デザインドックを起こして」「設計書にして」で起動。テンプレートは ~/.claude/skills-config/create-design-doc/ddtemplate.md を参照し、未配置なら「テンプレートなしで作成」と宣言して進める。
Create Jira Issues
ユーザーストーリーマップやタスク分解プランからJiraチケットを一括作成する場合に使用。ストーリーマップ完成後のチケット化、プランファイルからの一括作成、計画済みストーリー・タスクのJiraへの移行が必要な場合にトリガーされる。
Define Acceptance Criteria
プランモード中にプランファイルの受け入れ条件・技術リスクを定義する時に使用。詳細は分析ファイル( .analysis.md)に書き出し、プランファイル末尾には品質検証サマリーのみ追記する。/mece-plan-reviewの前に実行し、MECEの検証ターゲットを定義する。
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 の正本カバレッジ・ゲートの入力になる。
Map User Stories
設計書・プロジェクト仕様・Jira epic等からユーザーストーリーマップを作成し、タスク分解・スプリント計画まで行う場合に使用。新しいプロジェクトフェーズの計画、設計書の分析、大きな機能の実装単位への分解が必要な場合にトリガーされる。
Mece Plan Review
プランファイルの受け入れ条件(AC)に対しMECE完全性検証を実施し、ユースケース漏れ・技術的対応漏れ・ACの改善点を検出して分析ファイルに記録する。プランにACが定義済みで実装前にMECE検証が必要な時に使用。事前に /define-acceptance-criteria でACを定義しておくこと。
Polish Before Commit
コミット前やPR作成前に、プロジェクト規約への準拠・パターン一貫性・実装/spec 整合性 (Ruby の delegate / def 撤去後に残る dead mock の検出と削除を含む) を確認・修正したい時に使用。
QA UI
実装完了後にChromeDevTools MCPでUI検証を行う。ACがあればAC項目ごとに画面操作・スクリーンショット・pass/fail判定。FAILなら自動修正→再QAを最大3回ループ。
Review Code Quality
実装完了後のセルフチェック時、PRレビュー前の品質確認時に使用。RuboCop/ESLintでは検出できない設計レベルの問題と、domain model attribute (plancode / role / status 等) を更新する変更時の caller 業務副作用 (機能フラグ復活 / 認可 bypass 等の 2 段階副作用 chain) を検出する。
Review Plan Diff
実装完了後に、確定プラン (finalize-plan 出力)、または DD 該当タスクを転記した簡易プランと実装後の diff を突き合わせ、実装漏れ・仕様逸脱・計画外差異を検出したいときに使用する。「プランと突き合わせて」「実装漏れがないか見て」「diffがプラン通りか確認して」等の依頼で起動する。実案件 dogfood (2026-07-06) で実装漏れ2件 (計画済みテストの未実装) をCriticalとして検出した検査を独立skill化したもの。
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 記事下書きを生成する。プロジェクト単位の物語化・キャリアブランディング・月次記事執筆時に使用。
Quick start
- Choose your skills. Select individual skills above, or choose the entire pack.
- Copy the install prompt. Use Copy install prompt above the list.
- Send it to your agent. Paste into your coding agent’s chat. Your agent reviews the source and guides the setup.
Try it with your agent
After installation, start with a request like:
Use the Dry Ssot Text skill to help with my task.
Ask me for the context you need before getting started.Requirements & license
- A coding agent that can access your project files and install skills.
- Your agent checks each skill’s instructions, dependencies, and permissions during setup.
- Reported license for the skills shown: MIT. The author’s terms apply.