In the agentic-AI era, writing code is no longer the hard part. The hard part is knowing why code exists and what a change will break:

• Which requirement or issue caused this code to change?
• When an error appears, which code, design, and requirement is it rooted in?
• Who decided what, when, and on what basis — and what does that decision still constrain?

Holmes-Kit treats these as one connected investigation. It builds and maintains a fact-based graph linking requirements → design → code → tests → decisions, so an agent always works from evidence, not guesswork.

North Star: close the loop. Most tools stop at diagnosis; Holmes-Kit feeds a production signal or an issue back into the graph — localizing it to code, and flagging the requirements and tests it touches — so software engineers (human and agent) fix the cause, not the symptom.

Holmes-Kit drives a spec-driven development pipeline where deterministic code owns control and governance, and the LLM is used only for reasoning and generation:

• Requirement → Spec — classifies requirements by type and structures them into a reviewable hierarchy.
• Spec → sliceable units — decomposes each requirement into independently testable, AI-codeable units.
• Test-first (TDD) — generates BDD test specs with normal / corner / negative / boundary coverage, and enforces red-before-green as a hard gate.
• Deterministic Code Property Graph (D-CPG) — a multi-language, tree-sitter-based structural graph (precision over recall, no LLM in the loop).
• Requirements Traceability Matrix (RTM) — a queryable graph bundling spec ↔ code ↔ test, surfaced to the LLM just-in-time and token-efficiently to control hallucination and forgetting.
• Impact-aware testing — decides unit / partial-regression / full-regression scope from change reachability, not guesswork.

• Deterministic control plane. Loops, gates, and traceability live in ordinary testable code — never delegated to an LLM.
• Evidence over recall. The graph emits only verifiable relationships; advisory LLM inference is kept separate and clearly labeled.
• Config-driven & portable. Local Markdown is the source of truth first; external systems (issue trackers, docs, databases) plug in behind a stable interface.
• Built in the open, dogfooded. Holmes-Kit is developed using its own workflow.

Holmes-Kit is an engineering-time harness: it helps design, implement, test, and trace software across its lifecycle. It reads runtime signals (traces, errors, logs) only to route them back to the requirements, design, and code that caused them — where a pure SRE/incident agent stops at diagnosing the running system.

Actively shipping. Published on npm (@holmes-lab/holmes-kit), governing this repository and a consumer project. Interfaces still move between minor versions.