R00LLM recipes

A reusable method for agent-assisted project work.

This page records how SuperIntelligenceBuilder moved from an unvalidated C# experiment to a runnable project with guarded execution, three examples, connected documentation, and browser-tested pages.

Research / implementation / editorial review / rendered evidence / validation

It converts the useful decisions from the work into a reference that can be reused. Each recipe names the input, action, evidence, and stopping condition that made the result dependable.

Project details remain where they make the method concrete. Rules that transfer to another repository are stated separately. The expansive draft and sentence review preserve the two editorial stages that produced this page.

R01Reference shelf

Four skill repositories supplied discovery and review criteria. They were shallow-cloned as temporary reading material, not added as project dependencies. Their rules did not replace source or test evidence.

• riekelt/technical-writer 85e53729dd959a2795d593d6769068e342cf3486

  The document checkpoint established kind, audience, reader task, and non-goals before drafting. Its truth rules separated source facts, test observations, agent reports, and reviewer conclusions. Read-aloud, remove-the-name, claim, link, terminology, outline, and cold-read checks shaped the final edit.

  Files: technical-writing/SKILL.md; technical-writing/references/style.md; technical-writing/references/truth.md; reviewing-technical-prose/SKILL.md

• cursor/plugins ecc249f1e306fc64ddf83c7bed16cacf7c2239db

  The technical-writing skill separated tutorial, how-to, reference, and explanation jobs. Its sentence rules favored direct actors, conditions before actions, exact symbols, and stable terms. The unslop pass removed filler, generic claims, synonym cycling, decorative conclusions, and wording that could describe any project.

  Files: pstack/skills/technical-writing/SKILL.md; pstack/skills/unslop/SKILL.md

• vercel-labs/agent-skills 063bee94c3f4df8453406c830b0a7df0f2860278

  The web review prompted checks for semantic controls, keyboard and visible focus, navigation state, target size, responsive overflow, and honest empty or loading states. The writing rules reinforced descriptive headings, direct link labels, compact prose, and consistent naming.

  Files: skills/web-design-guidelines/SKILL.md; skills/writing-guidelines/SKILL.md

• addyosmani/web-quality-skills afa8da942115f2961fdbfa80807ea0b232ff6c00

  The useful audit order was evidence-led: choose representative routes and states, measure the rendered page, localize failures in source, fix the source, and rerun the same checks. The accessibility references supplied concrete reflow, contrast, target-size, semantics, label, focus-order, and consistent-navigation checks.

  Files: skills/web-quality-audit/SKILL.md; skills/accessibility/SKILL.md; accessibility/references/A11Y-PATTERNS.md; accessibility/references/WCAG.md

Project and voice references

skills.sh exposed candidate skills and adoption signals. Popularity chose what to inspect first; source quality, license, scope, and applicability determined what was used.

Bespoke: A Programming Language for People Who Say Please supplied the civil diagnostic voice and exact confirmation phrase. The implementation remains ordinary C#; it borrows tone, not Bespoke syntax or semantics.

DreamBerd, Rockstar, and an English programming-language documentation experiment demonstrated the same useful boundary: the premise can be playful while setup, behavior, errors, and limits stay literal.

Official vendor documentation remained authoritative for .NET, Codex, Claude Code, GitHub Copilot CLI, and every cataloged command-line tool.

R02Clone convention

Keep research repositories outside the product checkout. Use a disposable root whose name identifies the research task, such as ${TMPDIR:-/tmp}/sib-llm-references.

Name skill collections skills__OWNER__REPOSITORY. The prefix groups research by purpose; the owner and repository preserve provenance in file searches and shell history.

research_root="${TMPDIR:-/tmp}/sib-llm-references"
mkdir -p "$research_root"

git clone --depth 1 https://github.com/riekelt/technical-writer.git \
  "$research_root/skills__riekelt__technical-writer"
git clone --depth 1 https://github.com/cursor/plugins.git \
  "$research_root/skills__cursor__plugins"
git clone --depth 1 https://github.com/vercel-labs/agent-skills.git \
  "$research_root/skills__vercel-labs__agent-skills"
