3. Add structure

/create-issues

Turn the spec into issues an agent can build.

Install this skill Read the skill and templates

When to use it

Your spec’s v1 won’t fit one build session.
A feature spec needs one issue an agent can pick up.
You have TODOs, screenshots or notes to file as issues.

How it works

project_spec.md big project

/create-issues

Issue 1 first slice
Issue 2 blocked by issue 1
Issue 3 blocked by issue 2

feature_spec_<name>.md a feature

/create-issues

One issue ready for /blast-radius

a chat message inline text, TODOs or screenshots

/create-issues

Issues one per concern

1 Parse the request
What kind of issues, the source material, and GitHub or Linear.
2 Extract the issues
One per concern. A spec splits into vertical slices that each fit one build session.
3 Structure each issue
Your wording for titles. The body follows the issue template.
4 Check the destination
Duplicates, existing labels only, and the spec linked by its GitHub URL.
5 Preview
Exact titles, bodies, labels and dependencies before anything is created.
6 Create and summarize
Blockers first, then a summary with links and the dependency order.

What you get

Reviewed GitHub or Linear issues that link the spec by its GitHub URL.

Example issue: Export expenses as CSV

What goes in each issue

Description
Context, with the spec’s GitHub URL
Bug details, bugs only
Acceptance criteria and verification, including behavior it could break
End-to-end check: real user path, how an agent drives it, side effects
What agents should ask you
Dependencies: blocked by
Notes

Next step

When it’s done, /create-issues recommends one of these:

Build each issue · one at a time, blockers first
/blast-radius · for a feature: size it first
Wait for your go-ahead · if you asked for drafts or a review

Install /create-issues

One prompt installs just this skill and its templates. Want the whole system? Install all five from the Planning System page.

Then paste it into a conversation with your agent.

Works with

Claude Code
Codex
Grok Bot

Download create-issues.zip Unzip into your agent’s skills folder.

Read the installation prompt

Install the create-issues skill from this manifest for use in the agent I am using now:
https://ainativebuilder.com/plan/resources/create-issues/manifest.json

Identify this agent and use its supported personal/global skill installation or saved-skill mechanism, so the skill is reusable beyond the current project or conversation. If the correct mechanism is unclear, check this agent's official instructions before proceeding.

Fetch the manifest and download every listed file from the same origin. Preserve the exact contents and relative references of all 5 Markdown files, keeping each skill in its own folder named after the skill. Stage the complete bundle and verify its SHA-256 hashes before installation. If a download or hash check fails, stop and report it without changing existing skills. Back up any existing same-name skills before replacing them; keep filesystem backups outside skill-discovery directories. Install independent copies, not symlinks.

Verify that the skill is saved and discoverable and that every referenced template is accessible. If this host cannot preserve the complete bundle, explain the limitation instead of claiming successful installation. Report any enablement or refresh step still needed.

Confirm what was installed and where, then stop. Do not invoke the skill, start an interview, plan a project, or implement anything.

Install all five skills instead

Full instructions & templates

Read each complete file below. Copy or download the original Markdown to use with your agent.

Create issues skill

create-issues/SKILL.md

Select and copy the complete source below.

---
name: create-issues
description: Draft and create GitHub or Linear issues from a spec, files, screenshots, TODOs, or inline text. Use when the user explicitly asks to turn source material into one or more reviewed issues.
---

# Create Issues

Turn source material into focused, reviewed issues in GitHub or Linear. Tracker-specific access, commands, and dependency handling live in [references/github.md](references/github.md) and [references/linear.md](references/linear.md); use the one for the chosen tracker.

## Step 1: Parse the Request

From the current request and any text supplied with the invocation, extract:

