# Okhp3 Future State Change Strategy > Design a target-state process and a structured change strategy from a gap analysis. Use this skill when the user wants to redesign a process after gaps have been identified; when they ask \"what should the process look like\", \"how do we fix this\", \"design the to-be process\", or \"build a change plan\". This is a recommended extension skill — use after okhp3-process-gap-exception-analysis has produced a gap analysis. Do not use it to document only the current state — that is okhp3-as-is-process-capture; this skill designs what should change, not what exists today. Scope firewall applies: never include employer-proprietary constraints without explicit user authorisation. Produces a future-state process artifact and a change strategy document. - Skill: `okhp3/okhp3-future-state-change-strategy` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add okhp3/okhp3-future-state-change-strategy` - Raw SKILL.md: https://api.skillmd.com/api/skills/okhp3/okhp3-future-state-change-strategy/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: OKHP3 (https://skillmd.com/u/okhp3) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/okhp3/okhp3-future-state-change-strategy --- # okhp3-future-state-change-strategy **BP-SKILL: Business Process Agent Skill Suite** · part of [mermaid-diagram-bpmn](https://github.com/OKHP3/mermaid-diagram-bpmn) · OverKill Hill P³ --- ## Purpose Design the target-state (to-be) process and a structured change strategy based on gap analysis findings. The future-state artifact documents the intended process design; the change strategy documents how to get there. --- ## When to use this skill - `gap-analysis.yaml` exists with at least one `critical` or `major` gap - User wants to redesign a process based on identified gaps - User needs a change management plan to accompany process redesign - Preparing the target-state PNS input for `okhp3-process-narrative-authoring` ## When NOT to use this skill - No gap analysis exists: run `okhp3-process-gap-exception-analysis` first - User wants to document only the current state: use `okhp3-as-is-process-capture` - Scope firewall: do not include confidential employer constraints, proprietary system names, or commercially sensitive process details without explicit user instruction --- ## Scope Firewall This skill operates on process abstractions. Before authoring the future state: - Confirm all described gaps are based on user-provided information - Do not infer proprietary business rules from industry knowledge without flagging them as assumptions - Flag all assumed constraints with `confidence: assumed` in the future-state YAML - Do not include employer-identifying details in any generated artifact --- ## Future-State Design Workflow ### Step 1: Prioritise gaps Rank gaps from `gap-analysis.yaml` by severity: `critical → major → minor → observation`. Focus the future-state design on resolving all critical and major gaps. ### Step 2: Design to-be steps For each resolved gap, define the replacement or new step: - State the intended action in a single imperative statement - Assign a named role (not a person) - Define entry and exit criteria - Specify any system or tool involved ### Step 3: Validate completeness Check the future-state design covers: - All structural gaps (missing steps, unowned activities) - All exception gaps (undefined handling, missing escalation) - All compliance gaps (absent controls, missing segregation) ### Step 4: Define change approach For each major change, define: - `change_type`: add | remove | modify | automate | transfer - `effort`: low | medium | high - `risk`: low | medium | high - `dependencies[]`: other changes that must happen first - `owner_role`: who is responsible for implementing this change ### Step 5: Draft change strategy Structure the change strategy document with: 1. **Change summary**: what is changing and why 2. **Stakeholder impact**: who is affected, how significantly 3. **Transition plan**: sequence and timeline for changes 4. **Risk register**: what could go wrong during transition 5. **Communication plan**: how and when to inform each stakeholder group 6. **Success criteria**: how to know the change has landed --- ## Output Schema `future-state.yaml` contains: - `process_id`: matches PIR `process_id` - `future_state_version`: "0.1-draft" initially - `design_date`, `designed_by_role` - `resolved_gaps[]`: each gap from `gap-analysis.yaml` with its resolution - `to_be_steps[]`: `id`, `description`, `actor_role_id`, `systems[]`, `confidence` - `open_assumptions[]`: assumed constraints flagged for user confirmation - `change_items[]`: each with `change_type`, `effort`, `risk`, `dependencies[]`, `owner_role` --- ## Handoff Instruction Pass `future-state.yaml` to `okhp3-process-intake-and-scope` or `okhp3-process-narrative-authoring` to create the target-state PNS. The future-state steps map directly to `activity_sequence.activities[]` in the new PNS. --- ## Execution contract Apply this contract on every run so the artifact is trustworthy and reusable: 1. State the input evidence, assumptions, and unresolved questions before drafting. Never invent missing process facts, owners, controls, dates, or approvals. 2. Preserve stable identifiers and source traceability. When transforming an upstream artifact, retain its IDs and cite the source field or section for each derived decision. 3. Produce the declared artifact exactly, including required fields and valid values. Keep unsupported, uncertain, or not-applicable items explicit instead of silently omitting them. 4. Validate the result with the bundled script or fixture when available. Report validation status, warnings, and any manual review still required. 5. Stop and request the missing input when a boundary, approval authority, or safety-critical rule cannot be inferred. A partial artifact with clearly marked open questions is safer than a confident fabrication. If `scripts/generate-future-state.mjs` cannot run, scaffold the YAML by hand from `gap-analysis.yaml` using `references/change-strategy-framework.md`, and state in the output that automated scaffolding was not run. ## References Load on demand: - `references/change-strategy-framework.md`: change type taxonomy, effort/risk classification, ADKAR and Kotter alignment, and scope firewall rules ## Scripts - `scripts/generate-future-state.mjs`: scaffolds future-state YAML from gap-analysis input ## Assets - `assets/fixtures/future-state-example.yaml`: canonical future-state design for purchase-approval process ## Evaluation and release status No `evals/evals.json` exists for this skill yet, and none of the five root-level `evals/` categories cover future-state output directly. The only current check is the maintainer-facing `tests/validate-skill.test.mjs` against `assets/fixtures/future-state-example.yaml`. Evidence status: `not-run` for task quality and skill uplift. Version 0.2.0 (this pass) added the `compatibility` declaration, the script fallback instruction, and a sharper discovery-time boundary against `okhp3-as-is-process-capture`. Classified minor per the versioning table, not patch. No regression suite exists to run before this bump; that limitation is disclosed, not implied away. --- ## About Part of the **BP-SKILL: Business Process Agent Skill Suite**, published in [overkillhill/mermaid-diagram-bpmn](https://github.com/OKHP3/mermaid-diagram-bpmn). MIT License.