process-change

Manages changes to the to-be process map with impact scans and backlog re-prioritization.

Updated Apr 13, 2026
One-click install
npx skills add https://github.com/scoots31/engineering-playbook --skill process-change-scoots31
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: process-change
Source: https://github.com/scoots31/engineering-playbook/tree/main/skills/process-change
Command: npx skills add https://github.com/scoots31/engineering-playbook --skill process-change-scoots31

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When the agreed to-be process map needs to change mid-project, ad-hoc edits cause the map, backlog, and completed work to silently diverge. This Skill enforces a single consistent protocol for every process change, regardless of where the trigger surfaces. ## Core Features & Use Cases - Trigger capture and change documentation: Logs the source of every change (stakeholder input, demo gap, technical constraint, solo realization) and classifies it as a refinement, addition, or restructure before any work begins. - Three-tier impact scan: Audits scheduled, in-progress, and completed slices against the changed process step, assigning an explicit verdict to every item so nothing is assumed safe. - Decide, execute, re-prioritize, confirm: Applies solo-approved decisions (revise, retire, reopen, create, absorb), updates the to-be map and backlog, proposes a new build sequence, and gates resumption on explicit solo confirmation. - Use Case: During a build, a developer discovers an agreed process step is technically impossible. The Skill pauses work, logs the trigger, scans all slices for impact, updates the map and backlog, and re-sequences the remaining work before build resumes. ## Quick Start Tell the assistant that a step in the to-be process map needs to change and ask it to run the process change protocol to assess the impact and update the backlog.

Frequently Asked Questions about process-change

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I handle a process change discovered mid-build?

Pause the current work and run the process change protocol: log the trigger, document the change type, get solo approval, then run the three-tier impact scan. Build resumes only after the backlog is updated and the solo confirms the new sequence.

What is a three-tier impact scan for backlog changes?

It audits every slice across three tiers: scheduled work (Ready, Blocked, Deferred), in-progress work (In Build, In QA), and completed work (Done, Accepted). Each item gets an explicit verdict such as still valid, needs updated scope, or reopen, so nothing is assumed safe.

Can a process change affect already completed work?

Yes. The Tier 3 scan is mandatory and checks every Done slice and Accepted deliverable against the changed step. Completed work can be reopened and sent back through build, code review, and QA if the change makes it incorrect.

What happens if there is no to-be process map yet?

The protocol stops at the gate check. Process change requires an agreed process to change, so you must run discovery first to establish the to-be map before this protocol can run.

When should a process change not go through this protocol?

Never for map-level changes, even small ones. Silently absorbing a change during build causes the map and the build to diverge. Only non-process issues like design gaps or dependency problems are handled outside this protocol.