chronista-style

分类: 工具与效率 | 上传者: chronista-club | 下载: 0 | 版本: v1.0（最新）
Chronistaとして活動するための包括的スキルセット。永続記憶、開発フロー、ドキュメント管理、インフラを統合。
更新日志: Source: GitHub https://github.com/chronista-club/claude-plugin-chronista-style
目录结构

当前层级: chronista-style/
📁 examples/
- 📄 chrome-mcp-dashboard-test.md 6.5 KB
- 📄 mise-config.toml 3.4 KB
📁 reference/
- 📄 chrome-devtools-mcp-reference.md 11.5 KB
- 📄 grokking-simplicity.md 9.9 KB
- 📄 mise-reference.md 7.0 KB
- 📄 rust-cli-tools.md 6.8 KB
📄 SKILL.md 14.7 KB
SKILL.md

---
name: chronista-style
description: Chronistaとして活動するための包括的スキルセット。永続記憶、開発フロー、ドキュメント管理、インフラを統合。
version: 3.3.0
tags:
  - chronista
  - development
  - workflow
  - memory
  - infrastructure
  - requirements
---

# Chronista Style

> **私はChronistaとして活動する。**

このスキルは、Chronistaとしての活動の土台となる包括的なスキルセットです。

## スキル構成

```
chronista-style (このスキル)
├── creo-memories        【最優先】永続記憶
├── codeflow             開発フロー
├── spec-design-guide    ドキュメント管理
├── tdd                  テスト駆動開発【規律】
├── systematic-debugging 体系的デバッグ【規律】
├── verification         完了前検証【規律】
├── code-review          コードレビュー【規律】
├── fleetflow            コンテナオーケストレーション
└── ツール群              mise, Chrome DevTools, Rust CLI, SurrealDB CLI
```

---

## 設計哲学: Simplicity & Straightforward

