// Use when documentation needs to be planned and written end-to-end — from a Jira task, feature spec, or verbal description through to a polished draft. Not for review-only or planning-only tasks.
Use when adding support for a new locale/language to the Adapty docs site. Covers all hardcoded and dynamic locale registration points, translation commands, sitemap setup, Algolia search config, and the step-by-step order to follow.
Use when reviewing documentation from a product perspective — whether feature value is clear, onboarding flow makes sense, or technical descriptions align with real user experience. Does not check writing style.
Use when adding a new monthly section to src/content/docs/release-notes/whats-new.mdx — gathers commits to main over a date range, identifies user-facing updates worth featuring, confirms scope with the user, then drafts the section in the existing style.
Use when finishing work on a feature branch and wanting to promote it to develop (or another integration branch) while staying on the original branch. Handles commit, push, merge, push develop, and return.
Use when reviewing or writing MDX files in src/content/docs — proofreading, checking technical writing quality, verifying Simplified Technical English compliance, validating links and images, or drafting new doc content.
Walk through unresolved GitHub PR review comments one by one, suggest fixes, and track resolution in a local file. Use when the user wants to address PR feedback.
| name | doc-author |
| description | Use when documentation needs to be planned and written end-to-end — from a Jira task, feature spec, or verbal description through to a polished draft. Not for review-only or planning-only tasks. |
Manage the full lifecycle of a documentation task by coordinating specialized skills. Accept any input — a Jira task, feature spec, verbal description, or development task — and produce a reviewed, polished draft.
This skill orchestrates other skills. It does NOT duplicate their logic. Each phase invokes the appropriate skill and passes its output to the next phase. When a skill produces output, trust it and build on it — don't redo its work.
Accept any of these as a starting input:
If the input is too vague to determine what changed, who it affects, or where it lives in the product — ask clarifying questions before proceeding. Otherwise, move to Phase 1.
Rule: Each phase invokes a sub-skill via the Skill tool. Never substitute your own knowledge for an invoked skill — trust the skill's output and build on it.
writing-plannerREQUIRED SUB-SKILL: Use the Skill tool to invoke writing-planner.
The writing-planner will:
Your role in this phase:
Do NOT proceed to Phase 2 until the user explicitly approves the plan.
After approval, ask the user: "Ready to start drafting, or do you want to adjust anything first?"
editorREQUIRED SUB-SKILL: Use the Skill tool to invoke editor in write mode.
Pass the approved plan as input. The editor will:
Your role in this phase:
snippet-master. See "Code snippets" below.product-managerREQUIRED SUB-SKILL: Use the Skill tool to invoke product-manager.
The product-manager will evaluate:
Your role in this phase:
Present the draft and ask for feedback. The user may:
Repeat this phase until the user approves.
If user feedback at any phase contradicts a skill's instructions, evaluate whether the feedback represents:
A one-off preference (don't update the skill):
A reproducible pattern (update the skill):
When updating a skill:
@ syntax)adapty-product-knowledge.md), update that file instead of the main SKILL.mdsuperpowers:writing-skills to guide the update properlyEach skill has deep expertise. Don't second-guess the writing-planner's scope assessment, the editor's STE compliance, or the product-manager's persona analysis. Trust their output and focus on stitching phases together.
If the writing-planner assesses a "small update" but the user's feedback keeps expanding scope, flag it: "This has grown beyond the original small update scope. Want me to re-plan as a medium update?" Re-invoke writing-planner if needed.
For tasks affecting multiple articles, the writing-planner will produce a multi-article plan with execution order. Follow that order. Draft each article separately through Phases 2-4, completing one before starting the next (unless the user prefers parallel drafting).
When the plan or draft calls for code snippets, use the Skill tool to invoke snippet-master. REQUIRED SUB-SKILL: snippet-master handles SDK code across all 7 platforms (iOS, Android, React Native, Flutter, Unity, Kotlin Multiplatform, Capacitor) — don't write snippets yourself.