@zenuml/core 3.32.6 → 3.33.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/commands/README.md +162 -0
- package/.claude/commands/code-review.md +322 -0
- package/.claude/commands/create-docs.md +309 -0
- package/.claude/commands/full-context.md +121 -0
- package/.claude/commands/gemini-consult.md +164 -0
- package/.claude/commands/handoff.md +146 -0
- package/.claude/commands/refactor.md +188 -0
- package/.claude/commands/update-docs.md +314 -0
- package/.claude/hooks/README.md +270 -0
- package/.claude/hooks/config/sensitive-patterns.json +86 -0
- package/.claude/hooks/gemini-context-injector.sh +129 -0
- package/.claude/hooks/mcp-security-scan.sh +147 -0
- package/.claude/hooks/notify.sh +103 -0
- package/.claude/hooks/setup/hook-setup.md +96 -0
- package/.claude/hooks/setup/settings.json.template +63 -0
- package/.claude/hooks/sounds/complete.wav +0 -0
- package/.claude/hooks/sounds/input-needed.wav +0 -0
- package/.claude/hooks/subagent-context-injector.sh +65 -0
- package/.storybook/main.ts +25 -0
- package/.storybook/preview.ts +29 -0
- package/MCP-ASSISTANT-RULES.md +85 -0
- package/README.md +1 -1
- package/TUTORIAL.md +116 -0
- package/dist/zenuml.esm.mjs +4649 -4598
- package/dist/zenuml.js +52 -52
- package/docs/CONTEXT-tier2-component.md +96 -0
- package/docs/CONTEXT-tier3-feature.md +162 -0
- package/docs/README.md +207 -0
- package/docs/ai-context/deployment-infrastructure.md +21 -0
- package/docs/ai-context/docs-overview.md +89 -0
- package/docs/ai-context/handoff.md +174 -0
- package/docs/ai-context/project-structure.md +160 -0
- package/docs/ai-context/system-integration.md +21 -0
- package/docs/open-issues/example-api-performance-issue.md +79 -0
- package/eslint.config.mjs +26 -26
- package/package.json +9 -2
- package/tailwind.config.js +0 -4
- package/docs/asciidoc/integration-guide.adoc +0 -121
|
@@ -0,0 +1,146 @@
|
|
|
1
|
+
You are concluding work on the VR Language Learning App project and need to create a comprehensive handoff for the next AI session. This command intelligently analyzes your current session achievements and updates the handoff document with both auto-detected progress and user-provided context.
|
|
2
|
+
|
|
3
|
+
## Auto-Loaded Project Context:
|
|
4
|
+
@docs/ai-context/HANDOFF.md
|
|
5
|
+
@/CLAUDE.md
|
|
6
|
+
|
|
7
|
+
## Step 1: Process User Arguments
|
|
8
|
+
|
|
9
|
+
Handle the arguments flexibly:
|
|
10
|
+
- **With Arguments**: `$ARGUMENTS` provides user context about what was accomplished or attempted
|
|
11
|
+
- **Without Arguments**: Focus purely on auto-detection from session analysis
|
|
12
|
+
|
|
13
|
+
User provided context: "$ARGUMENTS"
|
|
14
|
+
|
|
15
|
+
## Step 2: Analyze Current Session Achievements
|
|
16
|
+
|
|
17
|
+
Think about what was accomplished in this session and how to best capture it for handoff. Review your recent conversation and tool usage to identify significant work:
|
|
18
|
+
|
|
19
|
+
**Auto-Detect Evidence of:**
|
|
20
|
+
- **File Operations** (Write, Edit, MultiEdit tools) - what files were modified and why
|
|
21
|
+
- **New Features** - functionality added or implemented
|
|
22
|
+
- **Bug Fixes** - issues resolved or debugging attempts
|
|
23
|
+
- **Architecture Changes** - structural improvements or refactoring
|
|
24
|
+
- **Configuration Updates** - settings, dependencies, or environment changes
|
|
25
|
+
- **Documentation Work** - updates to documentation files
|
|
26
|
+
- **Incomplete Work** - attempts that didn't reach completion
|
|
27
|
+
- **Blockers Encountered** - issues that prevented completion
|
|
28
|
+
|
|
29
|
+
**Generate Session Summary:**
|
|
30
|
+
```
|
|
31
|
+
Session Analysis:
|
|
32
|
+
- Primary work area: [component/domain affected]
|
|
33
|
+
- Main accomplishments: [key achievements]
|
|
34
|
+
- Files modified: [list of changed files]
|
|
35
|
+
- Status: [completed/in-progress/blocked]
|
|
36
|
+
- User context: [if $ARGUMENTS provided]
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
## Step 3: Analyze Auto-Loaded HANDOFF.md
|
|
40
|
+
|
|
41
|
+
Analyze the auto-loaded `docs/ai-context/HANDOFF.md` to understand:
|
|
42
|
+
- **Existing sections** and their current status
|
|
43
|
+
- **Related ongoing work** that might connect to your session
|
|
44
|
+
- **Structure and formatting** patterns to maintain consistency
|
|
45
|
+
- **Unrelated content** that should be preserved
|
|
46
|
+
|
|
47
|
+
## Step 4: Determine Update Strategy
|
|
48
|
+
|
|
49
|
+
Think about how to best update the handoff based on this session's work. Based on your session analysis and the auto-loaded existing handoff content, decide:
|
|
50
|
+
|
|
51
|
+
**If Current Work Relates to Existing Task:**
|
|
52
|
+
- Update the existing section with new progress
|
|
53
|
+
- Add accomplishments to "What Was Accomplished"
|
|
54
|
+
- Update "Current Status" and "Current Issue" if resolved
|
|
55
|
+
- Modify "Next Steps" based on new state
|
|
56
|
+
|
|
57
|
+
**If Current Work is New/Unrelated:**
|
|
58
|
+
- Create a new section with descriptive title
|
|
59
|
+
- Include timestamp for session identification
|
|
60
|
+
- Follow existing document structure and formatting
|
|
61
|
+
|
|
62
|
+
**If Work Completed an Existing Task:**
|
|
63
|
+
- Mark the task as completed
|
|
64
|
+
- Summarize final outcome
|
|
65
|
+
- Consider archiving or removing if fully resolved
|
|
66
|
+
|
|
67
|
+
## Step 5: Update HANDOFF.md Intelligently
|
|
68
|
+
|
|
69
|
+
Make targeted updates to the auto-loaded HANDOFF.md:
|
|
70
|
+
|
|
71
|
+
### For New Sections, Include:
|
|
72
|
+
```markdown
|
|
73
|
+
## [Task Title] - [Status]
|
|
74
|
+
|
|
75
|
+
### Current Status
|
|
76
|
+
[Brief description of current state]
|
|
77
|
+
|
|
78
|
+
### What Was Accomplished
|
|
79
|
+
[Bulleted list of concrete achievements with file paths]
|
|
80
|
+
|
|
81
|
+
### Current Issue (if applicable)
|
|
82
|
+
[Any blockers or unresolved problems]
|
|
83
|
+
|
|
84
|
+
### Next Steps to [Objective]
|
|
85
|
+
[Actionable items for continuation]
|
|
86
|
+
|
|
87
|
+
### Key Files to Review
|
|
88
|
+
[List of relevant files organized by category]
|
|
89
|
+
|
|
90
|
+
### Context for Next Session
|
|
91
|
+
[Important notes for continuity]
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
### For Updates to Existing Sections:
|
|
95
|
+
- **Add to accomplishments** without duplicating existing content
|
|
96
|
+
- **Update status** if progress changed the situation
|
|
97
|
+
- **Modify current issues** if problems were resolved or new ones discovered
|
|
98
|
+
- **Refresh next steps** based on new progress
|
|
99
|
+
|
|
100
|
+
## Step 6: Maintain Document Quality
|
|
101
|
+
|
|
102
|
+
Ensure your updates follow these guidelines:
|
|
103
|
+
|
|
104
|
+
**Content Quality:**
|
|
105
|
+
- **Specific**: Include exact file paths and technical details
|
|
106
|
+
- **Actionable**: Provide clear next steps for continuation
|
|
107
|
+
- **Contextual**: Explain the reasoning behind decisions
|
|
108
|
+
- **Current**: Reflect the actual state after your session
|
|
109
|
+
|
|
110
|
+
**Formatting Consistency:**
|
|
111
|
+
- Follow existing markdown structure and patterns
|
|
112
|
+
- Use consistent heading levels and formatting
|
|
113
|
+
- Maintain bullet point styles and organization
|
|
114
|
+
- Preserve the document's overall structure
|
|
115
|
+
|
|
116
|
+
**Information Management:**
|
|
117
|
+
- **Don't duplicate** existing information unless updating it
|
|
118
|
+
- **Preserve unrelated** sections that weren't part of your work
|
|
119
|
+
- **Consolidate** related information rather than fragmenting it
|
|
120
|
+
- **Archive completed** work appropriately
|
|
121
|
+
|
|
122
|
+
## Step 7: Final Verification
|
|
123
|
+
|
|
124
|
+
Before completing, verify that your handoff:
|
|
125
|
+
- **Accurately reflects** what was accomplished in the session
|
|
126
|
+
- **Combines** auto-detected technical changes with user-provided context
|
|
127
|
+
- **Provides clear direction** for the next AI session
|
|
128
|
+
- **Maintains continuity** with existing handoff content
|
|
129
|
+
- **Is immediately actionable** for someone picking up the work
|
|
130
|
+
|
|
131
|
+
## Quality Standards
|
|
132
|
+
|
|
133
|
+
**Be Comprehensive But Concise:**
|
|
134
|
+
- Include all relevant technical details
|
|
135
|
+
- Focus on actionable information
|
|
136
|
+
- Avoid redundancy with existing content
|
|
137
|
+
|
|
138
|
+
**Maintain Professional Handoff Quality:**
|
|
139
|
+
- Clear problem statements and current status
|
|
140
|
+
- Specific file references and technical context
|
|
141
|
+
- Logical next steps that build on current progress
|
|
142
|
+
- Helpful context that speeds up the next session
|
|
143
|
+
|
|
144
|
+
This intelligent handoff approach ensures smooth continuity between AI sessions while capturing both the technical reality of what was accomplished and the user's perspective on the work.
|
|
145
|
+
|
|
146
|
+
Now analyze your session, combine it with the user context "$ARGUMENTS", and update the handoff document accordingly.
|
|
@@ -0,0 +1,188 @@
|
|
|
1
|
+
You are working on the VR Language Learning App project. The user has requested to refactor specific files tagged with @ symbols in their arguments: "$ARGUMENTS"
|
|
2
|
+
|
|
3
|
+
## Auto-Loaded Project Context:
|
|
4
|
+
@/CLAUDE.md
|
|
5
|
+
@/docs/ai-context/project-structure.md
|
|
6
|
+
@/docs/ai-context/docs-overview.md
|
|
7
|
+
|
|
8
|
+
## Step 1: Parse Tagged Files
|
|
9
|
+
Extract all @ tagged file paths from the user's arguments. Only process files that are explicitly tagged with @ symbols.
|
|
10
|
+
|
|
11
|
+
**Example parsing:**
|
|
12
|
+
- Input: "refactor @src/big-file.ts @components/Large.svelte"
|
|
13
|
+
- Extract: ["src/big-file.ts", "components/Large.svelte"]
|
|
14
|
+
|
|
15
|
+
## Step 2: Validate and Analyze Files
|
|
16
|
+
For each tagged file:
|
|
17
|
+
1. **Verify file exists** - If file doesn't exist, inform user and skip
|
|
18
|
+
2. **Read file contents** - Understand the structure and dependencies
|
|
19
|
+
3. **Analyze current directory structure** - Map existing patterns around the file
|
|
20
|
+
|
|
21
|
+
## Step 3: Intelligent Analysis Strategy Decision
|
|
22
|
+
Think deeply about the safest and most effective refactoring approach based on the auto-loaded project context. Based on the initial analysis from Step 2 and the auto-loaded project context, intelligently decide the optimal approach for each file:
|
|
23
|
+
|
|
24
|
+
### Strategy Options:
|
|
25
|
+
|
|
26
|
+
**Direct Refactoring** (0-1 sub-agents):
|
|
27
|
+
- Simple files with clear, obvious split points
|
|
28
|
+
- Files with minimal external dependencies
|
|
29
|
+
- Standard refactoring patterns (e.g., extract utils, split large classes)
|
|
30
|
+
- Low risk of breaking changes
|
|
31
|
+
|
|
32
|
+
**Focused Analysis** (2-3 sub-agents):
|
|
33
|
+
- Moderate complexity with specific concerns
|
|
34
|
+
- Files with moderate dependency footprint
|
|
35
|
+
- When one aspect needs deep analysis (e.g., complex dependencies OR intricate file structure)
|
|
36
|
+
|
|
37
|
+
**Comprehensive Analysis** (3+ sub-agents):
|
|
38
|
+
- High complexity files with multiple concerns
|
|
39
|
+
- Extensive dependency networks
|
|
40
|
+
- Novel refactoring patterns not seen in project
|
|
41
|
+
- High risk of breaking changes
|
|
42
|
+
- Files that are central to multiple systems
|
|
43
|
+
|
|
44
|
+
## Step 4: Execute Chosen Strategy
|
|
45
|
+
|
|
46
|
+
### For Direct Refactoring:
|
|
47
|
+
Proceed with straightforward refactoring using the initial analysis and project context.
|
|
48
|
+
|
|
49
|
+
### For Sub-Agent Approaches:
|
|
50
|
+
You have complete autonomy to design and launch sub-agents based on the specific refactoring needs identified. Consider these key investigation areas and design custom agents to cover what's most relevant:
|
|
51
|
+
|
|
52
|
+
**Core Investigation Areas to Consider:**
|
|
53
|
+
- **File Structure Analysis**: Logical component boundaries, split points, cohesion assessment
|
|
54
|
+
- **Dependency Network Mapping**: Import/export analysis, usage patterns, circular dependency risks
|
|
55
|
+
- **Project Pattern Compliance**: Directory structures, naming conventions, organizational patterns
|
|
56
|
+
- **Impact Assessment**: Test files, configuration files, build scripts that need updates
|
|
57
|
+
- **Import Update Analysis**: All files that import from the target file and need updated import paths
|
|
58
|
+
- **Technology Stack Considerations**: Language-specific patterns, framework conventions
|
|
59
|
+
|
|
60
|
+
**Autonomous Sub-Agent Design Principles:**
|
|
61
|
+
- **Custom Specialization**: Define agents based on the specific file's complexity and risks
|
|
62
|
+
- **Flexible Agent Count**: Use as many agents as needed - scale based on actual complexity
|
|
63
|
+
- **Adaptive Coverage**: Ensure critical aspects are covered without unnecessary overlap
|
|
64
|
+
- **Risk-Focused Analysis**: Prioritize investigation of the highest-risk refactoring aspects
|
|
65
|
+
|
|
66
|
+
**Sub-Agent Task Template:**
|
|
67
|
+
```
|
|
68
|
+
Task: "Analyze [SPECIFIC_INVESTIGATION_AREA] for safe refactoring of [TARGET_FILE] related to user request '$ARGUMENTS'"
|
|
69
|
+
|
|
70
|
+
Standard Investigation Workflow:
|
|
71
|
+
1. Review auto-loaded project context (CLAUDE.md, project-structure.md, docs-overview.md)
|
|
72
|
+
2. [CUSTOM_ANALYSIS_STEPS] - Investigate the specific area thoroughly
|
|
73
|
+
3. Return actionable findings that support safe and effective refactoring
|
|
74
|
+
|
|
75
|
+
Return comprehensive findings addressing this investigation area."
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
**CRITICAL: When launching sub-agents, always use parallel execution with a single message containing multiple Task tool invocations.**
|
|
79
|
+
|
|
80
|
+
|
|
81
|
+
## Step 5: Synthesize Analysis and Plan Refactoring
|
|
82
|
+
|
|
83
|
+
Think deeply about integrating findings from all sub-agent investigations for safe and effective refactoring. Combine findings from all agents to create optimal refactoring strategy:
|
|
84
|
+
|
|
85
|
+
### Integration Analysis
|
|
86
|
+
- **File Structure**: Use File Analysis Agent's component breakdown
|
|
87
|
+
- **Organization**: Apply Pattern Recognition Agent's directory recommendations
|
|
88
|
+
- **Safety**: Implement Dependency Analysis Agent's import/export strategy
|
|
89
|
+
- **Completeness**: Address Impact Assessment Agent's broader concerns
|
|
90
|
+
|
|
91
|
+
### Refactoring Strategy Decision
|
|
92
|
+
Based on synthesized analysis, determine:
|
|
93
|
+
- **Split granularity**: How many files and what logical divisions
|
|
94
|
+
- **Directory structure**: Same-level, subdirectory, or existing directory placement
|
|
95
|
+
- **Import/export strategy**: How to restructure exports and update all consuming files
|
|
96
|
+
- **File naming**: Following project conventions and clarity
|
|
97
|
+
|
|
98
|
+
### Risk Assessment
|
|
99
|
+
- **Breaking changes**: Identify and mitigate potential issues
|
|
100
|
+
- **Dependency conflicts**: Plan import/export restructuring
|
|
101
|
+
- **Test impacts**: Plan for test file updates
|
|
102
|
+
- **Documentation needs**: Identify doc updates required
|
|
103
|
+
|
|
104
|
+
## Step 6: Refactoring Value Assessment
|
|
105
|
+
|
|
106
|
+
### Evaluate Refactoring Worth
|
|
107
|
+
After synthesizing all analysis, critically evaluate whether the proposed refactoring will actually improve the codebase:
|
|
108
|
+
|
|
109
|
+
**Positive Indicators (Worth Refactoring):**
|
|
110
|
+
- File significantly exceeds reasonable size limits (500+ lines for components, 1000+ for utilities)
|
|
111
|
+
- Clear separation of concerns violations (UI mixed with business logic, multiple unrelated features)
|
|
112
|
+
- High cyclomatic complexity that would be reduced
|
|
113
|
+
- Repeated code patterns that could be abstracted
|
|
114
|
+
- Poor testability that would improve with modularization
|
|
115
|
+
- Dependencies would become cleaner and more maintainable
|
|
116
|
+
- Aligns with project's architectural patterns
|
|
117
|
+
|
|
118
|
+
**Negative Indicators (Not Worth Refactoring):**
|
|
119
|
+
- File is already well-organized despite its size
|
|
120
|
+
- Splitting would create artificial boundaries that reduce clarity
|
|
121
|
+
- Would introduce unnecessary complexity or abstraction
|
|
122
|
+
- Dependencies would become more convoluted
|
|
123
|
+
- File serves a single, cohesive purpose effectively
|
|
124
|
+
- Refactoring would violate project conventions
|
|
125
|
+
- Minimal actual improvement in maintainability
|
|
126
|
+
|
|
127
|
+
### Decision Point
|
|
128
|
+
Based on the assessment:
|
|
129
|
+
|
|
130
|
+
**If Refactoring IS Worth It:**
|
|
131
|
+
- Print clear summary of benefits: "✅ This refactoring will improve the codebase by: [specific benefits]"
|
|
132
|
+
- Proceed automatically to Step 7 (Execute Refactoring)
|
|
133
|
+
|
|
134
|
+
**If Refactoring IS NOT Worth It:**
|
|
135
|
+
- Be brutally honest about why: "❌ This refactoring is not recommended because: [specific reasons]"
|
|
136
|
+
- Explain what makes the current structure acceptable
|
|
137
|
+
- Ask user explicitly: "The file is currently well-structured for its purpose. Do you still want to proceed with the refactoring? (yes/no)"
|
|
138
|
+
- Only continue if user confirms
|
|
139
|
+
|
|
140
|
+
## Step 7: Execute Refactoring
|
|
141
|
+
|
|
142
|
+
Implement the refactoring based on the synthesized analysis:
|
|
143
|
+
|
|
144
|
+
### File Creation Order
|
|
145
|
+
1. **Create directories** - Create any new subdirectories needed
|
|
146
|
+
2. **Create core files** - Start with main/index files
|
|
147
|
+
3. **Create supporting files** - Types, utils, constants
|
|
148
|
+
4. **Update imports** - Fix all import/export statements
|
|
149
|
+
5. **Update original file** - Replace with new modular structure
|
|
150
|
+
|
|
151
|
+
### Import/Export Management
|
|
152
|
+
- **Update all consuming files** - Modify import statements to point to new file locations
|
|
153
|
+
- **Restructure exports** - Organize exports in the new file structure
|
|
154
|
+
- **Update relative imports** - Fix paths throughout the codebase
|
|
155
|
+
- **Follow naming conventions** - Use project's established patterns
|
|
156
|
+
|
|
157
|
+
### Quality Assurance
|
|
158
|
+
- **Preserve functionality** - Ensure no breaking changes
|
|
159
|
+
- **Maintain type safety** - Keep all TypeScript types intact
|
|
160
|
+
- **Follow coding standards** - Apply project's style guidelines
|
|
161
|
+
- **Test compatibility** - Verify imports work correctly
|
|
162
|
+
|
|
163
|
+
|
|
164
|
+
## Step 8: Quality Verification
|
|
165
|
+
|
|
166
|
+
For each refactored file:
|
|
167
|
+
- **Check imports** - Verify all imports resolve correctly
|
|
168
|
+
- **Run type checks** - Ensure TypeScript compilation passes
|
|
169
|
+
- **Test functionality** - Confirm no breaking changes
|
|
170
|
+
- **Validate structure** - Ensure new organization follows project patterns
|
|
171
|
+
|
|
172
|
+
|
|
173
|
+
## Error Handling
|
|
174
|
+
- **File not found** - Skip and inform user
|
|
175
|
+
- **Not worth refactoring** - Skip files that are good as is and give users an explanation.
|
|
176
|
+
- **Parse errors** - Report syntax issues and skip
|
|
177
|
+
- **Import conflicts** - Resolve or report issues
|
|
178
|
+
|
|
179
|
+
## Summary Format
|
|
180
|
+
Provide a comprehensive summary of:
|
|
181
|
+
- **Analysis Results**: Key findings from each sub-agent
|
|
182
|
+
- **Refactoring Strategy**: Chosen approach and rationale
|
|
183
|
+
- **Value Assessment**: Whether refactoring improves the code (from Step 6)
|
|
184
|
+
- **Files Created**: New structure with explanations (if refactoring proceeded)
|
|
185
|
+
- **Dependencies Fixed**: Import/export changes made (if refactoring proceeded)
|
|
186
|
+
- **Issues Encountered**: Any problems and resolutions
|
|
187
|
+
|
|
188
|
+
Now proceed with multi-agent analysis and refactoring of the tagged files: $ARGUMENTS
|
|
@@ -0,0 +1,314 @@
|
|
|
1
|
+
You have just completed work on the VR Language Learning App project. Analyze changes based on the provided context and automatically update relevant documentation.
|
|
2
|
+
|
|
3
|
+
## Auto-Loaded Project Context:
|
|
4
|
+
@/CLAUDE.md
|
|
5
|
+
@/docs/ai-context/project-structure.md
|
|
6
|
+
@/docs/ai-context/docs-overview.md
|
|
7
|
+
|
|
8
|
+
## Core Documentation Principle: Document Current State Only
|
|
9
|
+
|
|
10
|
+
**CRITICAL: Always document the current "is" state of the system. Never reference legacy implementations, describe improvements made, or explain what changed. Documentation should read as if the current implementation has always existed.**
|
|
11
|
+
|
|
12
|
+
### Documentation Anti-Patterns to Avoid:
|
|
13
|
+
- ❌ "Refactored the voice pipeline to use streaming instead of batch processing"
|
|
14
|
+
- ❌ "Improved performance by implementing caching"
|
|
15
|
+
- ❌ "Previously used X, now uses Y for better results"
|
|
16
|
+
- ❌ "Legacy implementation has been replaced with..."
|
|
17
|
+
|
|
18
|
+
### Documentation Best Practices:
|
|
19
|
+
- ✅ "The voice pipeline uses streaming for real-time processing"
|
|
20
|
+
- ✅ "Implements caching for frequently accessed data"
|
|
21
|
+
- ✅ "Uses Y for optimal results"
|
|
22
|
+
- ✅ "The system architecture follows..."
|
|
23
|
+
|
|
24
|
+
## Step 1: Analyze Changes Based on Input
|
|
25
|
+
|
|
26
|
+
### Determine Analysis Mode:
|
|
27
|
+
- **No input (default)**: Analyze recent conversation context
|
|
28
|
+
- **Git commit ID** (e.g., "3b8d24e" or full hash): Analyze specific commit
|
|
29
|
+
- **"uncommitted"/"staged"/"working"**: Analyze uncommitted changes
|
|
30
|
+
- **"last N commits"** (e.g., "last 3 commits"): Analyze recent commits
|
|
31
|
+
|
|
32
|
+
### Execute Analysis:
|
|
33
|
+
Based on the input parameter:
|
|
34
|
+
|
|
35
|
+
#### For Git Commit Analysis:
|
|
36
|
+
```bash
|
|
37
|
+
# Get commit details
|
|
38
|
+
git show --name-status [COMMIT_ID]
|
|
39
|
+
git diff [COMMIT_ID]^ [COMMIT_ID]
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
#### For Uncommitted Changes:
|
|
43
|
+
```bash
|
|
44
|
+
# Get staged and unstaged changes
|
|
45
|
+
git status --porcelain
|
|
46
|
+
git diff HEAD
|
|
47
|
+
git diff --cached
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
#### For Recent Commits:
|
|
51
|
+
```bash
|
|
52
|
+
# Get recent commit history
|
|
53
|
+
git log --oneline -n [N]
|
|
54
|
+
git diff HEAD~[N] HEAD
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
#### For Session Context (default):
|
|
58
|
+
Review your recent conversation and tool usage for significant changes.
|
|
59
|
+
|
|
60
|
+
**Look for Evidence of Documentation-Relevant Changes:**
|
|
61
|
+
- **New features or components** (functionality that needs documenting)
|
|
62
|
+
- **Architecture decisions** (new patterns, structural changes, design decisions)
|
|
63
|
+
- **Technology stack changes** (new dependencies, framework additions, integration changes)
|
|
64
|
+
- **API changes** (new endpoints, modified interfaces, breaking changes)
|
|
65
|
+
- **Configuration changes** (new environment variables, settings, deployment requirements)
|
|
66
|
+
- **File structure changes** (new directories, moved components, reorganized code)
|
|
67
|
+
|
|
68
|
+
**Exclude from Documentation Updates:**
|
|
69
|
+
- Performance optimizations without architectural impact
|
|
70
|
+
- Bug fixes that don't change interfaces or patterns
|
|
71
|
+
- Code cleanup, refactoring that doesn't affect usage
|
|
72
|
+
- Logging improvements, debugging enhancements
|
|
73
|
+
- Test additions without new functionality
|
|
74
|
+
|
|
75
|
+
**Generate a brief summary** of what was accomplished:
|
|
76
|
+
```
|
|
77
|
+
Analysis source: [session context/commit ID/uncommitted changes]
|
|
78
|
+
Detected changes: [1-2 sentence summary of main work done]
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
## Step 2: Understand Project Context and Documentation Structure
|
|
82
|
+
|
|
83
|
+
Analyze the auto-loaded foundational files:
|
|
84
|
+
1. `/CLAUDE.md` - **CRITICAL:** Understand AI instructions, coding standards, and development protocols that govern the project
|
|
85
|
+
2. `/docs/ai-context/project-structure.md` - **FOUNDATION:** Technology stack, complete file tree and architecture overview
|
|
86
|
+
3. `/docs/ai-context/docs-overview.md` - Understand:
|
|
87
|
+
- What documentation files exist and their purposes
|
|
88
|
+
- How the documentation is organized
|
|
89
|
+
- Which types of changes map to which documentation
|
|
90
|
+
|
|
91
|
+
**AI-First Documentation Principle**: Remember that documentation is primarily for AI consumption - optimize for file path references, clear structure markers, and machine-readable patterns that enable efficient context loading.
|
|
92
|
+
|
|
93
|
+
## Step 3: Intelligent Update Strategy Decision
|
|
94
|
+
|
|
95
|
+
Think deeply about the documentation updates needed based on the auto-loaded project context and detected changes. Based on the detected changes from Step 1 AND the auto-loaded project context, intelligently decide the optimal approach:
|
|
96
|
+
|
|
97
|
+
### Strategy Options:
|
|
98
|
+
|
|
99
|
+
**Direct Update** (0-1 sub-agents):
|
|
100
|
+
- Simple file modifications with clear documentation mapping
|
|
101
|
+
- Bug fixes or minor enhancements that don't affect architecture
|
|
102
|
+
- Changes confined to a single component or feature area
|
|
103
|
+
- Standard patterns already well-documented in the project
|
|
104
|
+
|
|
105
|
+
**Focused Analysis** (2-3 sub-agents):
|
|
106
|
+
- Moderate complexity changes affecting multiple files
|
|
107
|
+
- New features that introduce novel patterns
|
|
108
|
+
- Changes that span 2-3 components or documentation tiers
|
|
109
|
+
- Technology stack updates requiring validation across docs
|
|
110
|
+
|
|
111
|
+
**Comprehensive Analysis** (3+ sub-agents):
|
|
112
|
+
- Complex architectural changes affecting multiple system areas
|
|
113
|
+
- Major refactoring that restructures component relationships
|
|
114
|
+
- New integrations that create cross-system dependencies
|
|
115
|
+
- Changes that require extensive documentation cascade updates
|
|
116
|
+
|
|
117
|
+
## Step 4: Execute Chosen Strategy
|
|
118
|
+
|
|
119
|
+
### For Direct Update:
|
|
120
|
+
Proceed with straightforward documentation updates using the detected changes and auto-loaded foundational context. Continue with Step 5 (Final Decision Making).
|
|
121
|
+
|
|
122
|
+
### For Sub-Agent Approaches:
|
|
123
|
+
You have complete autonomy to design sub-agents based on the specific changes detected. Consider these investigation areas and design custom agents to cover what's most relevant:
|
|
124
|
+
|
|
125
|
+
**Core Investigation Areas to Consider:**
|
|
126
|
+
- **Change Impact Analysis**: Map file modifications to affected documentation across all tiers
|
|
127
|
+
- **Architecture Validation**: Verify existing architectural docs still reflect current implementation
|
|
128
|
+
- **Cross-Component Dependency Mapping**: Identify documentation updates needed due to integration changes
|
|
129
|
+
- **Documentation Accuracy Assessment**: Validate current docs against modified code patterns
|
|
130
|
+
- **Tier Cascade Requirements**: Determine which documentation levels need updates based on change scope
|
|
131
|
+
- **Technology Stack Verification**: Ensure tech stack changes are reflected across relevant documentation
|
|
132
|
+
|
|
133
|
+
**Autonomous Sub-Agent Design Principles:**
|
|
134
|
+
- **Custom Specialization**: Define agents based on the specific change complexity and documentation impact
|
|
135
|
+
- **Flexible Agent Count**: Use as many agents as needed - scale based on actual change scope
|
|
136
|
+
- **Adaptive Coverage**: Ensure all affected documentation areas are covered without unnecessary overlap
|
|
137
|
+
- **Update-Focused Analysis**: Prioritize investigation that directly supports accurate documentation updates
|
|
138
|
+
|
|
139
|
+
**Sub-Agent Task Template:**
|
|
140
|
+
```
|
|
141
|
+
Task: "Analyze [SPECIFIC_INVESTIGATION_AREA] for documentation updates based on changes from [SOURCE]: [DETECTED_CHANGES]"
|
|
142
|
+
|
|
143
|
+
Standard Investigation Workflow:
|
|
144
|
+
1. Review auto-loaded project context (CLAUDE.md, project-structure.md, docs-overview.md)
|
|
145
|
+
2. [CUSTOM_ANALYSIS_STEPS] - Investigate the specific area thoroughly
|
|
146
|
+
3. Return actionable findings that identify required documentation updates
|
|
147
|
+
|
|
148
|
+
Return comprehensive findings addressing this investigation area for documentation updates.
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
**CRITICAL: When using sub-agents, always launch them in parallel using a single message with multiple Task tool invocations.**
|
|
152
|
+
|
|
153
|
+
## Step 5: Synthesize Analysis and Plan Updates
|
|
154
|
+
|
|
155
|
+
### For Sub-Agent Approaches:
|
|
156
|
+
Think deeply about integrating findings from all sub-agent investigations for optimal documentation updates. Combine findings from all agents to create optimal documentation update strategy:
|
|
157
|
+
|
|
158
|
+
**Integration Analysis:**
|
|
159
|
+
- **Change Impact**: Use Change Impact Agent's mapping of modifications to documentation
|
|
160
|
+
- **Architecture Validation**: Apply Architecture Validation Agent's findings on outdated information
|
|
161
|
+
- **Dependency Updates**: Implement Cross-Component Agent's integration change requirements
|
|
162
|
+
- **Accuracy Corrections**: Address Documentation Accuracy Agent's identified inconsistencies
|
|
163
|
+
- **Cascade Planning**: Execute Tier Cascade Agent's multi-level update requirements
|
|
164
|
+
|
|
165
|
+
**Update Strategy Decision:**
|
|
166
|
+
Based on synthesized analysis, determine:
|
|
167
|
+
- **Documentation scope**: Which files need updates and at what detail level
|
|
168
|
+
- **Update priority**: Critical architectural changes vs. minor pattern updates
|
|
169
|
+
- **Cascade requirements**: Which tier levels need coordinated updates
|
|
170
|
+
- **New file creation**: Whether new documentation files are warranted
|
|
171
|
+
|
|
172
|
+
## Step 6: Final Decision Making
|
|
173
|
+
|
|
174
|
+
Based on your context analysis and the auto-loaded documentation structure (either direct or synthesized from sub-agents), decide:
|
|
175
|
+
- **Which documents need updates** (match changes to appropriate documentation)
|
|
176
|
+
- **What type of updates** (component changes, architecture decisions, new patterns, etc.)
|
|
177
|
+
- **Update scope** (major changes get more detail, minor changes get brief updates)
|
|
178
|
+
- **Whether new documentation files are needed** (see Smart File Creation guidelines below)
|
|
179
|
+
|
|
180
|
+
## Step 7: Smart File Creation (If Needed)
|
|
181
|
+
|
|
182
|
+
Before updating existing documentation, assess if new documentation files should be created based on the 3-tier system:
|
|
183
|
+
|
|
184
|
+
### Guidelines for Creating New Documentation Files
|
|
185
|
+
|
|
186
|
+
**Create new Component CONTEXT.md when:**
|
|
187
|
+
- You detect an entirely new top-level component (new directory under `agents/`, `unity-client/`, `supabase-functions/`, etc.)
|
|
188
|
+
- The component has significant functionality (5+ meaningful files)
|
|
189
|
+
- Example: Adding `agents/lesson-generator/` → Create `agents/lesson-generator/CONTEXT.md`
|
|
190
|
+
|
|
191
|
+
**Create new Feature-Specific CONTEXT.md when:**
|
|
192
|
+
- You detect a new complex subsystem within an existing component
|
|
193
|
+
- The subsystem has 3+ files and represents a distinct functional area
|
|
194
|
+
- No existing granular CONTEXT.md file covers this area
|
|
195
|
+
- Example: Adding `agents/tutor-server/src/features/translation/` with multiple files → Create `agents/tutor-server/src/features/CONTEXT.md`
|
|
196
|
+
|
|
197
|
+
**When NOT to create new files:**
|
|
198
|
+
- Small additions (1-2 files) that fit existing documentation scope
|
|
199
|
+
- Bug fixes or minor modifications
|
|
200
|
+
- Temporary or experimental code
|
|
201
|
+
|
|
202
|
+
**File Creation Process:**
|
|
203
|
+
1. **Create the new CONTEXT.md file** with placeholder content following the pattern of existing granular docs
|
|
204
|
+
2. **Update `/docs/ai-context/docs-overview.md`** to include the new file in the appropriate tier
|
|
205
|
+
3. **Document the addition** in the current update process
|
|
206
|
+
|
|
207
|
+
### File Content Template for New Granular CONTEXT.md:
|
|
208
|
+
```markdown
|
|
209
|
+
# [Feature Area] Documentation
|
|
210
|
+
|
|
211
|
+
*This file documents [specific area] patterns and implementations within [component].*
|
|
212
|
+
|
|
213
|
+
## [Area] Architecture
|
|
214
|
+
- [Key architectural elements]
|
|
215
|
+
|
|
216
|
+
## Implementation Patterns
|
|
217
|
+
- [Key patterns used]
|
|
218
|
+
|
|
219
|
+
## Integration Points
|
|
220
|
+
- [How this integrates with other parts]
|
|
221
|
+
|
|
222
|
+
---
|
|
223
|
+
|
|
224
|
+
*This file was created as part of the 3-tier documentation system to document [brief reason].*
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
## Step 8: Tier-First Documentation Updates
|
|
228
|
+
|
|
229
|
+
**CRITICAL: Always start with Tier 3 (feature-specific) documentation and work upward through the tiers. Never skip tiers.**
|
|
230
|
+
|
|
231
|
+
### Tier 3 (Feature-Specific) - START HERE
|
|
232
|
+
**Always begin with the most granular documentation closest to your changes:**
|
|
233
|
+
- **Identify affected Tier 3 files** (feature-specific CONTEXT.md files in subdirectories)
|
|
234
|
+
- **Update these granular files first** with specific implementation details, patterns, and integration points
|
|
235
|
+
- **Examples**: `agents/tutor-server/src/core/pipelines/CONTEXT.md`, `web-dashboard/src/lib/api/CONTEXT.md`, `agents/tutor-server/src/features/*/CONTEXT.md`
|
|
236
|
+
- **Update guidelines**: Be specific about file names, technologies, implementation patterns
|
|
237
|
+
|
|
238
|
+
### Tier 2 (Component-Level) - CASCADE UP
|
|
239
|
+
**After completing Tier 3 updates, evaluate if component-level changes are needed:**
|
|
240
|
+
- **Check parent component CONTEXT.md files** (e.g., `agents/tutor-server/CONTEXT.md` for changes in `agents/tutor-server/src/*/`)
|
|
241
|
+
- **Update if changes represent significant architectural shifts** affecting the overall component
|
|
242
|
+
- **Focus on**: How granular changes affect component architecture, new integration patterns, major feature additions
|
|
243
|
+
- **Examples**: `agents/tutor-server/CONTEXT.md`, `web-dashboard/CONTEXT.md`, `unity-client/CONTEXT.md`
|
|
244
|
+
|
|
245
|
+
### Tier 1 (Foundational) - CASCADE UP
|
|
246
|
+
**Finally, check if foundational documentation needs updates for system-wide impacts:**
|
|
247
|
+
|
|
248
|
+
#### Project Structure Updates (`/docs/ai-context/project-structure.md`)
|
|
249
|
+
Update for any of these changes:
|
|
250
|
+
- **File tree changes**: Created, moved, deleted files/directories; renamed components; restructured organization
|
|
251
|
+
- **Technology stack updates**: New dependencies (check pyproject.toml, package.json), major version updates, new frameworks, AI service changes, development tool modifications
|
|
252
|
+
|
|
253
|
+
#### Other Foundational Documentation
|
|
254
|
+
Update other `/docs/ai-context/` files if changes affect:
|
|
255
|
+
- **System-wide architectural patterns**
|
|
256
|
+
- **Cross-component integration approaches**
|
|
257
|
+
- **Development workflow or standards**
|
|
258
|
+
|
|
259
|
+
### Cascade Decision Logic
|
|
260
|
+
**What Constitutes "Significant Updates" Requiring Cascade:**
|
|
261
|
+
- **New major feature areas** (not just bug fixes or minor enhancements)
|
|
262
|
+
- **Architectural pattern changes** that affect how components integrate with others
|
|
263
|
+
- **New technologies or frameworks** introduced to a component
|
|
264
|
+
- **Major refactoring** that changes component structure or responsibilities
|
|
265
|
+
- **New integration points** between components or external systems
|
|
266
|
+
|
|
267
|
+
### Update Quality Guidelines (All Tiers)
|
|
268
|
+
- **Be concise** (max 3 sentences unless major architectural change)
|
|
269
|
+
- **Be specific** (include file names, technologies, key benefits)
|
|
270
|
+
- **Follow existing patterns** in each document
|
|
271
|
+
- **Avoid redundancy** (don't repeat what's already documented)
|
|
272
|
+
- **Co-locate knowledge** (keep documentation near relevant code)
|
|
273
|
+
|
|
274
|
+
## Step 9: Update Documentation Overview
|
|
275
|
+
|
|
276
|
+
**IMPORTANT:** After updating any documentation files in steps 1-8, check if the documentation overview needs updates:
|
|
277
|
+
- Reference the auto-loaded `/docs/ai-context/docs-overview.md`
|
|
278
|
+
- If you added new documentation files (especially new CONTEXT.md files), update the overview to include them in the appropriate tier
|
|
279
|
+
- If you significantly changed the structure/purpose of existing documentation, update the overview to reflect these changes
|
|
280
|
+
- Keep the overview accurate and current so it serves as a reliable guide to the documentation architecture
|
|
281
|
+
|
|
282
|
+
### Special Note for New CONTEXT.md Files:
|
|
283
|
+
When you create new granular CONTEXT.md files, you MUST add them to the appropriate section in docs-overview.md:
|
|
284
|
+
- **Tier 2 (Component-Level)**: For new top-level components
|
|
285
|
+
- **Tier 3 (Feature-Specific)**: For new subsystem documentation within existing components
|
|
286
|
+
|
|
287
|
+
## Quality Guidelines
|
|
288
|
+
|
|
289
|
+
- **Concise:** Keep updates brief and focused
|
|
290
|
+
- **Specific:** Include file names, technologies, key benefits
|
|
291
|
+
- **Accurate:** Based on actual changes made, not assumptions
|
|
292
|
+
- **Helpful:** Information that would be useful to another developer
|
|
293
|
+
- **Current:** Ensure file tree reflects actual project structure
|
|
294
|
+
- **Organized:** Follow the 3-tier documentation system principles
|
|
295
|
+
|
|
296
|
+
## When Not to Update or Create Documentation
|
|
297
|
+
|
|
298
|
+
Skip documentation updates/creation for:
|
|
299
|
+
- Bug fixes (unless they change architecture)
|
|
300
|
+
- Minor tweaks or cleanup
|
|
301
|
+
- Debugging or temporary changes
|
|
302
|
+
- Code formatting or comments
|
|
303
|
+
- Trivial modifications
|
|
304
|
+
- Single-file additions that fit existing documentation scope
|
|
305
|
+
|
|
306
|
+
## 3-Tier System Benefits
|
|
307
|
+
|
|
308
|
+
This enhanced approach leverages the 3-tier documentation system to:
|
|
309
|
+
- **Minimize cascade effects**: Most changes update 1-2 granular files
|
|
310
|
+
- **Scale intelligently**: New documentation created only when warranted
|
|
311
|
+
- **Co-locate knowledge**: Documentation lives near relevant code
|
|
312
|
+
- **Maintain consistency**: Clear guidelines for when and how to extend documentation
|
|
313
|
+
|
|
314
|
+
Now analyze the specified changes and update the relevant documentation accordingly.
|