update-docs

Name: update-docs
Author: vercel

141kstars31kforks

How to install update-docs?

vercel/next.js/update-docs

$npx -y skills add vercel/next.js --skill update-docs

Installs into the current project.

Summary

This skill should be used when the user asks to "update documentation for my changes", "check docs for this PR", "what docs need updating", "sync docs with code", "scaffold docs for this feature", "document this feature", "review docs completeness", "add docs for this change", "w

Files · 1

View on GitHub

SKILL.md

1	# Next.js Documentation Updater
2
3	Guides you through updating Next.js documentation based on code changes on the active branch. Designed for maintainers reviewing PRs for documentation completeness.
4
5	## Quick Start
6
7	1. Analyze changes: Run `git diff canary...HEAD --stat` to see what files changed
8	2. Identify affected docs: Map changed source files to documentation paths
9	3. Review each doc: Walk through updates with user confirmation
10	4. Validate: Run `pnpm lint` to check formatting
11	5. Commit: Stage documentation changes
12
13	## Workflow: Analyze Code Changes
14
15	### Step 1: Get the diff
16
17	```bash
18	# See all changed files on this branch
19	git diff canary...HEAD --stat
20
21	# See changes in specific areas
22	git diff canary...HEAD -- packages/next/src/
23	```
24
25	### Step 2: Identify documentation-relevant changes
26
27	Look for changes in these areas:
28
29	\| Source Path \| Likely Doc Impact \|
30	\| -------------------------------------- \| --------------------------- \|
31	\| `packages/next/src/client/components/` \| Component API reference \|
32	\| `packages/next/src/server/` \| Function API reference \|
33	\| `packages/next/src/shared/lib/` \| Varies by export \|
34	\| `packages/next/src/build/` \| Configuration or build docs \|
35	\| `packages/next/src/lib/` \| Various features \|
36
37	### Step 3: Map to documentation files
38
39	Use the code-to-docs mapping in `references/CODE-TO-DOCS-MAPPING.md` to find corresponding documentation files.
40
41	Example mappings:
42
43	- `src/client/components/image.tsx` → `docs/01-app/03-api-reference/02-components/image.mdx`
44	- `src/server/config-shared.ts` → `docs/01-app/03-api-reference/05-config/`
45
46	## Workflow: Update Existing Documentation
47
48	### Step 1: Read the current documentation
49
50	Before making changes, read the existing doc to understand:
51
52	- Current structure and sections
53	- Frontmatter fields in use
54	- Whether it uses `<AppOnly>` / `<PagesOnly>` for router-specific content
55
56	### Step 2: Identify what needs updating
57
58	Common updates include:
59
60	- New props/options: Add to the props table and create a section explaining usage
61	- Changed behavior: Update descriptions and examples
62	- Deprecated features: Add deprecation notices and migration guidance
63	- New examples: Add code blocks following conventions
64
65	### Step 3: Apply updates with confirmation
66
67	For each change:
68
69	1. Show the user what you plan to change
70	2. Wait for confirmation before editing
71	3. Apply the edit
72	4. Move to the next change
73
74	### Step 4: Check for shared content
75
76	If the doc uses the `source` field pattern (common for Pages Router docs), the source file is the one to edit. Example:
77
78	```yaml
79	# docs/02-pages/... file with shared content
80	---
81	source: app/building-your-application/optimizing/images
82	---
83	```
84
85	Edit the App Router source, not the Pages Router file.
86
87	### Step 5: Validate changes
88
89	```bash
90	pnpm lint # Check formatting
91	pnpm prettier-fix # Auto-fix formatting issues
92	```
93
94	## Workflow: Scaffold New Feature Documentation
95
96	Use this when adding documentation for entirely new features.
97
98	### Step 1: Determine the doc type
99
100	\| Feature Type \| Doc Location \| Template \|
101	\| ------------------- \| --------------------------------------------------- \| ---------------- \|
102	\| New component \| `docs/01-app/03-api-reference/02-components/` \| API Reference \|
103	\| New function \| `docs/01-app/03-api-reference/04-functions/` \| API Reference \|
104	\| New config option \| `docs/01-app/03-api-reference/05-config/` \| Config Reference \|
105	\| New concept/guide \| `docs/01-app/02-guides/` \| Guide \|
106	\| New file convention \| `docs/01-app/03-api-reference/03-file-conventions/` \| File Convention \|
107
108	### Step 2: Create the file with proper naming
109
110	- Use kebab-case: `my-new-feature.mdx`
111	- Add numeric prefix if ordering matters: `05-my-new-feature.mdx`
112	- Place in the correct directory based on feature type
113
114	### Step 3: Use the appropriate template
115
116	API Reference Template:
117
118	```mdx
119	---
120	title: Feature Name
121	description: Brief description of what this feature does.
122	---
123
124	{/* The content of this doc is shared between the app and pages router. You can use the `<PagesOnly>Content</PagesOnly>` component to add content that is specific to the Pages Router. Any shared content should not b

People who liked this also viewed

6 picks

Type

update-docs

141kstars31kforks

View on GitHub

How to install update-docs?

vercel/next.js/update-docs

$npx -y skills add vercel/next.js --skill update-docs

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Next.js Documentation Updater
2
3	Guides you through updating Next.js documentation based on code changes on the active branch. Designed for maintainers reviewing PRs for documentation completeness.
4
5	## Quick Start
6
7	1. Analyze changes: Run `git diff canary...HEAD --stat` to see what files changed
8	2. Identify affected docs: Map changed source files to documentation paths
9	3. Review each doc: Walk through updates with user confirmation
10	4. Validate: Run `pnpm lint` to check formatting
11	5. Commit: Stage documentation changes
12
13	## Workflow: Analyze Code Changes
14
15	### Step 1: Get the diff
16
17	```bash
18	# See all changed files on this branch
19	git diff canary...HEAD --stat
20
21	# See changes in specific areas
22	git diff canary...HEAD -- packages/next/src/
23	```
24
25	### Step 2: Identify documentation-relevant changes
26
27	Look for changes in these areas:
28
29	\| Source Path \| Likely Doc Impact \|
30	\| -------------------------------------- \| --------------------------- \|
31	\| `packages/next/src/client/components/` \| Component API reference \|
32	\| `packages/next/src/server/` \| Function API reference \|
33	\| `packages/next/src/shared/lib/` \| Varies by export \|
34	\| `packages/next/src/build/` \| Configuration or build docs \|
35	\| `packages/next/src/lib/` \| Various features \|
36
37	### Step 3: Map to documentation files
38
39	Use the code-to-docs mapping in `references/CODE-TO-DOCS-MAPPING.md` to find corresponding documentation files.
40
41	Example mappings:
42
43	- `src/client/components/image.tsx` → `docs/01-app/03-api-reference/02-components/image.mdx`
44	- `src/server/config-shared.ts` → `docs/01-app/03-api-reference/05-config/`
45
46	## Workflow: Update Existing Documentation
47
48	### Step 1: Read the current documentation
49
50	Before making changes, read the existing doc to understand:
51
52	- Current structure and sections
53	- Frontmatter fields in use
54	- Whether it uses `<AppOnly>` / `<PagesOnly>` for router-specific content
55
56	### Step 2: Identify what needs updating
57
58	Common updates include:
59
60	- New props/options: Add to the props table and create a section explaining usage
61	- Changed behavior: Update descriptions and examples
62	- Deprecated features: Add deprecation notices and migration guidance
63	- New examples: Add code blocks following conventions
64
65	### Step 3: Apply updates with confirmation
66
67	For each change:
68
69	1. Show the user what you plan to change
70	2. Wait for confirmation before editing
71	3. Apply the edit
72	4. Move to the next change
73
74	### Step 4: Check for shared content
75
76	If the doc uses the `source` field pattern (common for Pages Router docs), the source file is the one to edit. Example:
77
78	```yaml
79	# docs/02-pages/... file with shared content
80	---
81	source: app/building-your-application/optimizing/images
82	---
83	```
84
85	Edit the App Router source, not the Pages Router file.
86
87	### Step 5: Validate changes
88
89	```bash
90	pnpm lint # Check formatting
91	pnpm prettier-fix # Auto-fix formatting issues
92	```
93
94	## Workflow: Scaffold New Feature Documentation
95
96	Use this when adding documentation for entirely new features.
97
98	### Step 1: Determine the doc type
99
100	\| Feature Type \| Doc Location \| Template \|
101	\| ------------------- \| --------------------------------------------------- \| ---------------- \|
102	\| New component \| `docs/01-app/03-api-reference/02-components/` \| API Reference \|
103	\| New function \| `docs/01-app/03-api-reference/04-functions/` \| API Reference \|
104	\| New config option \| `docs/01-app/03-api-reference/05-config/` \| Config Reference \|
105	\| New concept/guide \| `docs/01-app/02-guides/` \| Guide \|
106	\| New file convention \| `docs/01-app/03-api-reference/03-file-conventions/` \| File Convention \|
107
108	### Step 2: Create the file with proper naming
109
110	- Use kebab-case: `my-new-feature.mdx`
111	- Add numeric prefix if ordering matters: `05-my-new-feature.mdx`
112	- Place in the correct directory based on feature type
113
114	### Step 3: Use the appropriate template
115
116	API Reference Template:
117
118	```mdx
119	---
120	title: Feature Name
121	description: Brief description of what this feature does.
122	---
123
124	{/* The content of this doc is shared between the app and pages router. You can use the `<PagesOnly>Content</PagesOnly>` component to add content that is specific to the Pages Router. Any shared content should not b

People who liked this also viewed

6 picks

Type