build-release-mindset
Skill2 starsChanged 4 months agoMITView on GitHub
Use when touching build scripts, release or packaging steps, publish flows, or CI config.
In this repository19 other files it gives its agents.
- critical-thinkingSkill
- de-ai-proseSkill
- entry-point-auditSkill
- feasibility-guardSkill
- fix-in-the-shared-layerSkill
- fix-the-root-causeSkill
- independent-review-gateSkill
- logging-for-remote-diagnosisSkill
- no-duplicate-logicSkill
- opportunistic-fixesSkill
- performance-at-scaleSkill
- plan-with-teethSkill
- project-onto-all-systemsSkill
- question-the-premiseSkill
- tests-with-teethSkill
- user-action-edge-casesSkill
- using-instinctsSkill
- ux-designer-mindsetSkill
- verify-against-codeSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Start from a guaranteed clean state: remove stale artifacts and intermediates, restore any patched config, before you begin.
≈ “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
The rule
Build and release code has a different discipline than feature code: it must be reproducible, abortable, and reversible. A build that depends on whatever the last run left behind is unreliable by definition. Before you change a build step, ask what happens if it crashes halfway, and whether you could undo the release after it ships.
Fires when
Editing a build script, a release or packaging step, a publish flow, or CI config.
How to apply
- Start from a guaranteed clean state: remove stale artifacts and intermediates, restore any patched config, before you begin.
- Smoke-test the smallest case first and abort fast if it fails; don't run the full matrix on a setup you haven't proven.
- Version artifacts into timestamped outputs instead of overwriting, so rollback is trivial.
- Validate outputs, not just inputs. A silently-empty artifact, or a "0 tests passed" nobody asserted on, is the worst failure mode and the easiest to miss.
- Protect any global state you patch-and-restore with a lock, so a half-finished run doesn't leave the machine broken.
- Know the rollback before you ship.
Worked example
A release script builds against eight SDK versions over an hour, then you discover the first one was broken from the start — the whole hour is wasted. A canary fixes it: build the smallest target first, and abort the run if it fails, so a broken setup costs two minutes instead of sixty. The same instinct catches a "0 tests passed" that would otherwise ship green because nobody asserted the count was above zero — a loud failure is always better than a silent bad artifact.
Red flags
| Thought | Reality |
| "The machine's probably clean" | Probably is not a guarantee; start clean. |
| "It built, so it's good" | Built is not the same as validated. Check the output. |
| "I'll just overwrite the last build" | Then you can't roll back when this one's bad. |
| "All eight will be fine" | Smoke-test one before you spend an hour on eight. |
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.