Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/TechNickAI/ai-coding-configWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/technickai/ai-coding-config/troubleshoot)<a href="https://agentmods.dev/commands/technickai/ai-coding-config/troubleshoot"><img src="https://agentmods.dev/badge/commands/technickai/ai-coding-config/troubleshoot/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/technickai/ai-coding-config/troubleshoot"><img src="https://agentmods.dev/badge/commands/technickai/ai-coding-config/troubleshoot.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00021 | $0.01358 |
| Opus 5.5 | $0.00008 | $0.00543 |
| Sonnet 5.5 | $0.00004 | $0.00272 |
| Haiku 4.5 | $0.00002 | $0.00136 |
Grade A, and why
troubleshoot scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 25d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 137 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Troubleshoot Command
- /troubleshoot - Autonomous continuous mode (default)
- /troubleshoot auto 5 - Fix top 5 bugs in parallel worktrees
- /troubleshoot watch - Monitor and auto-fix critical errors as they occur
- /troubleshoot analyze - Pattern analysis without fixes
- /troubleshoot 3 - Fix the 3rd error in priority order
- /troubleshoot csrf token - Find and fix error matching keywords
If no monitoring service available, explain what's needed and how to connect one.
Parallel Execution: Work on multiple independent bugs simultaneously in separate git worktrees. Typically 3-5 concurrent worktrees is optimal.
Root Cause Over Symptoms: Investigate why errors happen. Review recent commits, check for related errors, understand data flow. Find the actual problem, not just where it manifested.
Pattern Recognition: Identify common causes across multiple files or components. One strategic fix can prevent many future errors.
Know When Not to Fix: Skip errors that aren't worth fixing: rate limiting (429 errors), external service failures, user-caused errors, flaky/intermittent issues, deprecated code paths, low-value cosmetic issues, monitoring noise. Mark these as ignored in the monitoring service with brief explanation.
Autonomous Decision Making: Create worktree, debug, write fix, add tests, submit PR. Use your judgment on what to fix and what to ignore. Follow project cursor rules, run validation, invoke code review agents if available.
Learning System: After fixes deploy, check if error rate dropped. Adjust approach based on outcomes.
Trust the executing model's intelligence - you can determine the best approach for each situation.
Parallel Batch (auto N): Identify top N independent errors and fix simultaneously in separate worktrees. Submit all PRs at once.
Watch Mode: Monitor for new critical errors (priority score >85). Auto-create worktree, fix, submit PR tagged [HOTFIX]. Queue non-critical errors for batch processing.
Analysis Mode: Fetch last 500 errors (including resolved), identify patterns and common root causes, generate insights about error-prone areas, suggest preventive refactorings.
Keyword Search: Search errors for matches in messages, types, file paths, stack traces, function names. Use fuzzy matching. If multiple matches, show ranked by relevance. If one clear match, fix immediately.
Error Intelligence: Fetch unresolved errors in default sort order. Identify clusters sharing root causes. Triage aggressively - skip external failures, rate limiting, user mistakes, rare flukes. Mark ignored errors in monitoring service with explanation.
Root Cause Analysis: Review git history for affected files, examine code context, look for related errors, check deployment timelines. Generate hypotheses about actual problems.
Git Worktree Workflow: Each bug fix in isolated worktree. Read
.cursor/rules/git-worktree-task.mdc for full workflow. Clean up worktrees after PRs
merge.
Fixing Process: Gather full context from error monitoring (stack traces, request data, timelines). Read failing code and context. Identify root cause. Implement fix handling edge cases with improved error messages. Add tests when appropriate. Run validation. Use code review agents if available. Create descriptive commits. Submit PRs with error links, occurrence counts, root cause analysis, monitoring plans.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 25d ago First seen · 137 lines · 21 tokens per session scan A cdad0b3334c4
troubleshoot is a command published in the GitHub repository TechNickAI/ai-coding-config (24 stars, last pushed 26d ago), licensed MIT. It adds 21 tokens to every session and 1,358 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-22.
Other commands, from other repositories
debug
Systematic debugging with hypotheses and evidence gathering.
improve
/improve Scan and fix all improvement categories /improve arch Architectural improvements only /improve duplication Duplicate code / abstraction consolidation /improve quality Code quality (GuardLoop patterns GL-01 through GL-10) /improve security Security posture improvements /improve --dry-run Show what would be…
detectar-ambiguedad
Detectar ambigüedades y contradicciones en specs de forma exhaustiva.
doctor
Diagnosticar y reparar problemas del framework Don Cheli, git y entorno. Usa cuando el usuario dice "doctor", "problemas del framework", "don cheli no funciona", "repair Don Cheli", "debug setup", "setup broken", "framework broken", "reparar entorno". Detecta y repara issues de configuración, git y dependencias…
diagnostico
Verificar la salud del setup de Don Cheli en el proyecto actual.
verify
An embedded-device verification workflow that checks a development step through building, flashing firmware, debugging with J-Link, and reading serial logs. Firmware is software that runs directly on a microcontroller or other device.