critique-problem-framing

name	critique-problem-framing
description	Audit an incoming problem statement, feature brief, or requirements draft before domain modeling or architecture work. Use when Codex needs a structured pre-design review that surfaces weak assumptions, contradictions, scope gaps, missing constraints, hidden risks, and unanswered questions. Do not use for architecture design, contract design, or implementation.

Critique Problem Framing

Goal

Stress-test the framing before design starts. Produce one reusable artifact that separates facts, assumptions, contradictions, missing inputs, and a corrected framing that later skills can consume.

Read Shared Contract Reference before producing the artifact.

Trigger boundary

• Use for pre-design critique of a brief, problem statement, or requirements draft.
• Do not use for domain modeling, architecture design, interface contracts, slice planning, or code changes.

Required input

• Required: brief or problem statement
• Optional: notes, existing docs, scope constraints, out-of-scope list, critical use cases, technology preferences, legacy behavior, policy constraints

Refusal and blocked policy

• Return BLOCKED when there is no concrete problem statement to critique.
• Return BLOCKED when the request is actually to design architecture, contracts, or code rather than critique framing.
• Ask only for inputs that block correct framing.
• Record non-blocking uncertainty under assumptions or open_questions.
• Do not invent architecture, contracts, or implementation details to cover missing product information.

Workflow

1. Restate the requested outcome in plain language.
2. Extract explicit goals, actors, scope, success conditions, and constraints.
3. Separate stated facts from inferred assumptions.
4. Assign ISSUE-* identifiers to contradictions, ambiguities, and missing required inputs.
5. Identify contradictions, overloaded terms, missing constraints, and scope leakage.
6. Call out risks only when they follow from framing defects.
7. Rewrite the brief into a tighter, implementation-ready framing without designing the solution.

Output contract

Write problem-framing-review.md or return equivalent Markdown using this structure:

# Problem Framing Review

## Artifact Metadata
- artifact_id:
- artifact_type: problem-framing-review
- artifact_status: draft | current | superseded
- approval_status: pending_review | approved | changes_required | rejected
- approved_by_gate_profile: none | problem-framing
- gate_report_ref: none | <ref>
- upstream_artifact_refs:

## Review Outcome
- review_outcome: usable | risky | blocked
- recommended_next_stage: critique-problem-framing | extract-domain-model | ask-user

## Problem Summary
...

## Stated Facts
- fact:
- evidence_source:
- evidence_excerpt_or_reference:

## Assumptions To Validate
- issue_id: ISSUE-*
- severity: low | medium | high
- assumption:
  evidence_source:
  evidence_excerpt_or_reference:
  why_it_matters:

## Contradictions And Ambiguities
- issue_id: ISSUE-*
- severity: medium | high
- blocking: true | false
- issue:
  evidence_source:
  evidence_excerpt_or_reference:
  impact:

## Missing Constraints
- issue_id: ISSUE-*
- severity: medium | high
- blocking: true | false
- missing_input:
  evidence_source:
  evidence_excerpt_or_reference:
  why_blocking_or_risky:

## Missing Required Inputs
- issue_id: ISSUE-*
- missing_required_input:
- evidence_source:
- evidence_excerpt_or_reference:
- why_blocking:

## Risks Introduced By Current Framing
- issue_id: ISSUE-*
- severity: low | medium | high
- risk:
  trigger:
  downstream_effect:

## Corrected Framing
- goal:
- in_scope:
- out_of_scope:
- success_conditions:
- constraints:

## Open Questions
- ...

## Recommended Next Input
- ...

Quality bar

• Tie every issue to evidence and downstream impact.
• Improve the framing instead of solutioning the system.
• Preserve user intent while tightening wording and scope.
• Keep the artifact short when the brief is already strong.
• Mark an issue as blocking only when it prevents reliable downstream modeling.
• Initialize artifact metadata with approval_status: pending_review until a gate or explicit approver marks it otherwise.