CtrlK
BlogDocsLog inGet started
Tessl Logo

abort-template

Abort / crisis plan generator — halt triggers, response actions, AI-aware safety gates (hallucination threshold, destructive-action gate, output validation).

73

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Abort / Crisis Plan Generator

The abort plan defines when the agent stops. Without it, the autonomous loop runs through real-incident alerts, scope violations, and production-data exposures as if they were normal operations.

AI-specific gates address the failure modes documented in OWASP Top 10 for Agentic Applications (2025.12) — hallucination, prompt injection, unverified destructive actions.

When to Use

  • After CONOPS + Threat Profile + Data Handling are written (the kill chain shapes which triggers are relevant)
  • User says "create abort plan", "halt triggers", "emergency stop", "safety gates"

Workflow

Step 1: Keep the Three Default Triggers

The AbortPlan schema seeds three default halt triggers. Keep all three; do not remove unless the engagement is explicitly read-only:

  1. EMERGENCY — Real-incident alert from blue team / SOC
  2. CRITICAL — Production data observed in collected evidence
  3. CRITICAL — Scope boundary violation detected

Step 2: Add Engagement-Specific Triggers

Based on the interview answers, add custom AbortTrigger entries. Common additions:

Engagement signalSeverityResponse
Tier-3+ adversary emulation against critical infrastructureEMERGENCYHalt + operator-page + 1hr cooldown
Compliance-bound data class encountered (GDPR / HIPAA)CRITICALHalt; redact; await operator
Network outage or latency spike on targetWARNINGPause active scanning; resume after 5min
LLM cost-per-objective threshold exceededWARNINGPause; ask operator to approve budget
C2 beacon lost for > 30 minutes during active phaseWARNINGPause; re-establish C2 before continuing

Step 3: Set AI Safety Gates

  • hallucination_threshold — default 3 (after 3 unverified-success claims, force evidence-collection mode). Lower (2) for high-stakes engagements; never set 0.
  • destructive_action_gate — default True. Set False only for read-only / recon-only engagements where no rm, drop, format, delete-policy commands will run.
  • output_validation — default "verify-evidence-hash". Override to "second-tool-confirm" for engagements where evidence cannot be hashed (e.g. real-time API responses).

Step 4: Set Abort Signal Channel + Recovery Procedure

  • abort_signal_channel — operator's out-of-band channel for forcing halt (HTTP endpoint, file marker, ask_user_question). Leave empty only if Ctrl+C-via-CLI is the only abort path.
  • recovery_procedure — default text covers the standard flow (snapshot → export evidence → run cleanup → operator approval). Override for engagements with custom recovery semantics.

Validation Checklist

Before writing plan/abort.json:

  • At least one EMERGENCY-severity trigger exists
  • All custom triggers have non-empty condition and response_action
  • hallucination_threshold ≥ 1
  • output_validation matches one of the documented methods
  • abort_signal_channel is set OR explicitly marked "CLI Ctrl+C only"

Anti-patterns

  • Removing the EMERGENCY default — guarantees the agent runs through a SOC real-incident alert
  • Setting destructive_action_gate=False for engagements that include post-exploit or cleanup phases
  • Conflating WARNING and CRITICAL — WARNING pauses one step; CRITICAL halts the active objective

Output

Write to plan/abort.json validating against decepticon.core.schemas.AbortPlan.

Repository
PurpleAILAB/Decepticon
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.