Menu
Template and writing guidelines for a GitHub issue. Every issue is one of epic, feature, task, bug, or research task — the user decides the type, and each type has its own template. Non-epic types can suggest a parent epic from the project board.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Implement a feature from the plan that plan-feature produced under docs/plan/<feature>/, one reviewed sub-issue at a time. Use when the user wants to implement or build a feature from a docs/plan/<feature>/ plan or a planned GitHub issue.
Turn a GitHub issue into an implementation plan under docs/plan/<feature>/: a feature spec decomposed into context-window-sized sub-issues, committed as the first commit of the feature branch with a draft PR. Use when the user wants to plan a feature, decompose a GitHub issue into sub-issues, or produce an implementation plan from an issue.
Draft a GitHub issue, get explicit user approval, and file it via the `gh` CLI. TRIGGER when: user wants to file or "drop" a GitHub issue / ticket.
Check and align a repo's .claude/settings.json and CLAUDE.md with team conventions. Use when the user wants to standardize a repo, align conventions, check settings, or bootstrap Claude Code config in a new project.
Use this skill whenever writing, editing, reviewing, or refactoring TypeScript React code — components, custom hooks, state stores, forms, queries, mutations, API clients, or styling. Trigger it for any task touching a `.ts` or `.tsx` file in a React project, including when the user says "add a feature", "fix this bug", or "clean this up" inside a component or hook. Also use it for architectural questions about React codebases: where state should live, whether a component is too big, how to organize modules, when to reach for TanStack Query, Zustand, React Context, or React Hook Form.
Author a DAM Experiment — a Python loop script (produce/eval/select, genetic algorithms, benchmark sweeps) the platform observes live with a graph, per-stage progress, and score charts. Use when asked to create, plan, or run an experiment, an optimization loop, or an iterate-and-score campaign. Provides the python experiment_sdk (Experiment/stage/span + spawn) and the plan → "Start a new run" workflow.
| name | draft-issue |
| description | Template and writing guidelines for a GitHub issue. Every issue is one of epic, feature, task, bug, or research task — the user decides the type, and each type has its own template. Non-epic types can suggest a parent epic from the project board. |
Follow docs/guidelines/issue-guidelines.md for the issue types, style, and the per-type templates.
Understand the request thoroughly. Read the user's prompt carefully — multiple times if it's long or ambiguous. Identify what problem they're describing, who it affects, and what outcome they want. Restate it back in one or two sentences to confirm shared understanding. Ask follow-ups for anything that would change the shape of the issue (scope, who it affects, dependencies on other work). Do not start drafting until you genuinely understand the ask.
Because Context leads every template — why this matters, what led here — make sure you actually have it. If the user's ask doesn't convey that context, ask them for it before drafting. A ticket without real context is the main thing this step exists to prevent.
Let the user decide the type. Every issue is an epic, feature, task, bug, or research task (see the guidelines doc). State which type you read the ask as and why, and let the user confirm or override — the type picks the template. Skip the question only when the type is unmistakable (e.g. the user said "bug" or described a clear defect).
Research the codebase thoroughly. Do real investigation of the current state — read relevant files, trace how the feature works today, understand the user-visible behavior end-to-end. The goal is to describe the status quo accurately, not superficially. A shallow understanding produces a vague ticket.
But keep the research out of the issue itself. Do not pull file paths, function names, line numbers, data structures, or architectural detail into the draft. The research informs your writing; it does not appear in it. If a sentence only makes sense to someone who's read the code, rewrite it.
For any non-epic type: consider an epic. Fetch the epics from the project board and check whether one clearly fits:
gh project item-list 1 --owner dam-agents --limit 3000 --format json \
| jq -r '.items[] | select(.status=="Epics") | "#\(.content.number) \(.title)"'
If one does, read its body (gh issue view <num> --repo dam-agents/dam) to confirm, then put it on the draft's Epic line with a one-line justification. If nothing fits, leave the line out — placement can be decided later in triage. Epics themselves have no parent; skip this step.
Decide output mode from the original prompt. Read the user's initial ask and pick one:
file-issue skill, which runs the dedupe → approve → file loop on top of the same draft.When in doubt, default to draft-only and ask whether to file.