sdlc-lld-workflow

name	sdlc-lld-workflow
description	Use to create or refine LLD for modules, interfaces, state machines, data structures, errors, transactions, and tests.
metadata	{"version":"0.4","updated":"2026-07-23"}

LLD Workflow

Use this skill to write detailed design for a bounded module or feature area.

Use when

• HLD exists and module internals need design.
• A domain/module requires class/function/interface/data/state/error details.
• A complex feature needs implementation-near design before dev task cards.
• The user asks for LLD, detailed design, module design, algorithm design, or implementation design.

Inputs

• HLD, SRS, NFR, SPEC slices, domain boundary map, directory spec.
• Existing code, interfaces, schemas, tests, and project conventions.
• Task constraints and validation expectations.

Workflow

1. Select the module or bounded area.
2. Confirm related HLD/SRS/NFR/SPEC IDs.
3. Define module responsibilities and forbidden responsibilities.
4. Define interfaces, data structures, state transitions, and error behavior, including idempotency, ordering, timeout, retry, and partial-failure semantics where they apply.
5. Define transaction, consistency, permission, and validation rules.
6. Make dependencies explicit and inspect global state, required call order, shared mutable data, framework types, and third-party SDK objects for hidden code, data, temporal, or implementation coupling.
7. Define directory/file placement and dependency rules.
8. Define test points and expected validation.
9. Identify implementation risks and unresolved decisions.

Validation

Check:

• Module responsibilities do not leak across domain boundaries.
• Data structures align with Data SPEC.
• API/interface details align with API SPEC.
• Permission checks align with Permission SPEC.
• State and error behavior are explicit.
• Public interfaces do not leak storage models, framework internals, or third-party SDK objects without a deliberate compatibility reason.
• Ordering, idempotency, timeout, retry, and partial-failure semantics are explicit when callers depend on them.
• Tests can be derived from the design.

Output

Return:

1. LLD summary
2. Module responsibility table
3. Interfaces and data structures
4. State/error/transaction rules
5. Directory and dependency notes
6. Test points
7. Implementation risks
8. Dev task candidates

Boundaries

• Do not edit code.
• Do not expand beyond the selected module.
• Do not contradict HLD/SRS/SPEC without reporting it.
• Do not require LLD for small direct-dev bugfixes when repo evidence is enough.

Handoff

Use sdlc-dev-handoff-planning to create implementation task cards. Use dev skills for coding.

Dev fallback: Dev can use SDLC / ADD / DDD / SDD materials when they exist, but dev can also continue without them when the task is clear, bounded, and testable from user request, issue, bug report, failing test, local diff, or repository evidence. Missing artifacts are risk/context, not automatic refusal.