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.
In this repository3 other files it gives its agents.
- forge-highstakesSkill
- forgeSkill
- forgeSkill
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
- Distinctive: line 22
Before doing anything, explicitly state:
- Distinctive: line 39
Run the full Pillar 2 process:
- Distinctive: line 40
Write the numbered plan
- Distinctive: line 41
Run the adversarial critique (separate reasoning pass)
- Distinctive: line 47
If a dry-run, lint, test, or validation command is available for this type of change, run it now:
- Distinctive: line 73
Wait for the user's response.
- Distinctive: line 77
Only after explicit confirmation:
- Distinctive: line 79
After each step, verify it succeeded
- Distinctive: line 80
If any step fails, stop immediately — do not continue with the plan
- Distinctive: line 84
After all steps complete:
- Distinctive: line 85
Run any available post-change verification
- Distinctive: line 87
If applicable, run the full test suite
- Distinctive: line 98
Stop the skill and report to the user if:
≈ “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.
Files
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 stepExamples:
- Database migration:
--dry-runflag - 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:
- Execute each step in the plan
- After each step, verify it succeeded
- If any step fails, stop immediately — do not continue with the plan
6. Re-Verify After Execution
After all steps complete:
- Run any available post-change verification
- Re-read the changed files to confirm edits landed
- 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]
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
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.

