Proposal · Compound Engineering Plugin

# The `ce-pov` skill

A skill that gives you a decisive, repo-grounded point of view on an external question — at the start of a session, or dropped into the middle of one. A bare agent gives you an opinion; `ce-pov` gives you a verdict it had to earn, and refuses to fake one.

2026-06-28 topic: ce-pov-skill status: design proposal (rev 3 — converged) reviewed: Claude + Codex + Cursor (4 rounds)

The one rule that is the whole moat

It will not hand you a verdict it didn't earn against your actual repo. A generic `deep-research` skill already exists; the differentiator is never "research the web." It is the refusal to answer in the abstract. Verified external evidence and concrete repo evidence, or no verdict. Nothing else — not the conversation, not the user's own assertions — substitutes for that.

## What it is

One-liner: `ce-pov` forms a project-grounded point of view on something from the outside world. You bring an external input; it does real research and reads your own codebase, then returns a decisive, graded verdict for your project.

It is one primitive — "form a grounded POV on an external input" — with many mouths. The original motivating case (should we adopt framework X?) is one instance:

- "Should we adopt framework X here?" (adoption / build-vs-buy / migrate-off)
- "What should we use for auth?" (selection from a discoverable field — with a guard; see Boundaries)
- "Does this CVE / deprecation / breaking change actually affect us?"
- "Is this pattern from elsewhere right for us? Is our current approach dead?"
- "We rejected X 18 months ago — still the right call?"
- "Weigh in on the direction this brainstorm is heading." (mid-session second opinion)

## What we bring to the fight

Anyone can prompt their agent "what's your POV on X?" So the value is not capability — the agent has that. The value is a sharp, opinionated method, the same reason `ce-work` and `ce-plan` exist when an agent can already code and plan. A bare agent asked "should we use X?" fails in predictable ways; `ce-pov` is the method that counteracts each:

A bare prompt tends to… | `ce-pov` forces…
--- | ---
Answer in the abstract ("X is great") | Dual-grounding: cite a real dep / call-site / prior decision, or no verdict
Agree with your framing (pushover) | A skeptic stance: seek disconfirming evidence, name the alternatives, allow "no"
Stop at the first source; hallucinate citations | Active, verified research — the claim must be supported by the source
Evaluate the named thing in isolation | Name the incumbent and "do nothing" as real options
Give a wishy-washy "it depends" | A graded verdict + "yes, if <repo conditions>" (+ a reversal trigger on weighty calls)
Let the answer evaporate in chat | An optional durable record, so re-runs are cheap
Re-litigate what the team already decided | A precedent check before researching
Apply uniform effort to trivial and weighty calls | Rigor sized to reversibility

## The method (4 steps)

Four steps, deliberately few so the agent runs a judgment loop rather than performing an 8-item checklist. Two things are cross-cutting properties of every step, not phases of their own: the skeptic stance (seek disconfirming evidence; "no" and "not our problem" are first-class) and reversibility-tiered effort (how deep each step goes scales with the door type).

1

Frame. Pin the actual question, the incumbent, the time horizon, and what success looks like. Most "should we use X?" asks smuggle unstated assumptions ("replace auth" vs "greenfield sidecar"); without this the skill optimizes the wrong question elegantly. If the field of candidates can't be bounded or the decision criteria are unclear, stop and route out (see Boundaries) rather than turning into disguised requirements discovery.

2

Precedent. Check what we already decided — prior decision records, closed issues, past rejections. Update a known-good; don't re-litigate. (Precedent-aware, not rigidly first — a CVE's urgency can lead.)

3

Verify (external + project). The dual-grounded core. Active external research with the best tools available (built-in web search/fetch, or Exa / parallel-search / an MCP search server when present — never required), claims supported by their cited source; and concrete project grounding — deps, lockfile, license, call-site migration cost, conventions, git history, the named incumbent. Neither leg alone is enough.

4

Verdict. Emit the fixed verdict contract (next section): a grade from the defined vocabulary + "yes, if <repo-specific conditions>" + a next-step handoff. For Tier 2/3 (weighty/one-way) calls, add a reversal trigger ("adopt if volume < N; re-evaluate if enterprise SSO appears"); skip it on Tier 1 / CVE triage where it is formulaic noise. Durable record optional, recommended only for Tier 2/3 or precedent-changing decisions.

## The verdict contract

Two things make verdicts trustworthy and comparable: a fixed vocabulary and a fixed shape. Both are mandatory — the durable record and the Step-2 precedent search only work if past verdicts can be grepped and compared, which prose-only output defeats.

### Vocabulary — the grade is always one of:

