moyu-ja
by uuczmoyu-ja is a Japanese code editing skill for keeping changes tightly scoped. It favors the smallest safe diff, avoids unrelated edits, and asks for clarification when a request is ambiguous. Use moyu-ja when you need disciplined, minimal updates instead of broad refactors. The moyu-ja guide focuses on restraint, exact scope, and practical change control.
This skill scores 68/100, which means it is listable but best presented with caveats. For directory users, it offers a clearly defined anti-overengineering behavior that an agent can trigger with less guesswork than a generic prompt, but it lacks supporting materials that would make adoption smoother and easier to evaluate at a glance.
- Explicit trigger conditions for overengineering cases, including scope creep, unnecessary abstractions, and unrequested tests/docs.
- Strong operational guidance in Japanese with three clear rules that constrain agent behavior and reduce accidental overreach.
- Substantial body content with headings and examples-like structure, giving the skill more workflow substance than a placeholder prompt.
- No install command, scripts, or support files, so users must rely on the SKILL.md text alone for adoption.
- The description field is very short and the repository provides little external metadata, making it harder to judge fit before installing.
Overview of moyu-ja skill
moyu-ja is a Japanese skill for code editing that helps an AI stay strictly minimal when a change request is narrow. It is best for developers who want a small, exact diff instead of a “helpful” rewrite, especially when they already know the target file, feature, or line range.
The real job of the moyu-ja skill is scope control: only edit what the user asked for, choose the simplest workable fix, and pause when the request is ambiguous or would spill into unrelated files. That makes it useful for maintenance work, bug fixes, and review-driven edits where overengineering is the main risk.
Its main differentiator is restraint. The skill is designed to discourage extra abstractions, extra dependencies, extra tests, and extra documentation when none were requested. If you want a model that preserves the existing design and changes as little as possible, moyu-ja is a strong fit.
moyu-ja for Code Editing
Use moyu-ja when the task is “change this, not that.” It fits code editing jobs where the safest output is the smallest one: a one-line fix, a targeted replacement, or a constrained patch in a known file.
What this skill is good at
- Keeping edits inside the user’s stated scope
- Avoiding unnecessary refactors and wrapper layers
- Preferring existing code paths over new structure
- Asking for confirmation when the request is underspecified
When it is a poor fit
If you want architectural cleanup, broad refactoring, or a solution that revisits surrounding design, moyu-ja will feel too conservative. It is not meant for “improve the whole module while you are here” requests.
How to Use moyu-ja skill
Install and activate moyu-ja
Install the moyu-ja skill in your skills environment, then invoke it for edit tasks where restraint matters. A typical install command in this repo is:
npx skills add uucz/moyu --skill moyu-ja
Use moyu-ja when your prompt contains a clearly bounded edit request, such as fixing one function, adjusting one condition, or applying a tiny behavior change.
Give it a narrow edit brief
The best moyu-ja usage starts with a prompt that names the exact target and the exact limit. Good inputs say what to change, where to change it, and what must not change.
Strong prompt pattern:
- “In
src/auth.ts, only change the token parsing logic. Do not touch unrelated validation.” - “Update this component so it handles empty input, but keep the current structure and avoid new files.”
- “Make the smallest possible fix for the failing case in
PaymentForm; do not add new abstractions.”
Weak prompt pattern:
- “Improve this code.”
- “Make it cleaner.”
- “Refactor this module.”
Read the source in the right order
For this skill, start with SKILL.md, then inspect the repo tree for any adjacent guidance files linked from the repository. If the project includes README.md, AGENTS.md, metadata.json, or support folders such as rules/, resources/, references/, or scripts/, read them only as needed to clarify scope and constraints.
The key is not to over-read. moyu-ja works best when you identify the minimum context needed to edit safely, then stop.
Workflow that gets better results
- Identify the exact file and behavior to change.
- State the desired outcome in one sentence.
- Add constraints like “minimal diff,” “no new files,” or “no new dependency” when they matter.
- Ask for the smallest acceptable fix first.
- If the model asks a clarifying question, answer it instead of broadening the task.
This workflow matches the moyu-ja guide: precise input, minimal scope, no guesswork.
moyu-ja skill FAQ
Is moyu-ja only for Japanese workflows?
No. The skill content is Japanese, but the editing behavior it enforces is general: stay minimal, stay scoped, and avoid unnecessary changes. The moyu-ja skill is still useful if your repository and prompts are in English.
How is this different from a normal prompt?
A normal prompt can ask for careful editing, but moyu-ja encodes that discipline as the default behavior. That matters when the model is tempted to “help” by rewriting too much, adding abstractions, or touching adjacent files.
Is moyu-ja suitable for beginners?
Yes, if the goal is learning how to make smaller, safer edits. It is especially helpful when beginners tend to overcorrect code or add extra layers that are not needed.
When should I not use moyu-ja?
Do not use moyu-ja when the real task is redesign, cleanup across multiple files, or a broader improvement pass. If you want the model to re-evaluate the architecture, a more expansive coding skill is a better fit.
How to Improve moyu-ja skill
Give tighter scope signals
The most important improvement is to specify the boundary of the edit. Name the file, the function, the line region, or the exact behavior. The more explicit the boundary, the less likely the skill is to overreach.
State the constraints that matter
If you care about preserving implementation style, say so. If you do not want new classes, new helpers, new dependencies, comments, tests, or documentation, say that directly. moyu-ja is strongest when the prompt makes the “do less” rule concrete.
Ask for the smallest acceptable fix
A useful moyu-ja improvement loop is to request the minimum viable patch first, then expand only if that patch fails. For example, start with “fix this bug with the smallest diff,” then iterate only if the first answer misses a real requirement.
Watch for overengineering failure modes
The main failure mode this skill is designed to prevent is scope creep: unrelated files changed, abstractions added for a one-off fix, or defensive code introduced for situations the user never asked about. If that happens, tighten the prompt around the exact edit and restate the prohibition on extra work.