Update to Kowalah

{
  "description": "Take a process from as-is to a proposed to-be — mark up what gets eliminated, merged or kept, then generate the redesign beside the original so the two can be compared. Use for \"redesign this process\", \"how would we do this with AI\", \"these ten steps should be three\", or when a diagnostic shows the process needs restructuring rather than automating.",
  "included_files": [],
  "name": "process-redesign",
  "skill_md_contents": "---\nname: process-redesign\ndescription: Take a process from as-is to a proposed to-be — mark up what gets eliminated, merged or kept, then generate the redesign beside the original so the two can be compared. Use for \"redesign this process\", \"how would we do this with AI\", \"these ten steps should be three\", or when a diagnostic shows the process needs restructuring rather than automating.\n---\n\n# Process redesign\n\nFor a process owner who has diagnosed a process and concluded it needs restructuring. Run\n`process-diagnostic` first — this skill assumes you have the diagnosis and have checked\n`access`.\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## Why this is not a disposition change\n\nA step's disposition — `human`, `ai_assisted`, `automated`, `ai_autonomous` — says **who\nruns the step**. Every one of those values *keeps the step*.\n\nEditing dispositions can only ever produce the same process with better paint. If the\nanswer is \"these ten steps become three\", no amount of disposition editing gets you there.\n`kowalah_propose_redesign` is the tool that can.\n\nSo the first question is always: **is this a redesign, or is this automation?** If the\nshape of the chain is right and individual steps should be run differently, use\n`kowalah_save_process_step` to set target dispositions and stop. If the chain itself is\nwrong, continue here.\n\n## The order matters\n\n**Mark up the real process first. Generate the redesign second.**\n\n`kowalah_propose_redesign` *seeds* the to-be from the as-is and from the redesign decisions\nalready recorded on the steps. Call it before doing the thinking and you get a copy you\nthen have to prune by hand. Do the thinking first and you get a redesign that already\nreflects it.\n\n### 1. Mark each step\n\n`kowalah_save_process_step` with the step `id`, setting `redesign_decision` and\n`redesign_rationale`.\n\n- Steps marked **`eliminate`** or **`merge`** do not carry across.\n- Everything else carries.\n- **A step with no decision is CARRIED, and reported back in `undecided_count`.** Silently\n  dropping work nobody decided to drop would be the worst possible default — so an\n  unmarked step survives. The count is your check that you covered the chain.\n\nAlways write `redesign_rationale`. The decision is what happens; the rationale is what\nsomeone six weeks from now needs in order to argue with it. \"Eliminate — this approval only\nexisted because the previous system couldn't enforce the limit\" is defensible. \"Eliminate\"\nalone is not.\n\nWork through the chain in order and put a decision on every step, including the ones you\nare keeping. An explicit \"keep\" and an unmarked step produce the same to-be but a very\ndifferent review.\n\n### 2. Generate the to-be\n\n`kowalah_propose_redesign` with the as-is `process_id`.\n\nYou get back a real process — status `draft`, `redesign_status` `proposed`, its own process\nnumber — with `step_count`, `carried_count`, `dropped_count` and `undecided_count`.\n**Nothing about the as-is changes.**\n\nCheck `undecided_count` immediately. If it is not zero, name the steps that carried without\na decision and ask whether that was intended.\n\n## Two things are deliberately cleared on the to-be\n\nBoth are easy to read as bugs. Neither is.\n\n**Target disposition is cleared.** The redesign is a new design question. Inheriting the\nold target would pre-answer it — you would be deciding how to run step 4 of the new process\nbased on a judgement made about step 4 of a process that no longer exists.\n\n**Elapsed time is cleared.** It is the number the redesign exists to *move*. Carrying it\nover would make the comparison show a saving of zero until somebody noticed. The to-be\nneeds its own estimates, and putting them in is part of the design work — not an\nafterthought.\n\nSay both of these out loud when you present the redesign, or the first question you get\nwill be \"why is the target column empty\".\n\n## Competing options are allowed and usually better\n\nCall `kowalah_propose_redesign` twice and you get option A beside option B, both held\nagainst the same as-is. This is often the right move: a conservative redesign and an\naggressive one, priced separately, lets the owner make a real decision instead of\napproving or rejecting a single proposal.\n\nTo do this, set one pass of decisions, generate option A, then revise the decisions on the\nas-is and generate option B. Name them clearly in the rationale so the two can be told\napart later.\n\n## Presenting the comparison\n\nLead with the mechanism, not the count. \"Ten steps to three\" is a headline; *why* is the\nargument:\n\n- Which steps were eliminated and what made them unnecessary\n- Which were merged and what handoff that removes\n- What the constraint step becomes\n- What the elapsed-time claim rests on — and flag it as an estimate, because the to-be's\n  timings are exactly that until the process runs\n\nIf the as-is diagnosis had a `cycle.ratio`, frame the redesign against it. A redesign that\ncuts touch time in a process that was 99% waiting has not fixed the problem, and it is\nbetter to say that before someone else does.\n\n## Permissions\n\nRedesigning follows the same rule as editing: you may redesign a process you own or one at\nor below your unit. Admins and core team may do it anywhere in the organisation.\n\nCheck the `access` block on `kowalah_get_process` first. **When `can_edit` is false, the\nroute is `kowalah_propose_process_change`** — it files an opportunity against the process\n(optionally pinned to one step) so the owner can pick it up. Nothing about the process\nchanges. Anyone may propose against any process they can see, so this route is always open.\n"
}