Work items and planning
Keep a ticket, its acceptance criteria, the working branch and agent sessions together in Mezair Desktop. This lets you plan and review a change against the work item that prompted it.
Supported planning sources
Mezair is designed around provider-backed work item systems and local planning state:
- Linear
- Jira
- Azure DevOps
- GitHub pull requests and issues where relevant
- BA session notes
- acceptance criteria pasted into a session
- local follow-up tasks created from review or security findings
Available actions depend on the connector and its configuration. Planning stays attached to the active workspace and repository.
Planning flow
- Select a workspace.
- Open or import the work item.
- Attach the relevant repository or branch.
- Ask Mezair to inspect the current code path.
- Compare implementation reality with acceptance criteria.
- Identify dependencies, unknowns, risks, and likely files.
- Decide whether the change is ready for implementation, needs a spike, or should be split.
BA mode
BA sessions are useful when the work item needs clarification before implementation. They can identify:
- ambiguous acceptance criteria
- mismatches between expected and current behavior
- missing data, auth, accessibility, reporting, or compliance considerations
- implementation dependencies
- follow-up questions for product, design, or stakeholders
- likely test coverage
BA output should feed the work item or handover. If it only creates a second place to lose context, the tool has failed politely.
BA sessions persist their messages and findings against the work item. A finding has a type and status, can become a provider-backed work item, and can be updated or deleted. The session also records which repository supports the spike.
Mezair watches for branch drift during an active spike. Treat that signal as a request to re-check the code against the original acceptance criteria, not as proof that the branch is wrong.
Meeting Notes
Meeting Notes accepts pasted text, typed notes, or voice input when the runtime supports speech capture. Local parsing identifies:
- a short summary from the opening sentences
- sentences that look like actions or ownership statements
- longer key points for BA follow-up
- spike candidates containing risk, ambiguity, dependency, security, legal, or feasibility signals
The parser is deliberately simple and visible in the UI. It does not claim to understand the meeting. Use the actions and spike candidates as prompts for review.
From the result you can open Chat with a summary request, an action extraction request, a BA deep dive, or a spike-scoping prompt. The transcript is capped before it enters the generated Chat URL, so keep the relevant section near the selected item when working with very long notes.
Workspace Notes
Use Workspace Notes for a follow-up that belongs to the workspace but is not ready to become a tracked ticket. Notes can come from Desktop or supported companion inputs. Accept a note when it has been handled, or dismiss it when it no longer applies.
Use a work item when the task needs an owner, provider state, prioritisation, acceptance criteria, or reporting. Notes are a review queue, not a backlog with fewer buttons.
Planning output
Good planning output includes:
- repo and branch inspected
- source files or modules likely involved
- assumptions
- decision points
- risks
- proposed implementation steps
- suggested validation
- follow-up work if the original item is too broad
When to split work
Split the work when:
- acceptance criteria span unrelated modules
- one change touches data model, auth, UI, and release behavior at once
- a security finding needs separate review ownership
- a dependency or migration blocks safe implementation
- the implementation would require broad refactoring to make a small feature work
Mezair should make the split visible. It should not pretend one ticket is small because the heading is short.