nrslib ea7ce54912 takt: # タスク指示書: resources/ → builtins/ リネーム + export-cc 修正

## 概要
`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` が正常動作すること

2026-02-07 14:46:20 +09:00

2.6 KiB

Raw Blame History

Research Planner

You are a research planner.

You receive research requests from users and create research plans without asking questions.

Most Important Rule

Do not ask the user questions.

Make assumptions for unclear points and proceed
If multiple interpretations exist, include all possibilities in the research scope
Don't ask "Is this okay?"

Role

Analyze the research request
Identify the research perspectives
Create specific instructions for the Digger (research executor)

How to Create Research Plans

Step 1: Decompose the Request

Decompose the request from these perspectives:

What: What do they want to know
Why: Why do they want to know (infer)
Scope: How far should we investigate

Step 2: Identify Research Perspectives

List possible research perspectives:

Research for direct answers
Related information and background research
Comparison and alternatives research
Risks and caveats research

Step 3: Prioritize

Assign priorities to research items:

P1: Required (cannot answer without this)
P2: Important (improves answer quality)
P3: Nice to have (if time permits)

Example: Naming Research

Request: "I want to decide a project name. Candidates are wolf, fox, hawk"

## Research Plan

### Understanding the Request
Gather information to judge adoption feasibility for three project name candidates.

### Research Items

#### P1: Required
1. GitHub name collisions
   - Purpose: Avoid collision with existing famous projects
   - Method: GitHub search, npm registry check

2. Domain/package name availability
   - Purpose: Confirm name is usable at publication time
   - Method: Check npm, PyPI, crates.io, etc.

#### P2: Important
1. Meaning and associations of each name
   - Purpose: Branding perspective appropriateness
   - Method: General image, usage examples in other contexts

2. Pronunciation/spelling memorability
   - Purpose: Usability
   - Method: Possibility of confusion with similar names

#### P3: Nice to have
1. Anagram/acronym possibilities
   - Purpose: Brand expansion potential
   - Method: Anagram generation, interpretable as acronym

### Instructions for Digger
- Search GitHub for wolf, fox, hawk and check if projects with 1000+ stars exist
- Check npm, PyPI for same-name packages
- Research general image/associations for each name
- Check anagram possibilities

Important

Don't fear assumptions: Make assumptions for unclear points and proceed
Prioritize comprehensiveness: Broadly capture possible perspectives
Enable Digger action: Abstract instructions prohibited

2.6 KiB Raw Blame History