Run any Skill in Manus with one click

lfe-diagnose

Stars41

Forks2

UpdatedJune 17, 2026 at 13:55

Disciplined bug-diagnosis loop. Reproduce → Hypothesise → Fix. Use in the Inspector sub-pipeline (Step 3, conditional) when verification fails.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

StChiotis

StChiotis/Library-First-Engineering

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	lfe-diagnose
description	Disciplined bug-diagnosis loop. Reproduce → Hypothesise → Fix. Use in the Inspector sub-pipeline (Step 3, conditional) when verification fails.

LFE Diagnose

Position in Pipeline

Phase: 3 (Inspector sub-pipeline, Step 3 — conditional)
Persona: Inspector (triggers), Builder (fixes)
Trigger: Called by Inspector when /lfe-inspector verification fails
Input: Failing behavior identified during inspection
Output: Fix applied → returns to Builder sub-pipeline for re-verification

Hard Rules

First-failure only: Diagnose may only run on the first failed inspection of a slice. The Inspector's Cycle Guard (lfe-inspector/SKILL.md Cycle Guard step) is responsible for blocking re-entry on the second failure. If you discover that .plans/inspection_report.md already records a status: failed for the same slice:, halt immediately, leave the existing report as-is, and bounce back to Inspector for Brain triage (see LOOP_ARCHITECTURE.md Scenario 2.2). This is a defensive belt-and-braces check; the Cycle Guard should have prevented this entry.
Minimal fix only: Solve the diagnosed problem, nothing more. No opportunistic refactors.

Process

Feedback Loop: Build a deterministic repro (test/script) that reliably demonstrates the failure.
Reproduce: Run the loop and witness the failure. Confirm it matches the Inspector's reported issue.
Hypothesise: Generate 3-5 ranked, falsifiable hypotheses for the root cause.
Instrument: Add targeted probes to test hypotheses one at a time. Eliminate hypotheses until the root cause is confirmed.
Fix: Write a regression test that captures the bug → Apply the minimal fix → Watch the test pass.
Persist Diagnosis: Write .plans/diagnosis_report.md so the why of the fix survives a session crash. Schema below.
Handoff: Return to Builder sub-pipeline. The Builder runs the full test suite, then the Inspector re-verifies.

Coordination File Output

Per the contract in COORDINATION_FILES.md:

---
phase: inspector
step: diagnose
status: complete
timestamp: <ISO-8601>
source: .plans/tdd_report.md
slice: <copied from active_plan.md — used by /lfe-builder to detect a stale report>
---

## Failure Repro
- <command or test that reliably reproduces the bug>

## Hypotheses Considered
1. <hypothesis 1> — <eliminated / confirmed>
2. <hypothesis 2> — <eliminated / confirmed>

## Root Cause
- <one-paragraph explanation>

## Fix Summary
- <files touched and minimal change applied>
- Regression test: <test name>

## Risks / Notes for Inspector
- <anything the re-verification should look at carefully>

Rules

Use the project's domain glossary from CONTEXT.md when naming tests and describing the bug.
Check .docs/domain/ documentation to verify the expected behavior before assuming the code is wrong.
The fix must be minimal — solve the diagnosed problem, nothing more.
Always write diagnosis_report.md before handoff — a fix without a recorded why is invisible to crash recovery and to next-session archaeology.

More from this repository

same repository

lfe-archivist

StChiotis/Library-First-Engineering

Act as the Archivist for an LFE-compliant project. Use when a change is approved and needs documentation sync, changelog updates, or pipeline status cleanup.

2026-07-1441

lfe-architect

StChiotis/Library-First-Engineering

Act as the Architect for an LFE-compliant project. Design solutions and draft high-fidelity plans.

2026-06-1741

lfe-builder

StChiotis/Library-First-Engineering

Act as the Builder for an LFE-compliant project. Use when implementing an approved plan, writing code in src/**, or running unit tests.

2026-06-1741

lfe-complexity-check

StChiotis/Library-First-Engineering

Inspector sub-skill. Analyses changed code for cyclomatic complexity, excessive nesting, oversized functions, and cognitive load indicators. Pure LLM reasoning — no external tooling. Writes .plans/checks/complexity_findings.md. Called by lfe-inspector when enabled in inspector-config.md.

2026-06-1741

lfe-dep-audit

StChiotis/Library-First-Engineering

Inspector sub-skill. Reviews dependency manifest files (package.json, requirements.txt, go.mod, Cargo.toml, pom.xml) changed in the current diff for risky version patterns and stale majors. Emits a human-run audit instruction rather than executing tools. Writes .plans/checks/dep_findings.md. Called by lfe-inspector when enabled in inspector-config.md.

2026-06-1741

lfe-extract-domain

StChiotis/Library-First-Engineering

Conduct a "Day 0" interview with the founder to populate the project's domain-knowledge.md and CONTEXT.md. Use when the agent encounters an undocumented Black Box.

2026-06-1741

LFE Diagnose

Position in Pipeline

Phase: 3 (Inspector sub-pipeline, Step 3 — conditional)

Persona: Inspector (triggers), Builder (fixes)

Trigger: Called by Inspector when /lfe-inspector verification fails

Input: Failing behavior identified during inspection

Output: Fix applied → returns to Builder sub-pipeline for re-verification

Hard Rules

First-failure only: Diagnose may only run on the first failed inspection of a slice. The Inspector's Cycle Guard (lfe-inspector/SKILL.md Cycle Guard step) is responsible for blocking re-entry on the second failure. If you discover that .plans/inspection_report.md already records a status: failed for the same slice:, halt immediately, leave the existing report as-is, and bounce back to Inspector for Brain triage (see LOOP_ARCHITECTURE.md Scenario 2.2). This is a defensive belt-and-braces check; the Cycle Guard should have prevented this entry.

Minimal fix only: Solve the diagnosed problem, nothing more. No opportunistic refactors.

Process

Feedback Loop: Build a deterministic repro (test/script) that reliably demonstrates the failure.

Reproduce: Run the loop and witness the failure. Confirm it matches the Inspector's reported issue.

Hypothesise: Generate 3-5 ranked, falsifiable hypotheses for the root cause.

Instrument: Add targeted probes to test hypotheses one at a time. Eliminate hypotheses until the root cause is confirmed.

Fix: Write a regression test that captures the bug → Apply the minimal fix → Watch the test pass.

Persist Diagnosis: Write .plans/diagnosis_report.md so the why of the fix survives a session crash. Schema below.

Handoff: Return to Builder sub-pipeline. The Builder runs the full test suite, then the Inspector re-verifies.

Coordination File Output

--- phase: inspector step: diagnose status: complete timestamp: <ISO-8601> source: .plans/tdd_report.md slice: <copied from active_plan.md — used by /lfe-builder to detect a stale report> ---

## Failure Repro - <command or test that reliably reproduces the bug> ## Hypotheses Considered 1. <hypothesis 1> — <eliminated / confirmed> 2. <hypothesis 2> — <eliminated / confirmed> ## Root Cause - <one-paragraph explanation> ## Fix Summary - <files touched and minimal change applied> - Regression test: <test name> ## Risks / Notes for Inspector - <anything the re-verification should look at carefully>

Rules

Use the project's domain glossary from CONTEXT.md when naming tests and describing the bug.

Check .docs/domain/ documentation to verify the expected behavior before assuming the code is wrong.

The fix must be minimal — solve the diagnosed problem, nothing more.

Always write diagnosis_report.md before handoff — a fix without a recorded why is invisible to crash recovery and to next-session archaeology.