Skills

/implement

Jiraチケットを受け取り、plan モードで技術設計を詰めてから実装・PR作成まで行う。

About

Jiraチケットを受け取り、plan モードで技術設計を詰めてから実装・PR作成まで行う。

Category:Coding
Scope:universal

Usage

Use when user says "implement", "実装して", "これやって", "着手", "取りかかる", "implement this".

Requirements

MCP SERVERS

Atlassian

CLI TOOLS

gh

Install

Agent:
curl -sf /api/skills/implement/download | tar xz -C .claude/skills/

Download / Upload

ZIP でダウンロード

→ Claude.ai: Customize > Skills にアップロード

Source

Implement

Jira チケット（/carve で作成されたもの等）を受け取り、plan モードで技術的な詳細を詰めてから実装し、PR 作成まで行う。

入力

  • $ARGUMENTS: Jira チケットキー（例: LLAM-972）、または「next」で /next-action 相当の自動選択
  • 入力がない場合はユーザーに確認する

定数

  • cloudId: 実行時に getAccessibleAtlassianResources で取得する

手順

1. チケット情報の取得

getJiraIssue で以下を取得:

  • summary, description（設計方針 + AC）
  • issuelinks（依存チケット — blocks / is blocked by）
  • parent（エピック）
  • status, priority

依存チケットの確認:

  • is blocked by のチケットが未完了なら警告し、先にそちらを着手すべきか確認する
  • 依存チケットの PR がマージ済みかを gh pr list で確認する

仕様書リンクの取得:

  • description 内の Confluence リンクがあれば getConfluencePage で仕様書を取得
  • リンクがなければ description の設計方針 + AC をそのまま仕様とする

2. コードベース探索（自動）

チケットの description に基づき、Agent（Explore）で以下を並列調査する:

  • 変更対象の特定: description に記載されたファイル・ディレクトリの現状確認
  • 既存パターンの把握: 類似機能の実装パターン（description の「〇〇と同じパターン」等の参照先）
  • データモデル確認: Prisma schema で関連テーブルの構造確認
  • テスト戦略: 類似機能のテストがどう書かれているか

3. Plan モード（技術設計）

EnterPlanMode で plan モードに入り、以下を設計する:

Plan に含める内容:

  • ファイル変更一覧: 新規作成・変更するファイルのリスト（パス + 変更概要）
  • 実装順序: ファイル間の依存を考慮した実装順
  • 技術的な判断: チケットの設計方針を具体的なコードレベルの判断に落とし込む
    • どの既存ファイルをベースにするか
    • 型定義の追加箇所
    • バリデーションロジックの方針
    • エラーハンドリングの方針（日本語メッセージ）
  • テスト方針: 何をテストするか、モックの範囲

Plan に含めないもの:

  • 実装コード全文（それは実装フェーズで書く）
  • 過度な詳細（Plan はレビューしやすいサイズに）

ユーザーが Plan を承認したら実装フェーズへ進む。

4. 実装

承認された Plan に沿って実装する。

実装の原則:

  • CLAUDE.md のルールに従う（テストパターン、エラーハンドリング等）
  • 1 チケット = 1 PR を厳守
  • 既存パターンを踏襲する（車輪の再発明をしない）
  • コミットは論理単位で分ける（Conventional Commits）

5. 品質チェック

実装完了後、以下を順番に実行する:

pnpm run check:ts          # 型チェック
pnpm run lint:fix           # lint 修正
pnpm run prettier:fix       # フォーマット
pnpm run test               # テスト（対象パッケージ）

エラーがあれば修正し、すべてパスするまで繰り返す。

6. 自己レビュー & リファクタリング

品質チェックをパスしたら、PR 作成前に自分の変更を客観的にレビューする。

レビュー手順:

  1. git diff で変更差分を全体通しで確認する
  2. 以下の観点でチェック:
    • AC 充足: チケットの受け入れ条件をすべて満たしているか
    • 不要な変更: 目的外の変更が混入していないか（デバッグコード、余計なリファクタ）
    • 命名: 変数名・関数名が既存コードと一貫しているか
    • 重複: 既存ユーティリティで代替できる処理を再実装していないか
    • セキュリティ: OWASP Top 10（インジェクション、XSS 等）に該当しないか
    • エラーメッセージ: ユーザー向けメッセージが日本語になっているか
  3. 問題があれば修正し、ステップ 5 の品質チェックを再実行する

7. PR 作成

品質チェックをパスしたら:

  1. ブランチ名: feat/LLAM-XXX-短い説明 or fix/LLAM-XXX-短い説明（チケットタイプに応じて）
  2. コミットメッセージ: Conventional Commits 形式、Jira チケット番号を含める
  3. gh pr create で PR を作成:
    • タイトル: feat: 概要 (LLAM-XXX) 形式
    • body: Summary + Test plan + Jira チケットリンク
    • assignee: 自分

8. Jira ステータス更新（任意）

PR 作成後、ユーザーに確認してから:

  • チケットのステータスを「In Progress」→「Ready For QA」に遷移
  • PR リンクをチケットの Remote Issue Link に追加

注意事項

  • Plan モードで必ずユーザーの承認を得てから実装に入ること
  • 依存チケットが未完了の場合は worktree での並列作業を提案する
  • テナント差異（SDH / EAST）がある場合は description に記載されているはず — なければ確認する
  • E2E テストが必要な場合は /e2e スキルのパターンに従う
  • description の AC を満たしているか、実装完了時にセルフチェックする