moyu-strict
by uuczmoyu-strict is a strict anti-over-engineering skill for Code Editing. It helps agents keep changes narrow, confirm scope before edits, avoid new abstractions, and skip unrequested tests, docs, dependencies, or rewrites. Use it when you want the smallest safe diff and predictable review.
This skill scores 64/100, which is just above the listing threshold: it is credible and usable for agents that need strict anti-over-engineering guardrails, but directory users should expect some missing adoption detail and will need to infer parts of the workflow from the prose.
- Explicit trigger condition: activates on any code change, making it easy for an agent to know when to apply it.
- Concrete guardrails are enumerated, including scope confirmation, 20-line diff limits, and avoiding unrequested abstractions, docs, tests, or dependencies.
- The SKILL.md is substantial and structured, with valid frontmatter and multiple sections that describe a real editing discipline rather than a placeholder.
- No install command, scripts, references, or support files are provided, so users must adopt it as a purely instruction-based skill.
- The description is high-level and terse in places, so agents may still need extra interpretation for edge cases and exact enforcement behavior.
Overview of moyu-strict skill
What moyu-strict is
moyu-strict is a guardrail skill for code editing that enforces strict anti-over-engineering behavior. It is meant for situations where you want the smallest safe change, not a polished redesign. The core job is to keep an agent from touching extra files, adding abstractions, or “improving” unrelated code while still satisfying the request.
Who should use it
This moyu-strict skill is best for reviewers, maintainers, and agents working on tightly scoped fixes in existing codebases. If you care about minimal diffs, predictable review, and avoiding accidental side effects, moyu-strict for Code Editing is a strong fit. It is less useful for exploratory refactors, architecture work, or broad cleanup tasks.
What makes it different
The practical difference is enforcement. moyu-strict is not a generic “write better code” prompt; it centers scope control, edit discipline, and restraint. Its strongest signals are the explicit rule set: confirm scope before editing, avoid new abstraction layers, do not add unrequested docs/tests/dependencies, and stop when a change is becoming too large for the ask.
How to Use moyu-strict skill
Install and activate it
Use the repo’s skill install flow for moyu-strict install, then load it when you expect code changes that must stay narrow. If your environment uses a command-based installer, the key idea is to attach moyu-strict before the model starts editing so the constraints shape the first draft, not just the review. For moyu-strict usage, activate it whenever the task is a targeted fix, not a design session.
Read the right files first
Start with skills/moyu-strict/SKILL.md, since that is the source of the strict rules and the activation behavior. Because this repo has a single skill file and no helper scripts, references, or rule folders, there is no hidden workflow tree to chase. The main thing users need is the rule text itself, not an extended repository tour.
Turn a rough task into a strict prompt
The skill works best when the request already names the exact target and the exact boundary. Strong input looks like this: “Fix the null crash in src/parser.ts and only edit that file; do not add tests, comments, or refactoring.” Weak input looks like: “Improve this module.” The first gives moyu-strict something to constrain; the second invites scope drift.
Use it in an edit-confirmation workflow
A good moyu-strict guide is: identify the affected file or function, state the intended change, confirm that no other files should move, then edit. If the task seems to require broader changes, stop and ask whether a smaller version is acceptable. That matches the skill’s strictest value: making overreach visible before it becomes a diff.
moyu-strict skill FAQ
Is moyu-strict just a normal prompt?
No. A normal prompt may ask for concise code, but moyu-strict is specifically about enforcing edit boundaries. It is most valuable when the main risk is not incorrect logic, but unnecessary extra changes.
When should I not use it?
Do not use moyu-strict for tasks that genuinely require a coordinated rewrite, new abstraction, documentation refresh, or test harness creation. If the outcome should include broader cleanup, the skill’s “minimal PR” bias can fight the real goal.
Is it beginner-friendly?
Yes, because the rules are simple and concrete. The main beginner mistake is giving a vague request and expecting the skill to infer the boundary. moyu-strict works better when the user can say what must change and, just as importantly, what must not.
How is it different from ordinary code editing prompts?
Ordinary prompts often optimize for completion. moyu-strict optimizes for restraint. It tells the agent to challenge scope creep, avoid decorative changes, and keep diffs small enough to review quickly. That makes it a better fit for maintenance work than for feature expansion.
How to Improve moyu-strict skill
Specify the exact edit boundary
The biggest quality gain comes from naming the file, function, and intended outcome up front. Instead of “clean this up,” say “change only src/auth.ts to handle empty tokens, and leave the rest untouched.” That helps moyu-strict enforce the narrowest possible response.
State what is forbidden
Because moyu-strict is built around exclusions, you should say what not to add: no new helpers, no comments, no tests, no dependency changes, no formatting-only edits. This matters because the skill’s value is in rejecting unnecessary additions, not in inventing a broader solution.
Watch for the common failure mode
The most common failure is a request that starts small but silently expands into a redesign. When that happens, the best improvement is not “more code quality”; it is shrinking the task. Ask for the smallest acceptable patch, then iterate if needed. That keeps the moyu-strict skill aligned with its strict diff limits and minimal-change philosophy.
Iterate from a tiny first patch
If the first output is too broad, tighten the prompt around one symptom, one file, and one outcome. If the first output is too shallow, add only the missing constraint that matters most, such as “do not change signatures” or “do not modify call sites.” For moyu-strict skill users, better results usually come from sharper boundaries, not longer instructions.