skills/writing/SKILL.md
Write product artifacts clearly — tickets, PRDs, project updates, and architecture decision records
npx skillsauth add athal7/dotfiles writingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Given a writing task, identify the right document type, read the relevant template, and apply it.
| Type | When to use | File |
|------|-------------|------|
| Ticket / Issue | Capturing a scoped unit of work — bug, feature, task, spike | templates/ticket.md |
| PRD | Defining a feature or product area before implementation begins | templates/prd.md |
| Project update | Communicating project status to stakeholders (weekly, milestone, etc.) | templates/project-update.md |
| ADR | Recording an architecture decision and why alternatives were rejected | templates/adr.md |
Read what the user wants to write. Pick the best-fit type. If unclear, ask one question: "Is this scoped work for someone to pick up, or a broader proposal/decision?"
Use the Read tool on the relevant path:
~/.agents/skills/writing/templates/ticket.md~/.agents/skills/writing/templates/prd.md~/.agents/skills/writing/templates/project-update.md~/.agents/skills/writing/templates/adr.mdEach file contains the structure, field-by-field guidance, and a fill-in template. Apply it to the user's context — don't just repeat the template verbatim.
Lead with outcomes, not tasks. The reader should understand why before what. A good ticket describes the problem and success condition; the implementation approach is secondary.
Be specific about scope. Ambiguity in a ticket becomes scope creep. If you can't state clearly what done looks like, the artifact isn't ready.
Compress ruthlessly. Remove words that don't add information. Background sections should be the minimum needed to make the decision or task legible.
One artifact, one audience. A ticket is for the implementer. A PRD is for alignment. A project update is for stakeholders. Don't mix them.
When the user wants the output saved to Google Docs, use your docs capability:
Always confirm the document name and location with the user before creating. If they provide a doc name or link, use that directly.
development
Zoom meeting captions — file locations and format
tools
macOS dictation custom vocabulary — sync knowledge base names and terms to the system spelling dictionary
testing
Look up people, projects, products, and decisions locally first: contact info (email, Slack ID, GitHub handle), titles and teams, project/product status, who works on what, and past decisions. Check before searching Slack, email, calendar, or GitHub — this is the first stop for any contact detail, project context, or decision-history question.
testing
Communication style, audience awareness, and AI-authorship markers for human-facing prose — load when composing chat messages, review comments, merge request descriptions, emails, doc bodies, or ticket descriptions