Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Use when the stakeholder asks a factual or status question about the workspace - call the matching read tool and answer conversationally, without creating tasks or asking for approval
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치 방법 보기설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
A factual question deserves a factual answer, not a plan. The failure mode is treating "how many projects do we have?" as work to orchestrate — creating tasks, asking approval, or claiming there's "no active context." Just call the read tool and answer.
Core principle: Read tool first, then answer in one or two sentences with the real data.
| Question | Tool |
|---|---|
| How many projects / what are they | list_projects |
| What repositories exist / which project each belongs to | list_repositories |
| Who is on the team / which role does what | list_team |
| What's on the board / a task's status | list_board_tasks |
| Overall status / "how are we doing" | get_board_summary (aggregated by column/type/priority) |
| What's next / what's ready to start | list_ready_tasks |
These read tools are always available and never need an active repository — never answer "no active project/repo context." Call the tool and use the real data.
get_board_summary for "status/how are we doing" over listing every task — it returns the total and counts grouped by column, type and priority in one call. Only drill into list_board_tasks when the stakeholder asks about a specific task or you need titles/assignees.Stakeholder: "How many repos do we have?" → call list_repositories → "We have 3 repos: backend-api, web, and mobile."
Stakeholder: "Who is on the team?" → call list_team → answer from what it returns, e.g. "system-architect and security-agent review, backend, frontend, mobile, data and game developers build, qa tests — each one owns its own area."
Stakeholder: "How are we doing?" → get_board_summary → {total 24; in_progress 3, code_review 2, need_revision 4, backlog 10, done 5} → "24 tasks in total. 3 are in active development, 2 are in architecture review. 4 went back for revision — that's where the biggest risk is. 10 are queued and 5 are done." Not a wall of 24 task titles.
list_board_tasks for a status question get_board_summary answers in one call.아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Use when the repository keeps its alerting in code, or a person asks for alerts outside TaskTrooper - PrometheusRule YAML, a Cloud Monitoring alert policy in Terraform, a Datadog monitor, each routed to TaskTrooper's alert ingest URL so it opens an incident here
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.