Start here
What is Alara Code
The product in one read: from an idea to a reviewed SDLC document set and a delivery board.
Alara Code turns an idea or a Request for Proposal into a complete, reviewed set of software delivery documents — scope, requirements, design, test plan, compliance, traceability and a client proposal — and then into epics and tickets on a delivery board. An AI agent drafts every document; a person reads and approves each one before the next step can start.
What Alara Code does
You describe what you want to build, or upload an RFP you already have. Alara Code then walks the project through a fixed sequence of steps. Each step asks the project's Alara agent to write one document, checks what comes back, and hands it to you for review. Nothing moves forward until someone approves it.
The result is a document set that hangs together: every requirement has an id, every design component names the requirements it serves, every test case names the requirements it proves, and every ticket on the board traces back to a design component.
Alara Code produces documents and tickets. It does not write application code, host an editor, or deploy anything.
Who it is for
- Pre-sales and solution teams who need a scope, a technical proposal and an effort picture from a client brief, quickly and consistently.
- Business analysts and product owners who want requirements written to a recognised structure (IEEE 830 for the SRS, IEEE 829 for the test plan) and kept traceable.
- Architects and tech leads who want a design specification with diagrams, decisions and implementation units they can review before any build starts.
- Delivery managers who want the approved design broken down into epics and tickets without re-typing it.
Everyone works inside an organization. Which projects you can open, and what you can do in them (run a step, approve, stop a run), depends on your organization role.
The document set
| Step | Command | What you get |
|---|---|---|
| RFP | /rfp | The Request for Proposal — uploaded by you, or drafted by the agent from the project chat |
| Scope | /scope | Objectives, in-scope and out-of-scope items, stakeholders, assumptions, constraints, risks and deliverables |
| SRS | /srs | The Software Requirements Specification: requirements, compliance flags, features, use cases and analysis models |
| SDS | /sds | The Software Design Specification: architecture, design components, decisions, data and interface design, with diagrams |
| STS | /sts | The Software Test Specification: test cases mapped to requirements, and the test plan around them |
| Tasks | /tasks | Epics and tickets for every design component — the source of the delivery board |
| Compliance | /compliance | Requirements checked against regulatory frameworks, with gaps flagged |
| Traceability | /traceability | The matrix from requirement to design component and test case |
| Proposal | /proposal | The client-facing technical proposal drawn from the approved documents |
Every document is Markdown, with diagrams drawn from Mermaid. You read it in the app and export it as PDF, Word, Excel, HTML or Markdown.
The human in the loop
Alara Code is built around one rule: the agent drafts, a person decides.
- Every reviewed document stops at a gate. RFP (when the agent drafts it), Scope, SRS, SDS, STS and Proposal each finish as Awaiting your review. You read the draft beside the conversation and choose Approve or Request changes.
- Approval unlocks the next step.
/scopeneeds an approved RFP,/srsneeds an approved scope,/sdsan approved SRS,/stsan approved SDS, and/proposalan approved STS. Locked steps show which approval they are waiting for. - Changes stay targeted. Request changes lists what to fix, one change per line; only that document is regenerated, and it comes back for review.
- Upstream changes are visible. When you re-run a document that later documents were built on, the later ones are marked so you know to re-run them.
- The agent never acts on its own. It cannot start, approve or edit a step. People press the buttons.
Tasks, Compliance and Traceability have no review gate of their own: they unlock once the document they read has been produced (the STS for Tasks and Compliance, the SDS for Traceability) and are complete as soon as they finish.
From idea to board
An uploaded RFP counts as approved by the person who uploaded it, so /scope unlocks straight away. A drafted RFP goes through review like any other document.
How it works, briefly
Each project is bound to one Alara reasoning agent that your organization has shared with Alara Code. Every step runs on that agent, as the person who started the step. The agent carries the Alara Code skills — one instruction file per kind of document — and each step names the skill it needs.
When the agent answers, Alara Code checks the document before you ever see it: the required section headings, the ids the step owns, the number of diagrams, and the size. If a check fails, the problem goes back to the agent as a correction, up to three attempts. Alara Code then adds a title block, its own catalogue tables and a version history, and saves the result as a new draft.
While a step runs you watch its progress live, and you can keep talking to the agent in the same conversation.
Where to go next
- Getting started — your first project, end to end.
- Key concepts — the words the rest of these docs use.
- Set up the project agent — the one-time setup every project needs before a step can run.
- How the pipeline works — the steps, the gates and what each document contains.
- Troubleshooting — what an error means and how to fix it.