Agent skill

Bugfix

by team-attention in team-attention/hoyeon

Root cause based one-shot bug fix. An agent skill from team-attention/hoyeon.

MITAuto-check passedDevelopment

Install Bugfix

skills CLI
$ npx skills add team-attention/hoyeon --skill bugfix -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install team-attention/hoyeon bugfix --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/team-attention/hoyeon.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/bugfix .claude/skills/bugfix && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
bugfix
GitHub stars
173
Token cost
~4.8k tokens
SKILL.md length
848 words
Files
1
Skills in repo
36
Repo updated
First seen
Licence
MIT

At a glance

Root cause based one-shot bug fix. An agent skill from team-attention/hoyeon.

  • Works in 5 steps: DIAGNOSE → REQUIREMENTS GENERATION → EXECUTE → …
  • Tasks that involve Debugging
  • SKILL.md covers The Iron Law, Architecture, Execution Mode and Phase 1: DIAGNOSE, plus 7 more sections
  • Calls git

What it does

Bugfix is an agent skill from team-attention/hoyeon. Root cause based one-shot bug fix. debugger diagnosis → requirements.md generation → /execute. /bugfix "error description" Full investigation pipeline: debugger + gap-analyzer + standard verify. QA suggestion after successful fix.

Its SKILL.md is about 4.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Debugging and Root cause analysis. The repository describes itself as: Requirements-first Harness — derive, verify, execute. The licence is MIT.

When your agent uses it

  • Tasks that involve Debugging
  • Tasks that involve Root cause analysis

Example prompts

  • “error description”
  • “/bugfix”

Requirements

  • Python 3

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. DIAGNOSE
  2. REQUIREMENTS GENERATION
  3. EXECUTE
  4. RESULT HANDLING
  5. CLEANUP & REPORT

What it can do on your machine

Read from SKILL.md and the folder at commit 7cff032. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Bugfix loads about 4.8k tokens when it runs. Until then it costs about 59 tokens; SKILL.md has 848 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~59
When it runs · the whole SKILL.md, loaded when a task matches
~4.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from team-attention/hoyeon at commit 7cff032, republished under its MIT licence (© team-attention). 848 words, ~4,783 tokens.

