agentleFS
cubxxwcubxxw/agent-kit/skills/boundary-demo/SKILL.md

boundary-demo

Skill2 starsChanged 3 months agoMITView on GitHub

Build a disposable, observable demo that answers one uncertain system-boundary, state, integration, or experience decision and preserves reusable case/eval evidence. Use when asked for a demo, prototype, sandbox, spike, boundary explorer, integration simulator, or UI comparison before production implementation. Do not use to ship production features.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 12 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before implementation, write down:

    line 13
  2. Distinctive:

    If these cannot be stated, ask one concise question.

    line 21
  3. Distinctive:

    Do not run all modes by default.

    line 37
  4. Distinctive:

    Prefer Streamlit for Python, data, LLM, state, trace, and human-review probes.

    line 39
  5. Distinctive:

    Prefer a CLI when the question is pure state or business logic and a browser adds no evidence.

    line 40
  6. Distinctive:

    Use an existing Web surface when DOM, CSS, responsive behavior, browser events, or page context is itself under test.

    line 42
  7. Distinctive:

    Only the user can confirm the expected behavior or taste choice.

    line 57
  8. Distinctive:

    Use ordinary pytest for contracts, state transitions, fake adapters, and evaluation.

    line 72
  9. Very specific:

    Use Streamlit AppTest for widgets, Session State, Run/Reset, and rendered outcomes.

    line 74
  10. Distinctive:

    Use Playwright or another browser harness only when actual DOM, CSS, JavaScript, screenshots, resize, or browser timing is part of the …

    line 76
  11. Distinctive:

    Read references/cases-and-review.md for the case lifecycle and P0/P1 review gate.

    line 79
  12. Distinctive:

    Do not copy private project or Brain cases into a public repository.

    line 92
  13. Distinctive:

    Never delete the probe or promote code into production without explicit user authorization.

    line 101

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

Boundary Demo

Build the smallest probe that can change one decision. The deliverable is evidence, not a miniature product.

Start with one decision contract

Before implementation, write down:

  • one question with at least two plausible answers;
  • the evidence that would change the decision;
  • the smallest observable failure;
  • a timebox and stop rule;
  • what is explicitly out of scope.

If these cannot be stated, ask one concise question. Do not expand into a full product specification. Read references/choosing-and-scoping.md when the right probe or medium is unclear.

Choose exactly one mode

  • Boundary: contracts, ownership, external services, failures, retries, or side effects. Default integrations to deterministic fake or read-only adapters.
  • Logic: state machines, data shapes, policies, or transitions. Keep the runner independent of the UI.
  • Taste: interaction or information hierarchy is the uncertainty. Compare two or three materially different variants against the same cases; read references/taste-comparison.md.

Do not run all modes by default. Choose the medium after the mode:

  • Prefer Streamlit for Python, data, LLM, state, trace, and human-review probes.
  • Prefer a CLI when the question is pure state or business logic and a browser adds no evidence.
  • Use an existing Web surface when DOM, CSS, responsive behavior, browser events, or page context is itself under test.

Build an observable probe

Make input, relevant state before and after, trace, output, and failure visible. Seed at least one normal, one edge, and one failure case. Keep four evidence classes separate:

  1. observed fact;
  2. automated verdict;
  3. human choice;
  4. AI hypothesis.

An automated pass never promotes a discovery case to regression or Gold. Only the user can confirm the expected behavior or taste choice.

For a new Streamlit probe, initialize the bundled example:

python <SKILL_DIR>/scripts/init_demo.py <TARGET_DIR> \
  --question "<ONE DECISION QUESTION>"

Then follow references/streamlit-runtime.md. The scaffold uses a project-local configuration with automatic reruns and loopback binding. Never modify a global Streamlit configuration.

Test the boundary, not the disposable shell

  • Use ordinary pytest for contracts, state transitions, fake adapters, and evaluation.
  • Use Streamlit AppTest for widgets, Session State, Run/Reset, and rendered outcomes.
  • Use Playwright or another browser harness only when actual DOM, CSS, JavaScript, screenshots, resize, or browser timing is part of the decision.

Read references/cases-and-review.md for the case lifecycle and P0/P1 review gate.

Authority and side effects

  • A starter must not contain a working real adapter.
  • Real network access, credentials, login state, deployment, or external mutation requires explicit scope for that run.
  • File-save reruns and widget reruns must not repeat side effects. Put adapter calls only behind an explicit Run/Submit event, never at module import or page render time.
  • Redact secrets and personal data from inputs, traces, screenshots, and exported receipts.
  • Do not copy private project or Brain cases into a public repository.

Finish at the decision

Return supported, rejected, or inconclusive, with the decisive cases and remaining uncertainty. Preserve the decision contract, confirmed regression cases, and accepted interface/contract. The UI shell, captures, and exploratory traces are disposable.

Never delete the probe or promote code into production without explicit user authorization. When the decision is accepted, hand the contract and cases to the production project or Product Foundry; rewrite production code under that project's quality gates.

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.