home / skills / athola / claude-night-market / war-room-checkpoint

war-room-checkpoint skill

/plugins/attune/skills/war-room-checkpoint

This skill assesses if a command warrants War Room escalation by computing a reversibility score and recommending express or full review.

npx playbooks add skill athola/claude-night-market --skill war-room-checkpoint

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
8.2 KB
---
name: war-room-checkpoint
description: "Inline reversibility assessment for embedded War Room escalation from commands. Use at decision points to determine escalation need. Skip for standalone strategic decisions."
# Custom metadata (not used by Claude for matching):
model_preference: claude-sonnet-4
category: strategic-planning
tags: [checkpoint, embedded, escalation, reversibility, inline]
dependencies:
  - attune:war-room
complexity: lightweight
estimated_tokens: 400
progressive_loading: false
---

# War Room Checkpoint Skill

Lightweight inline assessment for determining whether a decision point within a command warrants War Room escalation.

## Table of Contents

1. [Purpose](#purpose)
2. [When Commands Should Invoke This](#when-commands-should-invoke-this)
3. [Invocation Pattern](#invocation-pattern)
4. [Checkpoint Flow](#checkpoint-flow)
5. [Confidence Calculation](#confidence-calculation)
6. [Profile Thresholds](#profile-thresholds)
7. [Output Format](#output-format)
8. [Examples](#examples)

## Verification

Run `make test-checkpoint` to verify checkpoint logic works correctly after changes.

## Purpose

This skill is **not invoked directly by users**. It is called by other commands (e.g., `/do-issue`, `/pr-review`) at critical decision points to:

1. Calculate Reversibility Score (RS) for the current context
2. Determine if full War Room deliberation is needed
3. Return either a quick recommendation (express) or escalate to full War Room

## When Commands Should Invoke This

| Command | Trigger Conditions |
|---------|-------------------|
| `/do-issue` | 3+ issues, dependency conflicts, overlapping files |
| `/pr-review` | >3 blocking issues, architecture changes, ADR violations |
| `/architecture-review` | ADR violations, high coupling, boundary violations |
| `/fix-pr` | Major scope, conflicting reviewer feedback |

## Invocation Pattern

```markdown
Skill(attune:war-room-checkpoint) with context:
  - source_command: "{calling_command}"
  - decision_needed: "{human_readable_question}"
  - files_affected: [{list_of_files}]
  - issues_involved: [{issue_numbers}] (if applicable)
  - blocking_items: [{type, description}] (if applicable)
  - conflict_description: "{summary}" (if applicable)
  - profile: "default" | "startup" | "regulated" | "fast" | "cautious"
```

## Checkpoint Flow

### Step 1: Context Analysis

Analyze the provided context to extract:
- Scope of change (files, modules, services affected)
- Stakeholders impacted
- Conflict indicators
- Time pressure signals

### Step 2: Reversibility Assessment

Calculate RS using the 5-dimension framework:

| Dimension | Assessment Question |
|-----------|-------------------|
| Reversal Cost | How hard to undo this decision? |
| Time Lock-In | Does this crystallize immediately? |
| Blast Radius | How many components/people affected? |
| Information Loss | Does this close off future options? |
| Reputation Impact | Is this visible externally? |

Score each 1-5, calculate RS = Sum / 25.

### Step 3: Mode Selection

Apply profile thresholds to determine mode:

```
if RS <= profile.express_ceiling:
    mode = "express"
elif RS <= profile.lightweight_ceiling:
    mode = "lightweight"
elif RS <= profile.full_council_ceiling:
    mode = "full_council"
else:
    mode = "delphi"
```

### Step 4: Response Generation

#### Express Mode (RS <= threshold)

Return immediately with recommendation:

```yaml
response:
  should_escalate: false
  selected_mode: "express"
  reversibility_score: {rs}
  decision_type: "Type 2"
  recommendation: "{quick_recommendation}"
  rationale: "{brief_explanation}"
  confidence: 0.9
  requires_user_confirmation: false
```

#### Escalate Mode (RS > threshold)

Invoke full War Room and return results:

```yaml
response:
  should_escalate: true
  selected_mode: "{lightweight|full_council|delphi}"
  reversibility_score: {rs}
  decision_type: "{Type 1B|1A|1A+}"
  war_room_session_id: "{session_id}"
  orders: ["{order_1}", "{order_2}"]
  rationale: "{war_room_rationale}"
  confidence: {calculated_confidence}
  requires_user_confirmation: {true_if_confidence_low}
```

## Confidence Calculation

For escalated decisions, calculate confidence for auto-continue:

```
confidence = 1.0
- 0.10 * dissenting_view_count
- 0.20 if voting_margin < 0.3
- 0.15 if RS > 0.80
- 0.10 if novel_domain
- 0.10 if compound_decision
+ 0.20 if unanimous (cap at 1.0)

requires_user_confirmation = (confidence <= 0.8)
```

## Profile Thresholds

| Profile | Express | Lightweight | Full Council | Use Case |
|---------|---------|-------------|--------------|----------|
| default | 0.40 | 0.60 | 0.80 | Balanced |
| startup | 0.55 | 0.75 | 0.90 | Move fast |
| regulated | 0.25 | 0.45 | 0.65 | Compliance |
| fast | 0.50 | 0.70 | 0.90 | Speed priority |
| cautious | 0.30 | 0.50 | 0.70 | Higher stakes |

### Command-Specific Adjustments

| Command | Adjustment | Rationale |
|---------|-----------|-----------|
| do-issue (3+ issues) | -0.10 | Higher risk with multiple issues |
| pr-review (strict mode) | -0.15 | Strict mode = higher scrutiny |
| architecture-review | -0.05 | Architecture inherently consequential |

## Output Format

### For Calling Command

Return a structured response that the calling command can act on:

```markdown
## Checkpoint Response

**Source**: {source_command}
**Decision**: {decision_needed}

### Assessment
- **RS**: {reversibility_score} ({decision_type})
- **Mode**: {selected_mode}
- **Escalated**: {yes|no}

### Recommendation
{recommendation_or_orders}

### Control Flow
- **Confidence**: {confidence}
- **Auto-continue**: {yes|no}
{user_prompt_if_needed}
```

## Integration Notes

### Calling Commands Should

1. Check checkpoint response's `requires_user_confirmation`
2. If true: present confirmation prompt and wait
3. If false: continue with `orders` or `recommendation`
4. Log checkpoint to audit trail

### Failure Handling

If checkpoint invocation fails:
- Log warning with context
- Continue command execution without checkpoint
- Do NOT block the user's workflow

## Audit Trail

All checkpoints are logged to:
```
~/.claude/memory-palace/strategeion/checkpoints/{date}/{session-id}.yaml
```

## Examples

### Example 1: Low RS (Express)

**Input**:
```yaml
source_command: "do-issue"
decision_needed: "Execution order for issues #101, #102"
issues_involved: [101, 102]
files_affected: ["src/utils/helper.py", "tests/test_helper.py"]
```

**Assessment**:
- Reversal Cost: 1 (can revert commits)
- Time Lock-In: 1 (no deadline)
- Blast Radius: 1 (single utility module)
- Information Loss: 1 (all options preserved)
- Reputation Impact: 1 (internal)

**RS**: 0.20 (Type 2)

**Response**:
```yaml
should_escalate: false
selected_mode: "express"
recommendation: "Execute in parallel - no dependencies detected"
confidence: 0.95
requires_user_confirmation: false
```

### Example 2: High RS (Escalate)

**Input**:
```yaml
source_command: "pr-review"
decision_needed: "Review verdict for PR #456"
blocking_items:
  - {type: "architecture", description: "New service without ADR"}
  - {type: "breaking", description: "API contract change"}
  - {type: "security", description: "Auth flow modification"}
  - {type: "scope", description: "Unrelated payment refactor"}
files_affected: ["src/auth/", "src/api/", "src/payment/", "src/services/new/"]
```

**Assessment**:
- Reversal Cost: 4 (multi-service impact)
- Time Lock-In: 3 (PR deadline pressure)
- Blast Radius: 4 (cross-team impact)
- Information Loss: 3 (some paths closing)
- Reputation Impact: 2 (internal review)

**RS**: 0.64 (Type 1A)

**Response**:
```yaml
should_escalate: true
selected_mode: "full_council"
war_room_session_id: "war-room-20260125-143025"
orders:
  - "Split PR: auth changes separate from payment refactor"
  - "Require ADR for new service before merge"
  - "API change: add migration path, not blocking"
confidence: 0.75
requires_user_confirmation: true
```

## Related Skills

- `Skill(attune:war-room)` - Full War Room deliberation
- `Skill(attune:war-room)/modules/reversibility-assessment.md` - RS framework

## Related Commands

- `/attune:war-room` - Standalone War Room invocation
- `/do-issue` - Issue implementation (uses this checkpoint)
- `/pr-review` - PR review (uses this checkpoint)
- `/architecture-review` - Architecture review (uses this checkpoint)
- `/fix-pr` - PR fix (uses this checkpoint)

Overview

This skill performs a lightweight, inline reversibility assessment to decide whether a decision point within a command requires War Room escalation. It is intended to be called by other commands at critical decision junctures and returns either a quick recommendation or an escalation trigger. Use it to standardize escalation logic and reduce unnecessary full deliberations.

How this skill works

The skill analyzes supplied context (files affected, issues, blocking items, conflict summary, and profile) and scores reversibility across five dimensions: reversal cost, time lock-in, blast radius, information loss, and reputation impact. It normalizes the score to a Reversibility Score (RS), applies profile-specific thresholds, and selects a mode: express, lightweight, full_council, or delphi. For elevated RS values it initiates a War Room session and returns structured orders and confidence metrics.

When to use it

  • When a command reaches a decision point that might be hard to undo (e.g., PR merge, release action).
  • During automated flows like /do-issue, /pr-review, /architecture-review, or /fix-pr at designated checkpoints.
  • When multiple issues, cross-team impact, or conflicting reviewer feedback appear.
  • To gate actions under compliance or high-stakes profiles before proceeding.
  • When you need a reproducible, auditable escalation decision rather than ad hoc judgment.

Best practices

  • Invoke the checkpoint only at meaningful decision points to avoid noisy escalation.
  • Supply complete context: files_affected, issues_involved, blocking_items, conflict_description, and profile.
  • Respect requires_user_confirmation: pause flows when confidence is low.
  • Log checkpoint responses to the audit trail for postmortem and compliance.
  • Tune profile thresholds to match team risk appetite (startup vs regulated vs cautious).

Example use cases

  • A /pr-review detects architecture and breaking API changes and calls the checkpoint to decide escalation.
  • A bulk /do-issue job with 3+ issues runs the checkpoint to determine whether to proceed automatically.
  • An architecture-review flags ADR violations and uses the skill to mandate full council review.
  • A quick fix PR without broad impact runs express mode and continues without human confirmation.
  • A cross-service refactor yields high RS and triggers a delphi-mode War Room to produce orders.

FAQ

Can commands continue if checkpoint fails?

Yes. Failure handling logs a warning and allows the calling command to continue without blocking the workflow.

How is confidence computed for escalations?

Confidence starts at 1.0 and is reduced by dissenting views, low voting margin, high RS, novelty, and compound decisions; unanimous outcomes boost it, and requires_user_confirmation is set when confidence <= 0.8.