Create Tickets

Turn a brainstorming conversation into well-structured, properly-sized GitHub issues.

Overview

After a discussion about features, improvements, or bugs, this skill:

1. Extracts every idea from the conversation
2. Decomposes large features into PR-sized sub-issues
3. Presents a structured plan for user review
4. Batch-creates all approved issues with proper metadata
5. Adds them to the project board

Step 1: Extract Ideas from Conversation

Read the full conversation history. For each distinct idea, feature, bug, or task mentioned, capture:

• What it is (feature, bug fix, enhancement, refactor, docs, test, infrastructure)
• Why it matters (the user's stated motivation)
• Rough scope (how many files/areas it touches)

Group related ideas together. If the user discussed a large feature with multiple parts, keep those parts linked.

Step 2: Size and Decompose

Apply these sizing rules strictly:

For any idea estimated at L or larger, decompose by layer:

1. Data layer: models, migrations, interfaces (S)
2. Service layer: business logic implementing interfaces (S-M)
3. Endpoint layer: API endpoints wired to service (S)
4. UI layer: Blazor components consuming endpoints (S-M)
5. Test layer: unit + integration tests (S-M)

Not every layer applies to every feature. Only create sub-issues for layers that are relevant.

Step 3: Structure Each Issue

For each issue, determine all metadata:

Title

• Concise, actionable, imperative voice
• Good: "Add multi-prefix OR-clause to cloud scope search"
• Bad: "Cloud scope search improvements"

Labels (one type, one or more area labels, and a size label)

Type labels (exactly one): type: feature, type: bug, type: enhancement, type: refactor, type: docs, type: test, type: infrastructure

Area labels (one or more): area: core, area: web-ui, area: api, area: cli, area: mcp, area: ingestion, area: search, area: database, area: storage, area: identity, area: agents

Size labels (exactly one): size/XS, size/S, size/M, size/L, size/XL

Do NOT add needs-triage — issues created by this skill are fully triaged at creation time.

Priority

• P0-Critical: Blocking users or breaking core functionality
• P1-High: Important for next release, significant user impact
• P2-Medium: Planned improvement, moderate impact
• P3-Low: Nice to have, minor improvement

Milestone

Assign based on scope and dependencies:

• v0.3.1: Polish, tech debt, CI improvements
• v0.4.0: Cross-container search, live events, local connector ACLs
• v0.5.0: New connectors (GitHub, Notion, Slack) and embedding providers
• No milestone: exploratory or unscheduled work

Issue Body Format

Use this exact template for every issue:

## Description
[1-3 sentences: what this does and why it matters]

## Acceptance Criteria
- [ ] [Specific, testable criterion]
- [ ] [Another criterion]
- [ ] Tests pass (`dotnet test`)

## Implementation Notes
- Key file: `src/Connapse.[Project]/[relevant path]`
- Interface: `[relevant interface if applicable]`
- Pattern: [follow existing pattern in X if applicable]

## Size Estimate
[XS/S/M] — [one-line justification, e.g. "~80 lines across 2 files"]

## Related
[Parent: #N | Part of: #N | Depends on: #N | none]

Step 4: Present for Review

Before creating anything, present the full issue plan in a clear table format:

## Proposed Issues

### [Milestone or Group Name]

| # | Title | Type | Area | Size | Priority | Parent |
|---|-------|------|------|------|----------|--------|
| 1 | Title here | feature | storage | S | P2 | — |
| 2 | Title here | feature | storage | S | P2 | #1 |

Then show the full body for each issue so the user can review descriptions and acceptance criteria.

Ask the user to confirm, modify, or remove issues before proceeding. Use AskUserQuestion:

• "Create all N issues as shown?"
• Options: "Create all", "Let me make changes first", "Skip for now"

If the user wants changes, apply them and present again.

Step 5: Create Issues

After user approval, create issues in dependency order (parents before children).

For each issue, run:

gh issue create \
  --repo Destrayon/Connapse \
  --title "TITLE" \
  --body "$(cat <<'ISSUE_EOF'
BODY_CONTENT
ISSUE_EOF
)" \
  --label "type: feature" \
  --label "area: storage" \
  --label "size/S" \
  --milestone "v0.4.0"

Important gh issue create rules:

• Use HEREDOC for the body to preserve formatting
• Each --label flag takes one label (repeat the flag for multiple labels)
• Use --milestone only when a milestone was assigned
• Capture the issue URL from the output for project board and sub-issue linking

After creating each issue:

gh project item-add 3 --owner Destrayon --url ISSUE_URL

Sub-issue Linking

After both parent and child issues exist, link them using the GitHub API. First get the parent issue's node ID:

PARENT_NODE_ID=$(gh api graphql -f query='
  query {
    repository(owner: "Destrayon", name: "Connapse") {
      issue(number: PARENT_NUMBER) { id }
    }
  }' -q '.data.repository.issue.id')

Then get the child issue's node ID and add it as a sub-issue:

CHILD_NODE_ID=$(gh api graphql -f query='
  query {
    repository(owner: "Destrayon", name: "Connapse") {
      issue(number: CHILD_NUMBER) { id }
    }
  }' -q '.data.repository.issue.id')

gh api graphql -f query='
  mutation {
    addSubIssue(input: {
      issueId: "'"$PARENT_NODE_ID"'"
      subIssueId: "'"$CHILD_NODE_ID"'"
    }) {
      issue { id }
      subIssue { id }
    }
  }'

Step 6: Summary

After all issues are created, present a summary:

## Created Issues

| Issue | Title | Labels | Milestone |
|-------|-------|--------|-----------|
| #18 | Add multi-prefix OR-clause | type: enhancement, area: search | v0.3.1 |
| #19 | ... | ... | ... |

All issues added to project board: https://github.com/users/Destrayon/projects/3

Important Rules

1. NEVER create issues without user approval — always present the plan first
2. NEVER create L/XL issues — always decompose into S/M sub-issues
3. Every issue must have acceptance criteria — vague issues lead to vague PRs
4. One concern per issue — don't mix refactoring with features
5. Use TodoWrite to track progress through the batch creation process
6. If gh commands fail, report the error and ask if the user wants to retry or skip
7. Reference CLAUDE.md for architecture context when writing implementation notes