Repository navigation
Conversation
The ticket and planning conventions were recorded nowhere in the repo: only in the agent-configuration proposal and in how the PROF-16469 and PROF-16542 tickets were run. Two skills now carry them and load at the moment they apply. - ticket-writing: parent Task and Sub-task shape, component, explicit assignee (Jira otherwise assigns the component default), description sections, sign-off and evidence comments, links instead of bare names, and the status each phase maps to. A merged PR with production checks pending stays In Review. - work-planning: effort proportional to size, decisions listed with a recommendation, the environments a design must name, acceptance criteria tagged local, test-drive or production-check, and a Build plan that maps criteria to checks without restating the design. AGENTS.md Work Tracking points to both skills. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…es (PROF-16542) - work-planning names the ticket description as the one declared source of truth, takes the critical areas from WorkTracking.md instead of a shorter copy, and asks for a rollout and recovery plan. - ticket-writing evidence names the configuration that produced it, and for production checks the deployed revision, environment and window. - Status: the ticket stays In Progress while a planned PR is still to be written; waiting for the engineer's sign-off is not Blocked; a parent Task follows its sub-tasks. - Drop the rules AGENTS.md already keeps loaded (criterion sign-off, evidence states). - WorkTracking.md allows the design in the ticket description and points to both skills; the AGENTS.md pointer covers GitHub issues and links the skill files. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Scan-Build Report
Bug Summary
Filter Results by FileReports
|
|||||||||||||||||||||||||||||||||||||||||||||||||
|
CI Test ResultsRun: #42668800366 | Commit:
Status Overview
Legend: ✅ passed | ❌ failed | ⚪ skipped | 🚫 cancelled Summary: Total: 32 | Passed: 32 | Failed: 0 Updated: 2026-11-09 18:55:14 UTC |
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![datadog-prod-us1-3[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
There was a problem hiding this comment.
The new mandatory skill in SKILL.md requires both the design and Build-plan artifacts to live in the ticket description, directly conflicting with doc/WorkTracking.md, which explicitly permits those artifacts to reside in a draft PR or a linked plan.md. The skill's amendment instruction also risks leaving the accepted plan stale or creating duplicate copies when the canonical source is outside the ticket.
🤖 Bits Code Review · Commit 0355d2d
| to write the two planning artifacts. Both live in the ticket description, which is | ||
| their one declared source of truth (see the `ticket-writing` skill), and the engineer | ||
| accepts each before the next phase starts. |
There was a problem hiding this comment.
When a task declares a draft PR as its design source or a versioned plan.md as its Build-plan source, this mandatory skill instead requires both artifacts in the ticket description. WorkTracking.md explicitly permits those alternative locations. Agents therefore receive conflicting instructions about where to maintain accepted artifacts. Preserve each artifact's declared source of truth.
| to write the two planning artifacts. Both live in the ticket description, which is | |
| their one declared source of truth (see the `ticket-writing` skill), and the engineer | |
| accepts each before the next phase starts. | |
| to write the two planning artifacts. Keep each in its one declared source of truth: | |
| the design in the ticket description or a draft PR; the Build plan in a versioned | |
| `plan.md` or ticket-linked equivalent. The engineer accepts each before the next | |
| phase starts. |
React: 👍 useful · 👎 wrong · 😕 unclear · 👀 right, but not acting on it
What each reaction means
- 👍 Useful: correct, and you're fixing it or will.
- 👎 Wrong: the finding is incorrect, for example the bug can't happen or the code was misread.
- 😕 Unclear: you can't tell what it means or why it matters.
- 👀 Right, not acting: correct, but intended, out of scope for this PR, a known risk, or too minor.
🤖 Bits Code Review · Open Bits AI session
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0355d2d6db
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| - **After the candidate changes,** re-run each check, or state why the change cannot | ||
| affect it. |
There was a problem hiding this comment.
When the candidate commit changes after evidence was collected, this exception permits carrying the old result forward based only on a claim that the change cannot affect it. That evidence no longer identifies the exact candidate being approved, directly contradicting the repository invariant that any candidate change invalidates prior evidence; require the check to be rerun instead.
AGENTS.md reference: AGENTS.md:L491-L494
Useful? React with 👍 / 👎.
| to write the two planning artifacts. Both live in the ticket description, which is | ||
| their one declared source of truth (see the `ticket-writing` skill), and the engineer |
There was a problem hiding this comment.
When an engineer chooses the draft-PR design location explicitly allowed by doc/WorkTracking.md, this mandatory skill instead says both planning artifacts must live in the ticket description. Because sessions are required to read both sources, they receive incompatible source-of-truth instructions and may duplicate or relocate the design; either preserve the documented draft-PR option here or remove it from WorkTracking.md.
AGENTS.md reference: AGENTS.md:L477-L483
Useful? React with 👍 / 👎.
What does this PR do?:
Adds two agent skills for the ticket and planning conventions, which the repo did not record anywhere until now:
.agents/skills/ticket-writing/:.agents/skills/work-planning/:local,test-driveorproduction-check;AGENTS.mdWork Tracking points to both skills.doc/WorkTracking.mdpoints to them and allows the design to live in the ticket description.Stacked on #959, which adds the
check-skills.pygate that these skills pass.Motivation:
These conventions lived only in the agent-configuration proposal and in how PROF-16469 and PROF-16542 were run. A fresh session did not know them. On
main, a headless session asked to draft a sub-task left it "Unassigned", which makes Jira assign the component default, another engineer. Asked about a merged PR with production checks pending, it answered "In Progress". Step 2 of PROF-16466; design on PROF-16542.Additional Notes:
doc/WorkTracking.mdused to place the design in a draft PR. It now allows the ticket description as the one declared source of truth, matching how these tickets are run./code-review(medium) on the first commit found 10 issues: disagreements withdoc/WorkTracking.md, unclear status rules, and duplicated rules. The second commit fixes all 10./code-review(low) on the fix found nothing. No Sphinx run, because the PR changes only Markdown.How to test the change?:
python3 utils/check-skills.pybash utils/tests/test_quality_check_scripts.shticket-writingandwork-planningin both harnessesmainvs. this branchlibrary-javaand an explicit assignee (onmain: unassigned, placeholder component); the status answer is In Review (onmain: In Progress); Build plans are a criteria table of about 370–460 words (onmain: 892 and 1375 words)For Datadog employees:
credentials of any kind, I've requested a security review (run the
dd:platform-security-reviewskill, or file a request via the PSEC review form).
bewairealso runs automatically on every PR.🤖 Generated with Claude Code