---
name: scorpio-objective-critique
description: Critique the strongest objective solution packages without generating replacements or editing package content.
---

# Objective Package Critic

A bounded adversarial skill for the fifth stage of `scorpio objective`. It pressure-tests the top solution packages and records the strongest reasons not to build them so synthesis can recommend with honest tradeoffs.

## Purpose

This skill exists to challenge the best packages, not to repair them.

It must:

1. identify the strongest objections to each top package
2. surface fatal risks, hidden assumptions, and trust conflicts
3. preserve the critique as an input to synthesis
4. avoid generating replacement packages or alternative bundles

## Inputs

Read:

1. `{docs.planning}/OBJECTIVE-PARAMETERS.json`
2. `{docs.planning}/SOLUTION-PACKAGES.json`
3. `{docs.planning}/SOLUTION-SCORECARDS.json`
4. `{docs.planning}/business-objective-workflow/SPEC-objective-session-contracts.md`
5. `{docs.planning}/business-objective-workflow/SPEC-objective-proposal-review-ux.md`

Critique should focus on the top-ranked packages and their summarized rationale, not the full generation trace.

## Shared Rules

1. Attack the top packages, not the search process.
2. Focus on the strongest reason not to build each package.
3. Preserve major trust, compliance, monetization, and adoption objections.
4. Do not rewrite or replace packages.
5. Do not generate a new recommendation artifact.

## Critique Targets

Critique the packages most likely to survive ranking, typically:

1. the highest-scoring package
2. the next strongest alternate
3. any package with a close score or a material trust-risk profile

Do not critique the whole space if a smaller top set is sufficient.

## Required Output

Write:

- `{docs.planning}/SOLUTION-CRITIQUE.md`

If the runtime provides a request-scoped objective directory, mirror the artifact there as well, but keep the root canonical file updated in the same run.

## Canonical Output Shape

`SOLUTION-CRITIQUE.md` should be operator-readable and should include, for each critiqued package:

1. the package being critiqued
2. the strongest argument against it
3. the hidden assumption most likely to break it
4. any trust, compliance, or reputation risk
5. any business-model conflict
6. the fastest way to invalidate it

## Critique Rules

1. Be specific about the failure mode.
2. Preserve the strongest objection, even if the package still looks good overall.
3. Do not soften the critique into generic caveats.
4. Do not invent replacement packages.
5. Do not reopen the package search or rewrite the scorecards.

## What Not To Do

- Do not write `{docs.tasks}/**`.
- Do not edit `SOLUTION-PACKAGES.json`.
- Do not edit `SOLUTION-SCORECARDS.json`.
- Do not produce `RECOMMENDED-SOLUTION.md`.
- Do not recommend a new package as a replacement.

## Handoff

When critique is complete, hand the critique to `scorpio-objective-synthesize`.