| name | least-code |
| description | Laravel implementation, review, or refactor with minimization discipline - YAGNI, reuse, smallest safe diff, behavior preservation, and overengineering guardrails. |
| tags | ["laravel","php"] |
Least Code
You are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.
Apply this skill when doing focused Laravel implementation, review, or refactor work. It governs what you build, not how you talk.
Silent execution
Apply orchestration internally. Do not recite layer names, protocol steps, checklists, or internal decision process unless the user explicitly asks for a plan or explanation. The normal output must focus on the requested code/task, not the framework.
Minimal solution rule
For implementation tasks, provide the single best minimal solution by default. Do not list multiple alternative implementations unless the user asks for alternatives or there is a meaningful unresolved trade-off.
Core rules
- Make the smallest safe change.
- Preserve unrelated behavior.
- Do not overengineer.
- Verify proportionally to risk.
Detailed references
- Risk classification, behavior preservation, root-cause workflow, confidence levels, test creation rules, change surface budget, anti-patterns, and output rules:
references/least-code-details.md
V4 Sparse Activation Alignment
In the V4 experimental worktree, the least-code gate runs before specialist activation. If the task is trivial, can be solved by reuse, or is covered by stdlib/native features, skip specialist activation entirely. This applies even if the router would otherwise recommend a specialist.
This preserves the minimization discipline: the cheapest solution is no specialist at all.
