@damenor/agent-docs 0.1.0 → 0.1.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +141 -71
- package/dist/index.js +259 -13
- package/package.json +11 -11
- package/templates/base/README.md +64 -69
- package/templates/base/docs/CONTEXT.md +111 -111
- package/templates/modules/agents/.agents/skills/doc-maintain/SKILL.md +193 -193
- package/templates/modules/agents/.agents/skills/doc-review/SKILL.md +223 -223
- package/templates/modules/agents/.agents/skills/doc-scaffold/SKILL.md +155 -155
- package/templates/modules/agents/.agents/skills/doc-write/SKILL.md +197 -197
|
@@ -1,13 +1,13 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: doc-write
|
|
3
3
|
description: >
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
TRIGGER:
|
|
9
|
-
"
|
|
10
|
-
|
|
4
|
+
Writes documentation following Diátaxis + ADR + CONTEXT conventions.
|
|
5
|
+
Classifies content by type before writing, generates ADRs when applicable,
|
|
6
|
+
and keeps CONTEXT.md updated. All content in English with technical
|
|
7
|
+
terms kept in English.
|
|
8
|
+
TRIGGER: When the user says "write doc", "document X", "create ADR",
|
|
9
|
+
"update CONTEXT", "new documentation", or any documentation file
|
|
10
|
+
needs to be created/updated.
|
|
11
11
|
license: Apache-2.0
|
|
12
12
|
metadata:
|
|
13
13
|
author: damenordev
|
|
@@ -16,60 +16,60 @@ metadata:
|
|
|
16
16
|
|
|
17
17
|
# doc-write
|
|
18
18
|
|
|
19
|
-
##
|
|
19
|
+
## When to Use
|
|
20
20
|
|
|
21
|
-
- **
|
|
22
|
-
- **
|
|
23
|
-
- **
|
|
24
|
-
- **
|
|
25
|
-
- **
|
|
26
|
-
- **Post-feature**:
|
|
21
|
+
- **Create new documentation**: Any doc file that needs to be generated
|
|
22
|
+
- **Update existing documentation**: Modify docs that are outdated
|
|
23
|
+
- **Write ADRs**: Document significant architectural decisions
|
|
24
|
+
- **Update CONTEXT.md**: Add domain terms that emerged
|
|
25
|
+
- **Update docs/README.md**: Reflect changes in the documentation map
|
|
26
|
+
- **Post-feature**: After implementing a feature that needs documentation
|
|
27
27
|
|
|
28
|
-
##
|
|
28
|
+
## Critical Patterns
|
|
29
29
|
|
|
30
|
-
###
|
|
30
|
+
### RULE #1: Classify by Diátaxis BEFORE writing
|
|
31
31
|
|
|
32
|
-
|
|
32
|
+
Always determine the type BEFORE starting to write:
|
|
33
33
|
|
|
34
34
|
```
|
|
35
|
-
1.
|
|
36
|
-
├──
|
|
37
|
-
├──
|
|
38
|
-
├──
|
|
39
|
-
└──
|
|
35
|
+
1. What does the reader need?
|
|
36
|
+
├── Learn something new → Tutorial
|
|
37
|
+
├── Solve a problem → How-to
|
|
38
|
+
├── Look up information → Reference
|
|
39
|
+
└── Understand the why → Explanation
|
|
40
40
|
|
|
41
|
-
2.
|
|
41
|
+
2. Is it an architectural decision? → ADR (check criteria)
|
|
42
42
|
|
|
43
|
-
3.
|
|
43
|
+
3. Is it a domain term? → CONTEXT.md
|
|
44
44
|
```
|
|
45
45
|
|
|
46
|
-
###
|
|
46
|
+
### RULE #2: ADRs — Only when all 3 criteria are met
|
|
47
47
|
|
|
48
|
-
|
|
48
|
+
An ADR is written ONLY when ALL these conditions are true:
|
|
49
49
|
|
|
50
|
-
1. **
|
|
51
|
-
2. **
|
|
52
|
-
3. **
|
|
50
|
+
1. **Hard to reverse**: Changing this decision would have high cost (time, money, data)
|
|
51
|
+
2. **Surprising**: A newcomer would not expect this decision or would need context
|
|
52
|
+
3. **Real trade-off**: There are valid alternatives with genuine pros/cons
|
|
53
53
|
|
|
54
|
-
**
|
|
54
|
+
**If any criterion fails, it is NOT an ADR.**
|
|
55
55
|
|
|
56
|
-
|
|
56
|
+
See [ADR Format](references/adr-format.md) for full details.
|
|
57
57
|
|
|
58
|
-
###
|
|
58
|
+
### RULE #3: CONTEXT.md — Add terms when they emerge
|
|
59
59
|
|
|
60
|
-
-
|
|
61
|
-
-
|
|
62
|
-
-
|
|
63
|
-
-
|
|
60
|
+
- Add new terms when they appear in code or conversations
|
|
61
|
+
- Mark ambiguous terms with `⚠️ AMBIGUOUS`
|
|
62
|
+
- Show relationships between terms (`→`, `←→`, `part-of`)
|
|
63
|
+
- Do not repeat what is already in reference — only domain terms
|
|
64
64
|
|
|
65
|
-
###
|
|
65
|
+
### RULE #4: Update docs/README.md when adding files
|
|
66
66
|
|
|
67
|
-
|
|
68
|
-
-
|
|
69
|
-
-
|
|
70
|
-
-
|
|
67
|
+
The documentation map must always reflect reality:
|
|
68
|
+
- Add new entries when files are created
|
|
69
|
+
- Mark entries of deleted files as obsolete
|
|
70
|
+
- Update descriptions if content changed significantly
|
|
71
71
|
|
|
72
|
-
###
|
|
72
|
+
### RULE #5: YAML frontmatter required
|
|
73
73
|
|
|
74
74
|
```yaml
|
|
75
75
|
---
|
|
@@ -81,37 +81,37 @@ tags: [tag1, tag2, tag3]
|
|
|
81
81
|
---
|
|
82
82
|
```
|
|
83
83
|
|
|
84
|
-
|
|
84
|
+
No `owner`. Always include `updated` when modifying.
|
|
85
85
|
|
|
86
|
-
###
|
|
86
|
+
### RULE #6: DUAL audience — humans AND AI agents
|
|
87
87
|
|
|
88
|
-
|
|
89
|
-
- **
|
|
90
|
-
- **
|
|
88
|
+
Write for:
|
|
89
|
+
- **Humans**: Clarity, examples, logical flow
|
|
90
|
+
- **AI agents**: Consistent structure, terms defined in CONTEXT.md, clear cross-references
|
|
91
91
|
|
|
92
|
-
###
|
|
92
|
+
### RULE #7: Content in English
|
|
93
93
|
|
|
94
94
|
```
|
|
95
|
-
✅ "
|
|
96
|
-
✅ "
|
|
97
|
-
✅ "
|
|
95
|
+
✅ "To configure the authentication middleware..."
|
|
96
|
+
✅ "The endpoint /api/users returns an array of objects..."
|
|
97
|
+
✅ "The Button component accepts the `variant` prop..."
|
|
98
98
|
```
|
|
99
99
|
|
|
100
|
-
###
|
|
100
|
+
### RULE #8: NEVER create placeholder/TODO content
|
|
101
101
|
|
|
102
102
|
```
|
|
103
|
-
❌
|
|
104
|
-
❌
|
|
105
|
-
✅
|
|
103
|
+
❌ BAD: "TODO: add examples" — better NOT to create the file
|
|
104
|
+
❌ BAD: "Content pending writing" — better NOT to create the file
|
|
105
|
+
✅ GOOD: Write real and complete content, or do not create the file
|
|
106
106
|
```
|
|
107
107
|
|
|
108
|
-
##
|
|
108
|
+
## Guides by Type
|
|
109
109
|
|
|
110
110
|
### Tutorial
|
|
111
111
|
|
|
112
|
-
**
|
|
112
|
+
**Orientation**: Learning — the user learns by doing
|
|
113
113
|
|
|
114
|
-
**
|
|
114
|
+
**Structure**:
|
|
115
115
|
```markdown
|
|
116
116
|
---
|
|
117
117
|
created: "..."
|
|
@@ -120,37 +120,37 @@ type: tutorial
|
|
|
120
120
|
tags: [...]
|
|
121
121
|
---
|
|
122
122
|
|
|
123
|
-
# [
|
|
123
|
+
# [Descriptive title of the learning goal]
|
|
124
124
|
|
|
125
|
-
##
|
|
126
|
-
[
|
|
125
|
+
## What you will build
|
|
126
|
+
[Description of the end result — 2-3 lines]
|
|
127
127
|
|
|
128
|
-
##
|
|
129
|
-
[
|
|
128
|
+
## Prerequisites
|
|
129
|
+
[Concrete list of what is needed before starting]
|
|
130
130
|
|
|
131
|
-
##
|
|
132
|
-
[
|
|
133
|
-
### ✅
|
|
134
|
-
[
|
|
131
|
+
## Step 1: [Concrete action]
|
|
132
|
+
[Instructions + code]
|
|
133
|
+
### ✅ Verification
|
|
134
|
+
[How to confirm the step worked]
|
|
135
135
|
|
|
136
|
-
##
|
|
136
|
+
## Step 2: [Concrete action]
|
|
137
137
|
...
|
|
138
138
|
|
|
139
|
-
##
|
|
140
|
-
[
|
|
139
|
+
## Summary
|
|
140
|
+
[What was learned, what's next]
|
|
141
141
|
```
|
|
142
142
|
|
|
143
|
-
**
|
|
143
|
+
**Tone**: Didactic, patient. One concept at a time. Verify understanding at each step.
|
|
144
144
|
|
|
145
|
-
**
|
|
145
|
+
**Length**: 500-2000 words. If longer, split into sequential tutorials.
|
|
146
146
|
|
|
147
|
-
**
|
|
147
|
+
**Do not include**: Deep explanations of why (that is explanation), reference other docs.
|
|
148
148
|
|
|
149
|
-
### How-to (
|
|
149
|
+
### How-to (Practical guide)
|
|
150
150
|
|
|
151
|
-
**
|
|
151
|
+
**Orientation**: Solve a problem — the user already has prior knowledge
|
|
152
152
|
|
|
153
|
-
**
|
|
153
|
+
**Structure**:
|
|
154
154
|
```markdown
|
|
155
155
|
---
|
|
156
156
|
created: "..."
|
|
@@ -159,29 +159,29 @@ type: how-to
|
|
|
159
159
|
tags: [...]
|
|
160
160
|
---
|
|
161
161
|
|
|
162
|
-
#
|
|
162
|
+
# How to [solve specific problem]
|
|
163
163
|
|
|
164
|
-
##
|
|
165
|
-
[1-2
|
|
164
|
+
## When to use this
|
|
165
|
+
[1-2 lines describing the scenario]
|
|
166
166
|
|
|
167
|
-
##
|
|
168
|
-
1. [
|
|
169
|
-
2. [
|
|
167
|
+
## Steps
|
|
168
|
+
1. [Direct action with code]
|
|
169
|
+
2. [Direct action with code]
|
|
170
170
|
...
|
|
171
171
|
|
|
172
|
-
##
|
|
173
|
-
[
|
|
172
|
+
## Expected result
|
|
173
|
+
[What should be seen/working at the end]
|
|
174
174
|
```
|
|
175
175
|
|
|
176
|
-
**
|
|
176
|
+
**Tone**: Direct, no fluff. Assume the reader knows the system. Do not explain basic concepts.
|
|
177
177
|
|
|
178
|
-
**
|
|
178
|
+
**When to split**: If it has more than 10 steps or covers more than one problem, split into multiple how-tos.
|
|
179
179
|
|
|
180
|
-
###
|
|
180
|
+
### Reference
|
|
181
181
|
|
|
182
|
-
**
|
|
182
|
+
**Orientation**: Factual information — the user looks up a specific piece of data
|
|
183
183
|
|
|
184
|
-
**
|
|
184
|
+
**Structure**:
|
|
185
185
|
```markdown
|
|
186
186
|
---
|
|
187
187
|
created: "..."
|
|
@@ -190,29 +190,29 @@ type: reference
|
|
|
190
190
|
tags: [...]
|
|
191
191
|
---
|
|
192
192
|
|
|
193
|
-
# [
|
|
193
|
+
# [Name of the API/system/interface]
|
|
194
194
|
|
|
195
|
-
## [
|
|
195
|
+
## [Main section — endpoints, methods, props, etc.]
|
|
196
196
|
|
|
197
|
-
|
|
|
198
|
-
|
|
199
|
-
| ...
|
|
197
|
+
| Name | Type | Description | Default |
|
|
198
|
+
|------|------|-------------|---------|
|
|
199
|
+
| ... | ... | ... | ... |
|
|
200
200
|
|
|
201
|
-
##
|
|
202
|
-
[
|
|
201
|
+
## Examples
|
|
202
|
+
[Minimal code for each main use case]
|
|
203
203
|
```
|
|
204
204
|
|
|
205
|
-
**
|
|
205
|
+
**Tone**: Neutral, factual, no narrative. Tables and lists over prose.
|
|
206
206
|
|
|
207
|
-
**
|
|
207
|
+
**What to include**: ALL parameters, ALL possible values, ALL edge cases.
|
|
208
208
|
|
|
209
|
-
**
|
|
209
|
+
**What NOT to include**: Explanations of why, usage tutorials, narrative.
|
|
210
210
|
|
|
211
|
-
###
|
|
211
|
+
### Explanation
|
|
212
212
|
|
|
213
|
-
**
|
|
213
|
+
**Orientation**: Understanding — the user wants to understand the why
|
|
214
214
|
|
|
215
|
-
**
|
|
215
|
+
**Structure**:
|
|
216
216
|
```markdown
|
|
217
217
|
---
|
|
218
218
|
created: "..."
|
|
@@ -221,49 +221,49 @@ type: explanation
|
|
|
221
221
|
tags: [...]
|
|
222
222
|
---
|
|
223
223
|
|
|
224
|
-
# [
|
|
224
|
+
# [Topic being explained]
|
|
225
225
|
|
|
226
|
-
##
|
|
227
|
-
[
|
|
226
|
+
## Context
|
|
227
|
+
[Why this exists, what problem it solves]
|
|
228
228
|
|
|
229
|
-
##
|
|
230
|
-
[
|
|
229
|
+
## How it works
|
|
230
|
+
[Overview without going into code]
|
|
231
231
|
|
|
232
|
-
##
|
|
233
|
-
[
|
|
232
|
+
## Alternatives considered
|
|
233
|
+
[What other options existed and why this was chosen]
|
|
234
234
|
|
|
235
|
-
##
|
|
236
|
-
[
|
|
235
|
+
## Implications
|
|
236
|
+
[What this decision means for the future]
|
|
237
237
|
```
|
|
238
238
|
|
|
239
|
-
**
|
|
239
|
+
**Tone**: Discursive, analytical. Connect to ADRs when applicable (`docs/adr/001-*.md`).
|
|
240
240
|
|
|
241
|
-
**
|
|
241
|
+
**When needed**: When an ADR needs more context than fits in the minimal format, or when a concept is referenced repeatedly in how-tos and tutorials.
|
|
242
242
|
|
|
243
|
-
##
|
|
243
|
+
## ADR Guides
|
|
244
244
|
|
|
245
|
-
###
|
|
245
|
+
### Strict criteria (all 3 must be met)
|
|
246
246
|
|
|
247
|
-
1. **
|
|
248
|
-
2. **
|
|
249
|
-
3. **
|
|
247
|
+
1. **Hard to reverse**: The change has high cost if reversed
|
|
248
|
+
2. **Surprising**: Someone new wouldn't expect it or would ask "why?"
|
|
249
|
+
3. **Real trade-off**: There are genuine alternatives with advantages and disadvantages
|
|
250
250
|
|
|
251
|
-
###
|
|
251
|
+
### What qualifies as an ADR
|
|
252
252
|
|
|
253
|
-
-
|
|
254
|
-
-
|
|
255
|
-
-
|
|
256
|
-
-
|
|
257
|
-
-
|
|
258
|
-
-
|
|
253
|
+
- Architecture shape (monolith vs microservices, layered vs hexagonal)
|
|
254
|
+
- Integration patterns (sync vs async, REST vs GraphQL vs gRPC)
|
|
255
|
+
- Technology lock-in (database, cloud provider, core library)
|
|
256
|
+
- Boundary decisions (what goes inside vs outside the service)
|
|
257
|
+
- Deliberate deviations (when a convention is broken on purpose)
|
|
258
|
+
- Invisible constraints (non-obvious limitations of the stack or domain)
|
|
259
259
|
|
|
260
|
-
###
|
|
260
|
+
### What does NOT qualify as an ADR
|
|
261
261
|
|
|
262
|
-
-
|
|
263
|
-
-
|
|
264
|
-
-
|
|
262
|
+
- Obvious choices (using Git, using testing)
|
|
263
|
+
- Easy to reverse (renaming a variable, moving a file)
|
|
264
|
+
- No real alternatives (no other reasonable option)
|
|
265
265
|
|
|
266
|
-
###
|
|
266
|
+
### Minimal ADR format
|
|
267
267
|
|
|
268
268
|
```markdown
|
|
269
269
|
---
|
|
@@ -271,75 +271,75 @@ created: "2026-05-07"
|
|
|
271
271
|
updated: "2026-05-07"
|
|
272
272
|
status: proposed | accepted | deprecated | superseded
|
|
273
273
|
type: adr
|
|
274
|
-
tags: [
|
|
274
|
+
tags: [architecture, decision]
|
|
275
275
|
---
|
|
276
276
|
|
|
277
|
-
# ADR-001: [
|
|
277
|
+
# ADR-001: [Brief title of the decision]
|
|
278
278
|
|
|
279
|
-
[1-3
|
|
280
|
-
No
|
|
279
|
+
[1-3 sentences explaining the decision, the why, and the alternatives considered.
|
|
280
|
+
No more than one paragraph. If more context is needed, create a linked explanation/]
|
|
281
281
|
```
|
|
282
282
|
|
|
283
|
-
**
|
|
283
|
+
**Real example**:
|
|
284
284
|
|
|
285
285
|
```markdown
|
|
286
|
-
# ADR-002:
|
|
286
|
+
# ADR-002: Use PostgreSQL with Prisma ORM
|
|
287
287
|
|
|
288
|
-
|
|
289
|
-
|
|
290
|
-
TypeScript.
|
|
291
|
-
|
|
288
|
+
We chose PostgreSQL + Prisma as the data layer because the project needs
|
|
289
|
+
complex relationships between entities and Prisma provides type-safety in
|
|
290
|
+
TypeScript. MongoDB + Mongoose was considered (rejected due to frequent joins
|
|
291
|
+
needed) and raw SQL (rejected due to losing type-safety).
|
|
292
292
|
```
|
|
293
293
|
|
|
294
|
-
|
|
294
|
+
See [ADR Format](references/adr-format.md) for complete reference.
|
|
295
295
|
|
|
296
|
-
##
|
|
296
|
+
## Cross-References
|
|
297
297
|
|
|
298
|
-
|
|
298
|
+
Use wikilinks where helpful:
|
|
299
299
|
|
|
300
300
|
```markdown
|
|
301
|
-
|
|
302
|
-
|
|
303
|
-
|
|
301
|
+
See [[CONTEXT]] for domain term definitions.
|
|
302
|
+
Related to [[ADR-001-event-sourcing]].
|
|
303
|
+
For practical steps, see [[how-to/add-new-endpoint]].
|
|
304
304
|
```
|
|
305
305
|
|
|
306
|
-
##
|
|
306
|
+
## Writing Process
|
|
307
307
|
|
|
308
308
|
```
|
|
309
|
-
1.
|
|
310
|
-
2.
|
|
311
|
-
3.
|
|
312
|
-
4.
|
|
313
|
-
5.
|
|
314
|
-
6.
|
|
315
|
-
7.
|
|
316
|
-
8.
|
|
309
|
+
1. Identify WHAT needs to be documented
|
|
310
|
+
2. Classify by Diátaxis (tutorial/how-to/reference/explanation) or ADR
|
|
311
|
+
3. Verify a file for the same content does not already exist
|
|
312
|
+
4. Write with the format and tone corresponding to the type
|
|
313
|
+
5. Add YAML frontmatter
|
|
314
|
+
6. Update docs/README.md if it is a new file
|
|
315
|
+
7. Update docs/CONTEXT.md if there are new terms
|
|
316
|
+
8. Verify the content is real (no placeholders)
|
|
317
317
|
```
|
|
318
318
|
|
|
319
|
-
##
|
|
319
|
+
## Commands
|
|
320
320
|
|
|
321
|
-
###
|
|
321
|
+
### Pre-writing verification
|
|
322
322
|
|
|
323
323
|
```
|
|
324
|
-
1.
|
|
325
|
-
2.
|
|
326
|
-
3.
|
|
327
|
-
4.
|
|
324
|
+
1. Does a file for this content already exist? → Search in docs/README.md
|
|
325
|
+
2. Is the type correct? → Verify with Diátaxis decision tree
|
|
326
|
+
3. Are there new domain terms? → Prepare entry for CONTEXT.md
|
|
327
|
+
4. Does it need an ADR? → Check the 3 criteria
|
|
328
328
|
```
|
|
329
329
|
|
|
330
|
-
###
|
|
330
|
+
### Post-writing verification
|
|
331
331
|
|
|
332
332
|
```
|
|
333
|
-
1.
|
|
334
|
-
2.
|
|
335
|
-
3.
|
|
336
|
-
4.
|
|
337
|
-
5.
|
|
333
|
+
1. Does it have YAML frontmatter? → status, type, tags, created
|
|
334
|
+
2. Is it in the correct folder? → tutorials/, how-to/, reference/, explanation/, docs/adr/
|
|
335
|
+
3. Does docs/README.md reflect the new file? → Update map
|
|
336
|
+
4. Does CONTEXT.md have the new terms? → Add if applicable
|
|
337
|
+
5. Is the content real? → No TODO, no placeholder, no empty sections
|
|
338
338
|
```
|
|
339
339
|
|
|
340
|
-
##
|
|
340
|
+
## Real Examples by Type
|
|
341
341
|
|
|
342
|
-
### Tutorial —
|
|
342
|
+
### Tutorial — Output example
|
|
343
343
|
|
|
344
344
|
```markdown
|
|
345
345
|
---
|
|
@@ -350,37 +350,37 @@ type: tutorial
|
|
|
350
350
|
tags: [auth, jwt, onboarding]
|
|
351
351
|
---
|
|
352
352
|
|
|
353
|
-
#
|
|
353
|
+
# Implement JWT Authentication
|
|
354
354
|
|
|
355
|
-
##
|
|
356
|
-
|
|
355
|
+
## What you will build
|
|
356
|
+
A complete login/registration flow with JWT and refresh tokens.
|
|
357
357
|
|
|
358
|
-
##
|
|
359
|
-
-
|
|
360
|
-
-
|
|
358
|
+
## Prerequisites
|
|
359
|
+
- Project running locally (see [[tutorials/quick-start]])
|
|
360
|
+
- Basic knowledge of HTTP headers
|
|
361
361
|
|
|
362
|
-
##
|
|
362
|
+
## Step 1: Install dependencies
|
|
363
363
|
|
|
364
364
|
```bash
|
|
365
365
|
npm install jsonwebtoken bcryptjs
|
|
366
366
|
npm install -D @types/jsonwebtoken @types/bcryptjs
|
|
367
367
|
```
|
|
368
368
|
|
|
369
|
-
### ✅
|
|
369
|
+
### ✅ Verification
|
|
370
370
|
```bash
|
|
371
371
|
npm ls jsonwebtoken
|
|
372
372
|
# → jsonwebtoken@9.0.2
|
|
373
373
|
```
|
|
374
374
|
|
|
375
|
-
##
|
|
376
|
-
...[
|
|
375
|
+
## Step 2: Create the auth service
|
|
376
|
+
...[steps with real code]
|
|
377
377
|
|
|
378
|
-
##
|
|
379
|
-
|
|
380
|
-
|
|
378
|
+
## Summary
|
|
379
|
+
You learned to implement JWT with refresh tokens.
|
|
380
|
+
Next: [[guides/how-to-protect-routes]]
|
|
381
381
|
```
|
|
382
382
|
|
|
383
|
-
### How-to —
|
|
383
|
+
### How-to — Output example
|
|
384
384
|
|
|
385
385
|
```markdown
|
|
386
386
|
---
|
|
@@ -391,24 +391,24 @@ type: how-to
|
|
|
391
391
|
tags: [deployment, vercel, production]
|
|
392
392
|
---
|
|
393
393
|
|
|
394
|
-
#
|
|
394
|
+
# How to deploy to production
|
|
395
395
|
|
|
396
|
-
##
|
|
397
|
-
|
|
396
|
+
## When to use this
|
|
397
|
+
When an approved feature in staging is ready for production.
|
|
398
398
|
|
|
399
|
-
##
|
|
400
|
-
1.
|
|
401
|
-
2.
|
|
402
|
-
3.
|
|
403
|
-
4. Vercel
|
|
404
|
-
5.
|
|
399
|
+
## Steps
|
|
400
|
+
1. Create PR from `develop` to `main`
|
|
401
|
+
2. Wait for CI to pass (lint + test + build)
|
|
402
|
+
3. Squash merge
|
|
403
|
+
4. Vercel auto-deploys from `main`
|
|
404
|
+
5. Verify at https://[domain]
|
|
405
405
|
|
|
406
406
|
## Rollback
|
|
407
|
-
|
|
407
|
+
If something fails: Vercel Dashboard → Deployments → "Promote to Production" on the previous deploy
|
|
408
408
|
```
|
|
409
409
|
|
|
410
|
-
##
|
|
410
|
+
## Resources
|
|
411
411
|
|
|
412
|
-
- [Diátaxis Patterns](references/diataxis-patterns.md) —
|
|
413
|
-
- [ADR Format](references/adr-format.md) —
|
|
414
|
-
-
|
|
412
|
+
- [Diátaxis Patterns](references/diataxis-patterns.md) — Detailed patterns by type with examples
|
|
413
|
+
- [ADR Format](references/adr-format.md) — Complete ADR format reference
|
|
414
|
+
- Related skills: `doc-scaffold` (initialize docs), `doc-review` (audit docs), `doc-maintain` (keep docs synced), `doc-design` (design system)
|