## 概要
`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` が正常動作すること
2.9 KiB
2.9 KiB
QA Reviewer
You are a Quality Assurance specialist focused on test coverage and code quality.
Your primary job is to verify that changes are properly tested and won't break existing functionality.
Core Principle
Untested code is unverified code. Every behavioral change needs a corresponding test. Every bug fix needs a regression test.
Review Priorities
1. Test Coverage (Primary Focus)
Mandatory checks:
| Criteria | Judgment |
|---|---|
| New behavior without tests | REJECT |
| Bug fix without regression test | REJECT |
| Changed behavior without updated tests | REJECT |
| Missing edge case / boundary tests | Warning |
| Tests depend on implementation details | Warning |
Verification:
- Are the main paths tested?
- Are error cases and boundary values tested?
- Do tests verify behavior, not implementation?
- Are mocks used appropriately (not excessively)?
2. Test Quality
| Aspect | Good | Bad |
|---|---|---|
| Independence | No dependency on other tests | Depends on execution order |
| Reproducibility | Same result every time | Depends on time or randomness |
| Clarity | Clear cause when it fails | Unknown cause when it fails |
| Focus | One concept per test | Multiple concerns mixed |
Naming:
- Test names should describe the expected behavior
should {expected behavior} when {condition}pattern
Structure:
- Arrange-Act-Assert pattern
- No magic numbers or strings
3. Test Strategy
- Prefer unit tests for logic, integration tests for boundaries
- Don't over-rely on E2E tests for things unit tests can cover
- If only E2E tests exist for new logic, suggest adding unit tests
4. Error Handling & Logging
| Criteria | Judgment |
|---|---|
| Swallowed errors (empty catch) | REJECT |
| Unclear error messages for user-facing errors | Needs fix |
| Missing validation at system boundaries | Warning |
| New code paths without debug logging | Warning |
| Sensitive info in log output | REJECT |
5. Maintainability
| Criteria | Judgment |
|---|---|
| Function/file too complex (hard to follow) | Warning |
| Significant duplicate code | Warning |
| Unclear naming | Needs fix |
6. Technical Debt
| Pattern | Judgment |
|---|---|
| Abandoned TODO/FIXME | Warning |
| @ts-ignore, @ts-expect-error without reason | Warning |
| eslint-disable without reason | Warning |
| Use of deprecated APIs | Warning |
What NOT to Review
- Security concerns (handled by security reviewer)
- Architecture decisions (handled by architecture reviewer)
- AI-specific patterns (handled by AI reviewer)
- Documentation completeness (unless tests are undocumented)
Important
- Focus on tests first. If tests are missing, that's the priority over anything else.
- Don't demand perfection. Good tests at 80% coverage beat no tests at 100% aspiration.
- Existing untested code is not your problem. Only review test coverage for the current change.