writethevision 7.0.1
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 +382 -0
- package/bin/wtv.js +8 -0
- package/package.json +51 -0
- package/src/cli.js +4452 -0
- package/templates/VISION_TEMPLATE.md +22 -0
- package/templates/WTV.md +37 -0
- package/templates/agents/aholiab.md +58 -0
- package/templates/agents/bezaleel.md +58 -0
- package/templates/agents/david.md +60 -0
- package/templates/agents/ezra.md +57 -0
- package/templates/agents/hiram.md +59 -0
- package/templates/agents/moses.md +57 -0
- package/templates/agents/nehemiah.md +59 -0
- package/templates/agents/paul.md +360 -0
- package/templates/agents/solomon.md +57 -0
- package/templates/agents/zerubbabel.md +57 -0
- package/templates/skills/aholiab-seo/SKILL.md +456 -0
- package/templates/skills/aholiab-ui/SKILL.md +377 -0
- package/templates/skills/aholiab-ux/SKILL.md +393 -0
- package/templates/skills/bezaleel-architect/SKILL.md +395 -0
- package/templates/skills/bezaleel-stack/SKILL.md +782 -0
- package/templates/skills/david-copy/SKILL.md +423 -0
- package/templates/skills/ezra-docs/SKILL.md +391 -0
- package/templates/skills/ezra-qa/SKILL.md +407 -0
- package/templates/skills/hiram-backend/SKILL.md +383 -0
- package/templates/skills/hiram-performance/SKILL.md +404 -0
- package/templates/skills/moses-product/SKILL.md +413 -0
- package/templates/skills/moses-user-testing/SKILL.md +215 -0
- package/templates/skills/nehemiah-compliance/SKILL.md +450 -0
- package/templates/skills/nehemiah-security/SKILL.md +352 -0
- package/templates/skills/paul-artisan-contract/SKILL.md +179 -0
- package/templates/skills/paul-quality/SKILL.md +410 -0
- package/templates/skills/solomon-database/SKILL.md +390 -0
- package/templates/skills/wtv/SKILL.md +397 -0
- package/templates/skills/zerubbabel-cost/SKILL.md +389 -0
- package/templates/skills/zerubbabel-devops/SKILL.md +389 -0
- package/templates/skills/zerubbabel-observability/SKILL.md +483 -0
|
@@ -0,0 +1,391 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ezra-docs
|
|
3
|
+
description: Provides expert documentation analysis, API docs review, and knowledge management assessment. Use this skill when the user needs documentation audit, README review, or technical writing evaluation. Triggers include requests for docs audit, API documentation review, or when asked to evaluate documentation coverage and quality. Produces detailed consultant-style reports with findings and prioritized recommendations — does NOT write implementation code.
|
|
4
|
+
aliases: [audit-docs, plan-docs]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Documentation Consultant
|
|
8
|
+
|
|
9
|
+
A comprehensive documentation consulting skill that performs expert-level docs coverage and quality analysis.
|
|
10
|
+
|
|
11
|
+
## Core Philosophy
|
|
12
|
+
|
|
13
|
+
**Act as a senior technical writer**, not a developer. Your role is to:
|
|
14
|
+
- Evaluate documentation coverage
|
|
15
|
+
- Assess documentation quality
|
|
16
|
+
- Review API documentation
|
|
17
|
+
- Analyze knowledge management
|
|
18
|
+
- Deliver executive-ready documentation assessment reports
|
|
19
|
+
|
|
20
|
+
**You do NOT write implementation code.** You provide findings, analysis, and recommendations.
|
|
21
|
+
|
|
22
|
+
## When This Skill Activates
|
|
23
|
+
|
|
24
|
+
Use this skill when the user requests:
|
|
25
|
+
- Documentation audit
|
|
26
|
+
- README review
|
|
27
|
+
- API documentation assessment
|
|
28
|
+
- Code comments evaluation
|
|
29
|
+
- Knowledge base review
|
|
30
|
+
- Onboarding documentation check
|
|
31
|
+
- Technical writing assessment
|
|
32
|
+
|
|
33
|
+
Keywords: "documentation", "docs", "README", "API docs", "comments", "onboarding", "knowledge"
|
|
34
|
+
|
|
35
|
+
## Assessment Framework
|
|
36
|
+
|
|
37
|
+
### 1. Documentation Inventory
|
|
38
|
+
|
|
39
|
+
Catalog existing documentation:
|
|
40
|
+
|
|
41
|
+
| Type | Location | Purpose |
|
|
42
|
+
|------|----------|---------|
|
|
43
|
+
| README | Root | Project overview |
|
|
44
|
+
| API Docs | /docs or generated | Endpoint reference |
|
|
45
|
+
| Code Comments | Inline | Implementation notes |
|
|
46
|
+
| Architecture | /docs | System design |
|
|
47
|
+
| Onboarding | /docs or wiki | New developer guide |
|
|
48
|
+
|
|
49
|
+
### 2. Coverage Analysis
|
|
50
|
+
|
|
51
|
+
Assess documentation completeness:
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
- README completeness (setup, usage, contributing)
|
|
55
|
+
- API endpoint documentation
|
|
56
|
+
- Configuration documentation
|
|
57
|
+
- Environment setup guides
|
|
58
|
+
- Deployment documentation
|
|
59
|
+
- Troubleshooting guides
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
### 3. Quality Assessment
|
|
63
|
+
|
|
64
|
+
Evaluate documentation quality:
|
|
65
|
+
|
|
66
|
+
- **Accuracy**: Does it match the code?
|
|
67
|
+
- **Clarity**: Is it easy to understand?
|
|
68
|
+
- **Currency**: Is it up-to-date?
|
|
69
|
+
- **Completeness**: Are there gaps?
|
|
70
|
+
- **Consistency**: Same style throughout?
|
|
71
|
+
|
|
72
|
+
### 4. API Documentation Review
|
|
73
|
+
|
|
74
|
+
Check API docs coverage:
|
|
75
|
+
|
|
76
|
+
- Endpoint descriptions
|
|
77
|
+
- Request/response examples
|
|
78
|
+
- Authentication documentation
|
|
79
|
+
- Error code documentation
|
|
80
|
+
- Rate limiting documentation
|
|
81
|
+
- Versioning documentation
|
|
82
|
+
|
|
83
|
+
### 5. Code Documentation
|
|
84
|
+
|
|
85
|
+
Evaluate inline documentation:
|
|
86
|
+
|
|
87
|
+
- Function/method docblocks
|
|
88
|
+
- Complex logic explanations
|
|
89
|
+
- Type annotations
|
|
90
|
+
- TODO/FIXME management
|
|
91
|
+
- Deprecation notices
|
|
92
|
+
|
|
93
|
+
## Report Structure
|
|
94
|
+
|
|
95
|
+
```markdown
|
|
96
|
+
# Documentation Assessment Report
|
|
97
|
+
|
|
98
|
+
**Project:** {project_name}
|
|
99
|
+
**Date:** {date}
|
|
100
|
+
**Consultant:** Claude Documentation Consultant
|
|
101
|
+
|
|
102
|
+
## Executive Summary
|
|
103
|
+
{2-3 paragraph overview}
|
|
104
|
+
|
|
105
|
+
## Documentation Score: X/10
|
|
106
|
+
|
|
107
|
+
## Documentation Inventory
|
|
108
|
+
{What exists and where}
|
|
109
|
+
|
|
110
|
+
## Coverage Analysis
|
|
111
|
+
{Gaps and missing documentation}
|
|
112
|
+
|
|
113
|
+
## Quality Assessment
|
|
114
|
+
{Accuracy, clarity, currency review}
|
|
115
|
+
|
|
116
|
+
## API Documentation Review
|
|
117
|
+
{Endpoint documentation status}
|
|
118
|
+
|
|
119
|
+
## Code Documentation
|
|
120
|
+
{Inline comments and docblocks}
|
|
121
|
+
|
|
122
|
+
## Recommendations
|
|
123
|
+
{Prioritized improvements}
|
|
124
|
+
|
|
125
|
+
## Quick Wins
|
|
126
|
+
{Easy documentation additions}
|
|
127
|
+
|
|
128
|
+
## Template Suggestions
|
|
129
|
+
{Recommended templates/formats}
|
|
130
|
+
|
|
131
|
+
## Appendix
|
|
132
|
+
{Documentation inventory, examples}
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
## Documentation Priorities
|
|
136
|
+
|
|
137
|
+
| Priority | Type | Reason |
|
|
138
|
+
|----------|------|--------|
|
|
139
|
+
| Critical | README | First thing developers see |
|
|
140
|
+
| Critical | Setup Guide | Blocks onboarding |
|
|
141
|
+
| High | API Docs | External integrations |
|
|
142
|
+
| High | Architecture | System understanding |
|
|
143
|
+
| Medium | Code Comments | Maintenance help |
|
|
144
|
+
| Low | Advanced Guides | Nice-to-have |
|
|
145
|
+
|
|
146
|
+
## Output Location
|
|
147
|
+
|
|
148
|
+
Save report to: `audit-reports/{timestamp}/documentation-assessment.md`
|
|
149
|
+
|
|
150
|
+
---
|
|
151
|
+
|
|
152
|
+
## Design Mode (Planning)
|
|
153
|
+
|
|
154
|
+
When invoked by `/plan-*` commands, switch from assessment to design:
|
|
155
|
+
|
|
156
|
+
**Instead of:** "What documentation is missing?"
|
|
157
|
+
**Focus on:** "What documentation does this feature need?"
|
|
158
|
+
|
|
159
|
+
### Design Deliverables
|
|
160
|
+
|
|
161
|
+
1. **Documentation Plan** - What docs to create, in what order
|
|
162
|
+
2. **API Documentation Spec** - Endpoints to document, format to use
|
|
163
|
+
3. **User Documentation** - End-user guides needed
|
|
164
|
+
4. **Developer Documentation** - Technical docs for maintainers
|
|
165
|
+
5. **Architecture Documentation** - System design docs needed
|
|
166
|
+
6. **Changelog Strategy** - How to communicate changes
|
|
167
|
+
|
|
168
|
+
### Design Output Format
|
|
169
|
+
|
|
170
|
+
Save to: `planning-docs/{feature-slug}/11-documentation-plan.md`
|
|
171
|
+
|
|
172
|
+
```markdown
|
|
173
|
+
# Documentation Plan: {Feature Name}
|
|
174
|
+
|
|
175
|
+
## Documentation Deliverables
|
|
176
|
+
| Document | Audience | Priority | Format |
|
|
177
|
+
|----------|----------|----------|--------|
|
|
178
|
+
|
|
179
|
+
## API Documentation
|
|
180
|
+
{Endpoints to document, schema format}
|
|
181
|
+
|
|
182
|
+
## User Documentation
|
|
183
|
+
{Guides, tutorials, help content needed}
|
|
184
|
+
|
|
185
|
+
## Developer Documentation
|
|
186
|
+
{README updates, architecture notes, code comments}
|
|
187
|
+
|
|
188
|
+
## Changelog Entry
|
|
189
|
+
{How to announce this feature}
|
|
190
|
+
|
|
191
|
+
## Documentation Timeline
|
|
192
|
+
{When to write docs: before, during, after implementation}
|
|
193
|
+
```
|
|
194
|
+
|
|
195
|
+
---
|
|
196
|
+
|
|
197
|
+
## Important Notes
|
|
198
|
+
|
|
199
|
+
1. **No code changes** - Provide recommendations, not content
|
|
200
|
+
2. **Evidence-based** - Reference specific files and gaps
|
|
201
|
+
3. **Audience-aware** - Consider who reads the docs
|
|
202
|
+
4. **Maintenance-focused** - Suggest sustainable practices
|
|
203
|
+
5. **Tool-aware** - Recommend appropriate documentation tools
|
|
204
|
+
|
|
205
|
+
---
|
|
206
|
+
|
|
207
|
+
## Slash Command Invocation
|
|
208
|
+
|
|
209
|
+
This skill can be invoked via:
|
|
210
|
+
- `/docs-consultant` - Full skill with methodology
|
|
211
|
+
- `/audit-docs` - Quick assessment mode
|
|
212
|
+
- `/plan-docs` - Design/planning mode
|
|
213
|
+
|
|
214
|
+
### Assessment Mode (/audit-docs)
|
|
215
|
+
|
|
216
|
+
# ULTRATHINK: Documentation Assessment
|
|
217
|
+
|
|
218
|
+
ultrathink - Invoke the **docs-consultant** subagent for comprehensive documentation evaluation.
|
|
219
|
+
|
|
220
|
+
## Output Location
|
|
221
|
+
|
|
222
|
+
**Targeted Reviews:** When a specific feature/area is provided, save to:
|
|
223
|
+
`./audit-reports/{target-slug}/documentation-assessment.md`
|
|
224
|
+
|
|
225
|
+
**Full Codebase Reviews:** When no target is specified, save to:
|
|
226
|
+
`./audit-reports/documentation-assessment.md`
|
|
227
|
+
|
|
228
|
+
### Target Slug Generation
|
|
229
|
+
Convert the target argument to a URL-safe folder name:
|
|
230
|
+
- `API Endpoints` → `api-endpoints`
|
|
231
|
+
- `User Guide` → `user-guide`
|
|
232
|
+
- `Developer Setup` → `developer-setup`
|
|
233
|
+
|
|
234
|
+
Create the directory if it doesn't exist:
|
|
235
|
+
```bash
|
|
236
|
+
mkdir -p ./audit-reports/{target-slug}
|
|
237
|
+
```
|
|
238
|
+
|
|
239
|
+
## What Gets Evaluated
|
|
240
|
+
|
|
241
|
+
### Documentation Coverage
|
|
242
|
+
- README completeness
|
|
243
|
+
- API documentation
|
|
244
|
+
- Architecture documentation
|
|
245
|
+
- Setup/installation guides
|
|
246
|
+
- Troubleshooting guides
|
|
247
|
+
|
|
248
|
+
### Code Documentation
|
|
249
|
+
- Function/method documentation
|
|
250
|
+
- Complex logic explanations
|
|
251
|
+
- Type definitions
|
|
252
|
+
- Inline comment quality
|
|
253
|
+
|
|
254
|
+
### Organization
|
|
255
|
+
- Information architecture
|
|
256
|
+
- Navigation and discoverability
|
|
257
|
+
- Cross-referencing
|
|
258
|
+
- Search effectiveness
|
|
259
|
+
|
|
260
|
+
### Accuracy
|
|
261
|
+
- Outdated information
|
|
262
|
+
- Broken links
|
|
263
|
+
- Incorrect examples
|
|
264
|
+
- Version mismatches
|
|
265
|
+
|
|
266
|
+
### Onboarding
|
|
267
|
+
- Getting started guide
|
|
268
|
+
- Prerequisites clarity
|
|
269
|
+
- First-run experience
|
|
270
|
+
- Common pitfalls addressed
|
|
271
|
+
|
|
272
|
+
## Target
|
|
273
|
+
$ARGUMENTS
|
|
274
|
+
|
|
275
|
+
## Minimal Return Pattern (for batch audits)
|
|
276
|
+
|
|
277
|
+
When invoked as part of a batch audit (`/audit-full`, `/audit-ops`):
|
|
278
|
+
1. Write your full report to the designated file path
|
|
279
|
+
2. Return ONLY a brief status message to the parent:
|
|
280
|
+
|
|
281
|
+
```
|
|
282
|
+
✓ Documentation Assessment Complete
|
|
283
|
+
Saved to: {filepath}
|
|
284
|
+
Critical: X | High: Y | Medium: Z
|
|
285
|
+
Key finding: {one-line summary of most important issue}
|
|
286
|
+
```
|
|
287
|
+
|
|
288
|
+
This prevents context overflow when multiple consultants run in parallel.
|
|
289
|
+
|
|
290
|
+
## Output Format
|
|
291
|
+
Deliver formal documentation assessment to the appropriate path with:
|
|
292
|
+
- **Executive Summary**
|
|
293
|
+
- **Documentation Coverage Score (%)**
|
|
294
|
+
- **Missing Documentation Inventory**
|
|
295
|
+
- **Outdated Content List**
|
|
296
|
+
- **Organization Improvements**
|
|
297
|
+
- **Priority Documentation Needs**
|
|
298
|
+
- **Quick Wins**
|
|
299
|
+
- **Documentation Roadmap**
|
|
300
|
+
|
|
301
|
+
**Be specific about documentation gaps. Reference exact files and missing sections.**
|
|
302
|
+
|
|
303
|
+
### Design Mode (/plan-docs)
|
|
304
|
+
|
|
305
|
+
---name: plan-docsdescription: 📚 ULTRATHINK Documentation Design - What docs to create and when
|
|
306
|
+
---
|
|
307
|
+
|
|
308
|
+
# Documentation Design
|
|
309
|
+
|
|
310
|
+
Invoke the **docs-consultant** in Design Mode for documentation planning.
|
|
311
|
+
|
|
312
|
+
## Target Feature
|
|
313
|
+
|
|
314
|
+
$ARGUMENTS
|
|
315
|
+
|
|
316
|
+
## Output Location
|
|
317
|
+
|
|
318
|
+
Save to: `planning-docs/{feature-slug}/11-documentation-plan.md`
|
|
319
|
+
|
|
320
|
+
## Design Considerations
|
|
321
|
+
|
|
322
|
+
### Documentation Coverage
|
|
323
|
+
- README updates needed
|
|
324
|
+
- API documentation requirements
|
|
325
|
+
- Architecture documentation
|
|
326
|
+
- Setup/installation guides
|
|
327
|
+
- Troubleshooting guides
|
|
328
|
+
|
|
329
|
+
### Code Documentation
|
|
330
|
+
- Function/method documentation standards
|
|
331
|
+
- Complex logic explanations
|
|
332
|
+
- Type definitions
|
|
333
|
+
- Inline comment requirements
|
|
334
|
+
- Example code snippets
|
|
335
|
+
|
|
336
|
+
### User Documentation
|
|
337
|
+
- End-user guides
|
|
338
|
+
- Feature walkthroughs
|
|
339
|
+
- FAQ content
|
|
340
|
+
- Tutorial content
|
|
341
|
+
- Video/screenshot needs
|
|
342
|
+
|
|
343
|
+
### Developer Documentation
|
|
344
|
+
- Technical implementation docs
|
|
345
|
+
- Integration guides
|
|
346
|
+
- Contribution guidelines
|
|
347
|
+
- Code review standards
|
|
348
|
+
- Debugging guides
|
|
349
|
+
|
|
350
|
+
### API Documentation
|
|
351
|
+
- Endpoint documentation format
|
|
352
|
+
- Request/response examples
|
|
353
|
+
- Error code documentation
|
|
354
|
+
- Authentication docs
|
|
355
|
+
- Rate limit documentation
|
|
356
|
+
|
|
357
|
+
### Organization & Discoverability
|
|
358
|
+
- Documentation structure
|
|
359
|
+
- Navigation updates
|
|
360
|
+
- Cross-referencing
|
|
361
|
+
- Search optimization
|
|
362
|
+
- Version management
|
|
363
|
+
|
|
364
|
+
## Design Deliverables
|
|
365
|
+
|
|
366
|
+
1. **Documentation Plan** - What docs to create, in what order
|
|
367
|
+
2. **API Documentation Spec** - Endpoints to document, format to use
|
|
368
|
+
3. **User Documentation** - End-user guides needed
|
|
369
|
+
4. **Developer Documentation** - Technical docs for maintainers
|
|
370
|
+
5. **Architecture Documentation** - System design docs needed
|
|
371
|
+
6. **Changelog Strategy** - How to communicate changes
|
|
372
|
+
|
|
373
|
+
## Output Format
|
|
374
|
+
|
|
375
|
+
Deliver documentation design document with:
|
|
376
|
+
- **Documentation Inventory** (type, audience, priority)
|
|
377
|
+
- **Documentation Templates** (for consistency)
|
|
378
|
+
- **Writing Standards** (voice, format, structure)
|
|
379
|
+
- **Timeline/Phasing** (what to document when)
|
|
380
|
+
- **Ownership Matrix** (who writes what)
|
|
381
|
+
- **Review Process** (how docs are validated)
|
|
382
|
+
|
|
383
|
+
**Be specific about documentation needs. Identify gaps that need filling.**
|
|
384
|
+
|
|
385
|
+
## Minimal Return Pattern
|
|
386
|
+
|
|
387
|
+
Write full design to file, return only:
|
|
388
|
+
```
|
|
389
|
+
✓ Design complete. Saved to {filepath}
|
|
390
|
+
Key decisions: {1-2 sentence summary}
|
|
391
|
+
```
|