# Cursor Skills That Run Bugfix Operations End-to-End *How I use skill-driven code agents to take bugs from ticket to validated PR with less manual coordination.* This post is not about generic AI productivity. It is about concrete operational automation I run in production with custom Cursor skills. At a practical level, these skills automate the repetitive engineering operations around bugfix delivery: - 🔹 Sourcing the next bug from Asana using constraints - 🔹 Investigating whether the issue is already fixed on base branch - 🔹 Claiming task ownership and moving workflow state - 🔹 Creating isolated worktrees and ticket-scoped branches - 🔹 Implementing the smallest safe fix with regression coverage - 🔹 Running validation gates before opening review load - 🔹 Writing structured PR summaries and test plans - 🔹 Posting PR links and validation evidence back to Asana This is the work that usually burns lead and senior IC time. The skills system handles the mechanics so humans can focus on decisions. ## What this stack automates in production When people ask what the skills actually do, I describe it as an execution loop: - ✅ Code agents fix narrowly scoped bugs instead of producing broad, risky diffs - ✅ Agents generate reviewer-ready PR context (root cause, scope, test evidence) - ✅ Agents keep Asana and GitHub in sync so status is not stale - ✅ Agents run repeatable validation and stop before PR if checks fail - ✅ Agents can process backlog tickets in sequence with safe widening logic Why this matters: - 🔹 Less coordination tax for leaders - 🔹 Faster bugfix throughput without dropping quality - 🔹 Cleaner handoff between implementation and review - 🔹 Better visibility into what shipped and why ## Install this workflow in Cursor and Claude Code If you want to copy this operating model, installation is straightforward. The goal is simple: keep each skill in its own folder with a SKILL.md file so your agent can discover and invoke it. ### Prerequisites (CLI + MCP) Install the core command-line tools first: ~~~bash # macOS brew install git gh node ~~~ ~~~bash # Verify installs git --version gh --version node --version npm --version ~~~ Authenticate GitHub CLI: ~~~bash gh auth login gh auth status ~~~ Set up ticket-system access (choose one or both): - ✅ **Asana via MCP (recommended):** configure Asana MCP in your agent environment, then verify with a simple 'get_task' or search call. - ✅ **Jira via MCP (recommended):** configure Jira MCP and verify with a basic issue query before running skills. - ⚠️ **CLI alternative (assumption):** Jira often uses Atlassian CLI (acli) in enterprise environments; Asana is usually cleaner through MCP or API scripts instead of a single standard CLI. Minimum MCP readiness checklist: - ✅ API token is present and scoped correctly - ✅ Project/workspace IDs are confirmed - ✅ Tool schemas are readable from your MCP server config - ✅ A read call and a write call both succeed in a sandbox ticket ### Cursor installation (project-local and global) For project-local usage inside a repo: ~~~bash mkdir -p .cursor/skills/release-bugfix-lifecycle mkdir -p .cursor/skills/parallel-worktree-operations mkdir -p .cursor/skills/teammate-pr-review mkdir -p .cursor/skills/team-agent-showcase ~~~ Then place each skill file at: - '.cursor/skills/release-bugfix-lifecycle/SKILL.md' - '.cursor/skills/parallel-worktree-operations/SKILL.md' - '.cursor/skills/teammate-pr-review/SKILL.md' - '.cursor/skills/team-agent-showcase/SKILL.md' For global usage across repositories: ~~~bash mkdir -p ~/.cursor/skills/release-bugfix-lifecycle mkdir -p ~/.cursor/skills/parallel-worktree-operations mkdir -p ~/.cursor/skills/teammate-pr-review mkdir -p ~/.cursor/skills/team-agent-showcase ~~~ Then copy the same SKILL.md files into those directories. ### Claude Code installation Assumption: your Claude Code setup uses '~/.claude/skills' as the user-level skills directory. ~~~bash mkdir -p ~/.claude/skills/release-bugfix-lifecycle mkdir -p ~/.claude/skills/parallel-worktree-operations mkdir -p ~/.claude/skills/teammate-pr-review mkdir -p ~/.claude/skills/team-agent-showcase ~~~ Copy files to: - '~/.claude/skills/release-bugfix-lifecycle/SKILL.md' - '~/.claude/skills/parallel-worktree-operations/SKILL.md' - '~/.claude/skills/teammate-pr-review/SKILL.md' - '~/.claude/skills/team-agent-showcase/SKILL.md' ### Verify skills are loading correctly Use these checks after installation: - ✅ Restart Cursor or Claude Code session. - ✅ Run a direct invocation prompt for one skill. - ✅ Confirm the agent references the specific lifecycle/worktree/review behavior from your file. - ✅ If behavior is generic, check folder name and file path first. Example smoke prompts: ~~~text Use release-bugfix-lifecycle on this repo and source the next unassigned Release 1 bug. ~~~ ~~~text Use parallel-worktree-operations to investigate three candidate tickets in parallel, then pick one to implement. ~~~ ### Recommended folder hygiene - Keep one responsibility per skill. - Keep descriptions explicit and operational. - Link companion skills from each core skill. - Avoid giant all-in-one skill files. - Version skill changes with your repo so behavior is auditable. ### Markdown formatting notes (so bullets render correctly) If your blog parser is Markdown/MDX, these conventions prevent rendering glitches: - Keep a blank line before and after bullet lists. - Use '-' for unordered lists and '1.' style for ordered lists. - Avoid indenting list lines unless intentionally nesting. - Use fenced code blocks ('~~~bash', '~~~text') so command snippets stay intact. - Keep one list item per line for predictable styling. ## The skill stack in this repo and why I separated responsibilities These are the four skill files and their jobs: - 🔹 release-bugfix-lifecycle: the end-to-end operational backbone - 🔹 parallel-worktree-operations: safe concurrency and worktree discipline - 🔹 teammate-pr-review: findings-first quality review - 🔹 team-agent-showcase: internal communication and explainability layer I intentionally keep these responsibilities separated. One monolithic skill becomes brittle quickly. Separation gives me: - ✅ Cleaner failure boundaries - ✅ Easier maintenance and versioning - ✅ Better reuse across single-ticket and bulk-ticket modes - ✅ Stronger explainability for leadership and auditors ### Skill 1: release-bugfix-lifecycle This skill defines the full ticket lifecycle from sourcing to handoff. It covers: - 🔹 Asana sourcing strategy and narrowing logic - 🔹 Claim and ownership transitions - 🔹 Branch and worktree isolation - 🔹 Implementation scope controls - 🔹 Testing and validation gates - 🔹 Screenshot evidence handling - 🔹 PR template and quality requirements - 🔹 Asana state synchronization on claim, blocker, and ship ~~~markdown --- name: release-bugfix-lifecycle description: End-to-end backlog workflow for sourcing, claiming, fixing, validating, screenshotting, and shipping bugfix tasks from Asana to GitHub with status synchronization. --- ## Default Sourcing Strategy 1. Unassigned release bugs at the requested priority band 2. Unassigned non-media bugs before media bugs if the user has asked to avoid media 3. Assigned backlog bugs only after unassigned options are exhausted or the user explicitly allows widening 4. Feature requests or nice-to-haves only after true bugs are exhausted and the user wants to continue ## Branch And Worktree Workflow fix/-short-slug git worktree add -b "fix/-slug" "/path/to/worktree" origin/ ## Validation Checklist 1. Focused test file or test target 2. Lint for affected files or full lint 3. Generated-type step if the repo requires it 4. Typecheck 5. Any task-specific validation command ~~~ ### Skill 2: parallel-worktree-operations This skill makes parallelism disciplined instead of chaotic. It defines what can run concurrently and what must remain serial. ~~~markdown --- name: parallel-worktree-operations description: Run repository work in parallel with subagents and isolated git worktrees. --- ## Parallelization Rules Safe to parallelize: - ticket sourcing - codebase exploration - PR review vs bug triage - multiple isolated worktrees for different tickets Do not parallelize: - two agents editing the same branch - two agents changing the same files for the same solution - commands that depend on previous command output unless explicitly sequenced ## Worktree Strategy fix/-short-slug review/pr--short-slug experiment/- ~~~ ### Skill 3: teammate-pr-review This skill keeps review quality high while moving quickly. It enforces a findings-first review structure and branch-context analysis. ~~~markdown --- name: teammate-pr-review description: Pull teammate pull requests from remote, inspect the full diff and branch context, run focused validation, and produce a findings-first review. --- ## Review Mindset Findings first. Summaries second. Prioritize: - bugs - behavioral regressions - risky assumptions - missing tests - mismatch between ticket intent and implementation ## Writing The Review 1. Findings by severity 2. Open questions or assumptions 3. Brief summary of scope and validation ~~~ ### Skill 4: team-agent-showcase This skill handles internal communication and trust-building. It is the bridge from execution detail to leadership understanding. ~~~markdown --- name: team-agent-showcase description: Explain, demo, and package the team’s AI-assisted engineering workflow for internal audiences. --- ## Core Story To Tell 1. Integrated context 2. Safe isolation 3. Parallel evidence gathering 4. Strong operational loop 5. Model and mode discipline Do not oversell autonomy. Emphasize orchestration, isolation, validation, and human decision points. ~~~ ### Best Next.js pattern for scrollable skill code blocks If you want gist-style readable blocks in long-form posts, wrap long code in a container with max height and overflow auto. ~~~tsx export function ScrollCode({ children }: { children: React.ReactNode }) { return (

