using-lddlisted

# Using LDD — the bundle entry-point ## Overview Loss-Driven Development (LDD) is a ten-skill bundle that treats code changes as SGD steps and forbids overfitting to the current test. This entry-skill exists so you (the agent) know **when to reach for which LDD skill** without the user having to name each one by hand. **Core principle:** if the user prefixes their message with `LDD:` or mentions any of the trigger phrases below, LDD discipline is explicitly requested. Match their intent to the right sub-skill and announce which one you are applying. ## Trigger phrases (user → skill mapping) When the user's message contains any of these patterns, invoke the paired skill. | User signal | Invoke | |---|---| | `LDD:` prefix, "apply LDD", "use LDD" | Enter full LDD mode — default entry = `loop-driven-engineering` unless a more specific sub-skill matches below | | "failing test", "CI is red", "flaky", "one-off failure", "intermittent" | First `reproducibility-first`, then `root-cause-by-layer` if the failure is real | | "bug", "error", "exception", "unexpected behavior", "why is this breaking" | `root-cause-by-layer` | | "I've tried this 3 times", "keeps failing the same way", five fix-commits in one area | `loss-backprop-lens` (local-minimum trap) | | "this fix works but I'm not sure it generalizes", "will this break sibling tests" | `loss-backprop-lens` (generalization check) | | "I'm mid-debug", "is the fix done yet", before closing any fix-loop | `e2e-driven-iteration` |