Despite billions in investment, 95% of enterprise AI pilots fail to deliver measurable business impact (Challapally et al., 2025). The problem isn’t the models, it’s how they’re used. AI models are infrastructure, like the internet, not the product. What differentiates organisations is what they build on top of it. As capabilities converge, advantage shifts from tool selection to the quality of context and how it’s integrated into workflows. The focus should move from choosing models to building the knowledge infrastructure around them.Svoyski is a three-tier skills framework for encoding and deploying that knowledge.How We Make Sense of ThingsA common failure mode in AI adoption has little to do with the technology and more to do with how human sensemaking works. When making sense of things, we usually first gather input from multiple sources, reading, discussing, and absorbing information. Then, ideally, we step away from input, creating the conditions for understanding to form. The divergent phase fills the tank. The convergent phase is where the engine runs and produces a spark.In practice, most professional environments are optimised almost entirely for the divergent phase. There’s always another meeting, message, or task. Without space for convergence, input accumulates but rarely turns into understanding. Bertrand Russell would work intensely on a problem, abandon it deliberately, and return later to find it solved. Research suggests that stepping away from a problem after absorbing complex information can improve the originality of solutions (Dijksterhuis and Meurs, 2006).This pattern is not universal. Experienced practitioners often rely on rapid pattern recognition and act without deliberate incubation (Klein, 1998). For routine problems, this probably applies to all of us. But for novel or complex challenges, unstructured reflection remains critical.AI introduces a new failure mode. It allows us to bypass the convergent phase entirely, moving directly from input to output. The result is often fluent but shallow, lacking the judgment that comes from genuine understanding. The model cannot compensate for missing expertise, it can only amplify what is already present.This makes self-awareness a practical requirement. To use AI effectively, we must be able to articulate what we know, how we work, and what good looks like in our domain. In practice, this is difficult. Many people operate on tacit knowledge they have never externalised. Developing this capability requires deliberate practice, guidance, and the right conditions.How AI Models WorkA large language model is a statistical system trained on vast amounts of text. What we interact with today is several layers removed from that base, shaped by techniques such as reinforcement learning from human feedback and instruction tuning. These systems are neither databases nor formal reasoning engines, but they are more than simple pattern completionThey are effective at producing coherent, well-structured text that reflects how knowledgeable people write. However, they are unreliable when tasks require precise factual accuracy, formal logic, or up-to-date information. As Bender et al. (2021) argue, language models generate plausible language without grounding in meaning. The fluency is real, but the understanding is not. Incorrect outputs arrive with the same confidence as correct ones, and humans tend to overtrust systems that appear reliable (Parasuraman and Riley, 1997). Domain expertise remains the necessary quality filter.Interacting With a ModelPre-training defines what the model is capable of. It provides general language ability and broad world knowledge, and is outside the control of most organisations.Prompting is how we interact with the model in a given moment. The structure and clarity of a prompt strongly influence the response, to the point where two users of the same model can produce meaningfully different results. More context is not always better. Poorly structured or conflicting input degrades performance. Most organisations operate only at the prompting layer.Skills introduce a third layer. They are structured, reusable context injected at prompt time, but persistent enough to function as a middle layer between capability and interaction. A skill is a document or set of instructions that defines who the user is, how they work, and what standards apply. It acts as a professional briefing, grounding the model in specific expertise rather than generic training.In practice, AI functions less as autonomous intelligence and more as an interface layer between humans and computing. It allows users to express intent in natural language without needing to write code or learn formal syntax. As the barrier to interaction collapses, the limiting factor becomes the quality of the knowledge brought into the conversation.Most disappointing outcomes come from using AI generically. Without context, the model produces outputs that reflect an average across its training data, with no awareness of organisational standards, domain constraints, or prior decisions. The shift is from using AI as a search substitute to using it as a context-aware collaborator. Skills are the mechanism that enables that shift.The Svoyski FrameworkMuch of what makes an expert valuable cannot be fully captured in formal documentation. It exists as accumulated judgment, the ability to recognise what is wrong before being able to explain why. Nonaka and Takeuchi (1995) describe this as tacit knowledge, knowledge that is difficult to articulate yet critical in practice. Organisations consistently undervalue it because it remains invisible until it is lost.A skill is a structured document that surfaces a portion of tacit knowledge and makes it available to a model, conditioning AI outputs toward a specific standard of judgment rather than simply completing a task. Skills reduce ambiguity in the input space. They’re not only useful for the model, but also for the person creating it. They encode how work is approached, what constraints apply, and what good output looks like in a given domain. Unlike prompt templates or documentation, a skill doesn’t prescribe steps but instead defines perspective, making expertise explicit and portable.Skills improve AI usefulness in three ways. They constrain the solution space, reducing irrelevant or generic outputs. They align results with organisational standards and domain expectations. They also compress large amounts of tacit knowledge into a form that can be used effectively. The framework consists of three types of skills, each operating at a different level of abstraction.General SkillsGeneral Skills define how a discipline operates within an organisation. They encode values, standards, and patterns that define what good practice looks like, how to approach trade-offs, and which failure modes to avoid. Their purpose is not to prescribe solutions, but to shape how decisions are made. Some General Skills capture how the discipline thinks, while others define conventions and standards for tools such as Miro, Excel, Confluence, PowerPoint. Both are necessary. One ensures consistency in thinking, the other in output. Without this layer, tools and processes are applied inconsistently, and output quality depends heavily on individual interpretation.General Skills should be owned by discipline leads and treated as living standards, reviewed regularly. The act of writing them is itself valuable, as it forces the codification of knowledge that would otherwise remain implicit.General Skill Example**General Skill: Product Management***For any product manager, regardless of client or domain.*---**How we think about the role**Product management sits at the intersection of user needs, business goals, and technical constraints. We don't systematically favour one over the others. We treat the tension between them as the actual work. When these three pull in different directions, we make the conflict visible rather than resolving it prematurely. In practice, these forces are not balanced equally. Constraints, deadlines, or organisational priorities may dominate. The role is not to eliminate this imbalance, but to make it explicit and manage its consequences. A decision that maximises user delight at unsustainable cost is as much a failure as one that meets business targets but delivers no meaningful user value.**What we value**We favour decisions that are reversible over ones that aren't, when the cost of reversibility is low. We prefer validated assumptions over elegant theories. We treat scope as a variable, not a given. When in doubt, we ship less and learn faster. We prioritise work that is traceable to a clear user need or business objective. When this is unclear, the default action is to reduce scope or delay commitment.**How we work**We use user stories to create shared understanding, typically in the form "As a [user], I want [action] so that [outcome]." Acceptance criteria are written in Given/When/Then format and exist to prevent misalignment, not to create bureaucracy. We involve engineering early enough that constraints shape the problem, not just the solution. When delivery pressure overrides discovery, we explicitly acknowledge the risk rather than treating the solution as validated.**What good looks like**A well-run discovery surfaces what users actually need, not what they say they want. A well-written spec reduces back-and-forth during delivery and defines success criteria before describing the solution. A successful release is one where success criteria were defined in advance and can be evaluated without reinterpretation.**When helping with PM work, apply these principles**When reviewing a spec, check whether success criteria are defined before the solution is described. If not, ask for them. When evaluating prioritisation decisions, check whether each item is traceable to a user need or a business goal, if not, flag it. When writing or reviewing user stories, verify the outcome is stated from the user's perspective, not the feature's. When a roadmap is presented as fixed, ask what assumptions would have to be wrong for it to change.**Common failure modes to flag**Prioritising based on who asks loudest rather than validated need. Treating the roadmap as a commitment rather than a hypothesis. Skipping discovery because the solution feels obvious. Writing tickets so detailed they leave no room for engineering judgment. Defining success after the fact to fit what shipped.\General Skill for a Tool Example**General Skill: Miro***For anyone using Miro for workshops, discovery, or collaboration, regardless of project or client.*---**When we use Miro**Miro is for thinking together, not for producing deliverables. It's the right tool when work benefits from visual structure, spatial arrangement, or real-time collaboration. It's the wrong tool when the output needs to be shared with stakeholders who weren't in the room, in that case, the Miro output gets translated into a more accessible format before sharing.**How we structure boards**One board per session or workstream, not one board per project. Boards that try to hold everything become unreadable. Each board has a clear title, a date, and a one-line description of what it was for. Sections are labeled. Stickies have an author visible when context matters. Boards are archived or summarised once their purpose is complete.**Conventions**Yellow stickies for observations and facts. Pink for problems and risks. Green for opportunities and ideas. Blue for decisions and next steps. This is a default, not a strict rule, but if you deviate, label the legend on the board.**What good looks like**A well-run Miro session produces a clear output that can be understood by someone who wasn't there. The facilitator synthesises before the session ends. Key decisions and open questions are captured explicitly, not left scattered across the board.**When helping with Miro work, apply these principles**When asked to help structure a board, ask what the session is trying to produce before suggesting a layout. When reviewing a board, check whether decisions and open questions are explicitly captured. When summarising a session, prioritise decisions made, assumptions surfaced, and next steps, not a description of the activities.**Common failure modes to flag**Boards that grow without being archived or summarised. Stickies with no context that are unreadable a week later. Sessions that end without a clear output. Using Miro to document rather than to think.Project SkillsProject Skills adapt General Skills to a specific context. They introduce the constraints that matter for a given engagement, like domain, technology, team structure, and stakeholder expectations.If General Skills define values, Project Skills translate those values into principles that guide decisions in context. Project Skills do not eliminate trade-offs. They make them explicit. When different considerations conflict, the model can surface the tension, but resolution remains a human responsibility. They are owned by the project lead and evolve alongside the project. Their primary function is to ensure that anyone working within that context, human or model, operates with the same understanding from the outset.Project Skill Example**Project Skill: Product Management, Fintech Client, Mobile Banking Platform***Inherits: General Skill: Product Management*---**Client context**B2C mobile banking app, 200k active users, regulated under PSD2. Engineering team of eight, two-week sprints, releases gated by compliance review. The client's primary tension is speed-to-market vs. regulatory caution. In this project, regulatory compliance takes precedence over delivery speed when the two are in conflict.**Principles for this project**In practice, compliance requirements may be ambiguous or evolve during development. When unclear, default to escalation rather than interpretation. Nothing ships without compliance sign-off, even if it delays the sprint. Scope negotiation happens before a ticket enters development, not during. Feature flags are preferred over big-bang releases. When user needs and regulatory requirements conflict, escalate rather than decide unilaterally. We favour approaches that minimise regulatory risk over those that optimise for speed, unless the risk is explicitly understood and accepted.**Technology context**React Native frontend and Node.js backend deployed on AWS infrastructure. All changes follow a pull request workflow with mandatory review. No direct database access from the frontend. All API changes require versioning.**Definition of done**Acceptance criteria met, compliance checklist completed, analytics event firing, release notes written. A ticket is not considered complete unless these conditions are met, or a conscious exception is made and documented.**Stakeholder norms**The client CPO reviews the roadmap fortnightly. Surprises are unwelcome. Surface blockers early, in writing. The engineering lead makes final calls on technical approach, which should not be overridden within tickets.**Team norms**Retros are blameless. Decisions made in Slack are confirmed in Jira. Estimates are ranges, not commitments.**When helping with work on this project**Flag anything that might require compliance review before it reaches development. If a ticket lacks a compliance checklist item, ask for it. If a scope change appears mid-sprint, note it explicitly rather than absorbing it silently.**Common failure modes to flag**Treating compliance as a final step rather than a constraint during design, absorbing scope changes mid-sprint without surfacing their impact, making assumptions about regulatory requirements without proper validation, and prioritising speed in areas where compliance risk is unclear are all common failure modes that should be actively identified and challenged.Personal SkillsPersonal Skills capture how an individual works in practice, reflecting habits, heuristics, and decision-making patterns developed through experience. While General and Project Skills define what matters, Personal Skills define how it is applied in practice. They are the most powerful and the most difficult to develop. In most cases, they emerge over time rather than being written fully formed. Many individuals rely on tacit knowledge they have never externalised, making articulation itself a learned skill.Personal Skills are portable. They move with the individual across projects, allowing their way of working to remain consistent even as context changes. At the same time, they introduce diversity. Different individuals with the same role will encode different approaches, which is essential for avoiding uniform thinking. Borrowing another person’s skill can be a useful starting point, but it cannot replace the development of one’s own. A borrowed skill reflects someone else’s judgment and may propagate their blind spots if adopted uncritically.Personal Skill Example**Personal Skill: Product Manager, John Smith**---**How I work**I start discovery by mapping what I don't know before I map what I do. I use an assumptions log as a running list of things I'm treating as true but haven't validated. I revisit it regularly, typically at the end of each sprint.**Validation approach**I validate the problem before the solution. If I can't articulate the problem in one sentence without mentioning a feature, I'm not ready to spec anything. I use structured interviews for problem validation and usability testing for solution validation. I keep these distinct and don’t mix the two.**Tools and formats**I externalise thinking through visual mapping and structured documentation to create shared understanding. Specs follow a consistent structure of context, problem statement, success criteria, scope, and open questions, which I use to maintain clarity.**How I write user stories**As a [specific user type], I want [specific action] so that [measurable outcome]. If the outcome isn't measurable, the story isn't ready. Acceptance criteria in Given/When/Then, written before the story enters refinement.**Heuristics I apply**If a stakeholder can't tell me what problem a feature solves, I push back before estimating. If two engineers give wildly different estimates, I assume the spec is unclear rather than the estimates being wrong. If I'm tempted to skip discovery because the solution feels obvious, I treat that as a red flag. If a piece of work cannot be clearly linked to a user need or business objective, I treat it as a candidate for deprioritisation. I distrust solutions that feel obvious without evidence.**How I handle uncertainty**I name it explicitly in the spec rather than paper over it. Open questions stay open until answered, not until forgotten. When under delivery pressure, I tend to default to execution. I treat this as a risk signal and explicitly check whether the problem has been sufficiently validated before proceeding.**What I'm still developing**Saying no earlier. I tend to absorb scope creep before flagging it.---**When helping with John’s work, apply these directives**When reviewing a spec, check that success criteria appear before the solution is described. If not, ask for them. If ambiguity is present in the problem statement, prioritise clarifying it before refining the solution. When reviewing user stories, verify the outcome is measurable. If it isn't, flag it before the story progresses. When open questions are present, treat them as unresolved until explicitly answered. If scope appears to have grown beyond the original brief, surface it explicitly rather than absorbing it. If discovery is being skipped because the solution feels obvious, flag this as a risk. When producing any spec or documentation, follow the structure of context, problem statement, success criteria, scope, open questions.How Skills Work TogetherIn a typical session, three skills are loaded into the same context window and read together by the model. Each operates at a different level. The General Skill establishes discipline-level values. The Project Skill introduces the constraints and principles specific to the engagement. The Personal Skill reflects how the individual works in practice. Together, they shape the response before the task is even considered.This structure makes conflict visible. When different considerations pull in different directions, the tension is surfaced rather than resolved implicitly. A Project Skill may override a General Skill on specific decisions, but not on underlying values. The distinction lies in levels of abstraction, which allows the system to remain coherent even when trade-offs are present.The specific combination of skills varies by individual. A product manager and a front-end engineer working on the same project share the same Project context but bring different General and Personal Skills. The result is alignment on what matters, combined with variation in how it is approached. Context is not shared between sessions in real time, so consistency depends on the skills being maintained rather than on conversation history. The Project Skill acts as the connective layer, ensuring that different contributors operate with a compatible understanding of the same environment.Skills provide the model with values, constraints, and standards, while the prompt defines the immediate objective, whether that is a specification, a bug report, or a design task. The model produces a first pass, which is then reviewed, tested, and refined by the human. What remains is the work that requires judgment, deciding whether the output fits the system, reflects user needs, and holds under constraints that the model cannot fully see.The effect is a reduction in the distance between thinking and output. The model handles the translation from intent to draft, while the human focuses on meaning and correctness. The role shifts. What becomes more valuable is the ability to recognise what good looks like in context and to intervene where the model falls short.\Continuous ImprovementSkills are a practice, not a project. A skill that’s not maintained quickly becomes a liability, because it provides outdated context with a high degree of confidence. Knowledge evolves, projects change, and individuals develop new expertise. Skills need to be reviewed and updated over time in the same way a codebase is. When AI output degrades, the first question is not whether the model has changed, but whether the underlying Skill is still current.Maintenance happens at different levels. Personal Skills are revisited as individuals refine how they work or move between roles. General Skills evolve more slowly and reflect changes in discipline standards over time. Project Skills shift with the lifecycle of an engagement, adapting as context changes and eventually becoming a record of how the work was done.Unlike traditional documentation, the cost of staleness becomes visible through use. When a skill is outdated, the quality of AI output deteriorates in ways that are difficult to ignore. This creates a feedback loop that encourages maintenance, although it doesn’t guarantee it. The system still depends on deliberate ownership and attention.The framework doesn’t introduce a new layer of responsibility so much as it makes existing ones more explicit. Ownership remains with those already responsible for delivery quality and professional standards. Maintenance can be integrated into existing routines, rather than treated as a separate process.For this to work in practice, three conditions need to be met. There must be infrastructure that makes skills easy to store, version, and load into AI interactions without friction. There must be guidance that helps individuals understand what a good skill looks like and how to develop one. There must also be time set aside for this work, treated as part of the job rather than an additional burden. Small, regular updates are more sustainable than large, infrequent efforts, and organisations that succeed with this approach are likely to embed it quietly into existing practices rather than enforce it through heavy process.The Extended MindIn 1998, Andy Clark and David Chalmers argued that the boundary of the mind does not end at the skull. When we use external tools to store, process, or manipulate information, those tools become part of the cognitive system. Their example is a notebook. A person who consistently uses one to store and retrieve information is not cognitively worse off than someone who remembers everything internally. The notebook performs memory functions. Writing something down is not just record-keeping, but part of the thinking process itself.For a tool to qualify, occasional usefulness is not enough. It must be reliably available, easily accessible, and used with a degree of automatic trust. Clark later expanded this idea by arguing that tools become genuinely cognitive when they become transparent through habit, when we stop thinking about the tool and start thinking through it. A notebook that is consistently carried and used meets this standard. One that is rarely consulted does not.This creates a constraint for the skills framework. A skill that must be remembered, manually loaded, or frequently questioned is a weak cognitive extension. If it is outdated or difficult to maintain, it loses its effectiveness. The framework does not avoid this problem. It depends on the conditions described earlier, where skills are accessible, maintained, and integrated into regular practice.https://www.youtube.com/watch?v=kc-TdMjuJRU&embedable=true\What This Means For AIUnlike a notebook, a language model doesn’t just store information. It transforms what it’s given and applies it to new situations. Hutchins (1995) described this kind of system long before AI, where cognition is distributed across people and tools. A ship doesn’t navigate on its own. The crew, instruments, and shared context together form a system more capable than any one part.A skills framework applies the same principle to knowledge work. When an engineer loads their Personal Skill, a relevant General Skill, and a Project Skill, they extend their professional mind into the tool. The result is a system more capable than either the person or the model alone.Without that context, the model produces generic output. Using it is like working from someone else’s notebook. The information may be coherent, but it lacks relevance and grounding. The model isn’t the value. The knowledge that surrounds it is.ConclusionMost knowledge workers already externalise expertise into shared tools. Architecture decision records, onboarding guides, code review standards, internal wikis. The habit is already there. The Skills framework is a more deliberate, AI-native version of the same behaviour, where what we write doesn’t just describe how we work, it works alongside us.Most organisations will discover that the models are not the differentiator. They might invest in the tools, see underwhelming results, and conclude the technology isn’t ready. The technology is ready. The question is whether the knowledge infrastructure around it is.Domain expertise is the precondition for using AI well. A model can’t verify its own outputs, decide which problems are worth solving, or recognise when a plausible answer is actually wrong. The human in the loop isn’t a legacy cost to be eliminated, but the quality filter the system depends on.The right historical parallel is the assembly line. It didn’t replace workers. It restructured what they did, removing the overhead of moving parts between stations so each person could focus on the work only they could do. What disappeared was the wasted motion between the valuable work.AI can remove that same wasted motion in knowledge work. The time spent on first drafts that exist only to be rewritten, searching for information that already exists somewhere, re-explaining context to a tool that doesn’t remember. What remains, and grows in importance, is judgment. Domain knowledge. The ability to ask the right question and recognise the right answer.ReferencesBender, E.M., Gebru, T., McMillan-Major, A., & Shmitchell, S. (2021). On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? FAccT '21, 610-623.Challapally, A. et al. (2025). The GenAI Divide: State of AI in Business 2025. MIT Project NANDA.Clark, A. (2008). Supersizing the Mind: Embodiment, Action, and Cognitive Extension. Oxford University Press.Clark, A., & Chalmers, D. (1998). The extended mind. Analysis, 58(1), 7-19.Dijksterhuis, A., & Meurs, T. (2006). Where creativity resides: The generative power of unconscious thought. Consciousness and Cognition, 15(1), 135-146.Hutchins, E. (1995). Cognition in the Wild. MIT Press.Klein, G. (1998). Sources of Power: How People Make Decisions. MIT Press.Nonaka, I., & Takeuchi, H. (1995). The Knowledge-Creating Company. Oxford University Press.Page, S.E. (2007). The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies. Princeton University Press.Parasuraman, R., & Riley, V. (1997). Humans and automation: Use, misuse, disuse, abuse. Human Factors, 39(2), 230-253.\n