| name | package-spec-review |
| description | Review tracked rawsql-ts package-level Scope, Test Policy, Authority Model, Technology Policy, review-plan, and generated review views before package implementation or documentation changes. Use only when those package-owned artifacts exist in the checked-out base. |
Package Spec Review
Apply the owning package's tracked policy artifacts without inventing a missing harness or carrying rules forward from removed packages.
Authority
- Human-owned requirements: Concept Specs, DFDs, Process Maps, Scope Specs, issues, and explicit human decisions.
- AI-led review management: cross-document checks, required-read planning, and findings.
- Tool-owned derived views: generated reports, metadata checks, and review plans produced by a tracked command.
Generated views are evidence and navigation aids, not requirement sources.
Inputs
Discover tracked inputs in this order:
- root and owning package
AGENTS.md files;
- package concept, scope, and design documentation;
- tracked scope, test, authority, and technology rule registries;
- a review plan produced by a tracked repository command, when available;
- changed source artifacts and their declared required reads.
If no package-level harness exists, report this skill as not applicable and use the owning AGENTS.md, DESIGN.md, tests, and public contract. Do not reconstruct deleted files from ignored dist or node_modules output.
Surface diagnostics, unmapped business artifacts, missing source-to-generated traceability, and policy-exception warnings before semantic review.
Checks
- changed behavior remains inside the owning package responsibility;
- test evidence satisfies the owning Test Policy;
- human-owned requirements are not replaced by AI or generated prose;
- technology choices follow the tracked Technology Policy or declare a human-reviewable exception;
- generated review views trace back to their tracked source and generator;
- cross-package effects and required verification are explicit.
Treat possible exceptions as review triggers, not automatic rejection. Name the policy source, exception reason, scope impact, affected packages, and verification required.
Output
- Status:
pass, needs-revision, needs-human-decision, or not-applicable
- Authority inputs checked
- Package spec inputs checked
- Derived review-plan findings
- Semantic findings
- Policy exceptions
- Required human decision
Do not rewrite human-owned requirements as final authority, use generated output as a source of truth, silently skip a tracked mandatory rule, or resolve a policy exception by redefining concept meaning.
