name: ticket-create description: | Guides creation of well-structured tickets (task documents). This skill should be used when the user wants to create a ticket, task, feature request, bug report, or any work item that needs to be tracked and potentially assigned. Provides structure hints without enforcing rigid templates - the final structure adapts to the specific task and domain.

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:

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:

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

Structure Proposal

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

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.