Grade | Meaning
--- | ---
Adopt | Proven fit for us — use it.
Trial | Promising — use on a low-risk slice first; next step is a scoped spike.
Hold | A complete, valid decision to wait — promising but unstable, migration cost exceeds current pain, category moving too fast. Hold is a successful outcome, not a failure to finish. "Hold — insufficient grounding" is one subtype (the invalid-verdict escape when the project leg is too thin), not the only meaning of Hold.
Reject | Judged not worth it for us.
Not our problem | For exposure questions (CVE / deprecation) that don't reach us — avoids forced adopt/reject theater.

### Schema — every verdict carries these fields:

`Grade` · `Incumbent` · `Verified facts (repo + external)` · `Conversation hypotheses (unverified — warm only)` · `Conditions ("yes, if …")` · `Handoff (next skill)` · `Reversal trigger (Tier 2/3 only)`

The schema also enforces the provenance discipline structurally: "verified facts" and "conversation hypotheses" are separate fields, so an unverified chat claim can never quietly masquerade as grounding.

## One method, two contexts

`ce-pov` is one method with an invocation modifier — not two separate workflows. The same four steps run; what changes is where the question comes from and how much ceremony is warranted.

Same method, two entry contexts. Crucially, warm invocation takes only the question and claims to verify from the conversation — the grounding still comes from repo + verified external sources.

### Cold — session start

The user states an external question; the full method runs at the warranted tier. This is where the moat is thickest, because the repo grounding is automatable and hard to fake. Ship this rock-solid first.

### Warm — mid-session interjection

You want a second opinion mid-flow. The conversation supplies the question and the claims to verify — not grounding (see next section). Stay a guest: output a verdict block only, no reframing the session, hand control back. Be more adversarial than cold mode — the conversation's momentum pulls toward agreement, and a second opinion that rubber-stamps is worthless. When the question is absent or materially ambiguous, infer it and confirm before answering; when the user names it ("ce-pov: should we use X?"), skip the gate.

## Grounding provenance — the warm-mode safeguard

The sharpest risk surfaced in review: consensus laundering — twenty turns of the user and the agent mutually assuming "we must migrate off Postgres" quietly become "grounding," and `ce-pov` returns a confident verdict that ratifies chat fiction. The fix is to label every input by where it came from, and to let only verified buckets satisfy the verdict rule:

Bucket | Counts as grounding?
--- | ---
Observed repo facts | Yes
Verified external facts | Yes
Conversation claims | No — frame & hypotheses only, until corroborated
Assumptions needing confirmation | No — surfaced for the user to confirm/deny

Warm invocation adds no evidentiary weight: it surfaces hypotheses and framing, nothing more. If the conversation says "we have 40 call-sites on library X," the skill must `grep` before that counts. Same invalidation rule, no warm exemption. A verdict may use conversation claims to frame the decision, but cannot lean on them to satisfy dual-grounding unless corroborated or explicitly marked conditional.

## Two guardrails

Both reviewers independently flagged the same self-failure — form over substance — from opposite ends. Two guardrails, one for each end:

### Anti-theater — the Invalid-Verdict Rule

If the project-grounding leg is thinner than the external leg — can't name the incumbent + at least one concrete touchpoint, or a prior decision — the skill is forbidden from saying Adopt/Reject. It must return "Hold — insufficient project grounding" with a numbered list of what to inspect next. No verdict on vibes; the skill earns authority by refusing to pretend. (The provenance rule above is what stops warm mode from quietly evading this.)

### Anti-ritual — Reversibility-Tiered Effort

Bind effort and output length to the door type so it stays cheap enough to reach for casually. Tier 1 (reversible): one screen, 1–2 external + 1–2 repo facts, no reversal trigger. Tier 2 (moderate): fuller alternatives. Tier 3 (one-way / security / legal): deep research, precedent search, durable record. Otherwise it becomes a bureaucratic ritual and users go back to asking the model casually. The confirm-gate is held to the same standard — only when genuinely needed.

## Boundaries

The discriminator: `ce-pov` always takes an external input and judges it against your project, producing a decisive position — not options, not requirements, not implementation, not a diagnosis.

Neighbor | Theirs | The line
--- | --- | ---
generic `deep-research` | "Tell me about X" | `ce-pov` requires project grounding and ends in a graded verdict
`ce-ideate` | Invent options from an unbounded space | Invented vs. discovered: ideate invents; `ce-pov` judges/selects from a discoverable field
`ce-brainstorm` | Scope a chosen idea into requirements | `ce-pov` decides whether; brainstorm scopes what once it's a yes. No rollout sketching
`ce-plan` | How to build it | Verdict accepted → hand off. No task breakdown
`ce-debug` | Diagnose observed failing behavior | `ce-pov` assesses exposure and priority (is this CVE ours, how urgent); debug investigates an actual failure
`ce-strategy` | Product thesis / metrics | `ce-pov` is bounded to a specific external input, not company direction

