reshape
Skill1 starsChanged 18 days agoMIT-0View on GitHub
Reshape existing code the Tesla Valve way: checks become shapes or move to the spring, and the tests the compiler now covers go, one stream at a time. Run it only when the user asks for it, on a scope the user names: it changes code beyond any one task.
In this repository3 other files it gives its agents.
- AGENTS.mdAGENTS.md
- prepareSkill
- tesla-valveSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 35
Read for what no linter sees: a closed choice compared as a string, a validate() called after construction, a value the type leaves …
- Distinctive: line 63
Add first: the spring test that feeds the bad data, and, where the toolchain checks one, the line that proves the wrong use does not …
- Distinctive: line 67
After each slice, show the diff and the checks passing, and go on when the user agrees.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Reshape
The tesla-valve skill reshapes only the code a task touches, so existing code keeps its checks until someone asks for more. This skill is that ask. It holds no rules of its own: every decision below follows the tesla-valve skill and the reference for the language. Read them first.
1. Scope and enforcers
Work in the scope the user names: a module, a directory, a stream. Never the whole repository at once.
Find out which enforcers the project runs, in its config and its CI. A check or a test goes only where its replacement is enforced. Where an enforcer is missing, the checks it would replace stay: name them, and suggest the prepare skill. Configs and CI do not change here.
2. Inventory
List every check and every test of shape in the scope.
- The linters find part of it, and each finding names its rule. The prepare report lists the findings that keep a rule off.
- Read for what no linter sees: a closed choice compared as a string, a
validate()called after construction, a value the type leaves optional but one state needs, a record parsed loose and checked field by field, a derived default, a conversion that cannot fail or a mutable accessor on a type with an invariant, a test that tests only shape.
3. Plan
One row per check, written down before any change. The kind is one of the
three in the tesla-valve skill, or "stays" when no shape holds without a
paragraph of explanation, or when its enforcer is missing. For the loose
delivery_date in the
manifesto:
| check | kind | becomes | held by | tests |
panic!("unknown stock status") | bad data | stock_of refuses it | serde: unknown variant | a spring test feeds it an unknown status |
panic!("backorder without restock days") | wrong use | Backorder { restock_days: u16 } | the compiler: a missing field | its test goes; a spring test feeds a backorder without days |
"in_stock" spelled at every match | wrong use | enum Stock, matched without _ | the compiler; clippy | its test goes |
The user picks the rows.
4. One stream per slice
A slice moves one stream: its type, its spring and its callers.
- The tests pass before the slice and after it. A slice changes how the code is shaped, never what it computes.
- Add first: the spring test that feeds the bad data, and, where the toolchain checks one, the line that proves the wrong use does not compile. Delete second: the check, and each test the shape now covers, naming the enforcer that does.
- After each slice, show the diff and the checks passing, and go on when the user agrees.
5. Slices of their own
- A stale fact. Moving its check to where the operation commits changes what happens when two callers race, so it is a fix, not a reshape. It gets a slice of its own and a test of the intent: two orders for the last item, and one of them succeeds.
- A public API. A narrower type in a public signature breaks the callers outside the repository. Add the typed function beside the old one, let the old one parse and call it, mark it deprecated, and name the breaking change for the next major version. Where untyped code calls in, the runtime check stays.
6. Report
One line per row of the plan, not per test: what the check was, and what holds it now (a shape, the spring, the commit), or why it stays.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.