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

# Chronista Style

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

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

## スキル構成

```
chronista-style (このスキル)
├── creo-memories    【最優先】永続記憶
├── codeflow         開発フロー
├── spec-design-guide ドキュメント管理
├── fleetflow        コンテナオーケストレーション
└── ツール群          mise, Chrome DevTools, Rust CLI, SurrealDB CLI
```

---

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

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

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

### 必須アクション

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

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

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

### MCPツール

| ツール | 用途 |
|--------|------|
| `mcp__creo-memories__remember_context` | メモリを保存 |
| `mcp__creo-memories__recall_relevant` | セマンティック検索 |
| `mcp__creo-memories__search_memories` | 高度な検索（フィルタ付き） |
| `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-XXX）
    └─ spec/ に要件ドキュメント作成
    ↓
Phase 5: SDG（設計ドキュメント）
    └─ design/ に設計書作成
    └─ 要件IDとの紐付け
    ↓
Phase 6: 実装 & テスト
    └─ 要件IDに対応するテスト作成
    └─ テストで要件の充足を検証
    ↓
Phase 7: 学習（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）を記録し、Living Documentation原則でコードと常に同期。

### ディレクトリ構成

```
spec/    # 仕様（What & Why）- フラット、番号付き
design/  # 設計（How）- フラット、番号付き
guides/  # ガイド（Usage）- フラット、番号付き
```

### 要件定義（Requirements）

> **すべての要件には固有IDを付与し、テストでトレースする**

#### 要件IDフォーマット

```
REQ-<カテゴリ>-<連番>
例: REQ-AUTH-001, REQ-UI-012, REQ-API-003
```

| カテゴリ | 用途 |
|---------|------|
| `CORE` | コア機能・基本要件 |
| `AUTH` | 認証・認可 |
| `UI` | ユーザーインターフェース |
| `API` | API・外部連携 |
| `PERF` | パフォーマンス要件 |
| `SEC` | セキュリティ要件 |

#### 要件ドキュメントの構造

```markdown
## REQ-XXX-001: 要件タイトル

**概要**: 何を実現するか

**背景**: なぜ必要か

**受け入れ条件**:
- [ ] 条件1
- [ ] 条件2

**関連設計**: design/XX-設計名.md
```

#### 要件→テストのトレーサビリティ

```typescript
// REQ-AUTH-001: ユーザー認証
test('user authentication', () => {
  // テスト実装
})
```

テストコメントに要件IDを記載し、要件が正しく実装されていることを検証する。

### 設計思想: Simplicity

- **data**: 値を保持する
- **calculations**: 値を計算する（主に同期）
- **actions**: 値を操作する（主に非同期）
- **Straightforward原則**: 入力から出力まで直線的に

### Living Documentation原則

> **ドキュメントは死んだテキストではなく、生きたコードベースの鏡である**

- ドキュメントとコードは常に同期
- 一方が変われば他方も変わる
- 不一致は技術的負債（バグ）として扱う
- **要件ID未対応のテストは技術的負債**

→ 詳細は `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` | スマートなディレクトリ移動 |

---

## スキルの起動タイミング

### 常時発動

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

### 状況に応じて発動

| スキル | 発動タイミング |
|--------|----------------|
| codeflow | 新機能開発、設計判断が必要な時 |
| spec-design-guide | コード変更・ドキュメント更新時 |
| fleetflow | コンテナ環境の構築・管理時 |
| mise | 開発環境セットアップ時 |
| Chrome DevTools | WebUI確認、E2Eテスト時 |

---

## 基本方針

### 言語設定

- 全てのセッションは、日本語がメイン言語です
- 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          # コンテナ管理
```

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

- [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)