# Writing Artifacts

> Draft and revise external writing such as Medium articles, GitHub issues, pull requests, technical docs, release notes, and user-facing copy. Use only when explicitly invoked for paste-ready writing with a defined audience, format, tone, or acceptance criteria.

- Skill: `sgaabdu4/writing-artifacts` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add sgaabdu4/writing-artifacts`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sgaabdu4/writing-artifacts/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sgaabdu4 (https://skillmd.com/u/sgaabdu4)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sgaabdu4/writing-artifacts

---


# Writing Artifacts

## Brief

- Identify audience, purpose, reader action, format, tone, length, and source constraints.
- If a missing choice would change the result, ask. Otherwise choose a plain, useful default.
- Treat supplied facts, links, code, names, dates, and examples as source truth. Mark unknowns; do not invent them.
- Honor the artifact's requested length. Do not force the chat reply word cap onto a paste-ready deliverable.

## Format branches

### Medium article

- Open with the reader's problem, promise, or a concrete story. Earn attention quickly.
- State one clear thesis. Give each section one job, with examples or evidence that move it forward.
- Use a useful title, readable headings, specific transitions, and a conclusion that leaves the reader with a decision or next step.
- Remove sales language, generic lessons, fake certainty, and filler introductions.

### GitHub issue

- Title = the observable problem or requested outcome.
- Structure = summary + context + steps to reproduce + expected behavior + actual behavior + evidence + scope + acceptance criteria.
- Preserve exact errors, paths, commands, versions, dates, and links. Separate facts from hypotheses.
- Report one coherent problem. Include a proposed fix only when requested or clearly useful.

### Pull request

- Structure = what changed + why + user or system impact + proof run + risk or rollout notes.
- Link the issue or decision when supplied. State known gaps and follow-up work without hiding it in prose.

### Docs, notes, and copy

- Describe the accepted current state, not the editing history.
- Match the reader's job: explain, decide, perform, or understand. Use headings, examples, and calls to action only when they help.

## Final pass

- Check audience, purpose, structure, claims, links, code, dates, length, and requested tone.
- Remove repetition, chatbot filler, inflated claims, unexplained jargon, and process commentary.
- Return the finished artifact first. Add a short note only when the user asks for explanation or a material gap needs attention.