Menu
Read review queue, post review feedback, and transition tickets through the CQ gate on the Planning Board.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Participate in team discussions, report quality patterns, and respond to mentions on the Meeting Board.
Post status updates, respond to mentions, and communicate with the team on the Meeting Board.
Read assigned tickets, post comments, and update ticket status on the Planning Board.
Post deployment status, infrastructure health updates, and coordinate with team on the Meeting Board.
Read tickets, post deployment comments, and move tickets to closed status on the Planning Board.
Communicate with human stakeholders via Meeting Board, Discord, or Slack webhooks.
| name | planning-board |
| description | Read review queue, post review feedback, and transition tickets through the CQ gate on the Planning Board. |
CQ uses the planning board as the primary interface for the code review pipeline. CQ's access is scoped to gate operations: reading the review queue, posting review feedback, and transitioning tickets through the gate.
Note: Tickets have both a priority (1-5 categorical importance) and a rank (backlog position managed by PO). CQ does not modify rank.
PLANNING_BOARD_URL environment variablePLANNING_BOARD_TOKEN environment variableAuthorization: Bearer {PLANNING_BOARD_TOKEN}| Operation | Allowed |
|---|---|
| List/read tickets | Yes |
| Read ticket comments | Yes |
| Post comments | Yes |
| Status: in-review -> in-qa | Yes (PASS) |
| Status: in-review -> in-progress | Yes (FAIL) |
| Create tickets | No |
| Delete tickets | No |
| Assign tickets | No |
| Edit ticket details | No |
| Other status transitions | No |
Retrieve all tickets waiting for CQ review. Always process oldest first.
curl -s \
-H "Authorization: Bearer ${PLANNING_BOARD_TOKEN}" \
"${PLANNING_BOARD_URL}/api/tickets?status=in-review"
Response: Array of ticket objects sorted by creation date.
[
{
"id": "TICKET-42",
"title": "Add user authentication endpoint",
"status": "in-review",
"assignee": "dev-be",
"created_at": "2025-05-10T14:30:00Z",
"pr_url": "https://github.com/org/repo/pull/42"
}
]
Read the complete ticket to understand requirements and acceptance criteria before reviewing code.
curl -s \
-H "Authorization: Bearer ${PLANNING_BOARD_TOKEN}" \
"${PLANNING_BOARD_URL}/api/tickets/TICKET-42"
Response: Full ticket object with description, acceptance criteria, labels, and metadata.
Read the entire discussion thread. Prior comments may contain important context, design decisions, or notes from previous review rounds.
curl -s \
-H "Authorization: Bearer ${PLANNING_BOARD_TOKEN}" \
"${PLANNING_BOARD_URL}/api/tickets/TICKET-42/comments"
Response: Array of comment objects in chronological order.
Used for both approvals and rejections. Every status change must be accompanied by a comment.
curl -s -X POST \
-H "Authorization: Bearer ${PLANNING_BOARD_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"body": "APPROVED. Security review: No secrets in diff, all inputs validated, parameterized queries confirmed. Quality review: Error handling comprehensive, tests cover happy path and edge cases. Clean implementation."
}' \
"${PLANNING_BOARD_URL}/api/tickets/TICKET-42/comments"
APPROVED. Security review: [what was verified]. Quality review: [what was checked]. Ship it.
Keep it concise but specific. QA and the developer should know what CQ verified.
REVIEW FAILED
## Issue 1: [Descriptive Title] (CRITICAL|HIGH|MEDIUM|LOW)
**What's wrong:** [Clear, specific explanation of the problem]
**Why it matters:** [What could go wrong if this ships -- concrete scenario]
**Fix suggestion:**
\```[language]
[Specific code example or step-by-step instructions]
\```
## Issue 2: [Title] (SEVERITY)
...
Every rejection must include at minimum: what is wrong, why it matters, and how to fix it. Code examples are strongly preferred when the fix is code-related.
After posting an approval comment, move the ticket forward to QA.
curl -s -X PUT \
-H "Authorization: Bearer ${PLANNING_BOARD_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"status": "in-qa"}' \
"${PLANNING_BOARD_URL}/api/tickets/TICKET-42"
After posting a rejection comment with detailed feedback, move the ticket back to the developer.
curl -s -X PUT \
-H "Authorization: Bearer ${PLANNING_BOARD_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"status": "in-progress"}' \
"${PLANNING_BOARD_URL}/api/tickets/TICKET-42"
CRITICAL: When failing a ticket, BOTH actions are required:
in-progressA rejection without a comment leaves the developer confused. A comment without a status change leaves the ticket stuck in the queue. Both. Always. No exceptions.
status=in-review, sorted oldest first