TOML Generator — Core Skill (Detect → Route → Mirror Updates)
Design happens during REFACTORING, not during coding. See: references/tdd.md
What this skill MUST do
- Detect the project language(s) and framework(s).
- Route to the correct rule references in
references/**. - Generate and maintain a
toml/folder that mirrors architecture. - On ANY user code change: immediately and automatically update impacted TOML files and indexes.
Step 0 — Always start from TOML first (token efficiency)
On follow-ups or re-runs:
- Check if
toml/INDEX.tomlexists.- If YES → read it first, then read relevant
toml/**/*.toml. Only open source files if TOML is missing/outdated or user explicitly asks. - If NO → skip to Step 1 (first-time generation).
- If YES → read it first, then read relevant
Never block on missing TOML — always fall forward to generation.
Step 1 — Detect language & framework (MANDATORY)
Work through signals in order. Stop at first confident match.
Language detection
TypeScript (check first):
tsconfig.jsonexists, ORtypescriptinpackage.jsondependencies/devDependencies, OR.tsor.tsxfiles exist outside test folders (*.test.*,*.spec.*,__tests__/)
JavaScript (fallback):
.jsor.jsxfiles exist in non-test folders, AND- none of the TypeScript signals above are present
Mixed TS+JS project (both signals present):
- Treat as TypeScript project overall
- Per-file: if file is
.ts/.tsx→ apply TS rules; if.js/.jsx→ apply JS rules - Never apply TS rules to
.jsfiles or vice versa
Additional JS signals (do not ignore):
babel.config.jsor.babelrcexists → JS project confirmedjsconfig.jsonexists → JS project with path aliases
Framework detection
React:
reactin dependencies, OR.jsxor.tsxfiles exist, OR- JSX syntax (
<Component,return () found in files
Next.js (check after React):
nextin dependencies, OR/appor/pagesdirectory exists with route-like file patterns
Node server:
express,fastify,koa,hapi, or@nestjs/corein dependencies, OR- Entry files like
server.ts,app.ts,index.tsexist in aserver/orapi/folder
See:
- references/routing.md
- references/javascript/detect.md
- references/typescript/detect.md
Step 2 — Route to ruleset (MANDATORY)
Select exactly one primary ruleset + optional add-ons.
Primary ruleset
| Language | Framework | Rules |
|---|---|---|
| TypeScript | React | references/typescript/react.md + references/typescript/extraction.md |
| TypeScript | (none) | references/typescript/extraction.md |
| JavaScript | React | references/javascript/react.md + references/javascript/extraction.md |
| JavaScript | (none) | references/javascript/extraction.md |
Add-on rules (stack on top of primary)
- Next.js + TS → references/typescript/nextjs.md
- Next.js + JS → references/javascript/nextjs.md
- Node server + TS → references/typescript/node.md
- Node server + JS → references/javascript/node.md
See: references/routing.md
Step 3 — Generate/Update TOML mirror (MANDATORY)
Path mapping rule (never flatten):
path/to/File.ext → toml/path/to/File.toml
Every TOML file MUST include:
[metadata]— name, type, path, description[properties]— interface contract (props/params/returns/exports)[context]— architectural positioning
See: references/index-format.md
Step 4 — Incremental updates (MANDATORY — triggers on every user code change)
When to trigger
This step runs automatically whenever the user:
- Pastes modified source code
- Says "I updated X", "I added Y", "I deleted Z", "I renamed A to B"
- Shares a diff or patch
- Makes ANY code change visible in the conversation
Do NOT wait for the user to ask "update the TOML". Detect the change and update immediately.
What to update per change type
| Change | Action |
|---|---|
| File modified | Re-classify if needed → regenerate toml/<path>.toml → update INDEX entries if type/summary changed |
| File added | Classify → generate new toml/<path>.toml → add entry to both indexes |
| File deleted | Remove toml/<path>.toml → remove entries from both indexes |
| File renamed/moved | Move TOML mirror to new path → update indexes (remove old, add new) → regenerate content if file also changed |
Outdated detection
Treat a TOML as outdated if ANY of:
- TOML file is missing
metadata.source.generated_atis older than the user's stated change datemetadata.source.source_hashmismatches (if hash is tracked)- Exported interface or classification visibly changed
Minimal safe update (when diff is unavailable)
If only a file list is provided (no diff):
- Regenerate TOML for those files only
- Do not touch others
If a diff/patch is provided:
- Update TOML focusing only on exported interface changes:
- New or removed exports
- Changed prop/param contracts
- Changed dependencies (imports)
- Changed architectural role
See: references/diff-update.md
Step 5 — Keep indexes in sync (MANDATORY)
After any generation or update, always sync both:
toml/INDEX.md— human-readable listtoml/INDEX.toml— machine-readable index
Sync checklist:
- Every
toml/**/*.tomlhas a[[files]]entry inINDEX.toml - Every
[[files]]entry points to an existing TOML file - No orphan entries after deletions or moves
- No orphan TOML files after deletions
See: references/index-format.md
Default scope rules
Default scan: .
Include (do not skip):
src/ shared/ lib/ libs/ packages/ apps/ server/ api/ services/ utils/ scripts/
Never skip a folder solely because it is named api.
Exclude:
node_modules/ .git/ dist/ build/ .next/ out/ coverage/
Also exclude: assets, style-only files (.css, .scss), test files.
Non-negotiables
- Never include source code in TOML.
- Never flatten the folder hierarchy.
- Never write trivial descriptions — focus on WHAT + WHY + interface + architectural role.
- Never skip
[context]. - For JS files, prefer
unknownwith a clear description over guessing a wrong type. - For mixed TS+JS projects, apply per-file language rules — never cross-apply.
Design happens during REFACTORING, not during coding. See: references/tdd.md