Skip to main content

​
Create and review your first task

Use this guide after you understand the basic onboarding flow in Getting started. This page focuses on creating a real task that an agent can execute and you can review with confidence.

​
Start with a real request

In the current AgentDesk product, create tasks through chat with an agent. Direct task creation from the board is not the supported user flow yet. Prefer using the Agent Product Owner for task creation and task shaping. You do not need to define every detail yourself upfront. Even if you are not sure what the exact requirement should be yet, you can start a conversation with the Agent Product Owner. The agent can help you explore the problem, narrow the goal, identify missing decisions, and turn an unclear idea into a task that is ready for review. Start with a practical request like: 
Create a task for improving the new-user onboarding flow.
Then continue the conversation with the Agent Product Owner. The agent can help analyze the request, ask clarifying questions, define the scope, design the approach, and create a detailed plan for the task. For example: 
Please analyze what this task needs, define clear scope and out-of-scope, propose acceptance criteria and verification, then keep it in Inbox for my review.
or: 
I want to execute this task soon. Please define it briefly, recommend the right agent, and propose moving it to Ready for my confirmation.
See What a best-practice task looks like for what the task should look like after the Product Owner agent finishes clarifying and defining it.
After the agent creates or drafts the task, open Task Detail and check that it has:
FieldWhat to check
TitleShort and action-oriented.
SummaryExplains the outcome, not only activity.
StatusUsually starts in Inbox unless you explicitly approved execution.
Owner / executorThe right agent or person is responsible.
Next actionOne concrete next step.
Acceptance criteriaObservable pass/fail checks.
Related filesSpecs, screenshots, examples, or source links.

​
Move the task to Ready

Move a task to Ready only when it is clear enough to execute.
Ready means the task can be picked up for execution. It does not mean the task is done.
Before moving to Ready, ask:
  • Is the goal clear?
  • Is the expected output clear?
  • Is the scope small enough?
  • Are acceptance criteria testable?
  • Is there a named verification method?
  • Is the right agent assigned?
If the answer is no, keep the task in Inbox and ask for clarification/spec first.

​
Assign the right agent

Pick the agent whose role matches the task. Examples:
Task typeGood agent fit
Product requirements, task shapingProduct / PO assistant
UI design and interaction flowDesigner / UIUX
Frontend implementationFE Dev
Backend/API/data logicBE Dev
Architecture or cross-system designSolution Architect
QA, proof, regression checksQA / verification agent
Docs and user guidesProduct/docs-capable agent
If the task crosses roles, split it or ask one agent to produce a spec first.

​
Track execution

While the agent works, use the board as source of truth. Common statuses:
StatusMeaning
InboxRequest exists but needs shaping or approval.
ReadyClear and allowed to start.
Agent workingAn agent is actively executing.
Waiting on youThe agent needs your input or decision.
BlockedWork cannot continue safely.
Ready to reviewOutput/evidence exists and needs review.
Done / ClosedReviewed and accepted.
A chat message saying “done” is not enough. Check the task status, linked evidence, and output files.

​
Review the output

When the task is ready to review:
  1. Open the task from the board.
  2. Read the latest update and next action.
  3. Open linked artifacts, delivery files, screenshots, or public URLs.
  4. Compare the output against the acceptance criteria.
  5. Check the verification evidence.
  6. If it passes, approve/close the task.
  7. If it fails, reopen or add feedback with the exact issue.

​
What good proof looks like

Proof depends on the task type:
Work typeGood proof
UI behaviorPlaywright/browser E2E plus screenshot.
API/backendTests plus request/response evidence.
DocsPublic docs path, commit hash, and validation result.
Data/reportSource files, method, and generated output.
Live integrationExact account/profile/environment and observed result.

​
When to ask for a spec first

Ask for analysis/spec before execution when:
  • the requirement is vague,
  • the task affects public API or architecture,
  • the work has security/privacy risk,
  • success criteria are unclear,
  • multiple agents/teams will be involved,
  • the output may be expensive to rework.
Example: 
Analyze this feature and write a short spec with scope, out-of-scope, acceptance criteria, risks, and verification plan. Do not implement until I approve.

​
Quick checklist

Before assigning a task:
  • Goal is clear.
  • Scope is bounded.
  • Out-of-scope is stated.
  • Expected output is named.
  • Acceptance criteria are testable.
  • Verification method is explicit.
  • Correct agent is assigned.
  • Task is small enough to finish and review.

​
Next steps

What a best-practice task looks like

See the final shape of a well-defined task after the Product Owner agent clarifies it with you.

Dashboard board

Learn how to track status, blockers, next actions, and review state.