mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-06 01:54:11 +08:00
Compare commits
20 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
43d647e7b2 | ||
|
|
76aa20cdfd | ||
|
|
39c956c703 | ||
|
|
dd04433079 | ||
|
|
c36ff8fcec | ||
|
|
967e3805b7 | ||
|
|
e898ebc322 | ||
|
|
a38a216cc9 | ||
|
|
3b351693fc | ||
|
|
ab266a38b1 | ||
|
|
dc9d63b349 | ||
|
|
72bdb3470e | ||
|
|
f496a35da5 | ||
|
|
15bf9cdbed | ||
|
|
779581ec3b | ||
|
|
483ab621bc | ||
|
|
6adbe7c1e9 | ||
|
|
b5fb4e3d48 | ||
|
|
1cabccbbdd | ||
|
|
8073549234 |
@@ -178,7 +178,7 @@ target/
|
||||
/cli:cli-init --tool all --output=.config/
|
||||
```
|
||||
|
||||
## EXECUTION INSTRUCTIONS ⚡ START HERE
|
||||
## EXECUTION INSTRUCTIONS - START HERE
|
||||
|
||||
**When this command is triggered, follow these exact steps:**
|
||||
|
||||
@@ -209,7 +209,7 @@ bash(find . -name "Dockerfile" | head -1)
|
||||
```bash
|
||||
# Create .gemini/ directory and settings.json
|
||||
mkdir -p .gemini
|
||||
echo '{"contextfilename": "CLAUDE.md"}' > .gemini/settings.json
|
||||
Write({file_path: '.gemini/settings.json', content: '{"contextfilename": "CLAUDE.md"}'})
|
||||
|
||||
# Create .geminiignore file with detected technology rules
|
||||
# Backup existing files if present
|
||||
@@ -219,7 +219,7 @@ echo '{"contextfilename": "CLAUDE.md"}' > .gemini/settings.json
|
||||
```bash
|
||||
# Create .qwen/ directory and settings.json
|
||||
mkdir -p .qwen
|
||||
echo '{"contextfilename": "CLAUDE.md"}' > .qwen/settings.json
|
||||
Write({file_path: '.qwen/settings.json', content: '{"contextfilename": "CLAUDE.md"}'})
|
||||
|
||||
# Create .qwenignore file with detected technology rules
|
||||
# Backup existing files if present
|
||||
|
||||
@@ -257,12 +257,12 @@ TodoWrite({
|
||||
|
||||
**When to Resume vs New Session**:
|
||||
```
|
||||
✅ RESUME (same group):
|
||||
RESUME (same group):
|
||||
- Subtasks share files/modules
|
||||
- Logical continuation of previous work
|
||||
- Same architectural domain
|
||||
|
||||
❌ NEW SESSION (different group):
|
||||
NEW SESSION (different group):
|
||||
- Independent task area
|
||||
- Different files/modules
|
||||
- Switching architectural domains
|
||||
@@ -318,7 +318,7 @@ AskUserQuestion({
|
||||
|
||||
**During Execution**:
|
||||
```
|
||||
📊 Task Flow Diagram:
|
||||
Task Flow Diagram:
|
||||
[Group A: Auth Core]
|
||||
A1: Create user model ──┐
|
||||
A2: Add validation ─┤─► [resume] ─► A3: Database schema
|
||||
@@ -331,7 +331,7 @@ AskUserQuestion({
|
||||
C1: Unit tests ─────────────► [new session]
|
||||
C2: Integration tests ──────► [resume]
|
||||
|
||||
📋 Task Decomposition:
|
||||
Task Decomposition:
|
||||
[Group A] 1. Create user model
|
||||
[Group A] 2. Add validation logic [resume]
|
||||
[Group A] 3. Implement database schema [resume]
|
||||
@@ -341,28 +341,28 @@ AskUserQuestion({
|
||||
[Group C] 7. Unit tests [new session]
|
||||
[Group C] 8. Integration tests [resume]
|
||||
|
||||
▶️ [Group A] Executing Subtask 1/8: Create user model
|
||||
[Group A] Executing Subtask 1/8: Create user model
|
||||
Starting new Codex session for Group A...
|
||||
[Codex output]
|
||||
✅ Subtask 1 completed
|
||||
Subtask 1 completed
|
||||
|
||||
🔍 Git Verification:
|
||||
Git Verification:
|
||||
M src/models/user.ts
|
||||
✅ Changes verified
|
||||
Changes verified
|
||||
|
||||
▶️ [Group A] Executing Subtask 2/8: Add validation logic
|
||||
[Group A] Executing Subtask 2/8: Add validation logic
|
||||
Resuming Codex session (same group)...
|
||||
[Codex output]
|
||||
✅ Subtask 2 completed
|
||||
Subtask 2 completed
|
||||
|
||||
▶️ [Group B] Executing Subtask 4/8: Create auth endpoints
|
||||
[Group B] Executing Subtask 4/8: Create auth endpoints
|
||||
Starting NEW Codex session for Group B...
|
||||
[Codex output]
|
||||
✅ Subtask 4 completed
|
||||
Subtask 4 completed
|
||||
...
|
||||
|
||||
✅ All Subtasks Completed
|
||||
📊 Summary: [file references, changes, next steps]
|
||||
All Subtasks Completed
|
||||
Summary: [file references, changes, next steps]
|
||||
```
|
||||
|
||||
**Final Summary**:
|
||||
@@ -370,8 +370,8 @@ AskUserQuestion({
|
||||
# Task Execution Summary: [Task Description]
|
||||
|
||||
## Subtasks Completed
|
||||
1. ✅ [Subtask 1]: [files modified]
|
||||
2. ✅ [Subtask 2]: [files modified]
|
||||
1. [Subtask 1]: [files modified]
|
||||
2. [Subtask 2]: [files modified]
|
||||
...
|
||||
|
||||
## Files Modified
|
||||
|
||||
@@ -279,11 +279,11 @@ Each round's output is structured as:
|
||||
|
||||
| Command | Models | Rounds | Discussion | Implementation | Use Case |
|
||||
|---------|--------|--------|------------|----------------|----------|
|
||||
| `/cli:mode:plan` | Gemini | 1 | ❌ NO | ❌ NO | Single-model planning |
|
||||
| `/cli:analyze` | Gemini/Qwen | 1 | ❌ NO | ❌ NO | Code analysis |
|
||||
| `/cli:execute` | Any | 1 | ❌ NO | ✅ YES | Direct implementation |
|
||||
| `/cli:codex-execute` | Codex | 1 | ❌ NO | ✅ YES | Multi-stage implementation |
|
||||
| `/cli:discuss-plan` | **Gemini+Codex+Claude** | **Multiple** | ✅ **YES** | ❌ **NO** | **Multi-perspective planning** |
|
||||
| `/cli:mode:plan` | Gemini | 1 | NO | NO | Single-model planning |
|
||||
| `/cli:analyze` | Gemini/Qwen | 1 | NO | NO | Code analysis |
|
||||
| `/cli:execute` | Any | 1 | NO | YES | Direct implementation |
|
||||
| `/cli:codex-execute` | Codex | 1 | NO | YES | Multi-stage implementation |
|
||||
| `/cli:discuss-plan` | **Gemini+Codex+Claude** | **Multiple** | **YES** | **NO** | **Multi-perspective planning** |
|
||||
|
||||
## Best Practices
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ Execute implementation tasks with **YOLO permissions** (auto-approves all confir
|
||||
### YOLO Permissions
|
||||
Auto-approves: file pattern inference, execution, **file modifications**, summary generation
|
||||
|
||||
**⚠️ WARNING**: This command will make actual code changes without manual confirmation
|
||||
**WARNING**: This command will make actual code changes without manual confirmation
|
||||
|
||||
### Execution Modes
|
||||
|
||||
@@ -158,14 +158,14 @@ The agent handles all phases internally, including complexity-based tool selecti
|
||||
|
||||
## Examples
|
||||
|
||||
**Basic Implementation (Standard Mode)** (⚠️ modifies code):
|
||||
**Basic Implementation (Standard Mode)** (modifies code):
|
||||
```bash
|
||||
/cli:execute "implement JWT authentication with middleware"
|
||||
# Executes: Creates auth middleware, updates routes, modifies config
|
||||
# Result: NEW/MODIFIED code files with JWT implementation
|
||||
```
|
||||
|
||||
**Intelligent Implementation (Agent Mode)** (⚠️ modifies code):
|
||||
**Intelligent Implementation (Agent Mode)** (modifies code):
|
||||
```bash
|
||||
/cli:execute --agent "implement OAuth2 authentication with token refresh"
|
||||
# Phase 1: Classifies intent=execute, complexity=complex, keywords=['oauth2', 'auth', 'token', 'refresh']
|
||||
@@ -176,7 +176,7 @@ The agent handles all phases internally, including complexity-based tool selecti
|
||||
# Result: Complete OAuth2 implementation + detailed execution log
|
||||
```
|
||||
|
||||
**Enhanced Implementation** (⚠️ modifies code):
|
||||
**Enhanced Implementation** (modifies code):
|
||||
```bash
|
||||
/cli:execute --enhance "implement JWT authentication"
|
||||
# Step 1: Enhance to expand requirements
|
||||
@@ -184,7 +184,7 @@ The agent handles all phases internally, including complexity-based tool selecti
|
||||
# Result: Complete auth system with MODIFIED code files
|
||||
```
|
||||
|
||||
**Task Execution** (⚠️ modifies code):
|
||||
**Task Execution** (modifies code):
|
||||
```bash
|
||||
/cli:execute IMPL-001
|
||||
# Reads: .task/IMPL-001.json for requirements
|
||||
@@ -192,14 +192,14 @@ The agent handles all phases internally, including complexity-based tool selecti
|
||||
# Result: Code changes per task definition
|
||||
```
|
||||
|
||||
**Codex Implementation** (⚠️ modifies code):
|
||||
**Codex Implementation** (modifies code):
|
||||
```bash
|
||||
/cli:execute --tool codex "optimize database queries"
|
||||
# Executes: Codex with full file access
|
||||
# Result: MODIFIED query code, new indexes, updated tests
|
||||
```
|
||||
|
||||
**Qwen Code Generation** (⚠️ modifies code):
|
||||
**Qwen Code Generation** (modifies code):
|
||||
```bash
|
||||
/cli:execute --tool qwen --enhance "refactor auth module"
|
||||
# Step 1: Enhanced refactoring plan
|
||||
@@ -211,11 +211,11 @@ The agent handles all phases internally, including complexity-based tool selecti
|
||||
|
||||
| Command | Intent | Code Changes | Auto-Approve |
|
||||
|---------|--------|--------------|--------------|
|
||||
| `/cli:analyze` | Understand code | ❌ NO | N/A |
|
||||
| `/cli:chat` | Ask questions | ❌ NO | N/A |
|
||||
| `/cli:execute` | **Implement** | ✅ **YES** | ✅ **YES** |
|
||||
| `/cli:analyze` | Understand code | NO | N/A |
|
||||
| `/cli:chat` | Ask questions | NO | N/A |
|
||||
| `/cli:execute` | **Implement** | **YES** | **YES** |
|
||||
|
||||
## Notes
|
||||
|
||||
- Command templates, YOLO mode details, and session management: see intelligent-tools-strategy.md (loaded in memory)
|
||||
- **⚠️ Code Modification**: This command modifies code - execution logs document changes made
|
||||
- **Code Modification**: This command modifies code - execution logs document changes made
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: load-skill-memory
|
||||
description: Manually activate specified SKILL package and load documentation based on task intent
|
||||
argument-hint: "<skill_name> \"task intent description\""
|
||||
description: Activate SKILL package (auto-detect or manual) and load documentation based on task intent
|
||||
argument-hint: "[skill_name] \"task intent description\""
|
||||
allowed-tools: Bash(*), Read(*), Skill(*)
|
||||
---
|
||||
|
||||
@@ -9,10 +9,10 @@ allowed-tools: Bash(*), Read(*), Skill(*)
|
||||
|
||||
## 1. Overview
|
||||
|
||||
The `memory:load-skill-memory` command **manually activates a specified SKILL package** and intelligently loads documentation based on user's task intent. The system automatically determines which documentation files to read based on the intent description.
|
||||
The `memory:load-skill-memory` command **activates SKILL package** (auto-detect from task or manual specification) and intelligently loads documentation based on user's task intent. The system automatically determines which documentation files to read based on the intent description.
|
||||
|
||||
**Core Philosophy**:
|
||||
- **Manual Activation**: User explicitly specifies which SKILL to activate
|
||||
- **Flexible Activation**: Auto-detect skill from task description/paths, or user explicitly specifies
|
||||
- **Intent-Driven Loading**: System analyzes task intent to determine documentation scope
|
||||
- **Intelligent Selection**: Automatically chooses appropriate documentation level and modules
|
||||
- **Direct Context Loading**: Loads selected documentation into conversation memory
|
||||
@@ -22,26 +22,42 @@ The `memory:load-skill-memory` command **manually activates a specified SKILL pa
|
||||
- Load SKILL context when system hasn't auto-triggered it
|
||||
- Force reload SKILL documentation with specific intent focus
|
||||
|
||||
**Note**: Normal SKILL activation happens automatically via description triggers. Use this command only when manual activation is needed.
|
||||
**Note**: Normal SKILL activation happens automatically via description triggers or path mentions (system extracts skill name from file paths for intelligent triggering). Use this command only when manual activation is needed.
|
||||
|
||||
## 2. Parameters
|
||||
|
||||
- `<skill_name>` (Required): Name of SKILL package to activate
|
||||
- Example: `hydro_generator_module`, `Claude_dms3`
|
||||
- `[skill_name]` (Optional): Name of SKILL package to activate
|
||||
- If omitted: System auto-detects from task description or file paths
|
||||
- If specified: Direct activation of named SKILL package
|
||||
- Example: `my_project`, `api_service`
|
||||
- Must match directory name under `.claude/skills/`
|
||||
|
||||
- `"task intent description"` (Required): Description of what you want to do
|
||||
- Used for both: auto-detection (if skill_name omitted) and documentation scope selection
|
||||
- **Analysis tasks**: "分析builder pattern实现", "理解参数系统架构"
|
||||
- **Modification tasks**: "修改workflow逻辑", "增强thermal template功能"
|
||||
- **Learning tasks**: "学习接口设计模式", "了解测试框架使用"
|
||||
- **With paths**: "修改D:\projects\my_project\src\auth.py的认证逻辑" (auto-extracts `my_project`)
|
||||
|
||||
## 3. Execution Flow
|
||||
|
||||
### Step 1: Activate SKILL and Analyze Intent
|
||||
### Step 1: Determine SKILL Name (if not provided)
|
||||
|
||||
**Auto-Detection Strategy** (when skill_name parameter is omitted):
|
||||
1. **Path Extraction**: Scan task description for file paths
|
||||
- Extract potential project names from path segments
|
||||
- Example: `"修改D:\projects\my_project\src\auth.py"` → extracts `my_project`
|
||||
2. **Keyword Matching**: Match task keywords against SKILL descriptions
|
||||
- Search for project-specific terms, domain keywords
|
||||
3. **Validation**: Check if extracted name matches `.claude/skills/{skill_name}/`
|
||||
|
||||
**Result**: Either uses provided skill_name or auto-detected name for activation
|
||||
|
||||
### Step 2: Activate SKILL and Analyze Intent
|
||||
|
||||
**Activate SKILL Package**:
|
||||
```javascript
|
||||
Skill(command: "${skill_name}")
|
||||
Skill(command: "${skill_name}") // Uses provided or auto-detected name
|
||||
```
|
||||
|
||||
**What Happens After Activation**:
|
||||
@@ -57,7 +73,7 @@ Based on task intent description, system determines:
|
||||
- **Scope**: specific module, architecture overview, complete system
|
||||
- **Depth**: quick reference, detailed API, full documentation
|
||||
|
||||
### Step 2: Intelligent Documentation Loading
|
||||
### Step 3: Intelligent Documentation Loading
|
||||
|
||||
**Loading Strategy**:
|
||||
|
||||
@@ -86,7 +102,9 @@ The system automatically selects documentation based on intent keywords:
|
||||
**Documentation Loaded into Memory**:
|
||||
After loading, the selected documentation content is available in conversation memory for subsequent operations.
|
||||
|
||||
## 4. Usage Example
|
||||
## 4. Usage Examples
|
||||
|
||||
### Example 1: Manual Specification
|
||||
|
||||
**User Command**:
|
||||
```bash
|
||||
@@ -95,20 +113,52 @@ After loading, the selected documentation content is available in conversation m
|
||||
|
||||
**Execution**:
|
||||
```javascript
|
||||
// Step 1: Activate SKILL
|
||||
// Step 1: Use provided skill_name
|
||||
skill_name = "my_project" // Directly from parameter
|
||||
|
||||
// Step 2: Activate SKILL
|
||||
Skill(command: "my_project")
|
||||
|
||||
// Intent Analysis
|
||||
// Step 3: Intent Analysis
|
||||
Keywords: ["修改", "认证模块", "增加", "OAuth"]
|
||||
Action: modifying (implementation)
|
||||
Scope: auth module + examples
|
||||
|
||||
// Step 2: Load documentation based on intent
|
||||
// Load documentation based on intent
|
||||
Read(.workflow/docs/my_project/auth/README.md)
|
||||
Read(.workflow/docs/my_project/auth/API.md)
|
||||
Read(.workflow/docs/my_project/EXAMPLES.md)
|
||||
```
|
||||
|
||||
### Example 2: Auto-Detection from Path
|
||||
|
||||
**User Command**:
|
||||
```bash
|
||||
/memory:load-skill-memory "修改D:\projects\my_project\src\services\api.py的接口逻辑"
|
||||
```
|
||||
|
||||
**Execution**:
|
||||
```javascript
|
||||
// Step 1: Auto-detect skill_name from path
|
||||
Path detected: "D:\projects\my_project\src\services\api.py"
|
||||
Extracted: "my_project"
|
||||
Validated: .claude/skills/my_project/ exists ✓
|
||||
skill_name = "my_project"
|
||||
|
||||
// Step 2: Activate SKILL
|
||||
Skill(command: "my_project")
|
||||
|
||||
// Step 3: Intent Analysis
|
||||
Keywords: ["修改", "services", "接口逻辑"]
|
||||
Action: modifying (implementation)
|
||||
Scope: services module + examples
|
||||
|
||||
// Load documentation based on intent
|
||||
Read(.workflow/docs/my_project/services/README.md)
|
||||
Read(.workflow/docs/my_project/services/API.md)
|
||||
Read(.workflow/docs/my_project/EXAMPLES.md)
|
||||
```
|
||||
|
||||
## 5. Intent Keyword Mapping
|
||||
|
||||
**Quick Reference**:
|
||||
|
||||
@@ -9,38 +9,26 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Bash(*), Read(*), Write(*)
|
||||
|
||||
## Orchestrator Role
|
||||
|
||||
**This command is a pure orchestrator**: Execute documentation generation workflow, then generate SKILL.md index. Does NOT create task JSON files.
|
||||
**Pure Orchestrator**: Execute documentation generation workflow, then generate SKILL.md index. Does NOT create task JSON files.
|
||||
|
||||
**Execution Model - Auto-Continue Workflow**:
|
||||
**Auto-Continue Workflow**: This command runs **fully autonomously** once triggered. Each phase completes and automatically triggers the next phase without user interaction.
|
||||
|
||||
This workflow runs **fully autonomously** once triggered. Each phase completes and automatically triggers the next phase.
|
||||
|
||||
1. **User triggers**: `/memory:skill-memory [path] [options]`
|
||||
2. **Phase 1 executes** → Parse arguments and prepare → Auto-continues
|
||||
3. **Phase 2 executes** → Call `/memory:docs` to plan documentation → Auto-continues
|
||||
4. **Phase 3 executes** → Call `/workflow:execute` to generate docs → Auto-continues
|
||||
5. **Phase 4 executes** → Generate SKILL.md index → Reports completion
|
||||
|
||||
**Auto-Continue Mechanism**:
|
||||
- TodoList tracks current phase status (in_progress/completed)
|
||||
- After each phase completion, check TodoList and automatically execute next pending phase
|
||||
- All phases run autonomously without user interaction
|
||||
- Progress updates shown at each phase for visibility
|
||||
- Each phase MUST update TodoWrite before triggering next phase
|
||||
**Execution Paths**:
|
||||
- **Full Path**: All 4 phases (no existing docs OR `--regenerate` specified)
|
||||
- **Skip Path**: Phase 1 → Phase 4 (existing docs found AND no `--regenerate` flag)
|
||||
- **Phase 4 Always Executes**: SKILL.md index is never skipped, always generated or updated
|
||||
|
||||
## Core Rules
|
||||
|
||||
1. **Start Immediately**: First action is TodoWrite initialization, second action is Phase 1 execution
|
||||
2. **No Task JSON**: This command does not create task JSON files - delegates to /memory:docs
|
||||
3. **Parse Every Output**: Extract required data from each command output (session_id, task_count, file paths)
|
||||
4. **Auto-Continue via TodoList**: After completing each phase:
|
||||
- Update TodoWrite to mark current phase completed
|
||||
- Mark next phase as in_progress
|
||||
- Immediately execute next phase (no waiting for user input)
|
||||
- Check TodoList to identify next pending phase automatically
|
||||
4. **Auto-Continue**: After completing each phase, update TodoWrite and immediately execute next phase
|
||||
5. **Track Progress**: Update TodoWrite after EVERY phase completion before starting next phase
|
||||
6. **Direct Generation**: Phase 4 directly generates SKILL.md using Write tool
|
||||
7. **No Manual Steps**: User should never be prompted for decisions between phases - fully autonomous execution
|
||||
7. **No Manual Steps**: User should never be prompted for decisions between phases
|
||||
|
||||
---
|
||||
|
||||
## 4-Phase Execution
|
||||
|
||||
@@ -76,7 +64,7 @@ bash(git rev-parse --show-toplevel 2>/dev/null || pwd)
|
||||
|
||||
**Step 3: Check Existing Documentation**
|
||||
```bash
|
||||
# Check if docs directory exists (replace project_name with actual value)
|
||||
# Check if docs directory exists
|
||||
bash(test -d .workflow/docs/my_project && echo "exists" || echo "not_exists")
|
||||
|
||||
# Count existing documentation files
|
||||
@@ -107,7 +95,7 @@ if (existing_docs > 0 && !regenerate_flag) {
|
||||
}
|
||||
```
|
||||
|
||||
**Summary**:
|
||||
**Summary Variables**:
|
||||
- `PROJECT_NAME`: `my_project`
|
||||
- `TARGET_PATH`: `/d/my_project`
|
||||
- `DOCS_PATH`: `.workflow/docs/my_project`
|
||||
@@ -118,26 +106,19 @@ if (existing_docs > 0 && !regenerate_flag) {
|
||||
- `EXISTING_DOCS`: Count of existing documentation files
|
||||
- `SKIP_DOCS_GENERATION`: `true` if skipping Phase 2/3, `false` otherwise
|
||||
|
||||
**Completion Criteria**:
|
||||
- All parameters extracted and validated
|
||||
- Project name and paths confirmed
|
||||
- Existing docs count retrieved
|
||||
- Skip decision determined (SKIP_DOCS_GENERATION)
|
||||
- Default values set for unspecified parameters
|
||||
|
||||
**TodoWrite**:
|
||||
- If `SKIP_DOCS_GENERATION = true`: Mark phase 1 completed, phase 4 in_progress (skip phase 2 and 3)
|
||||
**Completion & TodoWrite**:
|
||||
- If `SKIP_DOCS_GENERATION = true`: Mark phase 1 completed, phase 2&3 completed (skipped), phase 4 in_progress
|
||||
- If `SKIP_DOCS_GENERATION = false`: Mark phase 1 completed, phase 2 in_progress
|
||||
|
||||
**After Phase 1**:
|
||||
- If skipping: Display skip message → **Jump to Phase 4** (SKILL.md generation)
|
||||
- If not skipping: Display preparation results → **Continue to Phase 2** (documentation planning)
|
||||
**Next Action**:
|
||||
- If skipping: Display skip message → Jump to Phase 4 (SKILL.md generation)
|
||||
- If not skipping: Display preparation results → Continue to Phase 2 (documentation planning)
|
||||
|
||||
---
|
||||
|
||||
### Phase 2: Call /memory:docs
|
||||
|
||||
**Note**: This phase is **skipped if SKIP_DOCS_GENERATION = true** (documentation already exists without --regenerate flag)
|
||||
**Skip Condition**: This phase is **skipped if SKIP_DOCS_GENERATION = true** (documentation already exists without --regenerate flag)
|
||||
|
||||
**Goal**: Trigger documentation generation workflow
|
||||
|
||||
@@ -154,32 +135,26 @@ SlashCommand(command="/memory:docs [targetPath] --tool [tool] --mode [mode] [--c
|
||||
|
||||
**Note**: The `--regenerate` flag is handled in Phase 1 by deleting existing documentation. This command always calls `/memory:docs` without the regenerate flag, relying on docs.md's built-in update detection.
|
||||
|
||||
**Input**:
|
||||
- `targetPath` from Phase 1
|
||||
- `tool` from Phase 1
|
||||
- `mode` from Phase 1
|
||||
- `cli_execute` from Phase 1 (optional)
|
||||
|
||||
**Parse Output**:
|
||||
- Extract session ID pattern: `WFS-docs-[timestamp]` (store as `docsSessionId`)
|
||||
- Extract session ID: `WFS-docs-[timestamp]` (store as `docsSessionId`)
|
||||
- Extract task count (store as `taskCount`)
|
||||
|
||||
**Completion Criteria**:
|
||||
- `/memory:docs` command executed successfully
|
||||
- Session ID extracted: `WFS-docs-[timestamp]`
|
||||
- Task count retrieved from output
|
||||
- Session ID extracted and stored
|
||||
- Task count retrieved
|
||||
- Task files created in `.workflow/[docsSessionId]/.task/`
|
||||
- workflow-session.json exists in session directory
|
||||
- workflow-session.json exists
|
||||
|
||||
**TodoWrite**: Mark phase 2 completed, phase 3 in_progress
|
||||
|
||||
**After Phase 2**: Display docs planning results (session ID, task count) → **Automatically continue to Phase 3** (no user input required)
|
||||
**Next Action**: Display docs planning results (session ID, task count) → Auto-continue to Phase 3
|
||||
|
||||
---
|
||||
|
||||
### Phase 3: Execute Documentation Generation
|
||||
|
||||
**Note**: This phase is **skipped if SKIP_DOCS_GENERATION = true** (documentation already exists without --regenerate flag)
|
||||
**Skip Condition**: This phase is **skipped if SKIP_DOCS_GENERATION = true** (documentation already exists without --regenerate flag)
|
||||
|
||||
**Goal**: Execute documentation generation tasks
|
||||
|
||||
@@ -194,17 +169,19 @@ SlashCommand(command="/workflow:execute")
|
||||
- `/workflow:execute` command executed successfully
|
||||
- Documentation files generated in `.workflow/docs/[projectName]/`
|
||||
- All tasks marked as completed in session
|
||||
- At minimum, module documentation files exist (API.md and/or README.md)
|
||||
- At minimum: module documentation files exist (API.md and/or README.md)
|
||||
- For full mode: Project README, ARCHITECTURE, EXAMPLES files generated
|
||||
|
||||
**TodoWrite**: Mark phase 3 completed, phase 4 in_progress
|
||||
|
||||
**After Phase 3**: Display execution results (file count, module count) → **Automatically continue to Phase 4** (no user input required)
|
||||
**Next Action**: Display execution results (file count, module count) → Auto-continue to Phase 4
|
||||
|
||||
---
|
||||
|
||||
### Phase 4: Generate SKILL.md Index
|
||||
|
||||
**Note**: This phase is **NEVER skipped** - it always executes to generate or update the SKILL index.
|
||||
|
||||
**Step 1: Read Key Files** (Use Read tool)
|
||||
- `.workflow/docs/{project_name}/README.md` (required)
|
||||
- `.workflow/docs/{project_name}/ARCHITECTURE.md` (optional)
|
||||
@@ -220,14 +197,11 @@ Extract from README + structure: Function (capabilities), Modules (names), Keywo
|
||||
|
||||
**Format**: `{Project} {core capabilities} (located at {project_path}). Load this SKILL when analyzing, modifying, or learning about {domain_description} or files under this path, especially when no relevant context exists in memory.`
|
||||
|
||||
**Path Reference**: Use `TARGET_PATH` from Phase 1 for precise location identification.
|
||||
|
||||
**Domain Description**: Extract human-readable domain/feature area from README (e.g., "workflow management", "thermal modeling"), NOT the technical project_name.
|
||||
|
||||
**Trigger Optimization**:
|
||||
- Include project path to improve triggering when users mention specific directories or file locations
|
||||
- Emphasize "especially when no relevant context exists in memory" to prioritize SKILL as primary context source
|
||||
- Cover three key actions: analyzing (分析), modifying (修改), learning (了解)
|
||||
**Key Elements**:
|
||||
- **Path Reference**: Use `TARGET_PATH` from Phase 1 for precise location identification
|
||||
- **Domain Description**: Extract human-readable domain/feature area from README (e.g., "workflow management", "thermal modeling")
|
||||
- **Trigger Optimization**: Include project path, emphasize "especially when no relevant context exists in memory"
|
||||
- **Action Coverage**: analyzing (分析), modifying (修改), learning (了解)
|
||||
|
||||
**Example**: "Workflow orchestration system with CLI tools and documentation generation (located at /d/Claude_dms3). Load this SKILL when analyzing, modifying, or learning about workflow management or files under this path, especially when no relevant context exists in memory."
|
||||
|
||||
@@ -267,11 +241,11 @@ Everything + [Examples](../../../.workflow/docs/{project_name}/EXAMPLES.md)
|
||||
|
||||
**TodoWrite**: Mark phase 4 completed
|
||||
|
||||
**After Phase 4**: Workflow complete → **Report final summary to user**
|
||||
**Final Action**: Report completion summary to user
|
||||
|
||||
**Return to User**:
|
||||
```
|
||||
✅ SKILL Package Generation Complete
|
||||
SKILL Package Generation Complete
|
||||
|
||||
Project: {project_name}
|
||||
Documentation: .workflow/docs/{project_name}/ ({doc_count} files)
|
||||
@@ -291,108 +265,9 @@ Usage:
|
||||
|
||||
---
|
||||
|
||||
## TodoWrite Pattern
|
||||
## Implementation Details
|
||||
|
||||
**Auto-Continue Logic**: After updating TodoWrite at end of each phase, immediately check for next pending task and execute it.
|
||||
|
||||
**Two Execution Paths**:
|
||||
1. **Full Path**: All 4 phases (no existing docs or --regenerate specified)
|
||||
2. **Skip Path**: Phase 1 → Phase 4 (existing docs found, no --regenerate)
|
||||
|
||||
### Full Path (SKIP_DOCS_GENERATION = false)
|
||||
|
||||
```javascript
|
||||
// Initialize (before Phase 1)
|
||||
// FIRST ACTION: Create TodoList with all 4 phases
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "in_progress", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "pending", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "pending", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "pending", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// SECOND ACTION: Execute Phase 1 immediately
|
||||
|
||||
// After Phase 1 completes (SKIP_DOCS_GENERATION = false)
|
||||
// Update TodoWrite: Mark Phase 1 completed, Phase 2 in_progress
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "in_progress", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "pending", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "pending", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// NEXT ACTION: Auto-continue to Phase 2 (execute /memory:docs command)
|
||||
|
||||
// After Phase 2 completes
|
||||
// Update TodoWrite: Mark Phase 2 completed, Phase 3 in_progress
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "completed", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "in_progress", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "pending", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// NEXT ACTION: Auto-continue to Phase 3 (execute /workflow:execute command)
|
||||
|
||||
// After Phase 3 completes
|
||||
// Update TodoWrite: Mark Phase 3 completed, Phase 4 in_progress
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "completed", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "completed", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "in_progress", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// NEXT ACTION: Auto-continue to Phase 4 (generate SKILL.md)
|
||||
|
||||
// After Phase 4 completes
|
||||
// Update TodoWrite: Mark Phase 4 completed
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "completed", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "completed", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "completed", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// FINAL ACTION: Report completion summary to user
|
||||
```
|
||||
|
||||
### Skip Path (SKIP_DOCS_GENERATION = true)
|
||||
|
||||
**Note**: Phase 4 (SKILL.md generation) is **NEVER skipped** - it always runs to generate or update the SKILL index.
|
||||
|
||||
```javascript
|
||||
// Initialize (before Phase 1)
|
||||
// FIRST ACTION: Create TodoList with all 4 phases (same as Full Path)
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "in_progress", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "pending", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "pending", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "pending", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// SECOND ACTION: Execute Phase 1 immediately
|
||||
|
||||
// After Phase 1 completes (SKIP_DOCS_GENERATION = true)
|
||||
// Update TodoWrite: Mark Phase 1 completed, Phase 2&3 skipped, Phase 4 in_progress
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "completed", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "completed", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "in_progress", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// Display skip message: "Documentation already exists, skipping Phase 2 and Phase 3. Use --regenerate to force regeneration."
|
||||
// NEXT ACTION: Jump directly to Phase 4 (generate SKILL.md)
|
||||
|
||||
// After Phase 4 completes
|
||||
// Update TodoWrite: Mark Phase 4 completed
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "completed", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "completed", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "completed", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// FINAL ACTION: Report completion summary to user
|
||||
```
|
||||
|
||||
## Auto-Continue Execution Flow
|
||||
|
||||
**Critical Implementation Rules**:
|
||||
### Critical Rules
|
||||
|
||||
1. **No User Prompts Between Phases**: Never ask user questions or wait for input between phases
|
||||
2. **Immediate Phase Transition**: After TodoWrite update, immediately execute next phase command
|
||||
@@ -404,9 +279,96 @@ TodoWrite({todos: [
|
||||
Phase N completes → Update TodoWrite (N=completed, N+1=in_progress) → Execute Phase N+1
|
||||
```
|
||||
|
||||
**Execution Sequence**:
|
||||
### TodoWrite Patterns
|
||||
|
||||
**Full Path** (no existing docs OR --regenerate specified):
|
||||
#### Initialization (Before Phase 1)
|
||||
|
||||
**FIRST ACTION**: Create TodoList with all 4 phases
|
||||
```javascript
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "in_progress", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "pending", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "pending", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "pending", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
```
|
||||
|
||||
**SECOND ACTION**: Execute Phase 1 immediately
|
||||
|
||||
#### Full Path (SKIP_DOCS_GENERATION = false)
|
||||
|
||||
**After Phase 1**:
|
||||
```javascript
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "in_progress", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "pending", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "pending", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// Auto-continue to Phase 2
|
||||
```
|
||||
|
||||
**After Phase 2**:
|
||||
```javascript
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "completed", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "in_progress", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "pending", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// Auto-continue to Phase 3
|
||||
```
|
||||
|
||||
**After Phase 3**:
|
||||
```javascript
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "completed", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "completed", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "in_progress", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// Auto-continue to Phase 4
|
||||
```
|
||||
|
||||
**After Phase 4**:
|
||||
```javascript
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "completed", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "completed", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "completed", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// Report completion summary to user
|
||||
```
|
||||
|
||||
#### Skip Path (SKIP_DOCS_GENERATION = true)
|
||||
|
||||
**After Phase 1** (detects existing docs, skips Phase 2 & 3):
|
||||
```javascript
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "completed", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "completed", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "in_progress", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// Display skip message: "Documentation already exists, skipping Phase 2 and Phase 3. Use --regenerate to force regeneration."
|
||||
// Jump directly to Phase 4
|
||||
```
|
||||
|
||||
**After Phase 4**:
|
||||
```javascript
|
||||
TodoWrite({todos: [
|
||||
{"content": "Parse arguments and prepare", "status": "completed", "activeForm": "Parsing arguments"},
|
||||
{"content": "Call /memory:docs to plan documentation", "status": "completed", "activeForm": "Calling /memory:docs"},
|
||||
{"content": "Execute documentation generation", "status": "completed", "activeForm": "Executing documentation"},
|
||||
{"content": "Generate SKILL.md index", "status": "completed", "activeForm": "Generating SKILL.md"}
|
||||
]})
|
||||
// Report completion summary to user
|
||||
```
|
||||
|
||||
### Execution Flow Diagrams
|
||||
|
||||
#### Full Path Flow
|
||||
```
|
||||
User triggers command
|
||||
↓
|
||||
@@ -431,7 +393,7 @@ User triggers command
|
||||
[Report] Display completion summary
|
||||
```
|
||||
|
||||
**Skip Path** (existing docs found AND no --regenerate flag):
|
||||
#### Skip Path Flow
|
||||
```
|
||||
User triggers command
|
||||
↓
|
||||
@@ -450,9 +412,8 @@ User triggers command
|
||||
[Report] Display completion summary
|
||||
```
|
||||
|
||||
**Note**: Phase 4 (SKILL.md generation) is **NEVER skipped** - it always executes to generate or update the index file.
|
||||
### Error Handling
|
||||
|
||||
**Error Handling**:
|
||||
- If any phase fails, mark it as "in_progress" (not completed)
|
||||
- Report error details to user
|
||||
- Do NOT auto-continue to next phase on failure
|
||||
@@ -480,6 +441,8 @@ User triggers command
|
||||
- When enabled: CLI generates docs directly in implementation_approach
|
||||
- When disabled (default): Agent generates documentation content
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Generate SKILL Package (Default)
|
||||
@@ -530,24 +493,42 @@ User triggers command
|
||||
3. Phase 3: Executes CLI-based documentation generation
|
||||
4. Phase 4: Generates SKILL.md at `.claude/skills/{project_name}/SKILL.md`
|
||||
|
||||
### Example 5: Skip Path (Existing Docs)
|
||||
|
||||
```bash
|
||||
/memory:skill-memory
|
||||
```
|
||||
|
||||
**Scenario**: Documentation already exists in `.workflow/docs/{project_name}/`
|
||||
|
||||
**Workflow**:
|
||||
1. Phase 1: Detects existing docs (5 files), sets SKIP_DOCS_GENERATION = true
|
||||
2. Display: "Documentation already exists, skipping Phase 2 and Phase 3. Use --regenerate to force regeneration."
|
||||
3. Phase 4: Generates or updates SKILL.md index only (~5-10x faster)
|
||||
|
||||
---
|
||||
|
||||
## Benefits
|
||||
|
||||
- ✅ **Pure Orchestrator**: No task JSON generation, delegates to /memory:docs
|
||||
- ✅ **Auto-Continue**: Autonomous 4-phase execution
|
||||
- ✅ **Simplified**: ~70% less code than previous version
|
||||
- ✅ **Maintainable**: Changes to /memory:docs automatically apply
|
||||
- ✅ **Direct Generation**: Phase 4 directly writes SKILL.md
|
||||
- ✅ **Flexible**: Supports all /memory:docs options
|
||||
- **Pure Orchestrator**: No task JSON generation, delegates to /memory:docs
|
||||
- **Auto-Continue**: Autonomous 4-phase execution without user interaction
|
||||
- **Intelligent Skip**: Detects existing docs and skips regeneration for fast SKILL updates
|
||||
- **Always Fresh Index**: Phase 4 always executes to ensure SKILL.md stays synchronized
|
||||
- **Simplified**: ~70% less code than previous version
|
||||
- **Maintainable**: Changes to /memory:docs automatically apply
|
||||
- **Direct Generation**: Phase 4 directly writes SKILL.md
|
||||
- **Flexible**: Supports all /memory:docs options (tool, mode, cli-execute)
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
skill-memory (orchestrator)
|
||||
├─ Phase 1: Prepare (bash commands)
|
||||
├─ Phase 2: /memory:docs (task planning)
|
||||
├─ Phase 3: /workflow:execute (task execution)
|
||||
└─ Phase 4: Write SKILL.md (direct file generation)
|
||||
├─ Phase 1: Prepare (bash commands, skip decision)
|
||||
├─ Phase 2: /memory:docs (task planning, skippable)
|
||||
├─ Phase 3: /workflow:execute (task execution, skippable)
|
||||
└─ Phase 4: Write SKILL.md (direct file generation, always runs)
|
||||
|
||||
No task JSON created by this command
|
||||
All documentation tasks managed by /memory:docs
|
||||
Smart skip logic: 5-10x faster when docs exist
|
||||
```
|
||||
|
||||
477
.claude/commands/memory/tech-research.md
Normal file
477
.claude/commands/memory/tech-research.md
Normal file
@@ -0,0 +1,477 @@
|
||||
---
|
||||
name: tech-research
|
||||
description: Generate tech stack SKILL packages using Exa research via agent delegation
|
||||
argument-hint: "[session-id | tech-stack-name] [--regenerate] [--tool <gemini|qwen>]"
|
||||
allowed-tools: SlashCommand(*), TodoWrite(*), Bash(*), Read(*), Write(*), Task(*)
|
||||
---
|
||||
|
||||
# Tech Stack Research SKILL Generator
|
||||
|
||||
## Overview
|
||||
|
||||
**Pure Orchestrator with Agent Delegation**: Prepares context paths and delegates ALL work to agent. Agent produces files directly.
|
||||
|
||||
**Auto-Continue Workflow**: Runs fully autonomously once triggered. Each phase completes and automatically triggers the next phase.
|
||||
|
||||
**Execution Paths**:
|
||||
- **Full Path**: All 3 phases (no existing SKILL OR `--regenerate` specified)
|
||||
- **Skip Path**: Phase 1 → Phase 3 (existing SKILL found AND no `--regenerate` flag)
|
||||
- **Phase 3 Always Executes**: SKILL index is always generated or updated
|
||||
|
||||
**Agent Responsibility**:
|
||||
- Agent does ALL the work: context reading, Exa research, content synthesis, file writing
|
||||
- Orchestrator only provides context paths and waits for completion
|
||||
|
||||
## Core Rules
|
||||
|
||||
1. **Start Immediately**: First action is TodoWrite initialization, second action is Phase 1 execution
|
||||
2. **Context Path Delegation**: Pass session directory or tech stack name to agent, let agent do discovery
|
||||
3. **Agent Produces Files**: Agent directly writes all module files, orchestrator does NOT parse agent output
|
||||
4. **Auto-Continue**: After completing each phase, update TodoWrite and immediately execute next phase
|
||||
5. **No User Prompts**: Never ask user questions or wait for input between phases
|
||||
6. **Track Progress**: Update TodoWrite after EVERY phase completion before starting next phase
|
||||
7. **Lightweight Index**: Phase 3 only generates SKILL.md index by reading existing files
|
||||
|
||||
---
|
||||
|
||||
## 3-Phase Execution
|
||||
|
||||
### Phase 1: Prepare Context Paths
|
||||
|
||||
**Goal**: Detect input mode, prepare context paths for agent, check existing SKILL
|
||||
|
||||
**Input Mode Detection**:
|
||||
```bash
|
||||
# Get input parameter
|
||||
input="$1"
|
||||
|
||||
# Detect mode
|
||||
if [[ "$input" == WFS-* ]]; then
|
||||
MODE="session"
|
||||
SESSION_ID="$input"
|
||||
CONTEXT_PATH=".workflow/${SESSION_ID}"
|
||||
else
|
||||
MODE="direct"
|
||||
TECH_STACK_NAME="$input"
|
||||
CONTEXT_PATH="$input" # Pass tech stack name as context
|
||||
fi
|
||||
```
|
||||
|
||||
**Check Existing SKILL**:
|
||||
```bash
|
||||
# For session mode, peek at session to get tech stack name
|
||||
if [[ "$MODE" == "session" ]]; then
|
||||
bash(test -f ".workflow/${SESSION_ID}/workflow-session.json")
|
||||
Read(.workflow/${SESSION_ID}/workflow-session.json)
|
||||
# Extract tech_stack_name (minimal extraction)
|
||||
fi
|
||||
|
||||
# Normalize and check
|
||||
normalized_name=$(echo "$TECH_STACK_NAME" | tr '[:upper:]' '[:lower:]' | tr ' ' '-')
|
||||
bash(test -d ".claude/skills/${normalized_name}" && echo "exists" || echo "not_exists")
|
||||
bash(find ".claude/skills/${normalized_name}" -name "*.md" 2>/dev/null | wc -l || echo 0)
|
||||
```
|
||||
|
||||
**Skip Decision**:
|
||||
```javascript
|
||||
if (existing_files > 0 && !regenerate_flag) {
|
||||
SKIP_GENERATION = true
|
||||
message = "Tech stack SKILL already exists, skipping Phase 2. Use --regenerate to force regeneration."
|
||||
} else if (regenerate_flag) {
|
||||
bash(rm -rf ".claude/skills/${normalized_name}")
|
||||
SKIP_GENERATION = false
|
||||
message = "Regenerating tech stack SKILL from scratch."
|
||||
} else {
|
||||
SKIP_GENERATION = false
|
||||
message = "No existing SKILL found, generating new tech stack documentation."
|
||||
}
|
||||
```
|
||||
|
||||
**Output Variables**:
|
||||
- `MODE`: `session` or `direct`
|
||||
- `SESSION_ID`: Session ID (if session mode)
|
||||
- `CONTEXT_PATH`: Path to session directory OR tech stack name
|
||||
- `TECH_STACK_NAME`: Extracted or provided tech stack name
|
||||
- `SKIP_GENERATION`: Boolean - whether to skip Phase 2
|
||||
|
||||
**TodoWrite**:
|
||||
- If skipping: Mark phase 1 completed, phase 2 completed, phase 3 in_progress
|
||||
- If not skipping: Mark phase 1 completed, phase 2 in_progress
|
||||
|
||||
---
|
||||
|
||||
### Phase 2: Agent Produces All Files
|
||||
|
||||
**Skip Condition**: Skipped if `SKIP_GENERATION = true`
|
||||
|
||||
**Goal**: Delegate EVERYTHING to agent - context reading, Exa research, content synthesis, and file writing
|
||||
|
||||
**Agent Task Specification**:
|
||||
|
||||
```
|
||||
Task(
|
||||
subagent_type: "general-purpose",
|
||||
description: "Generate tech stack SKILL: {CONTEXT_PATH}",
|
||||
prompt: "
|
||||
Generate a complete tech stack SKILL package with Exa research.
|
||||
|
||||
**Context Provided**:
|
||||
- Mode: {MODE}
|
||||
- Context Path: {CONTEXT_PATH}
|
||||
|
||||
**Templates Available**:
|
||||
- Module Format: ~/.claude/workflows/cli-templates/prompts/tech/tech-module-format.txt
|
||||
- SKILL Index: ~/.claude/workflows/cli-templates/prompts/tech/tech-skill-index.txt
|
||||
|
||||
**Your Responsibilities**:
|
||||
|
||||
1. **Extract Tech Stack Information**:
|
||||
|
||||
IF MODE == 'session':
|
||||
- Read `.workflow/{SESSION_ID}/workflow-session.json`
|
||||
- Read `.workflow/{SESSION_ID}/.process/context-package.json`
|
||||
- Extract tech_stack: {language, frameworks, libraries}
|
||||
- Build tech stack name: \"{language}-{framework1}-{framework2}\"
|
||||
- Example: \"typescript-react-nextjs\"
|
||||
|
||||
IF MODE == 'direct':
|
||||
- Tech stack name = CONTEXT_PATH
|
||||
- Parse composite: split by '-' delimiter
|
||||
- Example: \"typescript-react-nextjs\" → [\"typescript\", \"react\", \"nextjs\"]
|
||||
|
||||
2. **Execute Exa Research** (4-6 parallel queries):
|
||||
|
||||
Base Queries (always execute):
|
||||
- mcp__exa__get_code_context_exa(query: \"{tech} core principles best practices 2025\", tokensNum: 8000)
|
||||
- mcp__exa__get_code_context_exa(query: \"{tech} common patterns architecture examples\", tokensNum: 7000)
|
||||
- mcp__exa__web_search_exa(query: \"{tech} configuration setup tooling 2025\", numResults: 5)
|
||||
- mcp__exa__get_code_context_exa(query: \"{tech} testing strategies\", tokensNum: 5000)
|
||||
|
||||
Component Queries (if composite):
|
||||
- For each additional component:
|
||||
mcp__exa__get_code_context_exa(query: \"{main_tech} {component} integration\", tokensNum: 5000)
|
||||
|
||||
3. **Read Module Format Template**:
|
||||
|
||||
Read template for structure guidance:
|
||||
```bash
|
||||
Read(~/.claude/workflows/cli-templates/prompts/tech/tech-module-format.txt)
|
||||
```
|
||||
|
||||
4. **Synthesize Content into 6 Modules**:
|
||||
|
||||
Follow template structure from tech-module-format.txt:
|
||||
- **principles.md** - Core concepts, philosophies (~3K tokens)
|
||||
- **patterns.md** - Implementation patterns with code examples (~5K tokens)
|
||||
- **practices.md** - Best practices, anti-patterns, pitfalls (~4K tokens)
|
||||
- **testing.md** - Testing strategies, frameworks (~3K tokens)
|
||||
- **config.md** - Setup, configuration, tooling (~3K tokens)
|
||||
- **frameworks.md** - Framework integration (only if composite, ~4K tokens)
|
||||
|
||||
Each module follows template format:
|
||||
- Frontmatter (YAML)
|
||||
- Main sections with clear headings
|
||||
- Code examples from Exa research
|
||||
- Best practices sections
|
||||
- References to Exa sources
|
||||
|
||||
5. **Write Files Directly**:
|
||||
|
||||
```javascript
|
||||
// Create directory
|
||||
bash(mkdir -p \".claude/skills/{tech_stack_name}\")
|
||||
|
||||
// Write each module file using Write tool
|
||||
Write({ file_path: \".claude/skills/{tech_stack_name}/principles.md\", content: ... })
|
||||
Write({ file_path: \".claude/skills/{tech_stack_name}/patterns.md\", content: ... })
|
||||
Write({ file_path: \".claude/skills/{tech_stack_name}/practices.md\", content: ... })
|
||||
Write({ file_path: \".claude/skills/{tech_stack_name}/testing.md\", content: ... })
|
||||
Write({ file_path: \".claude/skills/{tech_stack_name}/config.md\", content: ... })
|
||||
// Write frameworks.md only if composite
|
||||
|
||||
// Write metadata.json
|
||||
Write({
|
||||
file_path: \".claude/skills/{tech_stack_name}/metadata.json\",
|
||||
content: JSON.stringify({
|
||||
tech_stack_name,
|
||||
components,
|
||||
is_composite,
|
||||
generated_at: timestamp,
|
||||
source: \"exa-research\",
|
||||
research_summary: { total_queries, total_sources }
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
6. **Report Completion**:
|
||||
|
||||
Provide summary:
|
||||
- Tech stack name
|
||||
- Files created (count)
|
||||
- Exa queries executed
|
||||
- Sources consulted
|
||||
|
||||
**CRITICAL**:
|
||||
- MUST read external template files before generating content (step 3 for modules, step 4 for index)
|
||||
- You have FULL autonomy - read files, execute Exa, synthesize content, write files
|
||||
- Do NOT return JSON or structured data - produce actual .md files
|
||||
- Handle errors gracefully (Exa failures, missing files, template read failures)
|
||||
- If tech stack cannot be determined, ask orchestrator to clarify
|
||||
"
|
||||
)
|
||||
```
|
||||
|
||||
**Completion Criteria**:
|
||||
- Agent task executed successfully
|
||||
- 5-6 modular files written to `.claude/skills/{tech_stack_name}/`
|
||||
- metadata.json written
|
||||
- Agent reports completion
|
||||
|
||||
**TodoWrite**: Mark phase 2 completed, phase 3 in_progress
|
||||
|
||||
---
|
||||
|
||||
### Phase 3: Generate SKILL.md Index
|
||||
|
||||
**Note**: This phase **ALWAYS executes** - generates or updates the SKILL index.
|
||||
|
||||
**Goal**: Read generated module files and create SKILL.md index with loading recommendations
|
||||
|
||||
**Steps**:
|
||||
|
||||
1. **Verify Generated Files**:
|
||||
```bash
|
||||
bash(find ".claude/skills/${TECH_STACK_NAME}" -name "*.md" -type f | sort)
|
||||
```
|
||||
|
||||
2. **Read metadata.json**:
|
||||
```javascript
|
||||
Read(.claude/skills/${TECH_STACK_NAME}/metadata.json)
|
||||
// Extract: tech_stack_name, components, is_composite, research_summary
|
||||
```
|
||||
|
||||
3. **Read Module Headers** (optional, first 20 lines):
|
||||
```javascript
|
||||
Read(.claude/skills/${TECH_STACK_NAME}/principles.md, limit: 20)
|
||||
// Repeat for other modules
|
||||
```
|
||||
|
||||
4. **Read SKILL Index Template**:
|
||||
|
||||
```javascript
|
||||
Read(~/.claude/workflows/cli-templates/prompts/tech/tech-skill-index.txt)
|
||||
```
|
||||
|
||||
5. **Generate SKILL.md Index**:
|
||||
|
||||
Follow template from tech-skill-index.txt with variable substitutions:
|
||||
- `{TECH_STACK_NAME}`: From metadata.json
|
||||
- `{MAIN_TECH}`: Primary technology
|
||||
- `{ISO_TIMESTAMP}`: Current timestamp
|
||||
- `{QUERY_COUNT}`: From research_summary
|
||||
- `{SOURCE_COUNT}`: From research_summary
|
||||
- Conditional sections for composite tech stacks
|
||||
|
||||
Template provides structure for:
|
||||
- Frontmatter with metadata
|
||||
- Overview and tech stack description
|
||||
- Module organization (Core/Practical/Config sections)
|
||||
- Loading recommendations (Quick/Implementation/Complete)
|
||||
- Usage guidelines and auto-trigger keywords
|
||||
- Research metadata and version history
|
||||
|
||||
6. **Write SKILL.md**:
|
||||
```javascript
|
||||
Write({
|
||||
file_path: `.claude/skills/${TECH_STACK_NAME}/SKILL.md`,
|
||||
content: generatedIndexMarkdown
|
||||
})
|
||||
```
|
||||
|
||||
**Completion Criteria**:
|
||||
- SKILL.md index written
|
||||
- All module files verified
|
||||
- Loading recommendations included
|
||||
|
||||
**TodoWrite**: Mark phase 3 completed
|
||||
|
||||
**Final Report**:
|
||||
```
|
||||
Tech Stack SKILL Package Complete
|
||||
|
||||
Tech Stack: {TECH_STACK_NAME}
|
||||
Location: .claude/skills/{TECH_STACK_NAME}/
|
||||
|
||||
Files: SKILL.md + 5-6 modules + metadata.json
|
||||
Exa Research: {queries} queries, {sources} sources
|
||||
|
||||
Usage: Skill(command: "{TECH_STACK_NAME}")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### TodoWrite Patterns
|
||||
|
||||
**Initialization** (Before Phase 1):
|
||||
```javascript
|
||||
TodoWrite({todos: [
|
||||
{"content": "Prepare context paths", "status": "in_progress", "activeForm": "Preparing context paths"},
|
||||
{"content": "Agent produces all module files", "status": "pending", "activeForm": "Agent producing files"},
|
||||
{"content": "Generate SKILL.md index", "status": "pending", "activeForm": "Generating SKILL index"}
|
||||
]})
|
||||
```
|
||||
|
||||
**Full Path** (SKIP_GENERATION = false):
|
||||
```javascript
|
||||
// After Phase 1
|
||||
TodoWrite({todos: [
|
||||
{"content": "Prepare context paths", "status": "completed", ...},
|
||||
{"content": "Agent produces all module files", "status": "in_progress", ...},
|
||||
{"content": "Generate SKILL.md index", "status": "pending", ...}
|
||||
]})
|
||||
|
||||
// After Phase 2
|
||||
TodoWrite({todos: [
|
||||
{"content": "Prepare context paths", "status": "completed", ...},
|
||||
{"content": "Agent produces all module files", "status": "completed", ...},
|
||||
{"content": "Generate SKILL.md index", "status": "in_progress", ...}
|
||||
]})
|
||||
|
||||
// After Phase 3
|
||||
TodoWrite({todos: [
|
||||
{"content": "Prepare context paths", "status": "completed", ...},
|
||||
{"content": "Agent produces all module files", "status": "completed", ...},
|
||||
{"content": "Generate SKILL.md index", "status": "completed", ...}
|
||||
]})
|
||||
```
|
||||
|
||||
**Skip Path** (SKIP_GENERATION = true):
|
||||
```javascript
|
||||
// After Phase 1 (skip Phase 2)
|
||||
TodoWrite({todos: [
|
||||
{"content": "Prepare context paths", "status": "completed", ...},
|
||||
{"content": "Agent produces all module files", "status": "completed", ...}, // Skipped
|
||||
{"content": "Generate SKILL.md index", "status": "in_progress", ...}
|
||||
]})
|
||||
```
|
||||
|
||||
### Execution Flow
|
||||
|
||||
**Full Path**:
|
||||
```
|
||||
User → TodoWrite Init → Phase 1 (prepare) → Phase 2 (agent writes files) → Phase 3 (write index) → Report
|
||||
```
|
||||
|
||||
**Skip Path**:
|
||||
```
|
||||
User → TodoWrite Init → Phase 1 (detect existing) → Phase 3 (update index) → Report
|
||||
```
|
||||
|
||||
### Error Handling
|
||||
|
||||
**Phase 1 Errors**:
|
||||
- Invalid session ID: Report error, verify session exists
|
||||
- Missing context-package: Warn, fall back to direct mode
|
||||
- No tech stack detected: Ask user to specify tech stack name
|
||||
|
||||
**Phase 2 Errors (Agent)**:
|
||||
- Agent task fails: Retry once, report if fails again
|
||||
- Exa API failures: Agent handles internally with retries
|
||||
- Incomplete results: Warn user, proceed with partial data if minimum sections available
|
||||
|
||||
**Phase 3 Errors**:
|
||||
- Write failures: Report which files failed
|
||||
- Missing files: Note in SKILL.md, suggest regeneration
|
||||
|
||||
---
|
||||
|
||||
## Parameters
|
||||
|
||||
```bash
|
||||
/memory:tech-research [session-id | "tech-stack-name"] [--regenerate] [--tool <gemini|qwen>]
|
||||
```
|
||||
|
||||
**Arguments**:
|
||||
- **session-id | tech-stack-name**: Input source (auto-detected by WFS- prefix)
|
||||
- Session mode: `WFS-user-auth-v2` - Extract tech stack from workflow
|
||||
- Direct mode: `"typescript"`, `"typescript-react-nextjs"` - User specifies
|
||||
- **--regenerate**: Force regenerate existing SKILL (deletes and recreates)
|
||||
- **--tool**: Reserved for future CLI integration (default: gemini)
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
**Generated File Structure** (for all examples):
|
||||
```
|
||||
.claude/skills/{tech-stack}/
|
||||
├── SKILL.md # Index (Phase 3)
|
||||
├── principles.md # Agent (Phase 2)
|
||||
├── patterns.md # Agent
|
||||
├── practices.md # Agent
|
||||
├── testing.md # Agent
|
||||
├── config.md # Agent
|
||||
├── frameworks.md # Agent (if composite)
|
||||
└── metadata.json # Agent
|
||||
```
|
||||
|
||||
### Direct Mode - Single Stack
|
||||
|
||||
```bash
|
||||
/memory:tech-research "typescript"
|
||||
```
|
||||
|
||||
**Workflow**:
|
||||
1. Phase 1: Detects direct mode, checks existing SKILL
|
||||
2. Phase 2: Agent executes 4 Exa queries, writes 5 modules
|
||||
3. Phase 3: Generates SKILL.md index
|
||||
|
||||
### Direct Mode - Composite Stack
|
||||
|
||||
```bash
|
||||
/memory:tech-research "typescript-react-nextjs"
|
||||
```
|
||||
|
||||
**Workflow**:
|
||||
1. Phase 1: Decomposes into ["typescript", "react", "nextjs"]
|
||||
2. Phase 2: Agent executes 6 Exa queries (4 base + 2 components), writes 6 modules (adds frameworks.md)
|
||||
3. Phase 3: Generates SKILL.md index with framework integration
|
||||
|
||||
### Session Mode - Extract from Workflow
|
||||
|
||||
```bash
|
||||
/memory:tech-research WFS-user-auth-20251104
|
||||
```
|
||||
|
||||
**Workflow**:
|
||||
1. Phase 1: Reads session, extracts tech stack: `python-fastapi-sqlalchemy`
|
||||
2. Phase 2: Agent researches Python + FastAPI + SQLAlchemy, writes 6 modules
|
||||
3. Phase 3: Generates SKILL.md index
|
||||
|
||||
### Regenerate Existing
|
||||
|
||||
```bash
|
||||
/memory:tech-research "react" --regenerate
|
||||
```
|
||||
|
||||
**Workflow**:
|
||||
1. Phase 1: Deletes existing SKILL due to --regenerate
|
||||
2. Phase 2: Agent executes fresh Exa research (latest 2025 practices)
|
||||
3. Phase 3: Generates updated SKILL.md
|
||||
|
||||
### Skip Path - Fast Update
|
||||
|
||||
```bash
|
||||
/memory:tech-research "python"
|
||||
```
|
||||
|
||||
**Scenario**: SKILL already exists with 7 files
|
||||
|
||||
**Workflow**:
|
||||
1. Phase 1: Detects existing SKILL, sets SKIP_GENERATION = true
|
||||
2. Phase 2: **SKIPPED**
|
||||
3. Phase 3: Updates SKILL.md index only (5-10x faster)
|
||||
|
||||
|
||||
517
.claude/commands/memory/workflow-skill-memory.md
Normal file
517
.claude/commands/memory/workflow-skill-memory.md
Normal file
@@ -0,0 +1,517 @@
|
||||
---
|
||||
name: workflow-skill-memory
|
||||
description: Generate SKILL package from archived workflow sessions for progressive context loading
|
||||
argument-hint: "session <session-id> | all"
|
||||
allowed-tools: Task(*), TodoWrite(*), Bash(*), Read(*), Write(*)
|
||||
---
|
||||
|
||||
# Workflow SKILL Memory Generator
|
||||
|
||||
## Overview
|
||||
|
||||
Generate SKILL package from archived workflow sessions using agent-driven analysis. Supports single-session incremental updates or parallel processing of all sessions.
|
||||
|
||||
**Scope**: Only processes WFS-* workflow sessions. Other session types (e.g., doc sessions) are automatically ignored.
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/memory:workflow-skill-memory session WFS-<session-id> # Process single WFS session
|
||||
/memory:workflow-skill-memory all # Process all WFS sessions in parallel
|
||||
```
|
||||
|
||||
## Execution Modes
|
||||
|
||||
### Mode 1: Single Session (`session <session-id>`)
|
||||
|
||||
**Purpose**: Incremental update - process one archived session and merge into existing SKILL package
|
||||
|
||||
**Workflow**:
|
||||
1. **Validate session**: Check if session exists in `.workflow/.archives/{session-id}/`
|
||||
2. **Invoke agent**: Call `universal-executor` to analyze session and update SKILL documents
|
||||
3. **Agent tasks**:
|
||||
- Read session data from `.workflow/.archives/{session-id}/`
|
||||
- Extract lessons, conflicts, and outcomes
|
||||
- Use Gemini for intelligent aggregation (optional)
|
||||
- Update or create SKILL documents using templates
|
||||
- Regenerate SKILL.md index
|
||||
|
||||
**Command Example**:
|
||||
```bash
|
||||
/memory:workflow-skill-memory session WFS-user-auth
|
||||
```
|
||||
|
||||
**Expected Output**:
|
||||
```
|
||||
Session WFS-user-auth processed
|
||||
Updated:
|
||||
- sessions-timeline.md (1 session added)
|
||||
- lessons-learned.md (3 lessons merged)
|
||||
- conflict-patterns.md (1 conflict added)
|
||||
- SKILL.md (index regenerated)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Mode 2: All Sessions (`all`)
|
||||
|
||||
**Purpose**: Full regeneration - process all archived sessions in parallel for complete SKILL package
|
||||
|
||||
**Workflow**:
|
||||
1. **List sessions**: Read manifest.json to get all archived session IDs
|
||||
2. **Parallel invocation**: Launch multiple `universal-executor` agents in parallel (one per session)
|
||||
3. **Agent coordination**:
|
||||
- Each agent processes one session independently
|
||||
- Agents use Gemini for analysis
|
||||
- Agents collect data into JSON (no direct file writes)
|
||||
- Final aggregator agent merges results and generates SKILL documents
|
||||
|
||||
**Command Example**:
|
||||
```bash
|
||||
/memory:workflow-skill-memory all
|
||||
```
|
||||
|
||||
**Expected Output**:
|
||||
```
|
||||
All sessions processed in parallel
|
||||
Sessions: 8 total
|
||||
Updated:
|
||||
- sessions-timeline.md (8 sessions)
|
||||
- lessons-learned.md (24 lessons aggregated)
|
||||
- conflict-patterns.md (12 conflicts documented)
|
||||
- SKILL.md (index regenerated)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Implementation Flow
|
||||
|
||||
### Phase 1: Validation and Setup
|
||||
|
||||
**Step 1.1: Parse Command Arguments**
|
||||
|
||||
Extract mode and session ID:
|
||||
```javascript
|
||||
if (args === "all") {
|
||||
mode = "all"
|
||||
} else if (args.startsWith("session ")) {
|
||||
mode = "session"
|
||||
session_id = args.replace("session ", "").trim()
|
||||
} else {
|
||||
ERROR = "Invalid arguments. Usage: session <session-id> | all"
|
||||
EXIT
|
||||
}
|
||||
```
|
||||
|
||||
**Step 1.2: Validate Archive Directory**
|
||||
```bash
|
||||
bash(test -d .workflow/.archives && echo "exists" || echo "missing")
|
||||
```
|
||||
|
||||
If missing, report error and exit.
|
||||
|
||||
**Step 1.3: Mode-Specific Validation**
|
||||
|
||||
**Single Session Mode**:
|
||||
```bash
|
||||
# Validate session ID format (must start with WFS-)
|
||||
if [[ ! "$session_id" =~ ^WFS- ]]; then
|
||||
ERROR = "Invalid session ID format. Only WFS-* sessions are supported"
|
||||
EXIT
|
||||
fi
|
||||
|
||||
# Check if session exists
|
||||
bash(test -d .workflow/.archives/{session_id} && echo "exists" || echo "missing")
|
||||
```
|
||||
|
||||
If missing, report error: "Session {session_id} not found in archives"
|
||||
|
||||
**All Sessions Mode**:
|
||||
```bash
|
||||
# Read manifest and filter only WFS- sessions
|
||||
bash(cat .workflow/.archives/manifest.json | jq -r '.archives[].session_id | select(startswith("WFS-"))')
|
||||
```
|
||||
|
||||
Store filtered session IDs in array. Ignore doc sessions and other non-WFS sessions.
|
||||
|
||||
**Step 1.4: TodoWrite Initialization**
|
||||
|
||||
**Single Session Mode**:
|
||||
```javascript
|
||||
TodoWrite({todos: [
|
||||
{"content": "Validate session existence", "status": "completed", "activeForm": "Validating session"},
|
||||
{"content": "Invoke agent to process session", "status": "in_progress", "activeForm": "Invoking agent"},
|
||||
{"content": "Verify SKILL package updated", "status": "pending", "activeForm": "Verifying update"}
|
||||
]})
|
||||
```
|
||||
|
||||
**All Sessions Mode**:
|
||||
```javascript
|
||||
TodoWrite({todos: [
|
||||
{"content": "Read manifest and list sessions", "status": "completed", "activeForm": "Reading manifest"},
|
||||
{"content": "Invoke agents in parallel", "status": "in_progress", "activeForm": "Invoking agents"},
|
||||
{"content": "Verify SKILL package regenerated", "status": "pending", "activeForm": "Verifying regeneration"}
|
||||
]})
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Phase 2: Agent Invocation
|
||||
|
||||
#### Single Session Mode - Agent Task
|
||||
|
||||
Invoke `universal-executor` with session-specific task:
|
||||
|
||||
**Agent Prompt Structure**:
|
||||
```
|
||||
Task: Process Workflow Session for SKILL Package
|
||||
|
||||
Context:
|
||||
- Session ID: {session_id}
|
||||
- Session Path: .workflow/.archives/{session_id}/
|
||||
- Mode: Incremental update
|
||||
|
||||
Objectives:
|
||||
|
||||
1. Read session data:
|
||||
- workflow-session.json (metadata)
|
||||
- IMPL_PLAN.md (implementation summary)
|
||||
- TODO_LIST.md (if exists)
|
||||
- manifest.json entry for lessons
|
||||
|
||||
2. Extract key information:
|
||||
- Description, tags, metrics
|
||||
- Lessons (successes, challenges, watch_patterns)
|
||||
- Context package path (reference only)
|
||||
- Key outcomes from IMPL_PLAN
|
||||
|
||||
3. Use Gemini for aggregation (optional):
|
||||
Command pattern:
|
||||
cd .workflow/.archives/{session_id} && gemini -p "
|
||||
PURPOSE: Extract lessons and conflicts from workflow session
|
||||
TASK:
|
||||
• Analyze IMPL_PLAN and lessons from manifest
|
||||
• Identify success patterns and challenges
|
||||
• Extract conflict patterns with resolutions
|
||||
• Categorize by functional domain
|
||||
MODE: analysis
|
||||
CONTEXT: @IMPL_PLAN.md @workflow-session.json
|
||||
EXPECTED: Structured lessons and conflicts in JSON format
|
||||
RULES: Template reference from skill-aggregation.txt
|
||||
"
|
||||
|
||||
3.5. **Generate SKILL.md Description** (CRITICAL for auto-loading):
|
||||
|
||||
Read skill-index.txt template Section: "Description Field Generation"
|
||||
|
||||
Execute command to get project root:
|
||||
```bash
|
||||
git rev-parse --show-toplevel # Example output: /d/Claude_dms3
|
||||
```
|
||||
|
||||
Apply description format:
|
||||
```
|
||||
Progressive workflow development history (located at {project_root}).
|
||||
Load this SKILL when continuing development, analyzing past implementations,
|
||||
or learning from workflow history, especially when no relevant context exists in memory.
|
||||
```
|
||||
|
||||
**Validation**:
|
||||
- [ ] Path uses forward slashes (not backslashes)
|
||||
- [ ] All three use cases present
|
||||
- [ ] Trigger optimization phrase included
|
||||
- [ ] Path is absolute (starts with / or drive letter)
|
||||
|
||||
4. Read templates for formatting guidance:
|
||||
- ~/.claude/workflows/cli-templates/prompts/workflow/skill-sessions-timeline.txt
|
||||
- ~/.claude/workflows/cli-templates/prompts/workflow/skill-lessons-learned.txt
|
||||
- ~/.claude/workflows/cli-templates/prompts/workflow/skill-conflict-patterns.txt
|
||||
- ~/.claude/workflows/cli-templates/prompts/workflow/skill-index.txt
|
||||
|
||||
**CRITICAL**: From skill-index.txt, read these sections:
|
||||
- "Description Field Generation" - Rules for generating description
|
||||
- "Variable Substitution Guide" - All required variables
|
||||
- "Generation Instructions" - Step-by-step generation process
|
||||
- "Validation Checklist" - Final validation steps
|
||||
|
||||
5. Update SKILL documents:
|
||||
- sessions-timeline.md: Append new session, update domain grouping
|
||||
- lessons-learned.md: Merge lessons into categories, update frequencies
|
||||
- conflict-patterns.md: Add conflicts, update recurring pattern frequencies
|
||||
- SKILL.md: Regenerate index with updated counts
|
||||
|
||||
**For SKILL.md generation**:
|
||||
- Follow "Generation Instructions" from skill-index.txt (Steps 1-7)
|
||||
- Use git command for project_root: `git rev-parse --show-toplevel`
|
||||
- Apply "Description Field Generation" rules
|
||||
- Validate using "Validation Checklist"
|
||||
- Increment version (patch level)
|
||||
|
||||
6. Return result JSON:
|
||||
{
|
||||
"status": "success",
|
||||
"session_id": "{session_id}",
|
||||
"updates": {
|
||||
"sessions_added": 1,
|
||||
"lessons_merged": count,
|
||||
"conflicts_added": count
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### All Sessions Mode - Parallel Agent Tasks
|
||||
|
||||
**Step 2.1: Launch parallel session analyzers**
|
||||
|
||||
Invoke multiple agents in parallel (one message with multiple Task calls):
|
||||
|
||||
**Per-Session Agent Prompt**:
|
||||
```
|
||||
Task: Extract Session Data for SKILL Package
|
||||
|
||||
Context:
|
||||
- Session ID: {session_id}
|
||||
- Mode: Parallel analysis (no direct file writes)
|
||||
|
||||
Objectives:
|
||||
|
||||
1. Read session data (same as single mode)
|
||||
|
||||
2. Extract key information (same as single mode)
|
||||
|
||||
3. Use Gemini for analysis (same as single mode)
|
||||
|
||||
4. Return structured data JSON:
|
||||
{
|
||||
"status": "success",
|
||||
"session_id": "{session_id}",
|
||||
"data": {
|
||||
"metadata": {
|
||||
"description": "...",
|
||||
"archived_at": "...",
|
||||
"tags": [...],
|
||||
"metrics": {...}
|
||||
},
|
||||
"lessons": {
|
||||
"successes": [...],
|
||||
"challenges": [...],
|
||||
"watch_patterns": [...]
|
||||
},
|
||||
"conflicts": [
|
||||
{
|
||||
"type": "architecture|dependencies|testing|performance",
|
||||
"pattern": "...",
|
||||
"resolution": "...",
|
||||
"code_impact": [...]
|
||||
}
|
||||
],
|
||||
"impl_summary": "First 200 chars of IMPL_PLAN",
|
||||
"context_package_path": "..."
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Step 2.2: Aggregate results**
|
||||
|
||||
After all session agents complete, invoke aggregator agent:
|
||||
|
||||
**Aggregator Agent Prompt**:
|
||||
```
|
||||
Task: Aggregate Session Results and Generate SKILL Package
|
||||
|
||||
Context:
|
||||
- Mode: Full regeneration
|
||||
- Input: JSON results from {session_count} session agents
|
||||
|
||||
Objectives:
|
||||
|
||||
1. Aggregate all session data:
|
||||
- Collect metadata from all sessions
|
||||
- Merge lessons by category
|
||||
- Group conflicts by type
|
||||
- Sort sessions by date
|
||||
|
||||
2. Use Gemini for final aggregation:
|
||||
gemini -p "
|
||||
PURPOSE: Aggregate lessons and conflicts from all workflow sessions
|
||||
TASK:
|
||||
• Group successes by functional domain
|
||||
• Categorize challenges by severity (HIGH/MEDIUM/LOW)
|
||||
• Identify recurring conflict patterns
|
||||
• Calculate frequencies and prioritize
|
||||
MODE: analysis
|
||||
CONTEXT: [Provide aggregated JSON data]
|
||||
EXPECTED: Final aggregated structure for SKILL documents
|
||||
RULES: Template reference from skill-aggregation.txt
|
||||
"
|
||||
|
||||
3. Read templates for formatting (same 4 templates as single mode)
|
||||
|
||||
4. Generate all SKILL documents:
|
||||
- sessions-timeline.md (all sessions, sorted by date)
|
||||
- lessons-learned.md (aggregated lessons with frequencies)
|
||||
- conflict-patterns.md (recurring patterns with resolutions)
|
||||
- SKILL.md (index with progressive loading)
|
||||
|
||||
5. Write files to .claude/skills/workflow-progress/
|
||||
|
||||
6. Return result JSON:
|
||||
{
|
||||
"status": "success",
|
||||
"sessions_processed": count,
|
||||
"files_generated": ["SKILL.md", "sessions-timeline.md", ...],
|
||||
"summary": {
|
||||
"total_sessions": count,
|
||||
"functional_domains": [...],
|
||||
"date_range": "...",
|
||||
"lessons_count": count,
|
||||
"conflicts_count": count
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Phase 3: Verification
|
||||
|
||||
**Step 3.1: Check SKILL Package Files**
|
||||
```bash
|
||||
bash(ls -lh .claude/skills/workflow-progress/)
|
||||
```
|
||||
|
||||
Verify all 4 files exist:
|
||||
- SKILL.md
|
||||
- sessions-timeline.md
|
||||
- lessons-learned.md
|
||||
- conflict-patterns.md
|
||||
|
||||
**Step 3.2: TodoWrite Completion**
|
||||
|
||||
Mark all tasks as completed.
|
||||
|
||||
**Step 3.3: Display Summary**
|
||||
|
||||
**Single Session Mode**:
|
||||
```
|
||||
Session {session_id} processed successfully
|
||||
|
||||
Updated:
|
||||
- sessions-timeline.md
|
||||
- lessons-learned.md
|
||||
- conflict-patterns.md
|
||||
- SKILL.md
|
||||
|
||||
SKILL Location: .claude/skills/workflow-progress/SKILL.md
|
||||
```
|
||||
|
||||
**All Sessions Mode**:
|
||||
```
|
||||
All sessions processed in parallel
|
||||
|
||||
Sessions: {count} total
|
||||
Functional Domains: {domain_list}
|
||||
Date Range: {earliest} - {latest}
|
||||
|
||||
Generated:
|
||||
- sessions-timeline.md ({count} sessions)
|
||||
- lessons-learned.md ({lessons_count} lessons)
|
||||
- conflict-patterns.md ({conflicts_count} conflicts)
|
||||
- SKILL.md (4-level progressive loading)
|
||||
|
||||
SKILL Location: .claude/skills/workflow-progress/SKILL.md
|
||||
|
||||
Usage:
|
||||
- Level 0: Quick refresh (~2K tokens)
|
||||
- Level 1: Recent history (~8K tokens)
|
||||
- Level 2: Complete analysis (~25K tokens)
|
||||
- Level 3: Deep dive (~40K tokens)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agent Guidelines
|
||||
|
||||
### Agent Capabilities
|
||||
|
||||
**universal-executor agents can**:
|
||||
- Read files from `.workflow/.archives/`
|
||||
- Execute bash commands
|
||||
- Call Gemini CLI for intelligent analysis
|
||||
- Read template files for formatting guidance
|
||||
- Write SKILL package files (single mode) or return JSON (parallel mode)
|
||||
- Return structured results
|
||||
|
||||
### Gemini Usage Pattern
|
||||
|
||||
**When to use Gemini**:
|
||||
- Aggregating lessons from multiple sources
|
||||
- Identifying recurring patterns
|
||||
- Classifying conflicts by type and severity
|
||||
- Extracting structured data from IMPL_PLAN
|
||||
|
||||
**Fallback Strategy**: If Gemini fails or times out, use direct file parsing with structured extraction logic.
|
||||
|
||||
---
|
||||
|
||||
## Template System
|
||||
|
||||
### Template Files
|
||||
|
||||
All templates located in: `~/.claude/workflows/cli-templates/prompts/workflow/`
|
||||
|
||||
1. **skill-sessions-timeline.txt**: Format for sessions-timeline.md
|
||||
2. **skill-lessons-learned.txt**: Format for lessons-learned.md
|
||||
3. **skill-conflict-patterns.txt**: Format for conflict-patterns.md
|
||||
4. **skill-index.txt**: Format for SKILL.md index
|
||||
5. **skill-aggregation.txt**: Rules for Gemini aggregation (existing)
|
||||
|
||||
### Template Usage in Agent
|
||||
|
||||
**Agents read templates to understand**:
|
||||
- File structure and markdown format
|
||||
- Data sources (which files to read)
|
||||
- Update strategy (incremental vs full)
|
||||
- Formatting rules and conventions
|
||||
- Aggregation logic (for Gemini)
|
||||
|
||||
**Templates are NOT shown in this command documentation** - agents read them directly as needed.
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Validation Errors
|
||||
- **No archives directory**: "Error: No workflow archives found at .workflow/.archives/"
|
||||
- **Invalid session ID format**: "Error: Invalid session ID format. Only WFS-* sessions are supported"
|
||||
- **Session not found**: "Error: Session {session_id} not found in archives"
|
||||
- **No WFS sessions in manifest**: "Error: No WFS-* workflow sessions found in manifest.json"
|
||||
|
||||
### Agent Errors
|
||||
- If agent fails, report error message from agent result
|
||||
- If Gemini times out, agents use fallback direct parsing
|
||||
- If template read fails, agents use inline format
|
||||
|
||||
### Recovery
|
||||
- Single session mode: Can be retried without affecting other sessions
|
||||
- All sessions mode: If one agent fails, others continue; retry failed sessions individually
|
||||
|
||||
|
||||
|
||||
## Integration
|
||||
|
||||
### Called by `/workflow:session:complete`
|
||||
|
||||
Automatically invoked after session archival:
|
||||
```bash
|
||||
SlashCommand(command="/memory:workflow-skill-memory session {session_id}")
|
||||
```
|
||||
|
||||
### Manual Invocation
|
||||
|
||||
Users can manually process sessions:
|
||||
```bash
|
||||
/memory:workflow-skill-memory session WFS-custom-feature # Single session
|
||||
/memory:workflow-skill-memory all # Full regeneration
|
||||
```
|
||||
@@ -15,7 +15,7 @@ Breaks down complex tasks into executable subtasks with context inheritance and
|
||||
|
||||
## Core Features
|
||||
|
||||
⚠️ **CRITICAL**: Manual breakdown with safety controls to prevent file conflicts and task limit violations.
|
||||
**CRITICAL**: Manual breakdown with safety controls to prevent file conflicts and task limit violations.
|
||||
|
||||
### Breakdown Process
|
||||
1. **Session Check**: Verify active session contains parent task
|
||||
@@ -50,7 +50,7 @@ Interactive process:
|
||||
Task: Build authentication module
|
||||
Current total tasks: 6/10
|
||||
|
||||
⚠️ MANUAL BREAKDOWN REQUIRED
|
||||
MANUAL BREAKDOWN REQUIRED
|
||||
Define subtasks manually (remaining capacity: 4 tasks):
|
||||
|
||||
1. Enter subtask title: User authentication core
|
||||
@@ -59,11 +59,11 @@ Define subtasks manually (remaining capacity: 4 tasks):
|
||||
2. Enter subtask title: OAuth integration
|
||||
Focus files: services/OAuthService.js, routes/oauth.js
|
||||
|
||||
⚠️ FILE CONFLICT DETECTED:
|
||||
FILE CONFLICT DETECTED:
|
||||
- routes/auth.js appears in multiple subtasks
|
||||
- Recommendation: Merge related authentication routes
|
||||
|
||||
⚠️ SIMILAR FUNCTIONALITY WARNING:
|
||||
SIMILAR FUNCTIONALITY WARNING:
|
||||
- "User authentication" and "OAuth integration" both handle auth
|
||||
- Consider combining into single task
|
||||
|
||||
@@ -83,10 +83,10 @@ AskUserQuestion({
|
||||
|
||||
User selected: "Proceed with breakdown"
|
||||
|
||||
✅ Task IMPL-1 broken down:
|
||||
▸ IMPL-1: Build authentication module (container)
|
||||
├── IMPL-1.1: User authentication core → @code-developer
|
||||
└── IMPL-1.2: OAuth integration → @code-developer
|
||||
Task IMPL-1 broken down:
|
||||
IMPL-1: Build authentication module (container)
|
||||
├── IMPL-1.1: User authentication core -> @code-developer
|
||||
└── IMPL-1.2: OAuth integration -> @code-developer
|
||||
|
||||
Files updated: .task/IMPL-1.json + 2 subtask files + TODO_LIST.md
|
||||
```
|
||||
@@ -167,45 +167,38 @@ Files updated: .task/IMPL-1.json + 2 subtask files + TODO_LIST.md
|
||||
```bash
|
||||
/task:breakdown impl-1
|
||||
|
||||
▸ impl-1: Build authentication (container)
|
||||
├── impl-1.1: Design schema → @planning-agent
|
||||
├── impl-1.2: Implement logic + tests → @code-developer
|
||||
└── impl-1.3: Execute & fix tests → @test-fix-agent
|
||||
impl-1: Build authentication (container)
|
||||
├── impl-1.1: Design schema -> @planning-agent
|
||||
├── impl-1.2: Implement logic + tests -> @code-developer
|
||||
└── impl-1.3: Execute & fix tests -> @test-fix-agent
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
```bash
|
||||
# Task not found
|
||||
❌ Task IMPL-5 not found
|
||||
Task IMPL-5 not found
|
||||
|
||||
# Already broken down
|
||||
⚠️ Task IMPL-1 already has subtasks
|
||||
Task IMPL-1 already has subtasks
|
||||
|
||||
# Wrong status
|
||||
❌ Cannot breakdown completed task IMPL-2
|
||||
Cannot breakdown completed task IMPL-2
|
||||
|
||||
# 10-task limit exceeded
|
||||
❌ Breakdown would exceed 10-task limit (current: 8, proposed: 4)
|
||||
Suggestion: Re-scope project into smaller iterations
|
||||
Breakdown would exceed 10-task limit (current: 8, proposed: 4)
|
||||
Suggestion: Re-scope project into smaller iterations
|
||||
|
||||
# File conflicts detected
|
||||
⚠️ File conflict: routes/auth.js appears in IMPL-1.1 and IMPL-1.2
|
||||
Recommendation: Merge subtasks or redistribute files
|
||||
File conflict: routes/auth.js appears in IMPL-1.1 and IMPL-1.2
|
||||
Recommendation: Merge subtasks or redistribute files
|
||||
|
||||
# Similar functionality warning
|
||||
⚠️ Similar functions detected: "user login" and "authentication"
|
||||
Consider consolidating related functionality
|
||||
Similar functions detected: "user login" and "authentication"
|
||||
Consider consolidating related functionality
|
||||
|
||||
# Manual breakdown required
|
||||
❌ Automatic breakdown disabled. Use manual breakdown process.
|
||||
Automatic breakdown disabled. Use manual breakdown process.
|
||||
```
|
||||
|
||||
## Related Commands
|
||||
|
||||
- `/task:create` - Create new tasks
|
||||
- `/task:execute` - Execute subtasks
|
||||
- `/workflow:status` - View task hierarchy
|
||||
- `/workflow:plan` - Plan within 10-task limit
|
||||
|
||||
**System ensures**: Manual breakdown control with file cohesion enforcement, similar functionality detection, and 10-task limit compliance
|
||||
@@ -37,7 +37,7 @@ Creates new implementation tasks with automatic context awareness and ID generat
|
||||
|
||||
Output:
|
||||
```
|
||||
✅ Task created: IMPL-1
|
||||
Task created: IMPL-1
|
||||
Title: Build authentication module
|
||||
Type: feature
|
||||
Agent: code-developer
|
||||
@@ -73,7 +73,7 @@ Status: pending
|
||||
### Analysis Triggers
|
||||
When implementation details incomplete:
|
||||
```bash
|
||||
⚠️ Task requires analysis for implementation details
|
||||
Task requires analysis for implementation details
|
||||
Suggest running: gemini analysis for file locations and dependencies
|
||||
```
|
||||
|
||||
@@ -117,16 +117,16 @@ Based on task type and title keywords:
|
||||
|
||||
```bash
|
||||
# No workflow session
|
||||
❌ No active workflow found
|
||||
→ Use: /workflow init "project name"
|
||||
No active workflow found
|
||||
Use: /workflow init "project name"
|
||||
|
||||
# Duplicate task
|
||||
⚠️ Similar task exists: IMPL-3
|
||||
→ Continue anyway? (y/n)
|
||||
Similar task exists: IMPL-3
|
||||
Continue anyway? (y/n)
|
||||
|
||||
# Max depth exceeded
|
||||
❌ Cannot create IMPL-1.2.1 (max 2 levels)
|
||||
→ Use: IMPL-2 for new main task
|
||||
Cannot create IMPL-1.2.1 (max 2 levels)
|
||||
Use: IMPL-2 for new main task
|
||||
```
|
||||
|
||||
## Examples
|
||||
@@ -135,7 +135,7 @@ Based on task type and title keywords:
|
||||
```bash
|
||||
/task:create "Implement user authentication"
|
||||
|
||||
✅ Created IMPL-1: Implement user authentication
|
||||
Created IMPL-1: Implement user authentication
|
||||
Type: feature
|
||||
Agent: code-developer
|
||||
Status: pending
|
||||
@@ -145,14 +145,8 @@ Status: pending
|
||||
```bash
|
||||
/task:create "Fix login validation bug" --type=bugfix
|
||||
|
||||
✅ Created IMPL-2: Fix login validation bug
|
||||
Created IMPL-2: Fix login validation bug
|
||||
Type: bugfix
|
||||
Agent: code-developer
|
||||
Status: pending
|
||||
```
|
||||
|
||||
## Related Commands
|
||||
|
||||
- `/task:breakdown` - Break into subtasks
|
||||
- `/task:execute` - Execute with agent
|
||||
- `/context` - View task details
|
||||
```
|
||||
@@ -4,12 +4,12 @@ description: Execute tasks with appropriate agents and context-aware orchestrati
|
||||
argument-hint: "task-id"
|
||||
---
|
||||
|
||||
### 🚀 **Command Overview: `/task:execute`**
|
||||
## Command Overview: /task:execute
|
||||
|
||||
- **Purpose**: Executes tasks using intelligent agent selection, context preparation, and progress tracking.
|
||||
**Purpose**: Executes tasks using intelligent agent selection, context preparation, and progress tracking.
|
||||
|
||||
|
||||
### ⚙️ **Execution Modes**
|
||||
## Execution Modes
|
||||
|
||||
- **auto (Default)**
|
||||
- Fully autonomous execution with automatic agent selection.
|
||||
@@ -22,7 +22,7 @@ argument-hint: "task-id"
|
||||
- Optional manual review using `@universal-executor`.
|
||||
- Used only when explicitly requested by user.
|
||||
|
||||
### 🤖 **Agent Selection Logic**
|
||||
## Agent Selection Logic
|
||||
|
||||
The system determines the appropriate agent for a task using the following logic.
|
||||
|
||||
@@ -52,11 +52,11 @@ FUNCTION select_agent(task, agent_override):
|
||||
END FUNCTION
|
||||
```
|
||||
|
||||
### 🔄 **Core Execution Protocol**
|
||||
## Core Execution Protocol
|
||||
|
||||
`Pre-Execution` **->** `Execution` **->** `Post-Execution`
|
||||
`Pre-Execution` -> `Execution` -> `Post-Execution`
|
||||
|
||||
### ✅ **Pre-Execution Protocol**
|
||||
### Pre-Execution Protocol
|
||||
|
||||
`Validate Task & Dependencies` **->** `Prepare Execution Context` **->** `Coordinate with TodoWrite`
|
||||
|
||||
@@ -65,7 +65,7 @@ END FUNCTION
|
||||
- **Session Context Injection**: Provides workflow directory paths to agents for TODO_LIST.md and summary management.
|
||||
- **TodoWrite Coordination**: Generates execution Todos and checkpoints, syncing with `TODO_LIST.md`.
|
||||
|
||||
### 🏁 **Post-Execution Protocol**
|
||||
### Post-Execution Protocol
|
||||
|
||||
`Update Task Status` **->** `Generate Summary` **->** `Save Artifacts` **->** `Sync All Progress` **->** `Validate File Integrity`
|
||||
|
||||
@@ -73,7 +73,7 @@ END FUNCTION
|
||||
- Creates a summary in `.summaries/`.
|
||||
- Stores outputs and syncs progress across the entire workflow session.
|
||||
|
||||
### 🧠 **Task & Subtask Execution Logic**
|
||||
### Task & Subtask Execution Logic
|
||||
|
||||
This logic defines how single, multiple, or parent tasks are handled.
|
||||
|
||||
@@ -99,7 +99,7 @@ FUNCTION execute_task_command(task_id, mode, parallel_flag):
|
||||
END FUNCTION
|
||||
```
|
||||
|
||||
### 🛡️ **Error Handling & Recovery Logic**
|
||||
### Error Handling & Recovery Logic
|
||||
|
||||
```pseudo
|
||||
FUNCTION pre_execution_check(task):
|
||||
@@ -124,7 +124,7 @@ END FUNCTION
|
||||
```
|
||||
|
||||
|
||||
### 📄 **Simplified Context Structure (JSON)**
|
||||
### Simplified Context Structure (JSON)
|
||||
|
||||
This is the simplified data structure loaded to provide context for task execution.
|
||||
|
||||
@@ -213,7 +213,7 @@ This is the simplified data structure loaded to provide context for task executi
|
||||
}
|
||||
```
|
||||
|
||||
### 🎯 **Agent-Specific Context**
|
||||
### Agent-Specific Context
|
||||
|
||||
Different agents receive context tailored to their function, including implementation details:
|
||||
|
||||
@@ -243,13 +243,13 @@ Different agents receive context tailored to their function, including implement
|
||||
- Dependency validation from implementation.context_notes.dependencies
|
||||
- Architecture compliance checks
|
||||
|
||||
### 🗃️ **Simplified File Output**
|
||||
### Simplified File Output
|
||||
|
||||
- **Task JSON File (`.task/<task-id>.json`)**: Updated with status and last attempt time only.
|
||||
- **Session File (`workflow-session.json`)**: Updated task stats (completed count).
|
||||
- **Summary File**: Generated in `.summaries/` upon completion (optional).
|
||||
|
||||
### 📝 **Simplified Summary Template**
|
||||
### Simplified Summary Template
|
||||
|
||||
Optional summary file generated at `.summaries/IMPL-[task-id]-summary.md`.
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ Replans individual tasks or batch processes multiple tasks with change tracking
|
||||
- **Change Documentation**: Track all modifications
|
||||
- **Progress Tracking**: TodoWrite integration for batch operations
|
||||
|
||||
⚠️ **CRITICAL**: Validates active session before replanning
|
||||
**CRITICAL**: Validates active session before replanning
|
||||
|
||||
## Operation Modes
|
||||
|
||||
@@ -189,7 +189,7 @@ AskUserQuestion({
|
||||
|
||||
User selected: "Yes, rollback"
|
||||
|
||||
✅ Task rolled back to version 1.1
|
||||
Task rolled back to version 1.1
|
||||
```
|
||||
|
||||
## Batch Processing with TodoWrite
|
||||
@@ -201,7 +201,7 @@ When processing multiple tasks, automatically creates TodoWrite task list:
|
||||
**Batch Replan Progress**:
|
||||
- [x] IMPL-002: Add FR-12 draft saving acceptance criteria
|
||||
- [x] IMPL-003: Add FR-14 history tracking acceptance criteria
|
||||
- [⧗] IMPL-004: Add FR-09 response surface explicit coverage
|
||||
- [ ] IMPL-004: Add FR-09 response surface explicit coverage
|
||||
- [ ] IMPL-008: Add NFR performance validation steps
|
||||
```
|
||||
|
||||
@@ -255,9 +255,9 @@ AskUserQuestion({
|
||||
|
||||
User selected: "Yes, apply"
|
||||
|
||||
✓ Version 1.2 created
|
||||
✓ Context updated
|
||||
✓ Backup saved to .task/backup/IMPL-1-v1.1.json
|
||||
Version 1.2 created
|
||||
Context updated
|
||||
Backup saved to .task/backup/IMPL-1-v1.1.json
|
||||
```
|
||||
|
||||
### Single Task - File Input
|
||||
@@ -267,9 +267,9 @@ User selected: "Yes, apply"
|
||||
Loading requirements.md...
|
||||
Applying specification changes...
|
||||
|
||||
✓ Task updated with new requirements
|
||||
✓ Version 1.1 created
|
||||
✓ Backup saved to .task/backup/IMPL-2-v1.0.json
|
||||
Task updated with new requirements
|
||||
Version 1.1 created
|
||||
Backup saved to .task/backup/IMPL-2-v1.0.json
|
||||
```
|
||||
|
||||
### Batch Mode - From Verification Report
|
||||
@@ -286,23 +286,23 @@ Found 4 tasks requiring replanning:
|
||||
Creating task tracking list...
|
||||
|
||||
Processing IMPL-002...
|
||||
✓ Backup created: .task/backup/IMPL-002-v1.0.json
|
||||
✓ Updated to v1.1
|
||||
Backup created: .task/backup/IMPL-002-v1.0.json
|
||||
Updated to v1.1
|
||||
|
||||
Processing IMPL-003...
|
||||
✓ Backup created: .task/backup/IMPL-003-v1.0.json
|
||||
✓ Updated to v1.1
|
||||
Backup created: .task/backup/IMPL-003-v1.0.json
|
||||
Updated to v1.1
|
||||
|
||||
Processing IMPL-004...
|
||||
✓ Backup created: .task/backup/IMPL-004-v1.0.json
|
||||
✓ Updated to v1.1
|
||||
Backup created: .task/backup/IMPL-004-v1.0.json
|
||||
Updated to v1.1
|
||||
|
||||
Processing IMPL-008...
|
||||
✓ Backup created: .task/backup/IMPL-008-v1.0.json
|
||||
✓ Updated to v1.1
|
||||
Backup created: .task/backup/IMPL-008-v1.0.json
|
||||
Updated to v1.1
|
||||
|
||||
✅ Batch replan completed: 4/4 successful
|
||||
📋 Summary report saved
|
||||
Batch replan completed: 4/4 successful
|
||||
Summary report saved
|
||||
```
|
||||
|
||||
### Batch Mode - Auto-detection
|
||||
@@ -320,35 +320,35 @@ Entering batch mode...
|
||||
### Single Task Errors
|
||||
```bash
|
||||
# Task not found
|
||||
❌ Task IMPL-5 not found
|
||||
→ Check task ID with /workflow:status
|
||||
Task IMPL-5 not found
|
||||
Check task ID with /workflow:status
|
||||
|
||||
# Task completed
|
||||
⚠️ Task IMPL-1 is completed (cannot replan)
|
||||
→ Create new task for additional work
|
||||
Task IMPL-1 is completed (cannot replan)
|
||||
Create new task for additional work
|
||||
|
||||
# File not found
|
||||
❌ File requirements.md not found
|
||||
→ Check file path
|
||||
File requirements.md not found
|
||||
Check file path
|
||||
|
||||
# No input provided
|
||||
❌ Please specify changes needed
|
||||
→ Provide text, file, or verification report
|
||||
Please specify changes needed
|
||||
Provide text, file, or verification report
|
||||
```
|
||||
|
||||
### Batch Mode Errors
|
||||
```bash
|
||||
# Invalid verification report
|
||||
❌ File does not contain valid verification report format
|
||||
→ Check report structure or use single task mode
|
||||
File does not contain valid verification report format
|
||||
Check report structure or use single task mode
|
||||
|
||||
# Partial failures
|
||||
⚠️ Batch completed with errors: 3/4 successful
|
||||
→ Review error details in summary report
|
||||
Batch completed with errors: 3/4 successful
|
||||
Review error details in summary report
|
||||
|
||||
# No replan recommendations found
|
||||
❌ Verification report contains no replan recommendations
|
||||
→ Check report content or use /workflow:action-plan-verify first
|
||||
Verification report contains no replan recommendations
|
||||
Check report content or use /workflow:action-plan-verify first
|
||||
```
|
||||
|
||||
## Batch Mode Integration
|
||||
@@ -429,16 +429,4 @@ TodoWrite({
|
||||
TodoWrite({
|
||||
todos: updateTaskStatus(taskId, "completed")
|
||||
});
|
||||
```
|
||||
|
||||
## Related Commands
|
||||
|
||||
- `/workflow:status` - View task structure and versions
|
||||
- `/workflow:action-plan-verify` - Generate verification report for batch mode
|
||||
- `/task:execute` - Execute replanned task
|
||||
- `/task:create` - Create new tasks
|
||||
- `/task:breakdown` - Break down complex tasks
|
||||
|
||||
## Context
|
||||
|
||||
$ARGUMENTS
|
||||
```
|
||||
@@ -152,12 +152,12 @@ bash(printf "%s\n%s" "3.2.1" "3.2.2" | sort -V | tail -n 1)
|
||||
|
||||
**Scenario 1: Up to date**
|
||||
```
|
||||
✅ You are on the latest stable version (3.2.1)
|
||||
You are on the latest stable version (3.2.1)
|
||||
```
|
||||
|
||||
**Scenario 2: Upgrade available**
|
||||
```
|
||||
⬆️ A newer stable version is available: v3.2.2
|
||||
A newer stable version is available: v3.2.2
|
||||
Your version: 3.2.1
|
||||
|
||||
To upgrade:
|
||||
@@ -167,7 +167,7 @@ Bash: bash <(curl -fsSL https://raw.githubusercontent.com/catlog22/Claude-Code-W
|
||||
|
||||
**Scenario 3: Development version**
|
||||
```
|
||||
✨ You are running a development version (3.4.0-dev)
|
||||
You are running a development version (3.4.0-dev)
|
||||
This is newer than the latest stable release (v3.3.0)
|
||||
```
|
||||
|
||||
@@ -252,7 +252,3 @@ ERROR: version.json is invalid or corrupted
|
||||
|
||||
### Timeout Configuration
|
||||
All network calls should use `timeout: 30000` (30 seconds) to handle slow connections.
|
||||
|
||||
## Related Commands
|
||||
- `/cli:cli-init` - Initialize CLI configurations
|
||||
- `/workflow:session:list` - List workflow sessions
|
||||
|
||||
@@ -242,10 +242,10 @@ Output a Markdown report (no file writes) with the following structure:
|
||||
|
||||
| Requirement ID | Requirement Summary | Has Task? | Task IDs | Priority Match | Notes |
|
||||
|----------------|---------------------|-----------|----------|----------------|-------|
|
||||
| FR-01 | User authentication | ✅ Yes | IMPL-1.1, IMPL-1.2 | ✅ Match | Complete |
|
||||
| FR-02 | Data export | ✅ Yes | IMPL-2.3 | ⚠️ Mismatch | High req → Med priority task |
|
||||
| FR-03 | Profile management | ❌ No | - | - | **CRITICAL: Zero coverage** |
|
||||
| NFR-01 | Response time <200ms | ❌ No | - | - | **HIGH: No performance tasks** |
|
||||
| FR-01 | User authentication | Yes | IMPL-1.1, IMPL-1.2 | Match | Complete |
|
||||
| FR-02 | Data export | Yes | IMPL-2.3 | Mismatch | High req → Med priority task |
|
||||
| FR-03 | Profile management | No | - | - | **CRITICAL: Zero coverage** |
|
||||
| NFR-01 | Response time <200ms | No | - | - | **HIGH: No performance tasks** |
|
||||
|
||||
**Coverage Metrics**:
|
||||
- Functional Requirements: 85% (17/20 covered)
|
||||
@@ -264,7 +264,7 @@ Output a Markdown report (no file writes) with the following structure:
|
||||
|
||||
### Dependency Graph Issues
|
||||
|
||||
**Circular Dependencies**: None detected ✅
|
||||
**Circular Dependencies**: None detected
|
||||
|
||||
**Broken Dependencies**:
|
||||
- IMPL-2.3 depends on "IMPL-2.4" (non-existent)
|
||||
@@ -323,12 +323,12 @@ Output a Markdown report (no file writes) with the following structure:
|
||||
#### Action Recommendations
|
||||
|
||||
**If CRITICAL Issues Exist**:
|
||||
- ❌ **BLOCK EXECUTION** - Resolve critical issues before proceeding
|
||||
- **BLOCK EXECUTION** - Resolve critical issues before proceeding
|
||||
- Use TodoWrite to track all required fixes
|
||||
- Fix broken dependencies and circular references
|
||||
|
||||
**If Only HIGH/MEDIUM/LOW Issues**:
|
||||
- ⚠️ **PROCEED WITH CAUTION** - Fix high-priority issues first
|
||||
- **PROCEED WITH CAUTION** - Fix high-priority issues first
|
||||
- Use TodoWrite to systematically track and complete all improvements
|
||||
|
||||
#### TodoWrite-Based Remediation Workflow
|
||||
|
||||
@@ -406,8 +406,8 @@ TodoWrite({
|
||||
#### TODO_LIST.md Update Timing
|
||||
**Single source of truth for task status** - enables lazy loading by providing task metadata without reading JSONs
|
||||
|
||||
- **Before Agent Launch**: Mark task as `in_progress` (⚠️)
|
||||
- **After Task Complete**: Mark as `completed` (✅), advance to next
|
||||
- **Before Agent Launch**: Mark task as `in_progress`
|
||||
- **After Task Complete**: Mark as `completed`, advance to next
|
||||
- **On Error**: Keep as `in_progress`, add error note
|
||||
- **Workflow Complete**: Call `/workflow:session:complete`
|
||||
|
||||
|
||||
@@ -153,7 +153,7 @@ CONTEXT: Existing user database schema, REST API endpoints
|
||||
|
||||
**Relationship with Brainstorm Phase**:
|
||||
- If brainstorm role analyses exist ([role]/analysis.md files), Phase 3 analysis incorporates them as input
|
||||
- **⚠️ User's original intent is ALWAYS primary**: New or refined user goals override brainstorm recommendations
|
||||
- **User's original intent is ALWAYS primary**: New or refined user goals override brainstorm recommendations
|
||||
- **Role analysis.md files define "WHAT"**: Requirements, design specs, role-specific insights
|
||||
- **IMPL_PLAN.md defines "HOW"**: Executable task breakdown, dependencies, implementation sequence
|
||||
- Task generation translates high-level role analyses into concrete, actionable work items
|
||||
@@ -192,12 +192,12 @@ Planning complete for session: [sessionId]
|
||||
Tasks generated: [count]
|
||||
Plan: .workflow/[sessionId]/IMPL_PLAN.md
|
||||
|
||||
✅ Recommended Next Steps:
|
||||
Recommended Next Steps:
|
||||
1. /workflow:action-plan-verify --session [sessionId] # Verify plan quality before execution
|
||||
2. /workflow:status # Review task breakdown
|
||||
3. /workflow:execute # Start implementation (after verification)
|
||||
|
||||
⚠️ Quality Gate: Consider running /workflow:action-plan-verify to catch issues early
|
||||
Quality Gate: Consider running /workflow:action-plan-verify to catch issues early
|
||||
```
|
||||
|
||||
## TodoWrite Pattern
|
||||
@@ -323,24 +323,24 @@ Return summary to user
|
||||
|
||||
## Coordinator Checklist
|
||||
|
||||
✅ **Pre-Phase**: Convert user input to structured format (GOAL/SCOPE/CONTEXT)
|
||||
✅ Initialize TodoWrite before any command (Phase 3 added dynamically after Phase 2)
|
||||
✅ Execute Phase 1 immediately with structured description
|
||||
✅ Parse session ID from Phase 1 output, store in memory
|
||||
✅ Pass session ID and structured description to Phase 2 command
|
||||
✅ Parse context path from Phase 2 output, store in memory
|
||||
✅ **Extract conflict_risk from context-package.json**: Determine Phase 3 execution
|
||||
✅ **If conflict_risk ≥ medium**: Launch Phase 3 conflict-resolution with sessionId and contextPath
|
||||
✅ Wait for Phase 3 completion (if executed), verify CONFLICT_RESOLUTION.md created
|
||||
✅ **If conflict_risk is none/low**: Skip Phase 3, proceed directly to Phase 4
|
||||
✅ **Build Phase 4 command** based on flags:
|
||||
- **Pre-Phase**: Convert user input to structured format (GOAL/SCOPE/CONTEXT)
|
||||
- Initialize TodoWrite before any command (Phase 3 added dynamically after Phase 2)
|
||||
- Execute Phase 1 immediately with structured description
|
||||
- Parse session ID from Phase 1 output, store in memory
|
||||
- Pass session ID and structured description to Phase 2 command
|
||||
- Parse context path from Phase 2 output, store in memory
|
||||
- **Extract conflict_risk from context-package.json**: Determine Phase 3 execution
|
||||
- **If conflict_risk ≥ medium**: Launch Phase 3 conflict-resolution with sessionId and contextPath
|
||||
- Wait for Phase 3 completion (if executed), verify CONFLICT_RESOLUTION.md created
|
||||
- **If conflict_risk is none/low**: Skip Phase 3, proceed directly to Phase 4
|
||||
- **Build Phase 4 command** based on flags:
|
||||
- Base command: `/workflow:tools:task-generate` (or `-agent` if `--agent` flag)
|
||||
- Add `--session [sessionId]`
|
||||
- Add `--cli-execute` if flag present
|
||||
✅ Pass session ID to Phase 4 command
|
||||
✅ Verify all Phase 4 outputs
|
||||
✅ Update TodoWrite after each phase (dynamically adjust for Phase 3 presence)
|
||||
✅ After each phase, automatically continue to next phase based on TodoList status
|
||||
- Pass session ID to Phase 4 command
|
||||
- Verify all Phase 4 outputs
|
||||
- Update TodoWrite after each phase (dynamically adjust for Phase 3 presence)
|
||||
- After each phase, automatically continue to next phase based on TodoList status
|
||||
|
||||
## Structure Template Reference
|
||||
|
||||
@@ -368,3 +368,22 @@ CONSTRAINTS: [Limitations or boundaries]
|
||||
# Phase 2
|
||||
/workflow:tools:context-gather --session WFS-123 "GOAL: Build authentication\nSCOPE: JWT, login, registration\nCONTEXT: REST API"
|
||||
```
|
||||
|
||||
## Related Commands
|
||||
|
||||
**Prerequisite Commands**:
|
||||
- `/workflow:brainstorm:artifacts` - Optional: Generate role-based analyses before planning (if complex requirements need multiple perspectives)
|
||||
- `/workflow:brainstorm:synthesis` - Optional: Refine brainstorm analyses with clarifications
|
||||
|
||||
**Called by This Command** (5 phases):
|
||||
- `/workflow:session:start` - Phase 1: Create or discover workflow session
|
||||
- `/workflow:tools:context-gather` - Phase 2: Gather project context and analyze codebase
|
||||
- `/workflow:tools:conflict-resolution` - Phase 3: Detect and resolve conflicts (auto-triggered if conflict_risk ≥ medium)
|
||||
- `/compact` - Phase 3: Memory optimization (if context approaching limits)
|
||||
- `/workflow:tools:task-generate` - Phase 4: Generate task JSON files with manual approach
|
||||
- `/workflow:tools:task-generate-agent` - Phase 4: Generate task JSON files with agent-driven approach (when `--agent` flag used)
|
||||
|
||||
**Follow-up Commands**:
|
||||
- `/workflow:action-plan-verify` - Recommended: Verify plan quality and catch issues before execution
|
||||
- `/workflow:status` - Review task breakdown and current progress
|
||||
- `/workflow:execute` - Begin implementation of generated tasks
|
||||
|
||||
@@ -89,5 +89,17 @@ The special `--resume-session` flag tells `/workflow:execute`:
|
||||
3. **Agent coordination**: TodoWrite and agent execution initiated successfully
|
||||
4. **Context preservation**: Session state and progress properly maintained
|
||||
|
||||
## Related Commands
|
||||
|
||||
**Prerequisite Commands**:
|
||||
- `/workflow:plan` or `/workflow:execute` - Workflow must be in progress or paused
|
||||
|
||||
**Called by This Command** (2 phases):
|
||||
- `/workflow:status` - Phase 1: Analyze current session status and identify resume point
|
||||
- `/workflow:execute` - Phase 2: Resume execution with `--resume-session` flag
|
||||
|
||||
**Follow-up Commands**:
|
||||
- None - Workflow continues automatically via `/workflow:execute`
|
||||
|
||||
---
|
||||
*Sequential command coordination for workflow session resumption*
|
||||
@@ -4,17 +4,17 @@ description: Optional specialized review (security, architecture, docs) for comp
|
||||
argument-hint: "[--type=security|architecture|action-items|quality] [optional: session-id]"
|
||||
---
|
||||
|
||||
### 🚀 Command Overview: `/workflow:review`
|
||||
## Command Overview: /workflow:review
|
||||
|
||||
**Optional specialized review** for completed implementations. In the standard workflow, **passing tests = approved code**. Use this command only when specialized review is required (security, architecture, compliance, docs).
|
||||
|
||||
## Philosophy: "Tests Are the Review"
|
||||
|
||||
- ✅ **Default**: All tests pass → Code approved
|
||||
- 🔍 **Optional**: Specialized reviews for:
|
||||
- 🔒 Security audits (vulnerabilities, auth/authz)
|
||||
- 🏗️ Architecture compliance (patterns, technical debt)
|
||||
- 📋 Action items verification (requirements met, acceptance criteria)
|
||||
- **Default**: All tests pass -> Code approved
|
||||
- **Optional**: Specialized reviews for:
|
||||
- Security audits (vulnerabilities, auth/authz)
|
||||
- Architecture compliance (patterns, technical debt)
|
||||
- Action items verification (requirements met, acceptance criteria)
|
||||
|
||||
## Review Types
|
||||
|
||||
@@ -44,13 +44,13 @@ fi
|
||||
|
||||
# Step 2: Validation
|
||||
if [ ! -d ".workflow/${sessionId}" ]; then
|
||||
echo "❌ Session ${sessionId} not found"
|
||||
echo "Session ${sessionId} not found"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Check for completed tasks
|
||||
if [ ! -d ".workflow/${sessionId}/.summaries" ] || [ -z "$(find .workflow/${sessionId}/.summaries/ -name "IMPL-*.md" -type f 2>/dev/null)" ]; then
|
||||
echo "❌ No completed implementation found. Complete implementation first"
|
||||
echo "No completed implementation found. Complete implementation first"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
@@ -59,7 +59,7 @@ review_type="${TYPE_ARG:-quality}"
|
||||
|
||||
# Redirect docs review to specialized command
|
||||
if [ "$review_type" = "docs" ]; then
|
||||
echo "💡 For documentation generation, please use:"
|
||||
echo "For documentation generation, please use:"
|
||||
echo " /workflow:tools:docs"
|
||||
echo ""
|
||||
echo "The docs command provides:"
|
||||
@@ -73,7 +73,7 @@ fi
|
||||
# BASH_EXECUTION_STOPS → MODEL_ANALYSIS_BEGINS
|
||||
```
|
||||
|
||||
### 🧠 Model Analysis Phase
|
||||
### Model Analysis Phase
|
||||
|
||||
After bash validation, the model takes control to:
|
||||
|
||||
@@ -205,7 +205,7 @@ After bash validation, the model takes control to:
|
||||
```bash
|
||||
# If architecture or quality issues found, suggest memory update
|
||||
if [ "$review_type" = "architecture" ] || [ "$review_type" = "quality" ]; then
|
||||
echo "💡 Consider updating project documentation:"
|
||||
echo "Consider updating project documentation:"
|
||||
echo " /update-memory-related"
|
||||
fi
|
||||
```
|
||||
@@ -226,7 +226,7 @@ After bash validation, the model takes control to:
|
||||
/workflow:review --type=docs
|
||||
```
|
||||
|
||||
## ✨ Features
|
||||
## Features
|
||||
|
||||
- **Simple Validation**: Check session exists and has completed tasks
|
||||
- **No Complex Orchestration**: Direct analysis, no multi-phase pipeline
|
||||
@@ -240,10 +240,10 @@ After bash validation, the model takes control to:
|
||||
|
||||
```
|
||||
Standard Workflow:
|
||||
plan → execute → test-gen → execute ✅
|
||||
plan -> execute -> test-gen -> execute (complete)
|
||||
|
||||
Optional Review (when needed):
|
||||
plan → execute → test-gen → execute → review (security/architecture/docs)
|
||||
plan -> execute -> test-gen -> execute -> review (security/architecture/docs)
|
||||
```
|
||||
|
||||
**When to Use**:
|
||||
@@ -256,11 +256,3 @@ Optional Review (when needed):
|
||||
- Regular development (tests are sufficient)
|
||||
- Simple bug fixes (test-fix-agent handles it)
|
||||
- Minor changes (update-memory-related is enough)
|
||||
|
||||
## Related Commands
|
||||
|
||||
- `/workflow:execute` - Must complete implementation first
|
||||
- `/workflow:test-gen` - Primary quality gate (tests)
|
||||
- `/workflow:tools:docs` - Generate hierarchical documentation (use instead of `--type=docs`)
|
||||
- `/update-memory-related` - Update CLAUDE.md docs after architecture findings
|
||||
- `/workflow:status` - Check session status
|
||||
|
||||
@@ -59,19 +59,19 @@ jq -r '.created_at // "unknown"' .workflow/WFS-session/workflow-session.json
|
||||
```
|
||||
Workflow Sessions:
|
||||
|
||||
✅ WFS-oauth-integration (ACTIVE)
|
||||
[ACTIVE] WFS-oauth-integration
|
||||
Project: OAuth2 authentication system
|
||||
Status: active
|
||||
Progress: 3/8 tasks completed
|
||||
Created: 2025-09-15T10:30:00Z
|
||||
|
||||
⏸️ WFS-user-profile (PAUSED)
|
||||
[PAUSED] WFS-user-profile
|
||||
Project: User profile management
|
||||
Status: paused
|
||||
Progress: 1/5 tasks completed
|
||||
Created: 2025-09-14T14:15:00Z
|
||||
|
||||
📁 WFS-database-migration (COMPLETED)
|
||||
[COMPLETED] WFS-database-migration
|
||||
Project: Database schema migration
|
||||
Status: completed
|
||||
Progress: 4/4 tasks completed
|
||||
@@ -81,10 +81,10 @@ Total: 3 sessions (1 active, 1 paused, 1 completed)
|
||||
```
|
||||
|
||||
### Status Indicators
|
||||
- **✅**: Active session
|
||||
- **⏸️**: Paused session
|
||||
- **📁**: Completed session
|
||||
- **❌**: Error/corrupted session
|
||||
- **[ACTIVE]**: Active session
|
||||
- **[PAUSED]**: Paused session
|
||||
- **[COMPLETED]**: Completed session
|
||||
- **[ERROR]**: Error/corrupted session
|
||||
|
||||
### Quick Commands
|
||||
```bash
|
||||
@@ -96,9 +96,4 @@ ls .workflow/.active-* | basename | sed 's/^\.active-//'
|
||||
|
||||
# Show recent sessions
|
||||
ls -t .workflow/WFS-*/workflow-session.json | head -3
|
||||
```
|
||||
|
||||
## Related Commands
|
||||
- `/workflow:session:start` - Create new session
|
||||
- `/workflow:session:switch` - Switch to different session
|
||||
- `/workflow:session:status` - Detailed session info
|
||||
```
|
||||
@@ -64,9 +64,4 @@ Session WFS-user-auth resumed
|
||||
- Paused at: 2025-09-15T14:30:00Z
|
||||
- Resumed at: 2025-09-15T15:45:00Z
|
||||
- Ready for: /workflow:execute
|
||||
```
|
||||
|
||||
## Related Commands
|
||||
- `/workflow:session:pause` - Pause current session
|
||||
- `/workflow:execute` - Continue workflow execution
|
||||
- `/workflow:session:list` - Show all sessions
|
||||
```
|
||||
@@ -212,9 +212,4 @@ bash(echo '{"session_id":"WFS-test","project":"test project","status":"planning"
|
||||
- Pattern: `WFS-[lowercase-slug]`
|
||||
- Characters: `a-z`, `0-9`, `-` only
|
||||
- Max length: 50 characters
|
||||
- Uniqueness: Add numeric suffix if collision (`WFS-auth-2`, `WFS-auth-3`)
|
||||
|
||||
## Related Commands
|
||||
- `/workflow:plan` - Uses `--auto` mode for session management
|
||||
- `/workflow:execute` - Uses discovery mode for session selection
|
||||
- `/workflow:session:status` - Shows detailed session information
|
||||
- Uniqueness: Add numeric suffix if collision (`WFS-auth-2`, `WFS-auth-3`)
|
||||
@@ -51,11 +51,11 @@ find .workflow/WFS-session/.summaries/ -name "*.md" -type f 2>/dev/null | wc -l
|
||||
**Progress**: 3/8 tasks completed
|
||||
|
||||
## Active Tasks
|
||||
- [⚠️] impl-1: Current task in progress
|
||||
- [IN PROGRESS] impl-1: Current task in progress
|
||||
- [ ] impl-2: Next pending task
|
||||
|
||||
## Completed Tasks
|
||||
- [✅] impl-0: Setup completed
|
||||
- [COMPLETED] impl-0: Setup completed
|
||||
```
|
||||
|
||||
## Simple Bash Commands
|
||||
@@ -112,13 +112,8 @@ Summary: .summaries/impl-1-summary.md
|
||||
|
||||
### Validation Results
|
||||
```
|
||||
✅ Session file valid
|
||||
✅ 8 task files found
|
||||
✅ 3 summaries found
|
||||
⚠️ 5 tasks pending completion
|
||||
```
|
||||
|
||||
## Related Commands
|
||||
- `/workflow:execute` - Uses this for task discovery
|
||||
- `/workflow:resume` - Uses this for progress analysis
|
||||
- `/workflow:session:status` - Shows session metadata
|
||||
Session file valid
|
||||
8 task files found
|
||||
3 summaries found
|
||||
5 tasks pending completion
|
||||
```
|
||||
@@ -171,14 +171,14 @@ Total tasks: [M] (1 task per simple feature + subtasks for complex features)
|
||||
Task breakdown:
|
||||
- Simple features: [K] tasks (IMPL-1 to IMPL-K)
|
||||
- Complex features: [L] features with [P] subtasks
|
||||
- Total task count: [M] (within 10-task limit ✅)
|
||||
- Total task count: [M] (within 10-task limit)
|
||||
|
||||
Structure:
|
||||
- IMPL-1: {Feature 1 Name} (Internal: 🔴 Red → 🟢 Green → 🔵 Refactor)
|
||||
- IMPL-2: {Feature 2 Name} (Internal: 🔴 Red → 🟢 Green → 🔵 Refactor)
|
||||
- IMPL-1: {Feature 1 Name} (Internal: Red → Green → Refactor)
|
||||
- IMPL-2: {Feature 2 Name} (Internal: Red → Green → Refactor)
|
||||
- IMPL-3: {Complex Feature} (Container)
|
||||
- IMPL-3.1: {Sub-feature A} (Internal: 🔴 Red → 🟢 Green → 🔵 Refactor)
|
||||
- IMPL-3.2: {Sub-feature B} (Internal: 🔴 Red → 🟢 Green → 🔵 Refactor)
|
||||
- IMPL-3.1: {Sub-feature A} (Internal: Red → Green → Refactor)
|
||||
- IMPL-3.2: {Sub-feature B} (Internal: Red → Green → Refactor)
|
||||
[...]
|
||||
|
||||
Plans generated:
|
||||
@@ -192,12 +192,12 @@ TDD Configuration:
|
||||
- Green phase includes test-fix cycle (max 3 iterations)
|
||||
- Auto-revert on max iterations reached
|
||||
|
||||
✅ Recommended Next Steps:
|
||||
Recommended Next Steps:
|
||||
1. /workflow:action-plan-verify --session [sessionId] # Verify TDD plan quality and dependencies
|
||||
2. /workflow:execute --session [sessionId] # Start TDD execution
|
||||
3. /workflow:tdd-verify [sessionId] # Post-execution TDD compliance check
|
||||
|
||||
⚠️ Quality Gate: Consider running /workflow:action-plan-verify to validate TDD task structure and dependencies
|
||||
Quality Gate: Consider running /workflow:action-plan-verify to validate TDD task structure and dependencies
|
||||
```
|
||||
|
||||
## TodoWrite Pattern
|
||||
@@ -258,11 +258,6 @@ Convert user input to TDD-structured format:
|
||||
- **Command failure**: Keep phase in_progress, report error
|
||||
- **TDD validation failure**: Report incomplete chains or wrong dependencies
|
||||
|
||||
## Related Commands
|
||||
- `/workflow:plan` - Standard (non-TDD) planning
|
||||
- `/workflow:execute` - Execute TDD tasks
|
||||
- `/workflow:tdd-verify` - Verify TDD compliance
|
||||
- `/workflow:status` - View progress
|
||||
## TDD Workflow Enhancements
|
||||
|
||||
### Overview
|
||||
@@ -294,7 +289,7 @@ IMPL (Green phase) tasks now include automatic test-fix cycle for resilient impl
|
||||
```
|
||||
1. Write minimal implementation code
|
||||
2. Execute test suite
|
||||
3. IF tests pass → Complete task ✅
|
||||
3. IF tests pass → Complete task
|
||||
4. IF tests fail → Enter fix cycle:
|
||||
a. Gemini diagnoses with bug-fix template
|
||||
b. Apply fix (manual or Codex)
|
||||
@@ -304,10 +299,10 @@ IMPL (Green phase) tasks now include automatic test-fix cycle for resilient impl
|
||||
```
|
||||
|
||||
**Benefits**:
|
||||
- ✅ Faster feedback within Green phase
|
||||
- ✅ Autonomous recovery from implementation errors
|
||||
- ✅ Systematic debugging with Gemini
|
||||
- ✅ Safe rollback prevents broken state
|
||||
- Faster feedback within Green phase
|
||||
- Autonomous recovery from implementation errors
|
||||
- Systematic debugging with Gemini
|
||||
- Safe rollback prevents broken state
|
||||
|
||||
#### 3. Agent-Driven Planning
|
||||
**From plan --agent workflow**
|
||||
@@ -335,7 +330,7 @@ Supports action-planning-agent for more autonomous TDD planning with:
|
||||
|
||||
### Migration Notes
|
||||
|
||||
**Backward Compatibility**: ✅ Fully compatible
|
||||
**Backward Compatibility**: Fully compatible
|
||||
- Existing TDD workflows continue to work
|
||||
- New features are additive, not breaking
|
||||
- Phase 3 can be skipped if test-context-gather not available
|
||||
@@ -367,3 +362,23 @@ Supports action-planning-agent for more autonomous TDD planning with:
|
||||
- `meta.max_iterations`: Fix attempts (default: 3)
|
||||
- `meta.use_codex`: Auto-fix mode (default: false)
|
||||
|
||||
## Related Commands
|
||||
|
||||
**Prerequisite Commands**:
|
||||
- None - TDD planning is self-contained (can optionally run brainstorm commands before)
|
||||
|
||||
**Called by This Command** (6 phases):
|
||||
- `/workflow:session:start` - Phase 1: Create or discover TDD workflow session
|
||||
- `/workflow:tools:context-gather` - Phase 2: Gather project context and analyze codebase
|
||||
- `/workflow:tools:test-context-gather` - Phase 3: Analyze existing test patterns and coverage
|
||||
- `/workflow:tools:conflict-resolution` - Phase 4: Detect and resolve conflicts (auto-triggered if conflict_risk ≥ medium)
|
||||
- `/compact` - Phase 4: Memory optimization (if context approaching limits)
|
||||
- `/workflow:tools:task-generate-tdd` - Phase 5: Generate TDD task chains with Red-Green-Refactor cycles
|
||||
- `/workflow:tools:task-generate-tdd --agent` - Phase 5: Generate TDD tasks with agent-driven approach (when `--agent` flag used)
|
||||
|
||||
**Follow-up Commands**:
|
||||
- `/workflow:action-plan-verify` - Recommended: Verify TDD plan quality and structure before execution
|
||||
- `/workflow:status` - Review TDD task breakdown
|
||||
- `/workflow:execute` - Begin TDD implementation
|
||||
- `/workflow:tdd-verify` - Post-execution: Verify TDD compliance and generate quality report
|
||||
|
||||
|
||||
@@ -118,14 +118,14 @@ RULES: Focus on TDD best practices and workflow adherence. Be specific about vio
|
||||
TDD Verification Report - Session: {sessionId}
|
||||
|
||||
## Chain Validation
|
||||
✅ Feature 1: TEST-1.1 → IMPL-1.1 → REFACTOR-1.1 (Complete)
|
||||
✅ Feature 2: TEST-2.1 → IMPL-2.1 → REFACTOR-2.1 (Complete)
|
||||
⚠️ Feature 3: TEST-3.1 → IMPL-3.1 (Missing REFACTOR phase)
|
||||
[COMPLETE] Feature 1: TEST-1.1 → IMPL-1.1 → REFACTOR-1.1 (Complete)
|
||||
[COMPLETE] Feature 2: TEST-2.1 → IMPL-2.1 → REFACTOR-2.1 (Complete)
|
||||
[INCOMPLETE] Feature 3: TEST-3.1 → IMPL-3.1 (Missing REFACTOR phase)
|
||||
|
||||
## Test Execution
|
||||
✅ All TEST tasks produced failing tests
|
||||
✅ All IMPL tasks made tests pass
|
||||
✅ All REFACTOR tasks maintained green tests
|
||||
All TEST tasks produced failing tests
|
||||
All IMPL tasks made tests pass
|
||||
All REFACTOR tasks maintained green tests
|
||||
|
||||
## Coverage Metrics
|
||||
Line Coverage: {percentage}%
|
||||
@@ -271,20 +271,20 @@ Status: {EXCELLENT | GOOD | NEEDS IMPROVEMENT | FAILED}
|
||||
## Chain Analysis
|
||||
|
||||
### Feature 1: {Feature Name}
|
||||
**Status**: ✅ Complete
|
||||
**Status**: Complete
|
||||
**Chain**: TEST-1.1 → IMPL-1.1 → REFACTOR-1.1
|
||||
|
||||
- ✅ **Red Phase**: Test created and failed with clear message
|
||||
- ✅ **Green Phase**: Minimal implementation made test pass
|
||||
- ✅ **Refactor Phase**: Code improved, tests remained green
|
||||
- **Red Phase**: Test created and failed with clear message
|
||||
- **Green Phase**: Minimal implementation made test pass
|
||||
- **Refactor Phase**: Code improved, tests remained green
|
||||
|
||||
### Feature 2: {Feature Name}
|
||||
**Status**: ⚠️ Incomplete
|
||||
**Status**: Incomplete
|
||||
**Chain**: TEST-2.1 → IMPL-2.1 (Missing REFACTOR-2.1)
|
||||
|
||||
- ✅ **Red Phase**: Test created and failed
|
||||
- ⚠️ **Green Phase**: Implementation seems over-engineered
|
||||
- ❌ **Refactor Phase**: Missing
|
||||
- **Red Phase**: Test created and failed
|
||||
- **Green Phase**: Implementation seems over-engineered
|
||||
- **Refactor Phase**: Missing
|
||||
|
||||
**Issues**:
|
||||
- REFACTOR-2.1 task not completed
|
||||
@@ -306,16 +306,16 @@ Status: {EXCELLENT | GOOD | NEEDS IMPROVEMENT | FAILED}
|
||||
## TDD Cycle Validation
|
||||
|
||||
### Red Phase (Write Failing Test)
|
||||
- ✅ {N}/{total} features had failing tests initially
|
||||
- ⚠️ Feature 3: No evidence of initial test failure
|
||||
- {N}/{total} features had failing tests initially
|
||||
- Feature 3: No evidence of initial test failure
|
||||
|
||||
### Green Phase (Make Test Pass)
|
||||
- ✅ {N}/{total} implementations made tests pass
|
||||
- ✅ All implementations minimal and focused
|
||||
- {N}/{total} implementations made tests pass
|
||||
- All implementations minimal and focused
|
||||
|
||||
### Refactor Phase (Improve Quality)
|
||||
- ⚠️ {N}/{total} features completed refactoring
|
||||
- ❌ Feature 2, 4: Refactoring step skipped
|
||||
- {N}/{total} features completed refactoring
|
||||
- Feature 2, 4: Refactoring step skipped
|
||||
|
||||
## Best Practices Assessment
|
||||
|
||||
@@ -351,8 +351,3 @@ Status: {EXCELLENT | GOOD | NEEDS IMPROVEMENT | FAILED}
|
||||
{Summary of compliance status and next steps}
|
||||
```
|
||||
|
||||
## Related Commands
|
||||
- `/workflow:tdd-plan` - Creates TDD workflow
|
||||
- `/workflow:execute` - Executes TDD tasks
|
||||
- `/workflow:tools:tdd-coverage-analysis` - Analyzes test coverage
|
||||
- `/workflow:status` - Views workflow progress
|
||||
|
||||
@@ -10,7 +10,7 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*), Task(*)
|
||||
## Overview
|
||||
Orchestrates dynamic test-fix workflow execution through iterative cycles of testing, analysis, and fixing. **Unlike standard execute, this command dynamically generates intermediate tasks** during execution based on test results and CLI analysis, enabling adaptive problem-solving.
|
||||
|
||||
**⚠️ CRITICAL - Orchestrator Boundary**:
|
||||
**CRITICAL - Orchestrator Boundary**:
|
||||
- This command is the **ONLY place** where test failures are handled
|
||||
- All CLI analysis (Gemini/Qwen), fix task generation (IMPL-fix-N.json), and iteration management happen HERE
|
||||
- Agents (@test-fix-agent) only execute single tasks and return results
|
||||
@@ -59,22 +59,22 @@ Orchestrates dynamic test-fix workflow execution through iterative cycles of tes
|
||||
|
||||
## Responsibility Matrix
|
||||
|
||||
**⚠️ CRITICAL - Clear division of labor between orchestrator and agents:**
|
||||
**CRITICAL - Clear division of labor between orchestrator and agents:**
|
||||
|
||||
| Responsibility | test-cycle-execute (Orchestrator) | @test-fix-agent (Executor) |
|
||||
|----------------|----------------------------|---------------------------|
|
||||
| Manage iteration loop | ✅ Controls loop flow | ❌ Executes single task |
|
||||
| Run CLI analysis (Gemini/Qwen) | ✅ Runs between agent tasks | ❌ Not involved |
|
||||
| Generate IMPL-fix-N.json | ✅ Creates task files | ❌ Not involved |
|
||||
| Run tests | ❌ Delegates to agent | ✅ Executes test command |
|
||||
| Apply fixes | ❌ Delegates to agent | ✅ Modifies code |
|
||||
| Detect test failures | ✅ Analyzes results and decides next action | ✅ Executes tests and reports outcomes |
|
||||
| Add tasks to queue | ✅ Manages queue | ❌ Not involved |
|
||||
| Update iteration state | ✅ Maintains overall iteration state | ✅ Updates individual task status only |
|
||||
| Manage iteration loop | Yes - Controls loop flow | No - Executes single task |
|
||||
| Run CLI analysis (Gemini/Qwen) | Yes - Runs between agent tasks | No - Not involved |
|
||||
| Generate IMPL-fix-N.json | Yes - Creates task files | No - Not involved |
|
||||
| Run tests | No - Delegates to agent | Yes - Executes test command |
|
||||
| Apply fixes | No - Delegates to agent | Yes - Modifies code |
|
||||
| Detect test failures | Yes - Analyzes results and decides next action | Yes - Executes tests and reports outcomes |
|
||||
| Add tasks to queue | Yes - Manages queue | No - Not involved |
|
||||
| Update iteration state | Yes - Maintains overall iteration state | Yes - Updates individual task status only |
|
||||
|
||||
**Key Principle**: Orchestrator manages the "what" and "when"; agents execute the "how".
|
||||
|
||||
**⚠️ ENFORCEMENT**: If test failures occur outside this orchestrator, do NOT handle them inline - always call `/workflow:test-cycle-execute` instead.
|
||||
**ENFORCEMENT**: If test failures occur outside this orchestrator, do NOT handle them inline - always call `/workflow:test-cycle-execute` instead.
|
||||
|
||||
## Execution Lifecycle
|
||||
|
||||
@@ -653,10 +653,3 @@ mv temp.json iteration-state.json
|
||||
5. **Verify No Regressions**: Check all tests pass, not just previously failing ones
|
||||
6. **Preserve Context**: All iteration artifacts saved for debugging
|
||||
|
||||
## Related Commands
|
||||
|
||||
- `/workflow:test-fix-gen` - Planning phase (creates initial tasks)
|
||||
- `/workflow:execute` - Standard workflow execution (no dynamic iteration)
|
||||
- `/workflow:status` - Check progress and iteration state
|
||||
- `/workflow:session:complete` - Mark session complete (auto-called on success)
|
||||
- `/task:create` - Manually create additional tasks if needed
|
||||
|
||||
@@ -13,7 +13,7 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
|
||||
|
||||
This command creates an independent test-fix workflow session for existing code. It orchestrates a 5-phase process to analyze implementation, generate test requirements, and create executable test generation and fix tasks.
|
||||
|
||||
**⚠️ CRITICAL - Command Scope**:
|
||||
**CRITICAL - Command Scope**:
|
||||
- **This command ONLY generates task JSON files** (IMPL-001.json, IMPL-002.json)
|
||||
- **Does NOT execute tests or apply fixes** - all execution happens in separate orchestrator
|
||||
- **Must call `/workflow:test-cycle-execute`** after this command to actually run tests and fixes
|
||||
@@ -274,7 +274,7 @@ Review artifacts:
|
||||
- Test plan: .workflow/[testSessionId]/IMPL_PLAN.md
|
||||
- Task list: .workflow/[testSessionId]/TODO_LIST.md
|
||||
|
||||
⚠️ CRITICAL - Next Steps:
|
||||
CRITICAL - Next Steps:
|
||||
1. Review IMPL_PLAN.md
|
||||
2. **MUST execute: /workflow:test-cycle-execute**
|
||||
- This command only generated task JSON files
|
||||
@@ -284,7 +284,7 @@ Review artifacts:
|
||||
|
||||
**TodoWrite**: Mark phase 5 completed
|
||||
|
||||
**⚠️ BOUNDARY NOTE**:
|
||||
**BOUNDARY NOTE**:
|
||||
- Command completes here - only task JSON files generated
|
||||
- All test execution, failure detection, CLI analysis, fix generation happens in `/workflow:test-cycle-execute`
|
||||
- This command does NOT handle test failures or apply fixes
|
||||
@@ -462,25 +462,23 @@ WFS-test-[session]/
|
||||
- Use `--use-codex` for autonomous fix application
|
||||
- Use `--cli-execute` for enhanced generation capabilities
|
||||
|
||||
### Related Commands
|
||||
## Related Commands
|
||||
|
||||
**Planning Phase**:
|
||||
- `/workflow:plan` - Create implementation workflow
|
||||
- `/workflow:session:start` - Initialize workflow session
|
||||
**Prerequisite Commands**:
|
||||
- `/workflow:plan` or `/workflow:execute` - Complete implementation session (for Session Mode)
|
||||
- None for Prompt Mode (ad-hoc test generation)
|
||||
|
||||
**Context Gathering**:
|
||||
- `/workflow:tools:test-context-gather` - Session-based context (Phase 2 for session mode)
|
||||
- `/workflow:tools:context-gather` - Prompt-based context (Phase 2 for prompt mode)
|
||||
**Called by This Command** (5 phases):
|
||||
- `/workflow:session:start` - Phase 1: Create independent test workflow session
|
||||
- `/workflow:tools:test-context-gather` - Phase 2 (Session Mode): Gather source session context
|
||||
- `/workflow:tools:context-gather` - Phase 2 (Prompt Mode): Analyze codebase directly
|
||||
- `/workflow:tools:test-concept-enhanced` - Phase 3: Generate test requirements using Gemini
|
||||
- `/workflow:tools:test-task-generate` - Phase 4: Generate test task JSONs with fix cycle specification
|
||||
- `/workflow:tools:test-task-generate --use-codex` - Phase 4: With automated Codex fixes (when `--use-codex` flag used)
|
||||
- `/workflow:tools:test-task-generate --cli-execute` - Phase 4: With CLI execution mode (when `--cli-execute` flag used)
|
||||
|
||||
**Analysis & Task Generation**:
|
||||
- `/workflow:tools:test-concept-enhanced` - Gemini test analysis (Phase 3)
|
||||
- `/workflow:tools:test-task-generate` - Generate test tasks (Phase 4)
|
||||
**Follow-up Commands**:
|
||||
- `/workflow:status` - Review generated test tasks
|
||||
- `/workflow:test-cycle-execute` - Execute test generation and iterative fix cycles
|
||||
- `/workflow:execute` - Standard execution of generated test tasks
|
||||
|
||||
**Execution**:
|
||||
- `/workflow:test-cycle-execute` - Execute test-fix workflow (recommended for IMPL-002)
|
||||
- `/workflow:execute` - Execute standard workflow tasks
|
||||
- `/workflow:status` - Check task progress
|
||||
|
||||
**Review & Management**:
|
||||
- `/workflow:review` - Review workflow results
|
||||
- `/workflow:session:complete` - Mark session complete
|
||||
|
||||
@@ -24,7 +24,7 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
|
||||
3. Analyze implementation with concept-enhanced → Parse ANALYSIS_RESULTS.md
|
||||
4. Generate test task from analysis → Return summary
|
||||
|
||||
**⚠️ Command Scope**: This command ONLY prepares test workflow artifacts. It does NOT execute tests or implementation. Task execution requires separate user action.
|
||||
**Command Scope**: This command ONLY prepares test workflow artifacts. It does NOT execute tests or implementation. Task execution requires separate user action.
|
||||
|
||||
## Core Rules
|
||||
|
||||
@@ -36,7 +36,7 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
|
||||
6. **Track Progress**: Update TodoWrite after every phase completion
|
||||
7. **Automatic Detection**: context-gather auto-detects test session and gathers source session context
|
||||
8. **Parse --use-codex Flag**: Extract flag from arguments and pass to Phase 4 (test-task-generate)
|
||||
9. **⚠️ Command Boundary**: This command ends at Phase 5 summary. Test execution is NOT part of this command.
|
||||
9. **Command Boundary**: This command ends at Phase 5 summary. Test execution is NOT part of this command.
|
||||
|
||||
## 5-Phase Execution
|
||||
|
||||
@@ -177,13 +177,13 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
|
||||
|
||||
---
|
||||
|
||||
### Phase 5: Return Summary (⚠️ Command Ends Here)
|
||||
### Phase 5: Return Summary (Command Ends Here)
|
||||
|
||||
**⚠️ Important**: This is the final phase of `/workflow:test-gen`. The command completes and returns control to the user. No automatic execution occurs.
|
||||
**Important**: This is the final phase of `/workflow:test-gen`. The command completes and returns control to the user. No automatic execution occurs.
|
||||
|
||||
**Return to User**:
|
||||
```
|
||||
✅ Test workflow preparation complete!
|
||||
Test workflow preparation complete!
|
||||
|
||||
Source Session: [sourceSessionId]
|
||||
Test Session: [testSessionId]
|
||||
@@ -198,17 +198,17 @@ Test Framework: [detected framework]
|
||||
Test Files to Generate: [count]
|
||||
Fix Mode: [Manual|Codex Automated] (based on --use-codex flag)
|
||||
|
||||
📋 Review Generated Artifacts:
|
||||
Review Generated Artifacts:
|
||||
- Test plan: .workflow/[testSessionId]/IMPL_PLAN.md
|
||||
- Task list: .workflow/[testSessionId]/TODO_LIST.md
|
||||
- Analysis: .workflow/[testSessionId]/.process/TEST_ANALYSIS_RESULTS.md
|
||||
|
||||
⚠️ Ready for execution. Use appropriate workflow commands to proceed.
|
||||
Ready for execution. Use appropriate workflow commands to proceed.
|
||||
```
|
||||
|
||||
**TodoWrite**: Mark phase 5 completed
|
||||
|
||||
**⚠️ Command Boundary**: After this phase, the command terminates and returns to user prompt.
|
||||
**Command Boundary**: After this phase, the command terminates and returns to user prompt.
|
||||
|
||||
---
|
||||
|
||||
@@ -244,7 +244,7 @@ Update status to `in_progress` when starting each phase, mark `completed` when d
|
||||
│ ↓ │
|
||||
│ Phase 5: Return summary │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
⚠️ COMMAND ENDS - Control returns to user
|
||||
COMMAND ENDS - Control returns to user
|
||||
|
||||
Artifacts Created:
|
||||
├── .workflow/WFS-test-[session]/
|
||||
@@ -330,8 +330,18 @@ See `/workflow:tools:test-task-generate` for complete JSON schemas.
|
||||
|
||||
## Related Commands
|
||||
|
||||
- `/workflow:tools:test-context-gather` - Phase 2 (coverage analysis)
|
||||
- `/workflow:tools:test-concept-enhanced` - Phase 3 (Gemini test analysis)
|
||||
- `/workflow:tools:test-task-generate` - Phase 4 (task generation)
|
||||
- `/workflow:execute` - Execute workflow
|
||||
- `/workflow:status` - Check progress
|
||||
**Prerequisite Commands**:
|
||||
- `/workflow:plan` or `/workflow:execute` - Complete implementation session that needs test validation
|
||||
|
||||
**Called by This Command** (5 phases):
|
||||
- `/workflow:session:start` - Phase 1: Create independent test workflow session
|
||||
- `/workflow:tools:test-context-gather` - Phase 2: Analyze test coverage and gather source session context
|
||||
- `/workflow:tools:test-concept-enhanced` - Phase 3: Generate test requirements and strategy using Gemini
|
||||
- `/workflow:tools:test-task-generate` - Phase 4: Generate test generation and execution task JSONs
|
||||
- `/workflow:tools:test-task-generate --use-codex` - Phase 4: With automated Codex fixes (when `--use-codex` flag used)
|
||||
- `/workflow:tools:test-task-generate --cli-execute` - Phase 4: With CLI execution mode (when `--cli-execute` flag used)
|
||||
|
||||
**Follow-up Commands**:
|
||||
- `/workflow:status` - Review generated test tasks
|
||||
- `/workflow:test-cycle-execute` - Execute test generation and fix cycles
|
||||
- `/workflow:execute` - Execute generated test tasks
|
||||
@@ -19,6 +19,7 @@ Autonomous task JSON and IMPL_PLAN.md generation using action-planning-agent wit
|
||||
- **MCP-Enhanced**: Use MCP tools for advanced code analysis and research
|
||||
- **Pre-Selected Templates**: Command selects correct template based on `--cli-execute` flag **before** invoking agent
|
||||
- **Agent Simplicity**: Agent receives pre-selected template and focuses only on content generation
|
||||
- **Path Clarity**: All `focus_paths` prefer absolute paths (e.g., `D:\\project\\src\\module`), or clear relative paths from project root (e.g., `./src/module`)
|
||||
|
||||
## Execution Lifecycle
|
||||
|
||||
|
||||
@@ -49,6 +49,7 @@ Generate TDD-specific tasks from analysis results with complete Red-Green-Refact
|
||||
- **Feature-Complete Tasks**: Each task contains complete Red-Green-Refactor cycle
|
||||
- **Phase-Explicit**: Internal phases clearly marked in flow_control.implementation_approach
|
||||
- **Task Merging**: Prefer single task per feature over decomposition
|
||||
- **Path Clarity**: All `focus_paths` prefer absolute paths (e.g., `D:\\project\\src\\module`), or clear relative paths from project root (e.g., `./src/module`)
|
||||
- **Artifact-Aware**: Integrates brainstorming outputs
|
||||
- **Memory-First**: Reuse loaded documents from memory
|
||||
- **Context-Aware**: Analyzes existing codebase and test patterns
|
||||
@@ -157,7 +158,7 @@ For each feature, generate task(s) with ID format:
|
||||
"expected_failure": "Why test should fail initially"
|
||||
}
|
||||
],
|
||||
"focus_paths": ["src/path/", "tests/path/"], // Files to modify
|
||||
"focus_paths": ["D:\\project\\src\\path", "./tests/path"], // Absolute or clear relative paths from project root
|
||||
"acceptance": [ // Success criteria
|
||||
"All tests pass (Red → Green)",
|
||||
"Code refactored (Refactor complete)",
|
||||
|
||||
@@ -40,6 +40,7 @@ This command is built on a set of core principles to ensure efficient and reliab
|
||||
- **Role Analysis-Driven**: All generated tasks originate from role-specific `analysis.md` files (enhanced in synthesis phase), ensuring direct link between requirements/design and implementation
|
||||
- **Artifact-Aware**: Automatically detects and integrates all brainstorming outputs (role analyses, guidance-specification.md, enhancements) to enrich task context
|
||||
- **Context-Rich**: Embeds comprehensive context (requirements, focus paths, acceptance criteria, artifact references) directly into each task JSON
|
||||
- **Path Clarity**: All `focus_paths` prefer absolute paths (e.g., `D:\\project\\src\\module`), or clear relative paths from project root (e.g., `./src/module`)
|
||||
- **Flow-Control Ready**: Pre-defines clear execution sequence (`pre_analysis`, `implementation_approach`) within each task
|
||||
- **Memory-First**: Prioritizes using documents already loaded in conversation memory to avoid redundant file operations
|
||||
- **Mode-Flexible**: Supports both agent-driven execution (default) and CLI tool execution (with `--cli-execute` flag)
|
||||
@@ -182,7 +183,7 @@ This enhanced 5-field schema embeds all necessary context, artifacts, and execut
|
||||
},
|
||||
"context": {
|
||||
"requirements": ["Clear requirement from analysis"],
|
||||
"focus_paths": ["src/module/path", "tests/module/path"],
|
||||
"focus_paths": ["D:\\project\\src\\module\\path", "./tests/module/path"],
|
||||
"acceptance": ["Measurable acceptance criterion"],
|
||||
"parent": "IMPL-N",
|
||||
"depends_on": ["IMPL-N.M"],
|
||||
|
||||
@@ -170,128 +170,318 @@ ELSE:
|
||||
extraction_insufficient = true
|
||||
```
|
||||
|
||||
### Step 2: Interactive Question Workflow (Agent)
|
||||
### Step 2: Generate Animation Questions (Main Flow)
|
||||
|
||||
```bash
|
||||
# If extraction failed or insufficient, use interactive questioning
|
||||
IF extraction_insufficient OR extraction_mode == "interactive":
|
||||
REPORT: "🤔 Launching interactive animation specification mode"
|
||||
REPORT: "🤔 Interactive animation specification mode"
|
||||
REPORT: " Context: {has_design_context ? 'Aligning with design tokens' : 'Standalone animation system'}"
|
||||
REPORT: " Focus: {focus_types}"
|
||||
|
||||
# Launch ui-design-agent for interactive questioning
|
||||
Task(ui-design-agent): `
|
||||
[ANIMATION_SPECIFICATION_TASK]
|
||||
Guide user through animation design decisions via structured questions
|
||||
# Determine question categories based on focus_types
|
||||
question_categories = []
|
||||
IF "all" IN focus_types OR "transitions" IN focus_types:
|
||||
question_categories.append("timing_scale")
|
||||
question_categories.append("easing_philosophy")
|
||||
|
||||
SESSION: {session_id} | MODE: interactive | BASE_PATH: {base_path}
|
||||
IF "all" IN focus_types OR "interactions" IN focus_types OR "hover" IN focus_types:
|
||||
question_categories.append("button_interactions")
|
||||
question_categories.append("card_interactions")
|
||||
question_categories.append("input_interactions")
|
||||
|
||||
## Context
|
||||
- Design tokens available: {has_design_context}
|
||||
- Focus areas: {focus_types}
|
||||
- Extracted data: {animations_extracted ? "Partial CSS data available" : "No CSS data"}
|
||||
IF "all" IN focus_types OR "page" IN focus_types:
|
||||
question_categories.append("page_transitions")
|
||||
|
||||
## Interactive Workflow
|
||||
IF "all" IN focus_types OR "loading" IN focus_types:
|
||||
question_categories.append("loading_states")
|
||||
|
||||
For each animation category, ASK user and WAIT for response:
|
||||
IF "all" IN focus_types OR "scroll" IN focus_types:
|
||||
question_categories.append("scroll_animations")
|
||||
```
|
||||
|
||||
### 1. Transition Duration Scale
|
||||
QUESTION: "What timing scale feels right for your design?"
|
||||
OPTIONS:
|
||||
- "Fast & Snappy" (100-200ms transitions)
|
||||
- "Balanced" (200-400ms transitions)
|
||||
- "Smooth & Deliberate" (400-600ms transitions)
|
||||
- "Custom" (specify values)
|
||||
### Step 3: Output Questions in Text Format (Main Flow)
|
||||
|
||||
### 2. Easing Philosophy
|
||||
QUESTION: "What easing style matches your brand?"
|
||||
OPTIONS:
|
||||
- "Linear" (constant speed, technical feel)
|
||||
- "Ease-Out" (fast start, natural feel)
|
||||
- "Ease-In-Out" (balanced, polished feel)
|
||||
- "Spring/Bounce" (playful, modern feel)
|
||||
- "Custom" (specify cubic-bezier)
|
||||
```markdown
|
||||
# Generate and output structured questions
|
||||
REPORT: ""
|
||||
REPORT: "===== 动画规格交互式配置 ====="
|
||||
REPORT: ""
|
||||
|
||||
### 3. Common Interactions (Ask for each)
|
||||
FOR interaction IN ["button-hover", "link-hover", "card-hover", "modal-open", "dropdown-toggle"]:
|
||||
QUESTION: "How should {interaction} animate?"
|
||||
OPTIONS:
|
||||
- "Subtle" (color/opacity change only)
|
||||
- "Lift" (scale + shadow increase)
|
||||
- "Slide" (transform translateY)
|
||||
- "Fade" (opacity transition)
|
||||
- "None" (no animation)
|
||||
- "Custom" (describe behavior)
|
||||
question_number = 1
|
||||
questions_output = []
|
||||
|
||||
### 4. Page Transitions
|
||||
QUESTION: "Should page/route changes have animations?"
|
||||
IF YES:
|
||||
ASK: "What style?"
|
||||
OPTIONS:
|
||||
- "Fade" (crossfade between views)
|
||||
- "Slide" (swipe left/right)
|
||||
- "Zoom" (scale in/out)
|
||||
- "None"
|
||||
# Q1: Timing Scale (if included)
|
||||
IF "timing_scale" IN question_categories:
|
||||
REPORT: "【问题{question_number} - 时间尺度】您的设计需要什么样的过渡速度?"
|
||||
REPORT: "a) 快速敏捷"
|
||||
REPORT: " 说明:100-200ms 过渡,适合工具型应用和即时反馈场景"
|
||||
REPORT: "b) 平衡适中"
|
||||
REPORT: " 说明:200-400ms 过渡,通用选择,符合多数用户预期"
|
||||
REPORT: "c) 流畅舒缓"
|
||||
REPORT: " 说明:400-600ms 过渡,适合品牌展示和沉浸式体验"
|
||||
REPORT: "d) 自定义"
|
||||
REPORT: " 说明:需要指定具体数值和使用场景"
|
||||
REPORT: ""
|
||||
questions_output.append({id: question_number, category: "timing_scale", options: ["a", "b", "c", "d"]})
|
||||
question_number += 1
|
||||
|
||||
### 5. Loading States
|
||||
QUESTION: "What loading animation style?"
|
||||
OPTIONS:
|
||||
- "Spinner" (rotating circle)
|
||||
- "Pulse" (opacity pulse)
|
||||
- "Skeleton" (shimmer effect)
|
||||
- "Progress Bar" (linear fill)
|
||||
- "Custom" (describe)
|
||||
# Q2: Easing Philosophy (if included)
|
||||
IF "easing_philosophy" IN question_categories:
|
||||
REPORT: "【问题{question_number} - 缓动风格】哪种缓动曲线符合您的品牌调性?"
|
||||
REPORT: "a) 线性匀速"
|
||||
REPORT: " 说明:恒定速度,技术感和精确性,适合数据可视化"
|
||||
REPORT: "b) 快入慢出"
|
||||
REPORT: " 说明:快速启动自然减速,最接近物理世界,通用推荐"
|
||||
REPORT: "c) 慢入慢出"
|
||||
REPORT: " 说明:平滑对称,精致优雅,适合高端品牌"
|
||||
REPORT: "d) 弹性效果"
|
||||
REPORT: " 说明:Spring/Bounce 回弹,活泼现代,适合互动性强的应用"
|
||||
REPORT: ""
|
||||
questions_output.append({id: question_number, category: "easing_philosophy", options: ["a", "b", "c", "d"]})
|
||||
question_number += 1
|
||||
|
||||
### 6. Micro-interactions
|
||||
QUESTION: "Should form inputs have micro-interactions?"
|
||||
IF YES:
|
||||
ASK: "What interactions?"
|
||||
OPTIONS:
|
||||
- "Focus state animation" (border/shadow transition)
|
||||
- "Error shake" (horizontal shake on error)
|
||||
- "Success check" (checkmark animation)
|
||||
- "All of the above"
|
||||
# Q3-5: Interaction Animations (button, card, input - if included)
|
||||
IF "button_interactions" IN question_categories:
|
||||
REPORT: "【问题{question_number} - 按钮交互】按钮悬停/点击时如何反馈?"
|
||||
REPORT: "a) 微妙变化"
|
||||
REPORT: " 说明:仅颜色/透明度变化,适合简约设计"
|
||||
REPORT: "b) 抬升效果"
|
||||
REPORT: " 说明:轻微缩放+阴影加深,增强物理感知"
|
||||
REPORT: "c) 滑动移位"
|
||||
REPORT: " 说明:Transform translateY,视觉引导明显"
|
||||
REPORT: "d) 无动画"
|
||||
REPORT: " 说明:静态交互,性能优先或特定品牌要求"
|
||||
REPORT: ""
|
||||
questions_output.append({id: question_number, category: "button_interactions", options: ["a", "b", "c", "d"]})
|
||||
question_number += 1
|
||||
|
||||
### 7. Scroll Animations
|
||||
QUESTION: "Should elements animate on scroll?"
|
||||
IF YES:
|
||||
ASK: "What scroll animation style?"
|
||||
OPTIONS:
|
||||
- "Fade In" (opacity 0→1)
|
||||
- "Slide Up" (translateY + fade)
|
||||
- "Scale In" (scale 0.9→1 + fade)
|
||||
- "Stagger" (sequential delays)
|
||||
- "None"
|
||||
IF "card_interactions" IN question_categories:
|
||||
REPORT: "【问题{question_number} - 卡片交互】卡片悬停时的动画效果?"
|
||||
REPORT: "a) 阴影加深"
|
||||
REPORT: " 说明:Box-shadow 变化,层次感增强"
|
||||
REPORT: "b) 上浮效果"
|
||||
REPORT: " 说明:Transform translateY(-4px),明显的空间层次"
|
||||
REPORT: "c) 缩放放大"
|
||||
REPORT: " 说明:Scale(1.02),突出焦点内容"
|
||||
REPORT: "d) 无动画"
|
||||
REPORT: " 说明:静态卡片,性能或设计考量"
|
||||
REPORT: ""
|
||||
questions_output.append({id: question_number, category: "card_interactions", options: ["a", "b", "c", "d"]})
|
||||
question_number += 1
|
||||
|
||||
## Output Generation
|
||||
IF "input_interactions" IN question_categories:
|
||||
REPORT: "【问题{question_number} - 表单交互】输入框是否需要微交互反馈?"
|
||||
REPORT: "a) 聚焦动画"
|
||||
REPORT: " 说明:边框/阴影过渡,清晰的状态指示"
|
||||
REPORT: "b) 错误抖动"
|
||||
REPORT: " 说明:水平shake动画,错误提示更明显"
|
||||
REPORT: "c) 成功勾选"
|
||||
REPORT: " 说明:Checkmark 动画,完成反馈"
|
||||
REPORT: "d) 全部包含"
|
||||
REPORT: " 说明:聚焦+错误+成功的完整反馈体系"
|
||||
REPORT: "e) 无微交互"
|
||||
REPORT: " 说明:标准表单,无额外动画"
|
||||
REPORT: ""
|
||||
questions_output.append({id: question_number, category: "input_interactions", options: ["a", "b", "c", "d", "e"]})
|
||||
question_number += 1
|
||||
|
||||
Based on user responses, generate structured data:
|
||||
# Q6: Page Transitions (if included)
|
||||
IF "page_transitions" IN question_categories:
|
||||
REPORT: "【问题{question_number} - 页面过渡】页面/路由切换是否需要过渡动画?"
|
||||
REPORT: "a) 淡入淡出"
|
||||
REPORT: " 说明:Crossfade 效果,平滑过渡不突兀"
|
||||
REPORT: "b) 滑动切换"
|
||||
REPORT: " 说明:Swipe left/right,方向性导航"
|
||||
REPORT: "c) 缩放过渡"
|
||||
REPORT: " 说明:Scale in/out,空间层次感"
|
||||
REPORT: "d) 无过渡"
|
||||
REPORT: " 说明:即时切换,性能优先"
|
||||
REPORT: ""
|
||||
questions_output.append({id: question_number, category: "page_transitions", options: ["a", "b", "c", "d"]})
|
||||
question_number += 1
|
||||
|
||||
1. Create animation-specification.json with user choices:
|
||||
- timing_scale (fast/balanced/slow/custom)
|
||||
- easing_philosophy (linear/ease-out/ease-in-out/spring)
|
||||
- interactions: {interaction_name: {type, properties, timing}}
|
||||
- page_transitions: {enabled, style, duration}
|
||||
- loading_animations: {style, duration}
|
||||
- scroll_animations: {enabled, style, stagger_delay}
|
||||
# Q7: Loading States (if included)
|
||||
IF "loading_states" IN question_categories:
|
||||
REPORT: "【问题{question_number} - 加载状态】加载时使用何种动画风格?"
|
||||
REPORT: "a) 旋转加载器"
|
||||
REPORT: " 说明:Spinner 圆形旋转,通用加载指示"
|
||||
REPORT: "b) 脉冲闪烁"
|
||||
REPORT: " 说明:Opacity pulse,轻量级反馈"
|
||||
REPORT: "c) 骨架屏"
|
||||
REPORT: " 说明:Shimmer effect,内容占位预览"
|
||||
REPORT: "d) 进度条"
|
||||
REPORT: " 说明:Linear fill,进度量化展示"
|
||||
REPORT: ""
|
||||
questions_output.append({id: question_number, category: "loading_states", options: ["a", "b", "c", "d"]})
|
||||
question_number += 1
|
||||
|
||||
2. Write to {base_path}/.intermediates/animation-analysis/animation-specification.json
|
||||
# Q8: Scroll Animations (if included)
|
||||
IF "scroll_animations" IN question_categories:
|
||||
REPORT: "【问题{question_number} - 滚动动画】元素是否在滚动时触发动画?"
|
||||
REPORT: "a) 淡入出现"
|
||||
REPORT: " 说明:Opacity 0→1,渐进式内容呈现"
|
||||
REPORT: "b) 上滑出现"
|
||||
REPORT: " 说明:TranslateY + fade,方向性引导"
|
||||
REPORT: "c) 缩放淡入"
|
||||
REPORT: " 说明:Scale 0.9→1 + fade,聚焦效果"
|
||||
REPORT: "d) 交错延迟"
|
||||
REPORT: " 说明:Stagger 序列动画,列表渐次呈现"
|
||||
REPORT: "e) 无滚动动画"
|
||||
REPORT: " 说明:静态内容,性能或可访问性考量"
|
||||
REPORT: ""
|
||||
questions_output.append({id: question_number, category: "scroll_animations", options: ["a", "b", "c", "d", "e"]})
|
||||
question_number += 1
|
||||
|
||||
## Critical Requirements
|
||||
- ✅ Use Write() tool immediately for specification file
|
||||
- ✅ Wait for user response after EACH question before proceeding
|
||||
- ✅ Validate responses and ask for clarification if needed
|
||||
- ✅ Provide sensible defaults if user skips questions
|
||||
- ❌ NO external research or MCP calls
|
||||
`
|
||||
REPORT: "支持格式:"
|
||||
REPORT: "- 空格分隔:1a 2b 3c"
|
||||
REPORT: "- 逗号分隔:1a,2b,3c"
|
||||
REPORT: "- 自由组合:1a 2b,3c"
|
||||
REPORT: ""
|
||||
REPORT: "请输入您的选择:"
|
||||
```
|
||||
|
||||
### Step 4: Wait for User Input (Main Flow)
|
||||
|
||||
```javascript
|
||||
# Wait for user input
|
||||
user_raw_input = WAIT_FOR_USER_INPUT()
|
||||
|
||||
# Store raw input for debugging
|
||||
REPORT: "收到输入: {user_raw_input}"
|
||||
```
|
||||
|
||||
### Step 5: Parse User Answers (Main Flow)
|
||||
|
||||
```javascript
|
||||
# Intelligent input parsing (support multiple formats)
|
||||
answers = {}
|
||||
|
||||
# Parse input using intelligent matching
|
||||
# Support formats: "1a 2b 3c", "1a,2b,3c", "1a 2b,3c"
|
||||
parsed_responses = PARSE_USER_INPUT(user_raw_input, questions_output)
|
||||
|
||||
# Validate parsing
|
||||
IF parsed_responses.is_valid:
|
||||
# Map question numbers to categories
|
||||
FOR response IN parsed_responses.answers:
|
||||
question_id = response.question_id
|
||||
selected_option = response.option
|
||||
|
||||
# Find category for this question
|
||||
FOR question IN questions_output:
|
||||
IF question.id == question_id:
|
||||
category = question.category
|
||||
answers[category] = selected_option
|
||||
REPORT: "✅ 问题{question_id} ({category}): 选择 {selected_option}"
|
||||
break
|
||||
ELSE:
|
||||
REPORT: "❌ 输入格式无法识别,请参考格式示例重新输入:"
|
||||
REPORT: " 示例:1a 2b 3c 4d"
|
||||
# Return to Step 3 for re-input
|
||||
GOTO Step 3
|
||||
```
|
||||
|
||||
### Step 6: Write Animation Specification (Main Flow)
|
||||
|
||||
```javascript
|
||||
# Map user choices to specification structure
|
||||
specification = {
|
||||
"metadata": {
|
||||
"source": "interactive",
|
||||
"timestamp": NOW(),
|
||||
"focus_types": focus_types,
|
||||
"has_design_context": has_design_context
|
||||
},
|
||||
"timing_scale": MAP_TIMING_SCALE(answers.timing_scale),
|
||||
"easing_philosophy": MAP_EASING_PHILOSOPHY(answers.easing_philosophy),
|
||||
"interactions": {
|
||||
"button": MAP_BUTTON_INTERACTION(answers.button_interactions),
|
||||
"card": MAP_CARD_INTERACTION(answers.card_interactions),
|
||||
"input": MAP_INPUT_INTERACTION(answers.input_interactions)
|
||||
},
|
||||
"page_transitions": MAP_PAGE_TRANSITIONS(answers.page_transitions),
|
||||
"loading_animations": MAP_LOADING_STATES(answers.loading_states),
|
||||
"scroll_animations": MAP_SCROLL_ANIMATIONS(answers.scroll_animations)
|
||||
}
|
||||
|
||||
# Mapping functions (inline logic)
|
||||
FUNCTION MAP_TIMING_SCALE(option):
|
||||
SWITCH option:
|
||||
CASE "a": RETURN {scale: "fast", base_duration: "150ms", range: "100-200ms"}
|
||||
CASE "b": RETURN {scale: "balanced", base_duration: "300ms", range: "200-400ms"}
|
||||
CASE "c": RETURN {scale: "smooth", base_duration: "500ms", range: "400-600ms"}
|
||||
CASE "d": RETURN {scale: "custom", base_duration: "300ms", note: "User to provide values"}
|
||||
|
||||
FUNCTION MAP_EASING_PHILOSOPHY(option):
|
||||
SWITCH option:
|
||||
CASE "a": RETURN {style: "linear", curve: "linear"}
|
||||
CASE "b": RETURN {style: "ease-out", curve: "cubic-bezier(0, 0, 0.2, 1)"}
|
||||
CASE "c": RETURN {style: "ease-in-out", curve: "cubic-bezier(0.4, 0, 0.2, 1)"}
|
||||
CASE "d": RETURN {style: "spring", curve: "cubic-bezier(0.34, 1.56, 0.64, 1)"}
|
||||
|
||||
FUNCTION MAP_BUTTON_INTERACTION(option):
|
||||
SWITCH option:
|
||||
CASE "a": RETURN {type: "subtle", properties: ["color", "background-color", "opacity"]}
|
||||
CASE "b": RETURN {type: "lift", properties: ["transform", "box-shadow"], transform: "scale(1.02)"}
|
||||
CASE "c": RETURN {type: "slide", properties: ["transform"], transform: "translateY(-2px)"}
|
||||
CASE "d": RETURN {type: "none", properties: []}
|
||||
|
||||
FUNCTION MAP_CARD_INTERACTION(option):
|
||||
SWITCH option:
|
||||
CASE "a": RETURN {type: "shadow", properties: ["box-shadow"]}
|
||||
CASE "b": RETURN {type: "float", properties: ["transform", "box-shadow"], transform: "translateY(-4px)"}
|
||||
CASE "c": RETURN {type: "scale", properties: ["transform"], transform: "scale(1.02)"}
|
||||
CASE "d": RETURN {type: "none", properties: []}
|
||||
|
||||
FUNCTION MAP_INPUT_INTERACTION(option):
|
||||
SWITCH option:
|
||||
CASE "a": RETURN {enabled: ["focus"], focus: {properties: ["border-color", "box-shadow"]}}
|
||||
CASE "b": RETURN {enabled: ["error"], error: {animation: "shake", keyframes: "translateX"}}
|
||||
CASE "c": RETURN {enabled: ["success"], success: {animation: "checkmark", keyframes: "draw"}}
|
||||
CASE "d": RETURN {enabled: ["focus", "error", "success"]}
|
||||
CASE "e": RETURN {enabled: []}
|
||||
|
||||
FUNCTION MAP_PAGE_TRANSITIONS(option):
|
||||
SWITCH option:
|
||||
CASE "a": RETURN {enabled: true, style: "fade", animation: "fadeIn/fadeOut"}
|
||||
CASE "b": RETURN {enabled: true, style: "slide", animation: "slideLeft/slideRight"}
|
||||
CASE "c": RETURN {enabled: true, style: "zoom", animation: "zoomIn/zoomOut"}
|
||||
CASE "d": RETURN {enabled: false}
|
||||
|
||||
FUNCTION MAP_LOADING_STATES(option):
|
||||
SWITCH option:
|
||||
CASE "a": RETURN {style: "spinner", animation: "rotate", keyframes: "360deg"}
|
||||
CASE "b": RETURN {style: "pulse", animation: "pulse", keyframes: "opacity"}
|
||||
CASE "c": RETURN {style: "skeleton", animation: "shimmer", keyframes: "gradient-shift"}
|
||||
CASE "d": RETURN {style: "progress", animation: "fill", keyframes: "width"}
|
||||
|
||||
FUNCTION MAP_SCROLL_ANIMATIONS(option):
|
||||
SWITCH option:
|
||||
CASE "a": RETURN {enabled: true, style: "fade", animation: "fadeIn"}
|
||||
CASE "b": RETURN {enabled: true, style: "slideUp", animation: "slideUp", transform: "translateY(20px)"}
|
||||
CASE "c": RETURN {enabled: true, style: "scaleIn", animation: "scaleIn", transform: "scale(0.9)"}
|
||||
CASE "d": RETURN {enabled: true, style: "stagger", animation: "fadeIn", stagger_delay: "100ms"}
|
||||
CASE "e": RETURN {enabled: false}
|
||||
|
||||
# Write specification file
|
||||
output_path = "{base_path}/.intermediates/animation-analysis/animation-specification.json"
|
||||
Write(output_path, JSON.stringify(specification, indent=2))
|
||||
|
||||
REPORT: "✅ Animation specification saved to {output_path}"
|
||||
REPORT: " Proceeding to token synthesis..."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Phase 2 Output**: `animation-specification.json` (user preferences)
|
||||
|
||||
## Phase 3: Animation Token Synthesis (Agent)
|
||||
## Phase 3: Animation Token Synthesis (Agent - No User Interaction)
|
||||
|
||||
**Executor**: `Task(ui-design-agent)` for token generation
|
||||
|
||||
**⚠️ CRITICAL**: This phase has NO user interaction. Agent only reads existing data and generates tokens.
|
||||
|
||||
### Step 1: Load All Input Sources
|
||||
|
||||
```bash
|
||||
@@ -305,61 +495,96 @@ IF animations_extracted:
|
||||
user_specification = null
|
||||
IF exists({base_path}/.intermediates/animation-analysis/animation-specification.json):
|
||||
user_specification = Read(file)
|
||||
REPORT: "✅ Loaded user specification from Phase 2"
|
||||
ELSE:
|
||||
REPORT: "⚠️ No user specification found - using extracted CSS only"
|
||||
|
||||
design_tokens = null
|
||||
IF has_design_context:
|
||||
design_tokens = Read({base_path}/style-extraction/style-1/design-tokens.json)
|
||||
```
|
||||
|
||||
### Step 2: Launch Token Generation Task
|
||||
### Step 2: Launch Token Generation Task (Pure Synthesis)
|
||||
|
||||
```javascript
|
||||
Task(ui-design-agent): `
|
||||
[ANIMATION_TOKEN_GENERATION_TASK]
|
||||
Synthesize all animation data into production-ready animation tokens
|
||||
Synthesize animation data into production-ready tokens - NO user interaction
|
||||
|
||||
SESSION: {session_id} | BASE_PATH: {base_path}
|
||||
|
||||
## Input Sources
|
||||
1. Extracted CSS Animations: {JSON.stringify(extracted_animations) OR "None"}
|
||||
2. User Specification: {JSON.stringify(user_specification) OR "None"}
|
||||
3. Design Tokens Context: {JSON.stringify(design_tokens) OR "None"}
|
||||
## ⚠️ CRITICAL: Pure Synthesis Task
|
||||
- NO user questions or interaction
|
||||
- READ existing specification files ONLY
|
||||
- Generate tokens based on available data
|
||||
|
||||
## Input Sources (Read-Only)
|
||||
1. **Extracted CSS Animations** (if available):
|
||||
${extracted_animations.length > 0 ? JSON.stringify(extracted_animations) : "None - skip CSS data"}
|
||||
|
||||
2. **User Specification** (REQUIRED if Phase 2 ran):
|
||||
File: {base_path}/.intermediates/animation-analysis/animation-specification.json
|
||||
${user_specification ? "Status: ✅ Found - READ this file for user choices" : "Status: ⚠️ Not found - use CSS extraction only"}
|
||||
|
||||
3. **Design Tokens Context** (for alignment):
|
||||
${design_tokens ? JSON.stringify(design_tokens) : "None - standalone animation system"}
|
||||
|
||||
## Synthesis Rules
|
||||
|
||||
### Priority System
|
||||
1. User specification (highest priority)
|
||||
2. Extracted CSS values (medium priority)
|
||||
1. User specification from animation-specification.json (highest priority)
|
||||
2. Extracted CSS values from animations-*.json (medium priority)
|
||||
3. Industry best practices (fallback)
|
||||
|
||||
### Duration Normalization
|
||||
- Analyze all extracted durations
|
||||
- Cluster into 3-5 semantic scales: instant, fast, normal, slow, very-slow
|
||||
- IF user_specification.timing_scale EXISTS:
|
||||
Use user's chosen scale (fast/balanced/smooth/custom)
|
||||
- ELSE IF extracted CSS durations available:
|
||||
Cluster extracted durations into 3-5 semantic scales
|
||||
- ELSE:
|
||||
Use standard scale (instant:0ms, fast:150ms, normal:300ms, slow:500ms, very-slow:800ms)
|
||||
- Align with design token spacing scale if available
|
||||
|
||||
### Easing Standardization
|
||||
- Identify common easing functions from extracted data
|
||||
- Map to semantic names: linear, ease-in, ease-out, ease-in-out, spring
|
||||
- Convert all cubic-bezier values to standard format
|
||||
- IF user_specification.easing_philosophy EXISTS:
|
||||
Use user's chosen philosophy (linear/ease-out/ease-in-out/spring)
|
||||
- ELSE IF extracted CSS easings available:
|
||||
Identify common easing functions from CSS
|
||||
- ELSE:
|
||||
Use standard easings
|
||||
- Map to semantic names and convert to cubic-bezier format
|
||||
|
||||
### Animation Categorization
|
||||
Organize into:
|
||||
- transitions: Property-specific transitions (color, transform, opacity)
|
||||
- keyframe_animations: Named @keyframe animations
|
||||
- interactions: Interaction-specific presets (hover, focus, active)
|
||||
- micro_interactions: Small feedback animations
|
||||
- page_transitions: Route/view change animations
|
||||
- scroll_animations: Scroll-triggered animations
|
||||
- **duration**: Timing scale (instant, fast, normal, slow, very-slow)
|
||||
- **easing**: Easing functions (linear, ease-in, ease-out, ease-in-out, spring)
|
||||
- **transitions**: Property-specific transitions (color, transform, opacity, etc.)
|
||||
- **keyframes**: Named @keyframe animations (fadeIn, slideInUp, pulse, etc.)
|
||||
- **interactions**: Interaction-specific presets (button-hover, card-hover, input-focus, etc.)
|
||||
- **page_transitions**: Route/view change animations (if user enabled)
|
||||
- **scroll_animations**: Scroll-triggered animations (if user enabled)
|
||||
|
||||
### User Specification Integration
|
||||
IF user_specification EXISTS:
|
||||
- Map user choices to token values:
|
||||
* timing_scale → duration values
|
||||
* easing_philosophy → easing curves
|
||||
* interactions.button → interactions.button-hover token
|
||||
* interactions.card → interactions.card-hover token
|
||||
* interactions.input → micro-interaction tokens
|
||||
* page_transitions → page_transitions tokens
|
||||
* loading_animations → loading state tokens
|
||||
* scroll_animations → scroll_animations tokens
|
||||
|
||||
## Generate Files
|
||||
|
||||
### 1. animation-tokens.json
|
||||
Complete animation token structure:
|
||||
Complete animation token structure using var() references:
|
||||
|
||||
{
|
||||
"duration": {
|
||||
"instant": "0ms",
|
||||
"fast": "150ms",
|
||||
"fast": "150ms", # Adjust based on user_specification.timing_scale
|
||||
"normal": "300ms",
|
||||
"slow": "500ms",
|
||||
"very-slow": "800ms"
|
||||
@@ -367,7 +592,7 @@ Task(ui-design-agent): `
|
||||
"easing": {
|
||||
"linear": "linear",
|
||||
"ease-in": "cubic-bezier(0.4, 0, 1, 1)",
|
||||
"ease-out": "cubic-bezier(0, 0, 0.2, 1)",
|
||||
"ease-out": "cubic-bezier(0, 0, 0.2, 1)", # Adjust based on user_specification.easing_philosophy
|
||||
"ease-in-out": "cubic-bezier(0.4, 0, 0.2, 1)",
|
||||
"spring": "cubic-bezier(0.34, 1.56, 0.64, 1)"
|
||||
},
|
||||
@@ -389,66 +614,74 @@ Task(ui-design-agent): `
|
||||
}
|
||||
},
|
||||
"keyframes": {
|
||||
"fadeIn": {
|
||||
"0%": {"opacity": "0"},
|
||||
"100%": {"opacity": "1"}
|
||||
},
|
||||
"slideInUp": {
|
||||
"0%": {"transform": "translateY(20px)", "opacity": "0"},
|
||||
"100%": {"transform": "translateY(0)", "opacity": "1"}
|
||||
},
|
||||
"pulse": {
|
||||
"0%, 100%": {"opacity": "1"},
|
||||
"50%": {"opacity": "0.7"}
|
||||
}
|
||||
"fadeIn": {"0%": {"opacity": "0"}, "100%": {"opacity": "1"}},
|
||||
"slideInUp": {"0%": {"transform": "translateY(20px)", "opacity": "0"}, "100%": {"transform": "translateY(0)", "opacity": "1"}},
|
||||
"pulse": {"0%, 100%": {"opacity": "1"}, "50%": {"opacity": "0.7"}},
|
||||
# Add more keyframes based on user_specification choices
|
||||
},
|
||||
"interactions": {
|
||||
"button-hover": {
|
||||
# Map from user_specification.interactions.button
|
||||
"properties": ["background-color", "transform"],
|
||||
"duration": "var(--duration-fast)",
|
||||
"easing": "var(--easing-ease-out)",
|
||||
"transform": "scale(1.02)"
|
||||
},
|
||||
"card-hover": {
|
||||
# Map from user_specification.interactions.card
|
||||
"properties": ["box-shadow", "transform"],
|
||||
"duration": "var(--duration-normal)",
|
||||
"easing": "var(--easing-ease-out)",
|
||||
"transform": "translateY(-4px)"
|
||||
}
|
||||
# Add input-focus, modal-open, dropdown-toggle based on user choices
|
||||
},
|
||||
"page_transitions": {
|
||||
# IF user_specification.page_transitions.enabled == true
|
||||
"fade": {
|
||||
"duration": "var(--duration-normal)",
|
||||
"enter": "fadeIn",
|
||||
"exit": "fadeOut"
|
||||
}
|
||||
# Add slide, zoom based on user_specification.page_transitions.style
|
||||
},
|
||||
"scroll_animations": {
|
||||
# IF user_specification.scroll_animations.enabled == true
|
||||
"default": {
|
||||
"animation": "fadeInUp",
|
||||
"animation": "fadeIn", # From user_specification.scroll_animations.style
|
||||
"duration": "var(--duration-slow)",
|
||||
"easing": "var(--easing-ease-out)",
|
||||
"threshold": "0.1",
|
||||
"stagger_delay": "100ms"
|
||||
"stagger_delay": "100ms" # From user_specification if stagger chosen
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
### 2. animation-guide.md
|
||||
Comprehensive usage guide:
|
||||
- Animation philosophy and rationale
|
||||
- Duration scale explanation
|
||||
- Easing function usage guidelines
|
||||
- Interaction animation patterns
|
||||
- Implementation examples (CSS and JS)
|
||||
- Accessibility considerations (prefers-reduced-motion)
|
||||
- Performance best practices
|
||||
Comprehensive usage guide with sections:
|
||||
- **Animation Philosophy**: Rationale from user choices and CSS analysis
|
||||
- **Duration Scale**: Explanation of timing values and usage contexts
|
||||
- **Easing Functions**: When to use each easing curve
|
||||
- **Transition Presets**: Property-specific transition guidelines
|
||||
- **Keyframe Animations**: Available animations and use cases
|
||||
- **Interaction Patterns**: Button, card, input animation examples
|
||||
- **Page Transitions**: Route change animation implementation (if enabled)
|
||||
- **Scroll Animations**: Scroll-trigger setup and configuration (if enabled)
|
||||
- **Implementation Examples**: CSS and JavaScript code samples
|
||||
- **Accessibility**: prefers-reduced-motion media query setup
|
||||
- **Performance Best Practices**: Hardware acceleration, will-change usage
|
||||
|
||||
## Output File Paths
|
||||
- animation-tokens.json: {base_path}/animation-extraction/animation-tokens.json
|
||||
- animation-guide.md: {base_path}/animation-extraction/animation-guide.md
|
||||
|
||||
## Critical Requirements
|
||||
- ✅ READ animation-specification.json if it exists (from Phase 2)
|
||||
- ✅ Use Write() tool immediately for both files
|
||||
- ✅ Ensure all tokens use CSS Custom Property format: var(--duration-fast)
|
||||
- ✅ All tokens use CSS Custom Property format: var(--duration-fast)
|
||||
- ✅ Include prefers-reduced-motion media query guidance
|
||||
- ✅ Validate all cubic-bezier values are valid
|
||||
- ✅ Validate all cubic-bezier values are valid (4 numbers between 0-1)
|
||||
- ❌ NO user questions or interaction in this phase
|
||||
- ❌ NO external research or MCP calls
|
||||
`
|
||||
```
|
||||
@@ -487,8 +720,8 @@ bash(ls -lh {base_path}/animation-extraction/)
|
||||
TodoWrite({todos: [
|
||||
{content: "Setup and input validation", status: "completed", activeForm: "Validating inputs"},
|
||||
{content: "CSS animation extraction (auto mode)", status: "completed", activeForm: "Extracting from CSS"},
|
||||
{content: "Interactive specification (fallback)", status: "completed", activeForm: "Collecting user input"},
|
||||
{content: "Animation token synthesis (agent)", status: "completed", activeForm: "Generating tokens"},
|
||||
{content: "Interactive specification (main flow)", status: "completed", activeForm: "Collecting user input in main flow"},
|
||||
{content: "Animation token synthesis (agent - no interaction)", status: "completed", activeForm: "Generating tokens via agent"},
|
||||
{content: "Verify output files", status: "completed", activeForm: "Verifying files"}
|
||||
]});
|
||||
```
|
||||
@@ -506,7 +739,7 @@ Configuration:
|
||||
- ✅ CSS extracted from {len(url_list)} URL(s)
|
||||
}
|
||||
{IF user_specification:
|
||||
- ✅ User specification via interactive mode
|
||||
- ✅ User specification via interactive mode (main flow)
|
||||
}
|
||||
{IF has_design_context:
|
||||
- ✅ Aligned with existing design tokens
|
||||
@@ -652,11 +885,12 @@ ERROR: Invalid cubic-bezier values
|
||||
|
||||
- **Auto-Trigger CSS Extraction** - Automatically extracts animations when --urls provided
|
||||
- **Hybrid Strategy** - Combines CSS extraction with interactive specification
|
||||
- **Main Flow Interaction** - User questions in main flow, agent only for token synthesis
|
||||
- **Intelligent Fallback** - Gracefully handles extraction failures
|
||||
- **Context-Aware** - Aligns with existing design tokens
|
||||
- **Production-Ready** - CSS var() format, accessibility support
|
||||
- **Comprehensive Coverage** - Transitions, keyframes, interactions, scroll animations
|
||||
- **Agent-Driven** - Autonomous token generation with ui-design-agent
|
||||
- **Separated Concerns** - User decisions (Phase 2 main flow) → Token generation (Phase 3 agent)
|
||||
|
||||
## Integration
|
||||
|
||||
|
||||
@@ -129,7 +129,10 @@ Task(ui-design-agent): `
|
||||
## Reference
|
||||
- Layout inspiration: Read("{base_path}/.intermediates/layout-analysis/inspirations/{target}-layout-ideas.txt")
|
||||
- Design tokens: Read("{base_path}/style-extraction/style-{style_id}/design-tokens.json")
|
||||
Parse ALL token values (colors, typography, spacing, borders, shadows, breakpoints)
|
||||
Parse ALL token values including:
|
||||
* colors, typography (with combinations), spacing, opacity
|
||||
* border_radius, shadows, breakpoints
|
||||
* component_styles (button, card, input variants)
|
||||
${design_attributes ? "- Adapt DOM to: density, visual_weight, formality, organic_vs_geometric" : ""}
|
||||
|
||||
## Generation
|
||||
@@ -152,14 +155,16 @@ Task(ui-design-agent): `
|
||||
|
||||
2. CSS: {base_path}/prototypes/{target}-style-{style_id}-layout-N.css
|
||||
- Self-contained: Direct token VALUES (no var())
|
||||
- Use tokens: colors, fonts, spacing, borders, shadows
|
||||
- Use tokens: colors, fonts, spacing, opacity, borders, shadows
|
||||
- IF tokens.component_styles exists: Use component presets for buttons, cards, inputs
|
||||
- IF tokens.typography.combinations exists: Use typography presets for headings and body text
|
||||
- Device-optimized: {device_type} styles
|
||||
${device_type === 'responsive' ? '- Responsive: Mobile-first @media' : '- Fixed: ' + device_type}
|
||||
${design_attributes ? `
|
||||
- Token selection: density → spacing, visual_weight → shadows` : ""}
|
||||
|
||||
## Notes
|
||||
- ✅ Token VALUES directly from design-tokens.json
|
||||
- ✅ Token VALUES directly from design-tokens.json (with typography.combinations, opacity, component_styles support)
|
||||
- ✅ Follow prompt requirements for {target}
|
||||
- ✅ Optimize for {device_type}
|
||||
- ❌ NO var() refs, NO external deps
|
||||
|
||||
@@ -99,7 +99,11 @@ Task(ui-design-agent): `
|
||||
|
||||
2. Design Tokens:
|
||||
Read("{base_path}/style-extraction/style-{style_id}/design-tokens.json")
|
||||
Extract: ALL token values (colors, typography, spacing, borders, shadows, breakpoints)
|
||||
Extract: ALL token values including:
|
||||
* colors, typography (with combinations), spacing, opacity
|
||||
* border_radius, shadows, breakpoints
|
||||
* component_styles (button, card, input variants)
|
||||
Note: typography.combinations, opacity, and component_styles fields contain preset configurations using var() references
|
||||
|
||||
3. Animation Tokens (OPTIONAL):
|
||||
IF exists("{base_path}/animation-extraction/animation-tokens.json"):
|
||||
@@ -133,11 +137,21 @@ Task(ui-design-agent): `
|
||||
- Replace ALL var(--*) with actual token values from design-tokens.json
|
||||
Example: var(--spacing-4) → 1rem (from tokens.spacing.4)
|
||||
Example: var(--breakpoint-md) → 768px (from tokens.breakpoints.md)
|
||||
Example: var(--opacity-80) → 0.8 (from tokens.opacity.80)
|
||||
- Add visual styling using design tokens:
|
||||
* Colors: tokens.colors.*
|
||||
* Typography: tokens.typography.*
|
||||
* Typography: tokens.typography.* (including combinations)
|
||||
* Opacity: tokens.opacity.*
|
||||
* Shadows: tokens.shadows.*
|
||||
* Border radius: tokens.border_radius.*
|
||||
- IF tokens.component_styles exists: Add component style classes
|
||||
* Generate classes for button variants (.btn-primary, .btn-secondary)
|
||||
* Generate classes for card variants (.card-default, .card-interactive)
|
||||
* Generate classes for input variants (.input-default, .input-focus, .input-error)
|
||||
* Use var() references that resolve to actual token values
|
||||
- IF tokens.typography.combinations exists: Add typography preset classes
|
||||
* Generate classes for typography presets (.text-heading-primary, .text-body-regular, .text-caption)
|
||||
* Use var() references for family, size, weight, line-height, letter-spacing
|
||||
- IF has_animations == true: Inject animation tokens
|
||||
* Add CSS Custom Properties for animations at :root level:
|
||||
--duration-instant, --duration-fast, --duration-normal, etc.
|
||||
|
||||
@@ -418,17 +418,33 @@ Task(ui-design-agent): `
|
||||
Create complete design system in {base_path}/style-extraction/style-1/
|
||||
|
||||
1. **design-tokens.json**:
|
||||
- Complete token structure: colors (brand, surface, semantic, text, border), typography (families, sizes, weights, line heights, letter spacing), spacing (0-24 scale), border_radius (none to full), shadows (sm to xl), breakpoints (sm to 2xl)
|
||||
- Complete token structure with ALL fields:
|
||||
* colors (brand, surface, semantic, text, border) - OKLCH format
|
||||
* typography (families, sizes, weights, line heights, letter spacing, combinations)
|
||||
* typography.combinations: Predefined typography presets (heading-primary, heading-secondary, body-regular, body-emphasis, caption, label) using var() references
|
||||
* spacing (0-24 scale)
|
||||
* opacity (0, 10, 20, 40, 60, 80, 90, 100)
|
||||
* border_radius (none to full)
|
||||
* shadows (sm to xl)
|
||||
* component_styles (button, card, input variants) - component presets using var() references
|
||||
* breakpoints (sm to 2xl)
|
||||
- All colors in OKLCH format
|
||||
${extraction_mode == "explore" ? "- Start from preview colors and expand to full palette" : ""}
|
||||
${extraction_mode == "explore" && refinements.enabled ? "- Apply user refinements where specified" : ""}
|
||||
- Common Tailwind CSS usage patterns in project (if extracting from existing project)
|
||||
|
||||
2. **style-guide.md**:
|
||||
- Design philosophy (${extraction_mode == "explore" ? "expand on: " + selected_direction.philosophy_name : "describe the reference design"})
|
||||
- Complete color system documentation with accessibility notes
|
||||
- Typography scale and usage guidelines
|
||||
- Typography Combinations section: Document each preset (heading-primary, heading-secondary, body-regular, body-emphasis, caption, label) with usage context and code examples
|
||||
- Spacing system explanation
|
||||
- Opacity & Transparency section: Opacity scale usage, common use cases (disabled states, overlays, hover effects), accessibility considerations
|
||||
- Shadows & Elevation section: Shadow hierarchy and semantic usage
|
||||
- Component Styles section: Document button, card, and input variants with code examples and visual descriptions
|
||||
- Border Radius system and semantic usage
|
||||
- Component examples and usage patterns
|
||||
- Common Tailwind CSS patterns (if applicable)
|
||||
|
||||
## Critical Requirements
|
||||
- ✅ Use Write() tool immediately for each file
|
||||
@@ -577,15 +593,46 @@ bash(test -f {base_path}/.intermediates/style-analysis/analysis-options.json &&
|
||||
"text": {"primary": "oklch(...)", "secondary": "oklch(...)", "tertiary": "oklch(...)", "inverse": "oklch(...)"},
|
||||
"border": {"default": "oklch(...)", "strong": "oklch(...)", "subtle": "oklch(...)"}
|
||||
},
|
||||
"typography": {"font_family": {...}, "font_size": {...}, "font_weight": {...}, "line_height": {...}, "letter_spacing": {...}},
|
||||
"typography": {
|
||||
"font_family": {...},
|
||||
"font_size": {...},
|
||||
"font_weight": {...},
|
||||
"line_height": {...},
|
||||
"letter_spacing": {...},
|
||||
"combinations": {
|
||||
"heading-primary": {"family": "var(--font-family-heading)", "size": "var(--font-size-3xl)", "weight": "var(--font-weight-bold)", "line_height": "var(--line-height-tight)", "letter_spacing": "var(--letter-spacing-tight)"},
|
||||
"heading-secondary": {...},
|
||||
"body-regular": {...},
|
||||
"body-emphasis": {...},
|
||||
"caption": {...},
|
||||
"label": {...}
|
||||
}
|
||||
},
|
||||
"spacing": {"0": "0", "1": "0.25rem", ..., "24": "6rem"},
|
||||
"opacity": {"0": "0", "10": "0.1", "20": "0.2", "40": "0.4", "60": "0.6", "80": "0.8", "90": "0.9", "100": "1"},
|
||||
"border_radius": {"none": "0", "sm": "0.25rem", ..., "full": "9999px"},
|
||||
"shadows": {"sm": "...", "md": "...", "lg": "...", "xl": "..."},
|
||||
"component_styles": {
|
||||
"button": {
|
||||
"primary": {"background": "var(--color-brand-primary)", "color": "var(--color-text-inverse)", "padding": "var(--spacing-3) var(--spacing-6)", "border_radius": "var(--border-radius-md)", "font_weight": "var(--font-weight-semibold)"},
|
||||
"secondary": {...},
|
||||
"tertiary": {...}
|
||||
},
|
||||
"card": {
|
||||
"default": {"background": "var(--color-surface-elevated)", "padding": "var(--spacing-6)", "border_radius": "var(--border-radius-lg)", "shadow": "var(--shadow-md)"},
|
||||
"interactive": {...}
|
||||
},
|
||||
"input": {
|
||||
"default": {"border": "1px solid var(--color-border-default)", "padding": "var(--spacing-3)", "border_radius": "var(--border-radius-md)", "background": "var(--color-surface-background)"},
|
||||
"focus": {...},
|
||||
"error": {...}
|
||||
}
|
||||
},
|
||||
"breakpoints": {"sm": "640px", ..., "2xl": "1536px"}
|
||||
}
|
||||
```
|
||||
|
||||
**Requirements**: OKLCH colors, complete coverage, semantic naming, WCAG AA compliance
|
||||
**Requirements**: OKLCH colors, complete coverage, semantic naming, WCAG AA compliance, typography combinations, component style presets, opacity scale
|
||||
|
||||
## Error Handling
|
||||
|
||||
|
||||
@@ -0,0 +1,359 @@
|
||||
Template for generating tech stack module documentation files
|
||||
|
||||
## Purpose
|
||||
Guide agent to create modular tech stack documentation from Exa research results.
|
||||
|
||||
## File Location
|
||||
`.claude/skills/{tech_stack_name}/*.md`
|
||||
|
||||
## Module Structure
|
||||
|
||||
Each module should include:
|
||||
- **Frontmatter**: YAML with module name and tech stack
|
||||
- **Main Sections**: Clear headings with hierarchical organization
|
||||
- **Code Examples**: Real examples from Exa research
|
||||
- **Best Practices**: Do's and don'ts sections
|
||||
- **References**: Attribution to Exa sources
|
||||
|
||||
---
|
||||
|
||||
## Module 1: principles.md (~3K tokens)
|
||||
|
||||
**Purpose**: Core concepts, philosophies, and fundamental principles
|
||||
|
||||
**Frontmatter**:
|
||||
```yaml
|
||||
---
|
||||
module: principles
|
||||
tech_stack: {tech_stack_name}
|
||||
description: Core concepts and philosophies
|
||||
tokens: ~3000
|
||||
---
|
||||
```
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
# {Tech} Principles
|
||||
|
||||
## Core Concepts
|
||||
- Fundamental principle 1
|
||||
- Fundamental principle 2
|
||||
- Key philosophy
|
||||
|
||||
## Design Philosophy
|
||||
- Approach to problem-solving
|
||||
- Architectural principles
|
||||
- Core values
|
||||
|
||||
## Key Features
|
||||
- Feature 1: Description
|
||||
- Feature 2: Description
|
||||
|
||||
## When to Use
|
||||
- Use case scenarios
|
||||
- Best fit situations
|
||||
|
||||
## References
|
||||
- Source 1 from Exa
|
||||
- Source 2 from Exa
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Module 2: patterns.md (~5K tokens)
|
||||
|
||||
**Purpose**: Implementation patterns with code examples
|
||||
|
||||
**Frontmatter**:
|
||||
```yaml
|
||||
---
|
||||
module: patterns
|
||||
tech_stack: {tech_stack_name}
|
||||
description: Implementation patterns with examples
|
||||
tokens: ~5000
|
||||
---
|
||||
```
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
# {Tech} Patterns
|
||||
|
||||
## Common Patterns
|
||||
|
||||
### Pattern 1: {Name}
|
||||
**Use Case**: When to use this pattern
|
||||
**Implementation**:
|
||||
\`\`\`{language}
|
||||
// Code example from Exa
|
||||
\`\`\`
|
||||
**Benefits**: Why use this pattern
|
||||
|
||||
### Pattern 2: {Name}
|
||||
[Same structure]
|
||||
|
||||
## Architectural Patterns
|
||||
- Pattern descriptions
|
||||
- Code examples
|
||||
|
||||
## Component Patterns
|
||||
- Reusable component structures
|
||||
- Integration examples
|
||||
|
||||
## References
|
||||
- Exa sources with pattern examples
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Module 3: practices.md (~4K tokens)
|
||||
|
||||
**Purpose**: Best practices, anti-patterns, pitfalls
|
||||
|
||||
**Frontmatter**:
|
||||
```yaml
|
||||
---
|
||||
module: practices
|
||||
tech_stack: {tech_stack_name}
|
||||
description: Best practices and anti-patterns
|
||||
tokens: ~4000
|
||||
---
|
||||
```
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
# {Tech} Best Practices
|
||||
|
||||
## Do's
|
||||
✅ **Practice 1**: Description
|
||||
- Rationale
|
||||
- Example scenario
|
||||
|
||||
✅ **Practice 2**: Description
|
||||
|
||||
## Don'ts
|
||||
❌ **Anti-pattern 1**: What to avoid
|
||||
- Why it's problematic
|
||||
- Better alternative
|
||||
|
||||
❌ **Anti-pattern 2**: What to avoid
|
||||
|
||||
## Common Pitfalls
|
||||
1. **Pitfall 1**: Description and solution
|
||||
2. **Pitfall 2**: Description and solution
|
||||
|
||||
## Performance Considerations
|
||||
- Optimization techniques
|
||||
- Common bottlenecks
|
||||
|
||||
## Security Best Practices
|
||||
- Security considerations
|
||||
- Common vulnerabilities
|
||||
|
||||
## References
|
||||
- Exa sources for best practices
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Module 4: testing.md (~3K tokens)
|
||||
|
||||
**Purpose**: Testing strategies, frameworks, and examples
|
||||
|
||||
**Frontmatter**:
|
||||
```yaml
|
||||
---
|
||||
module: testing
|
||||
tech_stack: {tech_stack_name}
|
||||
description: Testing strategies and frameworks
|
||||
tokens: ~3000
|
||||
---
|
||||
```
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
# {Tech} Testing
|
||||
|
||||
## Testing Strategies
|
||||
- Unit testing approach
|
||||
- Integration testing approach
|
||||
- E2E testing approach
|
||||
|
||||
## Testing Frameworks
|
||||
### Framework 1
|
||||
- Setup
|
||||
- Basic usage
|
||||
- Example:
|
||||
\`\`\`{language}
|
||||
// Test example from Exa
|
||||
\`\`\`
|
||||
|
||||
## Test Patterns
|
||||
- Common test patterns
|
||||
- Mock strategies
|
||||
- Assertion best practices
|
||||
|
||||
## Coverage Recommendations
|
||||
- What to test
|
||||
- Coverage targets
|
||||
|
||||
## References
|
||||
- Exa sources for testing examples
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Module 5: config.md (~3K tokens)
|
||||
|
||||
**Purpose**: Setup, configuration, and tooling
|
||||
|
||||
**Frontmatter**:
|
||||
```yaml
|
||||
---
|
||||
module: config
|
||||
tech_stack: {tech_stack_name}
|
||||
description: Setup, configuration, and tooling
|
||||
tokens: ~3000
|
||||
---
|
||||
```
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
# {Tech} Configuration
|
||||
|
||||
## Installation
|
||||
\`\`\`bash
|
||||
# Installation commands
|
||||
\`\`\`
|
||||
|
||||
## Basic Configuration
|
||||
\`\`\`{config-format}
|
||||
// Configuration example from Exa
|
||||
\`\`\`
|
||||
|
||||
## Common Configurations
|
||||
### Development
|
||||
- Dev config setup
|
||||
- Hot reload configuration
|
||||
|
||||
### Production
|
||||
- Production optimizations
|
||||
- Build configurations
|
||||
|
||||
## Tooling
|
||||
- Recommended tools
|
||||
- IDE/Editor setup
|
||||
- Linters and formatters
|
||||
|
||||
## Environment Setup
|
||||
- Environment variables
|
||||
- Config file structure
|
||||
|
||||
## References
|
||||
- Exa sources for configuration
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Module 6: frameworks.md (~4K tokens) [CONDITIONAL]
|
||||
|
||||
**Purpose**: Framework integration patterns (only for composite tech stacks)
|
||||
|
||||
**Condition**: Only generate if `is_composite = true`
|
||||
|
||||
**Frontmatter**:
|
||||
```yaml
|
||||
---
|
||||
module: frameworks
|
||||
tech_stack: {tech_stack_name}
|
||||
description: Framework integration patterns
|
||||
tokens: ~4000
|
||||
conditional: composite_only
|
||||
---
|
||||
```
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
# {Main Tech} + {Framework} Integration
|
||||
|
||||
## Integration Overview
|
||||
- How {main_tech} works with {framework}
|
||||
- Architecture considerations
|
||||
|
||||
## Setup
|
||||
\`\`\`bash
|
||||
# Integration setup commands
|
||||
\`\`\`
|
||||
|
||||
## Integration Patterns
|
||||
|
||||
### Pattern 1: {Name}
|
||||
\`\`\`{language}
|
||||
// Integration example from Exa
|
||||
\`\`\`
|
||||
|
||||
## Best Practices
|
||||
- Integration best practices
|
||||
- Common pitfalls
|
||||
|
||||
## Examples
|
||||
- Real-world integration examples
|
||||
- Code samples from Exa
|
||||
|
||||
## References
|
||||
- Exa sources for integration patterns
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Metadata File: metadata.json
|
||||
|
||||
**Purpose**: Store generation metadata and research summary
|
||||
|
||||
**Structure**:
|
||||
```json
|
||||
{
|
||||
"tech_stack_name": "typescript-react-nextjs",
|
||||
"components": ["typescript", "react", "nextjs"],
|
||||
"is_composite": true,
|
||||
"generated_at": "2025-11-04T22:00:00Z",
|
||||
"source": "exa-research",
|
||||
"research_summary": {
|
||||
"total_queries": 6,
|
||||
"total_sources": 25,
|
||||
"query_list": [
|
||||
"typescript core principles best practices 2025",
|
||||
"react common patterns architecture examples",
|
||||
"nextjs configuration setup tooling 2025",
|
||||
"testing strategies",
|
||||
"react nextjs integration",
|
||||
"typescript react integration"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Generation Guidelines
|
||||
|
||||
### Content Synthesis from Exa
|
||||
- Extract relevant code examples from Exa results
|
||||
- Synthesize information from multiple sources
|
||||
- Maintain technical accuracy
|
||||
- Cite sources in References section
|
||||
|
||||
### Formatting Rules
|
||||
- Use clear markdown headers
|
||||
- Include code fences with language specification
|
||||
- Use emoji for Do's (✅) and Don'ts (❌)
|
||||
- Keep token estimates accurate
|
||||
|
||||
### Error Handling
|
||||
- If Exa query fails, note in References section
|
||||
- If insufficient data, mark section as "Limited research available"
|
||||
- Handle missing components gracefully
|
||||
|
||||
### Token Distribution
|
||||
- Total budget: ~22K tokens for 6 modules
|
||||
- Adjust module size based on content availability
|
||||
- Prioritize quality over hitting exact token counts
|
||||
@@ -0,0 +1,185 @@
|
||||
Template for generating tech stack SKILL.md index file
|
||||
|
||||
## Purpose
|
||||
Create main SKILL package index with module references and loading recommendations.
|
||||
|
||||
## File Location
|
||||
`.claude/skills/{tech_stack_name}/SKILL.md`
|
||||
|
||||
## Template Structure
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: {TECH_STACK_NAME}
|
||||
description: {MAIN_TECH} development guidelines from industry standards (Exa research)
|
||||
version: 1.0.0
|
||||
generated: {ISO_TIMESTAMP}
|
||||
source: exa-research
|
||||
---
|
||||
# {TechStackTitle} SKILL Package
|
||||
|
||||
## Overview
|
||||
|
||||
{Brief 1-2 sentence description of the tech stack and purpose of this SKILL package}
|
||||
|
||||
**Primary Technology**: {MAIN_TECH}
|
||||
{IF_COMPOSITE}**Frameworks**: {COMPONENT_LIST}{/IF_COMPOSITE}
|
||||
|
||||
## Modular Documentation
|
||||
|
||||
### Core Understanding (~8K tokens)
|
||||
- [Principles](./principles.md) - Core concepts and philosophies
|
||||
- [Patterns](./patterns.md) - Implementation patterns with examples
|
||||
|
||||
### Practical Guidance (~7K tokens)
|
||||
- [Best Practices](./practices.md) - Do's, don'ts, anti-patterns
|
||||
- [Testing](./testing.md) - Testing strategies and frameworks
|
||||
|
||||
### Configuration & Integration (~7K tokens)
|
||||
- [Configuration](./config.md) - Setup, tooling, configuration
|
||||
{IF_COMPOSITE}- [Frameworks](./frameworks.md) - Integration patterns{/IF_COMPOSITE}
|
||||
|
||||
## Loading Recommendations
|
||||
|
||||
### Quick Reference (~7K tokens)
|
||||
Load for quick consultation on core concepts:
|
||||
- principles.md
|
||||
- practices.md
|
||||
|
||||
**Use When**: Need quick reminder of best practices or core principles
|
||||
|
||||
### Implementation Focus (~8K tokens)
|
||||
Load for active development work:
|
||||
- patterns.md
|
||||
- config.md
|
||||
|
||||
**Use When**: Writing code, setting up projects, implementing features
|
||||
|
||||
### Complete Package (~22K tokens)
|
||||
Load all modules for comprehensive understanding:
|
||||
- All 5-6 modules
|
||||
|
||||
**Use When**: Learning tech stack, architecture reviews, comprehensive reference
|
||||
|
||||
## Usage
|
||||
|
||||
**Load this SKILL when**:
|
||||
- Starting new {TECH_STACK} projects
|
||||
- Reviewing {TECH_STACK} code
|
||||
- Learning {TECH_STACK} best practices
|
||||
- Implementing {TECH_STACK} patterns
|
||||
- Troubleshooting {TECH_STACK} issues
|
||||
|
||||
**Auto-triggers on**:
|
||||
- Keywords: {TECH_KEYWORDS}
|
||||
- File types: {FILE_EXTENSIONS}
|
||||
|
||||
## Research Metadata
|
||||
|
||||
- **Generated**: {ISO_TIMESTAMP}
|
||||
- **Source**: Exa Research (web search + code context)
|
||||
- **Queries Executed**: {QUERY_COUNT}
|
||||
- **Sources Consulted**: {SOURCE_COUNT}
|
||||
- **Research Quality**: {QUALITY_INDICATOR}
|
||||
|
||||
## Tech Stack Components
|
||||
|
||||
**Primary**: {MAIN_TECH} - {MAIN_TECH_DESCRIPTION}
|
||||
|
||||
{IF_COMPOSITE}
|
||||
**Additional Frameworks**:
|
||||
{FOR_EACH_COMPONENT}
|
||||
- **{COMPONENT_NAME}**: {COMPONENT_DESCRIPTION}
|
||||
{/FOR_EACH_COMPONENT}
|
||||
{/IF_COMPOSITE}
|
||||
|
||||
## Version History
|
||||
|
||||
- **v1.0.0** ({DATE}): Initial SKILL package generated from Exa research
|
||||
|
||||
---
|
||||
|
||||
## Developer Notes
|
||||
|
||||
This SKILL package was auto-generated using:
|
||||
- `/memory:tech-research` command
|
||||
- Exa AI research APIs (mcp__exa__get_code_context_exa, mcp__exa__web_search_exa)
|
||||
- Token limit: ~5K per module, ~22K total
|
||||
|
||||
To regenerate:
|
||||
```bash
|
||||
/memory:tech-research "{tech_stack_name}" --regenerate
|
||||
```
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Variable Substitution Guide
|
||||
|
||||
### Required Variables
|
||||
- `{TECH_STACK_NAME}`: Lowercase hyphenated name (e.g., "typescript-react-nextjs")
|
||||
- `{TechStackTitle}`: Title case display name (e.g., "TypeScript React Next.js")
|
||||
- `{MAIN_TECH}`: Primary technology (e.g., "TypeScript")
|
||||
- `{ISO_TIMESTAMP}`: ISO 8601 timestamp (e.g., "2025-11-04T22:00:00Z")
|
||||
- `{QUERY_COUNT}`: Number of Exa queries executed (e.g., 6)
|
||||
- `{SOURCE_COUNT}`: Total sources consulted (e.g., 25)
|
||||
|
||||
### Conditional Variables
|
||||
- `{IF_COMPOSITE}...{/IF_COMPOSITE}`: Only include if tech stack has multiple components
|
||||
- `{COMPONENT_LIST}`: Comma-separated list of framework names
|
||||
- `{FOR_EACH_COMPONENT}...{/FOR_EACH_COMPONENT}`: Loop through components
|
||||
|
||||
### Optional Variables
|
||||
- `{MAIN_TECH_DESCRIPTION}`: One-line description of primary tech
|
||||
- `{COMPONENT_DESCRIPTION}`: One-line description per component
|
||||
- `{TECH_KEYWORDS}`: Comma-separated trigger keywords
|
||||
- `{FILE_EXTENSIONS}`: File extensions (e.g., ".ts, .tsx, .jsx")
|
||||
- `{QUALITY_INDICATOR}`: Research quality metric (e.g., "High", "Medium")
|
||||
|
||||
---
|
||||
|
||||
## Generation Instructions
|
||||
|
||||
### Step 1: Read metadata.json
|
||||
Extract values for variables from metadata.json generated during module creation.
|
||||
|
||||
### Step 2: Determine composite status
|
||||
- Single tech: Omit {IF_COMPOSITE} sections
|
||||
- Composite: Include frameworks section and integration module reference
|
||||
|
||||
### Step 3: Calculate token estimates
|
||||
- Verify module files exist
|
||||
- Adjust token estimates based on actual file sizes
|
||||
- Update loading recommendation estimates
|
||||
|
||||
### Step 4: Generate descriptions
|
||||
- **Overview**: Brief description of tech stack purpose
|
||||
- **Main tech description**: One-liner for primary technology
|
||||
- **Component descriptions**: One-liner per additional framework
|
||||
|
||||
### Step 5: Build keyword lists
|
||||
- Extract common keywords from tech stack name
|
||||
- Add file extensions relevant to tech stack
|
||||
- Include framework-specific triggers
|
||||
|
||||
### Step 6: Format timestamps
|
||||
- Use ISO 8601 format for all timestamps
|
||||
- Include timezone (UTC recommended)
|
||||
|
||||
### Step 7: Write SKILL.md
|
||||
- Apply template with all substitutions
|
||||
- Validate markdown formatting
|
||||
- Verify all relative paths work
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
- [ ] All module files exist and are referenced
|
||||
- [ ] Token estimates are reasonably accurate
|
||||
- [ ] Conditional sections handled correctly (composite vs single)
|
||||
- [ ] Timestamps in ISO 8601 format
|
||||
- [ ] All relative paths use ./ prefix
|
||||
- [ ] Metadata section matches metadata.json
|
||||
- [ ] Loading recommendations align with actual module sizes
|
||||
- [ ] Usage section includes relevant trigger keywords
|
||||
@@ -0,0 +1,172 @@
|
||||
# SKILL.md Index Generation Context
|
||||
|
||||
## Description Field Requirements
|
||||
|
||||
When generating final aggregated output, remember to prepare data for SKILL.md description field:
|
||||
|
||||
**Required Data Points**:
|
||||
- Project root path (to be obtained via git command)
|
||||
- Use cases: "continuing development", "analyzing past implementations", "learning from workflow history"
|
||||
- Trigger phrase: "especially when no relevant context exists in memory"
|
||||
|
||||
**Description Format**:
|
||||
```
|
||||
Progressive workflow development history (located at {project_root}).
|
||||
Load this SKILL when continuing development, analyzing past implementations,
|
||||
or learning from workflow history, especially when no relevant context exists in memory.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
You are aggregating workflow session history to generate a progressive SKILL package.
|
||||
|
||||
## Your Task
|
||||
|
||||
Analyze archived workflow sessions and aggregate:
|
||||
1. **Lessons Learned** - Successes, challenges, and watch patterns
|
||||
2. **Conflict Patterns** - Recurring conflicts and resolutions
|
||||
3. **Implementation Summaries** - Key outcomes by functional domain
|
||||
|
||||
## Input Data
|
||||
|
||||
You will receive:
|
||||
- Session metadata (session_id, description, tags, metrics)
|
||||
- Lessons from each session (successes, challenges, watch_patterns)
|
||||
- IMPL_PLAN summaries
|
||||
- Context package metadata (keywords, tech_stack, complexity)
|
||||
|
||||
## Output Requirements
|
||||
|
||||
### 1. Aggregated Lessons
|
||||
|
||||
**Successes by Category**:
|
||||
- Group successful patterns by functional domain (auth, testing, performance, etc.)
|
||||
- Identify practices that succeeded across multiple sessions
|
||||
- Mark best practices (success in 3+ sessions)
|
||||
|
||||
**Challenges by Severity**:
|
||||
- HIGH: Blocked development for >4 hours OR repeated in 3+ sessions
|
||||
- MEDIUM: Required significant rework OR repeated in 2 sessions
|
||||
- LOW: Minor issues resolved quickly
|
||||
|
||||
**Watch Patterns**:
|
||||
- Identify patterns mentioned in 2+ sessions
|
||||
- Prioritize by frequency and severity
|
||||
- Mark CRITICAL patterns (appeared in 3+ sessions with HIGH severity)
|
||||
|
||||
**Format**:
|
||||
```json
|
||||
{
|
||||
"successes_by_category": {
|
||||
"auth": ["JWT implementation with refresh tokens (3 sessions)", ...],
|
||||
"testing": ["TDD reduced bugs by 60% (2 sessions)", ...]
|
||||
},
|
||||
"challenges_by_severity": {
|
||||
"high": [
|
||||
{
|
||||
"challenge": "Token refresh edge cases",
|
||||
"sessions": ["WFS-user-auth", "WFS-jwt-refresh"],
|
||||
"frequency": 2
|
||||
}
|
||||
],
|
||||
"medium": [...],
|
||||
"low": [...]
|
||||
},
|
||||
"watch_patterns": [
|
||||
{
|
||||
"pattern": "Token concurrency issues",
|
||||
"frequency": 3,
|
||||
"severity": "CRITICAL",
|
||||
"sessions": ["WFS-user-auth", "WFS-jwt-refresh", "WFS-oauth"]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Conflict Patterns
|
||||
|
||||
**Analysis**:
|
||||
- Group conflicts by type (architecture, dependencies, testing, performance)
|
||||
- Identify recurring patterns (same conflict in different sessions)
|
||||
- Link successful resolutions to specific sessions
|
||||
|
||||
**Format**:
|
||||
```json
|
||||
{
|
||||
"architecture": [
|
||||
{
|
||||
"pattern": "Multiple authentication strategies conflict",
|
||||
"description": "Different auth methods (JWT, OAuth, session) cause integration issues",
|
||||
"sessions": ["WFS-user-auth", "WFS-oauth"],
|
||||
"resolution": "Unified auth interface with strategy pattern",
|
||||
"code_impact": ["src/auth/interface.ts", "src/auth/jwt.ts", "src/auth/oauth.ts"],
|
||||
"frequency": 2,
|
||||
"severity": "high"
|
||||
}
|
||||
],
|
||||
"dependencies": [...],
|
||||
"testing": [...],
|
||||
"performance": [...]
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Implementation Summary
|
||||
|
||||
**By Functional Domain**:
|
||||
- Group sessions by primary tag/domain
|
||||
- Summarize key accomplishments
|
||||
- Link to context packages and plans
|
||||
|
||||
**Format**:
|
||||
```json
|
||||
{
|
||||
"auth": {
|
||||
"session_count": 3,
|
||||
"sessions": [
|
||||
{
|
||||
"session_id": "WFS-user-auth",
|
||||
"description": "JWT authentication implementation",
|
||||
"key_outcomes": [
|
||||
"JWT token generation and validation",
|
||||
"Refresh token mechanism",
|
||||
"Secure password hashing with bcrypt"
|
||||
],
|
||||
"context_package": ".workflow/.archives/WFS-user-auth/.process/context-package.json",
|
||||
"metrics": {"task_count": 5, "success_rate": 100, "duration_hours": 4.5}
|
||||
}
|
||||
],
|
||||
"cumulative_metrics": {
|
||||
"total_tasks": 15,
|
||||
"avg_success_rate": 95,
|
||||
"total_hours": 12.5
|
||||
}
|
||||
},
|
||||
"payment": {...},
|
||||
"ui": {...}
|
||||
}
|
||||
```
|
||||
|
||||
## Analysis Guidelines
|
||||
|
||||
1. **Identify Patterns**: Look for recurring themes across sessions
|
||||
2. **Prioritize by Impact**: Focus on high-frequency, high-impact patterns
|
||||
3. **Link Sessions**: Connect related sessions (same domain, similar challenges)
|
||||
4. **Extract Wisdom**: Surface actionable insights from lessons learned
|
||||
5. **Maintain Context**: Keep references to original sessions and files
|
||||
|
||||
## Quality Criteria
|
||||
|
||||
- ✅ All sessions processed and categorized
|
||||
- ✅ Patterns identified and frequency counted
|
||||
- ✅ Severity levels assigned based on impact
|
||||
- ✅ Resolutions linked to specific sessions
|
||||
- ✅ Output is valid JSON with no missing fields
|
||||
- ✅ References (paths) are accurate and complete
|
||||
|
||||
## Important Notes
|
||||
|
||||
- **NO hallucination**: Only aggregate data from provided sessions
|
||||
- **Preserve detail**: Keep specific session references for traceability
|
||||
- **Smart grouping**: Group similar patterns even if wording differs slightly
|
||||
- **Frequency matters**: Prioritize patterns that appear in multiple sessions
|
||||
- **Context preservation**: Keep context package paths for on-demand loading
|
||||
@@ -0,0 +1,98 @@
|
||||
Template for generating conflict-patterns.md
|
||||
|
||||
## Purpose
|
||||
Document recurring conflict patterns across workflow sessions with resolutions.
|
||||
|
||||
## File Location
|
||||
`.claude/skills/workflow-progress/conflict-patterns.md`
|
||||
|
||||
## Update Strategy
|
||||
- **Incremental mode**: Add new conflicts, update frequency counters for existing patterns
|
||||
- **Full mode**: Regenerate entire conflict analysis from all sessions
|
||||
|
||||
## Structure
|
||||
|
||||
```markdown
|
||||
# Workflow Conflict Patterns
|
||||
|
||||
## Architecture Conflicts
|
||||
|
||||
### {Conflict_Pattern_Title}
|
||||
**Pattern**: {concise_pattern_description}
|
||||
**Sessions**: {session_id_1}, {session_id_2}
|
||||
**Resolution**: {resolution_strategy}
|
||||
|
||||
**Code Impact**:
|
||||
- Modified: {file_path_1}, {file_path_2}
|
||||
- Added: {file_path_3}
|
||||
- Tests: {test_file_path}
|
||||
|
||||
**Frequency**: {count} sessions
|
||||
**Severity**: {high|medium|low}
|
||||
|
||||
---
|
||||
|
||||
## Dependency Conflicts
|
||||
|
||||
### {Conflict_Pattern_Title}
|
||||
**Pattern**: {concise_pattern_description}
|
||||
**Sessions**: {session_id_list}
|
||||
**Resolution**: {resolution_strategy}
|
||||
|
||||
**Package Changes**:
|
||||
- Updated: {package_name}@{version}
|
||||
- Locked: {dependency_name}
|
||||
|
||||
**Frequency**: {count} sessions
|
||||
**Severity**: {high|medium|low}
|
||||
|
||||
---
|
||||
|
||||
## Testing Conflicts
|
||||
|
||||
### {Conflict_Pattern_Title}
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
## Performance Conflicts
|
||||
|
||||
### {Conflict_Pattern_Title}
|
||||
...
|
||||
```
|
||||
|
||||
## Data Sources
|
||||
- IMPL_PLAN summaries: `.workflow/.archives/{session_id}/IMPL_PLAN.md`
|
||||
- Context packages: `.workflow/.archives/{session_id}/.process/context-package.json` (reference only)
|
||||
- Session lessons: `manifest.json` -> `archives[].lessons.challenges`
|
||||
|
||||
## Conflict Identification (Use Gemini CLI)
|
||||
|
||||
**Command Pattern**:
|
||||
```bash
|
||||
gemini -p "
|
||||
PURPOSE: Identify conflict patterns from workflow sessions
|
||||
TASK:
|
||||
• Extract conflicts from IMPL_PLAN and lessons
|
||||
• Group by type (architecture/dependencies/testing/performance)
|
||||
• Identify recurring patterns (same conflict in different sessions)
|
||||
• Link resolutions to specific sessions
|
||||
MODE: analysis
|
||||
CONTEXT: @.workflow/.archives/*/IMPL_PLAN.md @.workflow/.archives/manifest.json
|
||||
EXPECTED: Conflict patterns with frequency and resolution
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/workflow/skill-aggregation.txt)
|
||||
"
|
||||
```
|
||||
|
||||
**Pattern Grouping**:
|
||||
- **Architecture**: Design conflicts, incompatible strategies, interface mismatches
|
||||
- **Dependencies**: Version conflicts, library incompatibilities, package issues
|
||||
- **Testing**: Mock data inconsistencies, test environment issues, coverage gaps
|
||||
- **Performance**: Bottlenecks, optimization conflicts, resource issues
|
||||
|
||||
## Formatting Rules
|
||||
- Sort by frequency within each category
|
||||
- Include code impact for traceability
|
||||
- Mark high-frequency patterns (3+ sessions) as "RECURRING"
|
||||
- Keep resolution descriptions actionable
|
||||
- Use relative paths for file references
|
||||
224
.claude/workflows/cli-templates/prompts/workflow/skill-index.txt
Normal file
224
.claude/workflows/cli-templates/prompts/workflow/skill-index.txt
Normal file
@@ -0,0 +1,224 @@
|
||||
Template for generating SKILL.md (index file)
|
||||
|
||||
## Purpose
|
||||
Create main SKILL package index with progressive loading structure and session references.
|
||||
|
||||
## File Location
|
||||
`.claude/skills/workflow-progress/SKILL.md`
|
||||
|
||||
## Update Strategy
|
||||
- **Always regenerated**: This file is always updated with latest session count, domains, dates
|
||||
|
||||
## Structure
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: workflow-progress
|
||||
description: Progressive workflow development history (located at {project_root}). Load this SKILL when continuing development, analyzing past implementations, or learning from workflow history, especially when no relevant context exists in memory.
|
||||
version: {semantic_version}
|
||||
---
|
||||
# Workflow Progress SKILL Package
|
||||
|
||||
## Documentation: `../../../.workflow/.archives/`
|
||||
|
||||
**Total Sessions**: {session_count}
|
||||
**Functional Domains**: {domain_list}
|
||||
**Date Range**: {earliest_date} - {latest_date}
|
||||
|
||||
## Progressive Loading
|
||||
|
||||
### Level 0: Quick Overview (~2K tokens)
|
||||
- [Sessions Timeline](sessions-timeline.md#recent-sessions-last-5) - Recent 5 sessions
|
||||
- [Top Conflict Patterns](conflict-patterns.md#top-patterns) - Top 3 recurring conflicts
|
||||
- Quick reference for last completed work
|
||||
|
||||
**Use Case**: Quick context refresh before starting new task
|
||||
|
||||
### Level 1: Core History (~8K tokens)
|
||||
- [Sessions Timeline](sessions-timeline.md) - Recent 10 sessions with details
|
||||
- [Lessons Learned](lessons-learned.md#best-practices) - Success patterns by category
|
||||
- [Conflict Patterns](conflict-patterns.md) - Known conflict types and resolutions
|
||||
- Context package references (metadata only)
|
||||
|
||||
**Use Case**: Understanding recent development patterns and avoiding known pitfalls
|
||||
|
||||
### Level 2: Complete History (~25K tokens)
|
||||
- All archived sessions with metadata
|
||||
- Full lessons learned (successes, challenges, watch patterns)
|
||||
- Complete conflict analysis with resolutions
|
||||
- IMPL_PLAN summaries from all sessions
|
||||
- Context package paths for on-demand loading
|
||||
|
||||
**Use Case**: Comprehensive review before major refactoring or architecture changes
|
||||
|
||||
### Level 3: Deep Dive (~40K tokens)
|
||||
- Full IMPL_PLAN.md and TODO_LIST.md from all sessions
|
||||
- Detailed task completion summaries
|
||||
- Cross-session dependency analysis
|
||||
- Direct context package file references
|
||||
|
||||
**Use Case**: Investigating specific implementation details or debugging historical decisions
|
||||
|
||||
---
|
||||
|
||||
## Quick Access
|
||||
|
||||
### Recent Sessions
|
||||
{list of 5 most recent sessions with one-line descriptions}
|
||||
|
||||
### By Domain
|
||||
- **{Domain_1}**: {count} sessions
|
||||
- **{Domain_2}**: {count} sessions
|
||||
- **{Domain_3}**: {count} sessions
|
||||
|
||||
### Top Watch Patterns
|
||||
1. {most_frequent_watch_pattern}
|
||||
2. {second_most_frequent}
|
||||
3. {third_most_frequent}
|
||||
|
||||
---
|
||||
|
||||
## Session Index
|
||||
|
||||
### {Domain_Category} Sessions
|
||||
- [{session_id}](../../../.workflow/.archives/{session_id}/) - {one_line_description} ({date})
|
||||
- Context: [context-package.json](../../../.workflow/.archives/{session_id}/.process/context-package.json)
|
||||
- Plan: [IMPL_PLAN.md](../../../.workflow/.archives/{session_id}/IMPL_PLAN.md)
|
||||
- Tags: {tag1}, {tag2}, {tag3}
|
||||
|
||||
---
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Loading Quick Context
|
||||
```markdown
|
||||
Load Level 0 from workflow-progress SKILL for overview of recent work
|
||||
```
|
||||
|
||||
### Investigating {Domain} History
|
||||
```markdown
|
||||
Load Level 2 from workflow-progress SKILL, filter by "{domain}" tag
|
||||
```
|
||||
|
||||
### Full Historical Analysis
|
||||
```markdown
|
||||
Load Level 3 from workflow-progress SKILL for complete development history
|
||||
```
|
||||
```
|
||||
|
||||
## Data Sources
|
||||
- Manifest: `.workflow/.archives/manifest.json`
|
||||
- All session metadata from manifest entries
|
||||
|
||||
## Generation Rules
|
||||
- Version format: `{major}.{minor}.{patch}` (increment patch for each update)
|
||||
- Domain list: Extract unique tags from all sessions, sort by frequency
|
||||
- Date range: Find earliest and latest archived_at timestamps
|
||||
- Token estimates: Approximate based on content length
|
||||
- Use relative paths (../../../.workflow/.archives/) for session references
|
||||
|
||||
## Formatting Rules
|
||||
- Keep descriptions concise
|
||||
- Sort sessions by date (newest first)
|
||||
- Group sessions by primary tag
|
||||
- Include only top 5 recent sessions in Quick Access
|
||||
- Include top 3 watch patterns
|
||||
|
||||
---
|
||||
|
||||
## Variable Substitution Guide
|
||||
|
||||
### Required Variables
|
||||
- `{project_root}`: Absolute project path from git root (e.g., "/d/Claude_dms3")
|
||||
- `{semantic_version}`: Version string (e.g., "1.0.0", increment patch for each update)
|
||||
- `{session_count}`: Total number of archived sessions
|
||||
- `{domain_list}`: Comma-separated unique tags sorted by frequency
|
||||
- `{earliest_date}`: Earliest session archived_at timestamp
|
||||
- `{latest_date}`: Most recent session archived_at timestamp
|
||||
|
||||
### Generated Variables
|
||||
- `{one_line_description}`: Extract from session description (first sentence, max 80 chars)
|
||||
- `{domain_category}`: Primary tag from session metadata
|
||||
- `{most_frequent_watch_pattern}`: Top recurring watch pattern across sessions
|
||||
- `{date}`: Session archived_at in YYYY-MM-DD format
|
||||
|
||||
### Description Field Generation
|
||||
|
||||
**Format Template**:
|
||||
```
|
||||
Progressive workflow development history (located at {project_root}).
|
||||
Load this SKILL when continuing development, analyzing past implementations,
|
||||
or learning from workflow history, especially when no relevant context exists in memory.
|
||||
```
|
||||
|
||||
**Generation Rules**:
|
||||
1. **Project Root**: Use `git rev-parse --show-toplevel` to get absolute path
|
||||
2. **Use Cases**: ALWAYS include these trigger phrases:
|
||||
- "continuing development" (开发延续)
|
||||
- "analyzing past implementations" (分析历史)
|
||||
- "learning from workflow history" (学习历史)
|
||||
3. **Trigger Optimization**: MUST include "especially when no relevant context exists in memory"
|
||||
4. **Path Format**: Use forward slashes for cross-platform compatibility (e.g., "/d/project")
|
||||
|
||||
**Why This Matters**:
|
||||
- **Auto-loading precision**: Path reference ensures Claude loads correct project's SKILL
|
||||
- **Context awareness**: "when no relevant context exists" prevents redundant loading
|
||||
- **Action coverage**: Three use cases cover all workflow scenarios
|
||||
|
||||
---
|
||||
|
||||
## Generation Instructions
|
||||
|
||||
### Step 1: Get Project Root
|
||||
```bash
|
||||
git rev-parse --show-toplevel # Returns: /d/Claude_dms3
|
||||
```
|
||||
|
||||
### Step 2: Read Manifest
|
||||
```bash
|
||||
cat .workflow/.archives/manifest.json
|
||||
```
|
||||
|
||||
Extract:
|
||||
- Total session count
|
||||
- All session tags (for domain list)
|
||||
- Date range (earliest/latest archived_at)
|
||||
|
||||
### Step 3: Aggregate Session Data
|
||||
- Count sessions per domain
|
||||
- Extract top 5 recent sessions
|
||||
- Identify top 3 watch patterns from lessons
|
||||
|
||||
### Step 4: Generate Description
|
||||
Apply format template with project_root from Step 1.
|
||||
|
||||
### Step 5: Calculate Version
|
||||
- Read existing SKILL.md version (if exists)
|
||||
- Increment patch version (e.g., 1.0.5 → 1.0.6)
|
||||
- Use 1.0.0 for new SKILL package
|
||||
|
||||
### Step 6: Build Progressive Loading Sections
|
||||
- Level 0: Recent 5 sessions + Top 3 conflicts
|
||||
- Level 1: Recent 10 sessions + Best practices
|
||||
- Level 2: All sessions + Full lessons + Full conflicts
|
||||
- Level 3: Include IMPL_PLAN and TODO_LIST references
|
||||
|
||||
### Step 7: Write SKILL.md
|
||||
- Apply all variable substitutions
|
||||
- Use relative paths: `../../../.workflow/.archives/`
|
||||
- Validate all referenced files exist
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
- [ ] `{project_root}` uses absolute path with forward slashes
|
||||
- [ ] Description includes all three use cases
|
||||
- [ ] Description includes trigger optimization phrase
|
||||
- [ ] Version incremented correctly
|
||||
- [ ] All session references use relative paths
|
||||
- [ ] Domain list sorted by frequency
|
||||
- [ ] Date range matches manifest
|
||||
- [ ] Quick Access section has exactly 5 recent sessions
|
||||
- [ ] Top Watch Patterns section has exactly 3 items
|
||||
- [ ] All referenced files exist in archives
|
||||
@@ -0,0 +1,98 @@
|
||||
Template for generating lessons-learned.md
|
||||
|
||||
## Purpose
|
||||
Aggregate lessons learned from workflow sessions, categorized by functional domain and severity.
|
||||
|
||||
## File Location
|
||||
`.claude/skills/workflow-progress/lessons-learned.md`
|
||||
|
||||
## Update Strategy
|
||||
- **Incremental mode**: Merge new session lessons into existing categories, update frequencies
|
||||
- **Full mode**: Regenerate entire lessons document from all sessions
|
||||
|
||||
## Structure
|
||||
|
||||
```markdown
|
||||
# Workflow Lessons Learned
|
||||
|
||||
## Best Practices (Successes)
|
||||
|
||||
### {Domain_Category}
|
||||
- {success_pattern_1} (sessions: {session_id_1}, {session_id_2})
|
||||
- {success_pattern_2} (sessions: {session_id_3})
|
||||
|
||||
### {Domain_Category_2}
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
## Known Challenges
|
||||
|
||||
### High Priority
|
||||
- **{challenge_title}**: {description}
|
||||
- Affected sessions: {session_id_1}, {session_id_2}
|
||||
- Resolution: {resolution_strategy}
|
||||
|
||||
### Medium Priority
|
||||
- **{challenge_title}**: {description}
|
||||
- Affected sessions: {session_id_3}
|
||||
- Resolution: {resolution_strategy}
|
||||
|
||||
### Low Priority
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
## Watch Patterns
|
||||
|
||||
### Critical (3+ sessions)
|
||||
1. **{pattern_name}**: {description}
|
||||
- Frequency: {count} sessions
|
||||
- Affected: {session_list}
|
||||
- Mitigation: {mitigation_strategy}
|
||||
|
||||
### High Priority (2 sessions)
|
||||
...
|
||||
|
||||
### Normal (1 session)
|
||||
...
|
||||
```
|
||||
|
||||
## Data Sources
|
||||
- Lessons: `manifest.json` -> `archives[].lessons.{successes|challenges|watch_patterns}`
|
||||
- Session metadata: `.workflow/.archives/{session_id}/workflow-session.json`
|
||||
|
||||
## Aggregation Rules (Use Gemini CLI)
|
||||
|
||||
**Command Pattern**:
|
||||
```bash
|
||||
gemini -p "
|
||||
PURPOSE: Aggregate workflow lessons from session data
|
||||
TASK:
|
||||
• Group successes by functional domain
|
||||
• Categorize challenges by severity (HIGH/MEDIUM/LOW)
|
||||
• Identify watch patterns with frequency >= 2
|
||||
• Mark CRITICAL patterns (3+ sessions)
|
||||
MODE: analysis
|
||||
CONTEXT: @.workflow/.archives/manifest.json
|
||||
EXPECTED: Aggregated lessons with frequency counts
|
||||
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/workflow/skill-aggregation.txt)
|
||||
"
|
||||
```
|
||||
|
||||
**Severity Classification**:
|
||||
- **HIGH**: Blocked development >4 hours OR repeated in 3+ sessions
|
||||
- **MEDIUM**: Required significant rework OR repeated in 2 sessions
|
||||
- **LOW**: Minor issues resolved quickly
|
||||
|
||||
**Pattern Identification**:
|
||||
- Successes in 3+ sessions → "Best Practices"
|
||||
- Challenges repeated 2+ times → "Known Issues"
|
||||
- Watch patterns frequency >= 2 → "High Priority Warnings"
|
||||
- Watch patterns frequency >= 3 → "CRITICAL"
|
||||
|
||||
## Formatting Rules
|
||||
- Sort by frequency (most common first)
|
||||
- Include session references for traceability
|
||||
- Use bold for challenge titles
|
||||
- Keep descriptions concise but actionable
|
||||
@@ -0,0 +1,53 @@
|
||||
Template for generating sessions-timeline.md
|
||||
|
||||
## Purpose
|
||||
Create or update chronological timeline of workflow sessions with functional domain grouping.
|
||||
|
||||
## File Location
|
||||
`.claude/skills/workflow-progress/sessions-timeline.md`
|
||||
|
||||
## Update Strategy
|
||||
- **Incremental mode**: Append new session to timeline, keep existing content
|
||||
- **Full mode**: Regenerate entire timeline from all sessions
|
||||
|
||||
## Structure
|
||||
|
||||
```markdown
|
||||
# Workflow Sessions Timeline
|
||||
|
||||
## Recent Sessions (Last 5)
|
||||
|
||||
### {session_id} ({archived_date})
|
||||
**Description**: {description}
|
||||
**Tags**: {tag1}, {tag2}, {tag3}
|
||||
**Metrics**: {task_count} tasks, {success_rate}% success, {duration_hours} hours
|
||||
**Context Package**: [{session_id}/context-package.json](../../../.workflow/.archives/{session_id}/.process/context-package.json)
|
||||
|
||||
**Key Outcomes**:
|
||||
- ✅ {success_item_1}
|
||||
- ✅ {success_item_2}
|
||||
- ⚠️ Watch: {watch_pattern}
|
||||
|
||||
---
|
||||
|
||||
## By Functional Domain
|
||||
|
||||
### {Domain_Name} ({count} sessions)
|
||||
- {session_id_1} ({date}) - {one_line_description}
|
||||
- {session_id_2} ({date}) - {one_line_description}
|
||||
|
||||
### {Domain_Name_2} ({count} sessions)
|
||||
...
|
||||
```
|
||||
|
||||
## Data Sources
|
||||
- Session metadata: `.workflow/.archives/{session_id}/workflow-session.json`
|
||||
- Manifest entry: `.workflow/.archives/manifest.json`
|
||||
- Lessons: `manifest.json` -> `archives[].lessons`
|
||||
|
||||
## Formatting Rules
|
||||
- Sort recent sessions by archived_at (newest first)
|
||||
- Group by functional domain using tags
|
||||
- Use relative paths for context package links
|
||||
- Use ✅ for successes, ⚠️ for watch patterns
|
||||
- Keep descriptions concise (one line)
|
||||
@@ -14,6 +14,7 @@ type: search-guideline
|
||||
|
||||
## ⚡ Core Search Tools
|
||||
|
||||
**Skill()**: FASTEST way to get context - use FIRST if SKILL exists. Three types: (1) `workflow-progress` for WFS sessions (2) tech SKILLs for stack docs (3) `{project-name}` for project docs
|
||||
**codebase-retrieval**: Semantic file discovery via Gemini CLI with all files analysis
|
||||
**rg (ripgrep)**: Fast content search with regex support
|
||||
**find**: File/directory location by name patterns
|
||||
@@ -24,6 +25,9 @@ type: search-guideline
|
||||
|
||||
| Need | Tool | Use Case |
|
||||
|------|------|----------|
|
||||
| **Workflow history** | Skill(workflow-progress) | WFS sessions lessons/conflicts - `/memory:workflow-skill-memory` |
|
||||
| **Tech stack docs** | Skill({tech-name}) | Stack APIs/guides - `/memory:tech-research` |
|
||||
| **Project docs** | Skill({project-name}) | Project modules/architecture - `/memory:skill-memory` |
|
||||
| **Semantic discovery** | codebase-retrieval | Find files relevant to task/feature context |
|
||||
| **Pattern matching** | rg | Search code content with regex |
|
||||
| **File name lookup** | find | Locate files by name patterns |
|
||||
@@ -32,6 +36,11 @@ type: search-guideline
|
||||
## 🔧 Quick Command Reference
|
||||
|
||||
```bash
|
||||
# SKILL Packages (FIRST PRIORITY - fastest context loading)
|
||||
Skill(command: "workflow-progress") # Workflow: WFS sessions history, lessons, conflicts
|
||||
Skill(command: "react-dev") # Tech: React APIs, patterns, best practices
|
||||
Skill(command: "claude_dms3") # Project: Project modules, architecture, examples
|
||||
|
||||
# Semantic File Discovery (codebase-retrieval)
|
||||
cd [directory] && gemini -p "
|
||||
PURPOSE: Discover files relevant to task/feature
|
||||
@@ -42,7 +51,7 @@ EXPECTED: Relevant file paths with relevance explanation
|
||||
RULES: Focus on direct relevance to task requirements
|
||||
"
|
||||
|
||||
# Program Architecture (MANDATORY FIRST)
|
||||
# Program Architecture (MANDATORY before planning)
|
||||
~/.claude/scripts/get_modules_by_depth.sh
|
||||
|
||||
# Content Search (rg preferred)
|
||||
|
||||
@@ -44,6 +44,7 @@ type: strategic-guideline
|
||||
|----------|------|-----------------|
|
||||
| **Exploring/Understanding** | Gemini → Qwen | `cd [dir] && gemini -p "PURPOSE:... CONTEXT: @**/*"` |
|
||||
| **Architecture/Analysis** | Gemini → Qwen | `cd [dir] && gemini -p "PURPOSE:... CONTEXT: @**/*"` |
|
||||
| **Multi-directory Analysis** | Gemini → Qwen | `cd [main-dir] && gemini -p "CONTEXT: @**/* @../dep/**/*" --include-directories ../dep` (reduces noise) |
|
||||
| **Building/Fixing** | Codex | `codex -C [dir] --full-auto exec "PURPOSE:... MODE: auto"` |
|
||||
| **Not sure?** | Multiple | Use tools in parallel |
|
||||
| **Small task?** | Still use tools | Tools are faster than manual work |
|
||||
@@ -53,6 +54,7 @@ type: strategic-guideline
|
||||
- **When in doubt, use both** - Parallel usage provides comprehensive coverage
|
||||
- **Default to tools** - Use specialized tools for most coding tasks, no matter how small
|
||||
- **Lower barriers** - Engage tools immediately when encountering any complexity
|
||||
- **Minimize context noise** - Use `cd` + `--include-directories` to focus on relevant files, exclude unrelated directories
|
||||
- **⚠️ Write operation protection** - For local codebase write/modify operations, require EXPLICIT user confirmation unless user provides clear instructions containing MODE=write or MODE=auto
|
||||
|
||||
---
|
||||
@@ -262,7 +264,7 @@ RULES: [template reference and constraints]
|
||||
|
||||
#### Multi-Directory Support (Gemini & Qwen)
|
||||
|
||||
**Purpose**: For large projects requiring fine-grained access across multiple directories
|
||||
**Purpose**: Reduce irrelevant file noise by focusing analysis on specific directories while maintaining necessary cross-directory context
|
||||
|
||||
**Use Case**: When `cd` limits scope but you need to reference files from parent/sibling folders
|
||||
|
||||
@@ -281,6 +283,7 @@ gemini -p "prompt" --include-directories /path/to/project1,/path/to/project2
|
||||
gemini -p "prompt" --include-directories /path/to/project1 --include-directories /path/to/project2
|
||||
|
||||
# Combined with cd for focused analysis with extended context (RECOMMENDED)
|
||||
# This pattern minimizes irrelevant files by focusing on src/auth while only including necessary dependencies
|
||||
cd src/auth && gemini -p "
|
||||
PURPOSE: Analyze authentication with shared utilities context
|
||||
TASK: Review auth implementation and its dependencies
|
||||
@@ -289,13 +292,14 @@ CONTEXT: @**/* @../shared/**/* @../types/**/*
|
||||
EXPECTED: Complete analysis with cross-directory dependencies
|
||||
RULES: Focus on integration patterns
|
||||
" --include-directories ../shared,../types
|
||||
# Result: Only src/auth/**, ../shared/**, ../types/** are analyzed, other project files excluded
|
||||
```
|
||||
|
||||
**Best Practices**:
|
||||
- **Recommended Pattern**: Use `cd` to navigate to primary focus directory, then use `--include-directories` for additional context
|
||||
- Example: `cd src/auth && gemini -p "CONTEXT: @**/* @../shared/**/*" --include-directories ../shared,../types`
|
||||
- **⚠️ CRITICAL**: CONTEXT must explicitly list external files (e.g., `@../shared/**/*`), AND command must include `--include-directories ../shared`
|
||||
- Benefits: More precise file references (relative to current directory), clearer intent, better context control
|
||||
- Benefits: **Minimizes irrelevant file interference** (only includes specified directories), more precise file references (relative to current directory), clearer intent, better context control
|
||||
- **Enforcement Rule**: When CONTEXT references external directories, ALWAYS add corresponding `--include-directories`
|
||||
- Use when `cd` alone limits necessary context visibility
|
||||
- Keep directory count ≤ 5 for optimal performance
|
||||
@@ -334,6 +338,7 @@ mcp__code-index__search_code_advanced(pattern="interface.*Props", file_pattern="
|
||||
CONTEXT: @src/components/Auth.tsx @src/types/auth.d.ts @src/hooks/useAuth.ts
|
||||
|
||||
# Step 3: Execute CLI with precise file references
|
||||
# cd to src/ reduces scope; specific files further minimize context to only relevant files
|
||||
cd src && gemini -p "
|
||||
PURPOSE: Analyze authentication components
|
||||
TASK: Review auth component patterns and props interfaces
|
||||
@@ -342,6 +347,7 @@ CONTEXT: @components/Auth.tsx @types/auth.d.ts @hooks/useAuth.ts
|
||||
EXPECTED: Pattern analysis and improvement suggestions
|
||||
RULES: Focus on type safety and component composition
|
||||
"
|
||||
# Result: Only 3 specific files analyzed instead of entire src/ tree
|
||||
```
|
||||
|
||||
---
|
||||
@@ -497,6 +503,7 @@ bash(codex -C directory --full-auto exec "task") # Complex implementation: 90-1
|
||||
- Working in subdirectory but need parent/sibling context
|
||||
- Cross-directory dependency analysis required
|
||||
- Multiple related modules need simultaneous access
|
||||
- **Key benefit**: Excludes unrelated directories, reducing token usage and improving analysis precision
|
||||
|
||||
---
|
||||
|
||||
|
||||
5
.gitignore
vendored
5
.gitignore
vendored
@@ -20,4 +20,7 @@ Thumbs.db
|
||||
settings.local.json
|
||||
.workflow
|
||||
version.json
|
||||
ref
|
||||
ref
|
||||
COMMAND_FLOW_STANDARD.md
|
||||
COMMAND_TEMPLATE_EXECUTOR.md
|
||||
COMMAND_TEMPLATE_ORCHESTRATOR.md
|
||||
|
||||
274
COMMAND_FLOW_STANDARD.md
Normal file
274
COMMAND_FLOW_STANDARD.md
Normal file
@@ -0,0 +1,274 @@
|
||||
# Command Flow Expression Standard
|
||||
|
||||
**用途**:规范命令文档中Task、SlashCommand、Skill和Bash调用的标准表达方式
|
||||
|
||||
**版本**:v2.1.0
|
||||
|
||||
---
|
||||
|
||||
## 核心原则
|
||||
|
||||
1. **统一格式** - 所有调用使用标准化格式
|
||||
2. **清晰参数** - 必需参数明确标注,可选参数加方括号
|
||||
3. **减少冗余** - 避免不必要的echo命令和管道操作
|
||||
4. **工具优先** - 优先使用专用工具(Write/Read/Edit)而非Bash变通
|
||||
5. **可读性** - 保持缩进和换行的一致性
|
||||
|
||||
---
|
||||
|
||||
## 1. Task调用标准(Agent启动)
|
||||
|
||||
### 标准格式
|
||||
|
||||
```javascript
|
||||
Task(
|
||||
subagent_type="agent-type",
|
||||
description="Brief description",
|
||||
prompt=`
|
||||
FULL TASK PROMPT HERE
|
||||
`
|
||||
)
|
||||
```
|
||||
|
||||
### 规范要求
|
||||
|
||||
- `subagent_type`: Agent类型(字符串)
|
||||
- `description`: 简短描述(5-10词,动词开头)
|
||||
- `prompt`: 完整任务提示(使用反引号包裹多行内容)
|
||||
- 参数字段缩进2空格
|
||||
|
||||
### 正确示例
|
||||
|
||||
```javascript
|
||||
// CLI执行agent
|
||||
Task(
|
||||
subagent_type="cli-execution-agent",
|
||||
description="Analyze codebase patterns",
|
||||
prompt=`
|
||||
PURPOSE: Identify code patterns for refactoring
|
||||
TASK: Scan project files and extract common patterns
|
||||
MODE: analysis
|
||||
CONTEXT: @src/**/*
|
||||
EXPECTED: Pattern list with usage examples
|
||||
`
|
||||
)
|
||||
|
||||
// 代码开发agent
|
||||
Task(
|
||||
subagent_type="code-developer",
|
||||
description="Implement authentication module",
|
||||
prompt=`
|
||||
GOAL: Build JWT-based authentication
|
||||
SCOPE: User login, token validation, session management
|
||||
CONTEXT: @src/auth/**/* @CLAUDE.md
|
||||
`
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. SlashCommand调用标准
|
||||
|
||||
### 标准格式
|
||||
|
||||
```javascript
|
||||
SlashCommand(command="/category:command-name [flags] arguments")
|
||||
```
|
||||
|
||||
### 规范要求
|
||||
|
||||
单行调用 | 双引号包裹 | 完整路径`/category:command-name` | 参数顺序: 标志→参数值
|
||||
|
||||
### 正确示例
|
||||
|
||||
```javascript
|
||||
// 无参数
|
||||
SlashCommand(command="/workflow:status")
|
||||
|
||||
// 带标志和参数
|
||||
SlashCommand(command="/workflow:session:start --auto \"task description\"")
|
||||
|
||||
// 变量替换
|
||||
SlashCommand(command="/workflow:tools:context-gather --session [sessionId] \"description\"")
|
||||
|
||||
// 多个标志
|
||||
SlashCommand(command="/workflow:plan --agent --cli-execute \"feature description\"")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Skill调用标准
|
||||
|
||||
### 标准格式
|
||||
|
||||
```javascript
|
||||
Skill(command: "skill-name")
|
||||
```
|
||||
|
||||
### 规范要求
|
||||
|
||||
单行调用 | 冒号语法`command:` | 双引号包裹skill-name
|
||||
|
||||
### 正确示例
|
||||
|
||||
```javascript
|
||||
// 项目SKILL
|
||||
Skill(command: "claude_dms3")
|
||||
|
||||
// 技术栈SKILL
|
||||
Skill(command: "react-dev")
|
||||
|
||||
// 工作流SKILL
|
||||
Skill(command: "workflow-progress")
|
||||
|
||||
// 变量替换
|
||||
Skill(command: "${skill_name}")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Bash命令标准
|
||||
|
||||
### 核心原则:优先使用专用工具
|
||||
|
||||
**工具优先级**:
|
||||
1. **Write工具** → 创建/覆盖文件内容
|
||||
2. **Edit工具** → 修改现有文件内容
|
||||
3. **Read工具** → 读取文件内容
|
||||
4. **Bash命令** → 仅用于真正的系统操作(git, npm, test等)
|
||||
|
||||
### 标准格式
|
||||
|
||||
```javascript
|
||||
bash(command args)
|
||||
```
|
||||
|
||||
### 合理使用Bash的场景
|
||||
|
||||
```javascript
|
||||
// ✅ Git操作
|
||||
bash(git status --short)
|
||||
bash(git commit -m "commit message")
|
||||
|
||||
// ✅ 包管理器和测试
|
||||
bash(npm install)
|
||||
bash(npm test)
|
||||
|
||||
// ✅ 文件系统查询和文本处理
|
||||
bash(find .workflow -name "*.json" -type f)
|
||||
bash(rg "pattern" --type js --files-with-matches)
|
||||
```
|
||||
|
||||
### 避免Bash的场景
|
||||
|
||||
```javascript
|
||||
// ❌ 文件创建/写入 → 使用Write工具
|
||||
bash(echo "content" > file.txt) // 错误
|
||||
Write({file_path: "file.txt", content: "content"}) // 正确
|
||||
|
||||
// ❌ 文件读取 → 使用Read工具
|
||||
bash(cat file.txt) // 错误
|
||||
Read({file_path: "file.txt"}) // 正确
|
||||
|
||||
// ❌ 简单字符串处理 → 在代码中处理
|
||||
bash(echo "text" | tr '[:upper:]' '[:lower:]') // 错误
|
||||
"text".toLowerCase() // 正确
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 组合调用模式(伪代码准则)
|
||||
|
||||
### 核心准则
|
||||
|
||||
直接写执行逻辑(无FUNCTION/END包裹)| 用`#`注释分段 | 变量赋值`variable = value` | 条件`IF/ELSE` | 循环`FOR` | 验证`VALIDATE` | 错误`ERROR + EXIT 1`
|
||||
|
||||
### 顺序调用(依赖关系)
|
||||
|
||||
```pseudo
|
||||
# Phase 1-2: Session and Context
|
||||
sessionId = SlashCommand(command="/workflow:session:start --auto \"description\"")
|
||||
PARSE sessionId from output
|
||||
VALIDATE: bash(test -d .workflow/{sessionId})
|
||||
|
||||
contextPath = SlashCommand(command="/workflow:tools:context-gather --session {sessionId} \"desc\"")
|
||||
context_json = READ(contextPath)
|
||||
|
||||
# Phase 3-4: Conditional and Agent
|
||||
IF context_json.conflict_risk IN ["medium", "high"]:
|
||||
SlashCommand(command="/workflow:tools:conflict-resolution --session {sessionId}")
|
||||
|
||||
Task(subagent_type="action-planning-agent", description="Generate tasks", prompt=`SESSION: {sessionId}`)
|
||||
|
||||
VALIDATE: bash(test -f .workflow/{sessionId}/IMPL_PLAN.md)
|
||||
RETURN summary
|
||||
```
|
||||
|
||||
### 并行调用(无依赖)
|
||||
|
||||
```pseudo
|
||||
PARALLEL_START:
|
||||
check_git = bash(git status)
|
||||
check_count = bash(find .workflow -name "*.json" | wc -l)
|
||||
check_skill = Skill(command: "project-name")
|
||||
WAIT_ALL_COMPLETE
|
||||
VALIDATE results
|
||||
RETURN summary
|
||||
```
|
||||
|
||||
### 条件分支调用
|
||||
|
||||
```pseudo
|
||||
IF task_type CONTAINS "test": agent = "test-fix-agent"
|
||||
ELSE IF task_type CONTAINS "implement": agent = "code-developer"
|
||||
ELSE: agent = "universal-executor"
|
||||
|
||||
Skill(command: "project-name")
|
||||
Task(subagent_type=agent, description="Execute task", prompt=build_prompt(task_type))
|
||||
VALIDATE output
|
||||
RETURN result
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 变量和占位符规范
|
||||
|
||||
| 上下文 | 格式 | 示例 |
|
||||
|--------|------|------|
|
||||
| **Markdown说明** | `[variableName]` | `[sessionId]`, `[contextPath]` |
|
||||
| **JavaScript代码** | `${variableName}` | `${sessionId}`, `${contextPath}` |
|
||||
| **Bash命令** | `$variable` | `$session_id`, `$context_path` |
|
||||
|
||||
---
|
||||
|
||||
## 7. 快速检查清单
|
||||
|
||||
**Task**: subagent_type已指定 | description≤10词 | prompt用反引号 | 缩进2空格
|
||||
|
||||
**SlashCommand**: 完整路径 `/category:command` | 标志在前 | 变量用`[var]` | 双引号包裹
|
||||
|
||||
**Skill**: 冒号语法 `command:` | 双引号包裹 | 单行格式
|
||||
|
||||
**Bash**: 能用Write/Edit/Read工具吗?| 避免不必要echo | 真正的系统操作
|
||||
|
||||
---
|
||||
|
||||
## 8. 常见错误及修复
|
||||
|
||||
```javascript
|
||||
// ❌ 错误1: Bash中不必要的echo
|
||||
bash(echo '{"status":"active"}' > status.json)
|
||||
// ✅ 正确: 使用Write工具
|
||||
Write({file_path: "status.json", content: '{"status":"active"}'})
|
||||
|
||||
// ❌ 错误2: Task单行格式
|
||||
Task(subagent_type="agent", description="Do task", prompt=`...`)
|
||||
// ✅ 正确: 多行格式
|
||||
Task(subagent_type="agent", description="Do task", prompt=`...`)
|
||||
|
||||
// ❌ 错误3: Skill使用等号
|
||||
Skill(command="skill-name")
|
||||
// ✅ 正确: 使用冒号
|
||||
Skill(command: "skill-name")
|
||||
```
|
||||
|
||||
135
COMMAND_TEMPLATE_EXECUTOR.md
Normal file
135
COMMAND_TEMPLATE_EXECUTOR.md
Normal file
@@ -0,0 +1,135 @@
|
||||
# Command Template: Executor
|
||||
|
||||
**用途**:直接执行特定功能的执行器命令模板
|
||||
|
||||
**特征**:专注于自身功能实现,移除 Related Commands 段落
|
||||
|
||||
---
|
||||
|
||||
## 模板结构
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: command-name
|
||||
description: Brief description of what this command does
|
||||
argument-hint: "[flags] arguments"
|
||||
allowed-tools: Read(*), Edit(*), Write(*), Bash(*), TodoWrite(*)
|
||||
---
|
||||
|
||||
# Command Name (/category:command-name)
|
||||
|
||||
## Overview
|
||||
Clear description of what this command does and its purpose.
|
||||
|
||||
**Key Characteristics**:
|
||||
- Executes specific functionality directly
|
||||
- Does NOT orchestrate other commands
|
||||
- Focuses on single responsibility
|
||||
- Returns concrete results
|
||||
|
||||
## Core Functionality
|
||||
- Function 1: Description
|
||||
- Function 2: Description
|
||||
- Function 3: Description
|
||||
|
||||
## Usage
|
||||
|
||||
### Command Syntax
|
||||
```bash
|
||||
/category:command-name [FLAGS] <ARGUMENTS>
|
||||
|
||||
# Flags
|
||||
--flag1 Description
|
||||
--flag2 Description
|
||||
|
||||
# Arguments
|
||||
<arg1> Description
|
||||
<arg2> Description (optional)
|
||||
```
|
||||
|
||||
### Usage Examples
|
||||
```bash
|
||||
# Basic usage
|
||||
/category:command-name arg1
|
||||
|
||||
# With flags
|
||||
/category:command-name --flag1 --flag2 arg1
|
||||
```
|
||||
|
||||
## Execution Process
|
||||
|
||||
### Step 1: Step Name
|
||||
Description of what happens in this step
|
||||
|
||||
**Operations**:
|
||||
- Operation 1
|
||||
- Operation 2
|
||||
|
||||
**Validation**:
|
||||
- Check 1
|
||||
- Check 2
|
||||
|
||||
---
|
||||
|
||||
### Step 2: Step Name
|
||||
[Repeat for each step]
|
||||
|
||||
---
|
||||
|
||||
## Input/Output
|
||||
|
||||
### Input Requirements
|
||||
- Input 1: Description and format
|
||||
- Input 2: Description and format
|
||||
|
||||
### Output Format
|
||||
```
|
||||
Output description and structure
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Errors
|
||||
| Error | Cause | Resolution |
|
||||
|-------|-------|------------|
|
||||
| Error message 1 | Root cause | How to fix |
|
||||
| Error message 2 | Root cause | How to fix |
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Practice 1**: Description and rationale
|
||||
2. **Practice 2**: Description and rationale
|
||||
3. **Practice 3**: Description and rationale
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 使用规则
|
||||
|
||||
### 核心原则
|
||||
1. **移除 Related Commands** - 执行器不协调其他命令
|
||||
2. **专注单一职责** - 每个执行器只做一件事
|
||||
3. **清晰的步骤划分** - 明确执行流程
|
||||
4. **完整的错误处理** - 列出常见错误和解决方案
|
||||
|
||||
### 可选段落
|
||||
根据命令特性,以下段落可选:
|
||||
- **Configuration**: 有配置参数时使用
|
||||
- **Output Files**: 生成文件时使用
|
||||
- **Exit Codes**: 有明确退出码时使用
|
||||
- **Environment Variables**: 依赖环境变量时使用
|
||||
|
||||
### 格式要求
|
||||
- 无 emoji/图标装饰
|
||||
- 纯文本状态指示器
|
||||
- 使用表格组织错误信息
|
||||
- 提供实用的示例代码
|
||||
|
||||
## 示例参考
|
||||
|
||||
参考已重构的执行器命令:
|
||||
- `.claude/commands/task/create.md`
|
||||
- `.claude/commands/task/breakdown.md`
|
||||
- `.claude/commands/task/execute.md`
|
||||
- `.claude/commands/cli/execute.md`
|
||||
- `.claude/commands/version.md`
|
||||
140
COMMAND_TEMPLATE_ORCHESTRATOR.md
Normal file
140
COMMAND_TEMPLATE_ORCHESTRATOR.md
Normal file
@@ -0,0 +1,140 @@
|
||||
# Command Template: Orchestrator
|
||||
|
||||
**用途**:协调多个子命令的编排器命令模板
|
||||
|
||||
**特征**:保留 Related Commands 段落,明确说明调用的命令链
|
||||
|
||||
---
|
||||
|
||||
## 模板结构
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: command-name
|
||||
description: Brief description of what this command orchestrates
|
||||
argument-hint: "[flags] arguments"
|
||||
allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
|
||||
---
|
||||
|
||||
# Command Name (/category:command-name)
|
||||
|
||||
## Overview
|
||||
Clear description of what this command orchestrates and its role.
|
||||
|
||||
**Key Characteristics**:
|
||||
- Orchestrates X phases/commands
|
||||
- Coordinates between multiple slash commands
|
||||
- Does NOT execute directly - delegates to specialized commands
|
||||
- Manages workflow state and progress tracking
|
||||
|
||||
## Core Responsibilities
|
||||
- Responsibility 1: Description
|
||||
- Responsibility 2: Description
|
||||
- Responsibility 3: Description
|
||||
|
||||
## Execution Flow
|
||||
|
||||
### Phase 1: Phase Name
|
||||
**Command**: `SlashCommand(command="/command:name args")`
|
||||
|
||||
**Input**: Description of inputs
|
||||
|
||||
**Expected Behavior**:
|
||||
- Behavior 1
|
||||
- Behavior 2
|
||||
|
||||
**Parse Output**:
|
||||
- Extract: variable name (pattern description)
|
||||
|
||||
**Validation**:
|
||||
- Validation rule 1
|
||||
- Validation rule 2
|
||||
|
||||
**TodoWrite**: Mark phase 1 completed, phase 2 in_progress
|
||||
|
||||
---
|
||||
|
||||
### Phase 2: Phase Name
|
||||
[Repeat structure for each phase]
|
||||
|
||||
---
|
||||
|
||||
## TodoWrite Pattern
|
||||
|
||||
Track progress through all phases:
|
||||
|
||||
```javascript
|
||||
TodoWrite({todos: [
|
||||
{"content": "Execute phase 1", "status": "in_progress|completed", "activeForm": "Executing phase 1"},
|
||||
{"content": "Execute phase 2", "status": "pending|in_progress|completed", "activeForm": "Executing phase 2"},
|
||||
{"content": "Execute phase 3", "status": "pending|in_progress|completed", "activeForm": "Executing phase 3"}
|
||||
]})
|
||||
```
|
||||
|
||||
## Data Flow
|
||||
|
||||
```
|
||||
Phase 1: command-1 → output-1
|
||||
↓
|
||||
Phase 2: command-2 (input: output-1) → output-2
|
||||
↓
|
||||
Phase 3: command-3 (input: output-2) → final-result
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Phase | Error | Action |
|
||||
|-------|-------|--------|
|
||||
| 1 | Error description | Recovery action |
|
||||
| 2 | Error description | Recovery action |
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Basic Usage
|
||||
```bash
|
||||
/category:command-name
|
||||
/category:command-name --flag "argument"
|
||||
```
|
||||
|
||||
## Related Commands
|
||||
|
||||
**Prerequisite Commands**:
|
||||
- `/command:prerequisite` - Description of when to use before this
|
||||
|
||||
**Called by This Command**:
|
||||
- `/command:phase1` - Description (Phase 1)
|
||||
- `/command:phase2` - Description (Phase 2)
|
||||
- `/command:phase3` - Description (Phase 3)
|
||||
|
||||
**Follow-up Commands**:
|
||||
- `/command:next` - Description of what to do after this
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 使用规则
|
||||
|
||||
### 核心原则
|
||||
1. **保留 Related Commands** - 明确说明命令调用链
|
||||
2. **清晰的阶段划分** - 每个Phase独立可追踪
|
||||
3. **数据流可视化** - 展示Phase间的数据传递
|
||||
4. **TodoWrite追踪** - 实时更新执行进度
|
||||
|
||||
### Related Commands 分类
|
||||
- **Prerequisite Commands**: 执行本命令前需要先运行的命令
|
||||
- **Called by This Command**: 本命令会调用的子命令(按阶段分组)
|
||||
- **Follow-up Commands**: 执行本命令后的推荐下一步
|
||||
|
||||
### 格式要求
|
||||
- 无 emoji/图标装饰
|
||||
- 纯文本状态指示器
|
||||
- 使用表格组织错误信息
|
||||
- 清晰的数据流图
|
||||
|
||||
## 示例参考
|
||||
|
||||
参考已重构的编排器命令:
|
||||
- `.claude/commands/workflow/plan.md`
|
||||
- `.claude/commands/workflow/execute.md`
|
||||
- `.claude/commands/workflow/session/complete.md`
|
||||
- `.claude/commands/workflow/session/start.md`
|
||||
Reference in New Issue
Block a user