1. **Intent** — what kind of issues the user wants (bug, feature, enhancement, etc.) and any labeling or formatting instructions.
2. **Source material** — a spec, file, folder, image, or inline content. Verify any referenced paths exist before proceeding.
3. **Tracker** — the one the user names. Otherwise infer it from the source (a GitHub or Linear issue link), project instructions such as `AGENTS.md` or `CLAUDE.md`, or which tracker is reachable; ask if both are plausible. Prefer an available connector or MCP server, otherwise the tracker's CLI.

## Step 2: Extract Issue Content

Pull out distinct issues from the source material (one per concern). Apply the user's instructions consistently across all items.

| Source type | How to extract |
|-------------|----------------|
| Spec or plan (e.g. `project_spec.md`, `feature_spec_<name>.md`) | Split it into vertical slices: each delivers user-visible or testable behavior and fits one build session. Follow the spec's milestones; if the MVP is being built straight from the spec, only the later milestones become issues unless the user says otherwise. If the whole spec fits one build session, one issue is fine. Carry each slice's acceptance criteria and verification forward, and record the order as dependencies. |
| Inline text in the prompt | Parse for distinct items (numbered lists, bullets, clearly separate concerns) |
| Markdown or text file | Read the file; split on headers, lists, or clear section breaks |
| Image / screenshot | Analyze the image and transcribe relevant evidence; use a repository-relative reference only when readers can access it |
| Folder | Enumerate candidate files first; exclude `.git`, dependencies, build output, hidden secret files, binaries, and symlinks that escape the requested folder. Ask only if it's unclear which files the user meant. |
| Code files (TODO/FIXME scans) | Search for the pattern, consolidate matches about the same concern, and include repository-relative paths and verified line numbers |

## Step 3: Structure Each Issue

### Title
- **Preserve the user's original wording** from the source material. Do not rephrase, summarize, or "action-verb-ify" titles unless the user explicitly asks for that.
- If the source has clear item names (e.g., "Transcript selector: List all .txt files"), use those directly as the issue title.
- Only lightly format if needed (e.g., capitalization, removing markdown artifacts).
- For a slice of a spec, or source content with no clear title, write a short title naming the outcome (e.g., "Export expenses as CSV"); section headings like "Milestone 1" are not titles.

### Body
Format the body using [references/issue_body_template.md](references/issue_body_template.md). Fill in the sections that apply; omit any that aren't relevant.

### Labels
Use [references/labels.md](references/labels.md) for the label taxonomy, selection rules, and auto-detection keywords. Pick the most specific label that fits each issue. Issues can have multiple labels when appropriate.

## Step 4: Resolve Destination, Duplicates, and Labels

1. Resolve the exact destination (a GitHub repository, or a Linear team and optional project) and who can see it, and use it explicitly for every read and write. Do not rely on the current directory for a mutation.
2. Search both open and closed issues for likely title or content duplicates. Surface matches before proposing a new issue.
3. Fetch the complete label inventory. Apply only labels that exist unless the user explicitly approves creating the exact missing labels.
4. Scan outgoing content for secrets, private code, personal data, machine-local paths, and unrelated material. Redact or omit it before review.
5. Link a source spec by its URL in the project's GitHub repository (e.g. `https://github.com/OWNER/REPO/blob/<default-branch>/plans/feature_spec_<name>.md`), not a local path. If the spec isn't committed and pushed yet, say so in the preview and offer to commit and push it first. Either way, write each issue body so it can be worked on without opening the spec.
6. A local screenshot path is not an attachment issue readers can access; upload an image only through a verified supported workflow and with user approval.

## Step 5: Preview

Before creating anything, show the user the exact destination and who can see it, the number of issues, each issue's exact title, body, labels, and dependencies with any likely duplicate, and any missing labels you propose to create. For a large batch, write the payload to a local draft file rather than truncating it.

If the user asked you to *create* the issues, this preview is informational: publish once it's shown, and don't ask again for a payload they already approved. If they asked for drafts or a review, or the destination or what should be disclosed is unclear, wait for their go-ahead.

## Step 6: Create Issues

