agentleFS
TalonT-OrgTalonT-Org/AutoSkillit/.claude/skills/render-recipe/SKILL.md

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".

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
  1. Distinctive:

    Do NOT auto-invoke when a recipe is loaded — only on explicit user request

    line 13
  2. Distinctive:

    Add decorative flair, emoji, or unnecessary commentary

    line 20
  3. Very specific:

    Create files outside temp/render-recipe/ and recipes/diagrams/

    line 21
  4. Very specific:

    Use Unicode characters, emoji, or non-ASCII symbols.

    line 22
  5. Distinctive:

    Read the recipe YAML carefully and render exactly what exists

    line 27
  6. Very specific:

    Write output to temp/render-recipe/{recipe-name}_{YYYY-MM-DD_HHMMSS}.md

    line 28
  7. Distinctive:

    If a hidden step is the *only* path between two visible steps, collapse the route — just connect the visible steps directly.

    line 64
  8. Very specific:

    Use a vertical spine with | and +-- branches.

    line 68
  9. Very specific:

    Optional steps: always go on their own +-- branch off the vertical spine: +-- [step-name] (optional).

    line 71
  10. Very specific:

    Back-edges: use brackets: -> plan [-> dry_walkthrough].

    line 75
  11. Distinctive:

    Do not show retry counts, model annotations, or other per-step metadata.

    line 77
  12. Very specific:

    Consistent failure language: Always use x fail for failure branches.

    line 87
  13. Very specific:

    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 | …

    line 89
  14. Distinctive:

    Always adapt the shape to the recipe — do not force a complex layout on a simple recipe.

    line 112
  15. Distinctive:

    Read the recipe YAML from the prompt context or from disk if a path is given.

    line 120
  16. Distinctive:

    All ingredients and their properties

    line 121
  17. Distinctive:

    All steps in declaration order

    line 122
  18. Distinctive:

    Before writing, check the diagram for alignment errors.

    line 136
  19. Very specific:

    Box closure: Every ┌ must have a matching └ at the same indentation level.

    line 139
  20. Distinctive:

    If any check fails, fix the diagram before proceeding.

    line 143

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
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/ and recipes/diagrams/
  • Use Unicode characters, emoji, or non-ASCII symbols. ASCII only — use * for pass, x for 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_cmd steps — value capture, shell one-liners, branch computation. All plumbing.
  • All push_to_remote steps — mechanical transport.
  • All clone_repo steps — 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_worktree steps — 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: route steps — 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.

  1. Main flow runs down the left spine. Show meaningful steps in order.
  2. 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.
  3. Iteration loops are wrapped in a FOR EACH block using +----+ / +----+. Only use this when note: fields indicate iteration over plan_parts or groups.
  4. Self-loops go on the same line with a bidirectional arrow: step <-> [x fail -> handler].
  5. Multi-way routing (on_result) is shown with labeled paths on separate lines.
  6. Back-edges use brackets: -> plan [-> dry_walkthrough].
  7. Terminal steps are omitted. The last visible step is the end of the diagram.
  8. Do not show retry counts, model annotations, or other per-step metadata.
  9. test_check steps display as test.
  10. Use the skill name, not the step key for run_skill steps. But apply these short display names:
    • implement-worktree-no-merge -> implement
    • audit-impl -> audit
    • resolve-failures -> fix
    • open-integration-pr -> open-pr
    • Everything else: use the skill name as-is (e.g., make-plan, dry-walkthrough, rectify)
  11. 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.
  12. Context limit recovery (retry_worktree, on_context_limit) is automatic plumbing — omit it.
  13. Consistent failure language. Always use x fail for failure branches. Never use "NO GO", "FAIL", "failure", or other variants.
  14. 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_plan and make_plan.on_success is dry_walkthrough, show x fail [-> make-plan] with the arrow going to make-plan, not to review-approach. The optional step is only reachable from its primary path, not from back-edges that happen to pass through the same chain.
  15. 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 EACH blocks. 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:

  1. 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 a FOR EACH block's ┌, │, └ characters are indented further than the spine, shift them left to match.
  2. Box closure. Every ┌ must have a matching └ at the same indentation level.
  3. Branch alignment. All ├── branches off the same spine share the same column.
  4. 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:

  1. temp/render-recipe/{recipe-name}_{YYYY-MM-DD_HHMMSS}.md — timestamped history copy
  2. 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 that load_recipe serves to Claude.

Print the full content to terminal.


Output Rules

ContentDestination
Rendered recipe overviewtemp/render-recipe/ (history) + recipes/diagrams/ (live) + terminal
Validation warnings (if any)Terminal only

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.