task

タスク — 体系的な実装ワークフロー

Codex との互換性

Codex でこのスキルを実行する場合は、操作を開始する前に Claude Code 専用のプリミティブを置き換えてください。AskUserQuestion -> chat/request_user_input、TodoWrite -> update_plan、Task/TaskCreate/TeamCreate/SendMessage -> 利用可能かつ許可されている場合は spawn_agent/send_input/wait_agent、EnterPlanMode/ExitPlanMode -> 簡潔なチャットでの計画と明示的な承認。 Read/Write/Edit/Bash/WebSearch/WebFetch は Codex のファイル／シェル／ウェブツールに対応付けてください。また、タスクで Claude Code が明示的に指定されている場合を除き、~/.claude/... のパスは ~/.agents/... または ~/.codex/... に対応付けてください。

Cursor との互換性

Cursor Agent でこのスキルを実行する場合は、操作を開始する前に Claude Code 専用のプリミティブを置き換えてください。AskUserQuestion -> AskQuestion、TodoWrite -> Cursor の TodoWrite または同等のチェックリスト、Task/TaskCreate/TeamCreate/SendMessage/マルチエージェントフロー -> 許可されている場合は Cursor の Task（サブエージェント）、並列 Task、または run_in_background（TeamCreate/SendMessage に完全に一致するものがない場合があります）、EnterPlanMode/ExitPlanMode -> Plan モード（SwitchMode / CreatePlan）と明示的なユーザー承認。 Read/Write/Edit/StrReplace/Bash/ウェブ／検索／MCP は Cursor Composer または Agent に相当するものに対応付けてください。mcp__server__tool 形式の MCP 名は通常、設定済みのサーバー識別子を使う call_mcp_tool に対応します。タスクで Claude Code が明示的に指定されている場合を除き、~/.claude/... は ~/.cursor/skills/、.cursor/skills/、.cursor/rules/ に対応付けてください。

品質ゲートを組み込んだ、すべての実装タスクに対応する標準的な5フェーズのワークフローです。

<essential_principles>

Serena の思考チェックポイント（必須）

指定された時点で、以下の Serena ツールを必ず呼び出してください。省略してはいけません。

チェックポイント	ツール	タイミング	目的
遵守ゲート	mcp__serena__think_about_task_adherence	フェーズ3で各コード編集の前	元のタスクに引き続き沿っているか確認する
完了ゲート	mcp__serena__think_about_whether_you_are_done	フェーズ4（検証）を終える前	作業が本当にすべて完了しているか確認する

フェーズ1の後とフェーズ2の後に、文章で簡潔な情報充足度のセルフチェックを行ってください（要件を理解していること、関連するコードを特定していること、計画が受け入れ基準と検証方法を網羅していること）。不足が残る場合は、先に進まず追加のコンテキストを集めてください。削除された Serena ツールに頼ってはいけません。

内省マーカー（常に有効）

すべてのフェーズを通じて、以下のマーカーを使い、推論を明確にしてください。

• 🤔 推論 — 「🤔 エラーから、依存関係の不足が考えられます」
• 🎯 判断 — 「🎯 アプローチBではなくAを選びます。理由は……」
• ⚡ パフォーマンス — 「⚡ このクエリではN+1が発生する可能性があります」
• 📊 品質 — 「📊 既存のパターンとの一貫性を確認します」
• 💡 洞察 — 「💡 このパターンは再利用できます」

安全ルール

• 破壊的な操作の前（削除、上書き、リセット）：必ずユーザーに確認してください
• コード編集の前：think_about_task_adherence を呼び出してください
• 自動でコミットしないこと：フェーズ5では、コミット／プッシュの指示をユーザーに求めてください
• 品質ゲートは必須：フェーズ5に進む前に、フェーズ4を通過する必要があります

</essential_principles>

フェーズ1：調査

タスクを理解し、コンテキストを集めます。

1. ユーザーの入力からタスク要件を把握します
2. 関連するコードファイルを読みます（Grep、Read、Serena のシンボリックツール）
3. 必要に応じて Context7 で外部ライブラリを確認します
4. 既存のパターンと規約を特定します
5. 情報充足度のセルフチェック — タスクを理解し、関連するコードパスを確認し、計画を立てるのに十分なプロジェクトの規約を把握していることを確認します。不十分な場合は、読み進めるか、フェーズ2の前にユーザーに質問してください。

ツール：Grep、Read、Glob、mcp__serena__find_symbol、mcp__serena__get_symbols_overview、mcp__context7__query-docs

フェーズ 2：計画

タスクを分解し、アプローチを設計します。

1. TodoWrite を使ってタスクを分解します
2. 並列化できるステップを特定します：Plan: 1) Parallel [Read A, B] → 2) Edit → 3) Parallel [Test, Lint]
3. 計画を Serena Memory に保存します：mcp__serena__write_memory("plan_<topic>", content)
4. 計画の完全性を自己チェック — 計画と Todo が受け入れ基準、エッジケース、変更の検証方法を網羅していることを確認します。重要な項目が不足している場合は、計画を修正します。

