bmad-method 4.16.0 → 4.17.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/CHANGELOG.md +14 -0
- package/package.json +1 -1
- package/tools/installer/lib/ide-setup.js +3 -0
- package/tools/installer/package.json +1 -1
- package/.bmad-core/agent-teams/team-all.yml +0 -14
- package/.bmad-core/agent-teams/team-fullstack.yml +0 -18
- package/.bmad-core/agent-teams/team-ide-minimal.yml +0 -10
- package/.bmad-core/agent-teams/team-no-ui.yml +0 -13
- package/.bmad-core/agents/analyst.md +0 -64
- package/.bmad-core/agents/architect.md +0 -64
- package/.bmad-core/agents/bmad-master.md +0 -101
- package/.bmad-core/agents/bmad-orchestrator.md +0 -126
- package/.bmad-core/agents/dev.md +0 -65
- package/.bmad-core/agents/pm.md +0 -61
- package/.bmad-core/agents/po.md +0 -63
- package/.bmad-core/agents/qa.md +0 -50
- package/.bmad-core/agents/sm.md +0 -51
- package/.bmad-core/agents/ux-expert.md +0 -63
- package/.bmad-core/checklists/architect-checklist.md +0 -443
- package/.bmad-core/checklists/change-checklist.md +0 -182
- package/.bmad-core/checklists/pm-checklist.md +0 -375
- package/.bmad-core/checklists/po-master-checklist.md +0 -441
- package/.bmad-core/checklists/story-dod-checklist.md +0 -101
- package/.bmad-core/checklists/story-draft-checklist.md +0 -156
- package/.bmad-core/core-config.yml +0 -20
- package/.bmad-core/data/bmad-kb.md +0 -814
- package/.bmad-core/data/technical-preferences.md +0 -3
- package/.bmad-core/install-manifest.yml +0 -196
- package/.bmad-core/tasks/advanced-elicitation.md +0 -92
- package/.bmad-core/tasks/brainstorming-techniques.md +0 -238
- package/.bmad-core/tasks/brownfield-create-epic.md +0 -160
- package/.bmad-core/tasks/brownfield-create-story.md +0 -147
- package/.bmad-core/tasks/core-dump.md +0 -74
- package/.bmad-core/tasks/correct-course.md +0 -73
- package/.bmad-core/tasks/create-deep-research-prompt.md +0 -301
- package/.bmad-core/tasks/create-doc.md +0 -74
- package/.bmad-core/tasks/create-next-story.md +0 -242
- package/.bmad-core/tasks/doc-migration-task.md +0 -151
- package/.bmad-core/tasks/document-project.md +0 -350
- package/.bmad-core/tasks/execute-checklist.md +0 -97
- package/.bmad-core/tasks/generate-ai-frontend-prompt.md +0 -51
- package/.bmad-core/tasks/index-docs.md +0 -178
- package/.bmad-core/tasks/kb-mode-interaction.md +0 -77
- package/.bmad-core/tasks/review-story.md +0 -153
- package/.bmad-core/tasks/shard-doc.md +0 -191
- package/.bmad-core/templates/architecture-tmpl.md +0 -776
- package/.bmad-core/templates/brownfield-architecture-tmpl.md +0 -544
- package/.bmad-core/templates/brownfield-prd-tmpl.md +0 -242
- package/.bmad-core/templates/competitor-analysis-tmpl.md +0 -291
- package/.bmad-core/templates/front-end-architecture-tmpl.md +0 -175
- package/.bmad-core/templates/front-end-spec-tmpl.md +0 -413
- package/.bmad-core/templates/fullstack-architecture-tmpl.md +0 -1018
- package/.bmad-core/templates/market-research-tmpl.md +0 -263
- package/.bmad-core/templates/prd-tmpl.md +0 -202
- package/.bmad-core/templates/project-brief-tmpl.md +0 -230
- package/.bmad-core/templates/story-tmpl.md +0 -69
- package/.bmad-core/utils/file-resolution-context.md +0 -10
- package/.bmad-core/utils/template-format.md +0 -26
- package/.bmad-core/utils/web-agent-startup-instructions.md +0 -39
- package/.bmad-core/utils/workflow-management.md +0 -223
- package/.bmad-core/workflows/brownfield-fullstack.yml +0 -112
- package/.bmad-core/workflows/brownfield-service.yml +0 -113
- package/.bmad-core/workflows/brownfield-ui.yml +0 -123
- package/.bmad-core/workflows/greenfield-fullstack.yml +0 -166
- package/.bmad-core/workflows/greenfield-service.yml +0 -132
- package/.bmad-core/workflows/greenfield-ui.yml +0 -161
|
@@ -1,77 +0,0 @@
|
|
|
1
|
-
# KB Mode Interaction Task
|
|
2
|
-
|
|
3
|
-
## Purpose
|
|
4
|
-
|
|
5
|
-
Provide a user-friendly interface to the BMAD knowledge base without overwhelming users with information upfront.
|
|
6
|
-
|
|
7
|
-
## Instructions
|
|
8
|
-
|
|
9
|
-
When entering KB mode (\*kb-mode), follow these steps:
|
|
10
|
-
|
|
11
|
-
### 1. Welcome and Guide
|
|
12
|
-
|
|
13
|
-
Announce entering KB mode with a brief, friendly introduction:
|
|
14
|
-
|
|
15
|
-
"I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD."
|
|
16
|
-
|
|
17
|
-
### 2. Present Topic Areas
|
|
18
|
-
|
|
19
|
-
Offer a concise list of main topic areas the user might want to explore:
|
|
20
|
-
|
|
21
|
-
**What would you like to know more about?**
|
|
22
|
-
|
|
23
|
-
1. **Setup & Installation** - Getting started with BMAD
|
|
24
|
-
2. **Workflows** - Choosing the right workflow for your project
|
|
25
|
-
3. **Web vs IDE** - When to use each environment
|
|
26
|
-
4. **Agents** - Understanding specialized agents and their roles
|
|
27
|
-
5. **Documents** - PRDs, Architecture, Stories, and more
|
|
28
|
-
6. **Agile Process** - How BMAD implements Agile methodologies
|
|
29
|
-
7. **Configuration** - Customizing BMAD for your needs
|
|
30
|
-
8. **Best Practices** - Tips for effective BMAD usage
|
|
31
|
-
|
|
32
|
-
Or ask me about anything else related to BMAD-METHOD!
|
|
33
|
-
|
|
34
|
-
### 3. Respond Contextually
|
|
35
|
-
|
|
36
|
-
- Wait for user's specific question or topic selection
|
|
37
|
-
- Provide focused, relevant information from the knowledge base
|
|
38
|
-
- Offer to dive deeper or explore related topics
|
|
39
|
-
- Keep responses concise unless user asks for detailed explanations
|
|
40
|
-
|
|
41
|
-
### 4. Interactive Exploration
|
|
42
|
-
|
|
43
|
-
- After answering, suggest related topics they might find helpful
|
|
44
|
-
- Maintain conversational flow rather than data dumping
|
|
45
|
-
- Use examples when appropriate
|
|
46
|
-
- Reference specific documentation sections when relevant
|
|
47
|
-
|
|
48
|
-
### 5. Exit Gracefully
|
|
49
|
-
|
|
50
|
-
When user is done or wants to exit KB mode:
|
|
51
|
-
|
|
52
|
-
- Summarize key points discussed if helpful
|
|
53
|
-
- Remind them they can return to KB mode anytime with \*kb-mode
|
|
54
|
-
- Suggest next steps based on what was discussed
|
|
55
|
-
|
|
56
|
-
## Example Interaction
|
|
57
|
-
|
|
58
|
-
**User**: \*kb-mode
|
|
59
|
-
|
|
60
|
-
**Assistant**: I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD.
|
|
61
|
-
|
|
62
|
-
**What would you like to know more about?**
|
|
63
|
-
|
|
64
|
-
1. **Setup & Installation** - Getting started with BMAD
|
|
65
|
-
2. **Workflows** - Choosing the right workflow for your project
|
|
66
|
-
3. **Web vs IDE** - When to use each environment
|
|
67
|
-
4. **Agents** - Understanding specialized agents and their roles
|
|
68
|
-
5. **Documents** - PRDs, Architecture, Stories, and more
|
|
69
|
-
6. **Agile Process** - How BMAD implements Agile methodologies
|
|
70
|
-
7. **Configuration** - Customizing BMAD for your needs
|
|
71
|
-
8. **Best Practices** - Tips for effective BMAD usage
|
|
72
|
-
|
|
73
|
-
Or ask me about anything else related to BMAD-METHOD!
|
|
74
|
-
|
|
75
|
-
**User**: Tell me about workflows
|
|
76
|
-
|
|
77
|
-
**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]
|
|
@@ -1,153 +0,0 @@
|
|
|
1
|
-
# review-story
|
|
2
|
-
|
|
3
|
-
When a developer marks a story as "Ready for Review", perform a comprehensive senior developer code review with the ability to refactor and improve code directly.
|
|
4
|
-
|
|
5
|
-
[[LLM: QA Agent executing review-story task as Senior Developer]]
|
|
6
|
-
|
|
7
|
-
## Prerequisites
|
|
8
|
-
|
|
9
|
-
- Story status must be "Review"
|
|
10
|
-
- Developer has completed all tasks and updated the File List
|
|
11
|
-
- All automated tests are passing
|
|
12
|
-
|
|
13
|
-
## Review Process
|
|
14
|
-
|
|
15
|
-
1. **Read the Complete Story**
|
|
16
|
-
|
|
17
|
-
- Review all acceptance criteria
|
|
18
|
-
- Understand the dev notes and requirements
|
|
19
|
-
- Note any completion notes from the developer
|
|
20
|
-
|
|
21
|
-
2. **Focus on the File List**
|
|
22
|
-
|
|
23
|
-
- Verify all files listed were actually created/modified
|
|
24
|
-
- Check for any missing files that should have been updated
|
|
25
|
-
|
|
26
|
-
3. **Senior Developer Code Review**
|
|
27
|
-
|
|
28
|
-
- Review code with the eye of a senior developer
|
|
29
|
-
- If changes form a cohesive whole, review them together
|
|
30
|
-
- If changes are independent, review incrementally file by file
|
|
31
|
-
- Focus on:
|
|
32
|
-
- Code architecture and design patterns
|
|
33
|
-
- Refactoring opportunities
|
|
34
|
-
- Code duplication or inefficiencies
|
|
35
|
-
- Performance optimizations
|
|
36
|
-
- Security concerns
|
|
37
|
-
- Best practices and patterns
|
|
38
|
-
|
|
39
|
-
4. **Active Refactoring**
|
|
40
|
-
|
|
41
|
-
- As a senior developer, you CAN and SHOULD refactor code where improvements are needed
|
|
42
|
-
- When refactoring:
|
|
43
|
-
- Make the changes directly in the files
|
|
44
|
-
- Explain WHY you're making the change
|
|
45
|
-
- Describe HOW the change improves the code
|
|
46
|
-
- Ensure all tests still pass after refactoring
|
|
47
|
-
- Update the File List if you modify additional files
|
|
48
|
-
|
|
49
|
-
5. **Standards Compliance Check**
|
|
50
|
-
|
|
51
|
-
- Verify adherence to `docs/coding-standards.md`
|
|
52
|
-
- Check compliance with `docs/unified-project-structure.md`
|
|
53
|
-
- Validate testing approach against `docs/testing-strategy.md`
|
|
54
|
-
- Ensure all guidelines mentioned in the story are followed
|
|
55
|
-
|
|
56
|
-
6. **Acceptance Criteria Validation**
|
|
57
|
-
|
|
58
|
-
- Verify each AC is fully implemented
|
|
59
|
-
- Check for any missing functionality
|
|
60
|
-
- Validate edge cases are handled
|
|
61
|
-
|
|
62
|
-
7. **Test Coverage Review**
|
|
63
|
-
|
|
64
|
-
- Ensure unit tests cover edge cases
|
|
65
|
-
- Add missing tests if critical coverage is lacking
|
|
66
|
-
- Verify integration tests (if required) are comprehensive
|
|
67
|
-
- Check that test assertions are meaningful
|
|
68
|
-
- Look for missing test scenarios
|
|
69
|
-
|
|
70
|
-
8. **Documentation and Comments**
|
|
71
|
-
- Verify code is self-documenting where possible
|
|
72
|
-
- Add comments for complex logic if missing
|
|
73
|
-
- Ensure any API changes are documented
|
|
74
|
-
|
|
75
|
-
## Append Results to Story File
|
|
76
|
-
|
|
77
|
-
After review and any refactoring, append your results to the story file in the QA Results section:
|
|
78
|
-
|
|
79
|
-
```markdown
|
|
80
|
-
## QA Results
|
|
81
|
-
|
|
82
|
-
### Review Date: [Date]
|
|
83
|
-
|
|
84
|
-
### Reviewed By: Quinn (Senior Developer QA)
|
|
85
|
-
|
|
86
|
-
### Code Quality Assessment
|
|
87
|
-
|
|
88
|
-
[Overall assessment of implementation quality]
|
|
89
|
-
|
|
90
|
-
### Refactoring Performed
|
|
91
|
-
|
|
92
|
-
[List any refactoring you performed with explanations]
|
|
93
|
-
|
|
94
|
-
- **File**: [filename]
|
|
95
|
-
- **Change**: [what was changed]
|
|
96
|
-
- **Why**: [reason for change]
|
|
97
|
-
- **How**: [how it improves the code]
|
|
98
|
-
|
|
99
|
-
### Compliance Check
|
|
100
|
-
|
|
101
|
-
- Coding Standards: [✓/✗] [notes if any]
|
|
102
|
-
- Project Structure: [✓/✗] [notes if any]
|
|
103
|
-
- Testing Strategy: [✓/✗] [notes if any]
|
|
104
|
-
- All ACs Met: [✓/✗] [notes if any]
|
|
105
|
-
|
|
106
|
-
### Improvements Checklist
|
|
107
|
-
|
|
108
|
-
[Check off items you handled yourself, leave unchecked for dev to address]
|
|
109
|
-
|
|
110
|
-
- [x] Refactored user service for better error handling (services/user.service.ts)
|
|
111
|
-
- [x] Added missing edge case tests (services/user.service.test.ts)
|
|
112
|
-
- [ ] Consider extracting validation logic to separate validator class
|
|
113
|
-
- [ ] Add integration test for error scenarios
|
|
114
|
-
- [ ] Update API documentation for new error codes
|
|
115
|
-
|
|
116
|
-
### Security Review
|
|
117
|
-
|
|
118
|
-
[Any security concerns found and whether addressed]
|
|
119
|
-
|
|
120
|
-
### Performance Considerations
|
|
121
|
-
|
|
122
|
-
[Any performance issues found and whether addressed]
|
|
123
|
-
|
|
124
|
-
### Final Status
|
|
125
|
-
|
|
126
|
-
[✓ Approved - Ready for Done] / [✗ Changes Required - See unchecked items above]
|
|
127
|
-
```
|
|
128
|
-
|
|
129
|
-
## Key Principles
|
|
130
|
-
|
|
131
|
-
- You are a SENIOR developer reviewing junior/mid-level work
|
|
132
|
-
- You have the authority and responsibility to improve code directly
|
|
133
|
-
- Always explain your changes for learning purposes
|
|
134
|
-
- Balance between perfection and pragmatism
|
|
135
|
-
- Focus on significant improvements, not nitpicks
|
|
136
|
-
|
|
137
|
-
## Blocking Conditions
|
|
138
|
-
|
|
139
|
-
Stop the review and request clarification if:
|
|
140
|
-
|
|
141
|
-
- Story file is incomplete or missing critical sections
|
|
142
|
-
- File List is empty or clearly incomplete
|
|
143
|
-
- No tests exist when they were required
|
|
144
|
-
- Code changes don't align with story requirements
|
|
145
|
-
- Critical architectural issues that require discussion
|
|
146
|
-
|
|
147
|
-
## Completion
|
|
148
|
-
|
|
149
|
-
After review:
|
|
150
|
-
|
|
151
|
-
1. If all items are checked and approved: Update story status to "Done"
|
|
152
|
-
2. If unchecked items remain: Keep status as "Review" for dev to address
|
|
153
|
-
3. Always provide constructive feedback and explanations for learning
|
|
@@ -1,191 +0,0 @@
|
|
|
1
|
-
# Document Sharding Task
|
|
2
|
-
|
|
3
|
-
## Purpose
|
|
4
|
-
|
|
5
|
-
- Split a large document into multiple smaller documents based on level 2 sections
|
|
6
|
-
- Create a folder structure to organize the sharded documents
|
|
7
|
-
- Maintain all content integrity including code blocks, diagrams, and markdown formatting
|
|
8
|
-
|
|
9
|
-
## Primary Method: Automatic with markdown-tree
|
|
10
|
-
|
|
11
|
-
[[LLM: First, check if markdownExploder is set to true in bmad-core/core-config.yml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
|
|
12
|
-
|
|
13
|
-
If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
|
|
14
|
-
|
|
15
|
-
If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
|
|
16
|
-
|
|
17
|
-
1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
|
|
18
|
-
2. Or set markdownExploder to false in bmad-core/core-config.yml
|
|
19
|
-
|
|
20
|
-
**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
|
|
21
|
-
|
|
22
|
-
If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
|
|
23
|
-
|
|
24
|
-
1. Set markdownExploder to true in bmad-core/core-config.yml
|
|
25
|
-
2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
|
|
26
|
-
|
|
27
|
-
I will now proceed with the manual sharding process."
|
|
28
|
-
|
|
29
|
-
Then proceed with the manual method below ONLY if markdownExploder is false.]]
|
|
30
|
-
|
|
31
|
-
### Installation and Usage
|
|
32
|
-
|
|
33
|
-
1. **Install globally**:
|
|
34
|
-
|
|
35
|
-
```bash
|
|
36
|
-
npm install -g @kayvan/markdown-tree-parser
|
|
37
|
-
```
|
|
38
|
-
|
|
39
|
-
2. **Use the explode command**:
|
|
40
|
-
|
|
41
|
-
```bash
|
|
42
|
-
# For PRD
|
|
43
|
-
md-tree explode docs/prd.md docs/prd
|
|
44
|
-
|
|
45
|
-
# For Architecture
|
|
46
|
-
md-tree explode docs/architecture.md docs/architecture
|
|
47
|
-
|
|
48
|
-
# For any document
|
|
49
|
-
md-tree explode [source-document] [destination-folder]
|
|
50
|
-
```
|
|
51
|
-
|
|
52
|
-
3. **What it does**:
|
|
53
|
-
- Automatically splits the document by level 2 sections
|
|
54
|
-
- Creates properly named files
|
|
55
|
-
- Adjusts heading levels appropriately
|
|
56
|
-
- Handles all edge cases with code blocks and special markdown
|
|
57
|
-
|
|
58
|
-
If the user has @kayvan/markdown-tree-parser installed, use it and skip the manual process below.
|
|
59
|
-
|
|
60
|
-
---
|
|
61
|
-
|
|
62
|
-
## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
|
|
63
|
-
|
|
64
|
-
[[LLM: Only proceed with the manual instructions below if the user cannot or does not want to use @kayvan/markdown-tree-parser.]]
|
|
65
|
-
|
|
66
|
-
### Task Instructions
|
|
67
|
-
|
|
68
|
-
1. Identify Document and Target Location
|
|
69
|
-
|
|
70
|
-
- Determine which document to shard (user-provided path)
|
|
71
|
-
- Create a new folder under `docs/` with the same name as the document (without extension)
|
|
72
|
-
- Example: `docs/prd.md` → create folder `docs/prd/`
|
|
73
|
-
|
|
74
|
-
2. Parse and Extract Sections
|
|
75
|
-
|
|
76
|
-
[[LLM: When sharding the document:
|
|
77
|
-
|
|
78
|
-
1. Read the entire document content
|
|
79
|
-
2. Identify all level 2 sections (## headings)
|
|
80
|
-
3. For each level 2 section:
|
|
81
|
-
- Extract the section heading and ALL content until the next level 2 section
|
|
82
|
-
- Include all subsections, code blocks, diagrams, lists, tables, etc.
|
|
83
|
-
- Be extremely careful with:
|
|
84
|
-
- Fenced code blocks (```) - ensure you capture the full block including closing backticks and account for potential misleading level 2's that are actually part of a fenced section example
|
|
85
|
-
- Mermaid diagrams - preserve the complete diagram syntax
|
|
86
|
-
- Nested markdown elements
|
|
87
|
-
- Multi-line content that might contain ## inside code blocks
|
|
88
|
-
|
|
89
|
-
CRITICAL: Use proper parsing that understands markdown context. A ## inside a code block is NOT a section header.]]
|
|
90
|
-
|
|
91
|
-
### 3. Create Individual Files
|
|
92
|
-
|
|
93
|
-
For each extracted section:
|
|
94
|
-
|
|
95
|
-
1. **Generate filename**: Convert the section heading to lowercase-dash-case
|
|
96
|
-
|
|
97
|
-
- Remove special characters
|
|
98
|
-
- Replace spaces with dashes
|
|
99
|
-
- Example: "## Tech Stack" → `tech-stack.md`
|
|
100
|
-
|
|
101
|
-
2. **Adjust heading levels**:
|
|
102
|
-
|
|
103
|
-
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
|
|
104
|
-
- All subsection levels decrease by 1:
|
|
105
|
-
|
|
106
|
-
```txt
|
|
107
|
-
- ### → ##
|
|
108
|
-
- #### → ###
|
|
109
|
-
- ##### → ####
|
|
110
|
-
- etc.
|
|
111
|
-
```
|
|
112
|
-
|
|
113
|
-
3. **Write content**: Save the adjusted content to the new file
|
|
114
|
-
|
|
115
|
-
### 4. Create Index File
|
|
116
|
-
|
|
117
|
-
Create an `index.md` file in the sharded folder that:
|
|
118
|
-
|
|
119
|
-
1. Contains the original level 1 heading and any content before the first level 2 section
|
|
120
|
-
2. Lists all the sharded files with links:
|
|
121
|
-
|
|
122
|
-
```markdown
|
|
123
|
-
# Original Document Title
|
|
124
|
-
|
|
125
|
-
[Original introduction content if any]
|
|
126
|
-
|
|
127
|
-
## Sections
|
|
128
|
-
|
|
129
|
-
- [Section Name 1](./section-name-1.md)
|
|
130
|
-
- [Section Name 2](./section-name-2.md)
|
|
131
|
-
- [Section Name 3](./section-name-3.md)
|
|
132
|
-
...
|
|
133
|
-
```
|
|
134
|
-
|
|
135
|
-
### 5. Preserve Special Content
|
|
136
|
-
|
|
137
|
-
[[LLM: Pay special attention to preserving:
|
|
138
|
-
|
|
139
|
-
1. **Code blocks**: Must capture complete blocks including:
|
|
140
|
-
|
|
141
|
-
```language
|
|
142
|
-
content
|
|
143
|
-
```
|
|
144
|
-
|
|
145
|
-
2. **Mermaid diagrams**: Preserve complete syntax:
|
|
146
|
-
|
|
147
|
-
```mermaid
|
|
148
|
-
graph TD
|
|
149
|
-
...
|
|
150
|
-
```
|
|
151
|
-
|
|
152
|
-
3. **Tables**: Maintain proper markdown table formatting
|
|
153
|
-
|
|
154
|
-
4. **Lists**: Preserve indentation and nesting
|
|
155
|
-
|
|
156
|
-
5. **Inline code**: Preserve backticks
|
|
157
|
-
|
|
158
|
-
6. **Links and references**: Keep all markdown links intact
|
|
159
|
-
|
|
160
|
-
7. **Template markup**: If documents contain {{placeholders}} or [[LLM instructions]], preserve exactly]]
|
|
161
|
-
|
|
162
|
-
### 6. Validation
|
|
163
|
-
|
|
164
|
-
After sharding:
|
|
165
|
-
|
|
166
|
-
1. Verify all sections were extracted
|
|
167
|
-
2. Check that no content was lost
|
|
168
|
-
3. Ensure heading levels were properly adjusted
|
|
169
|
-
4. Confirm all files were created successfully
|
|
170
|
-
|
|
171
|
-
### 7. Report Results
|
|
172
|
-
|
|
173
|
-
Provide a summary:
|
|
174
|
-
|
|
175
|
-
```text
|
|
176
|
-
Document sharded successfully:
|
|
177
|
-
- Source: [original document path]
|
|
178
|
-
- Destination: docs/[folder-name]/
|
|
179
|
-
- Files created: [count]
|
|
180
|
-
- Sections:
|
|
181
|
-
- section-name-1.md: "Section Title 1"
|
|
182
|
-
- section-name-2.md: "Section Title 2"
|
|
183
|
-
...
|
|
184
|
-
```
|
|
185
|
-
|
|
186
|
-
## Important Notes
|
|
187
|
-
|
|
188
|
-
- Never modify the actual content, only adjust heading levels
|
|
189
|
-
- Preserve ALL formatting, including whitespace where significant
|
|
190
|
-
- Handle edge cases like sections with code blocks containing ## symbols
|
|
191
|
-
- Ensure the sharding is reversible (could reconstruct the original from shards)
|