← KowalahCONTENT HISTORY

Update to Kowalah

Snapshot Oct 25, 2026 · 12:04 UTC · version 1.0.1

Collection source: downloaded plugin package.

WHAT CHANGED

Instructions updated for programme-review

Skill instructions — Now says: **`kowalah_get_operating_model`** with `view: "rows"` — the whole model in one call: every unit with its subtree roll-up, every process with its...

Observed in instructions or declared skills. Runtime behavior has not been tested.

Save Kowalah and check future changes in Following.

Up to 10 plugins free · no card required.

All fields and original values.

Skill instructions

Before

Oct 24, 2026 · 13:35 UTC

**`kowalah_get_operating_model_unit`** on each of those — its subtree roll-up, the processes it owns, and `topBacklog`, the ranked redesign backlog across its processes.

After

Oct 25, 2026 · 12:04 UTC

**`kowalah_get_operating_model`** with `view: "rows"` — the whole model in one call: every unit with its subtree roll-up, every process with its `readiness`, the organisation's ranked redesign backlog (each item naming its process ...

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -33,8 +33,12 @@
    roll-ups on every node, org-wide totals, and a `vision` block if one has been authored.
 2. **Read the totals properly** (see below). Pick the two or three units where the
    constraints and redesign gaps actually concentrate.
-3. **`kowalah_get_operating_model_unit`** on each of those — its subtree roll-up, the
-   processes it owns, and `topBacklog`, the ranked redesign backlog across its processes.
+3. **`kowalah_get_operating_model`** with `view: "rows"` — the whole model in one call:
+   every unit with its subtree roll-up, every process with its `readiness`, the
+   organisation's ranked redesign backlog (each item naming its process and unit) and the
+   open questions. Read the units you picked from it, rather than opening them one at a
+   time. If the connector doesn't accept `view: "rows"`, it's an older version: call
+   `kowalah_get_operating_model_unit` on each of those units instead.
 4. **`kowalah_get_update`** with no query — the portfolio of what is actually in flight:
    projects, deliverables, expert requests, opportunities, client-visible risks.
 5. **Cross-reference.** For each significant in-flight item, name the unit and process it
Full technical diff · 1 changed fields

changed /skill_md_contents

