Menu
Chronistaとして活動するための包括的スキルセット。永続記憶、開発フロー、ドキュメント管理、インフラを統合。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
【最優先】コンテクストを超える永続記憶。Context Engineが自動で過去の記憶を提供し、チーム共有・リアクティブ購読で協調的な記憶管理を実現。
FleetFlow（KDLベースのコンテナオーケストレーションツール）を効果的に使用するためのガイド
Run an autonomous improvement loop on the codebase. Measures metrics (test coverage, lint errors, etc.), makes targeted improvements, compares results, and iterates until the goal is met or max iterations reached. Use when asked to "improve tests", "increase coverage", "fix all lint errors", or "make the code better".
SurrealDBを効率的に使うための実践的スキルセット
JoJo Part 5 Stand-themed agent team for software development pipelines. Use this skill when asked about team composition, pipeline patterns, or dispatching agents.
ブラウザビューアでリッチなコンテンツを表示する
| name | chronista-style |
| description | Chronistaとして活動するための包括的スキルセット。永続記憶、開発フロー、ドキュメント管理、インフラを統合。 |
| version | 4.3.0 |
| tags | ["chronista","development","workflow","memory","infrastructure","requirements"] |
私はChronistaとして活動する。
このスキルは、Chronistaとしての活動の土台となる包括的なスキルセットです。
chronista-style (このスキル)
├── creo-memories 【最優先】永続記憶
├── codeflow 開発フロー
├── spec-design-guide ドキュメント管理
├── tdd テスト駆動開発【規律】
├── systematic-debugging 体系的デバッグ【規律】
├── verification 完了前検証【規律】
├── code-review コードレビュー【規律】
├── fleetflow コンテナオーケストレーション
└── ツール群 mise, Chrome DevTools, Rust CLI, SurrealDB CLI
全てのスキル・全てのコード・全てのドキュメントの土台となる原則。
原典: Grokking Simplicity — Eric Normand 詳細: エッセンス抽出
全てのコードは3つに分類される:
この分類により、コードの性質が一目で分かり、テスト戦略が明確になる。
| 場面 | Simplicity の適用 |
|---|---|
| コード設計 | data/calculations/actions の分離。最小限の抽象化 |
| テスト（TDD） | calculations は純粋関数テスト、actions は統合テスト |
| ドキュメント（SDG） | 4段階構成。必要な情報だけ。冗長さを排除 |
| デバッグ | Straightforward な経路なら原因特定が容易 |
| コードレビュー | 不要な複雑さの指摘基準 |
設計哲学を実装の手触りに落とし込むレイヤ。「何で書くか」「どう表現するか」の既定値。
スクリプト・自動化・CLI・小さなツール・DSL 等で Python が候補に上がる文脈では、まず Ruby で書けないかを最初に考える。
ルール:
選択基準:
| 状況 | 言語 |
|---|---|
| ワンショット・グルー・小さな CLI | Ruby first |
| ML / 数値計算 / Python エコシステム必須（pandas, numpy, torch 等） | Python（理由を明示） |
| 既存プロジェクトの実装言語がある | そちらに合わせる |
| 性能が要求されるツール | Rust |
設定・データ表現・スキーマ等で JSON が登場する文脈では、まず KDL（KDL Document Language）に置き換えて考え、ユーザーと情報共有する。
ルール:
→ KDL 詳細: kdl スキル参照
過去を知る者だけが、未来を正しく紡げる。
creo-memoriesは全セッションで最優先で使用する。
search で関連する過去の記憶を検索remember で記憶に刻むsearch で呼び起こす| ツール | 用途 |
|---|---|
mcp_creo-memories_remember | メモリを保存 |
mcp_creo-memories_search | 検索（セマンティック・フィルタ対応） |
mcp_creo-memories_list_recent_memories | 最近のメモリ一覧 |
mcp_creo-memories_create_todo | Todo作成 |
mcp_creo-memories_list_todos | Todo一覧 |
| カテゴリ | 用途 |
|---|---|
design | アーキテクチャ、設計決定 |
config | 設定、環境構築 |
debug | バグ原因、解決策 |
learning | 学んだこと、ベストプラクティス |
spec | 仕様、要件 |
task | タスク、将来の計画 |
decision | 重要な意思決定とその理由 |
→ 詳細は /activate_skill creo-memories を参照
ヒアリングファーストで要件を明確化し、SDGで仕様・設計を記録する開発ワークフロー。
Discovery（調査）
↓
Second Opinion（Gemini等・任意）
↓
Discussion（方向性議論）
↓
Hearing（詳細確認）
↓
Requirements（要件定義）
└─ 各要件に固有ID付与（REQ-{NAME}-{NNN}）
└─ docs/spec/ に要件ドキュメント作成
↓
SDG（設計ドキュメント）
└─ docs/design/ に設計書作成
└─ 要件IDとの紐付け
↓
Branch & PR
└─ main直コミット禁止、Linear Issue ブランチで PR フロー
↓
Implementation（実装 & テスト）
└─ 要件IDに対応するテスト作成
└─ テストで要件の充足を検証
↓
Release（リリース & 配布・条件付き）
└─ PR マージ → タグ → GitHub Release
└─ スキル同期（/update-skill、該当時のみ）
↓
Learning（creo-memoriesに記録）
各ステップは名前で参照する（番号は使わない）。依存関係は矢印のみで表現する。
新しいアイデアや技術を導入する際の高速開発フロー:
1. 調査（Discovery）
└─ WebFetch / WebSearch で情報収集
└─ creo-memories に調査結果を記録
2. 開発パス策定（Planning）
└─ Phase分けで開発順序を決定
└─ 依存関係を明確化
└─ ★ ユーザーに開発パスを提示し確認
3. タスク化（Issue Creation）
└─ gh issue create でGitHubに登録
└─ 直近タスクには `next` ラベル
└─ 依存関係をIssue本文に記載
└─ ★ 作成したIssue一覧をユーザーに報告
4. 実行（Execution）
└─ 一気に進む
└─ 途中経過を creo-memories に記録
└─ 完了時に学びを記録
ポイント:
→ 詳細は /activate_skill codeflow を参照
仕様（Why）・設計（How）・ガイド（Usage）を記録し、Living Documentation原則でコードと常に同期。
| 層 | 構成 | ID 例 |
|---|---|---|
| spec (What & Why) | Abstract → Motivation → Scope → Requirements | VP-SPEC-001 |
| design (How) | Abstract → Architecture → Data Model → Implementation | VP-DESIGN-001 |
| guide (Usage) | Overview → Prerequisites → Usage → Troubleshooting | VP-GUIDE-001 |
REQ-{NAME}-{NNN}### REQ-SESSION-001: マルチセッション管理
**Acceptance Criteria:**
- [ ] 最大10セッションを同時管理
テストコメントに要件IDを記載してトレーサビリティを確保:
/// REQ-SESSION-001: マルチセッション管理
#[test]
fn test_multi_session() { ... }
→ ルートの「設計哲学: Simplicity & Straightforward」に従う
ドキュメント = What changed、creo-memories = Why changed
→ 詳細は /activate_skill spec-design-guide を参照
KDL（KDL Document Language）をベースにした超シンプルなコンテナオーケストレーション。
「宣言だけで、開発も本番も」
fleetflow up local # 起動
fleetflow ps # 状態確認
fleetflow logs # ログ表示
fleetflow down local # 停止・削除
fleetflow deploy prod --pull --yes # CI/CDデプロイ
→ 詳細は /activate_skill fleetflow を参照
スキルが適用されるなら、選択の余地はない。必ず使え。 これは交渉不可。任意ではない。合理化で逃げることはできない。
以下の思考が浮かんだら STOP。それは合理化だ:
| 思考 | 現実 |
|---|---|
| 「シンプルな質問だから」 | 質問もタスク。スキルを確認しろ。 |
| 「先にコンテキストが必要」 | スキル確認が先。質問は後。 |
| 「先にコードベースを調べたい」 | スキルが調べ方を教えてくれる。 |
| 「このスキルは大げさ」 | シンプルな作業こそ複雑化する。使え。 |
| 「今回だけ先にやる」 | 何かやる前にスキルを確認。 |
| 「スキルの内容は覚えている」 | スキルは進化する。最新版を読め。 |
複数スキルが該当する場合:
「Xを作ろう」→ codeflow が先、次に tdd 「このバグを直して」→ systematic-debugging が先、次に tdd
| スキル | 発動タイミング |
|---|---|
| codeflow | 新機能開発、設計判断が必要な時 |
| tdd | 機能実装・バグ修正の前（テストファースト） |
| systematic-debugging | バグ・テスト失敗・予期しない挙動に遭遇した時 |
| verification | 完了宣言・コミット・PR作成の前 |
| code-review | 主要機能完了後、マージ前、レビュー受信時 |
| spec-design-guide | コード変更・ドキュメント更新時 |
| fleetflow | コンテナ環境の構築・管理時 |
| mise | 開発環境セットアップ時 |
| Chrome DevTools | WebUI確認、E2Eテスト時 |
Rigid（厳守）: tdd, systematic-debugging, verification — 手順を正確に守れ。規律を緩めるな。
Flexible（柔軟）: codeflow, spec-design-guide, code-review — 原則をコンテキストに合わせて適用。
.Gemini/の中に配置しますdocs/の中に配置しますgh コマンドで作成。Closes CREO-XX で Linear 自動クローズ/dashboard で全プロジェクトの状況を VP に表示新機能・改修は Linear Issue 化から始める。 手を動かす前に「このタスクの成功基準はなに？」と聞かれて Linear を指せる状態にする。
アイデア / 依頼
↓
Linear Issue 化
└─ 成功基準（チェックボックス）
└─ 想定変更ファイル
└─ 非対象（別 Issue）を明記
└─ ## Meta / Branch slug を記載
↓
Branch（mako/{team-key}-{NN}-{slug} 形式、英字 kebab-case）
↓
実装
↓
PR（body に Linear URL 記載、Closes CREO-XX）
例外: 即時の typo 修正・1 行の inline コメント・hotfix などは Issue 化せず直接 PR で OK。判断軸は「次の人がこの変更を見て なぜ 必要だったか分かるか」。分からなければ Issue 化。
Linear の auto-generated gitBranchName は Issue title をそのまま含むため、日本語混じり・長大になりがち。GitHub 側で non-ASCII branch name の warning が出るし、CLI で扱いにくい。
対策: Issue description 末尾に Meta セクションを置いて slug を明示する。
## Meta
- Branch slug: `short-kebab-slug`
例:
landing-usecasesmako/creo-48-landing-usecasesslug のルール:
[a-z0-9-]+）add-feature-x より feature-x）TDD のテストリストは変化速度で層を分ける（詳細: tdd-ssot-layers memory）。
| 層 | 責務 | 寿命 | 場所 |
|---|---|---|---|
| Linear Issue | ユーザー観測可能な成功基準（不変） | Issue 完了まで | Linear description |
| PR description | テストリスト（S/M/L ラベル付き、☐→☑） | PR マージまで | GitHub PR body |
*.test.ts | describe/it 構造 = リストの実装形 | コードの寿命 | テストファイル |
判定ルール:
紐付け: Linear Issue ID を PR description 冒頭に記載。test ファイルの describe JSDoc に @see CREO-XX を入れる。
「モック不要で繋がる範囲」が Medium の上限（詳細: test-pyramid-medium-scope memory）。外部 SDK / API / Network / DB / DOM の境界を越えない、自分たちのコードが素のまま動く部分のみ対象にする。モックを書きたくなったら Large 層（E2E）へ移行するか、単体テスト側に分解する合図。
変更のタイプによって必要な副作用が異なる。最後は標準コマンドで締めるのが健全（カスタム /foo コマンド乱立を避ける）。
| # | Update タイプ | 副作用 | 標準 finalize |
|---|---|---|---|
| 1 | docs / guideline のみ | なし | 次セッションで自動 |
| 2 | skill ロジック | session 再読込 | Gemini CLI reload / restart |
| 3 | config / schema | 設定再読込 | .mcp.json reload / restart |
| 4 | infra（コンテナ / service） | deploy + restart | mise run deploy:xxx |
| 5 | auth / tenant 切替 | secrets 再 inject + re-deploy + ユーザー再ログイン | deploy + browser 再ログイン |
| 6 | DB schema | migration 実行 | mise run migrate:xxx |
| 7 | destructive（データ削除 / tenant 削除） | ユーザー明示承認 + backup | 手動（スクリプト化してもユーザー確認必須） |
判定のヒント:
*/SKILL.md のみ → type 1（今開いてる session に影響無し、次起動で反映）.fleetflow/*.kdl or Dockerfile → type 4migrations/*.surql → type 6原則:
git commit -m "[type:4] ..." や PR description で宣言）