Download SKILL.mdSave it as .claude/skills/bugfix/SKILL.md (or your agent's skills folder).
name
bugfix
description
Root cause based one-shot bug fix. debugger diagnosis → requirements.md generation → /execute. /bugfix "error description" Full investigation pipeline: debugger + gap-analyzer + standard verify. QA suggestion after successful fix.
validate_prompt
Must complete with one of: 1. Execute completed successfully (all plan.json tasks done) 2. Circuit breaker triggered (max attempts exhausted, report saved) 3…

/bugfix Skill

Root cause based one-shot bug fix. Diagnose → generate requirements.md → delegate to /execute for fix, verification, and commit.

The Iron Law

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
No completion claims without evidence
Must stop after 3 failed attempts

Architecture

/bugfix "error description"

Phase 1: DIAGNOSE ─────────────────────────────────
  debugger + verification-planner + gap-analyzer (all parallel)
  → Blast-radius grep scan + Triage recommendation
  → User confirmation (includes triage hint)

Phase 2: REQUIREMENTS GENERATION ──────────────────
  Diagnosis results → requirements.md (hoyeon-cli req init + Write)

Phase 3: EXECUTE ──────────────────────────────────
  Skill("execute", args=spec_dir)
  → Success: Phase 5
  → HALT: Phase 4

Phase 4: RESULT HANDLING (if HALT) ────────────────
  Retry (max 3) with stagnation detection → Phase 3
  Circuit breaker → .hoyeon/debug/{slug}.md → suggest /specify

Phase 5: CLEANUP & REPORT ─────────────────────────
  Save .hoyeon/debug/{slug}.md → final summary

Execution Mode

Always runs the full investigation + execution pipeline. No SIMPLE/COMPLEX branching.

Phase 1Retry
debugger + verification-planner + gap-analyzerbugfix-managed (max 3)

/execute will prompt for dispatch/work/verify via AskUserQuestion when invoked — bugfix does not pre-select these modes.


Phase 1: DIAGNOSE

Step 1.1: Parse Input

Extract from user input:

  • Bug description: error message, symptoms, reproduction steps
  • Error output: stack trace, test failure logs (if available)
  • Context: related files, recent changes (if available)

Initialize Debug State:

SESSION_ID = [from hook — $CLAUDE_SESSION_ID]
slug = convert bug description to kebab-case (e.g. "null-pointer-in-auth")
DEBUG_STATE = "$HOME/.hoyeon/$SESSION_ID/debug-state.md"
hoyeon-cli session set --sid $SESSION_ID --json '{"skill":"bugfix","debug":"'"$DEBUG_STATE"'"}'

Write(DEBUG_STATE):
# Debug: {bug description}
status: investigating

attempt: 0
slug: {slug}

## Symptoms (IMMUTABLE after Phase 1)
- expected: {from user input}
- actual: {from user input}
- error: {from user input}

## Diagnosis
root_cause: pending
spec_dir: pending

## Attempts
Step 1.2: Parallel Investigation

Always dispatch 2 agents in parallel:

Task(debugger):
  "Bug Description: {user input}
   Error Output: {error logs, if available}
   Context: {related files/recent changes, if available}

   Investigate this bug following your Investigation Protocol.
   Classify Bug Type, trace backward to root cause, assess Severity."

Task(verification-planner):
  "User's Goal: Fix the bug described below
   Current Understanding: {user input}
   Work Breakdown:
   - Reproduce bug with test
   - Apply minimal fix at root cause
   - Verify fix resolves the issue

   Focus on Auto items only (what commands prove the fix works).
   Keep it minimal — this is a bug fix, not a feature.

   Note: /bugfix uses Tier 1-3 (Auto items) only. Do not inline VERIFICATION.md.
   Tier 4 (sandbox items) are not needed. Mark sandbox section as 'bugfix mode — Tier 1-3 only'."

After receiving debugger results, update debug-state.md:

Update DEBUG_STATE:
  ## Diagnosis section:
  root_cause: {debugger's Root Cause — 1 line}
  bug_type: {classification}
  proposed_fix: {proposed fix — 1 line}
Step 1.3: Gap Analysis

Always run gap-analyzer after debugger results:

Task(gap-analyzer):
  "User's Goal: Fix the bug below
   Current Understanding: {debugger's full Bug Analysis Report}
   Intent Type: Bug Fix

   Focus on:
   - Whether root cause vs symptom distinction is correct
   - Whether proposed fix could break other areas
   - Whether similar bugs exist with the same pattern"
Step 1.3b: Blast-radius Quick Scan

After debugger identifies root_cause.location (e.g. src/auth/token.ts:42), extract the function/module name and run grep-based structural scan. Always use wc -l so the LLM compares integers, not raw grep output.

bash
# Extract from debugger's Root Cause section:
#   fn   = function or symbol name at the root cause (e.g. "parseToken")
#   mod  = module path without extension (e.g. "src/auth/token")
# If the function name cannot be reliably extracted, set fn="" and skip caller_count.

total_files=$(git ls-files | wc -l | tr -d ' ')
callers=$(git grep -l -F "$fn" 2>/dev/null | wc -l | tr -d ' ')
importers=$(git grep -l -F "$mod" 2>/dev/null | wc -l | tr -d ' ')
test_refs=$(git grep -l -F "$fn" -- '**/*test*' '**/*spec*' 2>/dev/null | wc -l | tr -d ' ')
hot_path=$(git grep -l -F "$fn" -- 'migrations/**' 'auth/**' 'payment/**' 'billing/**' 'schema/**' 2>/dev/null | wc -l | tr -d ' ')

Use -F (fixed string) to avoid regex injection from extracted symbols. Empty or malformed symbols → skip that signal, do NOT fail the phase.

Store the scan in DEBUG_STATE:

Update DEBUG_STATE:
  ## Diagnosis:
    blast:
      total_files: {total_files}
      callers: {callers}
      importers: {importers}
      tests: {test_refs}
      hot_path: {hot_path}

Blind-spot note: grep misses dynamic dispatch, reflection, and non-JS/Python import forms. Low counts = no data, not safety.

Step 1.3c: Triage Recommendation

Compute a routing hint from the scan. This is advisory only — actual routing decision happens at Step 1.4 with user input.

Rules (first match wins):

ConditionHint
hot_path > 0/specify recommended — touches critical path (auth/payment/migration/schema)
debugger.severity == COMPLEX AND callers > 10 AND callers > total_files × 0.05/specify recommended — wide blast radius ({callers} callers, >5% of repo)
debugger.assumptions section non-empty AND root cause text contains uncertainty markers (?, 추정, possibly, may, unclear)/discuss recommended — root cause unclear
none of the abovebugfix appropriate

Store the hint in DEBUG_STATE:

Update DEBUG_STATE:
  triage:
    hint: {specify|discuss|bugfix}
    reason: "{1-line reason}"
Step 1.4: User Confirmation

Present debugger results + blast-radius scan + triage hint for user confirmation.

The triage hint is advisory — the user always makes the final routing decision.

AskUserQuestion:
  header: "Root Cause & Triage"
  question: "Review diagnosis and choose how to proceed."

  Display:
  - Bug Type: [classification]
  - Root Cause: [file:line + 1-line description]
  - Proposed Fix: [change description — 1 line]
  - Verification: [verification commands from verification-planner]
  - Assumptions: [debugger's Assumptions section]
  - Key warnings from Gap Analysis

  - Blast Radius: callers={N}, importers={M}, tests={T}, hot_path={H}
  - Triage: {hint from Step 1.3c} — {reason}
    (e.g. "/specify recommended — touches auth/ (hot path)")

  options:
  - "Continue with bugfix" → Phase 2
      (if triage hint != bugfix, show as "Continue with bugfix (override triage)")
  - "Switch to /specify" → Hand off requirements.md + debug-state.md to /specify
  - "Switch to /discuss" → Exit bugfix, suggest running /discuss with the bug context
  - "Root cause is different" → Re-run Step 1.2 with user's additional info
  - "Stop" → Exit

Handoff on /specify selection:

# requirements.md hasn't been written yet (Phase 2 is skipped on handoff),
# but debug-state.md contains all Phase 1 findings. Save a skeleton so /specify
# has a starting point, then exit bugfix.

hoyeon-cli req init ${SPEC_DIR} --type bugfix --goal "Fix: {bug description}"
# Append debugger report + blast scan to ${SPEC_DIR}/requirements.md as context
# (sections: ## Debug Context, ## Blast Radius)

Update DEBUG_STATE: status: escalated, reason: "user_triage_specify"

print("Handed off to /specify. Run: /specify {SPEC_DIR}")

Phase 2: REQUIREMENTS GENERATION

Convert diagnosis results into requirements.md format. requirements.md is the standard format consumed by /execute, and serves as escalation context for /specify on failure.

Step 2.1: Initialize
SPEC_DIR = "$HOME/.hoyeon/$SESSION_ID"

hoyeon-cli req init ${SPEC_DIR} --type bugfix --goal "Fix: {bug description}"

This creates ${SPEC_DIR}/requirements.md with a stub template.

Step 2.2: Write requirements content

Overwrite ${SPEC_DIR}/requirements.md with the full requirements derived from diagnosis results. Use the Write tool directly.

What to include:

markdown
---
type: bugfix
goal: "Fix: {bug description}"
non_goals:
  - "No refactoring beyond the fix"
  - "No unrelated feature changes"
---

# Requirements

## R-B1: {Bug fix requirement title — describes the broken behavior}
- behavior: {one-sentence description of what should work correctly after fix}

#### R-B1.1: {sub-requirement — the core bug scenario}
- given: {the precondition/state that triggers the bug}
- when: {the action that exercises the broken path}
- then: {the expected (post-fix) outcome — what "fixed" looks like}

#### R-B1.2: {sub-requirement — edge case or similar issue, if any}
- given: {precondition for the edge case}
- when: {action that triggers it}
- then: {expected outcome}

## R-T1: Minimal diff constraint
- behavior: Fix targets root cause only with minimal code changes

#### R-T1.1: Root cause targeting
- given: {root cause identified at file:line}
- when: the fix is applied
- then: only the root cause location is modified, no unrelated changes

## Constraints
- Minimal diff (<5% of codebase)
- Fix root cause, not symptom
- No refactoring beyond what the fix requires

Mapping rules:

  • Convert debugger's reproduction steps into GWT (given/when/then) for each sub-requirement
  • given: the precondition/state that triggers the bug
  • when: the action that exercises the broken path
  • then: the expected (post-fix) outcome
  • If debugger identified edge cases / similar issues, add sub-requirements for each (one sub per scenario)
  • Include a constraints section with fix-scope guardrails
Step 2.3: Register
bash
hoyeon-cli session set --sid $SESSION_ID --spec "$SPEC_DIR"

Update debug-state.md with spec_dir: ${SPEC_DIR}.


Phase 3: EXECUTE

Hand off requirements.md to /execute. Execute2 reads requirements.md from the spec dir and derives plan.json internally.

Skill("execute", args="${SPEC_DIR}")

What execute handles:

  • Prompts the user for dispatch / work / verify via AskUserQuestion
  • Worker dispatch according to the chosen dispatch mode
  • Round-level commit
  • Verify recipe according to the chosen verify depth
  • Final report

Result judgment:

IF execute completed successfully (all tasks done, report output):
  → Phase 5

IF execute HALTED:
  → Phase 4

Phase 4: RESULT HANDLING

When execute HALTs.

Step 4.1: Read Failure Context
# Extract failure reason from execute's HALT output
# or read from context dir's audit.md, issues.json
CONTEXT_DIR = "${SPEC_DIR}/context"
failure_reason = {execute HALT output or last triage result from audit.md}
Show full SKILL.md (342 more words)Show less
Step 4.2: Retry
# Read current attempt from debug-state.md
attempt = debug_state.attempt + 1
MAX_ATTEMPTS = 3

IF attempt >= MAX_ATTEMPTS:
  → Step 4.5 (Circuit Breaker)

Stagnation Detection (attempt >= 2):

# Compare with previous attempt failure info
previous = debug_state.Attempts[-1]
current_reason = failure_reason

SPINNING:    same file/component fails consecutively
OSCILLATION: A fails → B fails → A fails (circular)
NO_PROGRESS: different failures each time, previous fixes cause regressions

Pattern-specific retry_hint:
  SPINNING    → "Different root cause likely. Consider: previous root cause
                 was wrong — trace further back from the symptom."
  OSCILLATION → "Circular dependency. Fix both sides simultaneously."
  NO_PROGRESS → "Fundamental misunderstanding. Re-read error output.
                 Consider: multiple independent bugs? Missing dependency?"
  (no pattern) → "Different approach needed. Do NOT repeat previous attempt."
Step 4.4: Update Requirements & Re-execute
# 1. Record attempt in debug-state.md
Append to DEBUG_STATE ## Attempts section:
  ### Attempt {attempt}
  result: FAIL
  reason: {failure_reason}
  pattern: {detected pattern or "none"}
  hint: {retry_hint}

# 2. Update attempt counter
Update DEBUG_STATE: attempt: {attempt}

# 3. Add failure context to requirements.md
#    Read current requirements.md, append failure context to the Constraints
#    section or add a "## Known Issues" section with the failure info and
#    retry hint so the next worker has context.
#    Use Edit tool to append to requirements.md.

# 4. Re-invoke execute
#    /execute reads plan.json next to requirements.md. Do NOT touch plan.json
#    directly from bugfix — /execute handles task status and re-derivation.
#    If you need to reset failed tasks to pending so /execute will re-run them,
#    do it via the plan CLI:
#      hoyeon-cli plan list ${SPEC_DIR}
#      hoyeon-cli plan task ${SPEC_DIR} --status <task-id>=pending
#    In most cases /execute will resume on its own from the existing plan.json.

# 5. Re-invoke execute
→ Phase 3

Execute2 handles resume naturally:

  • Reads existing plan.json and skips done tasks
  • Context files (learnings.json, issues.json — in the context dir) retain previous failure info for the new worker
  • Known Issues section in requirements.md carries failure context and retry_hint for the worker
Step 4.5: Circuit Breaker

Max attempts exceeded. Present escalation options to user.

First, save attempt records:

Bash: mkdir -p .hoyeon/debug

Write to .hoyeon/debug/{slug}.md:
  # Bugfix Report: {description}
  Date: {timestamp}
  Status: ESCALATED
  Attempts: {attempt count}
  Spec Dir: {SPEC_DIR}

  ## Debugger Analysis
  {debugger's full Bug Analysis Report}

  ## Attempt History
  {full ## Attempts section from debug-state.md}

  ## Assessment
  "{attempt} attempts failed. Architecture-level issue likely."

Update DEBUG_STATE:
  status: escalated
AskUserQuestion:
  header: "Circuit Breaker"
  question: "Fix attempts have failed. This may be an architecture-level issue."
  options:
  - "Switch to /specify (full planning)"
    → "requirements.md and debug report are available:
       Spec Dir: {SPEC_DIR}
       Report: .hoyeon/debug/{slug}.md
       /specify can reference this context for deeper analysis."
  - "Try once more"
    → attempt += 1, go to Phase 3 (no circuit breaker reset)
  - "Stop"

Phase 5: CLEANUP & REPORT

After execute completes successfully.

Step 5.1: Save Debug Report
Bash: mkdir -p .hoyeon/debug

Write to .hoyeon/debug/{slug}.md:
  # Bugfix Report: {description}
  Date: {timestamp}
  Status: RESOLVED
  Attempts: {attempt count + 1}
  Spec Dir: {SPEC_DIR}

  ## Root Cause
  {debugger's Root Cause analysis}

  ## Fix
  {proposed fix from debugger + result summary from /execute's final report}

  ## Verification
  {verification results from execute's final report}

Update DEBUG_STATE:
  status: resolved
Step 5.2: Final Summary
print("""
## Bugfix Complete

**Bug**: {description}
**Root Cause**: {file:line — 1-line description}
**Attempts**: {count}
**Spec Dir**: {SPEC_DIR}
**Report**: .hoyeon/debug/{slug}.md
""")
Step 5.3: QA Suggestion

After successful fix, offer QA verification via browser/app:

AskUserQuestion:
  header: "QA"
  question: "Fix complete. Run QA to verify in browser/app?"
  options:
  - "Yes — run /qa"
    → Skill("qa", args="Verify bugfix: {description}. Root cause was at {file:line}. Check that the fix works and no regressions.")
  - "No — done"
    → End

Escalation Path

/bugfix (diagnose + requirements.md + execute)
   ↓ circuit breaker (3 failures)
   ↓ requirements.md + .hoyeon/debug/{slug}.md saved
/specify (requirements.md enrichment, leveraging existing diagnosis context)
   ↓
/execute (enriched requirements execution)

Since requirements.md is the standard format, /specify can read and enrich the existing requirements on escalation. All diagnosis context (constraints, known issues, GWT scenarios) is preserved.


Agent Summary

PhaseAgentStatusConditionRole
1debuggerexistingalwaysRoot cause analysis, Bug Type classification
1verification-plannerexistingalwaysGenerate Auto items list (verification commands)
1gap-analyzerexistingalwaysCheck for missed factors, risk assessment
1.5Bash (git grep + wc -l)newalwaysBlast-radius scan + triage hint (no agent, direct grep)
3/execute (Skill)existingalwaysrequirements.md-based execution (worker, verify, commit, review)
5/qa (Skill)existinguser opts inBrowser/app QA verification of the fix

Phase 2 (REQUIREMENTS GENERATION) and Phase 4 (RESULT HANDLING) are handled directly by bugfix without agents (hoyeon-cli calls + Write tool + judgment logic).


Design Principles

This skill combines core patterns from 3 proven open-source projects:

PrincipleSourceApplication
Root cause before fixsuperpowers (systematic-debugging)Entire Phase 1
Backward call stack tracingsuperpowers (root-cause-tracing)debugger's Step 3
Defense-in-depth after fixsuperpowers (defense-in-depth)Optional worker application
Anti-pattern rationalizationssuperpowers (common rationalizations)debugger's checklist
Bug Type → Tool routingoh-my-opencode (Metis intent classification)debugger's tool table
Full investigationoh-my-opencode (Momus "80% is good enough")Always gap-analyzer + standard verify
Minimal diff (<5%)oh-my-claudecode (executor/build-fixer)requirements constraint
Circuit breaker (3 attempts)oh-my-claudecode (debugger) + superpowersPhase 4
requirements.md as universal formatinternal (specify/execute unification)Phase 2
Execute reuseinternal (single execution engine)Phase 3
Advisory triage (grep blast-radius + user choice)internal (bugfix lightweight escalation)Phase 1.5 / Step 1.4

© team-attention, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/bugfix of team-attention/hoyeon.

Open the folder on GitHubat commit 7cff032

Compare with similar skills

Bugfix next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Bugfix compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Bugfix this skillteam-attention/hoyeon173—~4.8kAutomated safety check: PassMIT
OpenLogi macOS Permissions TriageAprilNEA/OpenLogi23k—~2.5kAutomated safety check: NotesApache-2.0
Bug Finder for daisyUIsaadeghi/daisyui43k—~2.3kAutomated safety check: PassMIT
Root Cause Debugginggarrytan/gstack136k—~1.4kAutomated safety check: PassMIT
Graph-Based Bug Tracingtirth8205/code-review-graph32k1 repos~287Automated safety check: PassMIT
Systematic DebuggingChrisWiles/claude-code-showcase6.1k3 repos~1.2kAutomated safety check: PassNone

Similar skills

  • Decides whether an OpenLogi device problem on macOS is a privacy-permission (TCC) problem, using agent log lines, and says which identity needs which grant.

    23k GitHub stars~2.5k tokensUpdated 4 days ago
    DevelopmentAuto-check: notes
  • Bug Finder for daisyUI

    saadeghi/daisyui

    Investigates suspected bugs in the daisyUI monorepo through read-only analysis, then writes a decision-ready fix plan in tmp/bugs without changing any product code.

    43k GitHub stars~2.3k tokensUpdated 8 days ago
    DevelopmentAuto-check passed
  • Root Cause Debugging

    garrytan/gstack

    Investigates bugs, errors and stack traces in phases and requires a root-cause hypothesis to be confirmed before any fix is written.

    136k GitHub stars~1.4k tokensUpdated today
    DevelopmentAuto-check passed
  • Graph-Based Bug Tracing

    tirth8205/code-review-graph

    Traces a bug through a code knowledge graph, following callers, callees and execution flow before opening source files, within a small token budget.

    32k GitHub starsUsed in 1 repo~287 tokens
    DevelopmentAuto-check passed
  • Systematic Debugging

    ChrisWiles/claude-code-showcase

    Applies a four-phase debugging routine that finds the root cause of a bug or failing test before any fix is written.

    6.1k GitHub starsUsed in 3 repos~1.2k tokens
    DevelopmentAuto-check passed
  • Debugging and Error Recovery

    addyosmani/agent-skills

    Applies a stop-the-line rule and a step-by-step triage when tests fail, builds break or something stops working, aiming at the root cause instead of guesses.

    103k GitHub starsUsed in 1 repo~2.6k tokens
    DevelopmentAuto-check passed

More from team-attention/hoyeon

All 36 skills in this repo
  • Skill Session Analyzer

    team-attention/hoyeon

    This skill should be used when the user asks to "analyze session", "evaluate skill execution", "check session logs", provides a session ID with a skill path, or wants to verify that a skill executed…

    173 GitHub stars~1.9k tokensUpdated 4 mo ago
    Auto-check: notes
  • Browser Work

    team-attention/hoyeon

    Recon-first browser automation. An agent skill from team-attention/hoyeon.

    173 GitHub stars~1.9k tokensUpdated 4 mo ago
    Auto-check passed
  • Check

    team-attention/hoyeon

    This skill should be used when the user wants to verify their changes before pushing, or update the project's rule checklists.

    173 GitHub stars~1.8k tokensUpdated 4 mo ago
    Auto-check: notes
  • Compound

    team-attention/hoyeon

    This skill should be used when the user says "/compound", "compound this", "document learnings", "save what we learned", or after completing a PR.

    173 GitHub stars~1.1k tokensUpdated 4 mo ago
    Auto-check: notes
  • QA

    team-attention/hoyeon

    Systematically QA test any application — web apps, native macOS apps, Electron apps, CLI tools, interactive REPLs, or anything on screen.

    173 GitHub stars~2.6k tokensUpdated 4 mo ago
    Auto-check: notes
  • Dev Scan

    team-attention/hoyeon

    Collect diverse opinions on technical topics from developer communities.

    173 GitHub starsUsed in 1 repo~5k tokens
    Auto-check passed

Categories

Questions about Bugfix

What does Bugfix do?

Root cause based one-shot bug fix. An agent skill from team-attention/hoyeon. Bugfix is an agent skill from team-attention/hoyeon. Root cause based one-shot bug fix.

When should I use Bugfix?

Bugfix fits situations like: tasks that involve Debugging; tasks that involve Root cause analysis.

How do I install Bugfix in Claude Code?

Run `npx skills add team-attention/hoyeon --skill bugfix -a claude-code`. Or copy the skill folder (skills/bugfix in team-attention/hoyeon) into .claude/skills/bugfix in your project. Claude Code loads it when a task matches its description.

How do I install Bugfix in Codex?

Run `npx skills add team-attention/hoyeon --skill bugfix -a codex`. Or copy the skill folder (skills/bugfix in team-attention/hoyeon) into .agents/skills/bugfix in your project. Codex loads it when a task matches its description.

Can I use Bugfix in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add team-attention/hoyeon --skill bugfix -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/bugfix, .gemini/skills/bugfix, .github/skills/bugfix and .opencode/skills/bugfix in your project.

What does Bugfix need to run?

Going by SKILL.md and its folder, Bugfix needs the command-line tools its instructions call (git). Our summary lists: Python 3.

Does Bugfix access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Bugfix safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Bugfix use?

Bugfix is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Bugfix use?

About 4.8k tokens (SKILL.md is roughly 19k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Bugfix?

Skills that share tags, products or a category with Bugfix: OpenLogi macOS Permissions Triage (AprilNEA/OpenLogi, 23k stars), Bug Finder for daisyUI (saadeghi/daisyui, 43k stars), Root Cause Debugging (garrytan/gstack, 136k stars) and Graph-Based Bug Tracing (tirth8205/code-review-graph, 32k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Bugfix?

team-attention (a GitHub organization) maintains it in team-attention/hoyeon, which has 173 GitHub stars. The repository holds 36 skills in this directory. The repository was last updated on May 21, 2026.

Source: team-attention/hoyeon on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.