Intent Recognition
Concept of the skill
Classifying the intent of an operation BEFORE any tool call that could modify state, touch sensitive targets, rewrite history, install dependencies, publish packages, or expose credentials — sorting into Passive/Read, Reconnaissance, Modification, or Destructive/Irreversible by operation type plus target sensitivity, then running Identify / Confirm / Verify before action.
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 of the skill
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_<date> (reversible) |
DELETE FROM x WHERE condition |
UPDATE x SET deleted_at = now() WHERE condition (soft delete) |
rm -rf <dir> |
mv <dir> <dir>.archived.<date> (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
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 |
Skill Graph context
Classification
- Subject:
ai-engineering
- Public:
true
- Domain:
ai-engineering/safety
- Scope: Classifying the intent of an operation BEFORE any tool call that could modify state, touch sensitive targets, rewrite history, install dependencies, publish packages, or expose credentials — sorting into Passive/Read, Reconnaissance, Modification, or Destructive/Irreversible by operation type plus target sensitivity, then running Identify / Confirm / Verify before action. Portable across any agent with tool access; principle-grounded, not repo-bound. Excludes deciding what code to write, executing already-classified work, reactive post-execution guardrails, and defining upstream governance policy.
When to use
- 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?
Not for
- 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
Related skills
- Verify with:
owasp-security, guardrails
- Related:
version-control, debugging, code-review, testing-strategy, owasp-security
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
1---2name: intent-recognition3description: 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. Do NOT use for design the deterministic safety hook that blocks destructive commands. Do NOT use for decide whether to use a switch or a chain of ifs. Do NOT use for actually execute the migration after we've classified the risk. Do NOT use for scan this repo for OWASP top 10 vulnerabilities. Do NOT use for review this AI-generated PR for correctness. Do NOT use for the loop is stalling — what's the steering signal.4license: MIT5---6# Intent Recognition78## Concept of the skill910Classifying the intent of an operation BEFORE any tool call that could modify state, touch sensitive targets, rewrite history, install dependencies, publish packages, or expose credentials — sorting into Passive/Read, Reconnaissance, Modification, or Destructive/Irreversible by operation type plus target sensitivity, then running Identify / Confirm / Verify before action.1112## Coverage1314Pre-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.1516## Philosophy of the skill17Agents 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.1819The 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.2021The 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.2223## 1. The Four-Tier Taxonomy2425| Tier | Name | Examples | Risk |26| ---- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------- |27| 1 | **Passive / Read** | View a non-sensitive file, list a directory, grep for a string | Low |28| 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) |29| 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 |30| 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 |3132Every tool call gets a tier before it fires. No exceptions, including for "familiar" commands.3334## 2. Operation-vs-Target Rule3536The tier comes from the combination of _operation_ and _target_. The same operation has a different tier depending on what it touches.3738| Operation | Generic target | Sensitive target | Tier shift |39| --------- | --------------------------- | ------------------------------------------------------- | -------------------------------------------- |40| Read | Source file | `.env`, `credentials.*`, private key | Passive → Reconnaissance |41| Read | Local DB | Production DB or secrets table | Passive → Reconnaissance |42| Write | Source file | Lockfile, environment config, public-key registry | Modification → Modification (still standard) |43| Run | Script with no side effects | Script with side effects (install, deploy, mutate prod) | Passive → Modification or Destructive |44| Git push | Topic branch | Main / master, force-push | Modification → Destructive (force-push) |4546When in doubt about the target, classify _up_, not down.4748## 3. The Identify / Confirm / Verify Sequence4950Before executing any tier-3 or tier-4 tool call:5152### Identify5354State explicitly:5556- The exact action (full command, full target path)57- The classified tier58- The reason this action is needed5960If 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.6162### Confirm6364Check the action against the active plan or task spec:6566- Was this action agreed to?67- Does the spec name the same target?68- If the action escalates a previously-agreed tier (e.g., the spec said "modify"; the proposed action is "destroy"), is the escalation explicitly authorized?6970Drift between agreed action and proposed action is the signal. The right response to drift is to _re-confirm with the human_, not to proceed.7172### Verify7374Ask: is there a non-destructive alternative that achieves the same goal?7576| Destructive | Non-destructive alternative |77| ------------------------------- | ------------------------------------------------------------------ |78| `git reset --hard` | `git revert` (preserves history) or `git stash` (preserves work) |79| `git push --force` | `git push --force-with-lease` (fails if remote moved unexpectedly) |80| `DROP TABLE x` | `ALTER TABLE x RENAME TO x_archived_<date>` (reversible) |81| `DELETE FROM x WHERE condition` | `UPDATE x SET deleted_at = now() WHERE condition` (soft delete) |82| `rm -rf <dir>` | `mv <dir> <dir>.archived.<date>` (still on disk; recoverable) |83| `npm publish` | `npm publish --dry-run` first (sees the package; doesn't push) |84| Lockfile rewrite | Smaller dependency change scoped to one package |8586If a non-destructive alternative exists and the destructive form was not specifically requested, prefer the non-destructive form.8788## 4. Trigger Phrases8990The skill should activate before any tool call where the agent is about to:9192- Modify or write a file (`Write`, `Edit`, `MultiEdit`, `replace_file_content`, …)93- Run a git command that mutates state (`commit`, `push`, `reset`, `rebase`, `merge`, `cherry-pick`, `branch -D`, `tag`, `stash drop`)94- Run a database query that mutates state (`INSERT`, `UPDATE`, `DELETE`, `DROP`, `TRUNCATE`, `ALTER`, `CREATE`)95- Run an install / publish / deploy command (`npm/pnpm/yarn install`, `npm publish`, `vercel deploy`, `cargo publish`, `pip install`, `apt install`, `gh repo edit`)96- Run a shell command with `&&`, `||`, `;`, `|` chains that include any of the above97- Read any file matching `.env*`, `credentials*`, `id_rsa*`, `*.pem`, `*.key`, `secrets.*`, `keystore*`9899These 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.100101## 5. Anti-Patterns102103| Anti-pattern | Why it fails | Correct approach |104| ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |105| 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 |106| 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 |107| 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 |108| 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 |109| 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 |110| 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 |111112## Verification113114- [ ] Before any tier-3 or tier-4 tool call, the agent has stated the action, the tier, and the reason in plain text115- [ ] Operation-and-target rule was applied — sensitive targets elevated the tier above what the operation alone would suggest116- [ ] The Confirm step checked the action against the agreed plan; any drift was re-confirmed with the human, not proceeded past117- [ ] The Verify step considered at least one non-destructive alternative and either chose it or named why the destructive form is required118- [ ] No tool call fired without an explicit tier classification — no exceptions for "familiar" commands119- [ ] The trigger-phrase list is the activation contract, not a suggestion: any matching command runs through the sequence120121## Do NOT Use When122123| Use instead | When |124| ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |125| 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 |126| A code-quality / code-logic skill | Deciding _what_ the code should do — implementation correctness rather than action risk |127| Task execution | Actually doing the work after classification has cleared the action |128| `owasp-security` | A domain audit against a known threat catalog (Top 10) — that is a class of investigation, not per-action classification |129| `code-review` | Reviewing an artefact for quality — orthogonal to action-risk classification |130| `version-control` | The general discipline of using git well — this skill is the moment-of-execution gate on specific git commands |131132## Skill Graph context133134<!-- skill-graph-context:start (generated — do not edit by hand) -->135136**Classification**137- Subject: `ai-engineering`138- Public: `true`139- Domain: `ai-engineering/safety`140- Scope: Classifying the intent of an operation BEFORE any tool call that could modify state, touch sensitive targets, rewrite history, install dependencies, publish packages, or expose credentials — sorting into Passive/Read, Reconnaissance, Modification, or Destructive/Irreversible by operation type plus target sensitivity, then running Identify / Confirm / Verify before action. Portable across any agent with tool access; principle-grounded, not repo-bound. Excludes deciding what code to write, executing already-classified work, reactive post-execution guardrails, and defining upstream governance policy.141142**When to use**143- the agent is about to run `git reset --hard` — what tier is this and what's the safer alternative?144- is reading the `.env` file a Passive operation since nothing mutates?145- I'm about to install a new package — what tier does that fit and why?146- force-push to main looks like 'just a push' — should I classify it as Modification?147- before running `DELETE FROM orders WHERE …`, what's the verification sequence?148- the agent classified everything as Modification because there's no exception for credentials149- what trigger phrases should activate this skill in our harness?150151**Not for**152- design the deterministic safety hook that blocks destructive commands153- decide whether to use a switch or a chain of ifs154- actually execute the migration after we've classified the risk155- scan this repo for OWASP top 10 vulnerabilities156- review this AI-generated PR for correctness157- the loop is stalling — what's the steering signal158159**Related skills**160- Verify with: `owasp-security`, `guardrails`161- Related: `version-control`, `debugging`, `code-review`, `testing-strategy`, `owasp-security`162163**Keywords**164- `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`165166<!-- skill-graph-context:end -->
jacob-balslev