ba-capability-mapping-21e229 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited ba-capability-mapping-21e229 (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
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.
Note: This skill follows the PlausibleBA Taxonomy Standard. Column order, numbering format, XLSX colours, MECE rules, and ID conventions are all defined there. Read that skill first if anything here is unclear.
Produce a rigorous, reusable Capability Map from any input — transcripts, charters, existing spreadsheets, industry reference models, or a mix. Output is a downloadable XLSX with a structured taxonomy, plus an inline preview for iteration.
Capabilities are the foundation of business architecture. Getting the hierarchy right before mapping value streams, processes, or technology is what makes downstream work consistent and investment-relevant.
A Business Capability is the stable ability of the organisation to perform a business function, grounded in a core business object, independent of organisational structure.
| Rule | Meaning |
|---|---|
| Object-grounded | An explicit business object must be identifiable for each capability |
| Enduring | Not project-based; survives organisational restructures |
| Not a process step | Describes what the org can do, never how it does it |
| Mutually exclusive | No two capabilities at the same level overlap in scope |
| Collectively exhaustive | Together, siblings cover the full scope of their parent — no gaps |
| Verb–Noun naming | Preferred convention, e.g. "Manage Certification Portfolio" |
Naming guidance:
L1 Business Area Broad accountability domain (e.g. "Customer Management")
L2 Business Domain Logical grouping within the area (e.g. "Customer Acquisition")
L3 Business Capability Operational ability (e.g. "Manage Lead Qualification")
L4 Sub-capability Optional — used for VSS mapping in complex domainsSizing guidance:
Important: L1 and L2 are structural groupings — they organise and label. L3 is where the actual capability lives. L4 is only added when value stream stage mapping requires it.
Every node in the hierarchy carries a positional number that encodes its place in the schema. This is the primary sort key — sorting by Number reveals the full hierarchy at a glance and is far easier to validate than grouping by level.
Format: <L1>.<L2>.<L3>.<L4> — dot-separated integers, one segment per level.
1 ← L1: First Business Area
1.1 ← L2: First Domain within Area 1
1.1.1 ← L3: First Capability within Domain 1.1
1.1.2 ← L3: Second Capability within Domain 1.1
1.2 ← L2: Second Domain within Area 1
1.2.1 ← L3: First Capability within Domain 1.2
2 ← L1: Second Business Area
2.1 ← L2: First Domain within Area 2
2.1.1 ← L3: First Capability within Domain 2.1
2.1.1.1 ← L4: First Sub-capability (only if needed)Rules:
This skill accepts inputs in any form or combination:
| Input Type | What to extract |
|---|---|
| Discovery transcript / interview notes | Business objects mentioned, pain points, decision points, handoffs |
| Project charter / scope document | Stated objectives, in-scope functions, stakeholder responsibilities |
| Existing Excel capability model | Current names — validate/reclassify against rules above |
| Industry reference model (BIAN, ACORD, eTOM, SCOR) | Adapt, do not copy wholesale |
| Verbal / ad-hoc description | Infer domain; ask one focused clarifying question if ambiguous |
If input is sparse, ask one clarifying question before proceeding. Never ask multiple questions at once.
Batching guidance: For large or multi-domain inputs, process 5–8 L2 domains at a time to maintain coherence and avoid drift. Run a consistency pass across the full set before finalising.
⚠️ Always run this skill in a fresh Cowork task. Prior conversation context will cause Claude to reference previous outputs rather than eliciting from the current input. Open a new task, paste the business description, then type the slash command.
Identify from input (or ask):
Before naming capabilities, list the primary objects the organisation manages. These ground the L3 capabilities and are the foundation of a future Concept Model.
Examples by sector:
Derive Business Areas (L1) and Business Domains (L2) first.
Present as a numbered table sorted by taxonomy number and ask:
"Here is a draft L1/L2 hierarchy of Business Areas and Domains. Does this look like something your business teams would recognise? Any areas missing, or any that feel like they belong inside another?"
Do not proceed to L3 until this is confirmed or adjusted.
Assign stable taxonomy numbers before presenting. If the client reorganises L1/L2 at this checkpoint, renumber sequentially before proceeding.
For each confirmed L2 Business Domain, ask: "What stable abilities does the organisation need within this domain?"
Apply MECE check before finalising:
Ground each L3 in a named business object from Step 2. If a capability candidate cannot be grounded in a business object, it is likely a process step — reclassify or discard.
Include both:
Run a uniqueness check before presenting: scan all L3 names for semantic overlap across domains. "Manage Customer Communication" appearing under both Acquisition and Retention is a MECE failure — either merge them under a shared parent or redefine scope boundaries.
Present the full numbered map (sorted by Number) and ask:
"Here are the Business Capabilities within each domain. Do these reflect how your organisation thinks about its abilities? Any that feel like process steps rather than stable abilities, or any gaps you'd expect to see?"
After Checkpoint 2 is confirmed, add L4 sub-capabilities only when:
Immediately after Checkpoint 2 is accepted, render an interactive treemap as a self-contained HTML artifact. Do NOT wait for the user to ask. Do NOT generate the XLSX first. The treemap IS the deliverable — XLSX is a download option offered beneath it.
Visual design — match VCC exactly:
#0f172a; L1 body: #111827; L1 header exec: rgba(59,130,246,0.08); gov: rgba(99,102,241,0.08)#1e3a5f; gov: #3730a3; border-radius:8pxfont-size:9px, font-weight:700, color:#cbd5e1, text-transform:uppercase, letter-spacing:0.5pxfont-size:8px, color:#94a3b8 — "N domains · N capabilities"background:rgba(255,255,255,0.05), border:1px solid rgba(255,255,255,0.10), border-radius:5pxfont-size:9px, font-weight:600, color:#94a3b8background:rgba(255,255,255,0.07), border:0.5px solid rgba(255,255,255,0.12), color:#94a3b8, font-size:8px, border-radius:3px, padding:2px 6pxbackground:rgba(59,130,246,0.15), color:#93c5fd, border-color:rgba(59,130,246,0.3)background:rgba(99,102,241,0.15), color:#a5b4fc, border-color:rgba(99,102,241,0.3)'DM Sans', system-ui, sans-serifInspector panel (opens on L3 click — matches VCC):
background:#1e293b, border:1.5px solid #3b82f6 (exec) or #6366f1 (gov), border-radius:8pxfont-size:14px, font-weight:700, color:#f1f5f9font-size:9px, font-weight:700, text-transform:uppercase, color:#3b82f6 — "BUSINESS OBJECT: [name]"font-size:12px, color:#94a3b8Legend row above grid: "Click any L3 tile to inspect · Double-click to rename" hint in color:#94a3b8
Build the data array from capabilities confirmed at Checkpoint 2. Each L1 entry has name, L2 children, each L2 has name and L3 array. Each L3 has: name, business object reference, description. Detect Governance L1s by keywords: governance, compliance, risk, audit, regulatory, data, privacy. Do NOT use PortfolioProp example data.
Include header: eyebrow "CAPABILITY MAP", full title "[Client] — Operating Capabilities", subtitle "N business areas · N domains · N capabilities".
Footer (required on every rendered artifact): Include a footer row at the bottom of the artifact, styled font-size:10px; color:#94a3b8; padding:10px 0 2px; border-top:1px solid #2e3f5c; margin-top:12px:
Generated by the PlausibleBA Skills Library | www.plausibleba.com
Turn this into an interactive workshopping canvas → plausibleba.com/canvasFirst line in color:#94a3b8, second line in color:#4a9eda with the URL as a link.
After rendering the treemap, immediately generate both export files without waiting for the user to ask:
<organisation>_capability_map.xlsx.<organisation>_capability_map.json.Use the present_files MCP tool (if available) to surface the files to the user after saving.
Then present the deliverables and next steps with clickable links:
"Here is your capability map. Hover any L3 tile to highlight it. Blue = Execution; purple = Governance.
>
Downloads: - [View Capability Map XLSX](computer:///<workspace_path>/<organisation>_capability_map.xlsx) — Capability Register workbook (4 tabs) - [View Capability Map JSON](computer:///<workspace_path>/<organisation>_capability_map.json) — VCC pipeline format
>
Build the full business architecture stack: - Type `/concept-model` to derive the Concept Model — identifies the core business objects that ground these capabilities (Party / Record / Resource) - Type `/value-stream` to map Value Streams — orchestrate these capabilities into staged delivery sequences - [Open in PlausibleBA Canvas](https://www.plausibleba.com/canvas) — upload the JSON for full interactive visualisation"
Replace <workspace_path> with the actual workspace output path and <organisation> with the client/organisation name from this session (snake_case for filenames).
Checkpoint 1 — After L1/L2 draft
Sorted by Number. The recognition question is critical — a wrong L1/L2 structure produces a bad map regardless of L3 quality.
Checkpoint 2 — After L3 draft
Full map sorted by Number. Ask whether capabilities feel like stable abilities or process steps, and whether anything is missing.
Post-processing pass before presenting: review all L3 names for consistency of register, length, and naming pattern. Rewrite any that drift from the Verb–Noun convention or feel formulaic.
The map typically stabilises in 2–3 iterations.
Checkpoint 1 — L1/L2 preview (sorted by Number):
| Number | Level | Name |
|---|---|---|
| 1 | L1 | Customer Management |
| 1.1 | L2 | Customer Acquisition |
| 1.2 | L2 | Customer Retention |
| 2 | L1 | Field Operations |
| 2.1 | L2 | Service Delivery |
| 2.2 | L2 | Service Scheduling |
Checkpoint 2 — Full map preview (sorted by Number):
| Number | Level | Name | Business Object | Type |
|---|---|---|---|---|
| 1 | L1 | Customer Management | ||
| 1.1 | L2 | Customer Acquisition | ||
| 1.1.1 | L3 | Manage Lead Qualification | Lead | Execution |
| 1.1.2 | L3 | Manage Channel Partnership | Channel Partner | Execution |
| 1.2 | L2 | Customer Retention | ||
| 1.2.1 | L3 | Manage Contract Renewal | Contract | Execution |
Four worksheets, in this order. The tab order is mandatory — Capability Summary always opens first.
Sheet 1: Capability Summary (client-facing executive view)
This is what the client sees on open. Structure:
[Organisation] — Capability Map (bold, 14pt, dark blue)Rental Property Portfolio Management | v1.0Generated by the PlausibleBA Skills Library | www.plausibleba.com (italic, pale blue background — required on every output)Sheet 2: Capability Register
Branding line above the header row (same format as Summary tab). Pre-sorted by Number — hierarchy visible on open.
| # | Column | Description |
|---|---|---|
| 1 | Number | Taxonomy position e.g. 1.2.3 — sheet is pre-sorted by this column |
| 2 | Level | L1 / L2 / L3 / L4 |
| 3 | Name | Capability name (Verb–Noun), indented by level |
| 4 | Description | "Ability to [verb] [object] [context]" — required for L3/L4 |
| 5 | Business Object | Core object grounding this capability (required for L3/L4) |
| 6 | Type | Execution / Governance |
| 7 | Parent № | Number of parent node (blank for L1) |
| 8 | Parent Name | Parent name (for readability) |
| 9 | ID | cap_<snake_case_name> |
Sheet 3: Validation Summary
| Check | Result | Notes |
|---|---|---|
| All L3 names follow Verb–Noun | PASS/FAIL | |
| All L3 capabilities object-grounded | PASS/FAIL | |
| No process steps at L3 | PASS/FAIL | |
| MECE within each L2 domain (no overlaps) | PASS/FAIL | |
| MECE within each L2 domain (no gaps) | PASS/FAIL | |
| Execution + governance coverage | PASS/NOTE | |
| L1 count within 5–8 | PASS/NOTE | |
| L3 count per L2 within 3–8 | PASS/NOTE | |
| Numbers sort correctly to reproduce hierarchy | PASS/FAIL | |
| No duplicate semantics across domains | PASS/FAIL |
Use NOTE (not FAIL) for acceptable edge cases with justification.
Sheet 4: Legend Colour coding, numbering system, naming conventions, MECE definition, PlausibleBA standard version, website link.
Produce JSON alongside XLSX so output feeds directly into the VCC:
{
"cap_<snake_case_name>": {
"id": "cap_<snake_case_name>",
"elementType": "Capability",
"name": "<Capability Name>",
"number": "1.2.3",
"level": "L1|L2|L3|L4",
"parentId": "cap_<parent>|null",
"parentNumber": "1.2|null",
"businessObject": "<Core Object>",
"description": "Ability to...",
"type": "Execution|Governance"
}
}Required fields: id, elementType, name, number elementType must be exactly: "Capability"
Enterprise Capability Map:
Value-stream-scoped map:
| Failure | Example | Fix |
|---|---|---|
| Activity at L3 | "Assess Credit Applications" | → "Manage Credit Assessment" |
| System named as capability | "Salesforce CRM" | → "Manage Customer Relationships" |
| Org unit at L1 | "Finance Department" | → "Financial Management" |
| L3 too granular | "Email Customer Re: Status" | Roll up to "Manage Customer Communication" |
| L2 too abstract | "Business Operations" | Break down — what domain? what object? |
| Non-MECE: overlapping siblings | "Sales Management" + "New Customer Sales" at same level | Redefine scope boundaries |
| Non-MECE: exhaustiveness gap | Field service domain missing scheduling capability | Add "Manage Service Scheduling" |
| Duplicate semantics across domains | "Manage Customer Communication" in two L2s | Merge under shared parent or redefine scope |
| Numbering doesn't sort to hierarchy | 1.2 appearing before 1.1 | Reassign sequentially |
| L4 added prematurely | L4 added before L3 is confirmed | L4 only after Checkpoint 2 |
Note which reference was used and where capabilities were adapted vs. adopted wholesale:
Next steps are now presented inline with the downloads after the treemap is rendered (see Step 6). The /concept-model and /value-stream commands are offered as clickable follow-on actions, and the XLSX/JSON exports are generated automatically — there is no separate "Export Options" gate.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.