design-thinking
Design Thinking
Coverage
Design thinking is the meta-skill that orchestrates a full human-centered design arc and routes specific work to the appropriate stage-specific sibling skill. Multiple canonical framings exist and largely agree on the shape. The Stanford d.school describes five stages: Empathize → Define → Ideate → Prototype → Test. The MIT Sloan framing renders it as Understand → Involve → Ideate → Prototype-test → Implement. The UK Design Council's Double Diamond maps the same arc onto two diamonds: Discover → Define (the problem-space diamond, diverge then converge on the right problem) and Develop → Deliver (the solution-space diamond, diverge then converge on the right solution). Tim Brown's HBR essay (2008) and the IDEO Field Guide describe the same arc under different stage labels.
Across framings the meta-skill covers (a) stage recognition — knowing which stage a team is currently in based on what artifacts exist and what question is open; (b) stage routing — handing the work to the right sibling skill (problem-framing for definition work, user-research for empathy/discovery, research-synthesis for sense-making, journey-mapping for cross-touchpoint experience, ideation for divergent/convergent concept generation, prototyping for learning artifacts, usability-testing for evaluation); (c) transition criteria — knowing what evidence justifies moving from one stage to the next; and (d) loop-back conditions — knowing when findings in a later stage invalidate work in an earlier one and the team should return rather than press forward.
The skill includes the non-linearity principle: although the stages are described in order, real projects loop. A prototype test (Test stage) commonly produces evidence that the team's problem framing (Define stage) was wrong, and the right response is to loop back to Define rather than ship the prototype as-is. Recognizing this is part of the meta-skill — a team that refuses to loop is performing the ritual of design thinking without practicing it. Conversely, looping endlessly without committing is its own failure mode, and the meta-skill includes naming when "we have enough" to proceed.
The skill also covers format choices for orchestration — multi-week project arcs versus compressed Design Sprints (Jake Knapp, Google Ventures) which run a full Define-through-Test cycle in five days. The format trades depth for speed; both have valid uses.
Philosophy
Design thinking exists because complex human problems do not yield to either pure analysis or pure intuition, and the discipline insists that iterating between empathy with users and concrete artifacts is more productive than either alone. The arc is not a procedure to be executed once; it is a structured way to make uncertainty visible. Each stage produces a specific kind of evidence (qualitative observations, framed problems, concept variants, learning artifacts, behavioral findings), and the discipline rewards teams that can name what kind of evidence they have versus what kind they still need.
The meta-skill is sceptical of two opposite failure modes. The first is stage skipping — leaping from a vague brief directly to prototyping because building feels like progress, with no framing and no research; the resulting prototype answers a question nobody asked. The second is stage stalling — researching indefinitely, framing endlessly, ideating without ever building, because each new round of empathy raises new questions and the team mistakes activity for progress. Both failures stem from the same root: not knowing which stage's question is currently open. The meta-skill names the open question explicitly and chooses the next stage to address it.
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.
7intent-recognition
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.
6dependency-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`).
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