@zenuml/core 3.32.6 → 3.32.7

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.
Files changed (35) hide show
  1. package/.claude/commands/README.md +162 -0
  2. package/.claude/commands/code-review.md +322 -0
  3. package/.claude/commands/create-docs.md +309 -0
  4. package/.claude/commands/full-context.md +121 -0
  5. package/.claude/commands/gemini-consult.md +164 -0
  6. package/.claude/commands/handoff.md +146 -0
  7. package/.claude/commands/refactor.md +188 -0
  8. package/.claude/commands/update-docs.md +314 -0
  9. package/.claude/hooks/README.md +270 -0
  10. package/.claude/hooks/config/sensitive-patterns.json +86 -0
  11. package/.claude/hooks/gemini-context-injector.sh +129 -0
  12. package/.claude/hooks/mcp-security-scan.sh +147 -0
  13. package/.claude/hooks/notify.sh +103 -0
  14. package/.claude/hooks/setup/hook-setup.md +96 -0
  15. package/.claude/hooks/setup/settings.json.template +63 -0
  16. package/.claude/hooks/sounds/complete.wav +0 -0
  17. package/.claude/hooks/sounds/input-needed.wav +0 -0
  18. package/.claude/hooks/subagent-context-injector.sh +65 -0
  19. package/.storybook/main.ts +25 -0
  20. package/.storybook/preview.ts +29 -0
  21. package/MCP-ASSISTANT-RULES.md +85 -0
  22. package/dist/zenuml.esm.mjs +3037 -2994
  23. package/dist/zenuml.js +40 -40
  24. package/docs/CONTEXT-tier2-component.md +96 -0
  25. package/docs/CONTEXT-tier3-feature.md +162 -0
  26. package/docs/README.md +207 -0
  27. package/docs/ai-context/deployment-infrastructure.md +21 -0
  28. package/docs/ai-context/docs-overview.md +89 -0
  29. package/docs/ai-context/handoff.md +174 -0
  30. package/docs/ai-context/project-structure.md +160 -0
  31. package/docs/ai-context/system-integration.md +21 -0
  32. package/docs/open-issues/example-api-performance-issue.md +79 -0
  33. package/eslint.config.mjs +26 -26
  34. package/package.json +9 -2
  35. package/tailwind.config.js +0 -4
@@ -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.