stuck

Diagnose failing build and test commands with a bounded, evidence-first loop.

6|3|Updated Apr 22, 2026
One-click install
npx skills add https://github.com/lordmacu/nexo-rs --skill stuck-lordmacu
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: stuck
Source: https://github.com/lordmacu/nexo-rs/tree/main/skills/stuck
Command: npx skills add https://github.com/lordmacu/nexo-rs --skill stuck-lordmacu

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

This Skill provides automated diagnosis for failing build or test commands, significantly reducing the time and effort required to troubleshoot and resolve issues.

Core Features & Use Cases

  • Auto-Diagnostic Loop: Automatically detects and analyzes failures during build or test runs.
  • Evidence-First: Focuses on providing clear, actionable information based on error output.
  • Reproduce-Inspect-Isolate-Propose Fix: Guides through the debugging process in an efficient manner.

Quick Start

Diagnose a failing build using the command: stuck run failing_command="cargo build" max_rounds=3 focus_pattern="E0[0-9]{3}"

Frequently Asked Questions about stuck

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I automate debugging for failing Rust build or test commands?

Automated debugging for failing Rust build or test commands is handled through a structured auto-diagnostic loop that detects failures, inspects error output, isolates the root cause, and proposes targeted fixes.

What is the best way to diagnose recurring build errors without manual inspection?

Diagnosing recurring build errors without manual inspection is achieved by running an evidence-first automated loop that reproduces the failure, inspects the logs, isolates the specific issue, and proposes a fix within bounded rounds.

Can I limit the diagnosis rounds when troubleshooting failing test commands?

You can limit the diagnosis rounds when troubleshooting failing test commands by setting a max_rounds parameter, ensuring the automated debugging loop remains bounded and efficient.

How do I focus the build failure diagnosis on specific error patterns?

To focus the build failure diagnosis on specific error patterns, you can provide a focus_pattern parameter, which filters the error output to isolate matching issues and propose fixes for those targeted failures.

Does this automated error handling approach work outside of Rust ecosystems?

While primarily designed for software development scenarios in Rust ecosystems, the structured auto-diagnostic approach is applicable to any failing build or test commands that require efficient, repetitive error resolution.

Why does my build failure diagnosis need an evidence-first approach?

An evidence-first approach for build failure diagnosis is needed to ensure that proposed fixes are based on clear, actionable information extracted directly from the error output, avoiding blind guesses during the debugging process.