You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .claude/skills/editor/SKILL.md
+36-2Lines changed: 36 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -115,6 +115,8 @@ See `references/simplified-technical-english.md` → Voice Guidelines + Verb Ten
115
115
116
116
Check for: non-parallel heading structure at same level, inconsistent list punctuation, dashes instead of colons after bold labels (`**Label**:` not `**Label** -`), inline lists where bullet lists would be clearer.
117
117
118
+
**Exception — UI/product names**: If a heading uses the exact name of a product feature or UI element, do not flag it for breaking parallelism. Feature names take precedence over grammatical consistency. Example: `## Sharing paid access between user accounts` is the name of the feature in the UI — do not rewrite it to fix parallel structure.
119
+
118
120
See `references/article-structure.md` → Parallel Heading Structure + List Formatting
✅ "To create a paywall, in the Paywalls section, click **Create paywall**"
125
127
❌ "Click **Create paywall** to create a paywall in the Paywalls section"
126
128
129
+
**Do not over-granularize**: A short inline instruction (2–3 steps expressible in one clear sentence) should stay inline. Breaking it into a numbered list introduces unnecessary friction. Use numbered steps only when: (a) the sequence has 4+ distinct actions, (b) each step requires separate verification, or (c) the sentence becomes unreadably long. Conciseness takes priority — do not flag a clear one-sentence instruction as a problem.
130
+
127
131
See `references/simplified-technical-english.md` → Instruction Pattern
128
132
129
133
### 8. Article Structure
@@ -134,9 +138,21 @@ See `references/article-structure.md`
134
138
135
139
### 9. Links and Images
136
140
137
-
**Diff reviews** (check only added items): existing pages, correct relative paths, anchor slugs lowercase-hyphenated, image files exist, `@assets/` not `@asset/`, descriptive alt text.
141
+
Run the link checker in diff mode to validate links automatically:
142
+
143
+
```bash
144
+
npm run check-links-diff
145
+
```
146
+
147
+
This checks outgoing links from changed files AND incoming links to changed files (catches breakage from renamed files or removed headings). Reports are written to `_temp/link-report.md` and `_temp/link-report.html`.
138
148
139
-
**Full article reviews**: validate ALL links and images.
149
+
After the script finishes, read `_temp/link-report.md` and include a summary in your review output. Report only **broken links** (errors) and **stale links** (warnings) — skip the "manual check" category. If issues were found, tell the user they can open the full HTML report:
150
+
151
+
```
152
+
open _temp/link-report.html
153
+
```
154
+
155
+
Additionally check images manually: image files exist, `@assets/` not `@asset/`, descriptive alt text.
140
156
141
157
See `references/astro-patterns.md`
142
158
@@ -168,6 +184,24 @@ For each issue: quote the text (with line number) → explain why → provide sp
168
184
169
185
See `references/output-templates.md` for annotated feedback example.
170
186
187
+
### Interactive Review Flow
188
+
189
+
After completing all checks, follow this flow:
190
+
191
+
1.**Number every finding** sequentially across all categories (Critical, Important, Suggestions). Assign a single global number to each, not per-category numbers.
192
+
193
+
2.**Present the full numbered list** as a concise "whole picture" — one line per finding, format: `**N.** [article if multiple] brief description → proposed fix`
194
+
195
+
3.**Ask before proceeding**: *"Here are all [N] findings. Would you like to go through them interactively, deciding which to accept?"* — wait for the answer.
196
+
197
+
4.**If yes — use `AskUserQuestion`**, 4 suggestions at a time:
198
+
- Question label (header, max 12 chars): `#N Topic`
Copy file name to clipboardExpand all lines: .claude/skills/product-manager/SKILL.md
+18Lines changed: 18 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -146,6 +146,24 @@ Start every review with **Persona Usage Analysis**, then:
146
146
147
147
See [`feedback-example.md`](references/feedback-example.md) for a complete annotated example.
148
148
149
+
### Interactive Review Flow
150
+
151
+
When both editor and product-manager reviews are combined in one session, a single shared numbered list is produced. When used alone, follow the same flow:
152
+
153
+
1.**Number every actionable finding** sequentially across all categories. Each finding gets one global number.
154
+
155
+
2.**Present the full numbered list** as a concise "whole picture" — one line per finding, format: `**N.** [article if multiple] brief description → proposed fix`
156
+
157
+
3.**Ask before proceeding**: *"Here are all [N] findings. Would you like to go through them interactively, deciding which to accept?"* — wait for the answer.
158
+
159
+
4.**If yes — use `AskUserQuestion`**, 4 suggestions at a time:
160
+
- Question label (header, max 12 chars): `#N Topic`
Copy file name to clipboardExpand all lines: CLAUDE.md
+24Lines changed: 24 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -164,3 +164,27 @@ These are layout/interactive components in `src/components/`, not imported by ar
164
164
## Reference
165
165
166
166
Comprehensive component examples and writing guidelines: `TECH_WRITERS_README.md`
167
+
168
+
## Design Context
169
+
170
+
### Users
171
+
Mobile developers (iOS, Android, React Native, Flutter, Unity, KMP, Capacitor) integrating Adapty's in-app purchase and subscription SDK. Technical, time-conscious, task-focused — they arrive to find an answer and get unblocked.
172
+
173
+
### Brand Personality
174
+
**Reliable, clean, developer-first.** Direct and precise. No marketing fluff. Trust is earned by making the right answer obvious and getting out of the developer's way.
175
+
176
+
### Emotional Goals
177
+
Developers should feel **confident** (know exactly what to do), **fast** (find things without hunting), and **welcomed** (smooth onboarding, low barrier to entry).
178
+
179
+
### Reference
180
+
**Stripe Docs** — authoritative, information-dense but scannable, strong typographic hierarchy, no decoration for decoration's sake.
181
+
182
+
### Anti-References
183
+
No heavy animations, neon gradients, or glassmorphism. No generic corporate feel. No cluttered sidebars or competing CTAs. No playful/toy-like UI — this is a technical reference.
184
+
185
+
### Design Principles
186
+
1. **Clarity over cleverness** — every decision serves comprehension, nothing else
187
+
2. **Scannability first** — headers, code blocks, callouts, and step numbers are navigation anchors
188
+
3. **Trust through restraint** — one brand color (`#6720ff`), subtle shadows, consistent spacing
189
+
4. **Code is first-class** — code blocks, syntax highlighting, copy buttons must be beautiful in both themes
190
+
5. **Dark mode is equal, not secondary** — full design target, no contrast or legibility compromises
0 commit comments