update-docs

Name: update-docs
Author: getnao

168stars52forks

How to install update-docs?

getnao/sylph/update-docs

$npx -y skills add getnao/sylph --skill update-docs

Installs into the current project.

Summary

Detect user-facing features in recently merged PRs and open a PR in the docs repo adding the missing documentation.

Files · 1

View on GitHub

SKILL.md

1	# Update Docs
2
3	When the user runs `/update-docs`, scan recently merged PRs for user-facing
4	changes and open a documentation PR.
5
6	## MCP connectors
7
8	\| Connector \| Purpose \|
9	\|-----------\|---------\|
10	\| GitHub \| Read merged PRs, create docs PRs \|
11
12	## Prerequisites
13
14	Both repos must be cloned locally:
15	- Product repo: the main codebase (configured in CONTEXT.md)
16	- Docs repo: the documentation site (configured in CONTEXT.md or asked on first run)
17
18	State file: `agents/cmo/_state/docs_last_refresh.txt` (plain text, single ISO date).
19
20	---
21
22	## Step 1: Determine the PR window
23
24	1. Read `agents/cmo/_state/docs_last_refresh.txt` if it exists
25	2. If the file exists, use its date as `SINCE`
26	3. If it does NOT exist (first run), use `today - 15 days` as `SINCE`
27	4. Record `TODAY` as the date to write back at the end
28
29	---
30
31	## Step 2: List merged PRs
32
33	```bash
34	gh pr list -R <product-repo> \
35	--state merged \
36	--search "merged:>=<SINCE>" \
37	--limit 100 \
38	--json number,title,url,mergedAt,body,author,files
39	```
40
41	Keep the full list - every PR appears in the final summary, even those that don't need docs.
42
43	---
44
45	## Step 3: Classify each PR
46
47	For each PR, decide: user-facing or not?
48
49	User-facing (needs docs):
50	- New feature in the UI, CLI, API, or configuration
51	- New command, flag, setting, integration, or UI element
52	- Behavior change that affects how users interact with the product
53	- New capability that a user would want to know about
54	- Anything that belongs in release notes
55
56	NOT user-facing (skip):
57	- Refactors, internal cleanups, tests, CI, infra
58	- Dependency bumps, lockfile updates
59	- Backend-only changes invisible to users
60	- Bug fixes that restore already-documented behavior
61	- Brand, marketing, or internal tooling changes
62
63	When unsure, read the PR body and changed files. If still ambiguous, err on no docs and note it in the summary.
64
65	---
66
67	## Step 4: Fetch current docs state
68
69	Pull latest from the docs repo:
70
71	```bash
72	cd <docs-repo> && git checkout main && git pull
73	```
74
75	Before writing any new doc, search the repo for existing coverage (grep on keywords from the PR title/body). If a relevant page exists, update it instead of creating a new one.
76
77	---
78
79	## Step 5: Write the docs
80
81	For each user-facing PR that needs docs:
82
83	1. Identify the right section and subfolder
84	2. Either update an existing page or create a new one
85	3. Follow the style of neighboring pages - tone, frontmatter, headings, code blocks
86	4. If you create a new page, add it to the navigation/sitemap config
87	5. Keep docs factual and concise - no marketing voice, direct tone
88	6. Only document what actually shipped - read the PR diff if the description is thin. Never invent behavior.
89
90	---
91
92	## Step 6: Create a new branch and PR
93
94	```bash
95	cd <docs-repo>
96	git checkout -b docs/refresh-<TODAY>
97	git add <changed files>
98	git commit -m "docs: refresh for PRs merged since <SINCE>"
99	git push -u origin docs/refresh-<TODAY>
100	gh pr create -R <docs-repo> \
101	--title "docs: refresh for PRs merged since <SINCE>" \
102	--body "<PR summary - see template below>"
103	```
104
105	### PR summary template
106
107	Every PR from Step 2 must appear in the list, in merge order. Use these exact shapes:
108
109	```
110	- PR merged #123 <PR title> - no docs added
111	- PR merged #124 <PR title> - added docs - <one-line description of what was documented and where>
112	```
113
114	No other bullet shapes. No section grouping. Keep it a flat list.
115
116	If zero PRs were user-facing, skip PR creation and just update the state file.
117
118	---
119
120	## Step 7: Log the refresh
121
122	Write `TODAY` (ISO date) to `agents/cmo/_state/docs_last_refresh.txt`:
123
124	```bash
125	echo "<TODAY>" > agents/cmo/_state/docs_last_refresh.txt
126	git add agents/cmo/_state/docs_last_refresh.txt
127	git commit -m "chore(cmo): log docs refresh <TODAY>"
128	git push
129	```
130
131	The next run picks up from this date.
132
133	---
134
135	## Step 8: Report back
136
137	Return to the user:
138	- Docs PR URL (or "no user-facing PRs this run" if none)
139	- Number of PRs reviewed / number that got docs
140	- The full PR summary list (same content as the PR body)
141	- New last-refresh date
142
143	## Guardrails
144
145	- Never modify source code - docs changes only
146	- Link to source PRs in the docs PR description
147	- One docs PR per batch - group related changes together
148	- Flag ambiguity - if a PR's user impact is unclear, ask before documenting
149	- Never invent features - only document what the diff shows
150
151	## Self-improvement
152
153	After the docs PR is reviewed and merged:
154
155	1. If the reviewer requests changes to doc structure, tone, or coverage scope, update the relevant step in this skill file
156	2. If a PR classification was wrong (documented something that didn't need docs, or missed something that did), refine the classification guide in Step 3
157	3. Update `_insights.md` with patterns: which PRs consistently need docs, which doc styles get approved without changes
158	4. If the PR summary format needs adjustme

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

update-docs

168stars52forks

View on GitHub

How to install update-docs?

getnao/sylph/update-docs

$npx -y skills add getnao/sylph --skill update-docs

Installs into the current project.

Summary

Detect user-facing features in recently merged PRs and open a PR in the docs repo adding the missing documentation.

Files · 1

View on GitHub

SKILL.md

1	# Update Docs
2
3	When the user runs `/update-docs`, scan recently merged PRs for user-facing
4	changes and open a documentation PR.
5
6	## MCP connectors
7
8	\| Connector \| Purpose \|
9	\|-----------\|---------\|
10	\| GitHub \| Read merged PRs, create docs PRs \|
11
12	## Prerequisites
13
14	Both repos must be cloned locally:
15	- Product repo: the main codebase (configured in CONTEXT.md)
16	- Docs repo: the documentation site (configured in CONTEXT.md or asked on first run)
17
18	State file: `agents/cmo/_state/docs_last_refresh.txt` (plain text, single ISO date).
19
20	---
21
22	## Step 1: Determine the PR window
23
24	1. Read `agents/cmo/_state/docs_last_refresh.txt` if it exists
25	2. If the file exists, use its date as `SINCE`
26	3. If it does NOT exist (first run), use `today - 15 days` as `SINCE`
27	4. Record `TODAY` as the date to write back at the end
28
29	---
30
31	## Step 2: List merged PRs
32
33	```bash
34	gh pr list -R <product-repo> \
35	--state merged \
36	--search "merged:>=<SINCE>" \
37	--limit 100 \
38	--json number,title,url,mergedAt,body,author,files
39	```
40
41	Keep the full list - every PR appears in the final summary, even those that don't need docs.
42
43	---
44
45	## Step 3: Classify each PR
46
47	For each PR, decide: user-facing or not?
48
49	User-facing (needs docs):
50	- New feature in the UI, CLI, API, or configuration
51	- New command, flag, setting, integration, or UI element
52	- Behavior change that affects how users interact with the product
53	- New capability that a user would want to know about
54	- Anything that belongs in release notes
55
56	NOT user-facing (skip):
57	- Refactors, internal cleanups, tests, CI, infra
58	- Dependency bumps, lockfile updates
59	- Backend-only changes invisible to users
60	- Bug fixes that restore already-documented behavior
61	- Brand, marketing, or internal tooling changes
62
63	When unsure, read the PR body and changed files. If still ambiguous, err on no docs and note it in the summary.
64
65	---
66
67	## Step 4: Fetch current docs state
68
69	Pull latest from the docs repo:
70
71	```bash
72	cd <docs-repo> && git checkout main && git pull
73	```
74
75	Before writing any new doc, search the repo for existing coverage (grep on keywords from the PR title/body). If a relevant page exists, update it instead of creating a new one.
76
77	---
78
79	## Step 5: Write the docs
80
81	For each user-facing PR that needs docs:
82
83	1. Identify the right section and subfolder
84	2. Either update an existing page or create a new one
85	3. Follow the style of neighboring pages - tone, frontmatter, headings, code blocks
86	4. If you create a new page, add it to the navigation/sitemap config
87	5. Keep docs factual and concise - no marketing voice, direct tone
88	6. Only document what actually shipped - read the PR diff if the description is thin. Never invent behavior.
89
90	---
91
92	## Step 6: Create a new branch and PR
93
94	```bash
95	cd <docs-repo>
96	git checkout -b docs/refresh-<TODAY>
97	git add <changed files>
98	git commit -m "docs: refresh for PRs merged since <SINCE>"
99	git push -u origin docs/refresh-<TODAY>
100	gh pr create -R <docs-repo> \
101	--title "docs: refresh for PRs merged since <SINCE>" \
102	--body "<PR summary - see template below>"
103	```
104
105	### PR summary template
106
107	Every PR from Step 2 must appear in the list, in merge order. Use these exact shapes:
108
109	```
110	- PR merged #123 <PR title> - no docs added
111	- PR merged #124 <PR title> - added docs - <one-line description of what was documented and where>
112	```
113
114	No other bullet shapes. No section grouping. Keep it a flat list.
115
116	If zero PRs were user-facing, skip PR creation and just update the state file.
117
118	---
119
120	## Step 7: Log the refresh
121
122	Write `TODAY` (ISO date) to `agents/cmo/_state/docs_last_refresh.txt`:
123
124	```bash
125	echo "<TODAY>" > agents/cmo/_state/docs_last_refresh.txt
126	git add agents/cmo/_state/docs_last_refresh.txt
127	git commit -m "chore(cmo): log docs refresh <TODAY>"
128	git push
129	```
130
131	The next run picks up from this date.
132
133	---
134
135	## Step 8: Report back
136
137	Return to the user:
138	- Docs PR URL (or "no user-facing PRs this run" if none)
139	- Number of PRs reviewed / number that got docs
140	- The full PR summary list (same content as the PR body)
141	- New last-refresh date
142
143	## Guardrails
144
145	- Never modify source code - docs changes only
146	- Link to source PRs in the docs PR description
147	- One docs PR per batch - group related changes together
148	- Flag ambiguity - if a PR's user impact is unclear, ask before documenting
149	- Never invent features - only document what the diff shows
150
151	## Self-improvement
152
153	After the docs PR is reviewed and merged:
154
155	1. If the reviewer requests changes to doc structure, tone, or coverage scope, update the relevant step in this skill file
156	2. If a PR classification was wrong (documented something that didn't need docs, or missed something that did), refine the classification guide in Step 3
157	3. Update `_insights.md` with patterns: which PRs consistently need docs, which doc styles get approved without changes
158	4. If the PR summary format needs adjustme

People who liked this also viewed

6 picks

Type