RigelProductRigel Plan
Rigel Plan
Requirement Brief (requirements drafting) turns a ticket into a requirement everyone can sign off. Solution Course (solution design) turns that into a design that knows which services it touches.
Chat
Members should be able to pause a subscription for up to three months.
Can every member pause, or only monthly plans? I've added that as an open question, and drafted the first two sections.
The critic sent back one line for being about the build, not the outcome. I rewrote it in business terms.
Rigel reads the chart
Design the solution →services · subscriptions, billing-worker, notifications
find_consumers · billing-worker, in another repo, subscribes to subscription.updated Beta
code graph · callers of issueInvoice in billing-worker
assembly · Membership constellation data flows
| Task | What it does | Repo | Size |
|---|---|---|---|
| T1 | Store a pause window per subscription | membership | M |
| T2 | Announce pause and resume as events | membership | S · after T1 |
| T3 | Skip invoices inside a pause window | billing | M · after T2 |
| T4 | Send a resume reminder | membership | S · after T2 |
“notifications already sends resume reminders” Grounding critic · not supported by the chart · advisory
1A product owner pastes a brief. Rigel drafts the requirement one turn at a time.
Requirement Brief
For product owners, BAs and PMs.
Brief or Jira issue in · requirement out
Paste a brief or pull in a Jira issue, screenshots and PDFs included. Rigel works with you one turn at a time, in a split view: chat on the left, the live document on the right.
Every section write passes through a business-language critic. When it rejects a line, Rigel sees the offending words and a rephrasing, and retries.
If the critic is unavailable, your session carries on. Each drafting session runs under a USD budget cap.
Scheduling
Names a mechanism (a scheduled job, a table) instead of the outcome a member sees.
Storage
Prescribes a column and a data type. The requirement only needs the fact to be kept.
Interfaces
Specifies an endpoint and an event. That belongs in the solution design.
Solution Course
For solution architects and tech leads.
Requirement in · design and tasks out
Start from a finished requirement, a Jira issue or a paste. Rigel drafts a seven-section solution design and a task breakdown, reading the chart while it writes.
find_consumers before it proposes a contract change.Services and their deep-analysis docs, APIs and events, the code graph, semantic search, cross-repo consumers and constellation assembly docs: the same chart your coding agents query over Rigel MCP.
From a published requirement, one click: Design the solution →
Idea to design
She pastes a brief into Requirement Brief. The critic keeps it about outcomes. She publishes v1.
One click from the published requirement. Solution Course finds the three services involved and drafts a design with tasks.
The grounding critic flags one claim the chart doesn't support. The architect fixes it, publishes and shares the link.
Illustration of a typical flow.
What's next
Agents that pick up the tasks in a published solution design and open governed pull requests, in dependency order. Not available today: Rigel Plan currently ends at a grounded task breakdown.
Rigel Map: the chart of services, contracts and consumers that Plan reads.
What ships today →Shipped, Beta and Coming soon, feature by feature.
Book a technical walkthrough →We'll draft a requirement and a design on a demo estate with you.
Mechanism: which parts are deterministic and which use a model →
Chart your repos, then plan from what's really there.