Create only the missing labels included in the approved preview, then create the issues in dependency order so blockers exist before the issues that depend on them. Record each dependency with the tracker's own mechanism.

After each issue is created, record its identifier and URL immediately and read back the title, body, labels, and dependencies. Stop on ambiguous failures, recheck for duplicates before retrying, and report partial completion.

## Step 7: Summary

After all issues are created, provide a summary:
- Total issues created, with identifiers, titles, and links
- The dependency order, when there is one
- Anything not created, and why

## Guidelines

- Keep issues focused and atomic - one concern per issue
- Write from the perspective of "what needs to be done"
- Include enough context for someone else to understand and work on the issue
- Prove success end to end: give each issue that completes a user journey an end-to-end check through the real user path (no test-only shortcuts), say how an agent drives it (browser, terminal, HTTP calls), and name the side effects to confirm, such as saved records, files written, or messages sent
- A label the user names wins over keyword hints. **Infer intent** when none is named: "fix the issues in..." implies bugs; "add features from..." implies enhancements

## Error Handling

- If neither a connector nor an authenticated CLI for the tracker is available, say so and hand back the drafts
- If an image can't be read, note this and ask for alternative input

Create Issues

Turn source material into focused, reviewed issues in GitHub or Linear. Tracker-specific access, commands, and dependency handling live in references/github.md and references/linear.md; use the one for the chosen tracker.

Step 1: Parse the Request

From the current request and any text supplied with the invocation, extract:

Intent — what kind of issues the user wants (bug, feature, enhancement, etc.) and any labeling or formatting instructions.
Source material — a spec, file, folder, image, or inline content. Verify any referenced paths exist before proceeding.
Tracker — the one the user names. Otherwise infer it from the source (a GitHub or Linear issue link), project instructions such as AGENTS.md or CLAUDE.md, or which tracker is reachable; ask if both are plausible. Prefer an available connector or MCP server, otherwise the tracker’s CLI.

Step 2: Extract Issue Content

Pull out distinct issues from the source material (one per concern). Apply the user’s instructions consistently across all items.

Source type	How to extract
Spec or plan (e.g. `project_spec.md`, `feature_spec_<name>.md`)	Split it into vertical slices: each delivers user-visible or testable behavior and fits one build session. Follow the spec’s milestones; if the MVP is being built straight from the spec, only the later milestones become issues unless the user says otherwise. If the whole spec fits one build session, one issue is fine. Carry each slice’s acceptance criteria and verification forward, and record the order as dependencies.
Inline text in the prompt	Parse for distinct items (numbered lists, bullets, clearly separate concerns)
Markdown or text file	Read the file; split on headers, lists, or clear section breaks
Image / screenshot	Analyze the image and transcribe relevant evidence; use a repository-relative reference only when readers can access it
Folder	Enumerate candidate files first; exclude `.git`, dependencies, build output, hidden secret files, binaries, and symlinks that escape the requested folder. Ask only if it’s unclear which files the user meant.
Code files (TODO/FIXME scans)	Search for the pattern, consolidate matches about the same concern, and include repository-relative paths and verified line numbers

Step 3: Structure Each Issue

Title

Preserve the user’s original wording from the source material. Do not rephrase, summarize, or “action-verb-ify” titles unless the user explicitly asks for that.
If the source has clear item names (e.g., “Transcript selector: List all .txt files”), use those directly as the issue title.
Only lightly format if needed (e.g., capitalization, removing markdown artifacts).
For a slice of a spec, or source content with no clear title, write a short title naming the outcome (e.g., “Export expenses as CSV”); section headings like “Milestone 1” are not titles.

Body

Format the body using references/issue_body_template.md. Fill in the sections that apply; omit any that aren’t relevant.

Labels

Use references/labels.md for the label taxonomy, selection rules, and auto-detection keywords. Pick the most specific label that fits each issue. Issues can have multiple labels when appropriate.

Step 4: Resolve Destination, Duplicates, and Labels

