Getting started
The fastest way to understand AIDEN is to complete one full loop:
- Create or import a project.
- Create a story.
- Turn that story into a spec.
- Start work in the story workspace.
- Review the result and move the board forward.
If you do that once, the rest of the product becomes much more intuitive.
Step 1 — Create a project
Start by creating a project from one of three common paths:
- New project — for something you want to start from scratch
- From repository — for an existing GitHub repo
- From folder — for a codebase already on your machine
A project is the top-level home for your stories, context, chats, and Git-aware work.
Step 2 — Understand the board
Once the project exists, go to the board.
The board is where AIDEN stops feeling like a generic AI tool and starts feeling like an operating system for real work.
Typical states include:
- Backlog
- Plan
- In Progress
- Review
- Done
Use the board to decide what needs clarification, what is active now, and what is truly complete.
Step 3 — Create a strong first story
A story is the main unit of work in AIDEN.
A good first story is:
- specific
- meaningful
- small enough to finish
- clear enough to review later
A weak story is broad and vague. A strong story gives AIDEN something concrete to plan and execute.
Step 4 — Plan before you build
This is one of the most important habits in AIDEN.
Do not jump straight into implementation. Move the story into planning and turn it into a real spec.
A good spec usually clarifies:
- what you are building
- why it matters
- what is in scope
- what is out of scope
- what success looks like
- what edge cases matter
The clearer the target, the better the execution.
Step 5 — Work inside the story workspace
Once the story is ready, open the story workspace.
This is where execution happens. Depending on your setup, it can include:
- the story spec
- story chat
- browser
- terminal
- notes
- files
- Git context
This is one of the most important product surfaces because it keeps planning and execution in the same environment.
Step 6 — Use agents when they actually help
You do not need a swarm on day one.
A good rule is:
- use the main story chat for focused implementation
- use a custom agent when a specialist role makes sense
- keep delegation deliberate instead of adding coordination noise too early
The goal is not more motion. The goal is better work.
Step 7 — Review honestly
Before a story is done, compare the result against the spec.
Ask:
- Did we meet the acceptance criteria?
- What still feels risky?
- What should be checked manually?
- Is the story actually complete?
Then move it to review, and only mark it done when it really deserves it.
Common beginner mistakes
Treating AIDEN like a prompt bucket
If you ignore the project, story, and spec structure, you lose most of the value.
Writing stories that are too broad
Big vague stories create messy outputs.
Skipping planning
Fast at first, expensive later.
Adding agent complexity too early
Extra coordination only helps when each worker owns a clear piece.