Change Impact Planner
Every commit is read as the files it actually changed — and what was decided about that area last time is on the screen when you scope this one.
What it does
Polls the repository for new commits, then calls it again for the changed PATHS — because a title states an intention and paths state a fact. It names the parts of the system those paths belong to using a path map you can edit, looks up what was decided about that area before, and proposes a targeted or a full run. A person chooses, and the scope they choose is remembered for the next change to the same area.
How it works
For every commit that lands, the mission reads which files actually changed, names the parts of the system they belong to, and checks what has been decided about changes there before. It then proposes what to run — and a person chooses the short list, the full run, or holds the change. The scope they choose is remembered, so the next change to the same area starts from what happened last time.
How it's wired
One poll watcher on the repository's commit list, storing into `changes`. A deterministic tool call fetches the diff mid-pipeline; the Impact Analyst names the components from its path map; a `lookup` step reads what was decided for those components before; two more enrichments propose a scope and say why. One human gate records the choice. The Change desk shows what landed, what it reaches, and what was chosen.
The team
Reads a change as its changed paths, names the parts of the system it reaches, and proposes what to run — narrower where the evidence supports it, wider where it does not.
Connects to
You supply
- Repository project id or path
- Branch to watch
What it watches
Polls the repository every three minutes for new commits on the watched branch, and records each one once.
Human approval
One consequential step waits for a person's approval before it acts.
What it already knows (4)
Data it carries
1 table
What it shows a human
Ask it
“These paths changed: src/core/Money.java, src/payments/InvoiceRenderer.java, src/reporting/MonthlyReport.java. What does this change reach, and what would you run?”
“These paths changed: config/api-gateway/pool.yaml. What would you run?”
“These paths changed: test/reporting/ExportFilterTest.java. What would you run?”
“A dependency bump changes package.json only. Why might that need a wider run than a one-line source change?”
“Why are the changed paths better evidence of impact than the commit message?”
Before it runs, you'll
- 1Confirm the Source Repository server at import. It is credential-free and works as-is; replace the URL with your own GitLab and nothing else changes — the mission calls list_commits and list_commit_diff, both of which our GitLab template provides.
- 2Set the project id and branch in Configure if you are pointing at your own repository.
- 3Edit the Impact Analyst's repository path map on the Knowledge tab to match your layout. This is the one document worth reading before you trust the mission's component names.
- 4Enable the observation, then work the Change desk. Its answers get better as decisions accumulate — the first few changes have no history to read.
Import into StudioX
- Download the
.sxmfile. - In StudioX → Missions → Import, drop the file.
- Review, finalize, and it's live — chat to it or enable the observation.
Reviews
No reviews yet. If you’ve run this mission, yours will be the first — what it handled well, and what you had to wire up, is what the next person needs to know.
More in Engineering
Bug Intake Gate
Every bug report is read before it reaches the backlog — and the ones that can't be worked are named, not silently queued.
Triage Analyst
Close-Out Gate
A fix isn't finished until somebody can say what went wrong — and the answer is written down where it can be found again.
RCA Analyst
Defect Twin Finder
Before anyone starts work, the mission says whether this fault has been seen before — and what was learned the last time it was.
Signature Analyst