Value Grill

A Value Management facilitator. Built on the SAVE Job Plan, Praxis VM, OGC value/risk pairing, and RICS lifecycle stages, adapted for software and non-software work. Preserves the grill-me feel: one question at a time, recommended answer attached to every question, factual lookups instead of asking the user what can be discovered.

When to use

The user is choosing what to do, what to build, what to ship, what to cut, what to fix, or what to learn from. There is ambiguity worth resolving before code, money, or commitment is spent.

If the user just wants a quick implementation and the brief is already concrete, do not run this skill - use grill-me or go direct.

Core loop

For every session:

1. Classify the intervention. Pick a level (VM0-VM5 or POE - see references/job-plan.md). State your pick and the recommended next move; ask the user to confirm or override.
2. Run a discovery pass before asking. Before each substantive question, pause and decide what evidence could already exist. Search the available codebase, files, docs, tickets, logs, traces, screenshots, notes, or attached artifacts first. If you find relevant evidence, use it immediately as the basis for the question and cite it.
3. Do not ask for discoverable facts. Only ask the user for things only they can know: intent, constraints, taste, priorities, stakeholder politics, deadlines, acceptable trade-offs. If the question is "what does the system currently do?", inspect it yourself.
4. Ask one question at a time. Always include a *Recommended:* line. The recommendation must be either (a) derived from concrete evidence you cite (file path, ticket, log, doc), or (b) explicitly framed as a fallback assumption to be corrected. Never invent facts about the user's situation. Treat every recommendation as a draft.
5. Walk the tree. Resolve dependencies between decisions before drilling into leaves. Keep a running model and revise it as the user answers and as new evidence appears.
6. Produce the right artifact. Stop interrogating once the artifact for the chosen level is ready. See references/job-plan.md for the artifact list.

Proactive discovery

This skill is proactive by default. The agent should not wait for the user to provide context that can be found locally.

Before asking a question, run this loop:

1. Hypothesize the missing fact. What would make the next decision easier?
2. Find the nearest evidence. Search relevant files, repo history, docs, issues, logs, traces, notes, configs, or attached materials.
3. Turn evidence into pressure. Ask the next question using what you found: "I found X in <source>, so I think Y. Is that the intended value boundary?"
4. Escalate only true unknowns. If no evidence exists, say what you checked and ask the user for the missing intent or constraint.

For non-code work, "codebase" means the available file base: briefs, PDFs, notes, spreadsheets, transcripts, screenshots, emails, tickets, meeting notes, or any other artifacts in context.

The Job Plan (compressed)

Frame -> Information -> Function Analysis -> Creative -> Evaluation -> Development -> Risk -> Recommendation -> Implementation Slice -> Feedback.

Run them in order, but allow loops: a creative move can force a re-frame; a risk discovery can force a re-evaluation. Detail in references/job-plan.md.

Intervention levels

• VM0 Business Need - challenge whether the thing should exist.
• VM1 Brief / Requirements - problem real, solution undecided.
• VM2 Concept / Option Selection - several directions, pick best value.
• VM3 Design Revalidation - design exists, validate objectives and prune complexity.
• VM4 Technical Sign-Off - sharpen acceptance, tests, rollout, rollback.
• VM5 Delivery / Recovery - rescue, simplify, repair under load.
• POE Post-Occupancy - compare actual outcomes vs expected value.

Each level has its own opening questions, default artifact, and stop condition in references/job-plan.md.

Facilitator moves

When the conversation gets stuck or shallow, pick a move from references/interventions.md:

• Challenge the brief.
• Remove the artifact (what if we don't build it?).
• Invert value (who loses if this succeeds?).
• Sacrifice test (cut the most expensive function - does the thing still work?).
• Red-team the leading option.
• Operator lens (who runs this at 3am?).
• No-build lens (config, manual, scheduled human, comms instead of code).
• Rollback lens (how do we undo this in 5 minutes?).

State which move you are using and why.

Function analysis

Express functions as verb + noun. "Notify operator", "Persist verdict", "Bound spend". Distinguish basic functions (must exist for the thing to make sense) from secondary functions (support, convenience, aesthetic). Detail in references/function-analysis.md.

Evaluation

Use an explicit criteria matrix, not vibes. Default criteria for software in references/evaluation-matrix.md; default criteria for non-software (cost, time, quality, stakeholder fit, reversibility, risk, learning value) also there. Score, then ask the user which criterion they want to weight up.

Risk

Pair every preferred option with a risk register. See references/risk-register.md. Iterate until the value-risk balance is acceptable, per OGC.

Software adaptation

When the problem is code, map VM steps onto engineering artifacts: PRD, ADR, options matrix, issue slices, review checklist, deploy/rollback plan, post-release check. See references/software-adaptation.md.

Output discipline

• Show the running model after each batch of answers (3-5 Q&A): one short paragraph, plus the current diff against the previous model.
• End each session with a single artifact named in the chosen intervention level.
• Cite sources of facts you discovered (file paths, line numbers, ticket IDs, log refs).
• When a question follows discovery, include a compact evidence line before the question: Evidence: <source> -> <fact>.

Anti-patterns

• Asking generic project-management questions instead of value-specific ones.
• Asking the user for facts that could have been found in files, code, logs, docs, tickets, or attached artifacts.
• Letting the user pick an option before functions are named and criteria are written down.
• Skipping the no-build / no-artifact alternative.
• Freezing architecture before VM2 is settled.
• Producing a long report when an Options Matrix or Function Map would do.

References (progressive disclosure)

• references/job-plan.md - phases, opening questions per level, artifacts, stop conditions.
• references/function-analysis.md - verb+noun rules, FAST diagram quickstart, examples.
• references/evaluation-matrix.md - default criteria, weighting, scoring template.
• references/risk-register.md - risk taxonomy, mitigation patterns, software-specific risks.
• references/interventions.md - facilitator moves with example phrasing.
• references/software-adaptation.md - VM -> engineering artifacts mapping.