Start a Project in Conversation
Tell Heimdall about a client and what they need; it creates the client and the project, writes the record as drafts, asks only for what it cannot infer, and convenes the council on the result inside the conversation.
By the end of this page you will know how a project goes from a paragraph in the Heimdall panel to a client, a project and a planning record you can read on every page, what Heimdall writes in which order, what it asks you, how the council joins in, and how to change or undo any of it.
The intake wizard still exists for a person who prefers forms. The conversation is the shorter road: a business analyst gives the minimum, Heimdall expands it, and every record it writes is a draft through the same actions the pages run, with a version you can put back.
Before you begin
| To | You need |
|---|---|
| Create the client and the project | client:create and project:create on the team; project managers and analysts have them by default, a client guest never does. |
| Let Heimdall write the record under it | The create permission of each family on the project (component:create, epic:create, requirement:create and so on), which your project role carries. |
| Let the council sit | ai:use, the project's assists on, and room in the team's monthly AI budget within the council's share. |
Heimdall holds exactly the permissions you hold. A record it may not write is refused by the same rule that would refuse you, and it tells you so rather than looking for another way.
Tell Heimdall about the client
Open the panel with Ask Heimdall or Ctrl+/ from any page, or press Start a new project
from a brief on its start screen, and write what you know in your own words:
"We need a project for a laundry shop called Super Clean Laundry: an informational website with online order placement, tracking, payment and appointment scheduling."
That is enough. Heimdall looks the client up on the registry and creates it when it is new,
creates the project with a key suggested from its name (SCL here; say another in the same
message if you want one) and your paragraph as its description, and tells you both are in, with a
card for each under its answer and Open to their pages. The project selector shows the new
project at once.
What it writes, in order
Heimdall then writes the record under the project the way an analyst would, in groups, saying what it wrote after each group with the references it gave them:
- Components and environments on the house stack: a Laravel web app, a Laravel API when one is needed, a mobile app only when the brief says so, and development, staging, UAT and production environments.
- Stakeholders and personas: the owner, the shop manager and the client's product owner as seats with the approval flags the brief implies; the busy parent, the student and the driver as the people the product serves.
- Epics for the bodies of work the client recognises, and under each the stories with their acceptance criteria, a negative criterion among them.
- Functional and non-functional requirements, each with a measure where it can be measured, and the business rules the brief states or implies, each with a worked example.
- The use cases with their main, alternate and exception flows, the glossary of the client's words, the data entities with their fields, the risks it sees and the decisions it took on the stack.
Every record arrives as a draft: an epic in draft, a story in the backlog, a requirement in draft, a glossary term in draft. Nothing reaches in review or approved except through the approvals, and nothing is hidden from you: each group shows as cards under the answer, and every page shows the same records the moment they are written.
Progressive, not one-shot
Heimdall writes group by group and keeps talking. Answer a question, correct a name or add a detail between groups and it changes what it wrote, through the same update tools, before it goes on; nothing waits for a final form.
What it asks you
Heimdall asks only for what it cannot infer from the brief, one or two questions at a time, and never holds the scaffold back for them: the client's contact and country, the target launch, the budget in hours, whether a mobile app is wanted, who on your team leads the project. Answer in the thread and it fills the fields in; leave a question unanswered and the record stays as it is.
Say when it is wrong. "There is no mobile app" deletes the component after a confirmation card; "the owner is Nadeesha Perera, she signs off requirements" writes the stakeholder with the flag; "call the key SCL2" renames the key while nothing is numbered under the project yet.
The council sits on the scaffold
When the scaffold is in, the council is convened on the project itself the moment Heimdall's answer lands, without anyone asking: the intake moment, with Odin, Thor, Loki, Týr, Frigg and Baldur reading the whole record through their lenses. (A scaffold is a project created in the conversation with at least one record written under it; a turn that only created the project waits for the record.) The sitting appears in the conversation as it happens: each voice researches the ground and says what it found, reads the scaffold and leaves findings, answers the other voices and refines the plan Heimdall drafts; Heimdall closes with the plan the council agreed and the findings ranked: what the drafts get wrong, what a project of this kind needs that nobody said yet, what the client will be held to. Each finding carries Accept and Dismiss; accepting one that drafts a record writes it as a draft, dismissing one is remembered so no voice raises it again. The same sitting is on the Council tab of the panel.
The council spends from the team's AI budget within the council's share of it; the card says what the sitting cost. A project with no room left, or one whose settings seat no voice on the intake moment, gets no sitting and the scaffold stands without it; ask Heimdall for the council later and it convenes one by hand.
A long scaffold is more steps than a question: Heimdall may reach the limit of one run with calls still queued. It carries on by itself, up to twice, picking up the queued calls where the run stopped; the timeline shows the calls the first run left behind with the reason, and the same calls run in the continuation.
Research and a longer brief
The research sweep starts by itself the moment the scaffold lands: Heimdall reads the web for what products of this kind are expected to do, the regulations they meet and the integrations clients ask for, filing notes and suggestions on the review queue. Hand it a long document and it starts a brief import instead of typing the record out: the drafts land on the review queue for you to accept, edit, merge or reject, and Heimdall reports when the reading is ready. On your word it decides a row or a council finding for you, after a confirmation card.
Change and undo
Every record Heimdall writes is yours: edit it on its page, ask Heimdall to change it, or put an earlier version back from its history, exactly as for a record a person wrote. The activity log and every version carry Heimdall's name on your behalf, so who wrote what is never in doubt. A record you did not want is deleted after a confirmation card; a project you did not want is archived or deleted from its own settings page.
From the MCP
The same tools serve an agent connected over MCP, under its token's abilities.
create_project
The project with a key suggested from its name; the door a conversation opens a project through.
create_client
The client on the registry, looked up first so it is created once.
create_epic
An epic as a draft, with the stories under it from create_work_item.
convene_council
The council on the project itself once the scaffold is in.
Permissions
| Action | Permission |
|---|---|
| Create the client | client:create |
| Create the project | project:create |
| Write each family of record under it | That family's create permission on the project, through your project role |
| Change or delete what Heimdall wrote | That family's update or delete permission; deletes confirm first |
| Convene the council and run research | ai:use on a project whose assists are on |
Questions
Can Heimdall approve what it wrote? No. Approvals are decided by the people the project's policy names, on the approval bar or in the inbox, and never by Heimdall or an agent. It can submit a record for review when you ask.
What if two people start the same project? A name or a key the team already uses is refused, and Heimdall says so and reuses the project that exists.
Does it spend the AI budget? The conversation does, as every Heimdall turn does; the council sitting and the research sweep spend within their shares. The record itself costs nothing to write.
Related
- The panel — the thread, the cards and the confirmation cards
- The council — the voices and what a sitting costs
- Brief import — a long document into the review queue
- Intake wizard — the same intake as forms
- Revisions and versions — putting a version back
How is this guide?
Last updated on
The Panel
Heimdall sheet beside every page, end to end: opening it, the context chip and the eye, the start screen, threads, the composer, the model tiers and the review switch, the work timeline and the streamed answer, buttons and follow-ups, confirmation cards and the budget line.
Inline assists
Ask Heimdall beside any long field of an epic, story, requirement, rule, use case, RAID item, decision or dictionary entry: draft it, improve it, shorten it, make it testable or rewrite it as Given, When, Then, then take the draft or drop it.