git clone --depth 1 https://github.com/addyosmani/web-quality-skills.git \
  "$research_root/skills__addyosmani__web-quality-skills"

--depth 1 fetches the current commit without older history. Record that commit before a rule enters a durable decision record.

for repo in "$research_root"/skills__*; do
  printf '%s\t' "$(basename "$repo")"
  git -C "$repo" rev-parse HEAD
done

find "$research_root" \
  \( -name SKILL.md -o -path '*/references/*.md' \) \
  -print | sort

Read only the skills and references that answer the current task, and read each selected instruction file completely. These repositories supply guidance, so they share no project run command.

R03Work contract

Convert the request into an explicit contract before installation or editing. Record the objective, editable files, preserved files, permitted tools, required artifacts, destructive boundaries, and proof of completion.

1. Read instructions. Start with the nearest AGENTS.md, then applicable parent instructions.
2. Preserve sequence. Turn “first,” “only after,” and “do not skip” into checklist dependencies.
3. Separate diagnosis from change. Collect evidence before a proposed fix can alter it.
4. Name exceptions. Record files or behavior that must survive unchanged.
5. Define readers by task. Replace the generic word “users” with the person deciding whether to run, integrate, inspect, or maintain the project.

Inventory before editing

Map the entry point, reusable source, project files, instructions, generated outputs, documentation, ignored artifacts, and parent-site integration. Read the implementation behind every public behavior claim.

rg --files
rg -n "WithFile|Proceed|Preview|ConfirmationRequired|AgentKind" .
git status --short

In this project, source tracing covered the caller read, dry-run return, existing-file confirmation, adapter discovery, compatibility probes, workspace lock, process launch, and completion-report parser. It also separated writes performed by the builder from edits requested of the coding agent.

Track reader-facing source artifacts—such as AGENTS.md, specifications, decisions, policies, HTML, CSS, and JavaScript. Ignore reproducible build output, runtime reports, workspace locks, and binary screenshots when a manifest preserves their evidence.

R04Research and planning

Begin research with questions. For each unstable or unfamiliar claim, record the question, preferred source, observed answer, project decision, and verification date.

• Use primary sources for installation commands, CLI flags, framework behavior, language versions, and accessibility standards.
• Use skills and example projects for review heuristics, structure, and vocabulary. Verify product behavior in its source, tests, or primary documentation.
• Use popularity to choose what to inspect first, then decide which exact rule transfers.
• Link each external source and state the borrowed idea and project-specific application.
• Date facts that can change. Tie stable implementation facts to source or tests.

Plan observable outcomes

For work spanning design, copy, behavior, and validation, write a change request before implementation. Each item names where to look, the question to ask, the decision to make, the file to change, and the check that proves the outcome.

Give independent defects separate checklist items, even when one patch can change both. Freeze the issue list before editing, record non-goals, and mark an item complete only after its matching validation passes.

The website plan covered visual-system drift, navigation order, Guardrails ownership, joke-forward copy, hidden tasks, incomplete output descriptions, incorrect first-run instructions, mobile layout, and evidence handling. The change request preserves those decisions.

R05Safe execution

Make the default command observational when an agent can edit a workspace. The default SuperIntelligenceBuilder path reads the caller and instruction file, identifies a harness candidate when possible, and prints the exact statement. It does not probe the CLI, launch a child process, create a file, or edit the workspace.

Plain, aligned output names the selected harness, executable, model choice, workspace, instruction state, source location, statement, non-actions, and live-run command. Logs remain readable without terminal colors.

The prompt states the scope: approval covers one run, does not approve every edit, and provides no rollback. Human diagnostics keep the civil voice while stable error codes remain machine-readable.

A zero process exit and a valid run-specific completion report are required protocol evidence. The report remains the agent's assertion; inspect the resulting files before claiming that the task succeeded.

R06Example design

Give each example a distinct reader job and deliverable. Each project references the same reusable source, shows its real fluent statement, and keeps useful generated outputs available for inspection.

Describe every output by its reader purpose; keep its filename as the linked identifier. Shared execution behavior belongs on the examples landing page and in the manual. Workflow-specific paths, warnings, and adoption advice belong on the detail page.

