Ticket Create Skill | Agent Skills

Ticket Create

Overview

This skill augments Caster's document creation workflow for tickets - task documents that describe work to be done. Tickets can represent features, bugs, improvements, research tasks, or any actionable work item.

When to Use

User wants to create a ticket, task, or work item
User has scattered thoughts about work that needs to be done
User says things like "I need to track this", "let's create a ticket for...", "this should be a task"
The /ticket-create command is invoked

Document Type

Type: Ticket (task document)

Unlike context packs (reference material), tickets are actionable - they describe work to be completed. They typically move through states (draft → active → completed) and may be assigned to someone.

Ticket Complexity

Tickets vary significantly in scope. Match structure to complexity:

| Complexity | Example | Typical Length | Structure | |------------|---------|----------------|-----------| | Simple | Bug fix, small task | 50-150 lines | Summary + Requirements + Acceptance Criteria | | Medium | Feature addition | 150-400 lines | Summary + Context + Requirements + Implementation Notes + AC | | Large | System refactor | 400-1500+ lines | Summary + Numbered Parts + Decisions + Questions + AC |

For large tickets, use numbered Parts to organize complex content:

## Part 1: Overview
## Part 2: Component A
## Part 3: Component B
etc.

Workflow Adaptations

When creating a ticket, adapt Caster's standard workflow:

Gap Analysis Focus

During gap analysis, specifically look for:

What needs to be done (the actual task)
Why it matters (context, motivation, impact)
Scope boundaries (what's included, what's explicitly excluded)
Success criteria (how to know when it's done)
Dependencies (what must happen first, what this blocks)

Clarification Questions

Prioritize questions about:

Scope and boundaries - what's in, what's out?
Success criteria - how will completion be measured?
Priority and urgency - how important is this relative to other work?
Dependencies - does this block or depend on other work?
Assignment - who should work on this?

Structure Proposal

Propose structure based on the specific task, not a fixed template. Common sections include:

| Section | When to Include | |---------|-----------------| | Summary | Always - numbered list of key changes/requirements | | Context/Background | When motivation or history matters | | Parts (numbered) | For large tickets with multiple components | | Requirements/Scope | When task has specific deliverables | | Decisions Made | When documenting choices (table format) | | Resolved Questions | When key decisions need rationale | | Acceptance Criteria | When success needs to be measurable (checkboxes) | | Implementation Notes | For technical tasks with design decisions | | Open Questions | When decisions are still pending | | References | Links to relevant code, docs, or other tickets |

Do NOT enforce all sections - include only what serves this specific ticket.

Frontmatter

Generating Git Context

Before creating frontmatter, run the metadata script to get git context:

.opencode/scripts/spec_metadata.sh

Or use thoughts metadata to get current values.

Complete Frontmatter Structure

---
# Git context (from metadata script)
date: 2025-01-15T10:30:00+03:00
researcher: username                # Who created this
git_commit: abc1234
branch: feature/my-feature
repository: project-name

# Document type
kind: ticket
status: draft                       # draft | active | blocked | implemented | verified | abandoned
topic: "Brief Descriptive Title"
tags: [feature, api, refactor]      # Categorization
source: manual                      # manual | linear | github | jira

# Priority and tracking
priority: 2                         # 0-4 (P0=critical, P4=backlog)
schema_version: 1

# References (enables wiki-links)
aliases:
  - ticket-2025-01-15-descriptive-slug

# Optional fields
assignee: alice                     # Who's responsible
due: 2025-02-01                     # YYYY-MM-DD deadline
depends_on:                         # What must complete first
  - "[[other-ticket-alias]]"

# Change tracking (updated automatically on edits)
last_updated: 2025-01-15T10:30:00+03:00
last_updated_by: username
last_updated_note: "Initial creation"
---

Minimal Frontmatter (for simple tickets)

---
date: 2025-01-15T10:30:00+03:00
researcher: username
kind: ticket
status: draft
topic: "Fix login button alignment"
tags: [bug, ui]
priority: 3
aliases:
  - ticket-2025-01-15-login-button-fix
---

Save Location

Tickets are saved to the current project's thoughts directory:

{project}/thoughts/shared/tickets/YYYY-MM-DD_descriptive-slug.md

After saving, remind the user to run thoughts sync to commit and push changes.

Alias Convention

Format: {kind}-{YYYY-MM-DD}-{descriptive-slug}

Examples:

ticket-2025-01-15-user-auth-flow
ticket-2025-01-15-api-rate-limiting
ticket-2025-01-15-dashboard-redesign

Acceptance Criteria Format

Use checkbox format for testable criteria:

## Acceptance Criteria

### Category 1

- [ ] Specific measurable criterion
- [ ] Another criterion with expected behavior

### Category 2

- [ ] Third criterion

Group related criteria under subheadings for large tickets.

Quality Checklist

Before finalizing, verify:

[ ] Summary clearly states what needs to be done
[ ] Scope is defined (or explicitly open-ended)
[ ] Success criteria exist (even if informal)
[ ] Alias follows convention
[ ] Frontmatter has appropriate fields for this ticket
[ ] Structure matches ticket complexity

Remember

Tickets are living documents. Start lean - it's better to have a clear, focused ticket than a comprehensive but bloated one. The ticket can be updated as understanding evolves. For large refactors, expect multiple review rounds to refine the specification.

Agent Skills: Ticket Create

Install this agent skill to your local

Skill Files