Storyline

The team discussions that actually matter.

For teams building software products

Not a code review. Storyline is about the human creative input and the discussions that come with good product development.

We set the stage for the most meaningful conversations — with every previous decision as context, even from years ago. So you don't waste time building the wrong features or re-litigating settled questions. Good products arise when creative minds challenge each other.

Join a review

Got a code? Enter it to jump right in.

One skill, two ways to review

Install the Storyline skill. It maintains your specs and runs reviews — from zero-setup solo reviews to full team collaboration.

Storyline Skill

Free & open source

Teaches your coding agent to maintain structured feature specs and run guided reviews. Works with Cursor, Claude Code, Copilot, Codex, and any agent that supports skills.

npx skills add bjornno/skills --skill storyline
View on GitHub
1

In your agent

Zero setup

Say "start review" in Cursor, Claude Code, or any agent. The skill reads your specs and diff, finds the risk, and walks you through the discussion right in the conversation. Reviews saved as markdown.

No server, no API key
Uses your agent's LLM
Great for solo or screen-share
2

Hosted

Open beta

Shareable review sessions with real-time collaboration, GitHub PR integration, and persistent history. Create from CLI, share a link — teammates join without an account.

Team collaboration with shareable URLs
GitHub Action for automatic PR reviews

Why confrontation-first?

Most reviews don't find real problems

Teams read the context, say "looks good," and move on. The hard question never gets asked. Storyline identifies it immediately and puts it in front of you — before any discussion starts.

Previous decisions as context

Every review includes past discussions and decisions — even from years ago. When someone asks "why is it like this?", the answer is already there. No more re-litigating settled questions or losing institutional knowledge when people leave.

13 risk angles

7 product angles (intent drift, scope creep, contradictions...) and 6 architecture angles (API design, security gaps, tech debt...). Storyline picks the one that matters most for this specific change.

Uncomfortable response options

No "looks good" button. Each step forces a real choice — options are specific to the question and designed to surface disagreement, not smooth it over.

Outcomes capture dissent

Storyline synthesizes what the team actually decided — including unresolved questions, minority positions, and concrete next steps. No more "approved" with nothing actionable.

How it works

1

Install the skill

One command. Your agent starts maintaining specs alongside your code — who the feature is for, what counts as done, what's in scope. Reads specs before coding, updates them when things change.

2

Say "start review"

The agent reads your specs, code diff, and previous decisions. It finds the single most important risk and confronts you with it — Yes, No, or Unsure. Then walks you through structured discussion steps.

3

Decide and record

The outcome is saved as markdown in your repo — decisions, dissent, open questions. Future reviews include these as context. Need team collaboration? Create a hosted session with one command.

Automatic reviews on every PR

Add a GitHub Action and every pull request gets evaluated automatically. If Storyline finds a product or architecture risk worth discussing, it posts a review link directly on the PR.

PR opened

Storyline reads the full branch diff and specs, checks for product and architecture risks

Risk found

Review session created automatically, link posted as a PR comment

Trivial change

Skipped silently — no noise on typo fixes, formatting, or dependency bumps

npx storyline-review setup-github

One command. Writes the workflow file and helps you set the secret. Duplicate reviews for the same branch are detected and reused automatically. Learn more

Try it yourself

Click through a real review. The product review catches scope creep in a notification feature. The architecture review challenges over-engineering.

Scope creep Notification Preferences

The spec says "let users mute noisy notifications." The last three commits add a full notification center with categories, scheduling, and digest emails. The original user problem — "I get too many emails" — is buried under a system nobody asked for.

Are you comfortable that users actually need a notification center, or did the team just find it more interesting to build than a mute button?

This is what reviewers see first — before any context or evidence.

Try hosted reviews

Log in with GitHub and start reviewing. Open beta with a daily usage limit per user to keep costs manageable.

Log in with GitHub

We only use OAuth for authentication — we don't access your repositories.

By logging in you accept the terms of use.

Specs live in your repo. Reviews run in your agent. Your code stays yours.

Terms of use