documentation-writing

Name: documentation-writing
Author: pavel-molyanov

241stars75forks

How to install documentation-writing?

pavel-molyanov/molyanov-ai-dev/documentation-writing

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill documentation-writing

Installs into the current project.

Summary

Maintain project documentation in .claude/skills/project-knowledge/: audit, edit, check consistency, track status. Use when: "проверь документацию", "обнови документацию", "аудит документации", "check docs", "audit documentation", "update docs", "проверь базу знаний проекта" For

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Documentation Management
4
5	Maintain project documentation in `.claude/skills/project-knowledge/references/`. Audit for bloat, edit files, check consistency, track status.
6
7	For creating documentation from scratch (new project or empty docs), use `project-planning` skill.
8
9	## Project Documentation Autosync
10
11	Project documentation source of truth is Claude-side: `CLAUDE.md` and `.claude/**`.
12	Codex-side `AGENTS.md` and `.codex/**` are generated runtime files.
13
14	After changing any project-local `.claude/**` file, immediately run:
15
16	```bash
17	~/.claude/scripts/sync-to-codex.sh --project "$PWD" --apply
18	```
19
20	If sync reports a conflict, stop and report it. Include generated `.codex/` changes in the same commit as the `.claude/` source change.
21
22	### Nested Agent Workspaces
23
24	Some projects keep an agent workspace under a subdirectory (for example
25	`nested-workspace/.claude/**`) while the repository root exposes selected skills or
26	agents through symlinks in root `.claude/**`. In that case, sync both levels:
27
28	```bash
29	~/.claude/scripts/sync-to-codex.sh --project "$PWD/nested-workspace" --apply
30	~/.claude/scripts/sync-to-codex.sh --project "$PWD" --apply
31	```
32
33	Verify root `.codex/agents` / `.codex/skills` and
34	`.codex/.sync/claude-to-codex-manifest.json` include every root-exposed agent or
35	skill. A generated file existing only inside the nested workspace is not enough
36	when the root runtime must invoke it.
37
38	## Documentation Principles
39
40	These rules apply to ALL documentation operations (audit, edit, create).
41
42	Goal: open docs → understand the project without reading code. What is this project, how it's structured, what it does, where to find key things, how to deploy, where are logs. A high-level navigation guide.
43
44	Describe what exists, what it does, and why. High-level overview of components, how they work together, decisions made (why this stack, why this architecture), operational details (server addresses, deploy procedures, log locations, env var names). Skip what's obvious from reading the code itself — function signatures, implementation details, generic framework behavior.
45
46	No code blocks, no pseudocode. Link to source files: `[auth.ts:45-67](src/auth/jwt.ts#L45-L67)`. Code in docs gets outdated and bloats context.
47
48	No duplication between files. Information lives in ONE place. Cross-reference: "See deployment.md for env vars."
49
50	patterns.md: only project-specific patterns. Universal coding standards live in `~/.claude/skills/code-writing/references/universal-patterns.md`. Project patterns.md contains only what's unique to THIS project.
51
52	## File Structure
53
54	4 core files in `.claude/skills/project-knowledge/references/`:
55
56	\| File \| Contains \|
57	\|------\|----------\|
58	\| project.md \| Overview, audience, problem, 3-5 key features, out of scope \|
59	\| architecture.md \| Tech stack (with WHY), project structure, dependencies, integrations, data model \|
60	\| patterns.md \| Project-specific code patterns, git workflow, testing methods, business rules \|
61	\| deployment.md \| Platform, env var names, CI/CD triggers, rollback, monitoring \|
62
63	Optional:
64	- ux-guidelines.md — only for projects with significant UI
65	- {custom}.md — domain-specific (bot.md, vault.md, api.md)
66
67	Templates with placeholder structure are in `~/.claude/shared/templates/new-project/.claude/skills/project-knowledge/references/`. The templates are self-documenting — each section has comments explaining what to write.
68
69	## Workflows
70
71	### 1. Audit
72
73	Trigger: User asks to audit, check quality, or find bloat.
74
75	1. Read all files from `.claude/skills/project-knowledge/references/` + CLAUDE.md + README.md
76	2. Flag issues:
77	- Code blocks → replace with file references
78	- Generic framework knowledge (belongs in official docs) → remove
79	- Function-level details → suggest moving to code comments
80	- Bloated sections (>3-5KB per file is suspicious) → condense
81	- Duplication across files → consolidate to one place
82	- Placeholder text (`[Project Name]`, `TODO`) → fill or remove
83	- Inconsistent terminology → standardize
84	- Outdated info (files/functions that no longer exist) → update or remove
85	- Universal patterns in patterns.md → flag for removal (those belong in code-writing skill)
86	3. Preserve operational details: server addresses, SSH configs, deploy commands, log paths, env var names, monitoring URLs. These belong in docs even if they seem "obvious" — they can't be read from code.
87	4. Create audit report wi

