一键在 Manus 中运行任何 Skill

lfe-diagnose

星标41

分支2

更新时间2026年6月17日 13:55

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

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

StChiotis

StChiotis/Library-First-Engineering

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

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.

同仓库更多 Skills

同仓库

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.

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