Package Optimizer
Turn existing package evidence into one bounded, reviewable proposal. The
optimizer is proposal-only: it never edits a package, changes a profile, or
starts a benchmark run.
Scope
| Situation |
Action |
| One package has current evaluator evidence |
Propose one disposition. |
| A bounded family shares the same evidence/profile |
Propose one family plan with a per-package row. |
| Evidence is missing, stale, structurally invalid, or from another profile |
Return inconclusive; name the unresolved package decision and request the smallest recertification needed. |
| User asks to apply a proposal |
Require explicit approval, preserve before artifacts, then hand the edit to the normal package workflow. |
| User asks for a broad benchmark before identifying a package decision |
Refuse the expansion; identify the package decision first. |
Required inputs
- Package scope — one
type/name package or an explicitly bounded family.
- Current evidence — static conformance and relevant eval-case result or a
recorded behavioral result. Cite exact commands, artifacts, or case IDs.
- Capability profile — model/client/tool-surface identity when behavioral
evidence depends on one. Structural-only evidence is labelled as such.
- Decision question — what behavior should be retained, simplified, or
strengthened.
Do not infer effectiveness from package length, heading count, or static score.
Evidence validity
Reject evidence when any condition holds:
- package path, version, or evaluator case differs from the proposed scope;
- a behavioral result has no model/client/tool-surface identity;
- a profile is older than a recorded package change or cannot be compared to the
requested profile;
- the evidence omits a failure, safety outcome, or relevant evaluator result;
- an M4 recertification report pools model targets or lacks complete cells.
A rejection uses the single output format below with Disposition: inconclusive,
Proposed change: none, and Approval required: yes. Its Unresolved package decision must name the package scope and decision question. A recertification
request repeats that exact field; do not request a benchmark without it.
Procedure
- Resolve the package scope and read its definition, evaluator cases, and
current conformance output.
- State the decision question and evidence class:
structural, behavioral,
or profile-scoped behavioral.
- Verify evidence validity. Stop with
inconclusive on any invalid input.
- Select exactly one disposition:
retain — evidence supports the current contract.simplify — evidence identifies redundant detail and the retained
contract/evaluator proves the smaller scope.strengthen — a documented failure requires a concrete contract addition.retire — explicit deprecation or replacement evidence supports removal.inconclusive — evidence cannot support a safe change.
- Produce a proposal. For non-
retain dispositions, name exact sections or
files to change and the evaluator behavior that must remain true.
- Stop. Do not edit. Require the user to explicitly approve the proposal.
Approval handoff
An approval must name the package, disposition, and proposal ID. The downstream
applying workflow—not this skill—must:
- Save the original package artifact and evaluator evidence.
- Apply only the approved package/family change.
- Run static conformance and relevant eval cases.
- Record before/after artifacts, verification output, profile identity, and any
regression.
- Revert the bounded package change on regression. Do not broaden the scope.
Output format
## Package Optimization Proposal
Scope: <type/name or bounded family>
Decision question: <question>
Evidence class: <structural | behavioral | profile-scoped behavioral>
Evidence:
- <command/artifact/case and observed result>
Capability profile: <identity | not applicable>
Disposition: <retain | simplify | strengthen | retire | inconclusive>
Rationale: <evidence-backed explanation>
Unresolved package decision: <scope + decision question | not applicable>
Proposal ID: <stable scope + evidence identifier>
Proposed change: <none | exact files/sections and intended behavior>
Preservation check: <existing evaluator/eval case>
Approval required: yes
Smallest next action: <concrete action>
Guardrails
- Never edit without explicit approval.
- Never optimize all packages at once.
- Never turn missing evidence into a simplification recommendation.
- Never claim token, cost, or quality improvement without recorded evidence.
- Prefer
retain or inconclusive over speculative change.
1---2name: package-optimizer3description: Evaluate one existing package or bounded package family from recorded evaluator evidence and a capability profile, then propose retain, simplify, strengthen, retire, or inconclusive without editing. Use when optimizing a skill, agent, hook, rule, command, utility, or preset; evaluating whether package detail is justified; reviewing a model-refresh impact; or preparing an approval-gated package improvement. Refuses missing, stale, or incomparable evidence and never edits without explicit approval. Not for scoring static package conformance or rubric dimensions; use package-evaluator.4---56# Package Optimizer78Turn existing package evidence into one bounded, reviewable proposal. The9optimizer is proposal-only: it never edits a package, changes a profile, or10starts a benchmark run.1112## Scope1314| Situation | Action |15| --- | --- |16| One package has current evaluator evidence | Propose one disposition. |17| A bounded family shares the same evidence/profile | Propose one family plan with a per-package row. |18| Evidence is missing, stale, structurally invalid, or from another profile | Return `inconclusive`; name the unresolved package decision and request the smallest recertification needed. |19| User asks to apply a proposal | Require explicit approval, preserve before artifacts, then hand the edit to the normal package workflow. |20| User asks for a broad benchmark before identifying a package decision | Refuse the expansion; identify the package decision first. |2122## Required inputs23241. **Package scope** — one `type/name` package or an explicitly bounded family.252. **Current evidence** — static conformance and relevant eval-case result or a26 recorded behavioral result. Cite exact commands, artifacts, or case IDs.273. **Capability profile** — model/client/tool-surface identity when behavioral28 evidence depends on one. Structural-only evidence is labelled as such.294. **Decision question** — what behavior should be retained, simplified, or30 strengthened.3132Do not infer effectiveness from package length, heading count, or static score.3334## Evidence validity3536Reject evidence when any condition holds:3738- package path, version, or evaluator case differs from the proposed scope;39- a behavioral result has no model/client/tool-surface identity;40- a profile is older than a recorded package change or cannot be compared to the41 requested profile;42- the evidence omits a failure, safety outcome, or relevant evaluator result;43- an M4 recertification report pools model targets or lacks complete cells.4445A rejection uses the single output format below with `Disposition: inconclusive`,46`Proposed change: none`, and `Approval required: yes`. Its `Unresolved package47decision` must name the package scope and decision question. A recertification48request repeats that exact field; do not request a benchmark without it.4950## Procedure51521. Resolve the package scope and read its definition, evaluator cases, and53 current conformance output.542. State the decision question and evidence class: `structural`, `behavioral`,55 or `profile-scoped behavioral`.563. Verify evidence validity. Stop with `inconclusive` on any invalid input.574. Select exactly one disposition:58 - `retain` — evidence supports the current contract.59 - `simplify` — evidence identifies redundant detail and the retained60 contract/evaluator proves the smaller scope.61 - `strengthen` — a documented failure requires a concrete contract addition.62 - `retire` — explicit deprecation or replacement evidence supports removal.63 - `inconclusive` — evidence cannot support a safe change.645. Produce a proposal. For non-`retain` dispositions, name exact sections or65 files to change and the evaluator behavior that must remain true.666. Stop. Do not edit. Require the user to explicitly approve the proposal.6768## Approval handoff6970An approval must name the package, disposition, and proposal ID. The downstream71applying workflow—not this skill—must:72731. Save the original package artifact and evaluator evidence.742. Apply only the approved package/family change.753. Run static conformance and relevant eval cases.764. Record before/after artifacts, verification output, profile identity, and any77 regression.785. Revert the bounded package change on regression. Do not broaden the scope.7980## Output format8182```text83## Package Optimization Proposal8485Scope: <type/name or bounded family>86Decision question: <question>87Evidence class: <structural | behavioral | profile-scoped behavioral>88Evidence:89- <command/artifact/case and observed result>90Capability profile: <identity | not applicable>9192Disposition: <retain | simplify | strengthen | retire | inconclusive>93Rationale: <evidence-backed explanation>94Unresolved package decision: <scope + decision question | not applicable>9596Proposal ID: <stable scope + evidence identifier>97Proposed change: <none | exact files/sections and intended behavior>98Preservation check: <existing evaluator/eval case>99Approval required: yes100101Smallest next action: <concrete action>102```103104## Guardrails105106- Never edit without explicit approval.107- Never optimize all packages at once.108- Never turn missing evidence into a simplification recommendation.109- Never claim token, cost, or quality improvement without recorded evidence.110- Prefer `retain` or `inconclusive` over speculative change.
mathews-tom