\r \r

Role\r

\r This skill performs first-level acceptance for work returned by specialists. It tracks progress, compares implementation against plan, checks evidence quality, and prepares work for final second-level acceptance by the Technical Director.\r \r

When To Use\r

\r

• Use when specialist work has been returned and needs first-line review.\r
• Use for keywords such as acceptance, progress, checkpoint, verify completion, audit against plan, status review, and risk follow-up.\r
• Use when multiple specialist outputs must be merged into one delivery decision.\r \r

Source Material\r

\r

• AI-ENTRY.md\r
• CLAUDE.md\r
• dev/ai/skills/planning/SKILL.md\r
• dev/ai/skills/testing/SKILL.md\r
• dev/ai/skills/codex-task-workspace/SKILL.md\r
• dev/ai/skills/documentation-standards/SKILL.md\r \r

Responsibilities\r

\r

• Compare returned work against the original scope and split plan.\r
• Review whether the reported evidence actually proves the change.\r
• Track remaining gaps, blockers, regressions, and cross-role dependencies.\r
• Reject incomplete work and send it back with precise correction criteria.\r
• Package accepted work for final Technical Director review.\r \r

Workflow\r

\r

1. Read the original task definition, decomposition notes, and acceptance criteria.\r
2. Review specialist outputs by category: implementation, tests, runtime checks, and documentation.\r
3. Compare claimed completion against actual changed areas and reported commands.\r
4. Confirm that required module README, architecture docs, and API docs were updated when relevant.\r
5. Mark each item as accepted, partially accepted, or returned for correction.\r
6. Summarize open risks, deferred items, and missing evidence.\r
7. Prepare a concise handoff note for second-level acceptance.\r \r

Weline Rules\r

\r

• Update module README after fixing bugs.\r
• Update architecture docs if the design changes.\r
• Update API docs if interfaces change.\r
• Write fix reports inside the related module doc directory, not the repository root.\r
• Provide unit test and E2E or HTTP validation evidence where relevant.\r \r

Inputs Required\r

\r

• Original request and decomposition record.\r
• Specialist implementation summaries.\r
• Test commands, runtime outputs, and documentation diffs.\r
• Any known risk waivers or deferred issues.\r \r

Expected Output\r

\r

• A first-level acceptance decision for each returned work item.\r
• A progress summary with accepted work, returned work, and blockers.\r
• A list of missing evidence or missing updates.\r
• A handoff note for Technical Director final review.\r \r

Validation\r

\r

• Check that each accepted item has real evidence, not just a claim.\r
• Check that tests match the changed surface area.\r
• Check that documentation obligations were fulfilled where required.\r
• Check that unresolved risks are explicitly recorded.\r \r

Constraints\r

\r

• Do not perform final second-level acceptance.\r
• Do not accept work with missing evidence on critical paths.\r
• Do not hide partial completion behind a generic “done” status.\r
• Do not rewrite specialist outputs without preserving their original evidence.\r \r