---
type: eval
skill: src/stdlib/skills/skill_builder/skill.md
skill_root: src/
---

## case: simple_article_writer
input: "Build a skill that writes a short article about a given topic."

### phase: plan_skill
quality:
- The generated skill_name is in snake_case.
- The skill_description (a) accurately summarizes the skill's purpose AND (b) lists at least one trigger context / synonym set the chat router can match against (e.g. "Use whenever the user asks to <action>, <synonym>, or <related-phrasing> — even if they don't explicitly say <skill_name>"). A bare one-line summary without trigger guidance is a fail (= under-triggers in practice).
- The skill_path is correctly formatted as 'reyn/local/{skill_name}'.
- The entry_phase is correctly identified and matches a phase name.
- finish_criteria are relevant and clearly stated.
- All phases in the `phases` list have unique names and valid `role` and `model_class` values.
- Phase instructions focus solely on the target skill's domain logic, not on skill-builder concerns.
- Transitions correctly define the graph flow, with `to` values being only phase names.
- Artifacts list includes all artifacts used as input by phases, with clear descriptions.
- Final output artifact is well-defined with a name and description.
- The `routing` block is populated with intents (= [task] for action skills, [stable_knowledge] for Q&A), 2-5 when_to_use scenario phrases, 1-3 when_not_to_use anti-trigger phrases (cross-referencing sibling skills), and examples.positive (2-3 verbatim phrasings) + examples.negative (1-2 quoting sibling-skill confusion). A missing or empty routing block is a fail — it leaves the chat router with only `description` to match against (= under-triggers in practice, same defect class as a bare description).

### phase: design_artifacts
quality:
- All artifact schemas have `type: object` with `properties` and `required` fields.
- Every property within each schema has a `description` field.
- Required fields are correctly declared for each artifact schema.
- Schemas for review phases contain only verdict fields, not duplicated content.
- Final output artifact schema includes deliverable content and necessary verdict fields.
- Schemas are focused and avoid redundant fields.

### phase: review_plan
quality:
- The reviewer correctly identifies schema issues based on the defined criteria.
- If issues are found, `control.type='rollback'` is emitted with a clear `control.reason.summary` listing numbered problems.
- If no issues are found, the phase transitions to `build_skill` with the `skill_plan` artifact unchanged.

### phase: build_skill
quality:
- skill.md is correctly generated with all required fields (name, description, entry, final_output, finish_criteria, routing).
- The `routing:` block in skill.md is present and copied verbatim from `data.routing` (= intents / when_to_use / when_not_to_use / examples sub-fields all written, even when some lists are short). A skill.md without a routing block is a fail.
- The graph in skill.md correctly reflects the transitions defined in the plan.
- Phase files correctly include `type: phase`, `name`, `input`, `role`, `model_class` (if applicable), and `can_finish` (if applicable).
- Phase instructions are copied verbatim from the plan.
- Artifact files are correctly formatted YAML with `name`, `description`, and `schema`.
- All artifact files and the final output artifact file are written.
- The `build_result` artifact is generated correctly after all files are written.

### phase: verify_skill
quality:
- The lint op is executed with the correct `skill_path`.
- If lint fails, `control.type='rollback'` is emitted with lint issues included in the reason.
- If lint passes, the phase **transitions to `iterate_with_evals`** (= not `finish`) with a correctly structured `skill_builder_result` artifact carrying `max_iterations` + `score_threshold` copied through from `build_result`.
- The `summary` field in `skill_builder_result` describes what the generated skill does for its users, not the build process itself.

### phase: iterate_with_evals
quality:
- When `data.max_iterations == 0`: the phase emits a `finish` decide turn with zero ops and the input artifact passed through verbatim (= legacy fast path).
- When `data.max_iterations > 0`: the phase emits exactly one `run_skill` op invoking `skill_improver` with `target_skill_path`, `max_iterations`, and `score_threshold` taken from input. After the op returns, the phase finishes with a `skill_builder_result` that adds `improvement_summary` (= `iterations_run`, `initial_score`, `final_score`, `termination_reason`, `files_modified`) and a brief tail appended to `summary`.
- If `run_skill` returns `status: error`, the phase still finishes successfully (= build itself was OK) with `improvement_summary.termination_reason = "error"` and a diagnostic note. The workflow is NOT aborted.

