agentleFS
Sign inStart free
me-cedricme-cedric/agent-compass/skills/impact-analysis/SKILL.md

impact-analysis

Skill3 starsChanged 27 days agoMITView on GitHub

Analyse what changed since a base git reference and write the developer action plan with technical impacts, blast radius and the project documents that are now stale. Use for the impact of a branch or diff before merge.

  • Reads credentials

11 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Ask the user for <base> when it is missing.

    line 23
  2. Distinctive:

    Never claim an impact that you did not confirm in the file.

    line 24
  3. Distinctive:

    If the diff is truncated, say so and name what you did not read.

    line 95
  4. Distinctive:

    Do not fix anything. This skill writes the plan.

    line 96

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

impact-analysis

Answer one question: given what changed, what else must change? This is the developer half of the delivery flow. delivery-digest is the Product Owner half. Never mix the two in one file.

Read the change

git diff --stat <base>...HEAD
git status --short
git diff <base>

Ask the user for <base> when it is missing. A guessed base makes every number wrong. Never claim an impact that you did not confirm in the file. A grep hit is a lead, not a finding.

Seven axes

Walk all seven. Write None. for an empty axis. A silent axis reads as "not checked".

  1. Behavior: what a user or caller can now do, or can no longer do. A breaking change gets its own line.
  2. Contracts: routes, methods, status codes, payloads, DTOs, shared types, events, queue messages. Each consumer of a changed contract is an impact. See api-contract-sync.
  3. Data: schema, migrations, backfills, indexes, retention. Say if the migration is reversible.
  4. Configuration: env vars, flags, secrets, infrastructure values. An added variable lands on every surface: the validation schema, .env.example and the deployment config.
  5. Security and privacy: authn and authz, ownership checks on by-id paths, input validation, injection surface, sensitive logging, new dependencies.
  6. Operations: build, CI, deployment order, rollback path, and a signal for each new failure mode.
  7. Delivery documents: the table below.

Documents to check

For each document write up to date, stale with the change to make, or not affected.

DocumentLocationStale when
Specs{{OPENSPEC_DIR}}Behavior changed or a requirement is now built
Decisions{{ADR_DIR}}A choice was made or reversed and no ADR records it
API contracts{{OPENAPI_DIR}} and the request collectionA route, payload, status code or auth rule moved
Data models{{DATA_MODELS_DIR}}A table, column, relation or enum changed
Diagrams{{DIAGRAMS_DIR}}A component or dependency appeared or vanished
Network flows{{FLOWS_FILE}}A new port, protocol, source or destination is needed
Designs{{DESIGNS_DIR}}Tokens, components or UI rules changed
Assignments{{DELIVERY_DIR}}/assignments.jsonScope moved between profiles or a gate cleared
Module docs**/README.md, **/DESIGN.mdA module's public API, files or configuration changed

Output

Write {{DELIVERY_DIR}}/impacts/<YYYY-MM-DD>-<slug>.md.

---
title: <one line>
date: <YYYY-MM-DD>
base: <base reference>
audience: dev
---

# <title>

## Change set
<n> files, +<added> / -<removed>, <n> commits. One line for each group of files.

## Impacts
### Behavior
### Contracts
### Data
### Configuration
### Security and privacy
### Operations

## Documents to update
| Document | State | Action |

## Action plan
- [ ] <item with a file or a command, and an owner profile when assignments name one>

## Risks

## Validation
<each command with its result: passed, failed, partial or not run, with the reason>

Rules

  • Order the action plan by dependency, not by severity.
  • An item that nobody can act on is a risk, not a task.
  • If the diff is truncated, say so and name what you did not read.
  • Do not fix anything. This skill writes the plan. A separate task does the work.
  • Do not commit.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free