出力：各ステップの明確な受け入れ基準を記載した TodoWrite エントリ。

フェーズ 3：実装

継続的に遵守状況を確認しながら、計画を実行します。

各実装ステップで：

1. TodoWrite の項目を進行中にします
2. 🔶 think_about_task_adherence — 順調に進んでいますか？
3. コードを編集します（Edit、Write）
4. 内省マーカー（🤔🎯⚡📊💡）を使って、推論を説明します
5. TodoWrite の項目を完了にします

ルール：

• // TODO: implement later は使用せず、動作するコードを書きます
• テスト以外でモックオブジェクトを使用しません
• 既存のコードパターンと規約に従います
• 破壊的な操作の前にユーザーの確認を取ります

フェーズ 4：検証

品質チェックを実行し、正しさを検証します。

標準検証（常に実施）

可能な場合は並列で実行します：

# Parallel execution
pnpm lint &
pnpm typecheck &
pnpm test &
pnpm build &
wait

チェックに失敗した場合 → 根本原因を調査 → フェーズ 3 で修正 → 再検証します。

--frontend-verify（フラグが指定された場合）

プラットフォーム間で視覚的に検証します。package.json からプラットフォームを自動検出します：

依存関係	プラットフォーム	事前準備	検証ツール
(default)	Web	kill-port <port> && pnpm dev	playwright-cli（open --headed、snapshot、screenshot）
electron	Electron	pnpm electron:dev	/qa-electron スキル（Electron CDP に接続した playwright-cli）
expo / react-native	モバイル	mcp__ios-simulator__open_simulator	iOS Simulator MCP（screenshot、ui_tap、ui_swipe）
commander / inquirer / oclif	CLI	シェルセッション	Shellwright MCP（TUI/CLI の操作と出力の検証）

フロントエンド検証ワークフロー：

0. 事前知識：ドラッグ＆ドロップの座標プロトコルを読み込むため、/dnd を呼び出します。ref ベースの drag は dnd-kit などのライブラリで成功したように見えて実際には失敗するため、Web または Electron を操作する前に必ず実施します。
1. 事前準備：kill-port <port> && pnpm dev を実行し、playwright-cli が利用可能であることを確認します（Web は直接、Electron は playwright-cli attach --cdp=http://localhost:9222 を使用）
2. シナリオ作成：変更内容に基づいてテストシナリオを設計し、Serena Memory に保存します
3. 実行：playwright-cli で各シナリオを実行し、各ステップの後にスクリーンショットを撮影します
4. 判定：すべて成功 → 続行します。失敗があれば → フェーズ 3 に戻ります

フロントエンド検証の認証

認証が必要なアプリ（SaaS ダッシュボード、管理パネル、OAuth で保護されたページ）を検証する場合は、playwright-cli の認証状態の永続化を使用します：

方法	コマンド	用途
state-save / state-load	playwright-cli state-save auth.json	セッション Cookie と localStorage。ほとんどの Web アプリに最適です
--profile <dir>	playwright-cli open <url> --profile ./browser-data	Chromium のユーザーデータディレクトリ全体。複雑な OAuth（Google、GitHub SSO）に最適です

OAuth フロー：

1. playwright-cli open <login-url> --headed（OAuth のリダイレクトには headed モードが必須です）
2. OAuth を手動で完了するか、snapshot + fill + click を使って完了します
3. playwright-cli state-save auth.json を実行してセッションを保存します
4. 次回以降の実行では、アプリに移動する前に playwright-cli state-load auth.json を実行します

セキュリティ：

• .gitignore に auth.json と browser-data/ を追加します
• 状態ファイルにはセッションシークレットが含まれています。認証情報として扱ってください
• OAuth の初回設定では --headed を使用します（リダイレクトには表示されているブラウザーが必要です）

完了判定

🔶 think_about_whether_you_are_done — すべて本当に完了していますか？

フェーズ 5：完了

結果を報告し、ユーザーの指示を待ちます。

1. 検証の概要をユーザーに提示します。
   • 変更内容（ファイル、関数）
   • テスト結果
   • スクリーンショット（--frontend-verify の場合）
2. TodoWrite を更新し、すべての項目を完了済みにします。
3. ⏸️ コミット／プッシュの指示をユーザーに確認します。
4. ユーザーの確認後：git commit && git push

クイックリファレンス

/task fix the login button styling
/task add dark mode support --frontend-verify
/task refactor the API error handling

フェーズフロー図

[Investigate] → 🔶 info gate
     ↓
  [Plan] → 🔶 info gate
     ↓
[Implement] → 🔶 adherence gate (per edit)
     ↓
 [Verify] → 🔶 completion gate
     ↓
[Complete] → ⏸️ wait for user → commit/push