← Back to my options
End-to-end showcase

One idea, run through the real gate, start to finish.

Not a demo written to look good. ShipLog is the literal output of one real pass through Keel and Spec Kit — a hypothesis, four disclosed synthetic interview records, a gate that actually blocked and then passed, a shipped app verified against live GitHub data, and an audit that scored the drift. Here's the whole trail.

keel-gate: brief OK keel.audit: 0 critical findings 6/6 assumptions traced into shipped code branch: feature/guided-validation-workflow
The problem statement

A solo founder's Friday chore

/speckit.keel.guide "ShipLog: a founder enters..."detected: no keel/ yet → captured the hypothesis, derived assumptions, wrote the interview guide and evidence-plan.md

Example shown using Spec Kit's dotted command format. Other agents may use dashes, $, or a named skill. See invocation formats.

The idea: ShipLog — a founder enters their public GitHub username and gets a draft weekly "build in public" update, generated from real commits, merged PRs, and releases over the last 7 days. They review and edit it before anything goes anywhere. It never posts on their behalf.

The belief: solo founders who build in public lose real time every week doing the same manual chore — reconstructing what they actually shipped from their own commit history, then writing it up. The reconstruction step, not the writing, is what a tool could remove — as long as the founder still controls what comes out the other end.

Why now, honestly: mostly founder intuition, not evidence yet — the hypothesis says so explicitly. GitHub's public API makes the data reachable without auth, and "build in public" is a common habit, but neither confirms the chore is painful enough, or that founders would trust a machine-drafted first pass. That's what discovery exists to find out before any of it becomes a spec.

The interviews

Four conversations, two roles, one real contradiction

Keel derived six assumptions the idea depends on, then a non-leading interview guide. Four interviews later, the gate had what it needed — and one belief didn't survive contact with the evidence.

/speckit.keel.guide × 4— one paste per interview, each detected as evidence collection phase and logged against the relevant assumptions
DISCLOSED Every interview below is synthetic — written to exercise Keel's gate for this run, not collected from real people. commands/add-evidence.md is explicit that the command "processes one real interview, it does not simulate one" — this run deliberately does the thing it says not to, to test the machinery, and says so in keel/decisions.md. Nothing here is evidence real founders want this.
indie_founder

E-001 — Founder-1

Walk me through the last time you wrote a public progress update.
"It usually takes me 30–40 minutes because I have to go back through my own commits and PRs to remember what actually happened that week. I scroll my repo's commit list and closed PRs — it's the only accurate record I have."
→ A-001supports — observed recurring behavior, not stated preference
indie_founder

E-002 — Founder-2

Would you ever let a summary of your work go out without reading it first?
"Never. I wouldn't let anything with my name on it go out unread — even something a cofounder wrote. And commit messages don't say why I rebuilt the whole billing flow — that's the actual story. A summary that just lists commits reads like a changelog, not an update."
→ A-002supports strongly — a stated principle, not a hedge
→ A-003contradicts — raw activity described as accurate but hollow
buildinpublic_reader

E-003 — Reader-1

What makes you actually read someone's weekly update versus skip it?
"If it's just a list of commits I skip it — I follow people for the story, what they struggled with, what they decided. I do read the ones that feel like a real person made a call about something."
→ A-003contradicts — second independent role, same direction
→ A-004supports, conditionally — engagement tied to narrative, not speed
indie_founder

E-004 — Founder-3

Have you connected tools to your GitHub before — what did you check first?
"I'd 100% read a draft before it went anywhere — my update goes to like 2,000 people, that's non-negotiable. I've connected read-only integrations before, didn't think twice about public-repo stuff. I'd be more careful about write access or private repos."
→ A-002supports — third independent founder, stakes-based reasoning
→ A-005supports, scope-matched to public read-only access
The gate

The actual gate, run against the disclosed test evidence

