| name | package-assess |
| description | Turn one package's review.md into its assessment.md — the recommendation layer of the per-package cell under agents/packages/<name>/. Sorts the gaps from review.md into Recommended (sweep-safe, within-package, non-design-decision) and Backlog (parked / cross-package / larger), applying the SDK-wide structural forks (registry-by-default, the subject triad, the bedrock test). Leaves Approved empty — approval is the user's verbal gate. Surfaces design forks and cross-package items to the charter's Open directions, not into Recommended. Use after package-review, or when asked to "assess <package>", "build the assessment", or as a batch stage. Read agents/packages/index.md, structural-forks.md, and CONTRACT.md first. |
Package Assess
You are the recommendation layer. Input: agents/packages/<name>/review.md (the verified observation). Output: exactly one file, agents/packages/<name>/assessment.md. You curate; you do not observe (that is the review) and you do not set vision or approve (those are the charter / the user).
Always full-path the cell artifacts (agents/packages/<name>/…) — the repo-root packages/<name>/ is the source tree, a name collision.
Inputs
agents/packages/<name>/review.md — gaps, contract-fit findings, candidate open directions. The evidence you sort.agents/packages/<name>/charter.md — the rubric. Recommend only what serves the charter's North star and respects its Boundaries. Items that need a Boundary/North-star decision are Open directions, not Recommended.structural-forks.md — apply the SDK-wide rules (next section).
Apply the structural forks
- Registry by default (fork B): a roadmap item that adds a
kind to a closed switch should prefer opening a registry; flag the union-vs-registry choice if the family is growing.
- The subject triad (data /
-formats / -backend): a roadmap item that is really a format codec or backend belongs in its own triad-layer cell — recommend it there, with the plurality guard (only when ≥2 formats/backends).
- The bedrock test: a roadmap item proposing a new package runs the test (substantial & irreducible / well-homed / honest-name). If it fails, say so; if it's a real new subject, it's a candidate for the register, not in-package Recommended.
- The bundle invariant: prefer a separately-importable primitive/pass over a new branch in a hot loop or a new case in a shared switch — an assembly never inflates a primitive's cost.
What assessment.md contains
Front matter per CONTRACT.md (package, updated, basedOn). Then three sections:
- Recommended — sweep-safe: within
@flighthq/<name>, no cross-package coupling, no breaking change, no open design decision. This is the set a blanket "do all recommended" can safely bless.
- Backlog — parked: cross-package coordination, larger scope, or waiting on an Open direction. Say why each is parked.
- Approved — frozen on the user's verbal approval only. Leave empty.
Design forks and cross-package items do not go in Recommended — route them to the charter's Open directions (note them for the charter; you do not edit the charter yourself).
Boundaries of this skill
- Produce exactly one file:
assessment.md. Do not write review.md, charter.md, or status.md, and never populate Approved.
- Keep
Recommended strictly sweep-safe — its safety is what makes blanket approval work.
- Ground every item in the review or the roadmap; do not invent work.