People who liked this also viewed

6 picks

Type

documentation-writing

241stars75forks

View on GitHub

How to install documentation-writing?

pavel-molyanov/molyanov-ai-dev/documentation-writing

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill documentation-writing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Documentation Management
4
5	Maintain project documentation in `.claude/skills/project-knowledge/references/`. Audit for bloat, edit files, check consistency, track status.
6
7	For creating documentation from scratch (new project or empty docs), use `project-planning` skill.
8
9	## Project Documentation Autosync
10
11	Project documentation source of truth is Claude-side: `CLAUDE.md` and `.claude/**`.
12	Codex-side `AGENTS.md` and `.codex/**` are generated runtime files.
13
14	After changing any project-local `.claude/**` file, immediately run:
15
16	```bash
17	~/.claude/scripts/sync-to-codex.sh --project "$PWD" --apply
18	```
19
20	If sync reports a conflict, stop and report it. Include generated `.codex/` changes in the same commit as the `.claude/` source change.
21
22	### Nested Agent Workspaces
23
24	Some projects keep an agent workspace under a subdirectory (for example
25	`nested-workspace/.claude/**`) while the repository root exposes selected skills or
26	agents through symlinks in root `.claude/**`. In that case, sync both levels:
27
28	```bash
29	~/.claude/scripts/sync-to-codex.sh --project "$PWD/nested-workspace" --apply
30	~/.claude/scripts/sync-to-codex.sh --project "$PWD" --apply
31	```
32
33	Verify root `.codex/agents` / `.codex/skills` and
34	`.codex/.sync/claude-to-codex-manifest.json` include every root-exposed agent or
35	skill. A generated file existing only inside the nested workspace is not enough
36	when the root runtime must invoke it.
37
38	## Documentation Principles
39
40	These rules apply to ALL documentation operations (audit, edit, create).
41
42	Goal: open docs → understand the project without reading code. What is this project, how it's structured, what it does, where to find key things, how to deploy, where are logs. A high-level navigation guide.
43
44	Describe what exists, what it does, and why. High-level overview of components, how they work together, decisions made (why this stack, why this architecture), operational details (server addresses, deploy procedures, log locations, env var names). Skip what's obvious from reading the code itself — function signatures, implementation details, generic framework behavior.
45
46	No code blocks, no pseudocode. Link to source files: `[auth.ts:45-67](src/auth/jwt.ts#L45-L67)`. Code in docs gets outdated and bloats context.
47
48	No duplication between files. Information lives in ONE place. Cross-reference: "See deployment.md for env vars."
49
50	patterns.md: only project-specific patterns. Universal coding standards live in `~/.claude/skills/code-writing/references/universal-patterns.md`. Project patterns.md contains only what's unique to THIS project.
51
52	## File Structure
53
54	4 core files in `.claude/skills/project-knowledge/references/`:
55
56	\| File \| Contains \|
57	\|------\|----------\|
58	\| project.md \| Overview, audience, problem, 3-5 key features, out of scope \|
59	\| architecture.md \| Tech stack (with WHY), project structure, dependencies, integrations, data model \|
60	\| patterns.md \| Project-specific code patterns, git workflow, testing methods, business rules \|
61	\| deployment.md \| Platform, env var names, CI/CD triggers, rollback, monitoring \|
62
63	Optional:
64	- ux-guidelines.md — only for projects with significant UI
65	- {custom}.md — domain-specific (bot.md, vault.md, api.md)
66
67	Templates with placeholder structure are in `~/.claude/shared/templates/new-project/.claude/skills/project-knowledge/references/`. The templates are self-documenting — each section has comments explaining what to write.
68
69	## Workflows
70
71	### 1. Audit
72
73	Trigger: User asks to audit, check quality, or find bloat.
74
75	1. Read all files from `.claude/skills/project-knowledge/references/` + CLAUDE.md + README.md
76	2. Flag issues:
77	- Code blocks → replace with file references
78	- Generic framework knowledge (belongs in official docs) → remove
79	- Function-level details → suggest moving to code comments
80	- Bloated sections (>3-5KB per file is suspicious) → condense
81	- Duplication across files → consolidate to one place
82	- Placeholder text (`[Project Name]`, `TODO`) → fill or remove
83	- Inconsistent terminology → standardize
84	- Outdated info (files/functions that no longer exist) → update or remove
85	- Universal patterns in patterns.md → flag for removal (those belong in code-writing skill)
86	3. Preserve operational details: server addresses, SSH configs, deploy commands, log paths, env var names, monitoring URLs. These belong in docs even if they seem "obvious" — they can't be read from code.
87	4. Create audit report wi

People who liked this also viewed

6 picks

Type