{children}

); } ~~~ Then place your skill block inside the wrapper in MDX. This keeps the page skimmable without hiding the source. ## Exact workflow: Asana ticket to merged PR Here is the exact path this stack drives. ### 1) Discovery in Asana via MCP I start by searching constrained candidates: release lane, priority, type, assignment status, and any exclusions such as non-media only. The lifecycle skill explicitly requires collecting ticket notes, comments, and attachment context before selecting a target. ### 2) Claim ownership and synchronize task state Once a ticket is selected: - 🔹 Assign owner - 🔹 Move task into active development section when applicable - 🔹 Add a concise start note when useful The skill warns against noisy updates when Asana already records the transition automatically. ### 3) Create isolated worktree and branch with ticket-first naming Every implementation happens outside a dirty local branch. Convention: ~~~text fix/-short-slug ~~~ Creation pattern: ~~~bash git worktree add -b "fix/-slug" "/path/to/worktree" origin/ ~~~ This is one of the most important safeguards in the system. ### 4) Implement the smallest scoped fix The lifecycle skill pushes for narrow scope: - 🔹 Change only what is necessary - 🔹 Preserve unrelated behavior - 🔹 Avoid broad refactors unless required by root cause - 🔹 Stop and ask humans when product behavior is ambiguous This keeps throughput high and review quality consistent. ### 5) Regression testing and validation gates The defined order is: - 🔹 focused regression test - 🔹 lint - 🔹 generated-type step if required - 🔹 typecheck - 🔹 task-specific validation No PR should be opened until validation is strong enough for review. ### 6) PR creation with structured summary and test plan The lifecycle skill includes a standard PR body structure: - 🔹 Summary bullets - 🔹 Test plan checklist - 🔹 Manual verification callouts when applicable - 🔹 Screenshot references for visual fixes That structure is not cosmetic. It reduces reviewer load and status update overhead. ### 7) Asana In Review and shipped updates with links and evidence On PR open, task updates include: - 🔹 Move to In Review or In Dev Review - 🔹 Assign review owner if needed - 🔹 Post PR link with concise summary and validation evidence This creates a clean ticket-to-PR audit trail. ## Bulk execution mode: processing multiple tickets safely Bulk mode is where this stack compounds value. The operating pattern: - 🔹 Use Asana MCP to fetch a constrained ticket set - 🔹 Investigate candidates in parallel - 🔹 Implement one ticket per isolated worktree and branch - 🔹 Validate each branch independently - 🔹 Open one PR per ticket - 🔹 Sync Asana per-ticket before moving on This gives you speed without branch chaos. ### Widening logic when constraints are exhausted The lifecycle skill defines a widening ladder for keep-going sessions: - 🔹 unassigned bugs in requested lane - 🔹 unassigned bugs with relaxed priority - 🔹 assigned bugs with low conflict risk - 🔹 adjacent features only if explicitly requested Widening is incremental and explicit. That prevents silent scope drift. ### Why parallel investigation plus isolated implementation works Parallelism is used for evidence gathering and selection, not uncontrolled editing. Worktree isolation ensures each implementation stream stays reviewable, revertible, and attributable to a single ticket. ## Safety and quality controls built into the stack ### Non-destructive git behavior The workflow avoids destructive history operations by default and keeps edits scoped to ticket branches. ### Worktree isolation One ticket, one branch, one worktree. This is the core anti-chaos primitive. ### Explicit human decision points When behavior is ambiguous, the workflow pauses for a product decision instead of inventing one. This is automation with judgment boundaries. ### Validation before PR Tests and checks run before creating reviewer load. The default behavior is evidence-first, not optimism-first. ### Durable screenshot evidence Both lifecycle and review skills call out expiring TestFlight image URLs. Important screenshots should be downloaded and attached in durable team-visible systems. ## Reusable production prompt stack These are the exact prompt patterns I reuse. ### A) Single-ticket lifecycle prompt ~~~text Use the release-bugfix-lifecycle skill on this repo. Repo: Asana project: Ticket: Base branch: Constraints: Owner on Asana: Please source or take the task, fix it, test it, capture screenshots if relevant, open a PR, and keep Asana updated through review. ~~~ ### B) Bulk-ticket prompt ~~~text Use release-bugfix-lifecycle plus parallel-worktree-operations. Fetch a constrained set of Asana tickets in with . Investigate in parallel, then process one-by-one: 1) create isolated branch/worktree 2) implement smallest safe fix 3) run validation 4) open one PR per ticket 5) move task to In Review with PR link and evidence When constrained tickets are exhausted, widen one level at a time and state what widened. ~~~ ### C) Keep-going continuation prompt ~~~text Keep going through the backlog with the current constraints and quality gates. Do not re-ask settled preferences unless behavior is ambiguous. After each ticket, return: - task id and title - branch name - PR URL - validation summary - Asana status update Then continue to the next candidate. ~~~ ## Outcomes this creates for engineering leadership This stack improves four things immediately: - ✅ Less time spent writing manual status updates - ✅ Higher throughput on scoped bugfix work - ✅ Better operational visibility across Asana and GitHub - ✅ Fewer interruptions asking where we are on specific tickets Claims that are assumptions (because they depend on your baseline metrics): - [Assumption] 30 to 60 percent reduction in weekly status-assembly time - [Assumption] measurable reduction in cycle-time variance on small bugfix tickets - [Assumption] faster reviewer response because PR summaries and validation are standardized ## Implementation Notes Before adopting this pattern, confirm: - ✅ Asana MCP access and permissions are working - ✅ GitHub auth via gh is stable - ✅ Base branch conventions are defined - ✅ Review ownership conventions are explicit - ✅ Screenshot storage policy exists for durable artifacts Caveats: - ⚠️ Parallel edits must remain file-isolated - ⚠️ Bulk mode should not bypass product clarification steps - ⚠️ Ticket quality still matters; underspecified tasks will slow any system - ⚠️ The workflow reduces status overhead, but it does not replace engineering judgment This workflow is the deliverable itself: a repeatable system for turning backlog input into validated engineering output with less reporting drag and clearer leadership visibility.