im-stuck
SolidBreak the task out of a loop, confusion state, or false-progress state, and determine the fastest safe path forward. Diagnoses whether the issue is technical, workflow-related, or scope-related, then routes to the right recovery command and editor mode (Ask by default; Debug if the stuckness is a concrete technical failure; Plan if it is a phase or contract or sequence issue). Use when progress is looping or stalling, the same questions or reviews are being repeated, the wrong command or wrong editor mode may be in use, or when the user is unsure whether the problem is technical, workflow-related, or scope-related. Do not use when the next step is already clear, the task only needs normal routing via what-next, or when the task is brand-new and should start with task-init. When the real blocker is a vague prompt, use prompt-shape.
Install
Quality Score: 81/100
Skill Content
Details
- Author
- Mozurok
- Repository
- Mozurok/fhorja.dev
- Created
- 1 months ago
- Last Updated
- 5 days ago
- Language
- Python
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
impact-analysis
Understand the requested change deeply enough to make safe workflow decisions, then persist the analysis as IMPACT_ANALYSIS.md in the active task folder. Per-repo subsections when multi-repo. Identifies blast radius, contract impacts, schema/runtime risks, and integration points before planning or coding. Use when a new task was just initialized, the task is still unclear or partially understood, the blast radius is not yet known, or the request may affect contracts, schema, integrations, runtime behavior, or critical user flows. Do not use when the task is already in a well-defined planning phase with valid impact analysis, the goal is only to sync task memory after progress, the main issue is an observed technical failure (use incident-triage), or the current need is to implement an already-approved slice (use implement-approved-slice). For greenfield work, consider backend-system-design, frontend-architecture-review, ai-feature-eval-harness, or code-context-map.
decision-interview
Ask the minimum set of high-value decision questions needed before turning the task into canonical implementation rules. Decisions that would change runtime behavior, data integrity, rollout safety, or test strategy. Use when the missing information is decision-driven (not factual), different answers would change behavior or data integrity or rollout safety or test strategy, or the task cannot safely move into planning because policy or behavior is undecided. Do not use when missing information is factual (use targeted-questions), decisions are already locked in code or docs or approved task artifacts, or the task is already in implementation with no correctness-critical ambiguity. To harden wording before planning, use contract-signoff; to reconcile contradictory rules, use resolve-contract-gaps.
implementation-plan
Define an incremental, reviewable, production-safe implementation plan for the active task and persist it as IMPLEMENTATION_PLAN.md plus a TASK_STATE.md update. Breaks work into the smallest safe slices with objective, exact scope, ordering rationale, key risks, validation approach, exit criteria, and work complexity (LOW/MEDIUM/HIGH) per slice. No code is written. Also runs an annotate-only retrofit mode that backfills per-slice Scope and Depends-on plus an Execution waves section onto an existing in-progress plan so it can adopt implement-fleet, without re-planning. A --spec mode derives slices from a spec or PRD, checking every spec item is covered (ADR-0061). Use when impact is understood enough to plan safely, key boundaries are known, and major factual or decision ambiguity is already resolved. Do not use when the task is still too unclear, when key facts or decisions remain open, or when the current need is to implement an already-approved slice (use implement-approved-slice).