mcpField
G
gravitas-highstakes

gravitas-highstakes

github.com/udaysharmadevAgent workflows384285 installsUpdated today
Repository

About gravitas-highstakes

GRAVITAS High-Stakes is a skill for agents handling hard-to-reverse, high-stakes actions. It requires risk classification, an adversarial review of the plan, available dry runs, and explicit user confirmation before execution.

Key features

  1. 01Classifies high-stakes actions
  2. 02Requires a numbered change plan
  3. 03Adds adversarial plan critique
  4. 04Runs available dry-run checks
  5. 05Waits for explicit user approval
  6. 06Stops on execution or verification failures

Use cases

  1. 01Prepare an irreversible database migration
  2. 02Review and validate a risky configuration change
  3. 03Require approval before deployment actions
  4. 04Halt a change when validation fails

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/udaysharmadev/gravitas --skill gravitas-highstakes

After installing, type/gravitas-highstakesin Claude Code to confirm it loaded.

Details

From the project README

GRAVITAS High-Stakes Skill

For Tier-2 actions (hard-to-reverse, high-stakes), follow this skill in addition to the standard GRAVITAS cognitive loop. This skill enforces explicit user checkpoints.

Steps

1. State the Change and Tier Classification

Before doing anything, explicitly state:

  • What you plan to change (specific files, tables, configs)
  • Why this is Tier 2 (what makes it hard to reverse)
  • What could go wrong

Format:

This is a Tier-2 action because: [reason]
Plan:
  1. [specific step]
  2. [specific step]
  ...
Risk: [what could break]
2. Present the Plan + Adversarial Critique

Run the full Pillar 2 process:

  • Write the numbered plan
  • Run the adversarial critique (separate reasoning pass)
  • Revise the plan based on critique
  • Present the revised plan to the user
3. Dry Run (if available)

If a dry-run, lint, test, or validation command is available for this type of change, run it now:

# turbo — auto-approved, no user confirmation needed for this step

Examples:

  • Database migration: --dry-run flag
  • Config change: schema validation
  • Code change: type check + lint
  • Deployment: preview environment
4. STOP — Wait for Explicit User Confirmation

Do not execute the plan yet. Present the plan and ask for confirmation:

I've completed the reconnaissance, plan, and adversarial critique.
This is a Tier-2 (irreversible/high-stakes) action.

[Show the plan]

Do you want me to proceed with this plan? Please confirm explicitly.

Wait for the user's response. Do not proceed until they confirm.

5. Execute the Confirmed Plan

Only after explicit confirmation:

  1. Execute each step in the plan
  2. After each step, verify it succeeded
  3. If any step fails, stop immediately — do not continue with the plan
6. Re-Verify After Execution

After all steps complete:

  1. Run any available post-change verification
  2. Re-read the changed files to confirm edits landed
  3. If applicable, run the full test suite

Report back with:

  • What was changed
  • Evidence it's working
  • Any concerns or follow-ups

Abort Conditions

Stop the skill and report to the user if:

  • A dry-run reveals unexpected side effects
  • The plan needs to change mid-execution
  • A verification step fails
  • The user requests changes to the plan at any point

Example: Database Migration

This is a Tier-2 action because: schema changes are irreversible once applied.

Plan:
  1. Create migration file: ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT false
  2. Run migration against dev database
  3. Update ORM model to include new column
  4. Add NOT NULL constraint after backfill (separate migration)

Risk: If the backfill is incomplete, the NOT NULL constraint will fail.
      If the migration runs in production prematurely, it could lock the table.

Dry run: psql --dry-run (or migration tool's dry-run flag)

[Wait for user confirmation]

[Execute and verify]

Comments

Markdown supported