Update to Oximy Reality Checks

{
  "description": "Compare a workflow before and after AI assistance to determine whether work disappeared or moved into review, waiting, correction, exception handling, or rework. Use when someone asks whether AI improved an end-to-end process rather than one production step. Do not claim causal impact from an uncontrolled before-and-after comparison.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 229
    },
    {
      "relative_path": "evals/cases.json",
      "size_in_bytes": 911
    },
    {
      "relative_path": "references/comparison-guide.md",
      "size_in_bytes": 898
    },
    {
      "relative_path": "scripts/analyze_events.py",
      "size_in_bytes": 2708
    }
  ],
  "name": "bottleneck-shift",
  "skill_md_contents": "---\nname: bottleneck-shift\ndescription: Compare a workflow before and after AI assistance to determine whether work disappeared or moved into review, waiting, correction, exception handling, or rework. Use when someone asks whether AI improved an end-to-end process rather than one production step. Do not claim causal impact from an uncontrolled before-and-after comparison.\nlicense: MIT\n---\n\n# Bottleneck Shift\n\nMeasure the whole path to accepted completion. Faster creation can coexist with a slower system.\n\n## Boundary\n\n- Compare a named workflow and accepted completion event, not generic activity totals.\n- Keep descriptive change separate from causal attribution and financial impact.\n- Do not rank individual workers or infer personal productivity from phase timing.\n\n## Required inputs\n\n- A named workflow with a stable start and accepted completion event.\n- Work-item or cohort evidence from a pre-AI baseline and an AI-assisted period.\n- Phase timestamps or credible duration estimates.\n- Quality and exception signals relevant to the work.\n\nIf the workflow definition, population, or completion event changed, record the mismatch before comparing periods.\n\n## Workflow\n\n1. Define the work item, start, accepted completion, phases, exceptions, and quality guardrails. Exclude activity that does not advance an item toward acceptance.\n2. Assess comparability: volume, mix, staffing, seasonality, policy, tooling, and measurement changes. Label controlled, adjusted, directional, or not comparable.\n3. Run `scripts/analyze_events.py` on a normalized event CSV when available. Inspect anomalies and missing spans before interpreting aggregates.\n4. Compare creation, queue, review, correction, exception, escalation, rework, and total elapsed time. Include completion rate and quality guardrails.\n5. Identify the constraint in each period. A phase with the most elapsed time is not automatically the constraint; test whether it limits accepted throughput.\n6. Trace displaced work: which upstream effort fell, which downstream effort rose, and which role absorbed it.\n7. Separate observation from explanation. Generate plausible mechanisms only after the measured changes are clear.\n8. Recommend one operating change and its next measurement. Prefer a bounded experiment over a universal rollout conclusion.\n\nRead [references/comparison-guide.md](references/comparison-guide.md) before comparing non-equivalent cohorts or reporting savings.\n\n## Completion criterion\n\nThe unit of work and accepted completion event are fixed; both periods cover the same phase model or disclose differences; missing data and comparability limits are explicit; downstream review and rework are included; and any causal or savings language matches the study design.\n\n## Output\n\n1. Bottom line and evidence strength\n2. Workflow and cohort definitions\n3. Comparability assessment\n4. Phase and throughput comparison\n5. Quality, exception, and rework comparison\n6. Work removed, work created, and role absorbing it\n7. Candidate explanation, clearly labeled\n8. Next operating change and measurement\n"
}