Agent skill
render-recipe
Render a recipe YAML as a compact visual overview with ASCII flow diagram and input table. Only invoke when the user explicitly says "render recipe" or "/render-recipe".
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/render-recipe
SKILL.md
Render Recipe
Produce a compact, structured overview of an AutoSkillit recipe. Reads the recipe YAML (provided in the prompt or loaded via load_recipe), analyzes the step graph, and writes a formatted Markdown file to temp/render-recipe/.
When to Use
- User explicitly says "render recipe", "show recipe overview", or invokes
/render-recipe - Do NOT auto-invoke when a recipe is loaded — only on explicit user request
Critical Constraints
NEVER:
- Modify any source code or recipe files
- Invent steps, ingredients, or routing not in the YAML
- Add decorative flair, emoji, or unnecessary commentary
- Create files outside
temp/render-recipe/andrecipes/diagrams/ - Use Unicode characters, emoji, or non-ASCII symbols. ASCII only — use
*for pass,xfor fail,?for confirm,|for spine,+for joins. No box-drawing characters, no arrows like→or↑, no check marks, no crosses. Write->and(up)instead. - Include HTML comments, hash markers, format version markers, or any metadata in the output. No
<!-- ... -->lines. - Include "Agent-managed" lines listing internal context variables. The user doesn't need to see plumbing state.
ALWAYS:
- Read the recipe YAML carefully and render exactly what exists
- Write output to
temp/render-recipe/{recipe-name}_{YYYY-MM-DD_HHMMSS}.md - Print the rendered content to terminal after writing the file
Rendering Specification
The output has exactly two sections. Follow this structure precisely.
Note: The inputs table is NOT part of the diagram output. It is generated at runtime from the recipe YAML by _format_ingredients_table (single source of truth). Do not include an inputs table in the diagram file.
Section 1: Header
## {name}
Just the name. No description — the user already chose the recipe from the picker.
Section 2: Flow Diagram
Build an ASCII flow diagram showing the step graph. This is the core visual.
Infrastructure steps to hide:
The diagram shows ONLY the skill work — run_skill invocations and test_check. Everything else is plumbing. Hide:
- All
run_cmdsteps — value capture, shell one-liners, branch computation. All plumbing. - All
push_to_remotesteps — mechanical transport. - All
clone_reposteps — setup plumbing. - All issue lifecycle steps —
get_issue_title,claim_issue,release_issue. Plumbing. - All branch creation steps —
create_unique_branch,create_branch. Plumbing. - All CI/CD steps —
wait_for_ci,wait_for_merge_queue,enable_auto_merge,route_queue_mode,reenter_merge_queue,queue_ejected_fix,diagnose_ci. Plumbing. - All
merge_worktreesteps — worktree-back-to-branch merge. Plumbing. - All cleanup steps —
delete_clone,cleanup_failure,confirm_cleanup. Teardown. - All post-PR steps —
review_pr,resolve_review,diagnose_ci,resolve_ci. Post-delivery plumbing. - All
action: routesteps — pure routing nodes with no work.
If a hidden step is the only path between two visible steps, collapse the route — just connect the visible steps directly. The reader should see: "what skills run, in what order, and what happens on failure."
Diagram layout:
Use a vertical spine with | and +-- branches. ASCII only — no Unicode.
- Main flow runs down the left spine. Show meaningful steps in order.
- Optional steps always go on their own
+--branch off the vertical spine:+-- [step-name] (optional). They are never inlined on a horizontal chain. Never repeat the step name outside the brackets. - Iteration loops are wrapped in a
FOR EACHblock using+----+/+----+. Only use this whennote:fields indicate iteration over plan_parts or groups. - Self-loops go on the same line with a bidirectional arrow:
step <-> [x fail -> handler]. - Multi-way routing (
on_result) is shown with labeled paths on separate lines. - Back-edges use brackets:
-> plan [-> dry_walkthrough]. - Terminal steps are omitted. The last visible step is the end of the diagram.
- Do not show retry counts, model annotations, or other per-step metadata.
test_checksteps display astest.- Use the skill name, not the step key for
run_skillsteps. But apply these short display names:implement-worktree-no-merge->implementaudit-impl->auditresolve-failures->fixopen-integration-pr->open-pr- Everything else: use the skill name as-is (e.g.,
make-plan,dry-walkthrough,rectify)
- FOR EACH loop routing (more parts? / all done?) is implicit — omit it. The loop block itself conveys iteration. The first step inside the loop connects directly to the
+----+box — no extra|line needed between them. - Context limit recovery (
retry_worktree,on_context_limit) is automatic plumbing — omit it. - Consistent failure language. Always use
x failfor failure branches. Never use "NO GO", "FAIL", "failure", or other variants. - Back-edge targets must be the actual destination, not an intermediate optional step. When a back-edge (e.g. audit fail) routes to a step that then passes through an optional step before reaching the real target, show the back-edge pointing to the real target directly. Example: if audit fail routes to
make_planandmake_plan.on_successisdry_walkthrough, showx fail [-> make-plan]with the arrow going tomake-plan, not toreview-approach. The optional step is only reachable from its primary path, not from back-edges that happen to pass through the same chain. - Center step names on the vertical spine. When a step name appears on the main spine (not on a branch), center the text relative to the
|character column. All spine-level step names should align to the same visual center.
Reference example for implementation:
+-- [make-groups] (optional)
|
+----+ FOR EACH GROUP:
| |
| make-plan --- [review-approach] (optional) --- dry-walkthrough --- implement --- test <-> [x fail -> fix]
|
+----+
|
+-- [audit] (optional)
| x fail [-> make-plan]
|
open-pr
Adapting to simpler recipes:
- Recipes without iteration do not use
FOR EACHblocks. Just show the linear flow with branches. - Recipes with few optional steps can show them inline on the main flow:
clone ─── audit ─── investigate ─── plan ─── implement ─── test ─── merge ─── push. - Very simple recipes (under 8 meaningful steps) can use a single horizontal chain.
- Always adapt the shape to the recipe — do not force a complex layout on a simple recipe.
Workflow
Step 1: Parse the Recipe
Read the recipe YAML from the prompt context or from disk if a path is given. Identify:
- All ingredients and their properties
- All steps in declaration order
- Infrastructure steps to hide (see expanded list in Section 2)
- The happy path (follow on_success chain from first step)
- Branch points (on_failure to non-terminal, on_result routing)
- Back-edges (on_success/on_failure targets that appear earlier in declaration order)
- Optional steps (optional: true)
- Terminal steps (action: stop)
Step 2: Build the Flow Diagram
Construct the ASCII diagram following the rules in Section 2. Start with the happy path, omit infrastructure steps, then layer in branches and optional annotations.
Step 3: Verify the Diagram
Before writing, check the diagram for alignment errors. Scan every line and verify:
- Spine consistency. The main vertical spine (
│,├,└) must stay in the same column throughout the diagram. Find the column of the first│— every subsequent│,├──, and└──on the main spine must start in that same column. If aFOR EACHblock's┌,│,└characters are indented further than the spine, shift them left to match. - Box closure. Every
┌must have a matching└at the same indentation level. - Branch alignment. All
├──branches off the same spine share the same column. - No trailing whitespace drift. Right-side annotations (
← only if ...) should be column-aligned with each other where practical.
If any check fails, fix the diagram before proceeding. This is a mechanical check — count character positions, do not eyeball it.
Step 4: Assemble and Write
Combine both sections and write to two locations:
temp/render-recipe/{recipe-name}_{YYYY-MM-DD_HHMMSS}.md— timestamped history copy- The recipe's diagram file — for bundled recipes:
src/autoskillit/recipes/diagrams/{recipe-name}.md; for project recipes:.autoskillit/recipes/diagrams/{recipe-name}.md. This is the file thatload_recipeserves to Claude.
Print the full content to terminal.
Output Rules
| Content | Destination |
|---|---|
| Rendered recipe overview | temp/render-recipe/ (history) + recipes/diagrams/ (live) + terminal |
| Validation warnings (if any) | Terminal only |
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?