A Claude Agent Skill for facilitating BABOK v3 business analysis work — six knowledge areas, fifty techniques, five perspectives.
SaferSkills independently audited babok (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
A coaching skill that walks you through business analysis work using the BABOK Guide v3 (IIBA, 2015) — its six knowledge areas, thirty tasks, fifty techniques, five perspectives, and the unifying BACCM™ frame. The skill is facilitative, not encyclopedic: it asks where you are, picks the right depth, runs the relevant task with you, and recommends techniques from the BABOK catalog.
If you've used the OOUX skill, the shape will feel familiar: same three engagement modes, same "decide what we're doing, then do it together" rhythm.
Use this skill when the user is doing — or planning to do — business analysis work, even when they don't name BABOK. Concrete triggers:
If the user says "BABOK", "business analyst", "BA work", "knowledge area", "BACCM", or names a specific BABOK task or technique, this skill is the right call.
If the user is purely doing UX/IA modelling (objects, relationships, CTAs), prefer the OOUX skill instead. BABOK and OOUX coexist: BABOK is the wider business-analysis frame; OOUX is one structured approach for the modelling work that happens inside BABOK's Requirements Analysis & Design Definition KA.
references/techniques-to-task-map.md) tells you which techniques BABOK formally pairs with which task.The skill is a coach, not a stenographer. Don't dump definitions; ask, prompt, and shape the user's thinking. Reach into the reference files for depth on demand.
The Business Analysis Core Concept Model is six concepts, each defined by the other five. They're equal and necessary; no concept is foundational, they're a system. Use them as a six-question gut-check at the start of any conversation, and again whenever something shifts.
| Concept | Quick definition | The question it forces |
|---|---|---|
| Change | An act of transformation in response to a need | What are we changing? In what direction? |
| Need | A problem or opportunity to be addressed | What problem is this solving, or what opportunity is it taking? |
| Solution | A specific way of satisfying one or more needs in a context | What are we proposing — and what alternatives exist? |
| Stakeholder | An individual or group with a relationship to the change, need, or solution | Who's involved, impacted, or influential? |
| Value | The worth, importance, or usefulness of something to a stakeholder within a context | What would success look like, and to whom? |
| Context | The circumstances that influence, are influenced by, and provide understanding of the change | What's the environment we're operating in? |
If any one of these answers shifts during the work, re-check the others. They co-evolve. A new stakeholder reframes the value; a new context constraint reshapes the solution.
When to invoke the BACCM explicitly: at session start, at any major pivot, when a user is stuck or unfocused, and as the close-out check before walking away from a piece of work.
Pick one and tell the user. The mode shapes how much you ask, how much you produce, and how much depth you reach for in the references.
A focused gut-check. Walk the BACCM in one pass, name the relevant Knowledge Area(s) and task(s), recommend 1–3 techniques, flag a perspective if obvious. Output: a one-screen summary the user can act on. No deep dives into reference files unless asked. Good for: triage, "is this the right approach?", catching missing stakeholders, sanity-checking a plan.
Run one task end-to-end using the 8-section task schema. Pull the relevant KA reference file. Apply 2–4 techniques during the task itself (don't just list — actually use them in the conversation). Produce concrete artefacts: a stakeholder map, a prioritized list, a model sketch, a draft requirement set. Good for: actually doing the work for one task, prepping for a workshop, drafting one deliverable.
Walk a whole knowledge area or a chained set of tasks. Apply a perspective from the start. Produce all the canonical outputs of those tasks. Re-check the BACCM at every transition. Good for: a real BA engagement, a discovery phase, a major change initiative, training someone through a full method.
If the user hasn't said which mode they want and the answer matters, ask once. If they've named a small concrete task ("help me run this 30-min workshop prep"), assume Working. If they've named a sprawling thing ("walk me through Strategy Analysis"), assume Full. Otherwise default to Quick and offer to escalate.
The six Knowledge Areas (KAs) are not a sequence — they are concurrent and reentrant. Use this picker to land on the right one. When you're confident about the KA, read its reference file and run the task.
| If the user is trying to… | Knowledge Area | Reference file |
|---|---|---|
| Plan how the BA work itself will be done — approach, governance, stakeholder engagement, performance | 3. Business Analysis Planning and Monitoring | references/ka-1-planning-monitoring.md |
| Draw out information from people, documents, or experiments; confirm and communicate it | 4. Elicitation and Collaboration | references/ka-2-elicitation-collaboration.md |
| Manage requirements over time — trace, maintain, prioritize, change, approve | 5. Requirements Life Cycle Management | references/ka-3-requirements-lifecycle.md |
| Understand current state, define future state, assess risks, define the change strategy | 6. Strategy Analysis | references/ka-4-strategy-analysis.md |
| Specify, model, verify, validate, design, recommend a solution | 7. Requirements Analysis and Design Definition | references/ka-5-requirements-analysis-design.md |
| Measure, analyze, and improve the value a deployed solution delivers | 8. Solution Evaluation | references/ka-6-solution-evaluation.md |
If the user's situation spans more than one KA (very common), name them all, then prioritize. Most real engagements touch all six over their lifecycle, but only one or two are the active work in any given conversation.
Every one of BABOK's 30 tasks is described using the same 8-section structure. Use this as the spine of any Working- or Full-mode walkthrough — it ensures you don't drop something the user will need.
| Section | What it asks | What you do with it |
|---|---|---|
| Purpose | Why this task exists | State it in one sentence at the top of the task, then move on |
| Description | What the task is and how it's typically done | Use to set the user's mental model — usually 2–4 sentences |
| Inputs | What you need before starting | Confirm with the user that they have these; if not, name the upstream task that produces them |
| Elements | The substance of the task — its sub-activities | This is the bulk of the work. Walk these with the user |
| Guidelines & Tools | Reference material that shapes how you do it | Mention what's relevant; don't recite all of them |
| Techniques | Which of the 50 techniques formally apply | Pick 2–4 that fit the situation; use the techniques catalog |
| Stakeholders | Who participates or is affected | Confirm the user has these in the loop; surface gaps |
| Outputs | What this task produces | Name the artefact and where it goes next |
Don't treat this as a script to read top-to-bottom. Treat it as a checklist — the user might already have inputs sorted but be stuck on elements; jump there. The structure exists so nothing gets dropped, not so everything gets ceremonially recited.
BABOK names 50 techniques (Chapter 10). They span elicitation aids (Interviews, Workshops, Observation, Focus Groups, Survey/Questionnaire), modelling tools (Process Modelling, Data Modelling, Decision Modelling, State Modelling, Sequence Diagrams, Use Cases & Scenarios, User Stories, Data Flow Diagrams), analytical lenses (SWOT, Root Cause Analysis, Decision Analysis, Risk Analysis, Financial Analysis, Business Capability Analysis, Business Model Canvas), governance/management (Backlog Management, Item Tracking, Reviews, Roles & Permissions Matrix, Lessons Learned, Vendor Assessment), and reference structures (Glossary, Data Dictionary, Concept Modelling, Acceptance & Evaluation Criteria, Non-Functional Requirements Analysis, Metrics & KPIs, Balanced Scorecard).
For the full list with purposes and when to use each, see references/techniques-catalog.md.
For "which techniques officially pair with which task" (BABOK Appendix B mapping), see references/techniques-to-task-map.md. This is the recommendation engine — when the user is on a specific task, this map tells you the formally-paired techniques to draw from.
How to recommend techniques: name 2–4, briefly say why each one fits this user's situation, and let them pick. Don't list 10. The point of curation is to remove choices, not to add them.
BABOK names 5 perspectives — specialized lenses for applying business analysis in particular contexts. They're not mutually exclusive. Most real initiatives engage at least one; many engage two or three.
| Perspective | When to apply |
|---|---|
| Agile | Iterative delivery, evolving requirements, empowered cross-functional teams, continuous stakeholder collaboration |
| Business Intelligence | Decisions on data and analytics platforms, KPIs, reporting, data warehousing, ML-adjacent initiatives |
| Information Technology | IT-driven change — software delivery, system integration, infrastructure, technical architecture work |
| Business Architecture | Enterprise-wide change — capability mapping, value streams, organizational design, strategic alignment |
| Business Process Management | Process-centric change — process discovery, modelling, improvement, automation, governance |
For full perspective profiles (change scope, BA scope, methodologies, competencies, KA impact), see references/perspectives.md.
How to apply a perspective: if the user names one, use it as a lens on the task — it changes who the stakeholders are, what techniques fit, what outputs look like, and how you measure success. If the user hasn't named one but the answer clearly matters (e.g., they're doing requirements work for a Scrum team), name the perspective gently and ask if they want that lens applied.
BABOK names 6 underlying competencies — the soft skills and knowledge that make a business analyst effective. These don't usually drive a conversation, but they're useful for self-assessment, mentoring, role design, and explaining why some BA work is hard:
For depth, see references/competencies.md. Surface these only when the user asks about BA capability, role design, mentoring, or "why is this hard for me?"
These are how to use the skill, not what's in BABOK.
Coach, don't recite. BABOK is a body of knowledge, not a script. The user has a real situation. Translate. Ask questions. Use BABOK's structure to make sure nothing gets dropped, but the conversation should feel like working with a thoughtful BA peer, not reading the textbook.
Cite the source when it earns its place. Naming the KA/task/technique by its BABOK identifier (e.g., "this is Task 4.2 Conduct Elicitation, and the relevant techniques here include Interviews and Observation") is useful — it gives the user a mental hook to look it up later. Avoid ceremonial citation that doesn't help.
Stay anchored in the BACCM. When a conversation drifts, return to "what's the change, what's the need, what's the value, who are the stakeholders, what's the context, and what's the solution we're considering?" Six questions. They reset everything.
Respect the user's time. Quick mode is the default for unfamiliar users. Don't escalate to Full unless the user asks or the situation clearly needs it. A great Quick-mode conversation that ends in "want me to run a Working session on Task X next?" beats an unwanted deep dive.
Use the references on demand. SKILL.md is the orchestrator. The reference files are deep. Read a reference file when you're committed to walking the user through that piece — not as background reading.
Don't reproduce BABOK verbatim. This skill distils and applies the methodology. The full text belongs to IIBA. Paraphrase liberally, name tasks/techniques by their BABOK numbers and titles, but don't reproduce the source language at length.
babok-skill/
├── SKILL.md ← this file (orchestrator)
└── references/
├── ka-1-planning-monitoring.md ← KA 3: 5 tasks
├── ka-2-elicitation-collaboration.md ← KA 4: 5 tasks
├── ka-3-requirements-lifecycle.md ← KA 5: 5 tasks
├── ka-4-strategy-analysis.md ← KA 6: 4 tasks
├── ka-5-requirements-analysis-design.md ← KA 7: 6 tasks
├── ka-6-solution-evaluation.md ← KA 8: 5 tasks
├── techniques-catalog.md ← all 50 techniques, brief
├── perspectives.md ← all 5 perspectives, profile each
├── competencies.md ← 6 underlying competencies
└── techniques-to-task-map.md ← Appendix B cross-referenceRead each reference file only when its content is about to be used. Don't pre-load.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.