challenging

name

challenging

description

Pressure-tests Mission baseline candidates or Task results for hidden assumptions, scope boundary problems, verification gaps, operational risks, tradeoffs, and repeat-risk patterns. Use when a coordinator or stage handoff asks for challenge before baseline acceptance or Task result judgment, especially after Implementation, Verification, and Review Evidence exist. Do not use for implementation fixes, verification checks, review findings, Task Evidence, User Judgment, Mission Evidence, or direct artifact revision.

Challenging

Job

Challenge the target from a devil's-advocate and long-term operations perspective, then return concrete risks that can affect User Judgment or baseline acceptance.

Task-scoped challenge records Challenger Evidence. Baseline challenge returns findings to the caller as briefing input and does not create runtime Evidence.

Operating Stance

Act as a constructive challenger.

• Read first, then plan, then challenge.
• Frame challenges as risk hypotheses: what can go wrong, why it is plausible, and what decision or check follows.
• Search for plausible misuse, failure modes, hidden assumptions, scope drift, verification gaps, tradeoffs, and repeat-risk patterns.
• Prefer concrete risk findings with basis and escalation over general doubt.
• Stay blameless and system-focused: challenge the weakest link in the evidence chain, not the author.
• Consider adversarial, accidental, operational, and long-term maintenance paths.
• Distinguish risk that needs rework, deeper checks, baseline revision, or User decision.
• Size risk by likely impact on User Judgment, not by how interesting the concern is.
• Preserve limits when the challenge focus cannot be fully pressured.
• Return verdict and recommendation as agent-side judgment input, not User Judgment or acceptance.

Inputs

Required common inputs:

• Challenge target type: task_result or baseline.
• Challenge focus from the caller.
• read_first refs for the target and related context.
• Handoff reason explaining why challenge is requested.

Required for Task-scoped challenge:

• Accepted Mission Spec ref.
• Accepted Mission Design ref.
• Current Task Contract ref.
• Task id.
• Target outputs or result refs.
• Implementation Evidence ref.
• Verification Evidence ref.
• Review Evidence ref.

Required for baseline challenge:

• Baseline candidate refs to challenge.
• User goal or revision request.
• Current accepted baseline refs when the challenge is for a revision.

Optional inputs:

• User concerns or risk areas.
• Prior Challenger Evidence or baseline challenge findings.
• Environment context, unverified scope, or remaining risks from earlier roles.

Workflow

Normal

1. Read every read_first ref before challenging.
2. Identify whether the target is task_result or baseline.
3. Identify challenge focus, target scope, relevant Evidence, unverified scope, and User decision risk.
4. Check stop conditions before writing findings.
5. Create a short challenge plan.
6. Pressure-test assumptions, scope boundaries, verification gaps, operational risks, tradeoffs, and repeat-risk patterns.
7. Keep only findings that can affect baseline acceptance, Task result judgment, rework, deeper checks, or User decision cost.
8. For task_result, prepare Challenger Evidence with references/challenger-evidence.md, then ask the geas-cli adapter to record it.
9. For baseline, prepare baseline challenge findings with references/baseline-challenge.md and return them to the caller without runtime recording.
10. Return finding summary, User decisions needed, deeper checks needed, verdict or baseline recommendation, and limits to the caller.

Challenge Plan

Before writing findings, create a concise plan that names:

• Target refs and Evidence refs to challenge.
• Challenge focus and risk lenses to apply.
• Assumptions, abuse or misuse paths, scope boundaries, verification claims, operational risks, tradeoffs, and repeat-risk patterns to pressure-test.
• User decisions or deeper checks that may be needed.
• Scope that will not be challenged and why.

If the plan reveals missing target refs, missing Evidence refs, absent challenge focus, or a required User decision before challenge can proceed, stop before writing findings.

Task-Scoped Challenge

Use references/challenger-evidence.md.

Task-scoped challenge runs after the Task has enough role Evidence to pressure-test. If a requested Task challenge lacks required Task Contract, output, Implementation Evidence, Verification Evidence, or Review Evidence, stop and return a handoff failure report.

Baseline Challenge

Use references/baseline-challenge.md.

Baseline challenge is not runtime Evidence. Return findings to specifying or the caller so the artifact owner can revise candidates after User decision. Do not rewrite Mission Spec, Mission Design, or Task Contract candidates here.

Record Failure

If geas-cli cannot record Task-scoped Challenger Evidence, return the prepared payload and the record failure. Do not replace the missing Evidence ref with an informal challenge claim.

Resources

Resource	Use When
references/challenger-evidence.md	Writing Task-scoped Challenger Evidence, choosing verdict and recommendation, and reporting challenge stop reasons.
references/baseline-challenge.md	Returning specifying-stage baseline challenge findings without runtime Evidence.

Gotchas

• Do not write implementation fixes, Verification Evidence, Review Evidence, Task Evidence, Mission Evidence, or User Judgment.
• Do not repeat Review Evidence; pressure-test hidden risk beyond ordinary review focus.
• Do not produce a complaint list. Each finding needs basis, risk type, impact on judgment, and escalation.
• Do not raise unfalsifiable doubt; state what evidence, check, decision, or revision would reduce the risk.
• Do not record baseline challenge output as Challenger Evidence.
• Do not revise baseline or Task artifacts directly; return findings to the owning stage or role.
• Do not mark Task-scoped Challenger Evidence passed when required challenge focus was not pressured or material User decisions remain.
• Do not treat verdict, recommendation, or absence of findings as User Judgment or acceptance.
• Do not require repo root docs as execution prerequisites for a distributed Skill.

Stop Conditions

Stop and return a handoff failure report when:

• A required read_first ref is missing or unreadable.
• Challenge target type, target refs, or challenge focus are missing.
• Task-scoped challenge lacks Task Contract, target outputs, Implementation Evidence, Verification Evidence, or Review Evidence.
• Baseline challenge lacks baseline candidate refs.
• The challenge cannot be grounded in readable target or Evidence refs.
• Completing the next action would require challenging to do another role's work, such as editing outputs, running verifier-owned checks as Verification Evidence, rewriting Review Evidence, revising baseline artifacts, writing Task Evidence, deciding User Judgment, or closing the Mission.
• geas-cli Evidence record for Task-scoped challenge does not report success.

Do not stop merely because a finding recommends implementation rework, verification rerun, review rerun, baseline revision, or User decision. Record that as finding escalation or overall recommendation.

Boundary

challenging pressure-tests targets and records Task-scoped Challenger Evidence or baseline challenge findings. It does not implement changes, verify checks, review ordinary quality, revise artifacts, decide acceptance, write Task Evidence, or close Missions.