---
name: work-on-ticket
description: Fetches Jira ticket details, creates an appropriately named branch, and initiates the task planning workflow. Use when the user says "work on [TICKET_ID]" or similar phrases.
---
# Work on Ticket
Streamlined workflow to start work on a Jira ticket by fetching ticket details, creating a branch, and initiating task planning.
## When to Use This Skill
Activate this skill when:
- The user says "work on AGP-123" or "start work on AGP-123"
- The user says "pick up AGP-123" or "begin AGP-123"
- The user mentions starting work on a specific Jira ticket ID
- Pattern: `work on [TICKET_ID]` or similar intent
## Workflow
### 1. Parse Ticket ID
Extract the Jira ticket ID from the user's message. Common patterns:
- `work on AGP-782`
- `start AGP-782`
- `pick up PROJ-123`
Ticket ID format: `[A-Z]+-[0-9]+` (e.g., AGP-782, AICC-123)
### 2. Fetch Jira Ticket Details
Use the MCP Zapier tool to fetch the ticket:
```typescript
mcp__zapier -
frontend__jira_software_cloud_find_issue_by_key({
instructions: "Get details for ticket [TICKET_ID]",
key: "[TICKET_ID]",
fields: "summary,description,issuetype,priority,status",
});
```
**Extract from response:**
- Summary (title)
- Description
- Issue type
- Status
- Any other relevant context
### 3. Generate Branch Name
Create a branch name using this format:
```
[TICKET_ID]-[kebab-case-summary]
```
**Branch Naming Rules:**
- Start with the ticket ID (e.g., `AGP-782-`)
- Convert summary to kebab-case (lowercase, dashes instead of spaces)
- Remove special characters
- Keep it concise (max 50 characters total)
- Use meaningful words from the summary
**Examples:**
- `AGP-782-migrate-existing-mcp-server`
- `AICC-123-fix-auth-token-expiry`
- `PROJ-456-add-user-settings-page`
**Implementation:**
```bash
# Convert summary to kebab-case
# Example: "Migrate existing MCP server" -> "migrate-existing-mcp-server"
```
### 4. Check Current Git State
Before creating a branch, check the current state:
```bash
# Check current branch
git branch --show-current
# Check for uncommitted changes
git status --porcelain
```
**If uncommitted changes exist:**
- STOP and inform User
- Suggest: "You have uncommitted changes. Should I commit them first, stash them, or continue anyway?"
- Wait for User's decision
**If not on staging/main:**
- STOP and inform User
- Suggest: "You're currently on branch [CURRENT_BRANCH]. Should I switch to staging first?"
- Wait for User's decision
### 5. Create Branch
Once it's safe to proceed:
```bash
# Ensure we're on the latest staging
git checkout staging
git pull origin staging
# Create and checkout new branch
git checkout -b [TICKET_ID]-[kebab-case-summary]
```
Confirm to User: "Created and checked out branch: [BRANCH_NAME]"
### 6. Build Task Planning Prompt
Analyze the Jira ticket and create a comprehensive prompt for the `/eng:chore` command:
**Prompt should include:**
- The ticket summary
- Key details from the description
- Any acceptance criteria mentioned
- Relevant technical context
**Example prompt construction:**
```
Summary: [ticket.summary]
Description: [ticket.description]
Acceptance Criteria:
[extracted criteria if present]
```
### 7. Execute Task Planning
Run the `/eng:chore` slash command with the ticket number and constructed prompt:
```bash
/eng:chore [TICKET_ID] [CONSTRUCTED_PROMPT]
```
**Example:**
```bash
AGP-782 Migrate existing MCP server implementation to new architecture
Description: We need to refactor the MCP server to use the new modular architecture. This includes updating the tool registry, migrating existing tools, and ensuring backward compatibility.
Acceptance Criteria:
- All existing tools work with new architecture
- Tests pass
- No breaking changes to API
```
## Error Handling
**If ticket not found:**
- Inform User: "Couldn't find ticket [TICKET_ID] in Jira. Please check the ticket ID."
- STOP - don't proceed with branch creation
**If branch already exists:**
- Inform User: "Branch [BRANCH_NAME] already exists."
- Ask: "Should I check it out, create a new branch with a different name, or stop?"
- Wait for decision
**If git operations fail:**
- Show the error to User
- STOP - don't proceed to task planning
## Example Usage
### Example 1: Simple Ticket
**User:** "work on AGP-782"
**Claude:**
1. Fetches AGP-782 from Jira
2. Finds summary: "Migrate existing MCP server"
3. Checks git state (clean, on staging)
4. Creates branch: `AGP-782-migrate-existing-mcp-server`
5. Runs: `/eng:chore AGP-782 Migrate existing MCP server implementation...`
### Example 2: With Uncommitted Changes
**User:** "work on AICC-456"
**Claude:**
1. Fetches AICC-456 from Jira
2. Checks git state - finds uncommitted changes
3. **STOPS** and asks: "You have uncommitted changes. Should I commit them first, stash them, or continue anyway?"
4. Waits for User's decision
### Example 3: Ticket Not Found
**User:** "work on BAD-999"
**Claude:**
1. Tries to fetch BAD-999 from Jira
2. Ticket not found
3. Informs User: "Couldn't find ticket BAD-999 in Jira. Please check the ticket ID."
4. STOPS
## Coding Standards
**CRITICAL RULE - NESTED CONDITIONALS:**
- **NEVER EVER EVER USE NESTED CONDITIONALS** when working on tickets
- If you find yourself nesting if statements, STOP immediately
- Refactor using early returns, guard clauses, or extract functions
- This rule applies to all code written while working on any ticket
- Violation of this rule is FAILURE
**Why this matters:**
- Nested conditionals reduce readability and increase cognitive load
- They make code harder to test and maintain
- Early returns and guard clauses are always clearer
**Instead of:**
```typescript
if (condition1) {
if (condition2) {
// do something
}
}
```
**Do this:**
```typescript
if (!condition1) return;
if (!condition2) return;
// do something
```
**CRITICAL RULE - NO UNNECESSARY INLINE COMMENTS:**
- **NEVER add simple, obvious inline comments** that just restate what the code does
- Code should be self-documenting through clear variable names, function names, and structure
- Only add comments when they explain **WHY** something is done, not **WHAT** is being done
- Remove unnecessary comments during refactoring
- This rule applies to all code written while working on any ticket
- Violation of this rule is FAILURE
**Bad comments (obvious, unnecessary):**
```typescript
// Set the user's name
user.name = "Alice";
// Loop through the items
for (const item of items) {
// Process the item
processItem(item);
}
// Return true if valid
return isValid;
```
**Good comments (explain WHY, add context):**
```typescript
// Cache user data for 5 minutes to reduce API calls
const cachedUser = await cache.get(userId, { ttl: 300 });
// Process items in batches to avoid memory issues with large datasets
for (const batch of chunkArray(items, 100)) {
await processBatch(batch);
}
// Skip validation for admin users per security requirement SEC-123
if (user.isAdmin) return true;
```
**When comments ARE appropriate:**
- Explaining non-obvious business logic or requirements
- Documenting workarounds for external bugs (with issue links)
- Clarifying performance optimizations
- Noting security considerations
- Referencing ticket numbers or external documentation
**When to use NO comments:**
- If the code is self-explanatory
- If a better variable/function name would make it clear
- If the comment just repeats what the code obviously does
**CRITICAL RULE - VITEST TESTING:**
- **ALWAYS use the Vitest TDD Expert skill** when writing or working with Vitest tests
- Before writing any Vitest tests, activate the Vitest TDD Expert skill by invoking it with the Skill tool
- The Vitest TDD Expert skill enforces:
- **Red-Green-Refactor TDD cycle** (test first, always)
- **95%+ coverage requirements** with quality metrics
- **FIRST principles** (Fast, Independent, Repeatable, Self-validating, Timely)
- **Behavior-focused testing** (not implementation details)
- **Comprehensive edge case coverage** and error path testing
- **Anti-pattern avoidance** (no brittle tests, no excessive mocking)
- This ensures high-quality, maintainable test suites that provide confidence
- Violation of this rule means tests may be brittle, incomplete, or low quality
**When to activate Vitest TDD Expert:**
```typescript
// Before writing Vitest tests, invoke:
Skill({ skill: "vitest-tdd" });
```
## Important Notes
- **Always check git state** before creating branches
- **Never force-create branches** or overwrite existing branches
- **Never proceed** if there are uncommitted changes without User's approval
- **Keep branch names concise** - aim for clarity over completeness
- **Include ticket context** in the task planning prompt to give the planner maximum context
- **The `/eng:chore` command** will handle the detailed planning - this skill just sets up the environment
## Success Criteria
The skill is successful when:
1. ✅ Jira ticket is fetched successfully
2. ✅ Appropriate branch name is generated
3. ✅ Git state is verified (no uncommitted changes or user approved)
4. ✅ New branch is created and checked out
5. ✅ `/eng:chore` command is executed with ticket context
6. ✅ User is informed of each major step