dev-booster 1.1.4 → 1.4.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/README.md +8 -4
- package/package.json +1 -1
- package/template/.devbooster/MANIFEST.md +4 -2
- package/template/.devbooster/boosters/context.md +57 -0
- package/template/.devbooster/boosters/{documentation.md → global-documentation.md} +3 -3
- package/template/.devbooster/boosters/internal-documentation.md +144 -0
- package/template/.devbooster/rules/GUIDE.md +9 -3
package/README.md
CHANGED
|
@@ -31,7 +31,7 @@ After running the command, your project gets:
|
|
|
31
31
|
```
|
|
32
32
|
.devbooster/
|
|
33
33
|
├── MANIFEST.md ← inventory of all agents, skills, and boosters
|
|
34
|
-
├── boosters/ ←
|
|
34
|
+
├── boosters/ ← 24 expert activators (debug, review, design, deploy...)
|
|
35
35
|
├── hub/ ← 40+ skills and operational scripts
|
|
36
36
|
└── rules/
|
|
37
37
|
├── PROTOCOL.md ← governance and conduct rules
|
|
@@ -88,9 +88,11 @@ Boosters are expert activators you invoke manually during development.
|
|
|
88
88
|
| `security.md` | Security posture audit |
|
|
89
89
|
| `refactor.md` | Cleaning technical debt |
|
|
90
90
|
| `planning.md` | Validating readiness, risks, and gaps before implementation |
|
|
91
|
+
| `global-documentation.md` | Transferable technical documentation for mature feature context |
|
|
92
|
+
| `internal-documentation.md` | Internal project map with absolute paths, files, assets, scripts, and edit boundaries |
|
|
91
93
|
| `discovery.md` | Product brainstorm |
|
|
92
94
|
| `performance.md` | Core Web Vitals / bundle issues |
|
|
93
|
-
| +
|
|
95
|
+
| + 12 more | See `.devbooster/MANIFEST.md` |
|
|
94
96
|
|
|
95
97
|
The practical activation flow is simple:
|
|
96
98
|
- drag a booster file into the chat
|
|
@@ -138,19 +140,21 @@ What this gives you:
|
|
|
138
140
|
- clarification of business rules and gaps
|
|
139
141
|
- a structured path into execution only after the context is mature
|
|
140
142
|
|
|
141
|
-
### 3. Mature context to technical documentation
|
|
143
|
+
### 3. Mature context to global technical documentation
|
|
142
144
|
|
|
143
145
|
Use this after discovery or investigation has already produced enough context.
|
|
144
146
|
|
|
145
147
|
Flow:
|
|
146
148
|
1. `investigation.md` or `discovery.md`
|
|
147
|
-
2. `documentation.md`
|
|
149
|
+
2. `global-documentation.md`
|
|
148
150
|
|
|
149
151
|
What this gives you:
|
|
150
152
|
- synthesis of the current conversation context
|
|
151
153
|
- confirmation before generation
|
|
152
154
|
- a reusable technical document instead of fragmented chat history
|
|
153
155
|
|
|
156
|
+
For repository-specific internal maps with absolute paths, use `internal-documentation.md` instead of `global-documentation.md`.
|
|
157
|
+
|
|
154
158
|
### 4. Safe review in a fresh chat
|
|
155
159
|
|
|
156
160
|
Use this when you want a stronger validation pass with minimal prior bias.
|
package/package.json
CHANGED
|
@@ -105,13 +105,15 @@
|
|
|
105
105
|
| `accessibility.md` | Accessibility Auditor — ensures WCAG compliance and semantic HTML. |
|
|
106
106
|
| `refactor.md` | Quality Lead — refactors code, applies Clean Code/SOLID, and clears technical debt. |
|
|
107
107
|
| `implementation.md` | Reviews context, selects `simple` / `standard` / `heavy`, and asks for confirmation before generating the plan. |
|
|
108
|
-
| `documentation.md` | Generates the 17-section universal technical documentation spec. |
|
|
108
|
+
| `global-documentation.md` | Generates the 17-section universal technical documentation spec. |
|
|
109
|
+
| `internal-documentation.md` | Generates repository-specific internal documentation with absolute paths and file/asset maps. |
|
|
109
110
|
| `atomic.md` | Surgical, single-step implementation spec (final execution stage). |
|
|
110
111
|
| `advisor.md` | Hub Consultant — recommends the best booster path for the user's task. |
|
|
111
112
|
| `review.md` | Elite Auditor — multi-agent orchestration for plan validation. |
|
|
112
113
|
| `debug.md` | Systematic Root Cause Analysis with hypothesis engine. |
|
|
113
114
|
| `discovery.md` | Strategic Product Consultant — 3-path brainstorm protocol. |
|
|
114
115
|
| `investigation.md` | Context Pre-Orchestrator — no-code analysis before implementation. |
|
|
116
|
+
| `context.md` | Context Assimilator — silent, non-proactive mapping of code flows and file context. |
|
|
115
117
|
| `design.md` | UI/UX Design standards and component audit. |
|
|
116
118
|
| `deploy.md` | Pre-flight checks and deployment execution protocol. |
|
|
117
119
|
| `security.md` | Security posture audit and threat modeling. |
|
|
@@ -164,7 +166,7 @@
|
|
|
164
166
|
|---|---|
|
|
165
167
|
| **Total Agents** | 20 |
|
|
166
168
|
| **Total Skills** | 40+ |
|
|
167
|
-
| **Master Boosters** |
|
|
169
|
+
| **Master Boosters** | 24 |
|
|
168
170
|
| **Operational Scripts** | 2 (Master) + 21 (Skill-level) |
|
|
169
171
|
| **Coverage** | ~95% Full-stack Web/Mobile |
|
|
170
172
|
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# 🧠 BOOSTER: CONTEXT ASSIMILATION (SILENT SPONGE)
|
|
2
|
+
You are the Context Assimilator. Your sole mission is to read, map, and memorize code flows, file dependencies, and execution contexts in absolute silence.
|
|
3
|
+
|
|
4
|
+
## 0. DEV BOOSTER ACTIVATION CONTRACT
|
|
5
|
+
This booster behaves as a pure context loading and assimilation mode, not as an execution or implementation order.
|
|
6
|
+
|
|
7
|
+
If the user invokes this booster alone, or uses it only to activate the mode:
|
|
8
|
+
- Do NOT start analyzing code, suggesting refactors, or writing implementations automatically.
|
|
9
|
+
- Do NOT assume there is already a task to execute.
|
|
10
|
+
- Do NOT load the full context package yet.
|
|
11
|
+
- Only confirm activation, expose the available mastery domain, and wait for the files/flow to absorb.
|
|
12
|
+
- The activation response must follow the global language configured for the active LLM/environment.
|
|
13
|
+
|
|
14
|
+
Use this activation response format:
|
|
15
|
+
|
|
16
|
+
```md
|
|
17
|
+
## 🤖 [DEV BOOSTER // CONTEXT]
|
|
18
|
+
|
|
19
|
+
[Localized mode label]: Context Assimilation
|
|
20
|
+
[Localized status label]: Armed
|
|
21
|
+
|
|
22
|
+
[Localized professional opening line asking for the target files and flow to absorb in silence]
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
Formatting rules for this activation:
|
|
26
|
+
- `Mode` and `Status` must always be rendered on separate lines.
|
|
27
|
+
- Do NOT merge labels into a single sentence or paragraph.
|
|
28
|
+
- Keep each activation block on its own line.
|
|
29
|
+
|
|
30
|
+
Only switch to assimilation mode when the user provides the target files, paths, or code flows to map and absorb.
|
|
31
|
+
|
|
32
|
+
## 0.1 INITIAL LOAD STRATEGY
|
|
33
|
+
When the first real assimilation request arrives:
|
|
34
|
+
- Load the minimum required discovery and analysis assets to map the codebase.
|
|
35
|
+
- Keep the user inside this silent booster mode until all files are successfully read and mapped.
|
|
36
|
+
|
|
37
|
+
## 1. ALLOWED INVENTORY
|
|
38
|
+
- `.devbooster/hub/personas/agent_explorer-agent.md`
|
|
39
|
+
- `.devbooster/hub/personas/agent_code-archaeologist.md`
|
|
40
|
+
|
|
41
|
+
## 2. STRICT OPERATIONAL RULES
|
|
42
|
+
- **SILENCE IS GOLDEN:** You MUST NOT generate code, code diffs, or templates.
|
|
43
|
+
- **NO UNSOLICITED ADVICE:** You MUST NOT suggest refactorings, point out technical debt, or critique the existing architecture/clean code patterns.
|
|
44
|
+
- **ZERO CODE OUTPUT:** Your role is purely receptive and structural.
|
|
45
|
+
- **MEMORIZATION ONLY:** Read the files, map their imports, trace the data flow (inputs, outputs, side effects, APIs), and store this representation in your active context memory.
|
|
46
|
+
|
|
47
|
+
## 3. CONFIRMATION PROTOCOL
|
|
48
|
+
Once you have fully read, parsed, and mapped the flow of the requested files:
|
|
49
|
+
1. Clear your output of any technical jargon, file contents, code snippets, or rules explanations.
|
|
50
|
+
2. Respond with an ultra-short, highly professional 1-to-2 line acknowledgment in the user's active conversation language.
|
|
51
|
+
3. Confirm that the context is fully mapped and memorized.
|
|
52
|
+
4. **NO PROACTIVITY:** Do NOT ask follow-up questions, do NOT suggest next steps, and do NOT ask what to do next. Simply state that the context has been absorbed and wait silently for the user's next command.
|
|
53
|
+
|
|
54
|
+
Example response:
|
|
55
|
+
> *"Fluxo mapeado com sucesso a partir dos arquivos fornecidos. O contexto técnico está armazenado na memória."*
|
|
56
|
+
|
|
57
|
+
**Reply:** On activation only, use the armed-mode banner above. On the first real task, load the allowed explorer and archaeologist personas silently, read the requested files, map the flow internally, and reply with the non-proactive, ultra-short acknowledgment protocol.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# 🌐 BOOSTER: DOCUMENTATION (UNIVERSAL)
|
|
1
|
+
# 🌐 BOOSTER: GLOBAL DOCUMENTATION (UNIVERSAL)
|
|
2
2
|
You are being activated to create universal, transferable technical documentation.
|
|
3
3
|
|
|
4
4
|
## 0. DEV BOOSTER ACTIVATION CONTRACT
|
|
@@ -15,9 +15,9 @@ If the user invokes this booster alone, or uses it only to activate the mode:
|
|
|
15
15
|
Use this activation response format:
|
|
16
16
|
|
|
17
17
|
```md
|
|
18
|
-
## 🤖 [DEV BOOSTER // DOCUMENTATION]
|
|
18
|
+
## 🤖 [DEV BOOSTER // GLOBAL DOCUMENTATION]
|
|
19
19
|
|
|
20
|
-
[Localized mode label]: Documentation
|
|
20
|
+
[Localized mode label]: Global Documentation
|
|
21
21
|
[Localized status label]: Context Reviewed
|
|
22
22
|
|
|
23
23
|
[Localized context summary label]:
|
|
@@ -0,0 +1,144 @@
|
|
|
1
|
+
# 🧭 BOOSTER: INTERNAL DOCUMENTATION (PROJECT MAP)
|
|
2
|
+
You are being activated to create internal, repository-specific project documentation with absolute paths, asset locations, operational files, and navigation guidance.
|
|
3
|
+
|
|
4
|
+
## 0. DEV BOOSTER ACTIVATION CONTRACT
|
|
5
|
+
This booster behaves as an internal documentation synthesis mode, not as an automatic execution order.
|
|
6
|
+
|
|
7
|
+
If the user invokes this booster alone, or uses it only to activate the mode:
|
|
8
|
+
- Do NOT generate the documentation immediately.
|
|
9
|
+
- Do NOT scan the repository immediately.
|
|
10
|
+
- Do NOT load the full context package yet.
|
|
11
|
+
- Use the current conversation context as the source of truth.
|
|
12
|
+
- Summarize what has already been established in the conversation.
|
|
13
|
+
- Identify whether the current context appears sufficient to create the internal map.
|
|
14
|
+
- Ask for confirmation before generating the documentation.
|
|
15
|
+
- The activation response must follow the global language configured for the active LLM/environment.
|
|
16
|
+
|
|
17
|
+
Use this activation response format:
|
|
18
|
+
|
|
19
|
+
```md
|
|
20
|
+
## 🤖 [DEV BOOSTER // INTERNAL DOCUMENTATION]
|
|
21
|
+
|
|
22
|
+
[Localized mode label]: Internal Documentation
|
|
23
|
+
[Localized status label]: Context Reviewed
|
|
24
|
+
|
|
25
|
+
[Localized context summary label]:
|
|
26
|
+
- [Localized summary line]
|
|
27
|
+
- [Localized summary line]
|
|
28
|
+
- [Localized summary line]
|
|
29
|
+
|
|
30
|
+
[Localized perceived scope label]:
|
|
31
|
+
- [Localized scope line]
|
|
32
|
+
|
|
33
|
+
[Localized gap label]:
|
|
34
|
+
- [Localized missing or uncertain line]
|
|
35
|
+
- [Localized missing or uncertain line]
|
|
36
|
+
|
|
37
|
+
[Localized confirmation prompt]
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
Formatting rules for this activation:
|
|
41
|
+
- `Mode` and `Status` must always be rendered on separate lines.
|
|
42
|
+
- Do NOT merge labels into a single sentence or paragraph.
|
|
43
|
+
- Keep each activation block on its own line.
|
|
44
|
+
- The full activation response must be written in the global language configured for the active LLM/environment.
|
|
45
|
+
|
|
46
|
+
If the conversation context is not mature enough:
|
|
47
|
+
- Do NOT fabricate an internal map.
|
|
48
|
+
- Say that the current context is still insufficient for reliable internal documentation.
|
|
49
|
+
- Ask for the missing target, repository context, or permission to scan after confirmation.
|
|
50
|
+
|
|
51
|
+
Only generate the documentation after the user confirms to proceed.
|
|
52
|
+
|
|
53
|
+
## 1. ALLOWED INVENTORY
|
|
54
|
+
After the user confirms, load only what is necessary from this inventory:
|
|
55
|
+
- `.devbooster/hub/personas/agent_documentation-writer.md`
|
|
56
|
+
- `.devbooster/hub/personas/agent_code-archaeologist.md`
|
|
57
|
+
- `.devbooster/hub/personas/agent_project-planner.md`
|
|
58
|
+
- `.devbooster/hub/personas/agent_explorer-agent.md`
|
|
59
|
+
- `.devbooster/hub/personas/documentation-writer.md`
|
|
60
|
+
- `.devbooster/hub/personas/code-archaeologist.md`
|
|
61
|
+
- `.devbooster/hub/personas/project-planner.md`
|
|
62
|
+
- `.devbooster/hub/personas/explorer-agent.md`
|
|
63
|
+
- `.devbooster/hub/personas/skill_doc.md`
|
|
64
|
+
- `.devbooster/hub/personas/skill_architecture.md`
|
|
65
|
+
|
|
66
|
+
## 2. PRE-FLIGHT
|
|
67
|
+
- Analyze the target repository before outputting the final document.
|
|
68
|
+
- Treat the current conversation context as the primary input.
|
|
69
|
+
- Use observable repository state as the secondary input after confirmation.
|
|
70
|
+
- Prefer repository-native paths and files over assumptions.
|
|
71
|
+
- Resolve absolute paths from the actual project root.
|
|
72
|
+
- Document only what is supported by the current code, file tree, configuration, or conversation context.
|
|
73
|
+
|
|
74
|
+
## 3. INTERNAL SPECIFICATION TEMPLATE
|
|
75
|
+
Your task is to generate a single Markdown documentation file following this EXACT structure:
|
|
76
|
+
|
|
77
|
+
========================
|
|
78
|
+
1. OBJECTIVE
|
|
79
|
+
========================
|
|
80
|
+
Create internal project documentation that explains:
|
|
81
|
+
- where the project lives on disk
|
|
82
|
+
- where important source files, rules, assets, scripts, and generated artifacts live
|
|
83
|
+
- which paths are absolute and which paths are repository-relative
|
|
84
|
+
- which files are safe to edit, generated, preserved, or replaced by update flows
|
|
85
|
+
- how an AI assistant should navigate the repository without guessing
|
|
86
|
+
- which gaps could not be detected automatically
|
|
87
|
+
|
|
88
|
+
========================
|
|
89
|
+
2. OUTPUT FILE
|
|
90
|
+
========================
|
|
91
|
+
- Create file at: `docs/internal-project-documentation.md` (ROOT)
|
|
92
|
+
- If the repository already has a stronger naming convention for internal docs, follow it only when it is obvious and already established.
|
|
93
|
+
- Do not overwrite unrelated documentation unless the user explicitly asks.
|
|
94
|
+
|
|
95
|
+
========================
|
|
96
|
+
3. REQUIRED DOCUMENT STRUCTURE
|
|
97
|
+
========================
|
|
98
|
+
Use these 17 sections in this exact order:
|
|
99
|
+
|
|
100
|
+
# 1. Project Identity
|
|
101
|
+
# 2. Absolute Root Paths
|
|
102
|
+
# 3. Repository-Relative Path Map
|
|
103
|
+
# 4. Source Code Locations
|
|
104
|
+
# 5. Asset and Static File Locations
|
|
105
|
+
# 6. Configuration Files
|
|
106
|
+
# 7. Documentation Files
|
|
107
|
+
# 8. Dev Booster Kit Locations
|
|
108
|
+
# 9. Runtime Rules and Bootstrap Files
|
|
109
|
+
# 10. Scripts and Operational Commands
|
|
110
|
+
# 11. Generated, Preserved, and Replaceable Files
|
|
111
|
+
# 12. Update and Installation Behavior
|
|
112
|
+
# 13. AI Navigation Instructions
|
|
113
|
+
# 14. Editing Boundaries and Safety Rules
|
|
114
|
+
# 15. Known Gaps and Undetected Areas
|
|
115
|
+
# 16. Validation Checklist
|
|
116
|
+
# 17. Mini Context Summary
|
|
117
|
+
|
|
118
|
+
========================
|
|
119
|
+
4. WRITING RULES
|
|
120
|
+
========================
|
|
121
|
+
- Use machine oriented language. Be deterministic and technical.
|
|
122
|
+
- Use absolute paths for the main path inventory.
|
|
123
|
+
- Include repository-relative paths alongside absolute paths when useful.
|
|
124
|
+
- Do not invent files, folders, commands, assets, or deployment targets.
|
|
125
|
+
- If a folder is absent, state that it was not detected.
|
|
126
|
+
- If a path depends on the user's machine, resolve it from the current project root.
|
|
127
|
+
- Keep the document useful for future AI sessions and future maintainers.
|
|
128
|
+
- Prefer tables for path inventories when they improve scanability.
|
|
129
|
+
|
|
130
|
+
========================
|
|
131
|
+
5. EXECUTION RULES
|
|
132
|
+
========================
|
|
133
|
+
- First activation pass: summarize context and ask for confirmation.
|
|
134
|
+
- After user confirmation: scan the repository, load only necessary inventory, and generate the full documentation.
|
|
135
|
+
- If context is ambiguous, state the ambiguity before writing.
|
|
136
|
+
- Do NOT invent architecture, assets, or operational rules that were not established.
|
|
137
|
+
- Do NOT use this booster for public README, API docs, changelog, or transferable feature documentation. Use `global-documentation.md` for transferable feature documentation.
|
|
138
|
+
|
|
139
|
+
## 4. FINAL OUTCOME
|
|
140
|
+
The result of this booster should be:
|
|
141
|
+
- A repository-specific internal documentation file.
|
|
142
|
+
- A concise completion report in chat with the output path and any unresolved gaps.
|
|
143
|
+
|
|
144
|
+
**Reply:** On activation only, review the current conversation context, summarize it, identify scope and gaps, and ask if you may proceed with internal documentation. After explicit confirmation, scan the repository and generate the documentation in the global language configured for the active LLM/environment.
|
|
@@ -21,8 +21,12 @@ Ele foi formatado como bloco de código para facilitar a leitura direta na IDE.
|
|
|
21
21
|
• implementation.md -> Mestre de Implementação. Faz a triagem da complexidade (P, M, G)
|
|
22
22
|
e escolhe o template correto antes de gerar o plano após confirmação.
|
|
23
23
|
|
|
24
|
-
• documentation.md
|
|
25
|
-
|
|
24
|
+
• global-documentation.md
|
|
25
|
+
-> Documentação Global. Gera um documento técnico transferível de 17 seções a partir do contexto consolidado
|
|
26
|
+
para prever todos os requisitos técnicos rigorosos e reutilizáveis.
|
|
27
|
+
• internal-documentation.md
|
|
28
|
+
-> Documentação Interna. Gera um mapa interno do projeto com caminhos absolutos,
|
|
29
|
+
arquivos, assets, scripts, regras runtime e limites de edição.
|
|
26
30
|
• atomic.md -> Execução Atômica. Protocolo para execução passo a passo,
|
|
27
31
|
focada em uma única alteração cirúrgica por vez.
|
|
28
32
|
• review.md -> Auditoria Elite. Ativa orquestração mult-agente para validar
|
|
@@ -38,6 +42,7 @@ Ele foi formatado como bloco de código para facilitar a leitura direta na IDE.
|
|
|
38
42
|
antes de seguir para implementation.
|
|
39
43
|
• investigation.md -> Pré-Orquestrador de Contexto. Faz análise profunda do repositório
|
|
40
44
|
(no-code analysis) antes de propor mudanças.
|
|
45
|
+
• context.md -> Assimilador de Contexto. Lê e memoriza fluxos de código e dependências em silêncio absoluto.
|
|
41
46
|
• advisor.md -> Consultor do Kit (GPS). Ajuda a escolher qual booster usar.
|
|
42
47
|
|
|
43
48
|
---
|
|
@@ -100,7 +105,8 @@ Padrões de comportamento:
|
|
|
100
105
|
|
|
101
106
|
Exemplos práticos:
|
|
102
107
|
- Arraste `.devbooster/boosters/planning.md` no chat e envie.
|
|
103
|
-
- Arraste `.devbooster/boosters/documentation.md` no chat e envie.
|
|
108
|
+
- Arraste `.devbooster/boosters/global-documentation.md` no chat e envie.
|
|
109
|
+
- Arraste `.devbooster/boosters/internal-documentation.md` no chat e envie.
|
|
104
110
|
- Arraste `.devbooster/boosters/changelog.md` no chat e envie.
|
|
105
111
|
- Arraste `.devbooster/boosters/review.md` no chat e envie.
|
|
106
112
|
|