agentleFS
The-Syntax-SlayerThe-Syntax-Slayer/skill-genie/skills/omnidebug-autopilot/SKILL.md

omnidebug-autopilot

Skill1 starsChanged 5 months agoMITView on GitHub

Autonomous end-to-end debugging skill for any codebase, language, and framework. Detects stack, reproduces failures, isolates root cause, applies minimal safe fixes, and verifies with tests/build/lint without user interruption.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

23 rules. About 0 are common, 21 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈21

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Default mode is autonomous execution: find root cause and ship a verified fix without pausing for user input.

    line 13
  2. Distinctive:

    Use this skill when requests include:

    line 17
  3. Distinctive:

    Do not ask follow-up questions during normal debugging.

    line 34
  4. Distinctive:

    Only stop when blocked by missing secrets, unavailable infrastructure, or destructive action risk.

    line 36
  5. Distinctive:

    If blocked, use the safest fallback and continue as far as possible.

    line 37
  6. Distinctive:

    Use debugging tools first: console logs and network requests before code edits.

    line 44
  7. Distinctive:

    Create one reproducible command.

    line 50
  8. Distinctive:

    Remove noise by disabling unrelated jobs and minimizing input.

    line 51
  9. Distinctive:

    Prefer deterministic seeds and controlled timing.

    line 52
  10. Distinctive:

    Test output with stack traces

    line 64
  11. Distinctive:

    Prefer the smallest change that resolves cause, not symptom masking.

    line 87
  12. Distinctive:

    Keep public API behavior stable unless the bug requires a behavior correction.

    line 88
  13. Distinctive:

    Add or update tests that fail before and pass after fix.

    line 89
  14. Very specific:

    Avoid temporary bypasses (@ts-ignore, disabled tests, silent catches).

    line 90
  15. Distinctive:

    All applicable gates must pass:

    line 94
  16. Distinctive:

    If any gate fails, loop back to Phase 4.

    line 101
  17. Distinctive:

    Use these scripts for browser bug reproduction and fix validation:

    line 105
  18. Distinctive:

    Use project-native commands first.

    line 127
  19. Distinctive:

    Verify with targeted tests, then full gates

    line 159
  20. Distinctive:

    Never claim success without passing verification.

    line 163
  21. Distinctive:

    Never skip tests to make status green.

    line 164
  22. Very specific:

    Never introduce permanent production console.log noise.

    line 165
  23. Distinctive:

    Never hardcode secrets or private endpoints.

    line 166

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

OmniDebug Autopilot

// TODO: split SKILL.md into smaller modules/components

Universal debugging skill for apps, services, libraries, and scripts across mainstream stacks. Default mode is autonomous execution: find root cause and ship a verified fix without pausing for user input.

Quick Start

Use this skill when requests include:

  • "debug this"
  • "fix this bug"
  • "why is this failing"
  • "find root cause"
  • "auto fix"

Execution contract:

  1. Detect language, framework, package manager, and test runner.
  2. Reproduce the failure with a single deterministic command.
  3. Collect evidence from logs, traces, network, and failing tests.
  4. Isolate the smallest root cause (code, config, env, data, dependency, race, permissions).
  5. Apply the minimum correct fix.
  6. Re-run verification gates until green.

Non-Interruption Policy

  • Do not ask follow-up questions during normal debugging.
  • Continue autonomously through analysis, patching, and verification.
  • Only stop when blocked by missing secrets, unavailable infrastructure, or destructive action risk.
  • If blocked, use the safest fallback and continue as far as possible.

Mainstream Debug Process

Phase 1: Triage

  • Capture exact error text and failing command.
  • Use debugging tools first: console logs and network requests before code edits.
  • Identify regression window from recent diffs if available.
  • Determine scope: runtime error, failing test, build failure, performance issue, or security defect.

Phase 2: Reproduction

  • Create one reproducible command.
  • Remove noise by disabling unrelated jobs and minimizing input.
  • Prefer deterministic seeds and controlled timing.
  • Confirm failure reproduces at least twice.
  • Browser-specific reproducibility rules:
    • Pin browser (chromium/firefox/webkit), viewport, locale, and timezone.
    • Freeze test data and seed values.
    • Disable retries during repro.
    • Persist traces, screenshots, videos, and HAR files.

Phase 3: Evidence Collection

