docs

Name: docs
Author: softspark

161stars21forks

How to install docs?

softspark/ai-toolkit/docs

$npx -y skills add softspark/ai-toolkit --skill docs

Installs into the current project.

Summary

Generates/updates README, API docs, architecture notes. Triggers: docs, README, API docs, architecture note, documentation.

Files · 1

View on GitHub

SKILL.md

1	# Generate Documentation
2
3	$ARGUMENTS
4
5	Generate or update documentation.
6
7	## Usage
8
9	```
10	/docs [type] [target]
11	```
12
13	## What This Command Does
14
15	1. Analyzes code structure
16	2. Extracts documentation info
17	3. Generates documentation files
18	4. Updates existing docs
19
20	## Documentation Types
21
22	\| Type \| Description \|
23	\|------\|-------------\|
24	\| `readme` \| Generate/update README \|
25	\| `api` \| API documentation \|
26	\| `architecture-note` \| Architecture note \|
27	\| `changelog` \| Generate changelog \|
28	\| `comments` \| Add code comments \|
29	\| `kb` \| Knowledge base entry (enforces KB structure) \|
30
31	## KB Document Rules (MANDATORY)
32
33	When creating or updating documents in the `kb/` directory, follow the `documentation-standards` knowledge skill (auto-loaded). Key rules:
34
35	- 7 required frontmatter fields: title, category, service, tags, created, last_updated, description
36	- 6 valid categories: reference, howto, procedures, troubleshooting, best-practices, planning
37	- Category must match directory (e.g., `category: howto` → `kb/howto/`)
38	- English only. No exceptions.
39	- validate.sh rejects docs without valid frontmatter.
40
41	Full spec: see `app/skills/documentation-standards/SKILL.md`.
42
43	## Templates
44
45	### README Generation
46	```markdown
47	# [Project Name]
48
49	[Auto-generated description]
50
51	## Installation
52	[Detected from package manager]
53
54	## Usage
55	[Extracted from code/examples]
56
57	## API
58	[Extracted from code]
59
60	## License
61	[Detected]
62	```
63
64	### Architecture Note Template
65	```markdown
66	# Architecture Note: [TITLE]
67
68	## Status
69	Proposed
70
71	## Context
72	[What is the issue?]
73
74	## Decision
75	[What was decided?]
76
77	## Consequences
78	[What are the results?]
79
80	## Date
81	[Today's date]
82	```
83
84	## Output Format
85
86	```markdown
87	## Documentation Report
88
89	### Generated
90	- [file 1]
91	- [file 2]
92
93	### Updated
94	- [file 3]: [what changed]
95
96	### Skipped
97	- [file 4]: [reason]
98
99	### Next Steps
100	- [ ] Review generated docs
101	- [ ] Add missing details
102	- [ ] Commit changes
103	```
104
105	## Common Rationalizations
106
107	\| Excuse \| Why It's Wrong \|
108	\|--------\|----------------\|
109	\| "The code is self-documenting" \| Code shows how, not why — decisions, constraints, and context need prose \|
110	\| "Nobody reads docs anyway" \| People don't read bad docs — good docs are the first thing consulted \|
111	\| "I'll document it when it's stable" \| Unstable code needs docs most — document intent so others can contribute \|
112	\| "Comments get stale" \| That's an argument for maintaining docs, not skipping them \|
113	\| "The tests are the documentation" \| Tests verify behavior but don't explain architecture, trade-offs, or setup \|
114
115	## Configuration
116
117	Documentation settings in:
118	- `.claude/settings.json`
119	- Project's doc config
120
121	## REVIEW BEFORE COMMIT
122
123	Generated documentation should be reviewed.
124	AI may miss context or make assumptions.
125
126	## Documentation Inventory
127
128	Run the bundled script to audit documentation coverage and find gaps:
129
130	```bash
131	python3 ${CLAUDE_SKILL_DIR}/scripts/doc-inventory.py .
132	```
133
134	## Parallel Documentation (large codebases)
135
136	If the inventory script reports `doc_coverage_percent < 50` and the project has multiple modules, use Agent Teams for parallel documentation:
137
138	```
139	Create an agent team for documentation:
140	- Teammate 1 (documenter): "Document the [module-1] directory. Generate docstrings for all public functions." Use Sonnet.
141	- Teammate 2 (documenter): "Document the [module-2] directory. Generate docstrings for all public functions." Use Sonnet.
142	- Teammate 3 (documenter): "Generate README sections: installation, usage, API reference." Use Opus.
143	Teammates should NOT overlap — each owns their assigned scope.
144	```
145
146	## Related Skills
147	- Documenting an architecture decision? → `/council` for multi-perspective analysis first
148	- Need to explore the codebase? → `/explore` to understand structure before documenting
149	- Writing a PRD? → `/write-a-prd` for structured product requirements
150	- Auditing existing docs? → `/analyze` for coverage gaps

People who liked this also viewed

6 picks

Type

