--- name: intent-recognition description: "Use BEFORE any tool call that could modify state, touch sensitive targets, rewrite history, install dependencies, publish packages, or expose credentials/environment data. Classifies intent into Passive/Read, Reconnaissance, Modification, or Destructive/Irreversible using operation type plus target sensitivity, then runs Identify / Confirm / Verify before action. Do NOT use for deciding what code to write, executing already-classified work, reactive post-execution guardrails, or defining upstream governance policy." license: MIT compatibility: "Runtime-agnostic. The four-tier classification, target-content rule, and Identify/Confirm/Verify sequence apply to any agent harness with tool execution — Claude Code, OpenCode, Cursor, Aider, Copilot Workspace, custom MCP-based agents, or any LLM with shell access." allowed-tools: Read Grep metadata: schema_version: "4" version: "1.0.0" type: capability category: engineering domain: ai-engineering/safety scope: portable owner: skill-graph-maintainer freshness: "2026-05-06" drift_check: "{\"last_verified\":\"2026-05-06\"}" eval_artifacts: planned eval_state: unverified routing_eval: absent stability: experimental keywords: "[\"intent recognition\",\"pre-execution risk classification\",\"four tier action taxonomy\",\"passive read reconnaissance modification destructive\",\"identify confirm verify sequence\",\"destructive operation classification\",\"credential read is reconnaissance\",\"git reset hard is destructive\",\"force push is destructive\",\"lockfile install is high impact\",\"non-destructive alternative\",\"agent action risk assessment\",\"tool call pre-execution gate\",\"reading dotenv is not passive\",\"history rewriting is irreversible\",\"state-changing tool call\",\"agent safety pre-execution\",\"target content elevates tier\"]" examples: "[\"the agent is about to run `git reset --hard` — what tier is this and what's the safer alternative?\",\"is reading the `.env` file a Passive operation since nothing mutates?\",\"I'm about to install a new package — what tier does that fit and why?\",\"force-push to main looks like 'just a push' — should I classify it as Modification?\",\"before running `DELETE FROM orders WHERE …`, what's the verification sequence?\",\"the agent classified everything as Modification because there's no exception for credentials\",\"what trigger phrases should activate this skill in our harness?\"]" anti_examples: "[\"design the deterministic safety hook that blocks destructive commands\",\"decide whether to use a switch or a chain of ifs\",\"actually execute the migration after we've classified the risk\",\"scan this repo for OWASP top 10 vulnerabilities\",\"review this AI-generated PR for correctness\",\"the loop is stalling — what's the steering signal\"]" relations: "{\"boundary\":[{\"skill\":\"owasp-security\",\"reason\":\"owasp-security is a domain audit against a known threat list; intent-recognition is the per-action risk classification that runs immediately before a tool call regardless of domain\"},{\"skill\":\"debugging\",\"reason\":\"debugging investigates a failure that has already happened; intent-recognition prevents one class of failure (destructive action mis-classification) from happening at all\"},{\"skill\":\"code-review\",\"reason\":\"code-review evaluates code-quality of an artefact; intent-recognition evaluates risk of an action about to be performed by a tool\"},{\"skill\":\"version-control\",\"reason\":\"version-control owns the discipline of using git well; intent-recognition specifically classifies which git commands are safe vs destructive at the moment of execution\"},{\"skill\":\"testing-strategy\",\"reason\":\"testing-strategy decides what to test proactively; intent-recognition gates one specific tool call from firing without classification\"}],\"related\":[\"owasp-security\",\"version-control\",\"debugging\"],\"verify_with\":[\"owasp-security\"]}" portability: "{\"readiness\":\"scripted\",\"targets\":[\"skill-md\"]}" lifecycle: "{\"stale_after_days\":365,\"review_cadence\":\"quarterly\"}" skill_graph_source_repo: "https://github.com/jacob-balslev/skill-graph" skill_graph_protocol: Skill Metadata Protocol v3 skill_graph_project: Skill Graph skill_graph_canonical_skill: skills/intent-recognition/SKILL.md --- # Intent Recognition ## Coverage Pre-execution action classification for any agent that can call tools with side effects. Defines four tiers — Passive/Read, Reconnaissance, Modification, Destructive/Irreversible — with the operation-and-target rule that determines tier (the target's sensitivity can elevate the tier above what the operation alone implies; reading a `.env` file is Reconnaissance even though no state changes). Specifies the three-step verification sequence (Identify the action and its tier, Confirm the rationale against the active plan, Verify whether a non-destructive alternative exists) that runs before any tier-3 or tier-4 action fires. Names the trigger phrases that should activate the skill. Catalogs the anti-patterns: classifying credential reads as Passive, treating package installs as Passive, skipping classification for familiar commands, classifying force-push as Modification, proceeding with Destructive actions without checking alternatives. ## Philosophy Agents execute tool calls at machine speed with no undo. Without an explicit pre-execution classification step, `git reset --hard` runs with the same ease as `cat README.md`. The cost of a single misclassified destructive action — wiped uncommitted work, dropped database, force-pushed branch — exceeds the cost of _every_ classification step the agent will ever run. The math is simple: classification is cheap, regret is expensive. The most subtle failure mode is _target-content elevation_. Reading a file is a Passive operation in the abstract. Reading a `.env` file is Reconnaissance because the _target_ is sensitive — credentials, connection strings, API keys. The tier comes from the combination of operation _and_ target, not the operation alone. A classifier that looks only at the verb misses half the risk surface. The Identify / Confirm / Verify sequence is the second non-negotiable. _Identify_ surfaces the agent's own reasoning about the action; if the agent can't state the tier and the rationale, it shouldn't fire the tool. _Confirm_ tests the action against the agreed plan — drift between "what we agreed to do" and "what the next tool call will do" is itself a signal. _Verify_ asks whether a safer alternative exists and is the step where most preventable destructive actions get caught. ## 1. The Four-Tier Taxonomy | Tier | Name | Examples | Risk | | ---- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------- | | 1 | **Passive / Read** | View a non-sensitive file, list a directory, grep for a string | Low | | 2 | **Reconnaissance** | Read `.env`, view a `credentials.*` file, run a SQL `SELECT` against a sensitive table, list installed packages and versions | Moderate (information exposure even without state change) | | 3 | **Modification** | Write or edit a source file, run a routine `git commit`, run a non-destructive `INSERT` or `UPDATE` with a `WHERE` clause | Standard | | 4 | **Destructive / Irreversible** | `git reset --hard`, `git push --force`, `DROP TABLE`, `TRUNCATE`, `DELETE FROM ...` without `WHERE`, `rm -rf`, `npm publish`, credential rotation, dependency lockfile rewrite | Critical — requires explicit justification | Every tool call gets a tier before it fires. No exceptions, including for "familiar" commands. ## 2. Operation-vs-Target Rule The tier comes from the combination of _operation_ and _target_. The same operation has a different tier depending on what it touches. | Operation | Generic target | Sensitive target | Tier shift | | --------- | --------------------------- | ------------------------------------------------------- | -------------------------------------------- | | Read | Source file | `.env`, `credentials.*`, private key | Passive → Reconnaissance | | Read | Local DB | Production DB or secrets table | Passive → Reconnaissance | | Write | Source file | Lockfile, environment config, public-key registry | Modification → Modification (still standard) | | Run | Script with no side effects | Script with side effects (install, deploy, mutate prod) | Passive → Modification or Destructive | | Git push | Topic branch | Main / master, force-push | Modification → Destructive (force-push) | When in doubt about the target, classify _up_, not down. ## 3. The Identify / Confirm / Verify Sequence Before executing any tier-3 or tier-4 tool call: ### Identify State explicitly: - The exact action (full command, full target path) - The classified tier - The reason this action is needed If the agent cannot complete this sentence — "I'm about to run X (tier Y) because Z" — it shouldn't fire the tool. Inability to articulate is itself a stop signal. ### Confirm Check the action against the active plan or task spec: - Was this action agreed to? - Does the spec name the same target? - If the action escalates a previously-agreed tier (e.g., the spec said "modify"; the proposed action is "destroy"), is the escalation explicitly authorized? Drift between agreed action and proposed action is the signal. The right response to drift is to _re-confirm with the human_, not to proceed. ### Verify Ask: is there a non-destructive alternative that achieves the same goal? | Destructive | Non-destructive alternative | | ------------------------------- | ------------------------------------------------------------------ | | `git reset --hard` | `git revert` (preserves history) or `git stash` (preserves work) | | `git push --force` | `git push --force-with-lease` (fails if remote moved unexpectedly) | | `DROP TABLE x` | `ALTER TABLE x RENAME TO x_archived_` (reversible) | | `DELETE FROM x WHERE condition` | `UPDATE x SET deleted_at = now() WHERE condition` (soft delete) | | `rm -rf ` | `mv .archived.` (still on disk; recoverable) | | `npm publish` | `npm publish --dry-run` first (sees the package; doesn't push) | | Lockfile rewrite | Smaller dependency change scoped to one package | If a non-destructive alternative exists and the destructive form was not specifically requested, prefer the non-destructive form. ## 4. Trigger Phrases The skill should activate before any tool call where the agent is about to: - Modify or write a file (`Write`, `Edit`, `MultiEdit`, `replace_file_content`, …) - Run a git command that mutates state (`commit`, `push`, `reset`, `rebase`, `merge`, `cherry-pick`, `branch -D`, `tag`, `stash drop`) - Run a database query that mutates state (`INSERT`, `UPDATE`, `DELETE`, `DROP`, `TRUNCATE`, `ALTER`, `CREATE`) - Run an install / publish / deploy command (`npm/pnpm/yarn install`, `npm publish`, `vercel deploy`, `cargo publish`, `pip install`, `apt install`, `gh repo edit`) - Run a shell command with `&&`, `||`, `;`, `|` chains that include any of the above - Read any file matching `.env*`, `credentials*`, `id_rsa*`, `*.pem`, `*.key`, `secrets.*`, `keystore*` These triggers are deliberately broad. False positives (classifying a Passive action as needing a tier check) are cheap; false negatives (firing a Destructive command without classification) are the failure mode this skill exists to prevent. ## 5. Anti-Patterns | Anti-pattern | Why it fails | Correct approach | | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | Classifying _all_ reads as Passive | A read of `.env` is Reconnaissance — credential exposure is the risk even with no state change | Check operation _and_ target type | | Treating `npm install` / `pnpm install` as Passive | Lockfile rewrites and node_modules churn affect reproducibility and can pull in compromised packages | Classify any environment-affecting command as at least Modification | | Skipping classification for "familiar" commands | `git push` is routine; `git push --force origin main` is Destructive — flags change tier | Classify every tool call regardless of familiarity | | Classifying force-push as Modification | Force-push rewrites remote history and cannot be `git checkout`-ed back | Any history-rewriting or unrecoverable action is Destructive | | Proceeding with Destructive without checking alternatives | `git reset --hard` instead of `git revert` is the single most common preventable loss | Run the Verify step every time | | Conflating Reconnaissance with Passive because "no state changes" | Information exposure (logging credentials, leaking connection strings into chat history) is itself a state change at the system level | Reconnaissance is its own tier for a reason | ## Verification - [ ] Before any tier-3 or tier-4 tool call, the agent has stated the action, the tier, and the reason in plain text - [ ] Operation-and-target rule was applied — sensitive targets elevated the tier above what the operation alone would suggest - [ ] The Confirm step checked the action against the agreed plan; any drift was re-confirmed with the human, not proceeded past - [ ] The Verify step considered at least one non-destructive alternative and either chose it or named why the destructive form is required - [ ] No tool call fired without an explicit tier classification — no exceptions for "familiar" commands - [ ] The trigger-phrase list is the activation contract, not a suggestion: any matching command runs through the sequence ## Do NOT Use When | Use instead | When | | ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A hook-based guardrail (deterministic blocker, e.g. PreToolUse hook in Claude Code) | Setting up _reactive_ / _structural_ enforcement that fires on a pattern match in the harness — that is hook-pattern territory; this skill is the agent-side cognitive classifier | | A code-quality / code-logic skill | Deciding _what_ the code should do — implementation correctness rather than action risk | | Task execution | Actually doing the work after classification has cleared the action | | `owasp-security` | A domain audit against a known threat catalog (Top 10) — that is a class of investigation, not per-action classification | | `code-review` | Reviewing an artefact for quality — orthogonal to action-risk classification | | `version-control` | The general discipline of using git well — this skill is the moment-of-execution gate on specific git commands |