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_<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 |
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.4license: MIT5---6
7# Intent Recognition
8
9## Coverage
10
11Pre-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.
12
13## Philosophy
14
15Agents 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.
16
17The 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.
18
19The 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.
20
21## 1. The Four-Tier Taxonomy
22
23| Tier | Name | Examples | Risk |
24| ---- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------- |
25| 1 | **Passive / Read** | View a non-sensitive file, list a directory, grep for a string | Low |
26| 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) |
27| 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 |
28| 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 |
29
30Every tool call gets a tier before it fires. No exceptions, including for "familiar" commands.
31
32## 2. Operation-vs-Target Rule
33
34The tier comes from the combination of _operation_ and _target_. The same operation has a different tier depending on what it touches.
35
36| Operation | Generic target | Sensitive target | Tier shift |
37| --------- | --------------------------- | ------------------------------------------------------- | -------------------------------------------- |
38| Read | Source file | `.env`, `credentials.*`, private key | Passive → Reconnaissance |
39| Read | Local DB | Production DB or secrets table | Passive → Reconnaissance |
40| Write | Source file | Lockfile, environment config, public-key registry | Modification → Modification (still standard) |
41| Run | Script with no side effects | Script with side effects (install, deploy, mutate prod) | Passive → Modification or Destructive |
42| Git push | Topic branch | Main / master, force-push | Modification → Destructive (force-push) |
43
44When in doubt about the target, classify _up_, not down.
45
46## 3. The Identify / Confirm / Verify Sequence
47
48Before executing any tier-3 or tier-4 tool call:
49
50### Identify
51
52State explicitly:
53
54- The exact action (full command, full target path)
55- The classified tier
56- The reason this action is needed
57
58If 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.
59
60### Confirm
61
62Check the action against the active plan or task spec:
63
64- Was this action agreed to?
65- Does the spec name the same target?
66- If the action escalates a previously-agreed tier (e.g., the spec said "modify"; the proposed action is "destroy"), is the escalation explicitly authorized?
67
68Drift between agreed action and proposed action is the signal. The right response to drift is to _re-confirm with the human_, not to proceed.
69
70### Verify
71
72Ask: is there a non-destructive alternative that achieves the same goal?
73
74| Destructive | Non-destructive alternative |
75| ------------------------------- | ------------------------------------------------------------------ |
76| `git reset --hard` | `git revert` (preserves history) or `git stash` (preserves work) |
77| `git push --force` | `git push --force-with-lease` (fails if remote moved unexpectedly) |
78| `DROP TABLE x` | `ALTER TABLE x RENAME TO x_archived_<date>` (reversible) |
79| `DELETE FROM x WHERE condition` | `UPDATE x SET deleted_at = now() WHERE condition` (soft delete) |
80| `rm -rf <dir>` | `mv <dir> <dir>.archived.<date>` (still on disk; recoverable) |
81| `npm publish` | `npm publish --dry-run` first (sees the package; doesn't push) |
82| Lockfile rewrite | Smaller dependency change scoped to one package |
83
84If a non-destructive alternative exists and the destructive form was not specifically requested, prefer the non-destructive form.
85
86## 4. Trigger Phrases
87
88The skill should activate before any tool call where the agent is about to:
89
90- Modify or write a file (`Write`, `Edit`, `MultiEdit`, `replace_file_content`, …)
91- Run a git command that mutates state (`commit`, `push`, `reset`, `rebase`, `merge`, `cherry-pick`, `branch -D`, `tag`, `stash drop`)
92- Run a database query that mutates state (`INSERT`, `UPDATE`, `DELETE`, `DROP`, `TRUNCATE`, `ALTER`, `CREATE`)
93- Run an install / publish / deploy command (`npm/pnpm/yarn install`, `npm publish`, `vercel deploy`, `cargo publish`, `pip install`, `apt install`, `gh repo edit`)
94- Run a shell command with `&&`, `||`, `;`, `|` chains that include any of the above
95- Read any file matching `.env*`, `credentials*`, `id_rsa*`, `*.pem`, `*.key`, `secrets.*`, `keystore*`
96
97These 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.
98
99## 5. Anti-Patterns
100
101| Anti-pattern | Why it fails | Correct approach |
102| ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
103| 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 |
104| 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 |
105| 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 |
106| 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 |
107| 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 |
108| 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 |
109
110## Verification
111
112- [ ] Before any tier-3 or tier-4 tool call, the agent has stated the action, the tier, and the reason in plain text
113- [ ] Operation-and-target rule was applied — sensitive targets elevated the tier above what the operation alone would suggest
114- [ ] The Confirm step checked the action against the agreed plan; any drift was re-confirmed with the human, not proceeded past
115- [ ] The Verify step considered at least one non-destructive alternative and either chose it or named why the destructive form is required
116- [ ] No tool call fired without an explicit tier classification — no exceptions for "familiar" commands
117- [ ] The trigger-phrase list is the activation contract, not a suggestion: any matching command runs through the sequence
118
119## Do NOT Use When
120
121| Use instead | When |
122| ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
123| 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 |
124| A code-quality / code-logic skill | Deciding _what_ the code should do — implementation correctness rather than action risk |
125| Task execution | Actually doing the work after classification has cleared the action |
126| `owasp-security` | A domain audit against a known threat catalog (Top 10) — that is a class of investigation, not per-action classification |
127| `code-review` | Reviewing an artefact for quality — orthogonal to action-risk classification |
128| `version-control` | The general discipline of using git well — this skill is the moment-of-execution gate on specific git commands |
aibot88