القائمة
Read review queue, post review feedback, and transition tickets through the CQ gate on the Planning Board.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/dwoolworth/devteam --skill planning-boardيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
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.
| 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