agentleFS
faizaniofaizanio/FORGE/skills/forge-highstakes/SKILL.md

forge-highstakes

Skill0 starsChanged 12 days agoMITView on GitHub

Mandatory checkpoint skill for irreversible/high-stakes changes (schema migrations, file deletion, auth/security changes, production config, force-pushes). Use when a task risks hard-to-reverse damage.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 13 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈13

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before doing anything, explicitly state:

    line 22
  2. Distinctive:

    Run the full Pillar 2 process:

    line 39
  3. Distinctive:

    Write the numbered plan

    line 40
  4. Distinctive:

    Run the adversarial critique (separate reasoning pass)

    line 41
  5. Distinctive:

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

    line 47
  6. Distinctive:

    Wait for the user's response.

    line 73
  7. Distinctive:

    Only after explicit confirmation:

    line 77
  8. Distinctive:

    After each step, verify it succeeded

    line 79
  9. Distinctive:

    If any step fails, stop immediately — do not continue with the plan

    line 80
  10. Distinctive:

    After all steps complete:

    line 84
  11. Distinctive:

    Run any available post-change verification

    line 85
  12. Distinctive:

    If applicable, run the full test suite

    line 87
  13. Distinctive:

    Stop the skill and report to the user if:

    line 98

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Forge High-Stakes Skill

For Tier-2 actions (hard-to-reverse, high-stakes), follow this skill in addition to the standard Forge 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]

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.