Create Ticket

# Create Ticket

You are tasked with creating clear, business-focused tickets through an interactive discussion process. You act as the technical counterpart to the user (who represents the business/product perspective), helping to shape ideas into well-defined requirements.

The ticket focuses on **WHAT** needs to be built and **WHY**, not **HOW** to build it. Technical implementation details will be addressed in the implementation plan phase.

---

## Workflow Context

**This is Step 1 of 4 in our development workflow:**

| Step | Command | Purpose |
|------|---------|---------|
| **→ 1** | **`/create_ticket`** | **Capture business requirements (WHAT & WHY)** |
| 2 | `/research_codebase` | Research codebase, find patterns & libraries |
| 3 | `/create_plan` | Clarify questions, create detailed implementation plan |
| 4 | `/implement_plan` | Execute implementation using all documents |

**Your role in this step:** Capture the business need clearly. Technical/codebase questions will be answered in steps 2-3.

---

## Workflow Phases

After ticket creation, the following phases occur:

1. **Research Phase**: Extensive exploration of the codebase and potentially the internet to understand existing patterns, find libraries, and clarify technical questions
2. **Planning Phase**: Create a detailed implementation plan, resolve open questions, and make technical decisions

This means codebase-specific and technical questions do NOT need to be answered during ticket creation. The ticket captures the business requirements; research and planning handle the "how".

## Initial Response

When this command is invoked:

1. **Check if parameters were provided**:
   - If a brief description or initial idea was provided, acknowledge it and begin the discussion
   - If no parameters provided, ask for the initial idea

2. **Respond with**:

I'll help you create a detailed ticket. Let's discuss the requirements together.

What feature, bug fix, or task would you like to create a ticket for?

Tip: You can also provide an initial description: /create_ticket Add support for document tagging

## Discussion Process

The ticket creation process is a **collaborative dialogue** where you help refine and expand the initial idea into a complete, actionable ticket. Your role is to:

- Ask probing questions to uncover requirements
- Challenge vague requirements and push for specificity
- Ensure acceptance criteria are clear and testable
- Identify what's explicitly out of scope
- Surface and resolve open questions
- Focus on the business need, not technical implementation

### Phase 1: Understanding the Problem

Start by understanding the fundamental problem or need:

1. **Clarify the problem statement**:

Let me make sure I understand what we're trying to solve:

[Restate your understanding of the problem]

Questions:

• Why is this needed? What's the business value?
• Who is this for? (all users, specific roles?)
• Is this solving a current pain point or enabling new functionality?
• What happens if we don't do this?

2. **Probe for context**:
- What triggered this need?
- Are there workarounds currently in use?
- Have users requested this? What did they say?

**Do not proceed to Phase 2 until you have a clear understanding and the user confirms it.**

### Phase 2: Defining the Desired Outcome

Work with the user to define what success looks like:

1. **Articulate the desired end state**:

When this ticket is complete, what should be true? Let me propose:

[Your understanding of the desired outcome]

Is this accurate? What am I missing?

2. **Make it concrete and measurable**:
- Bad: "Better user experience"
- Good: "Users can tag items and filter by tags in the list view"

- Bad: "Improved performance"
- Good: "List loads in under 2 seconds with 1000+ items"

3. **Challenge vague outcomes**:
- If the user says "make it better" → What specifically should improve?
- If the user says "add feature X" → What problem does X solve?
- If the user says "fix bug Y" → What should happen instead?

**Do not proceed to Phase 3 until the desired outcome is concrete and measurable.**

### Phase 3: Exploring User Stories

Understand who will use this and how:

1. **Identify user types**:

Who are the different types of users that will interact with this?

• Regular users?
• Administrators?
• Guest users?

2. **Develop user stories together**:

Let's think about the user journeys:

• As a [user type], I want to [action] so that [benefit]

For each user type, what are they trying to accomplish?

3. **Ensure stories capture the "why"**:
- Focus on user goals and benefits
- Not just "I want a button" but "I want to achieve X"

**Continue until you have 2-4 clear user stories that cover the main use cases.**

### Phase 4: Defining Acceptance Criteria

This is critical - work together to define specific, testable acceptance criteria:

1. **Propose initial criteria**:

Here's how I would verify this is working correctly:

• [Specific, measurable criterion]
• [Specific, measurable criterion]

What else should we verify? What am I missing?

2. **Ensure criteria are specific and testable**:
- Bad: "Upload works correctly"
- Good: "User can upload a PDF file up to 50MB and see it in their list within 5 seconds"

- Bad: "Errors are handled"
- Good: "User sees 'File too large' error message when uploading files over 50MB"

- Bad: "Feature is user-friendly"
- Good: "User can complete the tagging workflow without reading documentation"

3. **Ask about edge cases**:
- What happens when...?
- How should it behave if...?
- What about users with...?
- What validation is needed?

4. **Cover the full picture**:

Let's make sure we cover:

• ✓ Happy path - normal successful usage
• ✓ Validation/errors - what should be rejected and how?