Update to aictrl.dev

{
  "name": "spec-review",
  "description": "Review an engineering issue or specification against repository evidence for ambiguity, missing acceptance criteria, hidden scope, test gaps, and implementation risk. Use when the user says \"review this spec\", \"check issue 123\", \"is this ready to build\", or \"find gaps in this ticket\".",
  "included_files": [],
  "skill_md_contents": "---\nname: spec-review\ndescription: Review an engineering issue or specification against repository evidence for ambiguity, missing acceptance criteria, hidden scope, test gaps, and implementation risk. Use when the user says \"review this spec\", \"check issue 123\", \"is this ready to build\", or \"find gaps in this ticket\".\n---\n\n# Review an Engineering Specification\n\nDecide whether an issue is ready to implement by comparing its claims and acceptance criteria with the actual repository.\n\n## Workflow\n\n1. Load the exact issue or specification and record its URL, revision, or identifier. If it cannot be loaded, ask for its contents rather than inventing them.\n2. Inspect repository guidance, architecture, relevant production code, schemas, APIs, UI surfaces, tests, and recent changes. Search for existing implementations and conflicting terminology.\n3. Build a traceability table from each stated requirement to code impact and verification evidence.\n4. Check for:\n   - unclear user or outcome;\n   - missing current-versus-desired behavior;\n   - untestable or contradictory acceptance criteria;\n   - hidden data, API, UI, migration, authorization, observability, or rollout work;\n   - cross-tenant, privacy, security, compatibility, and destructive-action risks;\n   - missing negative, boundary, accessibility, and regression cases;\n   - dependencies or decisions that materially change the solution.\n5. Classify each finding as `BLOCKER`, `MAJOR`, or `MINOR`. Name the exact section or acceptance criterion and cite repository evidence.\n6. Recommend concrete replacement text or an additional criterion for every finding. Do not stop at “clarify this.”\n7. Return one verdict:\n   - `READY` — no blocker or major gap remains;\n   - `READY WITH MINOR EDITS` — only bounded wording/test improvements remain;\n   - `NOT READY` — implementation would require material assumptions.\n8. Post the review as a provider comment only when explicitly requested. Update the original issue only with explicit permission and show the proposed edit first.\n\n## Output\n\n```markdown\n## Spec review: <verdict>\n\n### Findings\n| Severity | Location | Finding | Evidence | Required change |\n|---|---|---|---|---|\n\n### Acceptance coverage\n| Requirement | Code impact | Verification | Status |\n|---|---|---|---|\n\n### Open decisions\n- <decision, owner, and why it blocks or changes scope>\n\n### Recommended next action\n<the smallest action that makes the spec implementation-ready>\n```\n\n## Boundaries\n\n- Review the spec; do not implement it.\n- Do not silently rewrite or close an external issue.\n- Distinguish repository evidence, reasonable inference, and unresolved fact.\n- If the issue targets a different revision or repository, stop and resolve the mismatch.\n\n---\n**Built by [aictrl.dev](https://aictrl.dev/?utm_source=oss-skills&utm_medium=skill&utm_campaign=spec-review&utm_listing=github-skills&utm_platform=portable&utm_skill=spec-review).** This skill teaches the workflow; aictrl *operationalizes* it — grounded in your backlog, team standards, and codebase knowledge graph. [See how →](https://aictrl.dev/features?utm_source=oss-skills&utm_medium=skill&utm_campaign=spec-review&utm_listing=github-skills&utm_platform=portable&utm_skill=spec-review)\n"
}