使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/udaysharmadev/gravitas --skill gravitas-highstakes開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
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 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]




