moyu-ko
by uuczmoyu-ko is a code-editing skill that keeps changes minimal, scoped, and review-friendly. It helps avoid overengineering by editing only requested files, using the simplest fix, and asking when scope is unclear. Use the moyu-ko skill when you want precise diffs, focused bug fixes, and a practical moyu-ko guide for disciplined code edits.
This skill scores 68/100, which means it is listable but best framed as a focused, opinionated workflow aid rather than a broadly polished install. For directory users, it offers a clear use case—preventing over-engineered edits—but the repository lacks surrounding docs and operational assets that would reduce adoption guesswork further.
- Very clear triggerability: the frontmatter explicitly says it activates when over-engineering patterns are detected, with a detailed 9-point trigger list.
- Strong operational intent: the body defines a concrete editing philosophy centered on minimal diffs, scoped changes, and asking before expanding work.
- Good install-decision value for a narrow audience: the skill is highly specific about when to use it and what behavior it enforces.
- Light supporting infrastructure: there are no scripts, references, resources, rules, or readme files to clarify usage beyond the SKILL.md text.
- Description is extremely short and the repo lacks workflow examples, so users must infer how the agent should apply the policy in real tasks.
Overview of moyu-ko skill
What moyu-ko is for
moyu-ko is a code-editing skill built to stop overengineering before it starts. It helps an AI make the smallest correct change, stay inside the user’s requested scope, and avoid adding extra abstractions, tests, docs, or dependencies unless they were asked for.
Who should install it
Install the moyu-ko skill if you often want an AI to patch existing code, fix a narrow bug, or make a minimal change without a rewrite. It is a strong fit for teams that care about precise diffs, review speed, and keeping implementation churn low.
What makes it different
Unlike a generic prompt that says “be concise,” moyu-ko encodes explicit guardrails: only edit requested files, prefer the simplest implementation, and stop to ask when the request is unclear. That makes it especially useful for moyu-ko for Code Editing when scope control matters more than expansive refactoring.
How to Use moyu-ko skill
Install and activate it
Use the directory’s standard install flow for the moyu-ko install step, then invoke the skill on a task that is clearly a code-editing request. A good trigger is a prompt like: “Use moyu-ko to make only the minimal change needed to fix this bug in src/auth.ts.”
Give the skill a bounded task
The moyu-ko usage pattern works best when you specify:
- the exact file(s) or path(s) to touch
- the desired behavior change
- what must not change
- any known constraints, such as “no new dependencies” or “do not add tests”
Stronger input:
Update
src/cart.tsso the discount only applies to logged-in users. Do not change other pricing logic or create new files.
Weaker input:
Improve the checkout flow.
Read the right files first
For the fastest moyu-ko guide workflow, start with SKILL.md and then inspect the files that define the change surface in your repo. Since this skill repository is intentionally small, the main value is in understanding the behavior rules, not hunting for extra support folders.
Prompt for minimal diffs
When you want the skill to engage well, explicitly ask for the smallest possible edit and mention any hard limits. For example:
Use moyu-ko to patch
api.ts. Change only the validation branch, avoid new helpers, and ask before touching any other file.
moyu-ko skill FAQ
Is moyu-ko only for code editing?
Yes, that is the intended use. The moyu-ko skill is about disciplined editing, not broad planning, architecture work, or greenfield scaffolding. If you need a redesign, a normal prompt may be a better fit.
When should I not use moyu-ko?
Do not use moyu-ko when you actually want the AI to explore multiple approaches, add supporting tests, or clean up adjacent code as part of the task. Its value is scope control, so it can be a poor match for open-ended refactors.
Is it beginner-friendly?
Yes, if you can describe the change clearly. The skill’s rules are simple, but it performs best when the request already has boundaries. Beginners get the best results when they name the file, the behavior, and the “do not touch” list.
How is it different from a normal prompt?
A normal prompt can ask for minimal changes, but moyu-ko makes that the default operating mode. That reduces the chance of accidental rewrites, added abstractions, or extra files when you only wanted a focused edit.
How to Improve moyu-ko skill
Give tighter scope instructions
The biggest quality jump comes from narrowing the edit surface. State the exact file, the smallest section to change, and the outcome you expect. The more precise the request, the less likely moyu-ko is to stall for clarification or over-edit.
Include explicit boundaries
If something must remain untouched, say so. Useful boundaries include:
- “no new helper functions”
- “no new dependencies”
- “do not change public APIs”
- “keep the diff under 10 lines if possible”
These constraints help moyu-ko for Code Editing produce review-friendly output.
Expect questions when the task is ambiguous
One common failure mode is under-specifying the target and expecting the model to infer the rest. If the request could affect other files or requires a new abstraction, moyu-ko should pause and ask. That is a feature, not a bug.
Iterate on the first patch, not the whole plan
If the first output is too broad, tighten the next instruction rather than expanding the task. For example, ask for “only the line that parses the input” instead of “clean up the module.” That keeps moyu-ko usage aligned with its minimal-change design.