@fifine/aim-studio 0.0.4 → 0.0.8

package/dist/templates/claude/commands/aim/parallel.md

@@ -1,217 +0,0 @@
-# 多 Agent 并行创作
-
-启动多终端并行创作模式，让多个 AI Agent 同时创作不同剧集。
-
----
-
-## ⚠️ 重要安全说明
-
-### 不会冲突的情况（安全）
-
-| 资源 | 原因 |
-|------|------|
-| **Git Worktree** | 每个 Agent 有独立的工作树目录 |
-| **Git 分支** | 每个 Agent 在独立分支上工作 |
-| **任务目录** | 每个 Agent 有独立的 `.aim-studio/tasks/任务名/` |
-| **进度日志** | 每个 Agent 有独立的日志文件 |
-
-### 可能冲突的情况（需要注意）
-
-| 资源 | 风险 | 解决方案 |
-|------|------|----------|
-| **创作输出** | 多 Agent 写入同一 workspace | ⚠️ **必须分配不同的剧集** |
-| **角色设定** | 多 Agent 同时修改 character.md | ⚠️ **创作前完成所有角色设定** |
-| **世界观** | 多 Agent 同时修改 world.md | ⚠️ **创作前完成世界观设定** |
-
-### 🚨 核心规则
-
-```
-✅ 安全：Agent A 写第1集，Agent B 写第2集（不同剧集）
-❌ 危险：Agent A 和 Agent B 同时写第1集（同一剧集）
-```
-
----
-
-## 使用场景
-
-| 场景 | 安全性 | 说明 |
-|------|--------|------|
-| **多剧集并行** | ✅ 安全 | Agent A 写第1集，Agent B 写第2集 |
-| **主线/支线分离** | ✅ 安全 | Agent A 写主线，Agent B 写支线 |
-| **创作+质检** | ⚠️ 需协调 | 质检 Agent 只读，不修改文件 |
-
----
-
-## 快速开始
-
-### 步骤 0：完成共享设定（必须）
-
-**在启动多 Agent 之前，必须完成所有角色和世界观设定！**
-
-```bash
-# 确保角色设定已完成
-cat .aim-studio/spec/story/character.md
-
-# 确保世界观设定已完成
-cat .aim-studio/spec/story/world.md
-```
-
-### 步骤 1：创建多个任务
-
-```bash
-# 创建任务 A（第1集）
-aim task create "第1集：系统觉醒" --slug 第1集_系统觉醒
-
-# 创建任务 B（第2集）
-aim task create "第2集：初入江湖" --slug 第2集_初入江湖
-```
-
-### 步骤 2：启动并行 Agent
-
-**重要：每个 Agent 必须在不同的终端中运行！**
-
-**终端 1：**
-```bash
-python3 ./.aim-studio/scripts/multi_agent/start.py .aim-studio/tasks/第1集_系统觉醒
-```
-
-**终端 2：**
-```bash
-python3 ./.aim-studio/scripts/multi_agent/start.py .aim-studio/tasks/第2集_初入江湖
-```
-
-### 步骤 3：监控进度
-
-```bash
-# 查看所有 Agent 状态
-python3 ./.aim-studio/scripts/multi_agent/status.py
-
-# 实时监控
-python3 ./.aim-studio/scripts/multi_agent/status.py --watch
-```
-
----
-
-## 隔离机制详解
-
-### Git Worktree 隔离
-
-每个 Agent 在独立的 Git Worktree 中运行：
-
-```
-主仓库 (main)
-├── .aim-studio/
-│   ├── spec/story/         # 共享设定（只读）
-│   ├── tasks/              # 任务目录
-│   │   ├── 第1集_系统觉醒/  # Agent A 的任务
-│   │   └── 第2集_初入江湖/  # Agent B 的任务
-│   └── workspace/          # 创作输出
-│       └── 我的故事/
-│           ├── 第1集_*/    # Agent A 的输出
-│           └── 第2集_*/    # Agent B 的输出
-│
-└── .agents/                # Agent 工作树（自动创建）
-    ├── registry.json       # Agent 注册表
-    ├── worktree-第1集/     # Agent A 的独立环境
-    │   └── .aim-studio/
-    │       └── .current-task → 第1集
-    └── worktree-第2集/     # Agent B 的独立环境
-        └── .aim-studio/
-            └── .current-task → 第2集
-```
-
-### 数据安全保证
-
-| 隔离级别 | 说明 |
-|----------|------|
-| **文件系统隔离** | 每个 Worktree 是独立的文件副本 |
-| **Git 分支隔离** | 每个 Agent 在独立分支上工作 |
-| **任务目录隔离** | 每个 Agent 有独立的任务配置 |
-| **进度追踪隔离** | 每个 Agent 有独立的进度日志 |
-
----
-
-## 完成后合并
-
-### 步骤 1：确认所有 Agent 完成
-
-```bash
-python3 ./.aim-studio/scripts/multi_agent/status.py
-```
-
-确保所有 Agent 状态为 `completed` 或 `finished`。
-
-### 步骤 2：合并创作内容
-
-```bash
-# 将各 Agent 的创作内容合并到主仓库
-# Agent A 的输出
-cp -r .agents/worktree-第1集/.aim-studio/workspace/我的故事/第1集_* .aim-studio/workspace/我的故事/
-
-# Agent B 的输出
-cp -r .agents/worktree-第2集/.aim-studio/workspace/我的故事/第2集_* .aim-studio/workspace/我的故事/
-```
-
-### 步骤 3：清理 Worktree
-
-```bash
-python3 ./.aim-studio/scripts/multi_agent/cleanup.py feature/第1集
-python3 ./.aim-studio/scripts/multi_agent/cleanup.py feature/第2集
-```
-
----
-
-## 故障排除
-
-### Agent 启动失败
-
-```bash
-# 检查任务目录是否存在
-ls .aim-studio/tasks/
-
-# 检查 task.json 是否有效
-cat .aim-studio/tasks/<任务名>/task.json
-```
-
-### Worktree 冲突
-
-```bash
-# 手动清理 Worktree
-git worktree list
-git worktree remove .agents/worktree-<name>
-```
-
-### Registry 损坏
-
-```bash
-# 重置 Registry
-rm .agents/registry.json
-python3 ./.aim-studio/scripts/multi_agent/status.py
-```
-
----
-
-## 最佳实践
-
-### ✅ 应该做
-
-1. **创作前完成所有共享设定**（角色、世界观）
-2. **为每个 Agent 分配不同的剧集**
-3. **定期检查 Agent 状态**
-4. **完成后及时合并和清理**
-
-### ❌ 不应该做
-
-1. **不要让多个 Agent 同时创作同一剧集**
-2. **不要在创作过程中修改共享设定**
-3. **不要忘记清理完成的 Worktree**
-
----
-
-## 相关命令
-
-| 命令 | 说明 |
-|------|------|
-| `/aim:start` | 单 Agent 创作模式 |
-| `/aim:story` | 漫剧创作模式 |
-| `/aim:finish-work` | 完成工作并记录进度 |

