第11話 スキル物語 「dev-cycle」と言うと開発のサイクルが一巡する話

いつ困る？

品質の懸念が溜まってきた時、「どこかでまとめて直したい」と思う。テスト書き・Lint・型チェック・依存更新・Issue整理・PR運用——ひとつずつ手を出そうとすると、どれから手を付けていいか分からず、結局放置する。個人プロジェクトほど「いつかやる」が積み上がり、形骸化していく。

こう言うと起こること

「dev-cycle」「開発サイクル」「品質改善」「自律ループ」を CC に投げる。裏側の dev-cycle スキルは5フェーズを一巡する: 品質スイープ → コードレビュー → Issue化 → 自律実装ループ → 完了通知。各フェーズは明確な受け入れ条件を持ち、前のフェーズの成果が次への入力になる。例: 品質スイープで Found issues が拾われ、コードレビューで設計判断がレビューされ、Issue化されたものが自律ループに渡され、テスト緑まで実行されて人間に届く。人間は「結果の妥当性チェック」と「承認」のみ。

flowchart TB
    A["🔄 品質点検"] --> B["コードレビュー"]
    B --> C["課題リスト化"]
    C --> D["自動で直す"]
    D --> E["完了報告"]
    E -->|"次の課題へ"| A

何が変わるか

「いつかやりたい品質改善」が予約不要で着手できる。1日1サイクルでPJを回すと、放置PJの鮮度が保たれる。セルフレビューを待たずに人に見せられる品質に保たれる——面談・相談・コラボのスピードが落ちない。「今月の改善テーマ」をAIに任せて、自分の手は判断と承認に集中できる。

<details><summary>▶ 技術的にどうなってるか</summary>

仕組み

• 5フェーズがツール呼び出しで実行: 品質スイープ（Lint/静的解析）→ コードレビュー（multi-llm-review 連動）→ Issue化（GitHub Issues 起票）→ 自律実装ループ（run-task.sh）→ 完了通知（Discord）
• 各フェーズは受け入れ条件（A/D/F層）あり・次フェーズにバトンを渡す前に検証
• 自律ループ側は approve.py + run-task.sh で「テスト必須・3件まで自動停止・失敗で停止」のフェイルセーフ
• 途中で人間が判断を挟むポイント（確認ゲート）が明示されている

注意点

• サイクル1周 = 数時間〜1日が目安（小規模PJなら短く、大規模なら分割して1日1フェーズずつ）
• 自律ループは最大3タスクで自動停止するため、長時間放置のリスク無し
• 完了報告にはテスト緑証跡とコミットハッシュが必須（テストだけ緑で確認無しは完了扱いせず）

由来情報

• 設計正典: SSOTの~/.claude/skills/dev-cycle/SKILL.md
• 関連スキル: code-reviewer（レビュー専門）, code-simplify（簡素化専門）, multi-llm-review（多機レビュー）, repo-review（品質全体の入口）

</details>