agentleFS
vasceannievasceannie/slopgate/.agents/skills/oma-debug/SKILL.md

oma-debug

Skill1 starsChanged 51 days agoMITView on GitHub

Bug diagnosis and fixing specialist - analyzes errors, identifies

We split this skill into the rules it gives an agent

13 rules. 13 are common, 0 are distinctive, and 0 are very specific to this project.

  • 13

    Common

    Most of the 4 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Must search for similar patterns after fixing

    line 48
  2. Common:

    ACQUIRE: Read failing code, tests, references, and similar patterns.

    line 59
  3. Common:

    FINALIZE: Document root cause, fix, test, and residual risk.

    line 63
  4. Common:

    If reproduction fails, use logs/tests to establish a weaker but explicit diagnostic signal.

    line 66
  5. Common:

    If the first fix fails verification, return to root-cause analysis.

    line 67
  6. Common:

    If similar patterns exist, inspect and patch only affected cases.

    line 68
  7. Common:

    If the request is actually feature work, route to the relevant implementation skill.

    line 69
  8. Common:

    If environment is missing, document the blocker and provide the closest static diagnosis.

    line 72
  9. Common:

    If no regression test is feasible, explain why and include manual verification.

    line 73
  10. Common:

    If fix scope grows, stop and call out the broader design issue.

    line 74
  11. Common:

    Every fix gets a regression test

    line 127
  12. Common:

    Search for similar patterns elsewhere after fixing

    line 128
  13. Common:

    Use the configured provider to locate the failing function, find callers, and search similar error patterns.

    line 132

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Debug Agent - Bug Fixing Specialist

Scheduling

Goal

Reproduce, diagnose, minimally fix, and regression-test bugs while preserving scope discipline and documenting root cause.

Intent signature

  • User reports a bug, crash, traceback, exception, error message, performance issue, intermittent failure, or regression.
  • User needs root cause analysis plus a minimal code fix and regression test.

When to use

  • User reports a bug with error messages
  • Something is broken and needs fixing
  • Performance issues or slowdowns
  • Intermittent failures or race conditions
  • Regression bugs

When NOT to use

  • Building new features -> use Frontend/Backend/Mobile agents
  • General code review -> use QA Agent

Expected inputs

  • Error message, failing behavior, reproduction steps, logs, test failure, or affected code path
  • Existing tests, stack traces, environment notes, and suspected regression boundary

Expected outputs

  • Root cause explanation
  • Minimal fix scoped to the failing behavior
  • Regression test or explicit reason it cannot be added
  • Bug documentation under .agents/results/bugs/ when appropriate

Dependencies

  • resources/execution-protocol.md, examples, checklist, common patterns, and debugging checklist
  • Local codebase search and symbol/reference tools
  • Project test, lint, typecheck, and runtime commands

Control-flow features

  • Branches by reproduction success, error class, suspected layer, and verification outcome
  • Reads logs/code/tests and writes code/tests/docs
  • Must search for similar patterns after fixing

Structural Flow

Entry

  1. Capture the reported symptom and suspected scope.
  2. Reproduce or establish the closest reliable failing signal.
  3. Identify affected files, tests, and related patterns.

Scenes

  1. PREPARE: Gather symptoms, logs, reproduction path, and verification command.
  2. ACQUIRE: Read failing code, tests, references, and similar patterns.
  3. REASON: Isolate root cause and reject unsupported hypotheses.
  4. ACT: Apply minimal fix and regression test.
  5. VERIFY: Re-run failing and related checks.
  6. FINALIZE: Document root cause, fix, test, and residual risk.

Transitions

  • If reproduction fails, use logs/tests to establish a weaker but explicit diagnostic signal.
  • If the first fix fails verification, return to root-cause analysis.
  • If similar patterns exist, inspect and patch only affected cases.
  • If the request is actually feature work, route to the relevant implementation skill.

Failure and recovery

  • If environment is missing, document the blocker and provide the closest static diagnosis.
  • If no regression test is feasible, explain why and include manual verification.
  • If fix scope grows, stop and call out the broader design issue.

Exit

  • Success: bug is fixed, regression coverage exists, and checks pass.
  • Partial success: root cause or verification blocker is explicit.

Logical Operations

Actions

ActionSSL primitiveEvidence
Reproduce failureCALL_TOOLTest/runtime/log command
Search affected codeREADCode, tests, symbols, references
Compare similar patternsCOMPAREPattern search
Infer root causeINFERDiagnostic reasoning
Write minimal fixWRITECode patch
Write regression testWRITETest patch
Verify behaviorVALIDATETests/checks
Report resultNOTIFYRoot-cause summary

Tools and instruments

  • Project test, lint, typecheck, runtime, and logging commands
  • Configured code-intelligence symbol/reference/pattern search with native fallback
  • Debugging checklist and bug report template

Canonical workflow path

rg "<error-message-or-symbol>"
rg --files

Then run the smallest reproduction command first, add a regression test, and re-run the failing check plus related tests.

Resource scope

ScopeResource target
CODEBASEFailing source, tests, and related patterns
LOCAL_FSBug reports and result artifacts
PROCESSReproduction and verification commands
MEMORYHypotheses, root-cause notes, verification evidence

Preconditions

  • A bug signal, symptom, or failing behavior is available.
  • Relevant code and verification path can be inspected or the blocker is stated.

Effects and side effects

  • Mutates source/tests only as needed for the fix.
  • May create bug documentation under .agents/results/bugs/.

Guardrails

  1. Reproduce first, then diagnose - never guess at fixes
  2. Identify root cause, not just symptoms
  3. Minimal fix: change only what's necessary
  4. Every fix gets a regression test
  5. Search for similar patterns elsewhere after fixing
  6. Document in .agents/results/bugs/

Code intelligence

Use the configured provider to locate the failing function, find callers, and search similar error patterns. Native search and scoped reads are supported fallbacks; see the shared capability contract.

References

  • Local code tools: ../_shared/core/code-intelligence.md (code search/navigation)
  • Execution steps (follow for the selected task): resources/execution-protocol.md
  • Checklist (pre-submit self-verification): resources/checklist.md
  • Error recovery: resources/error-playbook.md
  • Bug report template: resources/bug-report-template.md
  • Common patterns: resources/common-patterns.md
  • Debugging checklist (investigation guide, used during Steps 1-2): resources/debugging-checklist.md
  • Context loading: ../_shared/core/context-loading.md
  • Context budget: ../_shared/core/context-budget.md
  • Lessons learned: ../_shared/core/lessons-learned.md
  • Observability handoff: ../oma-observability/SKILL.md §Integrations — traces/logs by trace_id, 6-dim forensics

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.