intent-recognition
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
More from jacob-balslev/skill-graph
a11y
Use when building or reviewing interactive UI, forms, navigation, or dynamic content. Covers semantic HTML, keyboard access, focus management, labeling, state-change announcement, and reduced-motion / high-contrast preferences. Do NOT use for color-palette creation, visual branding, feedback-state staging, or prose reading-level accessibility - those belong to `visual-design-foundations`, `interaction-feedback`, and documentation respectively.
7dependency-architecture
Use when designing or auditing dependency structure: package boundaries, runtime vs build dependencies, adapter layers, duplicate-purpose libraries, supply-chain risk, upgrade policy, lock-in, and dependency graph health. Do NOT use for choosing a major framework (use `framework-fit-analysis`), vulnerability-only review (use `owasp-security`), or routine refactoring without dependency boundary changes (use `refactor`).
6information-architecture
Use when structuring information for findability: navigation, page hierarchy, docs architecture, sitemap shape, labeling systems, wayfinding, and content grouping. Do NOT use for formal category-governance work (use `taxonomy-design`), responsive page composition (use `layout-composition`), component/token architecture (use `design-system-architecture`), or sentence-level UI text (use `microcopy`).
6design-thinking
Use when orchestrating a full human-centered design process across discovery, definition, ideation, prototyping, and testing — when uncertain which stage of the arc a team is in, when deciding whether to loop back, or when routing to the right stage-specific sibling skill. Do NOT use for single-stage execution (go directly to problem-framing, user-research, research-synthesis, journey-mapping, ideation, prototyping, or usability-testing) or for engineering domain discovery (use event-storming).
6knowledge-modeling
Use when deciding *which representation paradigm* fits a piece of domain knowledge — knowledge graph vs frames vs production rules vs semantic network vs concept map vs procedural ontology vs hybrid — when designing AI-agent context systems, building a knowledge base, structuring a skill or reference library, or planning a GraphRAG retrieval pipeline. Covers the seven paradigms with structure / best-for / weakness tables, the tacit-to-explicit knowledge acquisition pipeline (elicitation → articulation → formalization → validation → encoding), knowledge graph design principles (reify when needed, separate schema from instance, label precisely, bidirectional naming, minimal redundancy), the four knowledge-validation types (completeness / consistency / relevance / currency) plus expert walkthrough, the seven-phase knowledge lifecycle (Create / Validate / Publish / Use / Monitor / Update / Retire), the application to AI-agent systems (skills as frames, routing as rules, memory as graph), and a full GraphRAG section covering the five patterns (entity-anchored retrieval, relationship-aware context, path-based reasoning, subgraph summarization, hybrid vector+graph) with rules for when graph-grounded retrieval beats plain RAG. Do NOT use for the *human-readable* domain analysis layer (use `conceptual-modeling`), for the database / ER design layer (a logical-modeling skill), for pure classification hierarchies (a taxonomy skill), for formal ontology axioms (an ontology skill), or for the live skill-library tooling that consumes modeled knowledge (use `skill-infrastructure`).
6ai-native-development
Use when reasoning about agent autonomy levels, designing auto-improve loops, evaluating AI-generated code quality, or measuring agent productivity in an LLM-assisted codebase. Covers Karpathy's three eras of software (1.0 explicit / 2.0 learned / 3.0 natural-language), the vibe-coding-vs-agentic-engineering distinction, the 0–5 autonomy slider with task-type recommendations, the one-asset / one-metric / one-time-box AutoResearch loop, Software 3.0 productivity metrics, and the documented quality regressions of ungated AI-generated code (the 'vibe hangover'). Do NOT use for choosing a specific autonomy-loop topology (use `agent-engineering`), for the per-prompt authoring discipline (use `prompt-craft`), or for reviewing the AI-generated code that comes out of a Software 3.0 workflow (use `code-review`).
5