## case: complex_review_and_revision_app
input: "Create a skill that generates a legal disclaimer and allows a reviewer to approve or reject it with specific feedback, looping back for revisions."

### phase: plan_skill
quality:
- The generated skill_name is in snake_case.
- The skill_description (a) accurately summarizes the skill's purpose AND (b) lists at least one trigger context / synonym set the chat router can match against (e.g. "Use whenever the user asks to <action>, <synonym>, or <related-phrasing> — even if they don't explicitly say <skill_name>"). A bare one-line summary without trigger guidance is a fail (= under-triggers in practice).
- The skill_path is correctly formatted as 'reyn/local/{skill_name}'.
- The entry_phase is correctly identified and matches a phase name.
- finish_criteria are relevant and clearly stated.
- All phases in the `phases` list have unique names and valid `role` and `model_class` values.
- Phase instructions focus solely on the target skill's domain logic, not on skill-builder concerns.
- Transitions correctly define the graph flow, with `to` values being only phase names.
- Artifacts list includes all artifacts used as input by phases, with clear descriptions.
- Final output artifact is well-defined with a name and description.
- The `routing` block is populated with intents (= [task] for action skills, [stable_knowledge] for Q&A), 2-5 when_to_use scenario phrases, 1-3 when_not_to_use anti-trigger phrases (cross-referencing sibling skills), and examples.positive (2-3 verbatim phrasings) + examples.negative (1-2 quoting sibling-skill confusion). A missing or empty routing block is a fail — it leaves the chat router with only `description` to match against (= under-triggers in practice, same defect class as a bare description).

### phase: design_artifacts
quality:
- All artifact schemas have `type: object` with `properties` and `required` fields.
- Every property within each schema has a `description` field.
- Required fields are correctly declared for each artifact schema.
- Schemas for review phases contain only verdict fields, not duplicated content.
- Final output artifact schema includes deliverable content and necessary verdict fields.
- Schemas are focused and avoid redundant fields.

### phase: review_plan
quality:
- The reviewer correctly identifies schema issues based on the defined criteria.
- If issues are found, `control.type='rollback'` is emitted with a clear `control.reason.summary` listing numbered problems.
- If no issues are found, the phase transitions to `build_skill` with the `skill_plan` artifact unchanged.

### phase: build_skill
quality:
- skill.md is correctly generated with all required fields (name, description, entry, final_output, finish_criteria, routing).
- The `routing:` block in skill.md is present and copied verbatim from `data.routing` (= intents / when_to_use / when_not_to_use / examples sub-fields all written, even when some lists are short). A skill.md without a routing block is a fail.
- The graph in skill.md correctly reflects the transitions defined in the plan.
- Phase files correctly include `type: phase`, `name`, `input`, `role`, `model_class` (if applicable), and `can_finish` (if applicable).
- Phase instructions are copied verbatim from the plan.
- Artifact files are correctly formatted YAML with `name`, `description`, and `schema`.
- All artifact files and the final output artifact file are written.
- The `build_result` artifact is generated correctly after all files are written.

### phase: verify_skill
quality:
- The lint op is executed with the correct `skill_path`.
- If lint fails, `control.type='rollback'` is emitted with lint issues included in the reason.
- If lint passes, the phase **transitions to `iterate_with_evals`** (= not `finish`) with a correctly structured `skill_builder_result` artifact carrying `max_iterations` + `score_threshold` copied through from `build_result`.
- The `summary` field in `skill_builder_result` describes what the generated skill does for its users, not the build process itself.

### phase: iterate_with_evals
quality:
- When `data.max_iterations == 0`: the phase emits a `finish` decide turn with zero ops and the input artifact passed through verbatim (= legacy fast path).
- When `data.max_iterations > 0`: the phase emits exactly one `run_skill` op invoking `skill_improver` with `target_skill_path`, `max_iterations`, and `score_threshold` taken from input. After the op returns, the phase finishes with a `skill_builder_result` that adds `improvement_summary` (= `iterations_run`, `initial_score`, `final_score`, `termination_reason`, `files_modified`) and a brief tail appended to `summary`.
- If `run_skill` returns `status: error`, the phase still finishes successfully (= build itself was OK) with `improvement_summary.termination_reason = "error"` and a diagnostic note. The workflow is NOT aborted.
