From Flagrare
Creates well-structured tickets as reviewable markdown files and pushes to trackers like Jira, Linear, GitHub Issues via MCP or CLI after user approval. Grounds tickets in codebase context.
How this skill is triggered — by the user, by Claude, or both
Slash command
/flagrare:ticket-creatorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create tickets as **reviewable markdown files** first. Present them for review. Only push to the tracker when the user explicitly approves.
Create tickets as reviewable markdown files first. Present them for review. Only push to the tracker when the user explicitly approves.
Before anything else, determine which tracker to target.
Detection order:
linear, jira, asana, shortcut, trello in tool nameswhich linear jira gh shortcut 2>/dev/null.linear/, atlassian.net in configs, existing ticket references in git historyTracker capability map:
| Tracker | MCP tool pattern | CLI | Ticket ID pattern |
|---|---|---|---|
| Jira | mcp__*atlassian*__*Jira* | jira | [A-Z]+-[0-9]+ |
| Linear | mcp__*linear*__* | linear | [A-Z]+-[0-9]+ |
| Shortcut | mcp__*shortcut*__* | shortcut | ch[0-9]+ / sc-[0-9]+ |
| Asana | mcp__*asana*__* | - | numeric ID |
| Trello | mcp__*trello*__* | - | card URL |
| GitHub Issues | gh issue create | gh | #[0-9]+ |
Record which tools are available. Use the best one when it's time to push.
Before drafting any ticket, ground it in the actual codebase if one exists. An engineer picking up an ungrounded ticket has to repeat the codebase exploration that this skill could have done once. Tickets that point at specific files and reuse-candidates are dramatically more useful than tickets that gesture vaguely at "the relevant area".
Skip codebase grounding when any of these is true:
git rev-parse --show-toplevel fails — not in a repogit ls-files | grep -vE '\.(md|txt|json|ya?ml|toml|gitignore|cff)$' | head -1 returns nothing[INFRA] add CODEOWNERS file, [DEVOPS] rotate AWS keys) and exploration would add no value — use judgementCall /flagrare:codebase-explore with the ticket's working title and a one-paragraph description of what it covers. Capture the returned findings: file paths with line numbers, related patterns, existing utilities that could be reused, prior branches/PRs.
These findings populate a new ticket subsection (see template updates below).
For multi-ticket flows (spec/TDD decomposition), dispatch N parallel /flagrare:codebase-explore agents — one per candidate ticket — in a single message with multiple Agent tool calls using model: "sonnet". Each agent gets that candidate's {title, summary} and returns its findings independently. Wall-clock stays bounded regardless of backlog size.
Do NOT run codebase-explore sequentially for backlog flows. The parallelism is the whole point — emit all Agent calls in one message so the runtime can execute them concurrently.
Tickets are written as numbered markdown files in a backlog folder.
docs/backlog/
INDEX.md # Overview, sequencing, summary table
00-epic.md # Epic/project definition (if creating a new one)
01-short-slug.md # First ticket
02-short-slug.md # Second ticket
...
NN-kebab-case-slug.md where NN is zero-padded sequence number00-epic.md# [PREFIX] Summary here
**Type:** Story | Task | Bug
**Priority:** High | Medium | Low | Critical
**Parent:** PROJ-123
**Tracker:** Jira | Linear | Shortcut | Asana | Trello | GitHub
# [Backlog Name]
**Epic/Project:** [KEY or "to be created"]
**Source:** `path/to/spec-or-tdd.md`
**Tracker:** [Jira | Linear | etc.]
**Total tickets:** N
## Suggested Sequencing
[ASCII tree or diagram showing phases and parallelism]
## Summary
| # | Summary | Type | Status |
|---|---------|------|--------|
| 01 | [PREFIX] First ticket summary | Story | draft |
| 02 | [PREFIX] Second ticket summary | Task | draft |
## Open Questions (optional)
## Blockers (optional)
Titles follow: [PREFIX] Summary
Common prefixes: [FE], [BE], [FE/BE], [SPIKE], [E2E], [INFRA], [DEVOPS]
Optionally include service name: [BE][billing-service] Summary
Summary should be concise and action-oriented. If you have seen the ticket before, it should fully remind you what it is about.
| Type | When to Use |
|---|---|
| Story | New user-facing features. Value to customers (not just engineering) |
| Task | Engineering work without direct customer value (refactors, infra, test coverage) |
| Bug | Defects, errors, incorrect behavior |
| Epic/Project | Groups related Stories/Tasks/Bugs into a larger deliverable |
Each template has an optional grounding subsection populated from /flagrare:codebase-explore findings (Step 0.5). The heading varies by type but the content format is the same: file paths with brief annotations, existing utilities, prior branches. Omit the subsection entirely if codebase grounding was skipped.
## Goal
[One-liner: what this delivers and why it matters.]
## Context
[Assume zero prior context. Explain what part of the project, what needs to change, end result. Link TDD/spec if available.]
## Existing Patterns (optional — from codebase-explore)
- `path/to/file.ts:42` — the function this touches today
- `path/to/utility.ts` — existing helper to reuse instead of writing fresh
- `prior-branch/feat-x` — abandoned approach, see PR #142 for why
## What needs to happen (optional, if implementation is known)
[Bullet list of specific changes: files, components, endpoints.]
## Acceptance Criteria
* [Specific, testable criterion]
* [Specific, testable criterion]
## Context
[What is happening vs what should happen. How discovered. Include IDs, threads, screenshots.]
## Suspect Code (optional — from codebase-explore)
- `path/to/file.ts:128` — handler where the bad behavior originates
- `path/to/validator.ts:64` — likely missing the guard for this input shape
## Steps to Reproduce (if known)
1. Step 1
2. Step 2
## Expected Behavior
[What should happen]
## Actual Behavior
[What actually happens]
## Acceptance Criteria
* [Specific fix criterion]
## Environment
[dev/prod/both, platform, browser, app version]
## Reference (optional)
[Logs, code links, related tickets.]
## Goal
[What question or problem needs investigation.]
## Context
[Background on why the spike is needed.]
## Prior Work (optional — from codebase-explore)
- `path/to/experimental.ts` — partial attempt from Q1
- `feat/spike-x` branch — abandoned, see PR #87 discussion for blockers
## Acceptance Criteria
* Document findings in [location]
* Evaluate LOE for [approaches]
* Recommend an approach with tradeoffs
## Reference
[Links to existing docs, related systems.]
After the draft is assembled with codebase findings, polish the Context section only by invoking /flagrare:write-docs with the draft Context as input.
The polish applies write-docs's craft layer to the Context: reader-situation-first opening, concrete file references inline (drawn from the grounding subsection), prose over bullets where causality matters, voice consistent across tickets.
Sections NOT polished — they stay mechanical:
Skip polish when: the user says "rough draft" / "skip polish" / --rough, or codebase grounding was skipped (without code references, there is little for write-docs to humanize).
Tickets should be 2-3 days of work. If larger, break up.
Specific and testable:
/flagrare:codebase-explore with the ticket's working title and description. Capture findings..md file with the next available sequence number, including the grounding subsection if applicable./flagrare:write-docs on the Context section. Replace the draft Context with the polished version.INDEX.md exists, update it./flagrare:codebase-explore agents (one per candidate ticket) by emitting N Agent tool calls with model: "sonnet" in a single message. Wait for all results before drafting./flagrare:write-docs on the Context section (skip if grounding was skipped or polish opted out).00-epic.md (if creating a new Epic/Project)NN-slug.md for each ticketINDEX.md with sequencing, summary table, open questions, blockersOnly when the user explicitly approves (e.g. "push these", "create these", "looks good, go ahead").
getAccessibleAtlassianResources to get cloud IDgetVisibleJiraProjects if neededgetJiraProjectIssueTypesMetadata to discover available issue types00-epic.md) if needed. Capture the key.parent to Epic key.md files with the assigned keylinear team list)00-epic.md existslinear issue create or MCP equivalent.md files with the assigned identifier00-epic.md existsgh issue create --title "..." --body "..." --milestone "...".md files with issue numbers00-epic.md exists.md files with story IDs.md files with task/card IDsUpdate each .md file metadata:
**Ticket:** PROJ-250
**Status:** created
Update INDEX.md summary table status from draft to created with the ticket key.
Present a summary with all created ticket keys/URLs.
path/to/file.ts:42 is dramatically more useful than one gesturing at "the relevant area"./flagrare:codebase-explore sequentially for a backlog flow. Emit all Agent tool calls in a single message — the runtime executes them concurrently. N tickets must take roughly the same wall-clock as 1.npx claudepluginhub flagrare/agent-skills --plugin flagrareProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.