When authenticated execution is part of the claim, run the example through the builder, then build and inspect its files independently after the agent reports completion.

R07Three-pass editorial pipeline

1. Write expansively. Capture every verified fact, decision, command, caveat, and route a reader may need.
2. Review analytically. Quote each sentence or logical unit in a separate file and decide whether to keep, rewrite, remove, combine, move, or extend it.
3. Publish selectively. Apply only accepted decisions to the reader-facing page.

Ask five questions of every content unit:

1. What reader task does this support?
2. What new fact, instruction, constraint, choice, or route does it add?
3. What source or observed behavior supports it?
4. Is this the correct page and position?
5. Should it stay, change, move, or disappear?

Language decisions

• Keep a sentence only when its usefulness answer is specific.
• Use one term per concept: “coding agent” for the external CLI, “adapter” for its integration, “builder” for the C# file, and “dry run” for the non-executing path.
• Put conditions before actions. Use exact filenames, flags, replies, error codes, and expected outputs.
• Remove importance words without consequences, popularity claims after discovery, and conclusions that add no instruction.
• Let the invented API and civil diagnostics carry the humor without labeling the project for the reader.
• Use descriptive headings wherever readers scan for an answer. End on the last useful fact.

R08Documentation system

Give each fact one canonical owner.

When content moves, make the old URL a small redirect with a visible fallback link. Keep the full prose at its canonical destination. Update the parent project index and RSS feed together whenever the public project listing changes.

Reuse the established page shell

Start from the established page shell so a new page inherits the site's design tokens, masthead, global navigation, desktop grid, contents rail, section codes, code panels, tables, focus treatment, mobile transformation, and print behavior. Add only styles required by new content.

• Prefer native headings, links, buttons, tables, and landmarks; add ARIA only where it supplies missing semantics.
• Use one descriptive h1, ordered headings, descriptive links, a skip link, visible focus, and aria-current="page".
• Allow prose and inline code to wrap. Preserve command whitespace when line breaks change meaning.
• Wrap illustrative source excerpts and stack dense comparison rows at narrow widths when scrolling would hide the instruction.

Social preview

Draft one accurate description, write five alternatives, compare clarity, specificity, length, and social-preview fit, then record the winner. Use it consistently in the standard, Open Graph, and X descriptions.

Create a 1200-by-630 local image with the project name, central mechanism, and enough empty space for small previews. Render the SVG with ImageMagick, verify its dimensions, and inspect the raster output.

magick social-card.svg social-card.png
identify social-card.png

R09Rendered review

1. Capture deployed and local pages before changing them. Crawl every important link and interaction so the review covers the complete site.
2. Save full-page desktop and mobile screenshots. Read them directly and compare related pages side by side.
3. Define what a first-time visitor must understand, decide, and do.
4. Ask for independent read-only opinions after evidence collection. Supply screenshots, source, audience, quality bar, and exact questions.
5. Separate observations from interpretations. Turn each finding into one decision: expand, rewrite, remove, rearrange, research further, or keep.
6. Write the change request before editing. Afterward, capture the same routes, viewports, and states.

Desktop 1440 × 900 / mobile 390 × 844 / reflow 320 × 720

Binary screenshots remain ignored in this source-only project. A tracked manifest records target, viewport, browser, purpose, and result.

Questions for every page and breakpoint

1. Does the first viewport identify the page, its purpose, and the next useful route?
2. Are global navigation, local navigation, and current state consistent?
3. Does the content column remain readable without dead space or cramped measures?
4. Do headings, spacing, rules, tables, and code panels match neighboring pages?
5. Does a breakpoint create overflow, hidden source, a stranded label, or a visual-system change?
6. Can a keyboard user see focus and reach controls in visual order?
7. Do links remain distinguishable without color alone?
8. Are non-inline targets large enough and spaced safely?
9. Does any copy sound interchangeable with another project?
10. Does the page repeat behavior owned by a canonical source?
11. Is every visual difference explained by the artifact's purpose?
12. Are applicable loading, empty, error, long-content, no-JavaScript, and reduced-motion states usable?

Automated accessibility output finds issues; it does not certify accessibility. Fix the named source node, then rerun the equivalent browser, keyboard, and visual checks.