grill-with-docsA relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.SkillsJul 2026537k182k
lark-minutes飞书妙记：搜索妙记、查看妙记基础信息、下载/上传音视频、读取或编辑妙记的产物内容、改标题、替换说话人/关键词、申请妙记查看/编辑权限。当给出minute_token、本地音视频文件，要查/改/转妙记产物，或用户明确要主动申请妙记权限时使用；本地音视频转纪要/逐字稿优先走本 skill，不要用 ffmpeg/whisper 本地转写。不负责：获取会议关联妙记，或仅按自然语言标题定位纪要SkillsJul 2026379k16k
lark-markdown飞书 Markdown：查看、创建、上传、编辑和比较 Markdown 文件。当用户需要创建或编辑 Markdown 文件、读取、修改、局部 patch 或比较差异时使用。不负责将 Markdown 导入为飞书在线文档，也不负责文件搜索、权限、评论、移动、删除等云空间管理操作。SkillsJul 2026295k16k
docxUse this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files) or Word templates (.dotx files). Triggers include: any mention of 'Word doc', 'word document', SkillsJul 2026157k163k
edit-articleSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026154k181k
lark-note飞书会议纪要（Note）直查：已知 note_id 时查询纪要详情、展示类型、关联文档 token，并读取 unified 原始逐字记录。当用户已持有 note_id，或从文档显式 vc-node-id 获得 note_id 时使用。不负责会议/日程/妙记定位、文档标题搜索或 Docx 正文读取。SkillsJul 2026154k16k

docs

161stars21forks

View on GitHub

How to install docs?

softspark/ai-toolkit/docs

$npx -y skills add softspark/ai-toolkit --skill docs

Installs into the current project.

Summary

Generates/updates README, API docs, architecture notes. Triggers: docs, README, API docs, architecture note, documentation.

Files · 1

View on GitHub

SKILL.md

1	# Generate Documentation
2
3	$ARGUMENTS
4
5	Generate or update documentation.
6
7	## Usage
8
9	```
10	/docs [type] [target]
11	```
12
13	## What This Command Does
14
15	1. Analyzes code structure
16	2. Extracts documentation info
17	3. Generates documentation files
18	4. Updates existing docs
19
20	## Documentation Types
21
22	\| Type \| Description \|
23	\|------\|-------------\|
24	\| `readme` \| Generate/update README \|
25	\| `api` \| API documentation \|
26	\| `architecture-note` \| Architecture note \|
27	\| `changelog` \| Generate changelog \|
28	\| `comments` \| Add code comments \|
29	\| `kb` \| Knowledge base entry (enforces KB structure) \|
30
31	## KB Document Rules (MANDATORY)
32
33	When creating or updating documents in the `kb/` directory, follow the `documentation-standards` knowledge skill (auto-loaded). Key rules:
34
35	- 7 required frontmatter fields: title, category, service, tags, created, last_updated, description
36	- 6 valid categories: reference, howto, procedures, troubleshooting, best-practices, planning
37	- Category must match directory (e.g., `category: howto` → `kb/howto/`)
38	- English only. No exceptions.
39	- validate.sh rejects docs without valid frontmatter.
40
41	Full spec: see `app/skills/documentation-standards/SKILL.md`.
42
43	## Templates
44
45	### README Generation
46	```markdown
47	# [Project Name]
48
49	[Auto-generated description]
50
51	## Installation
52	[Detected from package manager]
53
54	## Usage
55	[Extracted from code/examples]
56
57	## API
58	[Extracted from code]
59
60	## License
61	[Detected]
62	```
63
64	### Architecture Note Template
65	```markdown
66	# Architecture Note: [TITLE]
67
68	## Status
69	Proposed
70
71	## Context
72	[What is the issue?]
73
74	## Decision
75	[What was decided?]
76
77	## Consequences
78	[What are the results?]
79
80	## Date
81	[Today's date]
82	```
83
84	## Output Format
85
86	```markdown
87	## Documentation Report
88
89	### Generated
90	- [file 1]
91	- [file 2]
92
93	### Updated
94	- [file 3]: [what changed]
95
96	### Skipped
97	- [file 4]: [reason]
98
99	### Next Steps
100	- [ ] Review generated docs
101	- [ ] Add missing details
102	- [ ] Commit changes
103	```
104
105	## Common Rationalizations
106
107	\| Excuse \| Why It's Wrong \|
108	\|--------\|----------------\|
109	\| "The code is self-documenting" \| Code shows how, not why — decisions, constraints, and context need prose \|
110	\| "Nobody reads docs anyway" \| People don't read bad docs — good docs are the first thing consulted \|
111	\| "I'll document it when it's stable" \| Unstable code needs docs most — document intent so others can contribute \|
112	\| "Comments get stale" \| That's an argument for maintaining docs, not skipping them \|
113	\| "The tests are the documentation" \| Tests verify behavior but don't explain architecture, trade-offs, or setup \|
114
115	## Configuration
116
117	Documentation settings in:
118	- `.claude/settings.json`
119	- Project's doc config
120
121	## REVIEW BEFORE COMMIT
122
123	Generated documentation should be reviewed.
124	AI may miss context or make assumptions.
125
126	## Documentation Inventory
127
128	Run the bundled script to audit documentation coverage and find gaps:
129
130	```bash
131	python3 ${CLAUDE_SKILL_DIR}/scripts/doc-inventory.py .
132	```
133
134	## Parallel Documentation (large codebases)
135
136	If the inventory script reports `doc_coverage_percent < 50` and the project has multiple modules, use Agent Teams for parallel documentation:
137
138	```
139	Create an agent team for documentation:
140	- Teammate 1 (documenter): "Document the [module-1] directory. Generate docstrings for all public functions." Use Sonnet.
141	- Teammate 2 (documenter): "Document the [module-2] directory. Generate docstrings for all public functions." Use Sonnet.
142	- Teammate 3 (documenter): "Generate README sections: installation, usage, API reference." Use Opus.
143	Teammates should NOT overlap — each owns their assigned scope.
144	```
145
146	## Related Skills
147	- Documenting an architecture decision? → `/council` for multi-perspective analysis first
148	- Need to explore the codebase? → `/explore` to understand structure before documenting
149	- Writing a PRD? → `/write-a-prd` for structured product requirements
150	- Auditing existing docs? → `/analyze` for coverage gaps

People who liked this also viewed

6 picks

Type