The selection escape hatch (sharpened in review). "What should we use for auth?" is a `ce-pov` selection only when the candidate field is bounded (roughly ≤5 real options) and the decision criteria are knowable enough to judge. If the field can't be bounded without invention, or the criteria are unclear, `ce-pov` returns Hold → route to `ce-ideate` to enumerate (or `ce-brainstorm` to surface criteria), then re-run `ce-pov`. Without this, large/ambiguous fields (auth, observability, CI) tempt a divergent fan-out and the skill becomes disguised requirements discovery.

## What we don't build (v1)

The risk is boiling the ocean. Cut anything that turns a judgment skill into an implementation or governance system. Unanimous across reviewers:

- No PoC scaffolding; no scheduled re-evaluation engine
- No weighted-scoring spreadsheet (a one-line "considered: incumbent, X, Y; rejected Y because…" beats a matrix)
- No mandatory decision-record commit — offer it, keep it lightweight; many runs (CVE triage) are fine as a chat verdict
- No deep git archaeology (cap at ~15-min-equivalent effort); no exhaustive market map
- No required multi-agent research fan-out
- No three-mode taxonomy in the skill instructions — one method, one invocation modifier

The standard is "enough verified evidence for the decision class," not a research report.

## Universal mode (designed-in, deferred to a later version)

"Repo grounding" is a special case of grounding in the asker's real situation, so the method is portable beyond code (e.g. "should our company use vendor Y?", "should I adopt this productivity system?") with the grounding leg adaptive: repo when there is one, user-supplied context otherwise. That is real and consistent with how `ce-ideate` / `ce-brainstorm` / `ce-plan` generalize.

Decision for v1: ship repo/project-first; treat universal as a caveat, not a headline. Reviewers were unanimous that universal mode broadens surface area, weakens the moat (the automatable grounding largely vanishes, drifting toward method-only deep-research), and invites fuzzy life/business advice under the same brand. The portable method stays in the design; v1 is explicitly optimized for code/project contexts, with "works outside a repo when enough concrete context exists" as a noted capability to prove out before promoting. (This sequencing is the one item flagged for the owner's confirmation.)

## The name

`ce-pov` — it names the deliverable (a point of view) in the user's own words, signals a position (not a report), and carries the full breadth (a POV on any question). It earns its keep most in the warm "weigh in / second opinion" posture, which is unmistakably "give me your POV," never "check if it fits."

Rejected alternatives: `ce-research` (collides with the generic `deep-research` skill and signals open-ended exploration, the opposite of a verdict); `ce-fit` / `ce-fit-check` (too narrow — "fit" is one criterion the skill weighs, not the act; it shrinks a judgment skill into a compatibility check). If a sharper signal of "grounded judgment" is wanted later without narrowing, `ce-stance` and `ce-verdict` are the closest siblings.

## External review (Codex + Cursor, four rounds)

Two independent models reviewed across four rounds and converged. At round 4 both returned "ship it — no blocker"; their two final additions (a defined Hold-inclusive verdict vocabulary, and a fixed verdict schema) are folded into The verdict contract. Round-3 changes:

- Fixed the central contradiction: warm mode no longer treats the conversation as grounding — only as question + claims-to-verify — closing the "consensus laundering" hole both flagged. Added the grounding-provenance buckets.
- Collapsed 7 steps → 4; skeptic stance and reversibility tiering are now cross-cutting properties, and the two postures are one method + an invocation modifier (was a three-mode taxonomy reviewers warned agents would overfit).
- Tier-gated the reversal trigger (Tier 2/3 only) and the durable record.
- Narrowed the confirm-gate to absent/ambiguous questions.
- Added the selection escape hatch (unbounded field / unclear criteria → Hold → ideate/brainstorm → re-run).
- Deferred universal mode to repo-first per unanimous advice.
- Earlier rounds established: dual-grounding as the #1 move, the two guardrails, "frame the decision first", incumbent inventory, and "not our problem" as a first-class verdict.

## Open questions / next steps

- Where does the optional durable record live — a new `docs/decisions/` (ADR-style) path, or fold into `docs/solutions/`? Needs a slug/index convention so the precedent check (Step 2) can find prior verdicts.
- Should the precedent check and the verified-citation pass be shared persona assets, given the existing research-persona duplication across skills (the `web-researcher.md` copies have already drifted)? Likely a shared evidence/verdict output contract rather than a shared file, per the plugin's self-contained-skill constraint.
- Confirm the v1 repo-first / universal-deferred scoping (owner decision).
- Hand off to `ce-brainstorm` to turn this proposal into a requirements-only unified plan when ready to build.