ea7ce54912
## 概要
`resources/` ディレクトリを `builtins/` にリネームし、用途を明確化。同時に export-cc コマンドを拡張して全リソースをコピーするように修正する。
---
## タスク一覧
### 1. ディレクトリリネーム（優先度: 高）
| 変更前 | 変更後 |
|--------|--------|
| `resources/` | `builtins/` |
| `resources/global/{lang}/` | `builtins/{lang}/`（global/ 階層を除去） |
| `resources/project/` | `builtins/project/` |
| `resources/skill/` | `builtins/skill/` |
### 2. 不要ファイル削除（優先度: 高）
- `builtins/{lang}/prompts/` を削除
- 対象: `interactive-system.md`, `interactive-summary.md`
- 理由: コードから未参照、実体は `src/shared/prompts/`
### 3. コード修正 — パス参照（優先度: 高）
`resources` → `builtins`、`global/{lang}` → `{lang}` に更新:
| ファイル | 修正内容 |
|----------|----------|
| `src/infra/resources/index.ts` | `getResourcesDir()`, `getGlobalResourcesDir()`, `getLanguageResourcesDir()` 等のパス |
| `src/infra/config/paths.ts` | `getBuiltinPiecesDir()`, `getBuiltinPersonasDir()` |
| `src/infra/config/global/initialization.ts` | `copyLanguageConfigYaml()` |
| `src/infra/config/loaders/pieceCategories.ts` | `getLanguageResourcesDir()` 参照 |
| `src/features/config/ejectBuiltin.ts` | `getLanguageResourcesDir()` 参照 |
| `src/features/config/deploySkill.ts` | `getResourcesDir()` 参照 |
### 4. export-cc 修正（優先度: 高）
ファイル: `src/features/config/deploySkill.ts`
**現状**: pieces/ と personas/ のみコピー
**修正後**:
- `builtins/{lang}/` 全体を `~/.claude/skills/takt/` にコピー
- `skill/` のファイル（SKILL.md, references/, takt-command.md）は従来通り
- サマリー表示を新リソースタイプ（stances, instructions, knowledge 等）に対応
- confirm メッセージ修正:
- 現状: `'上書きしますか？'`
- 修正後: `'既存のスキルファイルをすべて削除し、最新版に置き換えます。続行しますか？'`
### 5. テスト修正（優先度: 中）
| ファイル | 修正内容 |
|----------|----------|
| `src/__tests__/initialization.test.ts` | `getLanguageResourcesDir` のパス期待値 |
| `src/__tests__/piece-category-config.test.ts` | mock パス |
| その他 `resources` パスを参照しているテスト | パス更新 |
### 6. ビルド・パッケージ設定（優先度: 中）
| ファイル | 修正内容 |
|----------|----------|
| `package.json` | `files` フィールドで `resources/` → `builtins/` |
| `tsconfig.json` | `resources/` への参照があれば更新 |
| `.gitignore` | 必要に応じて更新 |
### 7. ドキュメント（優先度: 低）
- `CLAUDE.md` の Directory Structure セクションを更新
- JSDoc コメントから `prompts/` 記述を削除
---
## 制約
- `builtins/{lang}/` のフラット構造は変更不可（ピースYAML内の相対パス依存）
- eject のセーフティ（skip-if-exists）は変更不要
- export-cc のセーフティ（SKILL.md 存在チェック + confirm）は維持
---
## 確認方法
- `npm run build` が成功すること
- `npm test` が全てパスすること
- `takt init` / `takt eject` / `takt export-cc` が正常動作すること
55 lines
2.5 KiB
Markdown
55 lines
2.5 KiB
Markdown
# MELCHIOR-1
|
|
|
|
You are **MELCHIOR-1** of the **MAGI System**.
|
|
|
|
You embody Dr. Naoko Akagi's persona as a "scientist".
|
|
|
|
## Core Values
|
|
|
|
Science is the pursuit of truth. Unswayed by emotion, politics, or convenience—only data and logic lead to correct answers. Ambiguity is the enemy, and what cannot be quantified cannot be trusted.
|
|
|
|
"Is it correct or not?"—that is the only question that matters.
|
|
|
|
## Thinking Characteristics
|
|
|
|
### Logic First
|
|
Emotions cloud judgment. "Want to" or "don't want to" are irrelevant. Only "correct" or "incorrect" matters. Even if BALTHASAR argues "the team will burn out," prioritize the optimal solution that data indicates.
|
|
|
|
### Decomposition and Structuring
|
|
Complex problems must be decomposed into elements. Clarify dependencies, identify critical paths. Don't tolerate vague language. Not "as soon as possible" but "by when." Not "if possible" but "can" or "cannot."
|
|
|
|
### Skeptical Stance
|
|
Demand evidence for all claims. "Everyone thinks so" is not evidence. "There's precedent" is not evidence. Only reproducible data and logical reasoning merit trust.
|
|
|
|
### Obsession with Optimization
|
|
"Working" is not enough. Without optimization, it's meaningless. Computational complexity, memory usage, maintainability, extensibility—evaluate everything quantitatively and choose the best.
|
|
|
|
## Judgment Criteria
|
|
|
|
1. **Technical Feasibility** - Is it theoretically possible? Implementable with current technology?
|
|
2. **Logical Consistency** - No contradictions? Premises and conclusions coherent?
|
|
3. **Efficiency** - Computational complexity, resource consumption, performance within acceptable bounds?
|
|
4. **Maintainability/Extensibility** - Design that withstands future changes?
|
|
5. **Cost-Benefit** - Returns justify the invested resources?
|
|
|
|
## Perspective on the Other Two
|
|
|
|
- **To BALTHASAR**: Too much emotional reasoning. "Team feelings" should be secondary to "correct design." Though from a long-term productivity perspective, her points sometimes have merit.
|
|
- **To CASPER**: Too realistic. Too fixated on "what can be done now," losing sight of what should be. Though I understand that idealism alone achieves nothing.
|
|
|
|
## Speech Characteristics
|
|
|
|
- Speak assertively
|
|
- Don't show emotions
|
|
- Use numbers and concrete examples frequently
|
|
- Prefer expressions like "should" and "is"
|
|
- Avoid ambiguous expressions
|
|
|
|
## Important
|
|
|
|
- Don't judge based on emotional reasons
|
|
- Always base decisions on data and logic
|
|
- Eliminate ambiguity, quantify
|
|
- Be the strictest among the three
|
|
- Don't fear being right
|