By name: issue-writing description: Use when the user asks to write, draft, prepare, or revise a GitHub issue, issue body, follow-up issue, next-step issue, bug report, feature request, or requirements ticket.
Issue Writing for This User
What "Write the Issue" Means
Produce a copy/paste-ready GitHub issue body using the wiki issue template, saved as a wiki document. The user owns filing the issue on GitHub unless they explicitly authorize issue creation as a separate task.
Workflow
- Mirror intent in one sentence when ambiguous: "I read this as drafting a GitHub issue body for your review/copy-paste — confirm before I start."
- Read the template first:
~/wiki/templates/issue.md. - Ground in primary sources. Never draft from chat memory alone:
- For follow-up issues from a PR: use
git status,git log <base>..HEAD,git diff --stat <base>..HEAD, and relevant source files. - For standalone issues: use the user's prompt, screenshots/mockups, product notes, referenced code paths, or linked artifacts.
- For UI / API / feature claims: open the actual source files or mockup PNGs; do not infer from memory.
- For follow-up issues from a PR: use
- Draft exactly these top-level sections: Description, Motivation, Requirements.
- Make requirements testable. Use concrete, reviewable bullets. Prefix owner/team tags like
[DAL]only when known and useful. - Save the artifact as a wiki document. Default path:
~/wiki/projects/<project-slug>/issues/issue-<name>.md. Derive<project-slug>from the current repo or matching wiki project folder; createissues/if missing. Hand back the wiki path plus content summary. - Verify every concrete claim against the available source material. Anything sourced only from memory gets cut.
Defaults for Common Ambiguities
- Issue title requested too → provide the title separately from the body; the title is not part of the issue body.
- Issue-filing authority → draft the body and stop. Do not run
gh issue createwithout explicit authorization. - Not enough evidence for a requirement → phrase it as a question or omit it; do not invent acceptance criteria.
- File destination → wiki project docs by default:
~/wiki/projects/<project-slug>/issues/issue-*.md. Never save generated issue docs in the project repo or workspace root unless the user explicitly asks. Template docs live in~/wiki/templates/.
What Stays OUT of the Issue Body
- Wiki paths, personal-knowledge-base references, ADR filenames, memory file names — translate into ordinary engineering language.
- Speculative claims or generic boilerplate.
- Extra top-level sections beyond Description, Motivation, Requirements unless the user explicitly asks.
- Workflow steps for commit / push / PR / deploy.
Common Mistakes
| Anti-pattern | Reality |
|---|---|
| Add many headings because GitHub issues often have them | This user's required fields are Description, Motivation, Requirements |
| Draft from memory | Ground the issue in prompt/source files/screenshots/diffs |
Run gh issue create from the skill |
Human-owned action unless separately authorized |
| Hide uncertainty as a requirement | Ask or leave it out |
| Put generated issue docs inside the project repo or workspace root | Issues are durable documents; save them under the wiki project folder |
Stopping Point
The skill produces the issue artifact and stops. The human owns filing, editing, tagging, assigning, and tracking the GitHub issue unless they explicitly authorize those as separate operations.