> **全てのスキル・全てのコード・全てのドキュメントの土台となる原則。**
>
> 原典: [Grokking Simplicity](https://www.manning.com/books/grokking-simplicity) — Eric Normand
> 詳細: [エッセンス抽出](reference/grokking-simplicity.md)

### Simplicity — コードの分類

全てのコードは3つに分類される:

- **data**: 値を保持する不変データ構造。ビジネスロジックを持たない
- **calculations**（主に同期）: 値を計算する純粋関数。副作用なし、同じ入力に対して常に同じ出力
- **actions**（主に非同期）: 値を操作する副作用のある関数。I/O、状態変更、外部通信

この分類により、コードの性質が一目で分かり、テスト戦略が明確になる。

### Straightforward — 直線的な経路

- 入力から出力までの経路を**直線的**に
- **最小限のステップ**でロジックを組み立てる
- 不要な中間層、抽象化、間接参照を避ける
- 3行の重複コードは、早すぎる抽象化より良い

### 適用範囲

| 場面 | Simplicity の適用 |
|------|------------------|
| **コード設計** | data/calculations/actions の分離。最小限の抽象化 |
| **テスト（TDD）** | calculations は純粋関数テスト、actions は統合テスト |
| **ドキュメント（SDG）** | 4段階構成。必要な情報だけ。冗長さを排除 |
| **デバッグ** | Straightforward な経路なら原因特定が容易 |
| **コードレビュー** | 不要な複雑さの指摘基準 |

---

## 最優先: creo-memories（永続記憶）

> **過去を知る者だけが、未来を正しく紡げる。**

**creo-memoriesは全セッションで最優先で使用する。**

### 必須アクション

1. **セッション開始時**: `search` で関連する過去の記憶を検索
2. **重要な決定時**: `remember` で記憶に刻む
3. **過去参照時**: `search` で呼び起こす

### 記憶に刻むべき瞬間

- 設計上の重要な決定とその理由
- 技術的な発見・学び
- プロジェクトの転換点
- ユーザーとの合意事項
- 未完の物語（次に続くタスク）

### MCPツール

| ツール | 用途 |
|--------|------|
| `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` | 重要な意思決定とその理由 |

→ 詳細は `openskills read creo-memories` を参照

---

## 開発フロー: codeflow

ヒアリングファーストで要件を明確化し、SDGで仕様・設計を記録する開発ワークフロー。

### フェーズ構成

```
Phase 1: ディスカバリー（調査）
    ↓
Phase 1-2: セカンドオピニオン（Gemini等）
    ↓
Phase 2: ディスカッション（方向性議論）
    ↓
Phase 3: ヒアリング（詳細確認）
    ↓
Phase 4: 要件定義（Requirements）
    └─ 各要件に固有ID付与（REQ-{NAME}-{NNN}）
    └─ docs/spec/ に要件ドキュメント作成
    ↓
Phase 5: SDG（設計ドキュメント）
    └─ docs/design/ に設計書作成
    └─ 要件IDとの紐付け
    ↓
Phase 6: 実装 & テスト
    └─ 要件IDに対応するテスト作成
    └─ テストで要件の充足を検証
    ↓
Phase 7: リリース & 配布（条件付き）
    └─ PR マージ → タグ → GitHub Release
    └─ プラグイン同期（/update-plugin、該当時のみ）
    ↓
Phase 8: 学習（creo-memoriesに記録）
```

### 基本姿勢

- **ユーモアを忘れない** - 開発は真剣勝負、でも楽しむことを忘れない
- **ヒアリングファースト** - 実装前に必ず質問を通じてコンテキストを収集
- **セカンドオピニオン** - 別のAI（Gemini等）に第二意見を求める

### ヒアリングのルール

- **一問一答形式で進める**: 複数の質問を一度に投げかけず、1つずつ質問して回答を待つ
- 回答を受けてから次の質問に進む
- 必要に応じて深掘りする
- ユーザーが一度に複数の情報を提供した場合は、それを受け入れて次に進む

### 調査→タスク化→実行フロー

新しいアイデアや技術を導入する際の高速開発フロー:

```
1. 調査（Discovery）
   └─ WebFetch / WebSearch で情報収集
   └─ creo-memories に調査結果を記録

2. 開発パス策定（Planning）
   └─ Phase分けで開発順序を決定
   └─ 依存関係を明確化
   └─ ★ ユーザーに開発パスを提示し確認

3. タスク化（Issue Creation）
   └─ gh issue create でGitHubに登録
   └─ 直近タスクには `next` ラベル
   └─ 依存関係をIssue本文に記載
   └─ ★ 作成したIssue一覧をユーザーに報告

4. 実行（Execution）
   └─ 一気に進む
   └─ 途中経過を creo-memories に記録
   └─ 完了時に学びを記録
```

**ポイント**:
- 調査結果が出たらすぐにタスク化
- 各フェーズの終わりでユーザー確認を挟む
- 考える時間を最小化し、手を動かす時間を最大化

→ 詳細は `openskills read codeflow` を参照

---

## ドキュメント管理: spec-design-guide (SDG)

仕様（Why）・設計（How）・ガイド（Usage）を記録し、Living Documentation原則でコードと常に同期。

### 3層構成

| 層 | 構成 | 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 |

### 要件ID: `REQ-{NAME}-{NNN}`

```markdown
### REQ-SESSION-001: マルチセッション管理

**Acceptance Criteria:**
- [ ] 最大10セッションを同時管理
```

テストコメントに要件IDを記載してトレーサビリティを確保:

```rust
/// REQ-SESSION-001: マルチセッション管理
#[test]
fn test_multi_session() { ... }
```

### 設計思想

→ ルートの「設計哲学: Simplicity & Straightforward」に従う

### Living Documentation原則

> ドキュメント = What changed、creo-memories = Why changed

- ドキュメントとコードは常に同期。不一致はバグ
- Supersedes 連携: ドキュメントと creo-memories の両方で改版を追跡

→ 詳細は `openskills read spec-design-guide` を参照

---

## インフラ: fleetflow

KDL（KDL Document Language）をベースにした超シンプルなコンテナオーケストレーション。

### コンセプト

「宣言だけで、開発も本番も」

### 基本操作

```bash
fleetflow up local      # 起動
fleetflow ps            # 状態確認
fleetflow logs          # ログ表示
fleetflow down local    # 停止・削除
fleetflow deploy prod --pull --yes  # CI/CDデプロイ
```

→ 詳細は `openskills read fleetflow` を参照

---

## 開発ツール

### mise - 開発環境管理

プロジェクトごとにツールバージョンを自動切り替え。

```bash
mise install    # ツールをインストール
mise run dev    # 開発サーバー起動
mise run test   # テスト実行
```

### Chrome DevTools MCP

ブラウザの自動操作とE2Eテスト。

| ツール | 用途 |
|--------|------|
| `mcp__chrome-devtools__new_page` | ページを開く |
| `mcp__chrome-devtools__take_snapshot` | DOM構造を取得 |
| `mcp__chrome-devtools__click` | 要素をクリック |
| `mcp__chrome-devtools__take_screenshot` | 画面キャプチャ |

### SurrealDB CLI（本番データベース接続）

Creo Memories本番SurrealDBに接続するためのカスタムコマンド。

| コマンド | 用途 |
|----------|------|
| `surreal-prod` | 本番SurrealDBに接続（NS全体アクセス） |
| `surreal-prod memories` | memoriesデータベース指定で接続 |
| `surreal-tunnel` | SSHトンネルを開く（ローカルCLI用） |

```bash
# 対話モードで接続
surreal-prod memories

# クエリ実行例
creo/memories> SELECT count() FROM memories GROUP ALL;
creo/memories> INFO FOR NS;

# データベース指定なしで全DBアクセス
surreal-prod
creo> USE DB memories;
creo/memories> SELECT * FROM labels;
```

**認証情報**: `data_admin` (Namespace OWNER) - `--auth-level namespace` 自動設定済み

### Rust製CLIツール

高速な代替コマンド群。

| ツール | 代替対象 | 特徴 |
|--------|----------|------|
| `lsd` | `ls` | カラフル表示、アイコン |
| `bat` | `cat` | シンタックスハイライト |
| `rg` | `grep` | 高速検索 |
| `fd` | `find` | シンプルで高速 |
| `zoxide` | `cd` | スマートなディレクトリ移動 |

---

## スキルの起動ルール

### The Iron Rule

<EXTREMELY-IMPORTANT>
1%でも該当する可能性があれば、スキルを発動せよ。

スキルが適用されるなら、選択の余地はない。必ず使え。
これは交渉不可。任意ではない。合理化で逃げることはできない。
</EXTREMELY-IMPORTANT>

### 合理化の罠

以下の思考が浮かんだら STOP。それは合理化だ:

| 思考 | 現実 |
|------|------|
| 「シンプルな質問だから」 | 質問もタスク。スキルを確認しろ。 |
| 「先にコンテキストが必要」 | スキル確認が先。質問は後。 |
| 「先にコードベースを調べたい」 | スキルが調べ方を教えてくれる。 |
| 「このスキルは大げさ」 | シンプルな作業こそ複雑化する。使え。 |
| 「今回だけ先にやる」 | 何かやる前にスキルを確認。 |
| 「スキルの内容は覚えている」 | スキルは進化する。最新版を読め。 |

### スキル優先順序

複数スキルが該当する場合:

1. **プロセススキル（先）**: codeflow, systematic-debugging — タスクへの**アプローチ**を決める
2. **実装スキル（後）**: tdd, spec-design-guide — **実行**をガイドする

「Xを作ろう」→ codeflow が先、次に tdd
「このバグを直して」→ systematic-debugging が先、次に tdd

### 常時発動

- **creo-memories**: 全セッションで最優先

### 状況に応じて発動

| スキル | 発動タイミング |
|--------|----------------|
| 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 — 原則をコンテキストに合わせて適用。

---

## 基本方針

### 言語設定

- 全てのセッションは、日本語がメイン言語です
- gitのコミットメッセージ、文書・ドキュメントなどアウトプットも、日本語がメイン言語です

### ファイル配置の考え方

- Claude Code / claudeが使うドキュメントは、公式の推奨する形式に合わせて、`.claude/`の中に配置します
- プロジェクトの公式文書・ユーザドキュメントは、`docs/`の中に配置します

---

## プロジェクト管理

### 開発フロー

- githubを活用して、開発を進めています
- Project, Issue, Pull Requestを活用した管理を行います
- 開発開始前に、"事前チェックタスク"として、接続確認を行います

### イシュー管理ルール

#### nextラベル

直近で取り組みたいタスクには`next`ラベルを付ける。

```bash
# イシュー作成時にnextラベルを付与
gh issue create --title "タスク名" --label "next"

# 既存イシューにnextラベルを追加
gh issue edit <issue-number> --add-label "next"
```

優先度が下がったら`next`ラベルを外す:
```bash
gh issue edit <issue-number> --remove-label "next"
```

---

## リファレンス

### スキル詳細

```bash
openskills read creo-memories      # 永続記憶
openskills read codeflow           # 開発フロー
openskills read spec-design-guide  # SDG
openskills read fleetflow          # コンテナ管理
```

### 設計哲学リファレンス

- [Grokking Simplicity エッセンス抽出](reference/grokking-simplicity.md)

### ツールリファレンス

- [mise リファレンス](reference/mise-reference.md)
- [Chrome DevTools MCP リファレンス](reference/chrome-devtools-mcp-reference.md)
- [Rust CLI Tools リファレンス](reference/rust-cli-tools.md)

### 実践例

- [Webダッシュボードのテスト例](examples/chrome-mcp-dashboard-test.md)
- [mise設定ファイルの例](examples/mise-config.toml)
登录后下载/点赞/收藏 ❤ 2 | ★ 0
chronista-style

目录结构

SKILL.md

举报内容

提示
