| name | lld-interview |
| description | Clarify only material repository implementation decisions before one repo LLD is written. Audit existing answers, inspect the bounded implementation seam, and ask feature-specific questions in grouped native popups. |
| allowed-tools | Read, Grep, Glob, Write, Bash |
| tags | ["sdlc","design","lld"] |
LLD interview
Resolve decisions that a developer cannot safely infer from the approved HLD and repository evidence.
This runs in the lead agent so the grouped conversation and subsequent LLD write share one context.
Read boundary
Read the approved parent HLD, its deferred-question ledger, confirmed LLD decisions, repository
guidance, the maintained codebase map, relevant manifest, and only source/tests around the seam this
feature changes. Start from paths named by the map. Do not scan the whole repository or another repo.
Decide from evidence before asking
Do not ask the user to choose a normal implementation detail when the repository already has a clear
convention. Record no question for choices the writer can safely make from code evidence. Ask only an
unresolved decision that materially changes correctness, compatibility, or the implementation seam:
- which existing module or extension seam owns ambiguous behavior;
- local state authority, lifecycle, validation, or migration where the HLD leaves alternatives;
- this repo's precise side of an API, event, navigation, storage, or background-work boundary;
- for an API-producing backend, unresolved persistence ownership or client-contract facts: entity
relationships, destructive behavior, route/operation shape, complete DTOs, authorization, stable
errors, pagination, time/enum representation, idempotency, refresh and shared-contract ownership;
- visible error, retry, concurrency, idempotency, offline, or recovery behavior;
- authorization, privacy, sensitive-data handling, or trust-boundary enforcement;
- backward compatibility, rollout, backout, or support for relevant execution modes;
- a verification seam when materially different choices change testability or delivery risk.
Do not reopen PRD or HLD decisions. Do not ask for filenames, class names, boilerplate, library syntax,
task estimates, styling preferences, or facts directly discoverable from source. Do not ask a
frontend developer to rediscover a backend payload later: resolve material client-visible ambiguity
before writing. Recommend the simplest option that follows current repository patterns.
Answer audit
- Check every saved answer against its
must_resolve facts and against code/HLD constraints.
- For
source: user-answer, only answer is confirmed; proposal text is not.
- Follow up only on the missing or contradictory fact, using a new stable ID.
- A blocking repo decision cannot be deferred. An implementation detail with a safe existing
convention should be decided by the writer, not sent back to the user.
Queue contract
Write the supplied queue as schema version 2. Each question has id, title, question, why,
proposal, and one to four short must_resolve facts. Use 3–7 questions when several material gaps
remain and fewer when nearly clear. An empty queue requires empty audit.unresolved and
audit.contradictions. Run the supplied validator before completing.
Presentation
Use only the workflow's native grouped popup. If the host limits popup size, collect consecutive
chunks without analyzing or writing between them, then record the complete round atomically. Never
fall back to ordinary chat.
Safety
Write only the workflow-supplied question queue. Never edit the LLD, source, parent artifacts, or
state.
Output contract
Return summary: one short sentence describing the queue or confirming the repo is clear.
