| name | skip-auto-generated-files |
| description | Identify and exclude TeslaCANModder's auto-generated files from feature commits and PRs. The user has explicitly rejected auto-generated diffs twice — they obscure the actual change in code review. |
| license | GPL-3.0 |
| compatibility | opencode |
| metadata | {"area":"workflow","priority":"medium"} |
What I do
Detect files in the TeslaCANModder working tree that are produced by a build step or code generator rather than hand-edited, and exclude them from any commit I propose. The user wants clean, reviewable diffs.
When to use me
Use this skill before every git add or git diff --stat summary I present to the user. If a file in the diff is auto-generated, revert it from the working tree before showing the diff.
Known auto-generated files in this repo
| File | Generated by |
|---|
firmware/lib/client/dashboard/dashboard.h | Generated from include/web/mcp2515_dashboard_ui.src.h and other sources by scripts/minify_dashboard.py during build. Run pio run (any env) to regenerate. |
client/src/docs/_generated-docs.ts | Generated by scripts/generate-docs.ts from docs/ markdown. Run npm run generate:docs (or whatever the package.json script is) to regenerate. |
client/src/docs/_generated-feature-settings.ts (if present) | Same generator. |
Hard rules
- Before staging a commit, run
git status --short and inspect every modified file. If a file is in the known-generated list above, or matches a generator pattern (giant auto-generated header comment, // AUTOGENERATED / // DO NOT EDIT banner, byte-counted arrays that match a .src.h input), revert it:
git checkout -- <path> to discard the working-tree change
- Never include generated files in a feature commit. The reviewer should see only the human-edited change.
- If a generated file is the ONLY file changed by a feature, that is a strong signal that the feature has no real code impact and is either incomplete or a docs-only change that should be reviewed as such.
- If the generated file MUST be updated for the feature to work (rare — usually a feature would update the source, not the generated output), regenerate it via the documented build step and commit it as a separate "regen:" commit, or include it explicitly in the commit message so the reviewer knows.
- When reviewing the diff for the user, do not list generated files in the "files changed" summary. Show only hand-edited files. Mention "regenerated dashboard.h" only if it was deliberately committed.
How to detect an unknown auto-generated file
Signs a file is auto-generated and should not be hand-edited:
- The first 20+ lines are a
// Auto-generated by … or // DO NOT EDIT banner
- The content is a single
const uint8_t arrayName[] = { … } of many bytes (likely minified UI HTML/CSS)
- The file has a corresponding
.src.h or .template input in the repo
- The file is regenerated whenever
pio run runs
If you find such a file, add it to this skill's known list (in a follow-up commit).
Ask first
- If you are unsure whether a file is auto-generated
- Before committing a regenerated generated file (only if the feature genuinely needs it)
- Before editing the build/generator scripts themselves
Why this exists
The user rejected the auto-generated firmware/lib/client/dashboard/dashboard.h diff twice in the same session: first in the BLE distance PR and again after the feifan work. The diff is hundreds of unrelated UI bytes, makes code review impossible, and is regenerated by the build anyway. Keep it out of feature commits.
