sdlc-classify-failure

Classify SDLC phase failures and route evidence-backed repair or stop decisions.

7|5|Updated Jul 22, 2025
One-click install
npx skills add https://github.com/nebius/nebius-ps-services --skill sdlc-classify-failure-nebius
Or copy as Structured Prompt for Agentโ–ผ
Please help me install this Agent Skill.
Skill: sdlc-classify-failure
Source: https://github.com/nebius/nebius-ps-services/tree/main/skills/sdlc-classify-failure
Command: npx skills add https://github.com/nebius/nebius-ps-services --skill sdlc-classify-failure-nebius

SYSTEM DOCUMENTATION & REQUIREMENTS

๐Ÿ’ก This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? When an automated software development lifecycle phase fails, teams often retry blindly or guess at the root cause, burning retry budgets and corrupting failure history. This Skill normalizes every failure into an immutable record, validates troubleshooting diagnoses, enforces repair budgets, and deterministically selects the earliest responsible owner or an explicit stop condition before any retry. ## Core Features & Use Cases - Deterministic failure classification: Records immutable failure events, diagnoses, and classifications using a taxonomy of 23 failure classes routed to the correct SDLC phase skill. - Repair budget enforcement: Caps localized repairs, design repairs, blocker attempts, active minutes, and per-feature dispatches through a process-safe locked helper script. - Design admission gate: Admits a design defect only with positive causal evidence and digest-verified human approval for broader changes. - Ordered revalidation: After a successful repair, advances a commit-bound revalidation cursor gate by gate before marking the failure resolved. - Use Case: An evaluation phase fails ambiguously during an agentic SDLC run; the coordinator invokes this Skill to route exactly once to troubleshooting, validate the returned diagnosis, and dispatch a bounded corrective plan without overwriting prior failure history. ## Quick Start Ask the agent to classify the current failed SDLC phase for the active feature and return the failure class, retry budget state, and next recommended skill.

Frequently Asked Questions about sdlc-classify-failure

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

FAQPage Schema
How do I classify a failed SDLC phase before retrying?โ–ผ

Record a normalized failure event with the feature ID, phase, evidence digests, and integration commit, then run the repair_control.py classify action. The helper validates the evidence, applies the failure taxonomy, and returns the failure class plus the next recommended skill or stop condition.

What failure classes does the SDLC failure taxonomy support?โ–ผ

The taxonomy defines 23 classes including SPEC_GAP, DESIGN_DEFECT, PLAN_DEFECT, TEST_DEFECT, IMPLEMENTATION_DEFECT, EVALUATION_DEFECT, ENVIRONMENT_DEFECT, POLICY_BLOCK, and UNKNOWN_DEFECT. Each class routes to the earliest SDLC phase skill that can fix the cause, or stops for human input.

When does an ambiguous evaluation failure go to troubleshooting?โ–ผ

An ambiguous evaluation failure routes to troubleshooting exactly once, and the resulting diagnosis must return through classification before any repair owner is selected. Proven mechanical defects bypass troubleshooting entirely, and probable or incomplete diagnoses cannot authorize repair.

Can this skill be invoked directly by end users?โ–ผ

No. It is an internal coordinator-only skill with user-invocable set to false, requiring verified workflow context from the active Agentic SDLC coordinator. Without verified project, run, and phase state, it returns without mutation.

What repair budget limits are enforced?โ–ผ

The helper enforces two localized repairs, one design repair, three total blocker attempts, 60 active minutes, and four repair dispatches per feature. Reaching any ceiling, repeating a failed direct repair without troubleshooting, or cycling phases without new evidence stops the loop immediately.

Why is a design defect rejected even when no implementation bug is found?โ–ผ

Absence of an implementation bug is never treated as design evidence. A DESIGN_DEFECT requires positive proof through the design gate: stable requirements, valid evaluator and environment, reproducibility, a named violated system contract, and evidence that localized repair is insufficient.