/speckit.keel.guidedetected: evidence at threshold → ran check inline, five-option decision menu, recommended proceed
IDStatementRiskStatus
A-001Founders spend real, recurring time each week reconstructing shipped work into a shareable update.highsupported
A-002A machine-drafted update is only usable if the founder can review and edit it first — not if it posts on their behalf.highsupported
A-003Public GitHub activity alone carries enough signal for a genuinely useful first draft.mediumcontradicted
A-004Founders would keep using this weekly, not try it once and drop it.mediumsupported
A-005Founders are comfortable with public, read-only, unauthenticated GitHub access.lowopen
A-006A founder-editable context field is necessary — raw activity alone reads as a changelog.mediumsupported

Swipe to see all columns →

What check ran internally — guide calls the same script, it's never a separate command you type:

$ bash .specify/extensions/keel/scripts/bash/keel-gate.sh brief evidence files: 4 distinct participant roles: 2 unvalidated high-risk: 0 contradictions: 1 NOTE: superseded (contradicted and replaced) recorded in keel/decisions.md for: A-003 (excluded from the count above, still surfaced by keel.audit). WARNING: 1 open contradiction(s). These must appear in the brief's unvalidated risks. keel-gate: brief OK

Two independent sources (E-002, E-003) contradicted A-003 — "GitHub activity alone carries enough signal." Rather than stretch its wording, the belief was replaced: superseded: A-003 in keel/decisions.md, pointing to a new assumption, A-006. The context field this produced wasn't added later as polish — it's in the spec as a load-bearing requirement, traced straight back to this contradiction.

The artifacts

Brief, constitution, spec — one traceable chain

/speckit.keel.guidedetected: check passed → wrote brief.md and constitution-input.md

What the evidence ruled out: a draft based on raw GitHub activity alone, presented as sufficient. Two independent sources called that output a changelog, not an update.

What shipped instead: activity grouped by repo, paired with a founder-editable "why" field woven into the draft, and a review step that's structurally mandatory — three independent founders were unconditional on that point.

MarkerRequirementVerdict at audit
A-001Fetch + present 7-day activity, grouped by repo, in an editable draftOK
A-002Mandatory review; exactly 2 output actions; zero auto-transmit pathsOK — stronger than required
A-003Raw activity never presented alone as finished (superseded by A-006)OK
A-005Public, read-only, unauthenticated GitHub access onlyOK
A-006Always-visible context field, woven into the draft, not decorativeOK

Checked by grep against the running code, not by matching filenames to requirement text — full table in keel/audit-report.md.

The build

Constitution to converge, unmodified Spec Kit

Keel only surrounds Spec Kit's own pipeline — it never sits inside the build.

constitution specify plan tasks implement !converge — found 1 keel.audit
/speckit.keel.guidedetected: build converged → ran audit → traced 6/6 requirements, 1 finding
!

What converge actually caught

Copy and Export were reachable with an empty draft — before the first Generate, or after a failed lookup, both buttons were clickable and would silently act on nothing. Not a security issue, but a real crack in "mandatory review" — there was nothing to review. Fixed as task T035: both buttons now stay disabled until the draft has content. This is the pipeline's own safety net working, not a bug found from outside it.

The outcome

Proof it runs against real data

Driven with a real browser (headless Chromium) against the app actually running on localhost — real username, real GitHub API, zero console errors, zero mocks.

ShipLog before generating — username field, context field, empty draft area
Idle — before Generate
ShipLog with a real draft generated for a live GitHub username, context field being filled in
Generated for @sindresorhus in 9.1s, 42 live GitHub API calls (2 pagination + 40 enrichment, capped by design), context being woven in live
ShipLog export confirmation after downloading the markdown file
Export confirmed — a real .md file downloaded, named shiplog-update-2026-08-15.md

Run it yourself

No build step, no install, no auth token. Clone it, or read the full evidence trail in the repo.

git clone https://github.com/keeldiscovery/shiplog.git
cd shiplog/app && python3 -m http.server 8000

Ready to use Keel on your idea?