moyu-en
by uuczmoyu-en is a restraint-first skill for code editing. It helps keep changes surgical, avoid over-engineering, and limit diffs to exactly what the user asked for. Use moyu-en when you need precise, small patches, narrow scope control, and a better guide for minimal code updates.
This skill scores 68/100, which means it is worth listing but best framed as a focused, opinionated workflow aid rather than a broadly self-explanatory install. The repository gives enough trigger logic and behavioral rules for agents to use it with less guesswork than a generic prompt, but users should still expect some interpretation because the install docs are sparse and there is no separate quick-start or reference material.
- Explicit trigger conditions for over-engineering behaviors, making activation fairly easy to recognize.
- Substantial rule-based guidance with multiple constraints and concrete do/don't examples in the skill body.
- No placeholder markers or experimental/test-only signals; the content appears to be a real operational skill, not a stub.
- The frontmatter description is very short, so directory users get limited install-decision context before opening the skill.
- No support files, install command, or reference assets, which reduces operational handoff and makes adoption more dependent on reading the full SKILL.md.
Overview of moyu-en skill
What moyu-en does
moyu-en is a minimal-editing skill for code work. It pushes the model to change only what the user asked for, avoid extra abstractions, and keep diffs small. If you want a moyu-en skill that helps prevent “helpful” overreach, this is aimed at that exact problem.
Who it is best for
Use the moyu-en skill when you care about surgical code edits, strict scope control, or reviewing an assistant that tends to add unrelated cleanup. It is a good fit for maintenance tasks, bug fixes, and one-file changes where the main risk is scope creep, not missing architecture.
What makes it different
The core value is restraint: no new dependency, no rewrite, no unrequested docs, no extra tests, and no defensive code for impossible paths. That makes moyu-en more useful as a guardrail than as a general coding prompt, especially for Code Editing tasks where precision matters more than breadth.
How to Use moyu-en skill
Install moyu-en
Use the skill in your skills workflow, then verify skills/moyu-en is the active path. The repo does not provide a custom install command, so treat moyu-en install as a directory-specific setup step rather than a special script-driven installer.
Give the skill a narrow edit brief
Best results come from prompts that name the exact file, exact change, and exact boundary. For example: “Update src/auth.ts so token refresh only runs on 401 responses; do not change tests or unrelated helpers.” That kind of input matches the moyu-en usage model and gives the skill permission to stay small.
Read the right file first
Start with SKILL.md in skills/moyu-en, because the skill is instruction-heavy and there are no support folders like rules/, references/, or scripts/ to rely on. Then read any repository files that define the target behavior, and ignore files that are only tangentially related.
Work in one constrained pass
For the best moyu-en guide workflow, ask for the smallest acceptable patch first, then review the diff before requesting follow-up changes. If you need a larger refactor, split it into separate prompts so the skill does not interpret a broad goal as permission to rewrite the codebase.
moyu-en skill FAQ
Is moyu-en for Code Editing only?
Yes, primarily. The skill is designed for editing restraint, not brainstorming, architecture design, or expansive code generation. If your task is “make this exact change with minimal blast radius,” moyu-en is a good match.
When should I not use moyu-en?
Do not use it when you actually want broad cleanup, migration work, new abstractions, or a redesign. If the task needs multiple coordinated file updates, the strict “only change what was asked” rule can become a limitation rather than an advantage.
How does it compare with a normal prompt?
A normal prompt may still invite the model to improve style, add helpers, or patch edge cases. moyu-en explicitly suppresses that behavior, which is useful when the main failure mode is over-editing. In practice, the moyu-en skill narrows the assistant’s freedom and makes the diff easier to review.
Is the moyu-en skill beginner friendly?
Yes, if the user can describe the desired change clearly. Beginners benefit because the skill reduces accidental complexity, but they still need to provide a concrete target file, behavior, or bug description for the skill to stay effective.
How to Improve moyu-en skill
Specify the exact boundary
The strongest inputs say what must change and what must not change. For example: “Fix the null check in parser.ts, but leave formatting, comments, and unrelated functions untouched.” That improves moyu-en because it aligns directly with the skill’s anti-overengineering rules.
Describe the smallest acceptable outcome
Tell the model what success looks like in one sentence, not a feature list. If you want a moyu-en usage result that feels disciplined, ask for the least invasive patch that resolves the bug and mention any files that are off-limits.
Review the diff, not the explanation
The skill is meant to produce a small, inspectable change. After the first output, verify whether the diff touched only the requested area, then iterate with a tighter prompt if it drifted. For moyu-en, the quality signal is usually the patch itself, not the prose around it.