Scaffold $ARGUMENTS into this codebase by copying the structure of the closest existing module, not by inventing a new one. If $ARGUMENTS is empty, ask the user what feature or module to scaffold and stop until they answer.

Step 1 — Find the exemplar

Identify the kind of thing requested (route/endpoint, model, component, service, CLI command, job, etc.) from $ARGUMENTS.
Search the repo for 2-3 existing modules of that same kind. Pick the one whose structure is most representative of the group (the shape the others share), not an outlier or one-off hotfix. If two are recent and current, tie-break by whichever the rest most resemble.
Read the exemplar end to end plus its test and any file that registers/imports it. This is your template. Do not proceed until you have one.

Step 2 — Extract the conventions

From the exemplar, note concretely: directory layout and file names, naming case (camel/snake/kebab/Pascal), import style (relative vs alias vs barrel), export style (default vs named), error handling, logging, validation, how config/DI/dependencies are obtained, and the test framework + assertion style. Detect these from the code — never assume a stack.

Step 3 — Create the files

Mirror the exemplar's file set and naming exactly, substituting the new name. Match the existing pluralization and folder placement.
Keep the new code minimal but real: the smallest working slice that follows the pattern (types, function signatures, one happy path). Leave TODO: markers where domain logic belongs — do not fabricate business rules.
Reuse the same helpers, base classes, and utilities the exemplar imports. Do not add a new library, abstraction, or pattern unless the exemplar lacks something essential — if so, flag it and ask before adding.

Step 4 — Wire it up

Register the module wherever siblings are registered (router table, DI container, index/barrel export, module list, migration, nav). Grep for where the exemplar's name appears across the repo and add the new name in each corresponding place. Nothing should be created but left unreferenced.

Step 5 — Test and verify

Add one test file modeled on the exemplar's test, covering the happy path plus one edge/failure case.
Discover the project's actual commands from its manifest/config (e.g. package.json scripts, Makefile, pyproject.toml, CI config), then run: install (only if a lockfile changed), typecheck/lint, and the test suite scoped to the new files. Fix what you introduced until they pass. If a given check has no defined script, skip it and say so in the report rather than inventing or guessing a command.

Output

List every file created or edited with a one-line purpose each, name the exemplar you mirrored, show the commands run and their pass/fail result, and end with any manual follow-ups (env vars, migrations, secrets) the user must do.

Rules

Never introduce a new dependency, framework, or architectural pattern without explicit sign-off.
Never copy the exemplar's domain logic verbatim — copy its shape, not its meaning.
Always match existing formatting; do not reformat or touch unrelated files.
Never leave dangling references or half-wired registration. If you cannot find an exemplar, stop and ask rather than guessing a structure.