| name | implement |
| description | 新機能の追加またはバグ修正を、既存パターンに従って完全に無停止で実装する |
このワークフローは開始から完了まで完全自動で実行する。各ブロック完了後、停止せず次へ進むこと。
引数:
/implement feature 日次株価の取得/implement fix #123 または /implement fix #123 ログインエラーの修正前提条件:
docs/ の永続ドキュメント（spec.md, architecture.md 等）に設計が記載済みであること。未記載の場合は先に /spec や /update-docs で設計を追加する。/investigate-bug で調査する。gateway issue create で起票し、steering.md に壁打ち内容を転写するagent-config/AGENTS.md と shared/rules/skill-trigger-policy.md の方針に従う。会話の中で以下のシグナルが出たら、ユーザーが /implement と明示しなくても本スキルを起動してよい：
「明らかにワンライナー修正」「typo」「5 分で終わる作業」は除外。
引数の先頭から作業タイプを判定する:
feature → 機能追加モードfix → バグ修正モードコンテキストを確立する:
/workspace/agent-config/worklog/active/[YYYYMMDD]-[slug]/
（ADR-0008 で .steering/ 旧運用は廃止。worklog 全部入れ方式）feature/[日付]-[作業名をkebab-case]fix/[日付]-[Issue番号]-[概要をkebab-case]ワークツリーを作成し、隔離された環境で作業する（配置ルールは worktree-policy.md 参照）:
cd /workspace/market-platform/apps/market-collector
git worktree add .worktrees/<カテゴリ>/<YYYYMMDD-Issue番号-slug> -b [ブランチ名] master
git worktree add .worktrees/fix/20260402-3-worktree-path -b fix/20260402-3-worktree-path master以降の全作業はワークツリーディレクトリ内で行う。
注意: ワークツリーには .venv/ がコピーされない。テスト・コマンド実行時はメインプロジェクトのvenvを絶対パスで参照する:
source /workspace/market-platform/apps/market-collector/.venv/bin/activate
入力情報の確認:
docs/ 配下の永続ドキュメントの改訂履歴を確認し、直近の変更範囲を把握する。gateway issue view [番号]）、調査結果・根本原因・再現手順を把握する。ラベルを in-progress に付替える:
gateway issue edit [番号] --remove-label investigating --add-label in-progress
Agent ツールで general-purpose サブエージェントを起動し、計画を委譲する（Planエージェントは Write/Edit 不可のため使用しない）:
/workspace/agent-config/templates/worklog/）に従って README.md（フロントマター必須）/ steering.md / tasklist.md / progress.md を生成する。decisions/ サブディレクトリも準備（ADR が必要なら作る）templates/requirements.md): 概要、背景、実装対象（受入条件付き）、スコープ外、参照ドキュメント。fix の場合は GitHub Issue の調査結果（根本原因、再現手順、期待動作）を反映するtemplates/design.md): アーキテクチャ概要、コンポーネント設計、データフロー、エラーハンドリング、テスト方針（動作確認の期待結果を含む）、ファイル構成、実装の順序templates/tasklist.md): requirements.md と design.md に基づき、各タスクを実装可能な粒度まで分解する。fix の場合は回帰テスト作成タスクを必ず含める。最後のフェーズに実環境での動作確認タスクを含める親エージェントはサブエージェント完了後、tasklist.md を読んでブロック3に進む。
tasklist.md に従って実装を進める。全タスクが [x] になるまで継続する。
tasklist.md を読み、次の未完了タスク（[ ]）を特定するEdit ツールで [ ] → [x] に更新する（まとめて更新しない。1タスク完了ごとに即更新）[x] になるまで繰り返すtasklist.md を読み、[ ] が残っていないことを確認する実装中にタスクが大きすぎると判明した場合、Edit ツールで元のタスクを削除し、より小さなサブタスク（[ ] 付き）をその場所に挿入してループを継続する。
スキップ時の記法: - [x] ~~タスク名~~ (理由: [具体的な技術的理由])
禁止事項: 「後でやる」「別タスクにする」等の理由でスキップすること。理由なく未完了タスクを放置してループを終了させること。
- [x] タスク名（実装方法を変更: 理由））論理的にまとまった単位（1タスクまたは関連するサブタスク群）ごとにコミットする。コミットメッセージは Conventional Commits 形式。
Bash ツールで直接実行する（サブエージェントは使わない）:
cd [ワークツリーパス]
source /workspace/market-platform/apps/market-collector/.venv/bin/activate
PYTHONPATH=src python -m pytest -m "not needs_secrets"
PYTHONPATH=src python -m ruff check .
PYTHONPATH=src python -m mypy .
エラーがあれば修正し、再度実行する。
3つのレビューサブエージェントを並列起動する。各エージェントが自分で情報収集からレビューまで一貫して実行する（親エージェントのコンテキスト汚染を防ぐため）。
1. スペック準拠: steering files（requirements.md/design.md）と実装の整合。設計にあるのに未実装、設計にないものが実装されていないか。
2. コード品質: 命名が意図を伝えているか。関数が単一責務か。重複コードがないか。早期リターンでネストが浅いか。エラーを握りつぶしていないか。
3. テスト品質: エッジケース（境界値、空入力、異常系）が網羅されているか。テストが意味のあるassertをしているか。fix の場合: バグを再現するテストケースが含まれているか。
4. セキュリティ: 機密情報がハードコードされていないか。エラーメッセージに機密情報が漏れていないか。入力検証が適切か。
5. パフォーマンス: データ構造の選択が適切か。不要な計算やN+1的なループがないか。メモリリークの可能性がないか。
6. ログ準拠: shared/rules/logging-policy.md の 8 原則に整合しているか。具体的には: (1) except Exception: pass / except: continue の例外黙殺がない (2) exc_info=True でスタックトレースを残している (3) 対象 identifier (mail_id / stock_code / url 等) をメッセージに含めている (4) 重要情報を DEBUG レベルだけに依存させていない (5) try-except のスコープが per-item の最小単位 (6) ログレベルが意味通り (障害可能性 → WARNING / 致命 → ERROR) (7) メッセージは半角英字基本 + 必要時のみ日本語 (8) 上位で握り潰される可能性がある場合に必ずログを残している。
[ワークツリーパス] から以下の4種の情報を収集する:
git diff master...HEAD の全文/workspace/agent-config/worklog/active/[YYYYMMDD]-[slug]/ の steering.md / tasklist.md / progress.md / decisions/*.md の全文docs/ 配下の永続ドキュメント（spec.md, architecture.md 等）のうち、変更ファイルに関連するものエージェント1 (Claude):
エージェント2 (Codex):
Skill('codex') を方式A（差分埋め込み）で実行せよ。収集した情報をプロンプトに埋め込み、6観点で評価させよ。エージェント3 (Gemini):
Skill('gemini') を方式A（差分埋め込み）で実行せよ。収集した情報をプロンプトに埋め込み、6観点で評価させよ。「subagent で並列起動」は誤った設計。正しくは Bash ツールを同一 assistant ターン内で複数発行する。
理由（Web リサーチ Web4 の発見）:
正しいパターン:
親エージェント (1ターン内で複数の Bash tool_use を発行)
├→ Bash: gateway external-llm --backend codex --task review --input <diff>
├→ Bash: gateway external-llm --backend gemini --task review --input <diff>
└→ 親エージェント自身が Claude として review（4LLM ではなく Claude を1つに兼ねる）
3つを 同じ assistant メッセージに含めることで Claude Code が真の並列実行する。Agent() ツール呼び出しは逐次なので使わない。
Codex / Gemini は OpenAI/Google それぞれの API レート制限・タイムアウトで失敗することがある。OpenAI の refresh_token_reused は同一プロセスの多重 refresh で発生するため、リトライではなく次のように扱う:
gateway runner 統合 + flock 排他制御で根治予定（ADR-0001 参照）親エージェントは3つのレビューサブエージェントの結果を受け取り、取捨選択・判断する:
tasklist.md に [ ] 形式で追加tasklist.md 末尾に「未解決」セクションで明記し、PR 本文に「未解決の指摘あり」と記載してブロック6へ進む。無限ループを避けるこのループ構造は cc-sdd v3 の /kiro-impl 思想（fresh implementer + 独立 reviewer + 2回 reject で auto-debug）を統合したもの（ADR-0001 / Web リサーチ Web1, Web4 参照）。
原則: ユニットテストの合格は動作確認の代替にならない。 ユニットテストはモックで個々のロジックを検証するが、動作確認は実環境でコンポーネント間の結合・通信・認証が実際に機能するかを確認する。両者は目的が異なる。
必ず実環境で動作確認を行い、期待する結果が得られることを確認する。本番環境（scheduler等）は使わない。
「テストができない」と判定して push に進むことを禁止する。「テストできない」は実装失敗と同等として扱う。具体的には：
SECRETS_DIR を読めずに skip されている → 実装失敗。push しないpytest の出力で S (skipped) があった場合、必ず理由を確認する。needs_secrets マーカー由来の skip は conftest.py の skipif フックで明示出力される（agent-config/docs/redesign/architecture.md 参照）。曖昧な「テスト不可」判定は許容しない。
過去事例: ~/.claude/projects/-workspace-infra/memory/feedback_skill_block_discipline.md に記録された Issue #9（secrets-manager 設計刷新）では、曖昧なスキップが本番デプロイ後にバグ検出された。再発を防ぐためこの原則を厳守する。
agent-config/docs/redesign/ 内の関連設計は agent-config/worklog/active/20260426-harness-redesign/architecture.md に移動済み。
このスキルは以下の順序で他スキルと連携する：
fix モード: /investigate-bug → /implement fix → 完了
feature モード: /spec（必要なら）→ /implement feature → 完了
レビュー: /review-docs（spec.md/architecture.md 変更があれば）
ブロック5 で内部的に呼ぶスキル：
external-llm（codex / gemini を Bash 並列発火、ADR-0001 P3 で完成予定）codex / gemini skill を直接 Bash で並列呼び出し各タスクが完了するごとに tasklist.md の末尾に Implementation Notes セクションを追記する。これは fresh context で動く次タスクの implementer に学びを引き継ぐためのもの。
形式：
## Implementation Notes
### タスク1: {タスク名} 完了時のメモ
- 採用したアプローチ: ...
- 失敗したアプローチ: ...
- 次タスクへの注意: ...
### タスク2: ...
これにより「context isolation（fresh implementer）」と「知識の累積（次タスクへの引継ぎ）」を両立する。Web リサーチ Web4 の知見。
動作確認に必要なコンテナ・サービスがデプロイされていない場合は、まずデプロイする。「未デプロイだから確認できない」は動作確認をスキップする理由にならない。
# 例: gateway コンテナのリビルド（公式 runner、build + self-restart 一発）
gateway rebuild
# 例: 起動確認
gateway health
注意: schedulerを停止してはならない。新規サービスの追加・既存サービスの再起動は docker compose up -d [サービス名] で個別に行う。
gateway 経由で test コンテナを起動する:
gateway collect <source> [--type <dtype>] [--force] [--date <date>]
test コンテナの特性（詳細は container-policy.md 参照）:
read_only: true だが /tmp と /home/node が tmpfs で書き込み可能DATA_BASE_PATH=/tmp/test-data, LOG_BASE_PATH=/tmp/test-logs により、アプリのデータ・ログ出力先が自動的に tmpfs に向く/workspace/apps は読み取り専用マウント — ワークツリーのコードはmasterにマージ済みの状態でテストする実装した機能の主要パスを実環境で実行する。
gateway collect [collector名] --type [dtype名]
変更が既存機能を壊していないかを確認する。変更した部分だけでなく、関連する既存機能が正常に動くことを必ず確認する。
影響範囲の特定: 以下の観点で、今回の変更が影響しうる既存機能を洗い出す:
find_referencing_symbols やGrepで特定）確認の実行: 特定した関連機能について、test コンテナで代表的なパスを実行する:
gateway collect [関連コレクター名] --type [dtype名]
確認観点:
/implement fix の実行中に、GitHub Issueに記載された根本原因が誤りだと判明した場合：
/investigate-bug #Issue番号 の再実行を提案するこのブロックは全ステップを番号順に実行する。スキップ禁止。
tasklist.md の末尾にある「振り返り」セクションに以下を記入する:
## 振り返り
### 実装完了日
YYYY-MM-DD
### 計画と実績の差分
- {計画と異なった点とその理由}
### 学んだこと
- {技術的な知見やプロセス改善点}
### 次回への改善提案
- {次回の改善点}
.steering/ 旧運用は ADR-0008 で廃止された。worklog 内の完了処理を以下の手順で行う：
worklog/active/{slug}/result.md を作成（テンプレ: templates/worklog/result.template.md）
README.md のフロントマターを更新: status: completed、completed_date: YYYY-MM-DDauto-doc-update skill を呼び出してマスタードキュメント反映 PR を生成worklog/archived/{slug}/ へ自動移動（audit-worklog.py / Stop hook で検出）旧運用の「ステアリングを Issue に1コメント統合投稿してから削除」は廃止された。worklog は archived/ で永続保持される。
3ファイルを 1コメントに <details> 折りたたみで統合 して投稿し、ステアリングディレクトリを削除する。分割投稿は禁止（通知が3回飛ぶ、スクロールが長くなる）。
重要: シェル変数展開（${VAR}）でマルチバイト文字が化けることがあるため、Python 経由で投稿する（github-workflow.md の「長文 body の文字化け防止」参照）。
python3 -c "
import subprocess
with open('.steering/[dir]/requirements.md') as f: req = f.read()
with open('.steering/[dir]/design.md') as f: design = f.read()
with open('.steering/[dir]/tasklist.md') as f: task = f.read()
body = f'''## Steering Files
<details><summary>Requirements</summary>
{req}
</details>
<details><summary>Design</summary>
{design}
</details>
<details><summary>Tasklist + Retrospective</summary>
{task}
</details>'''
subprocess.run(['gateway', 'issue', 'comment', '[Issue番号]', '--body', body])
"
rm -rf .steering/[YYYYMMDD]-[作業名]
このセクションの残りは旧運用の参照のみ。実行は不要。新運用（worklog/）で完結する。
# 旧運用の終わり
今回の変更がプロジェクトの基本設計やアーキテクチャに影響を与えるか判断する。影響がある場合、docs/ 内の関連する永続ドキュメントを Edit ツールで更新する。
docs/system-test-sheet.md は ADR-0004（20260429-allure-aggregation）で 観点基準書 に役割転換されている。今回の変更に関連する 観点 を追加し、Allure メタデータ（feature / story / severity / step）に対応付ける。
@allure.feature/story/severity を併記@allure.story("回帰: 〜") 等を付けるtemplates/tests/test-sheet.template.md試験結果の確認は集約サーバ（http://<NAS-IP>:5050/.../projects/<project_id>/reports/latest/index.html）。観点基準書はチェックリストとしてのみ機能し、結果サマリは記載しない（Allure と二重になるため）。
試験設計書（docs/system-test-design.md）は、カテゴリの追加・説明範囲の変更・テスト対象の増減がある場合のみ更新する。
GitHub Issue に修正完了レポートをコメントし、確認待ちラベルを付与する（クローズはユーザー確認後）。
Issue操作時は .claude/rules/github-workflow.md のラベルルールに従うこと。 レポートの記述スタイルは .claude/rules/doc-conventions.md の「Issue・レポートの記述ルール」に従う。
レポートの構成は .github/COMMENT_TEMPLATE/fix_report.md のテンプレートに従い、全項目を漏れなく記入する。
レポートは後から読む人が修正内容と確認結果を把握できる文書として書く。
説明文のスタイル:
orchestrator.py:201のas_completed(futures)にtimeout=3600を追加」→ OK「並列処理の完了待ちに1時間のタイムアウトを設定し、処理がハングした場合に強制打ち切りする仕組みを追加した」概要図（必須）: テンプレートの「変更概要図」セクションにMermaid記法の図を必ず含める。ノードには役割名を使い、クラス名は使わない。修正の全体像がコードを読まなくても伝わることが目的
各セクションの記述ガイド:
gateway issue comment [番号] --body '[fix_report.mdテンプレートに従ったレポート]'
gateway issue edit [番号] --remove-label in-progress --add-label needs-verification
cd /workspace/market-platform/apps/market-collector
git switch master && git merge [ブランチ名]
git worktree remove .worktrees/<カテゴリ>/<YYYYMMDD-Issue番号-slug>
gateway git push
コードをmasterにpushした後、変更が常駐サービス（scheduler等）に影響する場合、本番環境への反映を行う。Pythonの長時間実行プロセスはモジュールを起動時にメモリへロードし、ディスク上のファイル更新を自動反映しない。再起動しない限りコード変更は適用されない。
PR を merge した直後、dev-admin の local master は origin/master から遅れている可能性がある。bind mount 対象リポは dev-admin の作業コピーがそのまま本番（scheduler 等）に bind mount される構造のため、scheduler 再起動の前に master を同期させる 必要がある。
通常は posttooluse-pr-merge-cleanup.py hook が PR merge 検出時に repos.txt 記載の bind mount 対象リポを自動同期するため、本ステップが手動で必要なのは hook 失敗時（gateway 障害等）に限る。
cd /workspace/<repo> && git pull --ff-only
# 例: cd /workspace/market-platform && git pull --ff-only
uncommitted な変更があり ff-only が失敗する場合は、内容を確認して commit / stash / 破棄を判断してから再試行する。
見落とし時の影響: master 同期せずに 8-3 で scheduler を再起動すると、bind mount 経由で 古いコード が再ロードされる。Issue #46 / finding 20260428-231201 で実害（mp#147 修正の本番反映が約 10 時間遅延）が記録されている。
変更がschedulerプロセスで実行されるコード（src/ 配下、config/ 配下）に影響するかを判定する。
src/market_collector/ のモジュール、config/*.yaml の設定値 → 8-3へscripts/、tests/、docs/、.claude/ のみの変更 → スキップgateway docker compose up -d scheduler
再起動後、直近の収集サイクルのログで変更が反映されていることを確認する。
gateway docker compose logs scheduler --tail 50
確認観点:
"Excluded" ログ）| ブロック | 完了条件 |
|---|---|
| 3 | tasklist.md の全タスクが [x]（または技術的理由でスキップ） |
| 4 | pytest / ruff / mypy が全てエラーなし |
| 5 | 外部レビューで全観点「問題なし」 |
| 6 | 実環境での動作確認が成功 |
| 7 | 7-1〜7-7 の全ステップ完了。振り返り記録済み。ステアリングファイル Issue 投稿+削除済み。試験シート更新済み（feature は必須、fix は既存項目で完全カバーされる場合のみ省略可）。fix の場合は修正完了レポートを Issue にコメント + needs-verification ラベル付与済み |
| 8 | dev-admin master を origin に同期済み（hook が自動実行、手動では git pull --ff-only）。常駐サービスへの影響がある場合: scheduler 再起動済み + 本番ログで変更反映を確認済み。影響なしの場合: スキップ |
全条件を満たすまで自律的に作業を継続すること。
[HINT] Download the complete skill directory including SKILL.md and all related files