light
Skill2 starsChanged 4 months agoApache-2.0View on GitHub
Compressed Agent SDLC authoring for a small self-contained change: one short pass writes Brief, a handful of AC, and a short Plan, then hands to gate and a light build. Use instead of the full idea-through-techstack chain when the change is small. Triggers: 'light tier', 'small fix', 'this is a small change', 'skip the full chain', a bug fix or targeted edit of tens of lines. Use AFTER you know the change is small. Use BEFORE gate and build. Scope: Agent SDLC runs only. Default entry for small work; upgrade to the full chain only on a narrow trigger.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Fullive-AI/Animatheir own version, first seen Oct 9, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Fullive-AI/Anima★ 1ksame name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository18 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- acceptance-criteriaSkill
- architecture-designSkill
- buildSkill
- gateSkill
- getting-startedSkill
- handoffSkill
- ideaSkill
- linear-syncSkill
- planSkill
- pr-reviewSkill
- repo-setupSkill
- techstackSkill
- writing-readmesSkill
- writing-repo-docsSkill
- writing-technical-docsSkill
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
- Distinctive: line 8
Write the smallest spec the gate and build can verify, then stop.
- Very specific: line 15
Do not invent Design or Tech Stack to look complete.
- Distinctive: line 62
No Design/Tech Stack unless a trigger fired.
≈ “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
Light: small change, short authoring
Write the smallest spec the gate and build can verify, then stop. Do not run idea, architecture, or techstack unless a trigger below fires.
<HARD-GATE>
Applies when the change is small and self-contained: tens of lines, a few files, no new runtime
dependency, no new public API, no new trust or process boundary. Any of those failing, or the user
asking for the full chain, stops this skill: hand off to `idea` (or the missing full-chain stage).
Do not invent Design or Tech Stack to look complete. Output is Brief + Acceptance Criteria + Plan
in `docs/specs/<feature>/<feature>.md`. Terminal action: user approves the spec, then
`/agent-sdlc:gate`.
</HARD-GATE>Checklist
- Confirm it is still light. New runtime dependency, new public API, or a trust/process boundary -> upgrade: tell the user and start the full chain. When unsure, stay light and upgrade if a trigger appears.
- Write
## Brief. One paragraph: problem and scope. No design, no stack. - Write
## Acceptance Criteria. A handful ofAC-N, same grammar and verification types as the full chain (test-backed / reviewer-checked). Compressed in count, not in rigor. - Write
## Plan. A short set ofT-Nwith*Advances:*,*Component:*(an existing component by name, ornone),*Deps:*, files, and the failing test. Prefer one independently reviewable slice over many microtasks. The checker keeps a named existing component asC-exist-N; do not rewrite every light task tonone. - Do not write
## Designor## Tech Stackunless a trigger fired mid-pass. Their absence is by design. The plan traces to an existing component by name, ornone. - Get approval, then hand to
/agent-sdlc:gate. After a clean gate,/agent-sdlc:buildruns the light build path (no per-task reviewer). Do not start those yourself unless the user asked to continue.
Principles
- Light is the default. Full is the exception.
- Upgrade on a trigger, not on unease. "This might be a feature" is not a trigger.
- Same grammar, fewer sections. The checker still has to parse
AC-NandT-N. - Recommend, don't just ask. Lead with "this is light" and why.
Rationalizations
| Excuse | Rebuttal |
| "When unsure I should run the full chain." | Unsure stays light. Upgrade when a trigger fires. |
| "I'll add Design so the gate looks happier." | Absence of Design is valid. Do not gold-plate the spec. |
| "It's a new file, so it's a new component." | A new file in an existing area is not a new public API. |
Red flags
- Architecture or techstack started for a tens-of-lines edit.
- Light used after adding a runtime dependency or a public API.
- Plan split into microtasks that cannot be reviewed on their own.
Done when
- Brief, AC, and Plan are written and approved.
- No Design/Tech Stack unless a trigger fired.
- The hand-off to gate is stated.
The artifact (output)
docs/specs/<feature>/<feature>.md with ## Brief, ## Acceptance Criteria, ## Plan only
(plus Design/Tech Stack only if a trigger fired). Same file the full chain uses.
Conventions
- Same spec path and
AC-N/T-Ngrammar as the full chain. - Downstream:
/agent-sdlc:gate, then light/agent-sdlc:build, then/agent-sdlc:pr-review. - Load-bearing detail: reference/light-tier.md.
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.