Resolve the exact destination (a GitHub repository, or a Linear team and optional project) and who can see it, and use it explicitly for every read and write. Do not rely on the current directory for a mutation.
Search both open and closed issues for likely title or content duplicates. Surface matches before proposing a new issue.
Fetch the complete label inventory. Apply only labels that exist unless the user explicitly approves creating the exact missing labels.
Scan outgoing content for secrets, private code, personal data, machine-local paths, and unrelated material. Redact or omit it before review.
Link a source spec by its URL in the project’s GitHub repository (e.g. https://github.com/OWNER/REPO/blob/<default-branch>/plans/feature_spec_<name>.md), not a local path. If the spec isn’t committed and pushed yet, say so in the preview and offer to commit and push it first. Either way, write each issue body so it can be worked on without opening the spec.
A local screenshot path is not an attachment issue readers can access; upload an image only through a verified supported workflow and with user approval.

Step 5: Preview

Before creating anything, show the user the exact destination and who can see it, the number of issues, each issue’s exact title, body, labels, and dependencies with any likely duplicate, and any missing labels you propose to create. For a large batch, write the payload to a local draft file rather than truncating it.

If the user asked you to create the issues, this preview is informational: publish once it’s shown, and don’t ask again for a payload they already approved. If they asked for drafts or a review, or the destination or what should be disclosed is unclear, wait for their go-ahead.

Step 6: Create Issues

Create only the missing labels included in the approved preview, then create the issues in dependency order so blockers exist before the issues that depend on them. Record each dependency with the tracker’s own mechanism.

After each issue is created, record its identifier and URL immediately and read back the title, body, labels, and dependencies. Stop on ambiguous failures, recheck for duplicates before retrying, and report partial completion.

Step 7: Summary

After all issues are created, provide a summary:

Total issues created, with identifiers, titles, and links
The dependency order, when there is one
Anything not created, and why

Guidelines

Keep issues focused and atomic - one concern per issue
Write from the perspective of “what needs to be done”
Include enough context for someone else to understand and work on the issue
Prove success end to end: give each issue that completes a user journey an end-to-end check through the real user path (no test-only shortcuts), say how an agent drives it (browser, terminal, HTTP calls), and name the side effects to confirm, such as saved records, files written, or messages sent
A label the user names wins over keyword hints. Infer intent when none is named: “fix the issues in…” implies bugs; “add features from…” implies enhancements

Error Handling

If neither a connector nor an authenticated CLI for the tracker is available, say so and hand back the drafts
If an image can’t be read, note this and ask for alternative input

Issue body template

create-issues/references/issue_body_template.md

Select and copy the complete source below.

## Description
[Clear description of what needs to be done]

## Context
[Any relevant background, source file, or screenshot reference]

**Source spec:** [GitHub URL of the spec in the project's repository, plus the relevant section. Not a local path.]

## Bug Details
_Bugs only; omit for other issues._

- **Steps to reproduce:** [Numbered steps from a known starting state]
- **Expected:** [What should happen]
- **Actual:** [What happens instead, with any error message or screenshot reference]

## Acceptance Criteria and Verification
_Each criterion with how to check it and what counts as passing. Carry forward the source spec's relevant verification requirements, including any specific existing behavior this change could break. These are planned checks, not completed results._

- [ ] [Specific, measurable criterion] — **Verify:** [Test, walkthrough, measurement, or review, with relevant inputs and environment] → [Observable evidence or threshold required to pass]
- [ ] [Specific existing behavior this change could break, if any] — **Verify:** [Regression check] → [Still behaves as before]

**End-to-end check:** [The user journey this issue completes, exercised through the real user path rather than internal shortcuts or test-only endpoints; how an agent drives it (browser, terminal, HTTP calls); and the side effects to confirm, such as saved records, files written, or messages sent]

## What Agents Should Ask You
_Carry forward from the source spec when it has this section; omit otherwise._

- **Check with me first:** [e.g., new paid services, changes to existing data, anything public-facing]

## Dependencies
[When splitting a spec into multiple issues, record prerequisites and ordering. Omit if none apply.]

- **Blocked by:** [Issue link + what it must deliver first. Blockers are created first, so link the real issue; in the preview, use its draft title.]

## Notes
[Any additional context, constraints, or suggestions]

Show the issue body template

Description

[Clear description of what needs to be done]

Context

[Any relevant background, source file, or screenshot reference]

Source spec: [GitHub URL of the spec in the project’s repository, plus the relevant section. Not a local path.]

Bug Details

Bugs only; omit for other issues.

Steps to reproduce: [Numbered steps from a known starting state]
Expected: [What should happen]
Actual: [What happens instead, with any error message or screenshot reference]

Acceptance Criteria and Verification

Each criterion with how to check it and what counts as passing. Carry forward the source spec’s relevant verification requirements, including any specific existing behavior this change could break. These are planned checks, not completed results.

[Specific, measurable criterion] — Verify: [Test, walkthrough, measurement, or review, with relevant inputs and environment] → [Observable evidence or threshold required to pass]
[Specific existing behavior this change could break, if any] — Verify: [Regression check] → [Still behaves as before]

End-to-end check: [The user journey this issue completes, exercised through the real user path rather than internal shortcuts or test-only endpoints; how an agent drives it (browser, terminal, HTTP calls); and the side effects to confirm, such as saved records, files written, or messages sent]

What Agents Should Ask You

Carry forward from the source spec when it has this section; omit otherwise.

Check with me first: [e.g., new paid services, changes to existing data, anything public-facing]

Dependencies

[When splitting a spec into multiple issues, record prerequisites and ordering. Omit if none apply.]

Blocked by: [Issue link + what it must deliver first. Blockers are created first, so link the real issue; in the preview, use its draft title.]

Notes

[Any additional context, constraints, or suggestions]

Labels

create-issues/references/labels.md

Select and copy the complete source below.

# Labels Reference

## Label Definitions

| Label | Use when issue involves... |
|-------|---------------------------|
| `bug` | Fixing something broken, errors, incorrect behavior |
| `enhancement` | New features, improvements to existing functionality |
| `deployment` | Hosting, CI/CD, Vercel, infrastructure, environment setup, domains, SSL |
| `documentation` | README, docs, comments, API documentation |
| `refactor` | Code cleanup, restructuring without changing behavior |
| `testing` | Adding/fixing tests, test infrastructure |
| `security` | Auth, API keys, vulnerabilities, permissions |
| `performance` | Speed improvements, optimization, caching |
| `design` | UI/UX changes, styling, layouts |
| `good first issue` | Simple, self-contained, good for newcomers |

## Selection Rules

1. Treat explicit user labeling instructions as authoritative.
2. When the repository uses this taxonomy, choose at most one issue-type label (`bug`, `enhancement`, `refactor`, `documentation`, `testing`) and add domain labels (`deployment`, `security`, `performance`, `design`) when they materially improve routing.
3. Add `good first issue` only when the work is genuinely small, self-contained, and documented.
4. If a needed label does not exist, include its exact definition in the approval preview before creating it.

## Auto-Detection Keywords

Use these keywords as hints when choosing labels:

| Keywords/Patterns | Label |
|-------------------|-------|
| bug, fix, broken, error, crash, failing, doesn't work | `bug` |
| feature, add, new, implement, enhance, improve, support | `enhancement` |
| deploy, vercel, hosting, CI/CD, environment, domain, SSL, infrastructure, production, server | `deployment` |
| docs, documentation, readme, comments, API docs, guide | `documentation` |
| refactor, cleanup, reorganize, restructure, simplify | `refactor` |
| test, spec, coverage, unit test, integration test, e2e | `testing` |
| security, auth, API key, token, permission, vulnerability, secret | `security` |
| performance, speed, optimize, cache, slow, fast, latency | `performance` |
| UI, UX, design, style, layout, responsive, mobile, CSS, theme | `design` |

Keyword matches are suggestions, not proof. Read the issue meaning before assigning labels.

## Creating Missing Labels

Map to the tracker's existing labels before proposing a new one: repositories and workspaces often have their own taxonomy (Linear workspaces start with `Bug`, `Feature`, and `Improvement`), and existing definitions take precedence. When the user approves creating one of these labels, use this description and color:

| Label | Description | Color |
|-------|-------------|-------|
| `bug` | Something is not working | `#D73A4A` |
| `enhancement` | New feature or improvement | `#A2EEEF` |
| `deployment` | Infrastructure and deployment tasks | `#0E8A16` |
| `documentation` | Documentation improvements | `#0075CA` |
| `refactor` | Code cleanup and restructuring | `#FBCA04` |
| `testing` | Tests and test infrastructure | `#BFD4F2` |
| `security` | Security-related changes | `#D93F0B` |
| `performance` | Performance improvements | `#5319E7` |
| `design` | UI/UX and styling | `#F9D0C4` |
| `good first issue` | Approachable for a first contribution | `#7057FF` |

Create only the labels the user approved; the tracker reference has the command or tool to use.

Show the labels

Labels Reference

Label Definitions

Label	Use when issue involves…
`bug`	Fixing something broken, errors, incorrect behavior
`enhancement`	New features, improvements to existing functionality
`deployment`	Hosting, CI/CD, Vercel, infrastructure, environment setup, domains, SSL
`documentation`	README, docs, comments, API documentation
`refactor`	Code cleanup, restructuring without changing behavior
`testing`	Adding/fixing tests, test infrastructure
`security`	Auth, API keys, vulnerabilities, permissions
`performance`	Speed improvements, optimization, caching
`design`	UI/UX changes, styling, layouts
`good first issue`	Simple, self-contained, good for newcomers

Selection Rules

Treat explicit user labeling instructions as authoritative.
When the repository uses this taxonomy, choose at most one issue-type label (bug, enhancement, refactor, documentation, testing) and add domain labels (deployment, security, performance, design) when they materially improve routing.
Add good first issue only when the work is genuinely small, self-contained, and documented.
If a needed label does not exist, include its exact definition in the approval preview before creating it.

Auto-Detection Keywords

Use these keywords as hints when choosing labels:

Keywords/Patterns	Label
bug, fix, broken, error, crash, failing, doesn’t work	`bug`
feature, add, new, implement, enhance, improve, support	`enhancement`
deploy, vercel, hosting, CI/CD, environment, domain, SSL, infrastructure, production, server	`deployment`
docs, documentation, readme, comments, API docs, guide	`documentation`
refactor, cleanup, reorganize, restructure, simplify	`refactor`
test, spec, coverage, unit test, integration test, e2e	`testing`
security, auth, API key, token, permission, vulnerability, secret	`security`
performance, speed, optimize, cache, slow, fast, latency	`performance`
UI, UX, design, style, layout, responsive, mobile, CSS, theme	`design`

Keyword matches are suggestions, not proof. Read the issue meaning before assigning labels.

Creating Missing Labels

Map to the tracker’s existing labels before proposing a new one: repositories and workspaces often have their own taxonomy (Linear workspaces start with Bug, Feature, and Improvement), and existing definitions take precedence. When the user approves creating one of these labels, use this description and color:

Label	Description	Color
`bug`	Something is not working	`#D73A4A`
`enhancement`	New feature or improvement	`#A2EEEF`
`deployment`	Infrastructure and deployment tasks	`#0E8A16`
`documentation`	Documentation improvements	`#0075CA`
`refactor`	Code cleanup and restructuring	`#FBCA04`
`testing`	Tests and test infrastructure	`#BFD4F2`
`security`	Security-related changes	`#D93F0B`
`performance`	Performance improvements	`#5319E7`
`design`	UI/UX and styling	`#F9D0C4`
`good first issue`	Approachable for a first contribution	`#7057FF`

Create only the labels the user approved; the tracker reference has the command or tool to use.

GitHub notes

create-issues/references/github.md

Show the github notes

GitHub

Access

Prefer an available, authorized GitHub connector or MCP server. Otherwise use the gh CLI after confirming gh auth status. Pass --repo OWNER/REPO on every command rather than relying on the current directory.

Destination and visibility

gh repo view OWNER/REPO --json nameWithOwner,visibility

Issues in a public repository are public. Recheck outgoing content with that in mind.

Duplicates and labels

gh issue list --repo OWNER/REPO --state all --search "<keywords>" --limit 50
gh label list --repo OWNER/REPO --limit 200
gh label create "<name>" --repo OWNER/REPO --description "<description>" --color "<hex without #>"

Create and read back

Write each reviewed body to a securely created temporary file so arbitrary Markdown is never interpolated into a shell command:

gh issue create --repo OWNER/REPO --title "Title" --body-file <reviewed-body-file> --label "bug" --label "security"
gh issue view <number> --repo OWNER/REPO --json number,title,body,labels,url

Dependencies

Record each dependency as a Blocked by: #<number> line in the body’s Dependencies section; it is visible everywhere and survives any tooling. If the connector supports GitHub’s native issue dependencies or sub-issues, you may set those too.

Images

gh cannot attach a local image to an issue. Describe what the screenshot shows, or reference an image already committed to the repository, unless the user approves another supported upload path.

Linear notes

create-issues/references/linear.md

Show the linear notes

Linear

Access

Prefer Linear’s MCP server or another available Linear connector. Otherwise use a Linear CLI or API access the user has already configured. Never ask for an API key in chat or write one into a file or command. If neither is available, hand back the drafts.

Destination and visibility

An issue needs a team; a project (and a project milestone) is optional. List teams and projects to confirm exact names rather than guessing. Issues are visible to workspace members who can access the team, and a private team limits that further; say which applies in the preview.

Leave the issue in the team’s default state, and don’t set assignee, priority, estimate, or cycle unless the user asks or the source specifies them.

Duplicates and labels

Search the team’s issues by title and description keywords, including completed and canceled ones (and archived ones when the tool allows).

Labels exist at the workspace and team level. Retired labels and label groups can’t be applied. Create an approved missing label on the team unless the user asks for a workspace label, which every team would see.

Create and read back

Pass the description as Markdown with real newlines, not escaped sequences. Attach the source spec as a link on the issue when the tool supports links, in addition to the body’s Source spec line. After creating, fetch each issue and confirm its title, description, labels, and relations.

Dependencies

Linear has native relations. Create blockers first, then set blocked by on each dependent issue (in Linear’s MCP server, the blockedBy field of save_issue). Keep the body’s Dependencies section as well. Use a parent issue with sub-issues only when the user wants that structure.

When to use it

How it works

1 Parse the request

2 Extract the issues

3 Structure each issue

4 Check the destination

5 Preview

6 Create and summarize

What you get

Next step

Install /create-issues

Full instructions & templates

Create Issues

Step 1: Parse the Request

Step 2: Extract Issue Content

Step 3: Structure Each Issue

Title

Body

Labels

Step 4: Resolve Destination, Duplicates, and Labels

Step 5: Preview

Step 6: Create Issues

Step 7: Summary

Guidelines

Error Handling

Description

Context

Bug Details

Acceptance Criteria and Verification

What Agents Should Ask You

Dependencies

Notes

Labels Reference

Label Definitions

Selection Rules

Auto-Detection Keywords

Creating Missing Labels

GitHub

Access

Destination and visibility

Duplicates and labels

Create and read back

Dependencies

Images

Linear

Access

Destination and visibility

Duplicates and labels

Create and read back

Dependencies