Help us improve
Share bugs, ideas, or general feedback.
npx claudepluginhub chronista-club/claude-plugin-chronista-style --plugin chronista-styleHow this skill is triggered — by the user, by Claude, or both
Slash command
/chronista-style:codeflowThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Code Flow**は、ヒアリングファーストで要件を明確化し、仕様・設計を体系的に記録する開発ワークフローです。
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
Code Flowは、ヒアリングファーストで要件を明確化し、仕様・設計を体系的に記録する開発ワークフローです。
Code Flowのすべてのコミュニケーションの土台となる姿勢です。
「開発は真剣勝負、でも楽しむことを忘れない」
NGなユーモア
OKなユーモア
Code Flow は ステップ名で管理 します(番号は使いません)。依存関係は矢印のみで表現します。
Discovery → Second Opinion(任意)→ Discussion → Hearing → SDG(+ Bite-Sized Tasks)→ Branch & PR → Implementation → Release(条件付き)→ Learning
実装前の情報収集・調査ステップ。
別のAI(Gemini等)に第二意見を求めることで、視野を広げ見落としを防ぐ。
活用タイミング
確認ポイント
使い方
Gemini MCP経由で質問:
「この設計について、問題点や代替案があれば教えてください」
「この技術選定で見落としているリスクはありますか?」
どんなに「シンプル」に見えても、Discovery → Discussion を経ずに実装に入るな。 「シンプル」なプロジェクトこそ、未検証の仮定が最も多くの手戻りを生む。 設計は短くてもいい(数行でも可)。だが、提示して承認を得ろ。
調査結果とセカンドオピニオンを元にユーザーと方向性を議論。ここが一番楽しいステップ!
ディスカッションのコツ
方針決定後、詳細を詰めるための質問ステップ。質問をTodo管理して、優先順位をつけながら進める。
ヒアリングフロー
Step 1: 質問リスト作成 → Step 2: 全体確認 → Step 3: 優先順位付け → Step 4: 一問一答
Step 1: 質問リスト作成
create_todoで各質問を登録(priority: high/medium/low)hearing:<date>:<title>
["hearing:2024-12-15:認証機能の詳細設計"]Step 2: 全体確認
list_todosで質問一覧をユーザーに共有Step 3: 優先順位付け
Step 4: 一問一答
complete_todoでマークcreate_todoで追加ヒアリングのコツ
収集した情報を元に、仕様書(SPEC)と設計書(DESIGN)を生成し、実装タスクを bite-sized に分割する。
各タスクは 2-5分で完了する単位 に分割:
Step 1: 失敗するテストを書く
Step 2: テストの失敗を確認する
Step 3: 最小限の実装コードを書く
Step 4: テストの通過を確認する
Step 5: コミット
タスクには以下を明記:
タスクは creo-memories の memory として登録し、進捗を memory layer で一元管理する(2026-04-23 pivot: Linear → creo-memories)。memory = Issue / Todo / Decision / Milestone の unified layer。
Step 1: remember でタスクを memory 化(atlasId 指定)
Step 2: lifecycle は category、priority / size / cycle は tags で表現
Step 3: 親子・依存は derivedFrom / references / concept で接続
Step 4: ブランチ名は memory の slug から推論
priority:high / size:M / cycle:2026-W17supersedes 省略で dry-run → supersedeCandidates を確認 → 確定patch_memory(atomic in-place / CAS)/ append_memory(末尾追記)/ annotate(comment)。update_memory は fork するため lifecycle 更新に使わない別 project への修正依頼は issue 化せず、handoff memory 1 個で渡す(Cross-Project Handoff Protocol 準拠)。
requester: handoff memory を receiver の Atlas に作成(self-contained context、category: todo)
receiver: patch_memory で claim(CAS 排他)→ in-progress → 結果を append_memory → in-review
requester: 検証 → done(再発時は reborn)
1 handoff = 1 living memory。request / 作業 / 結果 / 検証が同じ memory に積層する。
main に直コミットしない。 必ずブランチで PR フローを踏む。
Step 1: memory の slug からブランチ名を推論(mako/{slug} or mako/{short-id}-{slug})
Step 2: ブランチ作成 → 実装 → コミット
Step 3: PR 作成(gh pr create)— PR body に対応 memory ID を参照
Step 4: レビュー(team-b Moody Blues 等)
Step 5: SHIP IT → マージ
ブランチ運用ルール:
main / master への直プッシュ禁止mako/{slug} 形式)チェックリストを生成し、tdd スキルに従って実装をガイドします。
必須: 実装時は tdd スキルの RED-GREEN-REFACTOR サイクルに従え。
テストファーストで書き、失敗を確認し、最小限のコードで通せ。
memory category 連動:
in-progress にin-review、マージ完了 → doneトリガー条件: 以下のいずれかに該当する場合のみ実行する。該当しなければスキップ。
Step 1: PR マージ → タグ → GitHub Release
Step 2: デプロイ(該当時)
Step 3: プラグイン同期(該当時) → /update-plugin
Step 4: memory の進捗を更新(Initiative / Milestone memory の category)
team-b 連携: Aerosmith がパイプラインをディスパッチする場合、Sticky Fingers(シップ)→ Gold Experience(デプロイ)→ /update-plugin(プラグイン配布)の順で実行。
セッションの知見を記録し、将来の開発に活用。
Code FlowはSDG(Spec-Design-Guide)原則に基づいています:
ヒアリングファースト
セカンドオピニオン活用
SDG準拠
チェックリスト活用
継続的学習
ドキュメント優先
project/
├── spec/ # 仕様書(What & Why)
│ ├── 01-*.md # 優先順位順
│ └── ...
├── design/ # 設計書(How)
│ ├── 01-*.md # 重要度順
│ └── ...
└── guide/ # 実装ガイド
├── 01-*.md # 利用順序
└── ...