render-recipe
Skill5 starsChanged 6 months agoMITView on GitHub
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".
In this repository23 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .github/CLAUDE.mdCLAUDE.md
- tests/CLAUDE.mdCLAUDE.md
- audit-archSkill
- audit-bugsSkill
- audit-cohesionSkill
- audit-defense-standardsSkill
- audit-testsSkill
- chart-courseSkill
- check-bearingSkill
- design-guardsSkill
- elaborate-phaseSkill
- id-slopSkill
- make-arch-diagSkill
- make-reqSkill
- make-scenariosSkill
- promote-to-mainSkill
- review-promotionSkill
- update-architectureSkill
- update-reqsSkill
- update-specsSkill
- validate-auditSkill
- verify-diagSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
20 rules. About 0 are common, 11 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Do NOT auto-invoke when a recipe is loaded — only on explicit user request
- Distinctive: line 20
Add decorative flair, emoji, or unnecessary commentary
- Very specific: line 21
Create files outside temp/render-recipe/ and recipes/diagrams/
- Very specific: line 22
Use Unicode characters, emoji, or non-ASCII symbols.
- Distinctive: line 27
Read the recipe YAML carefully and render exactly what exists
- Very specific: line 28
Write output to temp/render-recipe/{recipe-name}_{YYYY-MM-DD_HHMMSS}.md
- Distinctive: line 64
If a hidden step is the *only* path between two visible steps, collapse the route — just connect the visible steps directly.
- Very specific: line 68
Use a vertical spine with | and +-- branches.
- Very specific: line 71
Optional steps: always go on their own +-- branch off the vertical spine: +-- [step-name] (optional).
- Very specific: line 75
Back-edges: use brackets: -> plan [-> dry_walkthrough].
- Distinctive: line 77
Do not show retry counts, model annotations, or other per-step metadata.
- Very specific: line 87
Consistent failure language: Always use x fail for failure branches.
- Very specific: line 89
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 | …
- Distinctive: line 112
Always adapt the shape to the recipe — do not force a complex layout on a simple recipe.
- Distinctive: line 120
Read the recipe YAML from the prompt context or from disk if a path is given.
- Distinctive: line 121
All ingredients and their properties
- Distinctive: line 122
All steps in declaration order
- Distinctive: line 136
Before writing, check the diagram for alignment errors.
- Very specific: line 139
Box closure: Every ┌ must have a matching └ at the same indentation level.
- Distinctive: line 143
If any check fails, fix the diagram before proceeding.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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-prAdapting 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 |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

