Documentation Index
Fetch the complete documentation index at: https://docs.agentdesk.team/llms.txt
Use this file to discover all available pages before exploring further.
What a best-practice task looks like
You do not need to write a perfect task brief by yourself.
In AgentDesk, the recommended flow is to start with a rough request, then work with an Agent Product Owner to analyze, clarify, define, and plan the task before execution.
The goal of this page is to show what a task should look like after that conversation is complete.
The user does not need to know everything upfront
A rough request is enough to start:
Create a task for improving the new-user onboarding flow.
- a clear goal,
- scope and out-of-scope,
- assumptions and open questions,
- expected output,
- acceptance criteria,
- verification plan,
- suggested executor/owner,
- next action.
Your job is to provide business context, priorities, examples, and decisions. The Agent Product Owner’s job is to shape that into executable work.
What a best-practice task contains
A well-defined task usually has these parts:
| Section | What it answers |
|---|
| Title | What is this task about? |
| Goal | What user/business outcome should change? |
| Context | Why are we doing this now? What prior task, issue, user feedback, or decision matters? |
| Scope | What should be included? |
| Out of scope | What should not be touched in this task? |
| Expected output | What should be delivered? UI change, docs page, report, API, proof pack, etc. |
| Acceptance criteria | How will we know the task is good enough? |
| Verification plan | What proof is required before marking it done? |
| Owner / executor | Who should do the work? |
| Next action | What is the next concrete step? |
Example: from rough request to clear task
User starts with
Create a task for improving the new-user onboarding flow.
Agent Product Owner asks clarifying questions
Good questions are specific and decision-oriented:
I can create a task for improving the new-user onboarding flow. Before it is ready for execution, I need to clarify a few points:
1. What user or business outcome should this improve?
2. What final output do you expect: UI change, docs, report, automation, or test proof?
3. Is anything clearly out of scope?
4. Who should review or approve the result?
5. What proof is required: screenshot, Playwright UI E2E, test, build, or live verification?
User gives context
The goal is to help new users understand how to create clearer tasks for agents.
The output should be a User Guide docs page.
No product code changes are needed.
Proof should be the published page on docs.agentdesk.team plus a commit hash.
Agent Product Owner turns it into a defined task
Title:
Add User Guide page for creating clear AgentDesk tasks.
Goal:
Help new users understand how to work with an Agent Product Owner to turn a rough request into a clear, executable task.
Context:
Current docs mention task creation, but users may think they must define every detail themselves. In the current product, tasks are created through chat with an agent, preferably the Agent Product Owner.
Scope:
- Explain that users can start with a rough request.
- Explain how to collaborate with Agent Product Owner to clarify the task.
- Show what a well-defined task looks like after clarification.
- Add examples and review checklist.
- Publish to AgentDesk public docs.
Out of scope:
- Do not document direct board task creation as supported.
- Do not change product code.
- Do not require users to write full specs themselves.
Expected output:
A User Guide docs page in the public AgentDesk docs site.
Acceptance criteria:
- Page clearly recommends Agent Product Owner for task shaping.
- Page shows before/after examples.
- Page describes the final shape of a good task.
- Navigation includes the page.
- docs.json remains valid.
Verification plan:
- Validate docs.json.
- Run Mintlify validation if available.
- Push to the canonical docs repo.
- Provide commit hash and expected public URL.
Owner / executor:
Docs/Product agent.
Next action:
Draft the docs page, update navigation, validate, commit, and push.
How to interact with the Agent Product Owner
Use normal language. You can be rough at first.
Good starting prompts:
Create a task for improving the new-user onboarding flow.
Please analyze this request, write a clear spec/task, and keep it in Inbox for my review.
I want to build this feature. Ask me the key questions needed to define it, then create a task for the team.
Create a task for this bug. Do not assign it to engineering yet; analyze the cause and scope first.
Create this task and, if it is clear enough, recommend the right agent to execute it.
What the Agent Product Owner should do
A good Agent Product Owner should:
- restate the goal in plain language,
- identify missing decisions,
- ask only questions that change execution quality,
- define scope and out-of-scope,
- suggest acceptance criteria,
- suggest verification proof,
- keep the task in Inbox until approved,
- recommend the right executor,
- warn if the task is too broad or risky.
If the request is vague, the agent should not silently invent important requirements and move it straight to execution. It should clarify or create a draft task/spec for review.
What the user should review before approving
Before you tell the agent to move a task to Ready, check:
- Does the title match what you asked for?
- Does the goal describe the user/business outcome?
- Is scope clear enough?
- Is out-of-scope stated?
- Is the expected output concrete?
- Are acceptance criteria testable?
- Is verification/proof explicit?
- Is the recommended executor correct?
- Is the next action specific?
If something is missing, ask the Agent Product Owner to refine it.
Good approval prompts
When the task looks good:
Looks good. Move this task to Ready and assign it to Nam.
The spec looks good. Assign it to Duy and require Playwright screenshot proof before marking it done.
Keep this task in Inbox. I need to review the scope further.
Signs a task is not ready yet
Keep the task in Inbox if:
- the outcome is unclear,
- the task mixes too many unrelated things,
- expected output is not defined,
- acceptance criteria are subjective,
- no verification method is named,
- the executor is unclear,
- the work may affect security, auth, public docs, external messages, billing, or user data without review.
Final mental model
You provide intent and decisions.
The Agent Product Owner turns that intent into a clear task.
The executor agent delivers the task.
You review the output and proof before closing it.