using-ldd

Solid

Use at the start of any conversation, and whenever the user mentions LDD, loss-driven development, loss, gradient, SGD on code, drift, refinement loop, outer loop, inner loop, method evolution, or says "LDD:" / "apply LDD". Establishes how to dispatch the ten LDD skills and when each fires. Must be the first skill considered in any coding task where LDD is available.

AI & Automation 20 stars 4 forks Updated today Apache-2.0

Install

View on GitHub

Quality Score: 81/100

Stars 20%
44
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# 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` | ...

Details

Author
CorvinLabs
Repository
CorvinLabs/CorvinOS
Created
4 weeks ago
Last Updated
today
Language
Python
License
Apache-2.0

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

sdlc

Orchestrates an end-to-end, plan-gated software build pipeline: routes each stage to the right skill while enforcing human approval gates. Covers discovery, PRD, stress-test, architecture, API contracts, decomposition, implementation, QA, review, landing, and retro. The single entry point for the workflow. Use when the user wants to build a feature or product the disciplined way, start or resume structured development, asks "what stage are we at" / "what's next", or says "start the sdlc" / "run the pipeline".

1 Updated 6 days ago
enocgit
Code & Development Listed

getff

Use when treating any codebase rule (architectural, naming, dependency, test-quality, contract, SLO) as an executable test that fails the build when violated, or when the user asks about enforcing code quality, fighting AI-generated code drift, setting up linters/tests/CI/pre-commit hooks, designing review processes, mutation testing, contract testing, fitness functions, observability-driven development, SLO-as-code, or any version of "how do I make my codebase resistant to AI agents breaking my conventions". Also trigger on any mention of ArchUnit, Stryker, Pact, dependency-cruiser, AI Factory (aif), Husky, lint-staged, ESLint flat config, Zod validation strategy, or shift-left/shift-right testing. Strongly trigger when the user mentions Claude Code, Cursor, or Copilot writing code that "looks fine but is wrong" — that is the core problem this skill addresses.

0 Updated today
artyhoo
AI & Automation Solid

loop-driven-engineering

Use at the start of any non-trivial engineering task (feature, bugfix touching more than one file, refactor with observable behavior change, incident response). Orchestrates the three LDD loops — inner (code), refinement (deliverable), outer (method) — with hard iteration budgets, dispatches the specialist skills at the right moments, and forbids declaring "done" without a synced doc-level mental model.

20 Updated today
CorvinLabs