使用方法
- 复制安装命令,在自己的智能体环境安装前先检查源码包。
- 从原始文档核对所需工具、凭据和支持的宿主。
- 说明输入材料与期望交付物,并对照来源检查输出。
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]