Collect only relevant artifacts:

  • Console and application logs
  • Test output with stack traces
  • Network failures and status codes
  • Runtime metrics (latency, memory, CPU) when performance related
  • Config/env differences between working and failing contexts
  • Browser artifacts bundle:
    • Devtools console log export
    • Failed request waterfall with request/response metadata
    • Reproduction trace and screenshot at failure frame
    • Browser/version and OS metadata

Phase 4: Root Cause Analysis

Use this chain:

  1. Symptom statement
  2. Immediate fault location
  3. Underlying mechanism
  4. Trigger condition
  5. Why safeguards missed it

Root cause must be a single falsifiable statement tied to evidence.

Phase 5: Fix Strategy

  • Prefer the smallest change that resolves cause, not symptom masking.
  • Keep public API behavior stable unless the bug requires a behavior correction.
  • Add or update tests that fail before and pass after fix.
  • Avoid temporary bypasses (@ts-ignore, disabled tests, silent catches).

Phase 6: Verification Gates

All applicable gates must pass:

  • Unit, integration, and e2e tests
  • Lint and static analysis
  • Type checks
  • Build and package
  • Relevant runtime smoke check

If any gate fails, loop back to Phase 4.

Browser Reproduction Module

Use these scripts for browser bug reproduction and fix validation:

# 1) Reproduce failure deterministically (expected to fail)
python scripts/repro_browser_issue.py \
  --project-root . \
  --repro-cmd "pnpm exec playwright test tests/bug.spec.ts --project=chromium --workers=1 --retries=0" \
  --expect fail \
  --runs 2

# 2) Capture browser debugging artifacts into one bundle
python scripts/capture_browser_artifacts.py --project-root . --output-dir .debug/browser-artifacts

# 3) Verify fix deterministically (expected to pass)
python scripts/verify_browser_fix.py \
  --project-root . \
  --verify-cmd "pnpm exec playwright test tests/bug.spec.ts --project=chromium --workers=1 --retries=0" \
  --runs 2 \
  --signature-file .debug/browser-repro/repro_report.json

Supported frameworks: Playwright, Cypress, Selenium, WebdriverIO. Use project-native commands first; scripts only orchestrate repeatable debug workflow.

Stack Detection and Default Commands

StackDetect SignalsVerify Commands
Node.js / TypeScriptpackage.json, tsconfig.jsonpnpm test, pnpm lint, pnpm typecheck, pnpm build
Pythonpyproject.toml, requirements.txtpytest -q, ruff check ., mypy .
Gogo.modgo test ./..., go vet ./...
RustCargo.tomlcargo test, cargo clippy -- -D warnings
Java/Kotlinbuild.gradle, pom.xml./gradlew test, ./gradlew build or mvn test
RubyGemfilebundle exec rspec, bundle exec rubocop
PHPcomposer.jsoncomposer test, vendor/bin/phpunit
.NET*.sln, *.csprojdotnet test, dotnet build
Swift (iOS/macOS)Package.swift, *.xcodeprojswift test or xcodebuild test

Pick commands from project scripts first; use defaults only if scripts are missing.

Auto-Fix Heuristics

Prioritize fixes in this order:

  1. Incorrect logic or branching
  2. Null and undefined handling at source
  3. Async and concurrency ordering
  4. Contract and schema mismatch
  5. Config and environment mismatch
  6. Dependency incompatibility
  7. Resource, path, or permission issues

For each candidate fix:

  • Estimate blast radius
  • Choose the lowest-risk valid option
  • Verify with targeted tests, then full gates

Guardrails

  • Never claim success without passing verification.
  • Never skip tests to make status green.
  • Never introduce permanent production console.log noise.
  • Never hardcode secrets or private endpoints.
  • Preserve existing style and architecture conventions.

Completion Criteria

A task is complete only when all are true:

  • Reproduction exists for the original failure
  • Root cause statement is evidence-backed
  • Fix addresses root cause directly
  • Verification gates pass
  • Regression coverage is added or updated

Output Format

Return concise sections:

  1. Root cause
  2. Applied fix
  3. Verification commands and results
  4. Remaining risk (if any)

Resources

  • references/browser-repro-playbook.md
  • references/browser-artifact-checklist.md
  • scripts/repro_browser_issue.py
  • scripts/capture_browser_artifacts.py
  • scripts/verify_browser_fix.py

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.