Skill Introduction

Overview

Triage a bug or issue by exploring the codebase to find root cause, then create a GitHub issue with a TDD-based fix plan. Use when user reports a bug, wants to file an issue, mentions "triage", or wants to investigate and plan a fix for a problem.

Core value

Turns reusable Testing know-how into an installable skill, helping users complete github, community, subagent work faster.

Target users

Developers, testers, and maintainers who handle Testing tasks in Focus Code.
Teams that already trust workflows or content from mattpocock.
Users who want standardized prompts, steps, or conventions instead of repeating setup work.

Best practices

Read the skill content first to confirm required inputs, expected outputs, and dependencies.
Try it on a small task before relying on it for critical work.
Add project-specific constraints such as coding style, target platform, test expectations, and delivery format.
For external sources, verify the source link, version, and recent maintenance activity.

Best use cases

Tasks related to github, community, subagent that need a reusable execution flow.
Converting a community repo, team convention, or personal workflow into day-to-day assistance.
Starting from a proven skill instead of writing prompts or procedures from scratch.

Limits and boundaries

Results depend on the quality of the original skill content and may need human correction.
It does not replace code review, tests, security review, or professional judgment.
External tools, APIs, account permissions, and local dependencies still need separate setup.

Differentiation

Structured around Testing, making it easier to discover and reuse than loose prompt snippets.
Marked as GitHub, which helps users judge trust and maintenance expectations.
Keeps the original source link available for repository, documentation, or discussion follow-up.
Tagged with github, community, subagent, so it can be filtered by concrete task intent.

Install and use

Install

Copy Install Command

focus install triage-issue-c0b477

View source

Detail Preview

SKILL.md

Primary filemarkdown4 KB

name: triage-issue description: Triage a bug or issue by exploring the codebase to find root cause, then create a GitHub issue with a TDD-based fix plan. Use when user reports a bug, wants to file an issue, mentions "triage", or wants to investigate and plan a fix for a problem.

Triage Issue

Investigate a reported problem, find its root cause, and create a GitHub issue with a TDD fix plan. This is a mostly hands-off workflow - minimize questions to the user.

Process

1. Capture the problem

Get a brief description of the issue from the user. If they haven't provided one, ask ONE question: "What's the problem you're seeing?"

Do NOT ask follow-up questions yet. Start investigating immediately.

2. Explore and diagnose

Use the Agent tool with subagent_type=Explore to deeply investigate the codebase. Your goal is to find:

Where the bug manifests (entry points, UI, API responses)
What code path is involved (trace the flow)
Why it fails (the root cause, not just the symptom)
What related code exists (similar patterns, tests, adjacent modules)

Look at:

Related source files and their dependencies
Existing tests (what's tested, what's missing)
Recent changes to affected files (git log on relevant files)
Error handling in the code path
Similar patterns elsewhere in the codebase that work correctly

3. Identify the fix approach

Based on your investigation, determine:

The minimal change needed to fix the root cause
Which modules/interfaces are affected
What behaviors need to be verified via tests
Whether this is a regression, missing feature, or design flaw

4. Design TDD fix plan

Create a concrete, ordered list of RED-GREEN cycles. Each cycle is one vertical slice:

RED: Describe a specific test that captures the broken/missing behavior
GREEN: Describe the minimal code change to make that test pass

Rules:

Tests verify behavior through public interfaces, not implementation details
One test at a time, vertical slices (NOT all tests first, then all code)
Each test should survive internal refactors
Include a final refactor step if needed
Durability: Only suggest fixes that would survive radical codebase changes. Describe behaviors and contracts, not internal structure. Tests assert on observable outcomes (API responses, UI state, user-visible effects), not internal state. A good suggestion reads like a spec; a bad one reads like a diff.

5. Create the GitHub issue

Create a GitHub issue using gh issue create with the template below. Do NOT ask the user to review before creating - just create it and share the URL.

<issue-template>

Problem

A clear description of the bug or issue, including:

What happens (actual behavior)
What should happen (expected behavior)
How to reproduce (if applicable)

Root Cause Analysis

Describe what you found during investigation:

The code path involved
Why the current code fails
Any contributing factors

Do NOT include specific file paths, line numbers, or implementation details that couple to current code layout. Describe modules, behaviors, and contracts instead. The issue should remain useful even after major refactors.

TDD Fix Plan

A numbered list of RED-GREEN cycles:

RED: Write a test that [describes expected behavior] GREEN: [Minimal change to make it pass]
RED: Write a test that [describes next behavior] GREEN: [Minimal change to make it pass]

...

REFACTOR: [Any cleanup needed after all tests pass]

Acceptance Criteria

Criterion 1
Criterion 2
All new tests pass
Existing tests still pass

</issue-template>

After creating the issue, print the issue URL and a one-line summary of the root cause.

triage issue