lld-discuss

LLD Discussion — Gray Area Identification

Identify the implementation-level decisions that matter before gathering detailed LLD context. This skill loads HLD constraints, scouts existing code patterns in affected files, and guides the user through decisions about interfaces, state management, error handling, and testing.

Philosophy: An LLD should let an engineer code directly from it. The decisions that matter at this level are about HOW things work internally — method signatures, error catalogs, state transitions, data transformations. Two competent engineers would make different choices here, and the LLD should capture which choices THIS project makes.

Input

$ARGUMENTS — the LLD topic and optional HLD path.

Parse for:

• Topic — what the LLD covers (e.g., "GraphQL resolver layer")
• --hld flag — path to the HLD this LLD implements (e.g., --hld docs/hld/api-layer.md)

If no topic is provided, ask what component or module needs a detailed design.

Process

Human-in-the-loop: Every decision is captured from user input, never assumed.

Phase 1: Scout the Landscape

1. Load HLD constraints — if --hld provided, read the HLD and extract:

   • Component responsibilities and boundaries
   • API contracts and data models defined at HLD level
   • Key design decisions and their rationale
   • Implementation phases and dependencies
   • These are NON-NEGOTIABLE — LLD decisions must be consistent with HLD

2. Scan existing LLDs — Glob for docs/lld/*.md, identify related designs and patterns.

3. Deep-scout affected code — more thorough than ADR/HLD scouting because LLD decisions are about code-level patterns:

   • Read key files in the affected scope (not just Glob/Grep — actually Read the code)
   • Identify existing patterns: error handling conventions, state management approach, testing patterns, naming conventions
   • Find reusable utilities and base classes
   • Map the dependency graph for affected modules
   • Budget: up to 15 tool calls — LLD scouting needs more depth than ADR/HLD