// Explore radically different module shapes before committing to one. Use when choosing an API surface, deciding what a module hides vs exposes, or when the user says 'design it twice'.
Crystallize shared understanding into a reviewable spec, or update an existing one. Use when the problem needs a written specification, when assumptions or decisions have changed, or when the user says 'write a spec'.
Lightweight triage for the ln-* skill set. Use when unsure which ln skill to use next, starting work on something new, or when the user asks for guidance on their development process.
Collapse meaningful ambiguity with contrastive examples. Use when a plan/design has several plausible meanings, requirements feel vague, examples would clarify intent faster than grilling, or the user asks to disambiguate, find ambiguity, use behavioral kernels, or ask contrastive questions.
Audit code quality focusing on deep modules, naming, model hygiene, and architectural clarity. Use after a burst of development, when codebase structure needs assessment, or to make code more agent-navigable.
Refresh `memory/SPEC.md` and `memory/PLAN.md` in mature mode — restore canonical truth, archive retired plan history, delete stale derivative artifacts, and flag drift against code.
d3k assistant for debugging web apps
| name | ln-design |
| description | Explore radically different module shapes before committing to one. Use when choosing an API surface, deciding what a module hides vs exposes, or when the user says 'design it twice'. |
| argument-hint | [module or API boundary to explore] |
Apply Ousterhout's "Design It Twice": generate 3+ radically different module shapes, compare on depth, and synthesize. The goal is deep modules — small interfaces hiding significant complexity. Do not implement; this is purely about the shape of the seam.
Use ln-design as the deepening pathway from ln-review: when review surfaces a shallow module or weak seam, explore alternative deepened module shapes here before routing to ln-scope or ln-refactor.
The module or API boundary: $ARGUMENTS
Understand the problem, the callers, the key operations, constraints, and — crucially — what complexity should be hidden inside vs exposed. If this design follows an ln-review deepening candidate, start from that candidate's files, problem, possible direction, and benefits. Skip steps you already know the answer to.
Read memory/SPEC.md first when it exists. Use its lexicon for domain terms and respect its live assumptions, decisions, and invariants. Read memory/PLAN.md when the seam touches active or near-horizon work.
Spawn 3+ sub-agents simultaneously. Each must produce a radically different shape — enforce this by assigning divergent constraints:
Each agent returns: interface (types, methods, params, invariants, ordering constraints, error modes, required configuration, and performance characteristics), usage example, what it hides, seam / adapter strategy where relevant, and trade-offs.
Show each design sequentially, then compare in prose on:
Highlight where designs diverge most.
The best design often combines insights from multiple options. Ask which shape best fits the primary use case and whether elements from other designs are worth incorporating.
Present the recommended module shape with rationale. If memory/SPEC.md exists, ensure names align with its lexicon.
Do not invent a standalone design document unless the user explicitly asks for one. Durable design choices reconcile back into memory/SPEC.md and memory/PLAN.md.
After choosing a design, present these options to the user (use tool-ask-question):
| # | Label | Target | Why |
|---|---|---|---|
| 1 | Scope a slice | ln-scope | Design is chosen, define the first slice |
| 2 | Write a spec | ln-spec | Module needs a full spec before slicing |
| 3 | Grill it more | ln-grill | Design choice raised new questions |
Recommended: 1
Adapted from mattpocock/skills/design-an-interface.
