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
- Fei2-Labs/skill-genieword for word, first seen Sep 24, 2026
Other versions1 project uses a version of this.
Word for word · 1
- Fei2-Labs/skill-genie★ 12100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository24 other files it gives its agents.
- aegis-protocolSkill
- ai-csuiteSkill
- browser-driverSkill
- chinese-humanizerSkill
- close-loopSkill
- de-ai-englishSkill
- dev-inboxSkill
- foxcode-openclawSkill
- git-cryptSkill
- handoff-receiverSkill
- image-prompt-engineerSkill
- init-rulesSkill
- linuxdo-applicationSkill
- npm-publishSkill
- psychology-masterSkill
- refactor-agents-mdSkill
- research-to-wechatSkill
- rtk-token-saverSkill
- session-handoffSkill
- shared-memorySkill
- stalwart-dokploy-resend-relaySkill
- web-compliance-builderSkill
- wechat-compliance-checkSkill
- wordpress-vps-installSkill
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
- Distinctive: line 13
Default mode is autonomous execution: find root cause and ship a verified fix without pausing for user input.
- Distinctive: line 17
Use this skill when requests include:
- Distinctive: line 34
Do not ask follow-up questions during normal debugging.
- Distinctive: line 36
Only stop when blocked by missing secrets, unavailable infrastructure, or destructive action risk.
- Distinctive: line 37
If blocked, use the safest fallback and continue as far as possible.
- Distinctive: line 44
Use debugging tools first: console logs and network requests before code edits.
- Distinctive: line 50
Create one reproducible command.
- Distinctive: line 51
Remove noise by disabling unrelated jobs and minimizing input.
- Distinctive: line 52
Prefer deterministic seeds and controlled timing.
- Distinctive: line 64
Test output with stack traces
- Distinctive: line 87
Prefer the smallest change that resolves cause, not symptom masking.
- Distinctive: line 88
Keep public API behavior stable unless the bug requires a behavior correction.
- Distinctive: line 89
Add or update tests that fail before and pass after fix.
- Very specific: line 90
Avoid temporary bypasses (@ts-ignore, disabled tests, silent catches).
- Distinctive: line 94
All applicable gates must pass:
- Distinctive: line 101
If any gate fails, loop back to Phase 4.
- Distinctive: line 105
Use these scripts for browser bug reproduction and fix validation:
- Distinctive: line 127
Use project-native commands first.
- Distinctive: line 159
Verify with targeted tests, then full gates
- Distinctive: line 163
Never claim success without passing verification.
- Distinctive: line 164
Never skip tests to make status green.
- Very specific: line 165
Never introduce permanent production console.log noise.
- Distinctive: line 166
Never hardcode secrets or private endpoints.
≈ “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.
Files
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:
- Detect language, framework, package manager, and test runner.
- Reproduce the failure with a single deterministic command.
- Collect evidence from logs, traces, network, and failing tests.
- Isolate the smallest root cause (code, config, env, data, dependency, race, permissions).
- Apply the minimum correct fix.
- 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.
- Pin browser (
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:
- Symptom statement
- Immediate fault location
- Underlying mechanism
- Trigger condition
- 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.jsonSupported frameworks: Playwright, Cypress, Selenium, WebdriverIO. Use project-native commands first; scripts only orchestrate repeatable debug workflow.
Stack Detection and Default Commands
| Stack | Detect Signals | Verify Commands |
| Node.js / TypeScript | package.json, tsconfig.json | pnpm test, pnpm lint, pnpm typecheck, pnpm build |
| Python | pyproject.toml, requirements.txt | pytest -q, ruff check ., mypy . |
| Go | go.mod | go test ./..., go vet ./... |
| Rust | Cargo.toml | cargo test, cargo clippy -- -D warnings |
| Java/Kotlin | build.gradle, pom.xml | ./gradlew test, ./gradlew build or mvn test |
| Ruby | Gemfile | bundle exec rspec, bundle exec rubocop |
| PHP | composer.json | composer test, vendor/bin/phpunit |
| .NET | *.sln, *.csproj | dotnet test, dotnet build |
| Swift (iOS/macOS) | Package.swift, *.xcodeproj | swift 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:
- Incorrect logic or branching
- Null and undefined handling at source
- Async and concurrency ordering
- Contract and schema mismatch
- Config and environment mismatch
- Dependency incompatibility
- 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.lognoise. - 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:
- Root cause
- Applied fix
- Verification commands and results
- Remaining risk (if any)
Resources
references/browser-repro-playbook.mdreferences/browser-artifact-checklist.mdscripts/repro_browser_issue.pyscripts/capture_browser_artifacts.pyscripts/verify_browser_fix.py
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
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.

