Generate a behavior spec for your product in 2 minutes

TL;DR: You don't have to learn the PBC format before you see the value. Copy the prompt below, describe a module in your product, and your AI assistant generates a .pbc.md file. Drop it into the PBC viewer to see it rendered as structured UI. Edit what's wrong, commit what's right.

Writing a behavior spec from scratch takes focus. But you shouldn't have to learn a format before you can decide whether it's useful.

Here's a faster way: let your AI assistant draft the spec, then you review it.

The prompt

Copy this into Claude, ChatGPT, or any LLM you use. Replace the description in Step 2 with your own product module.

You are a Product Behavior Contract (PBC) author. Generate a `.pbc.md` file
following the PBC spec format.

**Format rules:**

1. Start with YAML frontmatter: id, title, context, status (always "draft"),
   updated (today's date), and tags.

2. Include these sections in order:
   - **Scope** — bullet list of what this contract covers
   - **Non-goals** — what's explicitly out of scope
   - **Glossary** — table of domain terms + a `pbc:glossary` fenced block
   - **Actors** — table of actors (human/system/external) + a `pbc:actors`
     fenced block
   - **States** — table of states with user_access levels + a `pbc:states`
     fenced block + a mermaid state diagram
   - **Behaviors** — each behavior gets:
     - A prose description
     - Given / When / Then sections
     - Invariants (if any rules must always hold)
     - Edge cases (if any exceptions exist)
     - A `pbc:behavior` block with id, name, actor, description
     - `pbc:preconditions`, `pbc:trigger`, `pbc:outcomes` blocks
     - `pbc:transitions` block (if state changes)
     - `pbc:exceptions` block (if edge cases exist)

3. Behavior IDs follow the pattern: `XXX-BHV-001`, `XXX-BHV-002`, etc.
   where XXX is a short module prefix (e.g., BIL for billing, AUTH for auth).

4. Write in plain, specific language. Avoid vague words like "appropriate"
   or "as needed." Every behavior should be concrete enough that someone
   could check whether the code honors it.

5. Include 4-6 behaviors covering: the happy path, the main failure case,
   at least one edge case, and any critical invariants.

6. Put structured `pbc:*` blocks inside `<details>` tags with a summary
   of `📎 <code>pbc:block_type</code>` so they're collapsible in Markdown
   renderers.

**Now generate a `.pbc.md` for this module:**

[Describe your module here. 3-5 sentences is enough. Example:]

"Our billing module handles monthly subscriptions with a 14-day free trial.
When payment fails, users get a 7-day grace period with full access.
We have three plans: Starter ($12/mo), Growth ($24/mo), and Pro ($48/mo).
Admins can cancel or pause subscriptions. Cancelled subscriptions stay
active until the end of the billing period."

Replace the description at the bottom with your own module. Be specific about the rules that matter — grace periods, limits, who can do what.

What you'll get

The AI will generate a complete .pbc.md file with:

Frontmatter, scope, glossary, actors, states
4-6 behaviors with Given/When/Then structure
Invariants and edge cases
Structured pbc:* blocks that tools can parse
A mermaid state diagram

It won't be perfect. That's the point — you're generating a first draft to react to, not writing from a blank page.

See it in action

Copy the generated output
Open the PBC viewer
Paste or drop the .pbc.md content

The viewer renders the structured blocks as interactive UI: state diagrams you can click, behavior accordions, actor cards, glossary panels. This is what a behavior spec looks like when it's not just a text file.

Edit what's wrong

The AI will get some things wrong. That's actually useful — it surfaces the decisions you haven't made yet.

When you read the generated spec and think "no, the grace period is 14 days not 7" or "we haven't decided whether admins can pause subscriptions" — that reaction is the whole point. You're catching assumptions before they become code.

Fix what's wrong. Add status: draft to behaviors you're unsure about. Remove behaviors that don't exist yet. What's left is a first draft of your product truth.

Commit it

When the spec looks close enough to be useful:

# put it in your repo
cp billing.pbc.md your-project/

# tell your agents about it
echo "Read *.pbc.md files before modifying billing, auth, or entitlement logic." >> CLAUDE.md

Now your agents have product context, not just coding instructions.

What comes next

Edit by hand to refine — the tutorial post walks through the format in detail
Generate more modules — auth, entitlements, onboarding — same prompt, different description
Review with your team — the spec is only as good as the decisions behind it
Browse the examples — the PBC viewer has billing, auth, and workspace contracts you can inspect

If you want Stewie to generate behavior specs directly from your codebase (not from a description): request early access.

The PBC spec is open source at github.com/stewie-sh/pbc-spec. The prompt above works with any LLM. The format is yours — no vendor lock-in.