R10Validation ladder

Run inexpensive deterministic checks before expensive or state-changing checks.

1. Inspect the diff and run whitespace checks.
2. Parse HTML, XML, JavaScript, CSS, Markdown links, and project configuration.
3. Build the root project and every example with warnings treated as errors.
4. Run the root project and examples in default dry-run mode.
5. Test exact live flags, refusal, approval, near matches, and end-of-input. Use a controlled failure when it can prove a gate without launching a paid agent.
6. Run authenticated integration only when the claim requires real provider execution.
7. Inspect generated files and validate format, links, and traceability independently of the agent report.
8. Serve the site over local HTTP and test rendered routes with Playwright.
9. Run axe, keyboard flows, forms, copy controls, anchors, redirects, console checks, and overflow assertions.
10. Capture and inspect the same viewports used for the baseline.
11. Run the parent index, preview-target, RSS XML, and item-count checks.
12. Record observed results and remaining platform limits.

dotnet build --configuration Release
dotnet run
dotnet run -- --yes,please,proceed

python3 -m http.server 4173 --bind 127.0.0.1

Use a disposable browser harness when Playwright and axe are review tools rather than project dependencies.

browser_root="${TMPDIR:-/tmp}/sib-browser-audit"
mkdir -p "$browser_root"
cd "$browser_root"
npm init -y
npm install --no-save @playwright/test@1.55.0 @axe-core/playwright@4.10.2
npx playwright install chromium

Validate editable HTML with explicit local style exceptions instead of reformatting the repository around a validator's defaults.

npx --yes html-validate@10.4.0 \
  --rule doctype-style:off \
  --rule void-style:off \
  --rule prefer-native-element:off \
  index.html llm-recipes.html examples/index.html

Keep git diff --check, local link resolution, node --check, XML parsing, checksum comparison, and parent-repository checks as separate evidence.

R11Tools and evidence

Keep evidence records separate

• The change request records the issue, decision, files, and planned proof.
• The sentence review records why each content unit stayed, changed, moved, or disappeared.
• The validation record states commands, environment, observations, and limits.
• The screenshot manifest describes ignored binary evidence by route, viewport, browser, purpose, and result.

Generated output files are deliverables. Build products, locks, screenshots, and transient run reports are reproducible evidence and remain ignored. Agent completion reports record provenance, not independent validation.

Name a count's method and scope. Keep “not tested” separate from “failed.” Preserve historical material when its integrity is part of the task; change only the shared navigation when a later request explicitly requires it.

R12Reusable recipe

The pseudo-language below compresses the method while preserving order, evidence boundaries, and the optional live-agent branch. Highlighting is local CSS; the text is understandable without color or JavaScript.

recipe DeliverAgentAssistedProject(request, repository):
    contract := read_instructions_and_define_scope(request, repository)
    inventory := map_source_docs_outputs_and_ignored_artifacts(repository)
    questions := list_unstable_unfamiliar_and_high_risk_claims(inventory)
    sources := research_primary_sources_and_selected_skills(questions)
    plan := write_evidence_linked_checklist(contract, inventory, sources)

    validate_existing_state(plan)
    implement_one_bounded_change_at_a_time(plan)
    build_and_run_default_dry_paths()

    if real_agent_output_is_part_of_the_claim:
        require_explicit_execution_flag("--yes,please,proceed")
        require_exact_existing_file_confirmation_when_applicable()
        run_authenticated_agent()
        inspect_outputs_independently_of_agent_report()

    draft := write_complete_reader_facing_content()
    review := quote_and_decide_every_content_unit(draft)
    page := apply_only_accepted_editorial_decisions(review)

    before := capture_routes_viewports_states()
    implement_documentation_shell_and_content(page)
    after := capture_equivalent_routes_viewports_states()
    compare(before, after)

    run_static_build_runtime_browser_accessibility_and_parent_checks()
    record_observed_results_and_limits()
    keep_temporary_tools_outside_the_product_checkout()

    return source_files, generated_outputs, documentation,
           review_records, validation_record

Completion requires every requested artifact to exist, every planned check to have a recorded result, every accepted issue to map to a change, and every behavior claim to map to source or observation.