[]
Brief one-line description of what the project does.
<features>
- Feature 1
- Feature 2
- Feature 3
</features>
<quick_start>
```bash
npm install package-name
```
</quick_start>
<basic_usage>
```typescript
import { example } from "package-name";
const result = example();
console.log(result);
```
</basic_usage>
<documentation>
See [full documentation](link) for detailed guides.
</documentation>
<contributing>
Contributions welcome! See [CONTRIBUTING.md](link).
</contributing>
<license>
MIT
</license>
</example>
<authentication>
All requests require an API key in the Authorization header:
```bash
Authorization: Bearer YOUR_API_KEY
```
</authentication>
<base_url>
```
https://api.example.com/v1
```
</base_url>
<endpoints>
<get_users>
Retrieve a list of users.
**Parameters:**
- `limit` (integer, optional): Number of results (default: 10)
- `offset` (integer, optional): Pagination offset (default: 0)
**Response:**
```json
{
"users": [
{ "id": 1, "name": "John Doe" },
{ "id": 2, "name": "Jane Smith" }
],
"total": 100
}
```
**Error Codes:**
- `401`: Unauthorized - Invalid API key
- `429`: Rate limit exceeded
</get_users>
</endpoints>
</example>
<summary>
**Problem:** Brief description of the problem being solved
**Solution:** High-level approach
**Scope:** What's included and what's not
</summary>
<background>
Context and motivation for this design.
</background>
<goals_and_non_goals>
**Goals:**
- Goal 1
- Goal 2
**Non-Goals:**
- What we're explicitly not doing
- Future considerations
</goals_and_non_goals>
<technical_design>
<architecture>
[Diagram or description of system architecture]
</architecture>
<data_flow>
1. User action
2. System processing
3. Response
</data_flow>
<components>
**Component A:** Responsible for X
**Component B:** Responsible for Y
</components>
</technical_design>
<alternatives_considered>
<alternative_1>
Pros: ...
Cons: ...
Decision: Not chosen because...
</alternative_1>
</alternatives_considered>
<security_considerations>
- Data encryption at rest and in transit
- Authentication and authorization
- Input validation
</security_considerations>
<testing_strategy>
- Unit tests for component logic
- Integration tests for API contracts
- E2E tests for critical user flows
</testing_strategy>
<rollout_plan>
1. Phase 1: Internal testing
2. Phase 2: Beta release (10% of users)
3. Phase 3: Full rollout
</rollout_plan>
</example>
<getting_started>
Welcome! This guide will help you get started with [Product Name].
</getting_started>
<core_concepts>
**Workspace:** A container for your projects
**Project:** A collection of related items
**Item:** The basic unit of work
</core_concepts>
<creating_your_first_project>
1. Click the "New Project" button
2. Enter a project name
3. Choose a template (optional)
4. Click "Create"
You'll see your new project in the sidebar.
</creating_your_first_project>
<troubleshooting>
<troubleshooting_login>
1. Check your email address is correct
2. Click "Forgot Password" to reset
3. Contact support if the issue persists
</troubleshooting_login>
<troubleshooting_data>
Ensure you have a stable internet connection. The app auto-saves every 30 seconds.
</troubleshooting_data>
</troubleshooting>
<glossary>
**Term:** Definition
**Another Term:** Another definition
</glossary>
</example>
<bad_example>Bad</bad_example>
The server can be started by running the following command.
</example>
<bad_example>Bad</bad_example>
サーバーの起動については、下記コマンドを実行することで可能となります。
</example>
<structure>
[Proposed sections based on document type]
</structure>
<content>
[Actual documentation content]
</content>
<review_checklist>
- [ ] Technical accuracy verified
- [ ] Code examples tested
- [ ] Links working
- [ ] Appropriate for audience
- [ ] Grammar and spelling checked
</review_checklist>
1---2name: technical-documentation3description: This skill should be used when the user asks to "write documentation", "create README", "API docs", "design document", "specification", "user guide", or needs documentation guidance. Provides comprehensive documentation patterns for developers, teams, and end-users in both English and Japanese.4---5
6<purpose>
7 Provide structured patterns for creating technical documentation including README, design documents, API specifications, and user guides for diverse audiences.
8</purpose>
9
10<tools>
11 <tool>Write - Create new documentation files</tool>
12 <tool>Edit - Update existing documentation</tool>
13 <tool>Read - Review existing documentation and code</tool>
14 <tool>Grep - Search for patterns across documentation</tool>
15 <tool>Glob - Find related documentation files</tool>
16</tools>
17
18<concepts>
19 <concept name="document_types">Four primary types: README (project intro), API spec (endpoints/interfaces), design doc (architecture decisions), user guide (end-user tutorials)</concept>
20 <concept name="audience_levels">Developer (technical depth), team member (context + depth), end user (no jargon, step-by-step)</concept>
21 <concept name="progressive_disclosure">Start with quick start, then common cases, then advanced config, finally edge cases</concept>
22 <concept name="documentation_lifecycle">Plan (outline) → Draft (write + examples) → Review (verify accuracy) → Maintain (update with code)</concept>
23</concepts>
24
25<patterns>
26 <pattern name="readme_document_type">
27 <description>Project introduction and quick start guide</description>
28 <decision_tree name="when_to_use">
29 <question>Is this the main entry point for project documentation?</question>
30 <if_yes>Create README with quick start and overview</if_yes>
31 <if_no>Consider using design doc for detailed architecture or user guide for end-user documentation</if_no>
32 </decision_tree>
33 <context>
34 <audience>Developers, contributors, users</audience>
35 <when_to_use>Creating or updating main project documentation</when_to_use>
36 </context>
37 <structure>
38 <section>Project title and badges</section>
39 <section>One-line description</section>
40 <section>Key features (3-5 bullet points)</section>
41 <section>Quick start / Installation</section>
42 <section>Basic usage example</section>
43 <section>Documentation links</section>
44 <section>Contributing / License</section>
45 </structure>
46 </pattern>
47
48 <pattern name="api_specification_document_type">
49 <description>API reference documentation</description>
50 <decision_tree name="when_to_use">
51 <question>Are you documenting API endpoints or SDK interfaces?</question>
52 <if_yes>Create API specification with authentication, endpoints, and examples</if_yes>
53 <if_no>Use README for library usage or design doc for internal architecture</if_no>
54 </decision_tree>
55 <context>
56 <audience>Developers integrating with the API</audience>
57 <when_to_use>Documenting REST APIs, GraphQL schemas, or SDK interfaces</when_to_use>
58 </context>
59 <structure>
60 <section>Overview and authentication</section>
61 <section>Base URL and versioning</section>
62 <section>Endpoints (method, path, parameters, response)</section>
63 <section>Error codes and handling</section>
64 <section>Rate limits</section>
65 <section>Examples (curl, language-specific)</section>
66 </structure>
67 </pattern>
68
69 <pattern name="design_document_type">
70 <description>Technical design and architecture documentation</description>
71 <decision_tree name="when_to_use">
72 <question>Are you proposing a major feature or architectural change?</question>
73 <if_yes>Create design document with technical details, alternatives, and rollout plan</if_yes>
74 <if_no>Use inline code comments for small changes or README for usage instructions</if_no>
75 </decision_tree>
76 <context>
77 <audience>Team members, reviewers, future maintainers</audience>
78 <when_to_use>Proposing new features, architectural changes, or major refactors</when_to_use>
79 </context>
80 <structure>
81 <section>Summary (problem, solution, scope)</section>
82 <section>Background and motivation</section>
83 <section>Goals and non-goals</section>
84 <section>Technical design (architecture, data flow)</section>
85 <section>Alternatives considered</section>
86 <section>Security / Privacy considerations</section>
87 <section>Testing strategy</section>
88 <section>Rollout plan</section>
89 </structure>
90 </pattern>
91
92 <pattern name="user_guide_document_type">
93 <description>End-user facing documentation</description>
94 <decision_tree name="when_to_use">
95 <question>Is your audience non-technical end users?</question>
96 <if_yes>Create user guide with step-by-step tutorials and troubleshooting</if_yes>
97 <if_no>Use API docs for developers or README for contributors</if_no>
98 </decision_tree>
99 <context>
100 <audience>Non-technical users, administrators</audience>
101 <when_to_use>Creating help documentation, tutorials, or product guides</when_to_use>
102 </context>
103 <structure>
104 <section>Getting started</section>
105 <section>Core concepts</section>
106 <section>Step-by-step tutorials</section>
107 <section>Feature reference</section>
108 <section>Troubleshooting / FAQ</section>
109 <section>Glossary</section>
110 </structure>
111 </pattern>
112
113 <pattern name="readme_structure">
114 <description>Standard structure for README documentation</description>
115 <example>
116 <note>Project Name</note>
117
118 []
119
120 Brief one-line description of what the project does.
121
122 <features>
123 - Feature 1
124 - Feature 2
125 - Feature 3
126 </features>
127
128 <quick_start>
129 ```bash
130 npm install package-name
131 ```
132 </quick_start>
133
134 <basic_usage>
135 ```typescript
136 import { example } from "package-name";
137
138 const result = example();
139 console.log(result);
140 ```
141 </basic_usage>
142
143 <documentation>
144 See [full documentation](link) for detailed guides.
145 </documentation>
146
147 <contributing>
148 Contributions welcome! See [CONTRIBUTING.md](link).
149 </contributing>
150
151 <license>
152 MIT
153 </license>
154 </example>
155 </pattern>
156
157 <pattern name="api_documentation">
158 <description>Comprehensive API reference documentation structure</description>
159 <example>
160 <note>API Reference</note>
161
162 <authentication>
163 All requests require an API key in the Authorization header:
164
165 ```bash
166 Authorization: Bearer YOUR_API_KEY
167 ```
168 </authentication>
169
170 <base_url>
171 ```
172 https://api.example.com/v1
173 ```
174 </base_url>
175
176 <endpoints>
177 <get_users>
178 Retrieve a list of users.
179
180 **Parameters:**
181
182 - `limit` (integer, optional): Number of results (default: 10)
183 - `offset` (integer, optional): Pagination offset (default: 0)
184
185 **Response:**
186
187 ```json
188 {
189 "users": [
190 { "id": 1, "name": "John Doe" },
191 { "id": 2, "name": "Jane Smith" }
192 ],
193 "total": 100
194 }
195 ```
196
197 **Error Codes:**
198
199 - `401`: Unauthorized - Invalid API key
200 - `429`: Rate limit exceeded
201 </get_users>
202 </endpoints>
203 </example>
204 </pattern>
205
206 <pattern name="design_document_structure">
207 <description>Technical design document format for architectural decisions</description>
208 <example>
209 <note>Feature Name Design Document</note>
210
211 <summary>
212 **Problem:** Brief description of the problem being solved
213 **Solution:** High-level approach
214 **Scope:** What's included and what's not
215 </summary>
216
217 <background>
218 Context and motivation for this design.
219 </background>
220
221 <goals_and_non_goals>
222 **Goals:**
223
224 - Goal 1
225 - Goal 2
226
227 **Non-Goals:**
228
229 - What we're explicitly not doing
230 - Future considerations
231 </goals_and_non_goals>
232
233 <technical_design>
234 <architecture>
235 [Diagram or description of system architecture]
236 </architecture>
237
238 <data_flow>
239 1. User action
240 2. System processing
241 3. Response
242 </data_flow>
243
244 <components>
245 **Component A:** Responsible for X
246 **Component B:** Responsible for Y
247 </components>
248 </technical_design>
249
250 <alternatives_considered>
251 <alternative_1>
252 Pros: ...
253 Cons: ...
254 Decision: Not chosen because...
255 </alternative_1>
256 </alternatives_considered>
257
258 <security_considerations>
259 - Data encryption at rest and in transit
260 - Authentication and authorization
261 - Input validation
262 </security_considerations>
263
264 <testing_strategy>
265 - Unit tests for component logic
266 - Integration tests for API contracts
267 - E2E tests for critical user flows
268 </testing_strategy>
269
270 <rollout_plan>
271 1. Phase 1: Internal testing
272 2. Phase 2: Beta release (10% of users)
273 3. Phase 3: Full rollout
274 </rollout_plan>
275 </example>
276 </pattern>
277
278 <pattern name="user_guide_structure">
279 <description>End-user documentation with step-by-step instructions</description>
280 <example>
281 <note>User Guide</note>
282
283 <getting_started>
284 Welcome! This guide will help you get started with [Product Name].
285 </getting_started>
286
287 <core_concepts>
288 **Workspace:** A container for your projects
289 **Project:** A collection of related items
290 **Item:** The basic unit of work
291 </core_concepts>
292
293 <creating_your_first_project>
294 1. Click the "New Project" button
295 2. Enter a project name
296 3. Choose a template (optional)
297 4. Click "Create"
298
299 You'll see your new project in the sidebar.
300 </creating_your_first_project>
301
302 <troubleshooting>
303 <troubleshooting_login>
304 1. Check your email address is correct
305 2. Click "Forgot Password" to reset
306 3. Contact support if the issue persists
307 </troubleshooting_login>
308
309 <troubleshooting_data>
310 Ensure you have a stable internet connection. The app auto-saves every 30 seconds.
311 </troubleshooting_data>
312 </troubleshooting>
313
314 <glossary>
315 **Term:** Definition
316 **Another Term:** Another definition
317 </glossary>
318 </example>
319 </pattern>
320</patterns>
321
322<best_practices>
323 <practice priority="critical">
324 <description>Audience-first approach - Write for your specific audience's knowledge level</description>
325 <example>
326 Developers: Assume technical background, focus on implementation details
327 Team members: Balance context with technical depth
328 End users: Avoid jargon, use step-by-step instructions
329 </example>
330 </practice>
331
332 <practice priority="critical">
333 <description>Progressive disclosure - Start with essentials, reveal complexity gradually</description>
334 <example>
335 1. Quick start for immediate value
336 2. Common use cases
337 3. Advanced configuration
338 4. Edge cases and troubleshooting
339 </example>
340 </practice>
341
342 <practice priority="high">
343 <description>Make content scannable to enable quick information retrieval</description>
344 <example>
345 - Use descriptive headings
346 - Use bullet points for lists
347 - Include code blocks with syntax highlighting
348 - Use tables for structured data
349 - Use bold for key terms (sparingly)
350 </example>
351 </practice>
352
353 <practice priority="high">
354 <description>Example-driven documentation - Show, don't just tell</description>
355 <example>
356 - Include working code examples
357 - Show expected output
358 - Provide copy-pasteable commands
359 </example>
360 </practice>
361
362 <practice priority="medium">
363 <description>Active voice and present tense for clarity</description>
364 <example>
365 Good: Run this command to start the server.
366 Bad: The server can be started by running the following command.
367 </example>
368 </practice>
369
370 <practice priority="medium">
371 <description>Test all code examples before publishing</description>
372 <example>
373 Always verify that code examples compile and run correctly
374 Include expected output
375 Test edge cases mentioned in documentation
376 </example>
377 </practice>
378</best_practices>
379
380<language_guidelines>
381 <english>
382 <style>Active voice, present tense</style>
383 <tone>Professional but approachable</tone>
384 <avoid>Unnecessarily complex words, idioms that don't translate</avoid>
385 <example>
386 <good_example>Good</good_example>
387 Run this command to start the server.
388
389 <bad_example>Bad</bad_example>
390 The server can be started by running the following command.
391 </example>
392 </english>
393
394 <japanese>
395 <style>です・ます調 (polite form) for user docs, である調 for technical specs</style>
396 <tone>丁寧だが簡潔</tone>
397 <avoid>過度なカタカナ語、曖昧な表現</avoid>
398 <example>
399 <good_example>Good</good_example>
400 以下のコマンドでサーバーを起動します。
401
402 <bad_example>Bad</bad_example>
403 サーバーの起動については、下記コマンドを実行することで可能となります。
404 </example>
405 </japanese>
406
407 <bilingual>
408 <rule>Maintain parallel structure between languages</rule>
409 <rule>Keep code examples identical, translate only prose</rule>
410 <rule>Use consistent terminology (create glossary if needed)</rule>
411 </bilingual>
412</language_guidelines>
413
414<workflow>
415 <phase name="plan">
416 <step>Identify document type and audience</step>
417 <step>Outline key sections</step>
418 <step>Gather technical details</step>
419 </phase>
420
421 <phase name="draft">
422 <step>Write in order: overview → details → examples</step>
423 <step>Include all code examples (test them)</step>
424 <step>Mark TODOs for uncertain parts</step>
425 </phase>
426
427 <phase name="review">
428 <step>Verify technical accuracy</step>
429 <step>Check all links and code examples work</step>
430 <step>Review for audience appropriateness</step>
431 <step>Proofread for grammar and typos</step>
432 </phase>
433
434 <phase name="maintain">
435 <step>Update when code changes</step>
436 <step>Review periodically for accuracy</step>
437 <step>Track user feedback</step>
438 </phase>
439</workflow>
440
441<output>
442 <format>
443 <document_plan>
444 - Type: [readme/api_spec/design_doc/user_guide]
445 - Audience: [developer/team/end_user]
446 - Language: [en/ja/both]
447 </document_plan>
448
449 <structure>
450 [Proposed sections based on document type]
451 </structure>
452
453 <content>
454 [Actual documentation content]
455 </content>
456
457 <review_checklist>
458 - [ ] Technical accuracy verified
459 - [ ] Code examples tested
460 - [ ] Links working
461 - [ ] Appropriate for audience
462 - [ ] Grammar and spelling checked
463 </review_checklist>
464 </format>
465</output>
466
467<anti_patterns>
468 <avoid name="wall_of_text">
469 <description>Long paragraphs without formatting</description>
470 <instead>Break into smaller paragraphs, use bullet points, headings, and code blocks</instead>
471 </avoid>
472
473 <avoid name="outdated_info">
474 <description>Documenting historical context instead of current state</description>
475 <instead>Document what exists now, move history to a separate section if needed</instead>
476 </avoid>
477
478 <avoid name="assuming_context">
479 <description>Using terms or concepts without definition</description>
480 <instead>Define terms on first use, link to prerequisites, provide glossary</instead>
481 </avoid>
482
483 <avoid name="untested_examples">
484 <description>Including code examples that haven't been tested</description>
485 <instead>Always verify code examples compile and run correctly before publishing</instead>
486 </avoid>
487
488 <avoid name="passive_voice">
489 <description>Using passive constructions that obscure agency</description>
490 <instead>Use active voice for clarity (e.g., "Run the command" not "The command should be run")</instead>
491 </avoid>
492
493 <avoid name="jargon_overload">
494 <description>Using technical jargon without explanation</description>
495 <instead>Define technical terms on first use, provide a glossary, or use simpler language for user-facing docs</instead>
496 </avoid>
497
498 <avoid name="missing_prerequisites">
499 <description>Assuming users have required knowledge or setup</description>
500 <instead>List prerequisites clearly at the beginning, link to setup guides</instead>
501 </avoid>
502
503 <avoid name="vague_instructions">
504 <description>Using imprecise language like "simply" or "just" without concrete steps</description>
505 <instead>Provide specific, numbered steps with expected outcomes</instead>
506 </avoid>
507</anti_patterns>
508
509<rules priority="critical">
510 <rule>Verify all code examples compile and run before including in documentation</rule>
511 <rule>Match documentation structure to audience knowledge level</rule>
512 <rule>Never publish documentation with placeholder content or TODOs</rule>
513</rules>
514
515<rules priority="standard">
516 <rule>Use active voice and present tense for instructions</rule>
517 <rule>Include expected output for all code examples</rule>
518 <rule>Define technical terms on first use or link to glossary</rule>
519 <rule>Keep README under 500 lines; link to detailed docs for more</rule>
520</rules>
521
522<error_escalation>
523 <level severity="low">
524 <example>Minor formatting inconsistency</example>
525 <action>Fix formatting, follow style guide</action>
526 </level>
527 <level severity="medium">
528 <example>Outdated information detected</example>
529 <action>Update content, verify with code</action>
530 </level>
531 <level severity="high">
532 <example>Incorrect technical information</example>
533 <action>Stop, verify with implementation before publishing</action>
534 </level>
535 <level severity="critical">
536 <example>Security-sensitive information exposed</example>
537 <action>Block publication, require security review</action>
538 </level>
539</error_escalation>
540
541<constraints>
542 <must>Verify accuracy against actual implementation</must>
543 <must>Include runnable code examples</must>
544 <must>Follow project documentation style</must>
545 <avoid>Documenting without reading code</avoid>
546 <avoid>Adding timestamps to documents</avoid>
547 <avoid>Duplicating information unnecessarily</avoid>
548</constraints>
549
550<related_agents>
551 <agent name="design">Requirements analysis and documentation structure planning</agent>
552 <agent name="docs">Technical documentation writing and generation</agent>
553 <agent name="execute">Documentation deployment and publishing tasks</agent>
554 <agent name="bug">Fixing broken links, outdated examples, and documentation inconsistencies</agent>
555</related_agents>
556
557<related_skills>
558 <skill name="serena-usage">Symbol operations for extracting code examples and API signatures</skill>
559 <skill name="context7-usage">Library documentation lookup for accurate API references</skill>
560 <skill name="investigation-patterns">Analyzing codebases to understand features for documentation</skill>
561 <skill name="technical-writing">Creating blog posts and tutorials from documentation</skill>
562</related_skills>