From skillry-product-docs-and-research
Use when you need to create clean markdown specifications, implementation docs, repair reports, and handoff packs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/skillry-product-docs-and-research:63-md-spec-generatorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create clean markdown specifications, implementation docs, repair reports, and handoff packs. Every document is execution-oriented — it leads with the outcome the reader must act on, backs every claim with a verified `file:line` reference or a copy-pasteable command, and never relies on assumption. The goal is a document a reader with repo access can act on alone, without re-deriving context or...
Create clean markdown specifications, implementation docs, repair reports, and handoff packs. Every document is execution-oriented — it leads with the outcome the reader must act on, backs every claim with a verified file:line reference or a copy-pasteable command, and never relies on assumption. The goal is a document a reader with repo access can act on alone, without re-deriving context or asking follow-up questions.
file:line), fix applied, and verification result.64-codex-final-execution-prompt for agent-executable prompts, 70-adr-generator for architecture decision records, 69-technical-writing-review for prose-quality review.path:line references and real, copy-pasteable commands. If a fact is unconfirmed, mark it as an open question rather than asserting it.path:line, not a vague "the config file".file:line of the root cause, not just "fixed a bug".# Implementation Spec — <feature>
## Context / Goal / Non-goals
## Acceptance criteria
- [ ] <observable outcome>
- [ ] <observable outcome>
## File-level changes
| File | Change | Why |
|------|--------|-----|
## Steps (ordered; each has a verify command)
1. <change> — verify: `<command>` → <expected result>
## Test plan / Risks / Rollback
# Repair Report — <issue>
## Symptom
Exact error: `<error string>`
## Root cause
`<path:line>` — <what was wrong>
## Fix
<what changed, and why this and not the alternative>
## Commands run + results
- `<command>` → <result>
## Verification
`<gate command>` → green
## Residual risks / Next safe command
# Handoff Pack — <project>
## What it is
## How to run (verified on a clean checkout)
1. `<install>` 2. `<start>`
## Architecture map
## Env vars (names only)
| Name | Purpose | Required |
## Data / migrations / Known issues
## Where things live / What to check next
| The reader needs to… | Produce | Leads with |
|---|---|---|
| Build a feature without asking questions | Implementation spec | Goal + acceptance criteria |
| Understand what a fix changed and trust it | Repair report | Symptom + root cause |
| Take ownership of an unfamiliar project | Handoff pack | How to run, verified |
| Review the result of an audit | Findings doc | Severity-ranked table |
If two needs apply (e.g., a fix plus a handoff), produce two documents rather than blending them — a reader scanning for "how do I run this" should not wade through a root-cause analysis.
A vague note "fixed the login bug" is not a repair report. The execution-grade version:
# Repair Report — login 500 on empty password
## Symptom
POST /auth/login with an empty password returned 500.
Exact error: `TypeError: Cannot read properties of undefined (reading 'compare')`.
## Root cause
`api/auth.ts:31` — `bcrypt.compare(input, user.hash)` ran before the
empty-input guard, and `user` was undefined for an unknown email.
## Fix
Moved the input + user-existence guard above the bcrypt call, returning
401 for both bad email and bad password (avoids user enumeration).
Chosen over try/catch because the 500 masked a real validation gap.
## Commands run + results
- `npm test -- auth` → 14 passed (added 2 cases: empty pw, unknown email)
## Verification
`npm run typecheck && npm test -- auth` → green
## Residual risks / Next safe command
Rate-limiting on /auth/login is still absent — track separately.
Every line points at evidence: the exact error string, the file:line, the test that now covers it, and the green gate. A reviewer can trust it without re-deriving anything.
config/app.ts:42. The reader should not have to hunt.DATABASE_URL instead of naming the variable. Names only.npm run deploy:prod that does not exist in package.json. Every command must be real.Return the finished Markdown document(s) using the matching skeleton, plus a one-line note on what evidence backs the key claims (which command ran, which files were read). Keep it self-contained: a reader with repo access could execute or take over from it directly.
Done means the right document type was produced from real evidence, it leads with outcome and is fully scannable, every claim is verifiable via a named command/file/test, secrets are redacted, and the reader could act from it alone.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub fluxonlab/skillry --plugin skillry-product-docs-and-research