Project Setup and First Run
This guide is about setting up context: how to "tell" the agent about your project so it can propose the right actions instead of guessing. Everything happens in the conversation — there is no separate admin panel.
What happens on the first run
If the agent does not know the context, it starts with a short interview — this is called awareness. Three tools:
| Command | What it does | Result |
|---|---|---|
/environment | A short interview on how work is organized | Project profile: scope, methodology, industry, and the trackers and spaces that belong to the project |
/documents | A registry of project documents: what exists, what is missing, what does not apply | A document table with a note on what each one covers |
/path | An advisor: where the project is in its lifecycle and what to do next | The stage + up to three concrete suggestions |
Step 1. Project profile: /environment
Type /environment — the agent asks one question at a time:
- Operating scope — a single project, a portfolio, or org-wide standards.
- Work containers — which of the available Jira projects and Confluence spaces belong to this project (or "none" if the project lives only in documents).
- Methodology — how the team runs work: Scrum, Kanban, or something else. For time-boxed methods — also the cycle length (e.g., 2 weeks).
- Industry and scaling model — which industry profile fits, and whether there is a scaling model.
Before confirming, the agent shows all four values — check them and confirm explicitly. The profile can be corrected at any time: say a field is wrong and the agent will update it.
Step 2. Document registry: /documents
Type /documents (or upload a document and ask it to be classified). The agent reviews the uploaded materials and builds a registry: which project documents already exist — charter, scope, BRD, specification, contract, risk register, plan, and others — and what is missing.
Key details:
- Each document gets a "covers" note — a short statement of which project question it answers. This makes it clear which document answers which question.
- Inapplicable documents are marked explicitly. An internal project with no delivery contract is not a "missed" document: the agent marks the contract as "not applicable" with a reason and will not keep reminding you about it.
- Session and project documents are distinct. A draft prepared in the conversation lives in the session. When a document is ready to be used across sessions, it can be promoted to the project — the agent asks for confirmation before promoting.
Step 3. Next-step advisor: /path
Type /path — the agent reconciles what is already done (document registry, profile, current conversation), determines the lifecycle stage, and proposes up to three concrete next actions.
The stages the advisor distinguishes: awareness → charter → scope → requirements → specification → delivery → risk → monitoring → reporting.
Example output: the charter and scope already exist, the BRD does not, and the contract is marked "not applicable" — then /requirements becomes the priority, and the advisor will not offer the contract.
The advisor /path also runs automatically: at the start of a new conversation and after any command finishes, the agent itself proposes what to do next.
What the agent can and cannot do
| Can | Cannot |
|---|---|
| Read project issues, pages, documents, and schedules | Create projects, spaces, or catalogs in Jira, Confluence, BeOnTime |
| Create and edit working documents | Publish anything without your confirmation |
| Propose issue creation and schedule edits | Commit tracker or schedule changes on your behalf |
| Prepare reports, snapshots, and meeting agendas | Change the project profile on its own without your answer |
Where to continue
- Working with the document base — how to upload project documents to the knowledge base.
- Project initiation — for a new project: charter, contract analysis, first scope.
- Project documents: creation and upkeep — how the agent maintains project documents as work evolves.