package/dist/templates/claude/commands/aim/update-spec.md

@@ -1,285 +0,0 @@
-# Update Spec - Capture Knowledge into Specifications
-
-When you learn something valuable (from debugging, implementing, or discussion), use this command to update the relevant spec documents.
-
-**Timing**: After completing a task, fixing a bug, or discovering a new pattern
-
----
-
-## When to Update Specs
-
-| Trigger | Example | Target Spec |
-|---------|---------|-------------|
-| **Implemented a feature** | Added template download with giget | Relevant `backend/` or `frontend/` file |
-| **Made a design decision** | Used type field + mapping table for extensibility | Relevant spec + "Design Decisions" section |
-| **Fixed a bug** | Found a subtle issue with error handling | `backend/error-handling.md` |
-| **Discovered a pattern** | Found a better way to structure code | Relevant `backend/` or `frontend/` file |
-| **Hit a gotcha** | Learned that X must be done before Y | Relevant spec + "Common Mistakes" section |
-| **Established a convention** | Team agreed on naming pattern | `quality-guidelines.md` |
-| **New thinking trigger** | "Don't forget to check X before doing Y" | `guides/*.md` (as a checklist item, not detailed rules) |
-
-**Key Insight**: Spec updates are NOT just for problems. Every feature implementation contains design decisions and project conventions that future AI/developers need to know.
-
----
-
-## Spec Structure Overview
-
-```
-.aim-studio/spec/
-├── backend/           # Backend coding standards
-│   ├── index.md       # Overview and links
-│   └── *.md           # Topic-specific guidelines
-├── frontend/          # Frontend coding standards
-│   ├── index.md       # Overview and links
-│   └── *.md           # Topic-specific guidelines
-└── guides/            # Thinking checklists (NOT coding specs!)
-    ├── index.md       # Guide index
-    └── *.md           # Topic-specific guides
-```
-
-### CRITICAL: Spec vs Guide - Know the Difference
-
-| Type | Location | Purpose | Content Style |
-|------|----------|---------|---------------|
-| **Spec** | `backend/*.md`, `frontend/*.md` | Tell AI "how to write code" | Detailed rules, code examples, forbidden patterns |
-| **Guide** | `guides/*.md` | Help AI "what to think about" | Checklists, questions, pointers to specs |
-
-**Decision Rule**: Ask yourself:
-
-- "This is **how to write** the code" → Put in `backend/` or `frontend/`
-- "This is **what to consider** before writing" → Put in `guides/`
-
-**Example**:
-
-| Learning | Wrong Location | Correct Location |
-|----------|----------------|------------------|
-| "Use `reconfigure()` not `TextIOWrapper` for Windows stdout" | ❌ `guides/cross-platform-thinking-guide.md` | ✅ `backend/script-conventions.md` |
-| "Remember to check encoding when writing cross-platform code" | ❌ `backend/script-conventions.md` | ✅ `guides/cross-platform-thinking-guide.md` |
-
-**Guides should be short checklists that point to specs**, not duplicate the detailed rules.
-
----
-
-## Update Process
-
-### Step 1: Identify What You Learned
-
-Answer these questions:
-
-1. **What did you learn?** (Be specific)
-2. **Why is it important?** (What problem does it prevent?)
-3. **Where does it belong?** (Which spec file?)
-
-### Step 2: Classify the Update Type
-
-| Type | Description | Action |
-|------|-------------|--------|
-| **Design Decision** | Why we chose approach X over Y | Add to "Design Decisions" section |
-| **Project Convention** | How we do X in this project | Add to relevant section with examples |
-| **New Pattern** | A reusable approach discovered | Add to "Patterns" section |
-| **Forbidden Pattern** | Something that causes problems | Add to "Anti-patterns" or "Don't" section |
-| **Common Mistake** | Easy-to-make error | Add to "Common Mistakes" section |
-| **Convention** | Agreed-upon standard | Add to relevant section |
-| **Gotcha** | Non-obvious behavior | Add warning callout |
-
-### Step 3: Read the Target Spec
-
-Before editing, read the current spec to:
-- Understand existing structure
-- Avoid duplicating content
-- Find the right section for your update
-
-```bash
-cat .aim-studio/spec/<category>/<file>.md
-```
-
-### Step 4: Make the Update
-
-Follow these principles:
-
-1. **Be Specific**: Include concrete examples, not just abstract rules
-2. **Explain Why**: State the problem this prevents
-3. **Show Code**: Add code snippets for patterns
-4. **Keep it Short**: One concept per section
-
-### Step 5: Update the Index (if needed)
-
-If you added a new section or the spec status changed, update the category's `index.md`.
-
----
-
-## Update Templates
-
-### Adding a Design Decision
-
-```markdown
-### Design Decision: [Decision Name]
-
-**Context**: What problem were we solving?
-
-**Options Considered**:
-1. Option A - brief description
-2. Option B - brief description
-
-**Decision**: We chose Option X because...
-
-**Example**:
-\`\`\`typescript
-// How it's implemented
-code example
-\`\`\`
-
-**Extensibility**: How to extend this in the future...
-```
-
-### Adding a Project Convention
-
-```markdown
-### Convention: [Convention Name]
-
-**What**: Brief description of the convention.
-
-**Why**: Why we do it this way in this project.
-
-**Example**:
-\`\`\`typescript
-// How to follow this convention
-code example
-\`\`\`
-
-**Related**: Links to related conventions or specs.
-```
-
-### Adding a New Pattern
-
-```markdown
-### Pattern Name
-
-**Problem**: What problem does this solve?
-
-**Solution**: Brief description of the approach.
-
-**Example**:
-\`\`\`
-// Good
-code example
-
-// Bad
-code example
-\`\`\`
-
-**Why**: Explanation of why this works better.
-```
-
-### Adding a Forbidden Pattern
-
-```markdown
-### Don't: Pattern Name
-
-**Problem**:
-\`\`\`
-// Don't do this
-bad code example
-\`\`\`
-
-**Why it's bad**: Explanation of the issue.
-
-**Instead**:
-\`\`\`
-// Do this instead
-good code example
-\`\`\`
-```
-
-### Adding a Common Mistake
-
-```markdown
-### Common Mistake: Description
-
-**Symptom**: What goes wrong
-
-**Cause**: Why this happens
-
-**Fix**: How to correct it
-
-**Prevention**: How to avoid it in the future
-```
-
-### Adding a Gotcha
-
-```markdown
-> **Warning**: Brief description of the non-obvious behavior.
->
-> Details about when this happens and how to handle it.
-```
-
----
-
-## Interactive Mode
-
-If you're unsure what to update, answer these prompts:
-
-1. **What did you just finish?**
-   - [ ] Fixed a bug
-   - [ ] Implemented a feature
-   - [ ] Refactored code
-   - [ ] Had a discussion about approach
-
-2. **What did you learn or decide?**
-   - Design decision (why X over Y)
-   - Project convention (how we do X)
-   - Non-obvious behavior (gotcha)
-   - Better approach (pattern)
-
-3. **Would future AI/developers need to know this?**
-   - To understand how the code works → Yes, update spec
-   - To maintain or extend the feature → Yes, update spec
-   - To avoid repeating mistakes → Yes, update spec
-   - Purely one-off implementation detail → Maybe skip
-
-4. **Which area does it relate to?**
-   - [ ] Backend code
-   - [ ] Frontend code
-   - [ ] Cross-layer data flow
-   - [ ] Code organization/reuse
-   - [ ] Quality/testing
-
----
-
-## Quality Checklist
-
-Before finishing your spec update:
-
-- [ ] Is the content specific and actionable?
-- [ ] Did you include a code example?
-- [ ] Did you explain WHY, not just WHAT?
-- [ ] Is it in the right spec file?
-- [ ] Does it duplicate existing content?
-- [ ] Would a new team member understand it?
-
----
-
-## Relationship to Other Commands
-
-```
-Development Flow:
-  Learn something → /aim:update-spec → Knowledge captured
-       ↑                                  ↓
-  /aim:break-loop ←──────────────────── Future sessions benefit
-  (deep bug analysis)
-```
-
-- `/aim:break-loop` - Analyzes bugs deeply, often reveals spec updates needed
-- `/aim:update-spec` - Actually makes the updates (this command)
-- `/aim:finish-work` - Reminds you to check if specs need updates
-
----
-
-## Core Philosophy
-
-> **Specs are living documents. Every debugging session, every "aha moment" is an opportunity to make the spec better.**
-
-The goal is **institutional memory**:
-- What one person learns, everyone benefits from
-- What AI learns in one session, persists to future sessions
-- Mistakes become documented guardrails