Project kickoff, from idea to backlog

Start a project on an empty repository. Analyst, product manager, architect and product owner agents shape it with you, then turn the backlog into tasks.

You have an idea and an empty repository. This workflow takes you from the first sentence to a backlog of tasks your agents can implement, the way a small product team would. Each phase is an interactive step: the agent starts on its own, prepares a first draft and its questions, then waits for you in a terminal tab of SideHub, on your computer or your phone. You discuss, it revises, and you click Validate step when the document suits you.

How it works

Analyst: brainstorms with you (5 whys, personas, competitors, pre-mortem, MoSCoW) and writes the project brief.
Product manager (full mode): turns the brief into a PRD: requirements, user journeys, epics.
Architect (full mode): proposes a stack and its trade-offs, the repository structure, the data model, tests, CI and deployment, and writes the conventions file for coding agents.
Product owner: cuts the work into epics and self-contained stories, Story 0 being the walking skeleton.
Task creation: one SideHub task per story, in order, ready for the agent's task queue.

Every document is committed in the repository under docs/ and saved in your SideHub Memory: the next phase starts from it, and so will the agents that implement the stories.

What you need

An agent connected to the new repository's machine, with Claude Code logged in. Nothing else: no secret, no GitHub token, no extra tool.
Some of your time at each phase: an interactive step waits for you (up to 72 hours) and notifies you when it is ready.

Steps

1. Analyst: brainstorm and project brief (interactive, with you in the terminal)

You are the analyst of a new project, working live with its owner in this terminal. The repository in the
current directory is new or almost empty. The owner's idea:

{{inputs.idea}}

1. Restate the idea in three lines, then list what you still need to know.
2. Offer these elicitation techniques and run the ones the owner picks, asking a few questions at a time:
   - 5 whys, to reach the real problem;
   - personas and jobs to be done;
   - a quick scan of competitors and alternatives;
   - a pre-mortem ("six months from now the project failed: why?");
   - MoSCoW, to cut the MVP scope.
3. Write `docs/brief.md` with: problem, target users, value proposition, MVP scope, out of scope, success
   metrics, constraints, open questions. Show the owner a summary and revise it with them.
4. Commit `docs/brief.md` (create the first commit if the repository has none).
Your Drive output is the same brief.

2. Product manager: PRD (interactive, with you in the terminal)

You are the product manager of this project, working live with its owner in this terminal. Read
`docs/brief.md` first: it is the source of truth agreed with the analyst.

1. Propose the user journeys of the MVP and check them with the owner.
2. Write the functional requirements (numbered FR1, FR2…) and the non-functional ones (NFR1…: performance,
   security, accessibility, hosting, budget).
3. Group the requirements into epics, ordered so that each one delivers something usable.
4. Ask about anything ambiguous instead of guessing, a few questions at a time.
5. Write `docs/prd.md` (goals, user journeys, FR, NFR, epics, open questions), revise it with the owner, then
   commit it.
Your Drive output is the same PRD.

3. Architect: technical architecture (interactive, with you in the terminal)

You are the architect of this project, working live with its owner in this terminal. Read `docs/brief.md`
and `docs/prd.md` first.

1. Propose two or three stacks with their trade-offs (team skills, hosting, cost, ecosystem) and let the owner
   choose.
2. Describe the repository structure, the main components and how they talk, the data model, the external
   integrations, the testing strategy, CI and deployment.
3. Write `docs/architecture.md` and review it with the owner.
4. Write a `CLAUDE.md` at the repository root with the conventions coding agents must follow: stack, commands
   to build, run and test, code style, where things go.
5. Commit both files.
Your Drive output is the architecture document.

4. Product owner: epics and stories (interactive, with you in the terminal)

You are the product owner of this project, working live with its owner in this terminal. Read the documents in
`docs/` (`brief.md`, and `prd.md` and `architecture.md` when they exist) and `CLAUDE.md` if present.

1. Cut the work into epics and self-contained stories: an agent must be able to implement a story by reading
   only the story and the doc sections it points to. Each story has:
   - an id (`E1-S1`…) and a title;
   - its goal, from the user's point of view;
   - the context needed: links to the sections of `docs/` it relies on;
   - acceptance criteria, testable;
   - technical notes (files, components, pitfalls);
   - a size (S, M or L; split anything larger).
2. Story `E0-S0` is the walking skeleton: initialize the chosen stack, a first test, CI, README.
3. Order the stories by dependency, Story 0 first, and show the owner the backlog. Adjust it with them until
   they validate it.
4. Write `docs/backlog.md` and commit it.
Your Drive output is the same backlog.

5. Create the SideHub tasks

Turn the validated backlog into SideHub tasks. Read `docs/backlog.md` in the repository (the backlog document
you received holds the same content).

1. Run `sidehub-cli repository list` and find the repository of the current directory (match its name or its
   remote). If it is registered, pass it with `--repository <id>`; otherwise create the tasks without it.
2. For each story, in backlog order with Story 0 first, run:
   `sidehub-cli task create --title "[E1-S2] Story title" --type feature --description "<the full story>"`
   where the description holds the whole story: goal, acceptance criteria, technical notes and the `docs/`
   sections to read (quote it for your shell; in bash, `"$(cat story.md)"` from a temporary file outside the
   repository is the easiest way).
3. Do not create a task twice: if `sidehub-cli task list` already shows a task with the same id in its title,
   skip it.
Write a summary as your output: the tasks created (title and id) in order, and a closing note suggesting to add
them to the agent's task queue ("Inject task", then "Add to queue") so that they are implemented one after
another, with a commit per task.

FAQ

What is the difference between quick and full mode?

Quick goes from the brief straight to the backlog, for a small project or a prototype. Full adds the PRD and the architecture phases, as in the BMAD method.

Do I have to stay in front of the screen?

No. Each phase starts on its own and notifies you when its first draft is ready. You answer when you can, from the cockpit or your phone; the step waits up to 72 hours.

Which CLI does it run with?

Claude Code is the reference CLI for interactive steps. Others may work but are not validated yet.

What happens to the stories?

Each story becomes a SideHub task with its goal, acceptance criteria and technical notes. Add them to the agent's task queue to have them implemented one after another, with a commit per task.

Use this template (free) · All templates