Update to Kowalah

{
  "description": "Read one business process honestly — where its cycle time actually goes, how many handoffs it has, and what has never been measured. Use for \"walk me through this process\", \"why does this take so long\", \"where are the bottlenecks in X\", or before proposing any change to a process.",
  "included_files": [],
  "name": "process-diagnostic",
  "skill_md_contents": "---\nname: process-diagnostic\ndescription: Read one business process honestly — where its cycle time actually goes, how many handoffs it has, and what has never been measured. Use for \"walk me through this process\", \"why does this take so long\", \"where are the bottlenecks in X\", or before proposing any change to a process.\n---\n\n# Process diagnostic\n\nFor the person who owns a process and has to decide what to do about it. This is the read\nthat comes before any redesign. Run it first — `process-redesign` assumes it.\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## Sequence\n\n1. **`kowalah_get_process`** with the process UUID. If you do not have the UUID, get it\n   from `kowalah_get_operating_model_unit` (the unit's process list) or\n   `kowalah_get_update`.\n2. **Read the `diagnosis` block first** — before the steps, before the roll-up. It is the\n   derived read of how well the process is actually captured, and it decides whether the\n   rest of the data can be trusted.\n3. **Check `access`** before offering to change anything.\n4. Narrate the chain: steps in order, current→target dispositions, gap and constraint\n   markers, the DEFINE contract on each step, and the ranked `backlog`.\n\n## The counting rule that governs everything\n\n**A null is \"can't say\". It is never \"none\".**\n\nThis is the single most important thing to get right, and the easiest to get wrong, because\na null renders as an absence and an absence reads as a clean bill of health.\n\n- `handoff_count` is null whenever *any* step lacks an owner. A partial count would\n  understate the handoffs — and the handoffs are where the waiting is. When it is null,\n  say so and ask for the missing owners. Do not describe the process as though it flowed\n  straight through.\n- `cycle.ratio` is null unless *every* step is both timed and costed. A ratio built from\n  three of twelve steps makes a process look tighter than it is.\n- `touch_minutes_total` is a **floor**, not a total. Read it alongside\n  `steps_missing_touch`. \"At least 40 minutes, across the eight steps anyone has timed\" is\n  honest; \"40 minutes\" is not.\n\n## Work is measured in minutes. Processes are measured in days.\n\n`cycle.ratio` is touch time over elapsed time across the whole chain. **When it is there,\nlead with it.**\n\nA process that is 0.4% work and 99.6% waiting cannot be fixed by making the work faster.\nThat is usually the entire finding, and it reframes the conversation from \"can AI do this\nstep quicker\" to \"why does this sit for six days between steps\". Automating a step inside a\nprocess that is 99% waiting moves nothing.\n\n**When `cycle.ratio` is null, the missing timings are the finding.** Do not skip past it to\nthe parts you can measure. `cycle.steps_untimed` gives you the sentence: *\"nine of twelve\nsteps have never been timed end to end — we cannot say where this process spends its\ntime, and that is the first thing to fix.\"* That is a more useful output than a confident\nread of the three steps that happen to have data.\n\n## The rest of the diagnosis block\n\n- `constraint_steps` — steps marked as constraining the whole chain. These rank highest in\n  the redesign backlog and are where effort actually pays.\n- `steps_missing_output` and `steps_missing_acceptance_criteria` — the DEFINE contract\n  gaps. A step with no defined output artifact or no acceptance criteria cannot be handed\n  to AI, because there is no bar to hold it to. Route these to `quality-bar`.\n- `steps_with_exception_notes` — where the documented process and the real one diverge.\n  Worth reading aloud; exception notes are usually where the actual work happens.\n- `chased_steps` — steps that need chasing. Chasing is coordination burden, and it is\n  invisible in touch time.\n\n## Use it to challenge, not just to report\n\nThe diagnosis is a set of questions to put to the owner, not a summary to read back. Good\nchallenges:\n\n- \"Four different people own steps in this chain. What happens between step 3 and step 4?\"\n- \"Six of these steps have no acceptance criteria. How does anyone know when they're done\n  right?\"\n- \"The constraint is step 7, but the two initiatives aimed at this process both target\n  step 2.\"\n- \"This is 12 minutes of work spread across 9 days. What are we actually trying to fix?\"\n\n## Before offering to change anything\n\n`access` reports what this user may do to this process: `relationship`\n(`at_own` / `below` / `at_peer` / `above` / `lateral`), `can_edit`, `can_create`,\n`can_propose`.\n\n**When `can_edit` is false, the route is `kowalah_propose_process_change`, not an edit that\nwill be refused.** Say which route you are taking and why — \"this process is owned by\nOperations, so I'll file this as a proposal for its owner rather than editing it\" is a\nuseful sentence, not an apology.\n\n`initiatives` lists the opportunities, deliverables and projects already aimed at this\nprocess, pinned to a step where relevant. It is filtered to what this user may personally\nsee, so it can legitimately differ between colleagues — do not present it as the complete\nlist of work on this process.\n\n## When an agent or tool runs a step\n\nA step whose `platform_detail` names an agent or tool (\"Brian drafts the reply\", \"the\nKoko skill triages enquiries\") but whose `implementations` are empty has the tool only in\nfree text. Offer to record it properly: `kowalah_get_ai_estate` to find the asset (or\n`kowalah_record_ai_assets` to add it, if the user confirms it exists), with\n`serves_step_ids` pointing at the step. Then the estate can say which steps depend on it,\nand the step can say what runs it.\n\n## What the process has delivered\n\n`outcomes` lists the value recorded on the process and its steps, with `totals` per unit.\nClaimed and verified are kept apart, and so are one-off and recurring. Read it alongside\nthe timings: a step that has had AI on it for months with no outcome recorded isn't a step\nwhere nothing improved. Nobody has said what improved. Ask, and if the user knows, record\nit (`outcomes` skill).\n\n## Where to go next\n\n- The process needs restructuring, not just better paint → `process-redesign`\n- Steps lack acceptance criteria or quality checks → `quality-bar`\n- Something needs to go to the Kowalah team → `raise-opportunity`\n- Someone reports a saving or a win on this process → `outcomes`\n"
}