yzr-skill-creator

yzr-skill-creator

Entry

Classify first, then act; for the execution flow seesection

1. Create a skill: from scratch
2. Improve skill: first dividesingle-point(body wording / typo / reference / comments) andbehavioral(rules / process / script behavior / new features)
3. description optimization: any change touching the frontmatter description(whether the intent is trigger accuracy or wording) always goes through this entry
4. principle validation: audit compliance (report only)

Routing:

• When the user says "optimize the description" but the object is unclear, the default broad sense (body wording and structure) goes through entry 2, and only when the frontmatter is named does it go through entry 3
• When a single request involves both the body and description , first do 2 then 3, and do not mix them into the same round of evaluation

Input and output

Entry	Deliverable
1. Create a skill	the complete skill directory after convergence
2. Improve skill	single-point: the modified file + verify all green + classified report; behavioral: additionally add workspace evaluation artifacts (see ref/improve-workflow.md）
3. description optimization	the new descriptionwritten back after user confirmation (with before/after trigger scores)
4. Principle validation	item-by-item conclusions in the conversation + evidence + suggested fixes

Execution principles

1. Every line proves itself: for each passage touched by a change ask "if it is deleted, would a competent agent do it wrong"; if not, delete it or push it down; new content must be supported by recorded failures and approved by the user, and must not preemptively block imagined holes
2. Placement: routing sections contain only classification criteria and pointers, not execution flow; gate / discipline sentences go at the entry point of the flow they protect; the body keeps only judgment, routing, gates, invocation contracts, and "why". Execution details that exceed one screen, are read together in multiple places, or are extracted by scripts by section—only if one of these three holds should they be an independent ref/ file; otherwise keep them in the corresponding workflow section
3. Mechanical operations go to scripts: for any content first ask "can it be pinned down with a script": anything that can be executed mechanically must be implemented with a script, not constrained by prose; mechanisms rely on code self-description (naming / structure / --help), and neither docstrings nor md restate the mechanism; scripts are execution black boxes, md content categories follow the "placement" whitelist and the invocation contract is given in full (when to call, how to call); if the execution agent is forced to read the source code to call it correctly = md defect
4. Dual readers: the body guides the agent's execution, not a user manual; before writing each passage, first consider whether it can guide the agent's execution, then consider whether it is easy for the user to maintain later
5. Write classes, not examples: user feedback covers only individual scenarios, while the body must hold for a class of requests; before turning feedback into body text, first generalize which class of requests it points to, write rules for the class, and do not copy individual cases into the body
6. Single source and unified naming: One thing is described in only one place, elsewhere at most a reference; use the same name for the same concept throughout
7. Delivery discipline: All-green gates only prove form, not that the content is correct; a batch of changes (touching multiple sections / multiple files / the same wording in multiple places) has blind spots under the diff view. Before delivery, proactively propose a full-text audit of the target skill (the mechanism layer goes through principle validation, the prose layer goes to yzr-writing-review), and execute only after the user agrees; single-point edits are exempt
8. Change surface of the whole folder: The change surface of any entry point is the entire skill folder, not just SKILL.md

workflow

Create a skill

Read ref/create-workflow.md first before acting (interview, bare run, draft, test, evaluate)

Improve skill

Authorization gate (behavioral): first ask the user whether to run the evaluation loop; do not run without approval, do not silently skip evaluation; the creation scenario already has a "confirm test cases first" step as implicit authorization, while the improvement scenario has no such embedded point, so ask explicitly. Read ref/improve-workflow.md first before acting

description optimize

Authorization gate: write back only after user confirmation; write back only if there is no trigger regression. Read ref/description-workflow.md first before acting

Principle validation

Only audit, do not rewrite (if fixes are needed, transfer to entry 2 after user approval); prose quality is not reviewed here, transfer to yzr-writing-review. Read ref/audit-workflow.md first before acting