BEFORE
"---\nname: programme-review\ndescription: Review the state of an AI operating model programme — coverage, where constraints concentrate, and whether the work in flight is aimed at the actual gaps. Use for \"how is our AI programme going\", \"where are we with AI\", \"what should we do next\", \"prep me for the steering group\", or any org-wide or divisional read of AI progress.\n---\n\n# Programme review\n\nFor the person accountable for AI across an organisation or a division: the AI programme\nlead, the core team, the exec sponsor. The job is to say where the programme actually is\nand what should happen next — not to recite a dashboard.\n\n## Read the model before you ask\n\nThe operating model already holds the owners, the steps, the timings, the constraints, the\nquality bars and the work in flight. **Ask the user only for what it doesn't have.**\nQuestioning someone about a process the model already describes wastes their time and\ntells them you didn't look.\n\nWhere the model is missing something, that absence is usually the finding — say what isn't\nrecorded rather than quietly filling the gap from conversation.\n\n## The one failure mode this skill exists to prevent\n\n**A portfolio of initiatives aimed at places that had no gap.** It is the most common\nfinding and the least comfortable one. Coverage climbs, everyone reports green, and none\nof the work is pointed at where the business is actually constrained. Every review must\nend by testing the in-flight work against the gaps — not by reporting them on separate\nslides.\n\n## Sequence\n\n1. **`kowalah_get_operating_model`** — the world view. Returns the unit tree with coverage\n   roll-ups on every node, org-wide totals, and a `vision` block if one has been authored.\n2. **Read the totals properly** (see below). Pick the two or three units where the\n   constraints and redesign gaps actually concentrate.\n3. **`kowalah_get_operating_model_unit`** on each of those — its subtree roll-up, the\n   processes it owns, and `topBacklog`, the ranked redesign backlog across its processes.\n4. **`kowalah_get_update`** with no query — the portfolio of what is actually in flight:\n   projects, deliverables, expert requests, opportunities, client-visible risks.\n5. **Cross-reference.** For each significant in-flight item, name the unit and process it\n   is aimed at. Then name the top-backlog items with nothing pointed at them.\n\nSteps 4 and 5 are not optional. A review that stops at step 3 is a coverage report.\n\n## Reading coverage honestly\n\n**Coverage % is the vanity metric.** It says how much of the mapped business has processes\nrecorded against it. It says nothing about whether those processes are any good, whether\nanyone is working on them, or whether the ones that matter are covered. Never lead with it.\n\n**Lead with where constraints concentrate.** The roll-ups carry `constraint count` and\n`redesign-gap count` across each unit's whole subtree. A unit at 80% coverage with fifteen\nconstraints is in worse shape than one at 40% with two. Say that plainly.\n\n**Mind the denominator.** Roll-ups cover what has been *mapped*. A division with no\nprocesses recorded shows no constraints — not because it has none, but because nobody has\nlooked. If a unit's process count is zero or near it, that absence is the finding. Do not\nlet an unmapped unit read as a healthy one.\n\n**Coverage moving is not progress.** Mapping more processes raises coverage without\nchanging anything about how the business runs. Progress is constraints closing and\nredesigns landing. If coverage rose and the constraint count did not fall, say so.\n\n## Using the vision map\n\nWhen a `vision` block comes back, it carries the vision statement, the guiding principles,\nand the programme success measures — in the organisation's own words, from their AI Vision\nDay.\n\nEach principle has defining attributes as an assertion plus a counter-clause: *\"It moves a\nbusiness KPI.\" / \"Not a good idea in search of one.\"* **That pair is the test.** Apply both\nhalves. The counter-clause is the half that does the work — it is what lets you say a\npiece of in-flight work is off-vision without it being an opinion.\n\nQuote the principles in their own words. Do not paraphrase them into generic AI-strategy\nlanguage; the specific wording is the thing the organisation agreed to.\n\nWhen `kowalah_get_operating_model_unit` returns a vision with `ownership: \"inherited\"`, say\nwhose it is — \"you are working to the group vision, this division hasn't authored its own\"\nis itself a finding worth surfacing.\n\n**Read the success measures as numbers where they have them.** From `kowalah_get_vision`,\neach measure carries a numeric baseline, target and current reading, when these have been\nset, and `progress` towards the target. The text baseline and target are the workshop's\nwords, so quote those. Report the numbers as progress. Check when the current reading was\ntaken (`currentMeasuredAt`): a measure with no current reading hasn't been read, which is\nnot the same as not having moved. Where outcomes have been recorded against a measure, the\n`outcomes` skill can show what's behind the movement.\n\n**Check `lastUpdatedAt` on the vision block, and say how old it is.** A vision is the\nfoundation every other judgement in this review rests on, so its age changes what the\nreview means. Coverage that doubled against principles nobody has revisited in a year is\nnot obviously progress — it may be a year of work aimed at last year's priorities. Put the\ndate in the review: *\"these principles were last authored in March, and the portfolio has\nturned over twice since.\"* If it looks stale, the next decision may be re-authoring the\nvision rather than adding to the backlog.\n\n## What a good review says\n\nFour things, in this order:\n\n1. **Where the business is constrained** — named units, named processes, with numbers.\n2. **Whether the work in flight is aimed there** — the cross-reference from step 5, with\n   both the hits and the misses.\n3. **What is unmapped** — where you cannot say anything because nobody has looked.\n4. **The next decision** — not a list of everything possible; the one or two things that\n   would change the picture, and who has to decide.\n\nWhere the user wants to act on a gap, hand off to `raise-opportunity` rather than writing\nthe opportunity inline — it checks the accelerator library first and gets the ICE score and\nvision test right.\n\n## Scope and permissions\n\n`kowalah_get_update` returns different things by role. Admins and core team see everything\nin the organisation; members see only their own opportunities plus items they are a\nstakeholder on. If the user is a member, the portfolio view is partial by design — say so\nrather than presenting it as the whole picture.\n\nIf the user belongs to more than one Kowalah organisation, the model tools need an\n`organization_id`. Call `kowalah_get_update` with no query first to list their\norganisations, then ask which one — do not guess.\n\nIf either model tool returns `kind: \"empty\"`, no operating model or vision has been mapped\nyet. That is Define-phase work their Kowalah team does with them; say that rather than\noffering to map it from scratch here.\n\nOne thing to rule out first: a model showing **one unit and zero processes**, where the\nuser is the sole `admin` of a single organisation and no vision exists, is not an unmapped\nclient. A new organisation was created for this account instead of it joining the\ncompany's existing one. That is the normal state for someone self-serving with no\nengagement, in which case there is no programme to review yet and the useful offer is to\nhelp them map one. It is the wrong place for someone whose company already works with\nKowalah. Judge the shape, not the name: a newly-created organisation is named from the\nsigner-up's email domain, so it can carry the company's own name and still be empty. See\nthe `kowalah-setup` skill.\n"
AFTER
"---\nname: programme-review\ndescription: Review the state of an AI operating model programme — coverage, where constraints concentrate, and whether the work in flight is aimed at the actual gaps. Use for \"how is our AI programme going\", \"where are we with AI\", \"what should we do next\", \"prep me for the steering group\", or any org-wide or divisional read of AI progress.\n---\n\n# Programme review\n\nFor the person accountable for AI across an organisation or a division: the AI programme\nlead, the core team, the exec sponsor. The job is to say where the programme actually is\nand what should happen next — not to recite a dashboard.\n\n## Read the model before you ask\n\nThe operating model already holds the owners, the steps, the timings, the constraints, the\nquality bars and the work in flight. **Ask the user only for what it doesn't have.**\nQuestioning someone about a process the model already describes wastes their time and\ntells them you didn't look.\n\nWhere the model is missing something, that absence is usually the finding — say what isn't\nrecorded rather than quietly filling the gap from conversation.\n\n## The one failure mode this skill exists to prevent\n\n**A portfolio of initiatives aimed at places that had no gap.** It is the most common\nfinding and the least comfortable one. Coverage climbs, everyone reports green, and none\nof the work is pointed at where the business is actually constrained. Every review must\nend by testing the in-flight work against the gaps — not by reporting them on separate\nslides.\n\n## Sequence\n\n1. **`kowalah_get_operating_model`** — the world view. Returns the unit tree with coverage\n   roll-ups on every node, org-wide totals, and a `vision` block if one has been authored.\n2. **Read the totals properly** (see below). Pick the two or three units where the\n   constraints and redesign gaps actually concentrate.\n3. **`kowalah_get_operating_model`** with `view: \"rows\"` — the whole model in one call:\n   every unit with its subtree roll-up, every process with its `readiness`, the\n   organisation's ranked redesign backlog (each item naming its process and unit) and the\n   open questions. Read the units you picked from it, rather than opening them one at a\n   time. If the connector doesn't accept `view: \"rows\"`, it's an older version: call\n   `kowalah_get_operating_model_unit` on each of those units instead.\n4. **`kowalah_get_update`** with no query — the portfolio of what is actually in flight:\n   projects, deliverables, expert requests, opportunities, client-visible risks.\n5. **Cross-reference.** For each significant in-flight item, name the unit and process it\n   is aimed at. Then name the top-backlog items with nothing pointed at them.\n\nSteps 4 and 5 are not optional. A review that stops at step 3 is a coverage report.\n\n## Reading coverage honestly\n\n**Coverage % is the vanity metric.** It says how much of the mapped business has processes\nrecorded against it. It says nothing about whether those processes are any good, whether\nanyone is working on them, or whether the ones that matter are covered. Never lead with it.\n\n**Lead with where constraints concentrate.** The roll-ups carry `constraint count` and\n`redesign-gap count` across each unit's whole subtree. A unit at 80% coverage with fifteen\nconstraints is in worse shape than one at 40% with two. Say that plainly.\n\n**Mind the denominator.** Roll-ups cover what has been *mapped*. A division with no\nprocesses recorded shows no constraints — not because it has none, but because nobody has\nlooked. If a unit's process count is zero or near it, that absence is the finding. Do not\nlet an unmapped unit read as a healthy one.\n\n**Coverage moving is not progress.** Mapping more processes raises coverage without\nchanging anything about how the business runs. Progress is constraints closing and\nredesigns landing. If coverage rose and the constraint count did not fall, say so.\n\n## Using the vision map\n\nWhen a `vision` block comes back, it carries the vision statement, the guiding principles,\nand the programme success measures — in the organisation's own words, from their AI Vision\nDay.\n\nEach principle has defining attributes as an assertion plus a counter-clause: *\"It moves a\nbusiness KPI.\" / \"Not a good idea in search of one.\"* **That pair is the test.** Apply both\nhalves. The counter-clause is the half that does the work — it is what lets you say a\npiece of in-flight work is off-vision without it being an opinion.\n\nQuote the principles in their own words. Do not paraphrase them into generic AI-strategy\nlanguage; the specific wording is the thing the organisation agreed to.\n\nWhen `kowalah_get_operating_model_unit` returns a vision with `ownership: \"inherited\"`, say\nwhose it is — \"you are working to the group vision, this division hasn't authored its own\"\nis itself a finding worth surfacing.\n\n**Read the success measures as numbers where they have them.** From `kowalah_get_vision`,\neach measure carries a numeric baseline, target and current reading, when these have been\nset, and `progress` towards the target. The text baseline and target are the workshop's\nwords, so quote those. Report the numbers as progress. Check when the current reading was\ntaken (`currentMeasuredAt`): a measure with no current reading hasn't been read, which is\nnot the same as not having moved. Where outcomes have been recorded against a measure, the\n`outcomes` skill can show what's behind the movement.\n\n**Check `lastUpdatedAt` on the vision block, and say how old it is.** A vision is the\nfoundation every other judgement in this review rests on, so its age changes what the\nreview means. Coverage that doubled against principles nobody has revisited in a year is\nnot obviously progress — it may be a year of work aimed at last year's priorities. Put the\ndate in the review: *\"these principles were last authored in March, and the portfolio has\nturned over twice since.\"* If it looks stale, the next decision may be re-authoring the\nvision rather than adding to the backlog.\n\n## What a good review says\n\nFour things, in this order:\n\n1. **Where the business is constrained** — named units, named processes, with numbers.\n2. **Whether the work in flight is aimed there** — the cross-reference from step 5, with\n   both the hits and the misses.\n3. **What is unmapped** — where you cannot say anything because nobody has looked.\n4. **The next decision** — not a list of everything possible; the one or two things that\n   would change the picture, and who has to decide.\n\nWhere the user wants to act on a gap, hand off to `raise-opportunity` rather than writing\nthe opportunity inline — it checks the accelerator library first and gets the ICE score and\nvision test right.\n\n## Scope and permissions\n\n`kowalah_get_update` returns different things by role. Admins and core team see everything\nin the organisation; members see only their own opportunities plus items they are a\nstakeholder on. If the user is a member, the portfolio view is partial by design — say so\nrather than presenting it as the whole picture.\n\nIf the user belongs to more than one Kowalah organisation, the model tools need an\n`organization_id`. Call `kowalah_get_update` with no query first to list their\norganisations, then ask which one — do not guess.\n\nIf either model tool returns `kind: \"empty\"`, no operating model or vision has been mapped\nyet. That is Define-phase work their Kowalah team does with them; say that rather than\noffering to map it from scratch here.\n\nOne thing to rule out first: a model showing **one unit and zero processes**, where the\nuser is the sole `admin` of a single organisation and no vision exists, is not an unmapped\nclient. A new organisation was created for this account instead of it joining the\ncompany's existing one. That is the normal state for someone self-serving with no\nengagement, in which case there is no programme to review yet and the useful offer is to\nhelp them map one. It is the wrong place for someone whose company already works with\nKowalah. Judge the shape, not the name: a newly-created organisation is named from the\nsigner-up's email domain, so it can carry the company's own name and still be empty. See\nthe `kowalah-setup` skill.\n"
Full snapshot data
{
  "description": "Review the state of an AI operating model programme — coverage, where constraints concentrate, and whether the work in flight is aimed at the actual gaps. Use for \"how is our AI programme going\", \"where are we with AI\", \"what should we do next\", \"prep me for the steering group\", or any org-wide or divisional read of AI progress.",
  "included_files": [],
  "name": "programme-review",
  "skill_md_contents": "---\nname: programme-review\ndescription: Review the state of an AI operating model programme — coverage, where constraints concentrate, and whether the work in flight is aimed at the actual gaps. Use for \"how is our AI programme going\", \"where are we with AI\", \"what should we do next\", \"prep me for the steering group\", or any org-wide or divisional read of AI progress.\n---\n\n# Programme review\n\nFor the person accountable for AI across an organisation or a division: the AI programme\nlead, the core team, the exec sponsor. The job is to say where the programme actually is\nand what should happen next — not to recite a dashboard.\n\n## Read the model before you ask\n\nThe operating model already holds the owners, the steps, the timings, the constraints, the\nquality bars and the work in flight. **Ask the user only for what it doesn't have.**\nQuestioning someone about a process the model already describes wastes their time and\ntells them you didn't look.\n\nWhere the model is missing something, that absence is usually the finding — say what isn't\nrecorded rather than quietly filling the gap from conversation.\n\n## The one failure mode this skill exists to prevent\n\n**A portfolio of initiatives aimed at places that had no gap.** It is the most common\nfinding and the least comfortable one. Coverage climbs, everyone reports green, and none\nof the work is pointed at where the business is actually constrained. Every review must\nend by testing the in-flight work against the gaps — not by reporting them on separate\nslides.\n\n## Sequence\n\n1. **`kowalah_get_operating_model`** — the world view. Returns the unit tree with coverage\n   roll-ups on every node, org-wide totals, and a `vision` block if one has been authored.\n2. **Read the totals properly** (see below). Pick the two or three units where the\n   constraints and redesign gaps actually concentrate.\n3. **`kowalah_get_operating_model`** with `view: \"rows\"` — the whole model in one call:\n   every unit with its subtree roll-up, every process with its `readiness`, the\n   organisation's ranked redesign backlog (each item naming its process and unit) and the\n   open questions. Read the units you picked from it, rather than opening them one at a\n   time. If the connector doesn't accept `view: \"rows\"`, it's an older version: call\n   `kowalah_get_operating_model_unit` on each of those units instead.\n4. **`kowalah_get_update`** with no query — the portfolio of what is actually in flight:\n   projects, deliverables, expert requests, opportunities, client-visible risks.\n5. **Cross-reference.** For each significant in-flight item, name the unit and process it\n   is aimed at. Then name the top-backlog items with nothing pointed at them.\n\nSteps 4 and 5 are not optional. A review that stops at step 3 is a coverage report.\n\n## Reading coverage honestly\n\n**Coverage % is the vanity metric.** It says how much of the mapped business has processes\nrecorded against it. It says nothing about whether those processes are any good, whether\nanyone is working on them, or whether the ones that matter are covered. Never lead with it.\n\n**Lead with where constraints concentrate.** The roll-ups carry `constraint count` and\n`redesign-gap count` across each unit's whole subtree. A unit at 80% coverage with fifteen\nconstraints is in worse shape than one at 40% with two. Say that plainly.\n\n**Mind the denominator.** Roll-ups cover what has been *mapped*. A division with no\nprocesses recorded shows no constraints — not because it has none, but because nobody has\nlooked. If a unit's process count is zero or near it, that absence is the finding. Do not\nlet an unmapped unit read as a healthy one.\n\n**Coverage moving is not progress.** Mapping more processes raises coverage without\nchanging anything about how the business runs. Progress is constraints closing and\nredesigns landing. If coverage rose and the constraint count did not fall, say so.\n\n## Using the vision map\n\nWhen a `vision` block comes back, it carries the vision statement, the guiding principles,\nand the programme success measures — in the organisation's own words, from their AI Vision\nDay.\n\nEach principle has defining attributes as an assertion plus a counter-clause: *\"It moves a\nbusiness KPI.\" / \"Not a good idea in search of one.\"* **That pair is the test.** Apply both\nhalves. The counter-clause is the half that does the work — it is what lets you say a\npiece of in-flight work is off-vision without it being an opinion.\n\nQuote the principles in their own words. Do not paraphrase them into generic AI-strategy\nlanguage; the specific wording is the thing the organisation agreed to.\n\nWhen `kowalah_get_operating_model_unit` returns a vision with `ownership: \"inherited\"`, say\nwhose it is — \"you are working to the group vision, this division hasn't authored its own\"\nis itself a finding worth surfacing.\n\n**Read the success measures as numbers where they have them.** From `kowalah_get_vision`,\neach measure carries a numeric baseline, target and current reading, when these have been\nset, and `progress` towards the target. The text baseline and target are the workshop's\nwords, so quote those. Report the numbers as progress. Check when the current reading was\ntaken (`currentMeasuredAt`): a measure with no current reading hasn't been read, which is\nnot the same as not having moved. Where outcomes have been recorded against a measure, the\n`outcomes` skill can show what's behind the movement.\n\n**Check `lastUpdatedAt` on the vision block, and say how old it is.** A vision is the\nfoundation every other judgement in this review rests on, so its age changes what the\nreview means. Coverage that doubled against principles nobody has revisited in a year is\nnot obviously progress — it may be a year of work aimed at last year's priorities. Put the\ndate in the review: *\"these principles were last authored in March, and the portfolio has\nturned over twice since.\"* If it looks stale, the next decision may be re-authoring the\nvision rather than adding to the backlog.\n\n## What a good review says\n\nFour things, in this order:\n\n1. **Where the business is constrained** — named units, named processes, with numbers.\n2. **Whether the work in flight is aimed there** — the cross-reference from step 5, with\n   both the hits and the misses.\n3. **What is unmapped** — where you cannot say anything because nobody has looked.\n4. **The next decision** — not a list of everything possible; the one or two things that\n   would change the picture, and who has to decide.\n\nWhere the user wants to act on a gap, hand off to `raise-opportunity` rather than writing\nthe opportunity inline — it checks the accelerator library first and gets the ICE score and\nvision test right.\n\n## Scope and permissions\n\n`kowalah_get_update` returns different things by role. Admins and core team see everything\nin the organisation; members see only their own opportunities plus items they are a\nstakeholder on. If the user is a member, the portfolio view is partial by design — say so\nrather than presenting it as the whole picture.\n\nIf the user belongs to more than one Kowalah organisation, the model tools need an\n`organization_id`. Call `kowalah_get_update` with no query first to list their\norganisations, then ask which one — do not guess.\n\nIf either model tool returns `kind: \"empty\"`, no operating model or vision has been mapped\nyet. That is Define-phase work their Kowalah team does with them; say that rather than\noffering to map it from scratch here.\n\nOne thing to rule out first: a model showing **one unit and zero processes**, where the\nuser is the sole `admin` of a single organisation and no vision exists, is not an unmapped\nclient. A new organisation was created for this account instead of it joining the\ncompany's existing one. That is the normal state for someone self-serving with no\nengagement, in which case there is no programme to review yet and the useful offer is to\nhelp them map one. It is the wrong place for someone whose company already works with\nKowalah. Judge the shape, not the name: a newly-created organisation is named from the\nsigner-up's email domain, so it can carry the company's own name and still be empty. See\nthe `kowalah-setup` skill.\n"
}

SHA-256 of public snapshot: 78a6790aa84b1a795b1e2d80d1a50e5464da9ffce67de6f94f4df249ef2c771a