القائمة
Use when a document carries inline {curly-brace} edit notes to apply in place, or when scattered edits across long drafts or multiple files must stay consistent — no copy-paste round-trips
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when the Kickbacks/vibe-ads ad extension owns the Claude Code statusline and the user wants the Yuumi Tokyo Night statusline back WITHOUT removing the ad — installs a combined HUD+ad statusline and locks it against the extension's rewrites (Claude Code only; macOS/Linux)
Agree on domain, package location, responsibility, and function signatures before implementing — sketch the skeleton, record a design note, hand off code to yuumi:implement. Invoke by hand.
Use when a file, endpoint, module, system, concept, or change (a PR, branch, or diff) needs to be genuinely understood, not skimmed — renders a single-file Anthropic-style HTML explainer that installs a mental model in one read; add a comprehension quiz when the user wants their understanding verified ("a quiz I must pass")
Use when implementing a spec whose reviewer will need the decision trail — resolved ambiguities, deviations, tradeoffs, open questions — not just the diff; keeps a running single-file HTML decision log alongside the code
Use when a plan or spec needs pressure-testing before you build it — finds the holes through an in-depth interview rather than a passive review
Use when a deliverable should be a polished single-file HTML page — a report, explainer, design note, comparison, or anything too long or too visual for chat — rendered in the warm editorial Yuumi visual system
| name | yuumi:edit |
| description | Use when a document carries inline {curly-brace} edit notes to apply in place, or when scattered edits across long drafts or multiple files must stay consistent — no copy-paste round-trips |
| version | 1.6.4 |
Position IS context. Instead of bringing text TO Claude, leave instructions WHERE they belong using {curly brace comments}.
Not for: Single, focused edits where you can just describe what to change
/edit # File under discussion, or search for {thoughts}
/edit draft.md # Specific file
/edit draft.md notes.md # Multiple files
If no file is specified and none is obvious from the conversation, search the working directory for marker comments:
rg "\{[^}]+\}" --type md -l
The search defaults to documents because code files are full of literal braces. A code file the user explicitly names is fair game — handled by the instruction-vs-literal rule below.
Mark edit instructions with curly braces {your instruction here}:
# Why Vaults Matter
Vaults give claude memory
{feels abstract - add concrete mechanism}
Without persistent storage claude forgets everything between sessions
{this is the key point, make it hit harder}
The solution is simple
{dont say simple, show it instead}
{...} comments{...} is an edit instruction only when it reads as a natural-language note to the editor. Braces that belong to the content itself — code, template variables, JSON, math — are not instructions. When genuinely ambiguous, leave the text untouched and list the marker in the summary instead of guessing.{...} markers after processingAfter processing, show a summary:
Processed 3 edits in why-vaults-matter.md:
1. "feels abstract" → added concrete mechanism
2. "make it hit harder" → expanded with specific pain points
3. "dont say simple" → replaced with direct statement
When editing multiple files, ensure references stay consistent:
/edit api.md docs.md changelog.md
If api.md has {rename this endpoint to /users/profile}, update all references in other files too.
{thoughts} wherever something feels off/edit| Instruction | Meaning |
|---|---|
{expand} | Add more detail |
{cut} | Remove this |
{too vague} | Make specific |
{example?} | Add an example |
{tone} | Adjust voice/style |
{→ section X} | This relates to another section |