swamp-club/swamp-extensions

Watch

Fork 0

feat(stagecraft): a getting-started walkthrough for a first factory, and incident-review, content-review and openapi-models examples (swamp-club #2931) #432

Merged

seth merged 1 commit from cue/2931-gatorwalk-factory-skill into main

2026-10-02 02:58:41 +00:00

seth commented

2026-10-02 02:56:52 +00:00

Owner

Closes swamp-club #2931.

What

references/getting-started.md: a guided walkthrough for a first factory, modelled on swamp-getting-started.
- The states run goal → factory created → validated → seen in the studio → simulated → first work item (optional) → graduated.
- Each state has a Verify and an On failure.
- It opens with a checklist, and a "Before starting" step hands off when a factory already exists.
- It asks about the person's goal in their own words, with an early exit for anyone who already uses factory terms.
- It links to authoring.md's states for the actual work instead of repeating them.
Routing:
- In a repo with no factory, a new factory now starts at the walkthrough. SKILL.md, authoring.md (Before starting) and driving.md (Set up a factory) all send it there.
- SKILL.md's description gains name-neutral factory triggers ("set up a factory", "my first factory", "get started with stagecraft", …).
- It also gains an explicit not-for clause: getting started with swamp, swamp workflows, software-factory, issue-lifecycle.
Three new examples:
- incident-review.yaml: timeline → analysis → second-reader review → a person signs off on the action items → publish.
- content-review.yaml: draft → editorial review → a person approves → publish.
- openapi-models.yaml: one work item is an API's OpenAPI spec, or a slice of it, and ends with a swamp extension whose models call the API.
  - The stages are scope → mapping → mapping review and approval → implement (tests against a local fake, never the live API) → check and code review → try-it (optional) → release (registry push or kept local).
  - try-it is a live call with the person's key from a vault.
- Each new example validates with no warnings and runs its saved scenarios. Each review prompt carries a severity rubric suited to what it reviews.
- Their loops are bounded with maxCycles, and their revise exits need the person's recorded feedback.
starter.yaml is unchanged, as decided in triage: it stays the simple software template.
Tests:
- examples_test: the expected set, no warnings, and the rubric. The rubric phrase is now "against the size of the", since non-software reviews judge against the incident or the piece. The implement-injects-review test is now a table.
- tracker examples_test: the status keys.
- factories_test: stages, human stops and revise wiring per new example, plus the openapi try-it gates.
- studio fixtures: the new examples are added.
- skill_test: a new check that every link in getting-started.md points at a file and heading that exist.
Not added:
- There is no init --from. The walkthrough copies the example in the way authoring.md already does, and adding a method was out of scope.
- No manifest exists yet, so there is no version bump.

Verification

Attestation posted for this commit.
verify-build: 12/12 passed, 2 skipped by guard.
verify-reviews: code-review and adversarial-review both pass.
Two low-severity review notes on the link check, left as follow-ups:
- Fenced code blocks aren't stripped before headings are collected.
- Only getting-started.md's links are checked.

Acceptance run

Setup:

A separate claude -p process, not a subagent, in a scratch swamp repo outside this checkout.
stagecraft was added as an extension source, and only the skill was installed.
It was driven turn by turn with --resume, with Claude answering as the person.

First attempt: the agent read authoring.md and skipped the walkthrough. That led to the routing rule above.

Re-run (transcript below):

The agent showed the checklist and asked its questions in plain words.
It built post-incident-review from incident-review. validate reported 0 warnings and 3 saved scenarios passed, including the person's "never published without sign-off" rule.
It started the studio and walked the person through it, offered Simulate, and graduated with next steps.

The studio stops when a headless -p turn ends. I re-served it and confirmed /api/factories lists post-incident-review.

Transcript

Person: I want to set up a factory for our post-incident reviews.

Skill: stagecraft
Read: .claude/skills/stagecraft/references/getting-started.md
Bash: swamp model search stagecraft --json
Bash: swamp model type search stagecraft --json 2>&1
Read: .claude/skills/stagecraft/references/examples/incident-review.yaml

Agent: This repo has the stagecraft extension installed and no factories yet, so we'll build your first one. Here's how it'll go:

Your process, in your words
The factory, built from the closest example
Checked for problems
Seen in the studio, a page that draws the process
A sample review walked through it, to see it move
Optionally, your first real incident review
What to do next

There's a ready-made incident-review example that should fit closely. Before I adapt it, tell me how your reviews actually run. Next to each question is what I'll assume if you don't say otherwise, so a short answer is fine:

What goes in, and what comes out?
Assumed: an incident goes in, and a published, blameless review comes out.
Who does what?
Assumed: an agent drafts the timeline with you from chat logs, alerts and dashboards. It then writes the analysis: what contributed to the incident, and action items that each have an owner. A separate agent acts as a second reader and tries to poke holes in the analysis.
Where must a person decide?
Assumed: someone signs off on the action items before anything is published, and someone confirms before a review is abandoned.
What counts as done?
Assumed: the review is published somewhere, with the location recorded. Where do yours go: a wiki, a doc, a shared folder?
What sends work back?
Assumed: the second reader finds a serious problem, such as a wrong cause, a missed factor or blame on a person, or the sign-off person asks for changes. After three rounds, a person decides whether another round is worth it.

Also: is there anything your write-ups always include that I haven't mentioned? For example, severity, detection time, customer impact, or follow-up tickets in a tracker. I'll track tickets in stagecraft's built-in tracker unless you use something like Linear.

Person: Mostly right. We publish to our Confluence space, a page under Incidents. Every write-up has a severity (SEV1 to SEV3). Our on-call lead signs off. And the one thing that must never happen: a review gets published without sign-off. Built-in tracker is fine.

Read: .claude/skills/stagecraft/references/authoring.md
Read: .claude/skills/stagecraft/references/scenarios.md
Bash: swamp model create @swamp/stagecraft/tracker incidents --global-arg prefix=inc --json && swamp model create @swamp/stagecraft/factory post-i
Read: models/@swamp/stagecraft/factory/post-incident-review.yaml
Read: models/@swamp/stagecraft/tracker/incidents.yaml
Edit: models/@swamp/stagecraft/tracker/incidents.yaml

Agent: The tracker is set up. Now I'm writing the factory definition: adding severity, the on-call lead's sign-off and the Confluence publish step.

Write: models/@swamp/stagecraft/factory/post-incident-review.yaml
Bash: swamp model method run post-incident-review validate 2>&1

Agent: That failure is mine: an unquoted comma inside the scenario's feedback text broke the YAML. Fixing it.

Edit: models/@swamp/stagecraft/factory/post-incident-review.yaml
Edit: models/@swamp/stagecraft/factory/post-incident-review.yaml
Bash: swamp model method run post-incident-review validate 2>&1

Agent: Validation is clean: no warnings, and all three saved scenarios pass. Starting the studio so you can see the factory.

Bash: swamp model create @swamp/stagecraft/studio studio --json >/dev/null && echo created
Bash (background): swamp model method run studio serve 2>&1
Read: <the studio serve output file>

Agent: I've built your post-incident review factory, post-incident-review, and it passes its checks: no problems found, and all three sample paths through it work as expected.

See it in the studio: http://127.0.0.1:37967/ (it stays running)

How a review moves through it:

timeline: you and an agent write the timeline from chat logs, alerts and dashboards. It records the incident's name, severity (SEV1, SEV2 or SEV3; the agent asks you and never guesses), a summary, the events in order and the impact.
analysis: an agent writes the contributing factors without blame, action items that each have an owner, and what went well.
review: a second agent tries to poke holes in the analysis. A serious finding sends the analysis back: a wrong cause, a missed factor that would let it happen again, or blame on a person. Anything smaller doesn't hold it up. The reviewer keeps its review in proportion to the severity, so a SEV3 gets a short one.
sign-off: it stops here for your on-call lead. They either sign off, or send it back with their feedback written down so the next analysis has to address it.
publish: the review becomes a page under Incidents in your Confluence space, titled like "SEV2: Checkout outage", and the page's URL is recorded.

The analysis can be sent back at most 3 times; after that, a person decides whether another round is worth it. Abandoning a review also needs a person to confirm.

Your "never published without sign-off" rule is enforced, not just intended. The only way into publish is the on-call lead's sign-off, and I saved a test path that validate checks every time the factory changes. It confirms that a review can't go to publish:

before the lead signs off,
after they decline, or
on an old sign-off: if they sign off and then send it back, the revised analysis needs a fresh sign-off.

In the studio, gold marks the places it stops for a person. Simulate plays these paths step by step. The page is read-only, so tell me any change you want in plain words, or paste a line from Copy reference.

I also set up the built-in tracker, incidents. Its tickets get ids starting with inc-, with "incident" as the ticket type.

Does the design look right? If so, we can run a real incident through it now and drive it to its first stop for the on-call lead, or leave that for later.

Person:
bx03qdeor
toolu_01ANnqP7S4QiciojhsKURrHS
stopped

Background shell command didn't finish before the previous session ended

No completion record was found for it in the previous session. It may have been stopped (via the UI, Monitor timeout, or agent teardown — these leave no transcript marker), or it may have been running when the previous Claude Code process exited. Check the output file for partial results before assuming it completed.

Person: I opened the studio and it looks right. I played the sign-off path in Simulate and it makes sense. Let's leave a real incident for later.

Agent: Good, the factory is ready, and we'll leave the first real incident for later.

What you have

Factory post-incident-review: timeline (with severity) → analysis → second-reader review → on-call lead sign-off → publish to Confluence under Incidents.
Stops for a person: the on-call lead's sign-off, confirming a duplicate incident, and abandoning a review.
Saved paths that validate checks on every change:
- never-published-without-sign-off, your hard rule.
- timeline-to-published, the normal path.
- sign-off-feedback, where the lead sends it back.
Tracker incidents: built in, ticket ids start with inc-.

The studio server has stopped now that the earlier session ended. When you want the page again, run swamp model method run studio serve and open the URL it prints.

The new files are under models/ and haven't been committed yet.

Possible next steps:

Start the first review when an incident comes in: just say "start a review for ". I'll file the ticket and drive it to the on-call lead's sign-off.
Add fields to the write-up: for example, detection time, time to recover, or links to follow-up tickets.
Commit the factory so the rest of the team can use it.

Want me to do any of these now?

Eval cases for the walkthrough (for #2912)

Not added here; #2912 builds the suite. Each case loads only the stagecraft skill.

1. first-factory-non-software

Scaffold: swamp init --tool none, swamp extension source add <stagecraft checkout from EVAL_STAGECRAFT_DIR>.
Prompt: "I want to set up a factory for our post-incident reviews." The history file supplies the person's answers: Confluence, a SEV1–SEV3 severity, the on-call lead signs off, never published without sign-off, built-in tracker.
Graders:
- tool_used Read with input_match: getting-started\.md.
- tool_used Bash with input_match: method run .* validate, min: 1.
- tool_used Bash with input_match: studio serve.
- file_exists models/@swamp/stagecraft/factory/*.yaml.
- regex on the trace for saved scenario\(s\) passed.
- llm rubric:
  - shows the checklist;
  - asks its questions in one message, in plain words, without making the person learn factory terms;
  - checks each step before moving on;
  - writes the person's must-never rule as a saved scenario;
  - ends with next steps.

2. existing-factory-hands-off

Scaffold: as above, plus a factory created from minimal.
Prompt: "set up a factory".
Graders:
- regex on last_message: it says a factory exists and asks whether to change it, make another or drive work.
- tool_used Bash with input_match: model create @swamp/stagecraft/factory, max: 0.

Trigger phrases

Should trigger: "set up a factory", "my first factory", "get started with stagecraft", "build a factory for our review process", "a process where agents do the work and a person approves each stage".
Should not trigger:
- "get started with swamp" (swamp-getting-started);
- "create a workflow that runs nightly" (swamp workflows);
- "automate this nightly job";
- "triage issue 42" (issue-lifecycle);
- "run the software-factory".

🤖 Generated with Claude Code

Closes swamp-club #2931. ## What - **`references/getting-started.md`**: a guided walkthrough for a first factory, modelled on swamp-getting-started. - The states run goal → factory created → validated → seen in the studio → simulated → first work item (optional) → graduated. - Each state has a Verify and an On failure. - It opens with a checklist, and a "Before starting" step hands off when a factory already exists. - It asks about the person's goal in their own words, with an early exit for anyone who already uses factory terms. - It links to `authoring.md`'s states for the actual work instead of repeating them. - **Routing**: - In a repo with no factory, a new factory now starts at the walkthrough. SKILL.md, `authoring.md` (Before starting) and `driving.md` (Set up a factory) all send it there. - SKILL.md's description gains name-neutral factory triggers ("set up a factory", "my first factory", "get started with stagecraft", …). - It also gains an explicit not-for clause: getting started with swamp, swamp workflows, software-factory, issue-lifecycle. - **Three new examples**: - **`incident-review.yaml`**: timeline → analysis → second-reader review → a person signs off on the action items → publish. - **`content-review.yaml`**: draft → editorial review → a person approves → publish. - **`openapi-models.yaml`**: one work item is an API's OpenAPI spec, or a slice of it, and ends with a swamp extension whose models call the API. - The stages are scope → mapping → mapping review and approval → implement (tests against a local fake, never the live API) → check and code review → try-it (optional) → release (registry push or kept local). - try-it is a live call with the person's key from a vault. - Each new example validates with no warnings and runs its saved scenarios. Each review prompt carries a severity rubric suited to what it reviews. - Their loops are bounded with `maxCycles`, and their `revise` exits need the person's recorded feedback. - **`starter.yaml` is unchanged**, as decided in triage: it stays the simple software template. - **Tests**: - **examples_test**: the expected set, no warnings, and the rubric. The rubric phrase is now "against the size of the", since non-software reviews judge against the incident or the piece. The implement-injects-review test is now a table. - **tracker examples_test**: the status keys. - **factories_test**: stages, human stops and revise wiring per new example, plus the openapi try-it gates. - **studio fixtures**: the new examples are added. - **skill_test**: a new check that every link in `getting-started.md` points at a file and heading that exist. - **Not added**: - There is no `init --from`. The walkthrough copies the example in the way `authoring.md` already does, and adding a method was out of scope. - No manifest exists yet, so there is no version bump. ## Verification - Attestation posted for this commit. - **verify-build**: 12/12 passed, 2 skipped by guard. - **verify-reviews**: code-review and adversarial-review both pass. - **Two low-severity review notes on the link check, left as follow-ups:** - Fenced code blocks aren't stripped before headings are collected. - Only `getting-started.md`'s links are checked. ## Acceptance run **Setup:** - A separate `claude -p` process, not a subagent, in a scratch swamp repo outside this checkout. - stagecraft was added as an extension source, and only the skill was installed. - It was driven turn by turn with `--resume`, with Claude answering as the person. **First attempt:** the agent read `authoring.md` and skipped the walkthrough. That led to the routing rule above. **Re-run** (transcript below): - The agent showed the checklist and asked its questions in plain words. - It built `post-incident-review` from `incident-review`. `validate` reported 0 warnings and 3 saved scenarios passed, including the person's "never published without sign-off" rule. - It started the studio and walked the person through it, offered Simulate, and graduated with next steps. The studio stops when a headless `-p` turn ends. I re-served it and confirmed `/api/factories` lists `post-incident-review`. <details><summary>Transcript</summary> **Person:** I want to set up a factory for our post-incident reviews. - `Skill`: `stagecraft` - `Read`: `.claude/skills/stagecraft/references/getting-started.md` - `Bash`: `swamp model search stagecraft --json` - `Bash`: `swamp model type search stagecraft --json 2>&1` - `Read`: `.claude/skills/stagecraft/references/examples/incident-review.yaml` **Agent:** This repo has the stagecraft extension installed and no factories yet, so we'll build your first one. Here's how it'll go: 1. Your process, in your words 2. The factory, built from the closest example 3. Checked for problems 4. Seen in the studio, a page that draws the process 5. A sample review walked through it, to see it move 6. Optionally, your first real incident review 7. What to do next There's a ready-made incident-review example that should fit closely. Before I adapt it, tell me how your reviews actually run. Next to each question is what I'll assume if you don't say otherwise, so a short answer is fine: 1. **What goes in, and what comes out?** *Assumed:* an incident goes in, and a published, blameless review comes out. 2. **Who does what?** *Assumed:* an agent drafts the timeline with you from chat logs, alerts and dashboards. It then writes the analysis: what contributed to the incident, and action items that each have an owner. A separate agent acts as a second reader and tries to poke holes in the analysis. 3. **Where must a person decide?** *Assumed:* someone signs off on the action items before anything is published, and someone confirms before a review is abandoned. 4. **What counts as done?** *Assumed:* the review is published somewhere, with the location recorded. Where do yours go: a wiki, a doc, a shared folder? 5. **What sends work back?** *Assumed:* the second reader finds a serious problem, such as a wrong cause, a missed factor or blame on a person, or the sign-off person asks for changes. After three rounds, a person decides whether another round is worth it. Also: is there anything your write-ups always include that I haven't mentioned? For example, severity, detection time, customer impact, or follow-up tickets in a tracker. I'll track tickets in stagecraft's built-in tracker unless you use something like Linear. **Person:** Mostly right. We publish to our Confluence space, a page under Incidents. Every write-up has a severity (SEV1 to SEV3). Our on-call lead signs off. And the one thing that must never happen: a review gets published without sign-off. Built-in tracker is fine. - `Read`: `.claude/skills/stagecraft/references/authoring.md` - `Read`: `.claude/skills/stagecraft/references/scenarios.md` - `Bash`: `swamp model create @swamp/stagecraft/tracker incidents --global-arg prefix=inc --json && swamp model create @swamp/stagecraft/factory post-i` - `Read`: `models/@swamp/stagecraft/factory/post-incident-review.yaml` - `Read`: `models/@swamp/stagecraft/tracker/incidents.yaml` - `Edit`: `models/@swamp/stagecraft/tracker/incidents.yaml` **Agent:** The tracker is set up. Now I'm writing the factory definition: adding severity, the on-call lead's sign-off and the Confluence publish step. - `Write`: `models/@swamp/stagecraft/factory/post-incident-review.yaml` - `Bash`: `swamp model method run post-incident-review validate 2>&1` **Agent:** That failure is mine: an unquoted comma inside the scenario's feedback text broke the YAML. Fixing it. - `Edit`: `models/@swamp/stagecraft/factory/post-incident-review.yaml` - `Edit`: `models/@swamp/stagecraft/factory/post-incident-review.yaml` - `Bash`: `swamp model method run post-incident-review validate 2>&1` **Agent:** Validation is clean: no warnings, and all three saved scenarios pass. Starting the studio so you can see the factory. - `Bash`: `swamp model create @swamp/stagecraft/studio studio --json >/dev/null && echo created` - `Bash` (background): `swamp model method run studio serve 2>&1` - `Read`: `<the studio serve output file>` **Agent:** I've built your post-incident review factory, `post-incident-review`, and it passes its checks: no problems found, and all three sample paths through it work as expected. **See it in the studio:** http://127.0.0.1:37967/ (it stays running) **How a review moves through it:** 1. **timeline**: you and an agent write the timeline from chat logs, alerts and dashboards. It records the incident's name, severity (SEV1, SEV2 or SEV3; the agent asks you and never guesses), a summary, the events in order and the impact. 2. **analysis**: an agent writes the contributing factors without blame, action items that each have an owner, and what went well. 3. **review**: a second agent tries to poke holes in the analysis. A serious finding sends the analysis back: a wrong cause, a missed factor that would let it happen again, or blame on a person. Anything smaller doesn't hold it up. The reviewer keeps its review in proportion to the severity, so a SEV3 gets a short one. 4. **sign-off**: it stops here for your on-call lead. They either sign off, or send it back with their feedback written down so the next analysis has to address it. 5. **publish**: the review becomes a page under Incidents in your Confluence space, titled like "SEV2: Checkout outage", and the page's URL is recorded. The analysis can be sent back at most 3 times; after that, a person decides whether another round is worth it. Abandoning a review also needs a person to confirm. **Your "never published without sign-off" rule** is enforced, not just intended. The only way into publish is the on-call lead's sign-off, and I saved a test path that `validate` checks every time the factory changes. It confirms that a review can't go to publish: - before the lead signs off, - after they decline, or - on an old sign-off: if they sign off and then send it back, the revised analysis needs a fresh sign-off. In the studio, gold marks the places it stops for a person. **Simulate** plays these paths step by step. The page is read-only, so tell me any change you want in plain words, or paste a line from **Copy reference**. I also set up the built-in tracker, `incidents`. Its tickets get ids starting with `inc-`, with "incident" as the ticket type. Does the design look right? If so, we can run a real incident through it now and drive it to its first stop for the on-call lead, or leave that for later. **Person:** <task-notification> <task-id>bx03qdeor</task-id> <tool-use-id>toolu_01ANnqP7S4QiciojhsKURrHS</tool-use-id> <status>stopped</status> <summary>Background shell command didn't finish before the previous session ended</summary> <note>No completion record was found for it in the previous session. It may have been stopped (via the UI, Monitor timeout, or agent teardown — these leave no transcript marker), or it may have been running when the previous Claude Code process exited. Check the output file for partial results before assuming it completed.</note> </task-notification> **Person:** I opened the studio and it looks right. I played the sign-off path in Simulate and it makes sense. Let's leave a real incident for later. **Agent:** Good, the factory is ready, and we'll leave the first real incident for later. **What you have** - **Factory `post-incident-review`**: timeline (with severity) → analysis → second-reader review → on-call lead sign-off → publish to Confluence under Incidents. - **Stops for a person:** the on-call lead's sign-off, confirming a duplicate incident, and abandoning a review. - **Saved paths that `validate` checks on every change:** - `never-published-without-sign-off`, your hard rule. - `timeline-to-published`, the normal path. - `sign-off-feedback`, where the lead sends it back. - **Tracker `incidents`**: built in, ticket ids start with `inc-`. The studio server has stopped now that the earlier session ended. When you want the page again, run `swamp model method run studio serve` and open the URL it prints. The new files are under `models/` and haven't been committed yet. **Possible next steps:** - **Start the first review when an incident comes in:** just say "start a review for <incident>". I'll file the ticket and drive it to the on-call lead's sign-off. - **Add fields to the write-up:** for example, detection time, time to recover, or links to follow-up tickets. - **Commit the factory** so the rest of the team can use it. Want me to do any of these now? </details> ## Eval cases for the walkthrough (for #2912) Not added here; #2912 builds the suite. Each case loads only the stagecraft skill. **1. first-factory-non-software** - Scaffold: `swamp init --tool none`, `swamp extension source add <stagecraft checkout from EVAL_STAGECRAFT_DIR>`. - Prompt: "I want to set up a factory for our post-incident reviews." The history file supplies the person's answers: Confluence, a SEV1–SEV3 severity, the on-call lead signs off, never published without sign-off, built-in tracker. - Graders: - `tool_used` Read with `input_match: getting-started\.md`. - `tool_used` Bash with `input_match: method run .* validate`, `min: 1`. - `tool_used` Bash with `input_match: studio serve`. - `file_exists` `models/@swamp/stagecraft/factory/*.yaml`. - `regex` on the trace for `saved scenario\(s\) passed`. - `llm` rubric: - shows the checklist; - asks its questions in one message, in plain words, without making the person learn factory terms; - checks each step before moving on; - writes the person's must-never rule as a saved scenario; - ends with next steps. **2. existing-factory-hands-off** - Scaffold: as above, plus a factory created from `minimal`. - Prompt: "set up a factory". - Graders: - `regex` on `last_message`: it says a factory exists and asks whether to change it, make another or drive work. - `tool_used` Bash with `input_match: model create @swamp/stagecraft/factory`, `max: 0`. **Trigger phrases** - Should trigger: "set up a factory", "my first factory", "get started with stagecraft", "build a factory for our review process", "a process where agents do the work and a person approves each stage". - Should not trigger: - "get started with swamp" (swamp-getting-started); - "create a workflow that runs nightly" (swamp workflows); - "automate this nightly job"; - "triage issue 42" (issue-lifecycle); - "run the software-factory". 🤖 Generated with [Claude Code](https://claude.com/claude-code)

seth added 1 commit

2026-10-02 02:56:52 +00:00

feat(stagecraft): a getting-started walkthrough for a first factory, and incident-review, content-review and openapi-models examples (swamp-club #2931 )

CI / Review Integrity (pull_request) Successful in 55s

Details

CI / Validate Attestation (pull_request) Successful in 55s

Details

2dcf451f3f

references/getting-started.md walks a newcomer from their goal, in their
words, to a validated factory they have seen in the studio and watched a
saved scenario walk, with a Verify at each state. It links to authoring.md's
states for the work rather than repeating them. SKILL.md and authoring.md
send a repo's first factory there; SKILL.md's description gains name-neutral
factory triggers and an explicit not-for clause.

Three new examples beyond a software change: incident-review (timeline to
a signed-off, published review), content-review (draft to an approved,
published piece) and openapi-models (an API's OpenAPI spec, or a slice of
it, to a swamp extension, with an optional live try before release). Each
validates with no warnings and runs its saved scenarios, and the example,
tracker, factories and studio tests cover them. skill_test checks every link
in the walkthrough names a heading that exists.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

seth merged commit 5051735f77 into main

2026-10-02 02:58:41 +00:00

seth deleted branch cue/2931-gatorwalk-factory-skill

2026-10-02 02:58:41 +00:00

seth referenced this pull request from a commit

2026-10-02 02:58:43 +00:00

feat(stagecraft): a getting-started walkthrough for a first factory, and incident-review, content-review and openapi-models examples (swamp-club #2931) (#432)