Risk assessment

Skill Siddharth00/agent-revamp-skills/skills/02-strategize/risk-assessment

Production-grade migration skills for AI coding agents. Revamp any product, module, or feature from one stack to another.

Install

npx -y skills add Siddharth00/agent-revamp-skills --skill risk-assessment

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Reads AUDIT.md, scores all migration risks on a 3×3 Likelihood × Impact matrix across four categories, and produces a committed RISK-REGISTER.md that feeds the risk register section of MIGRATION-PLAN.md.

SKILL.md

38.2 KB, as published. Nobody here has run it

1. Purpose

This skill systematically surfaces and scores every migration risk before a single line of code changes. It reads AUDIT.md and scans across four categories — Technical, Operational, Data, and External — extracting signals that indicate where the migration is most likely to fail, be delayed, or cause a production incident. Every risk is scored on a 3×3 Likelihood × Impact matrix (score = L × I, maximum 9), and every risk with score ≥ 4 is assigned a concrete mitigation action, an early warning signal, an owning role, and a deadline phase. The skill runs in Phase 2, in parallel with migration-strategy, and its output — RISK-REGISTER.md — is the evidence base for the risk register section embedded in MIGRATION-PLAN.md. A score-9 risk (Likelihood 3, Impact 3) is an unconditional migration blocker: the project returns to Phase 1 for more information before any Phase 3 or Phase 4 work begins. The primary hazard this skill manages is the gap between what the audit can measure mechanically and what the migration will encounter in production — implicit coupling, undocumented behavior, and operational constraints that have no grep-able representation in the codebase.

2. Trigger Conditions

Use when:

AUDIT.md exists at the repo root, all numbered sections are populated (run grep -c '<!-- TODO' AUDIT.md and confirm the result is 0), and Sign-off Status is APPROVED.
MIGRATION-PLAN.md does not yet exist or its §4 Risk Register is empty — this skill feeds that section. If MIGRATION-PLAN.md already contains a fully populated risk register with external sign-off, re-running this skill overwrites it; archive the old register first.
The migration scope is known — the engineer can list the modules or services being migrated before this skill runs. Risk assessment scoped to "all of it" without a list produces low-quality scores.
A Phase 2 session is in progress. This skill is designed to run in parallel with migration-strategy; both can read AUDIT.md simultaneously and their outputs merge into MIGRATION-PLAN.md.

Do NOT use when:

AUDIT.md is absent, has unfilled sections, or its Sign-off Status is PENDING — risk scores derived from incomplete audit data will be inaccurate. Run codebase-audit and get sign-off first.
AUDIT.md is more than 90 days old — dependency health, CVE status, and coupling data may have changed materially. Re-run codebase-audit before scoring risks against stale signals.
Phase 4 migration is already in progress and the question is whether to roll back a specific change — that is an incident response decision, not a pre-migration risk assessment. Consult the rollback decision tree in MIGRATION-PLAN.md §5 instead.
The scope is a single file with no external consumers and ≥ 90% test coverage — the overhead of a full risk assessment exceeds the risk itself. Apply judgment; document the decision.

3. Inputs

Required:

Input	Type	Description
`audit_file`	file-path	Path to `AUDIT.md`. Almost always `AUDIT.md` at repo root. Must exist, be fully populated, and have Sign-off Status `APPROVED` before this skill reads it.
`migration_goal`	string	One sentence stating what the migration achieves and why. Copied verbatim into the RISK-REGISTER.md header. Must match the `migration_goal` used in `migration-strategy` if both skills run in the same phase.
`target_stack`	string	The technology stack being migrated TO, with version numbers. Used to assess External risks (SDK changes, browser compatibility, vendor API contracts). Example: `"Fastify 4.x, TypeScript 5.x strict, Node 22 LTS"`.
`primary_engineer`	string	Name or handle of the engineer owning this migration. Named as the default escalation contact in the risk-materialization protocol.

Optional:

Input	Type	Default	Description
`scope`	string	All modules flagged in `AUDIT.md §3` (coupling hot spots) and `§4.2` (coverage gaps)	Comma-separated list of `src/` paths or module names to scope the risk assessment to. Override when the migration is intentionally narrower than what the audit covers. Risks outside scope are not scored.
`output_register_file`	file-path	`RISK-REGISTER.md` at repo root	Where to write the risk register. Override only when managing multiple concurrent migration streams in one repo.
`risk_appetite`	enum(`low`, `medium`, `high`)	`medium`	Adjusts Likelihood scores. `low`: add +1 to all Likelihood scores before computing Score (more conservative). `high`: subtract 1 from Likelihood scores where the codebase has explicit test coverage for that risk (less conservative). Never adjust Impact scores — impact is a consequence of the code and infrastructure, not of appetite. Document the setting and reason in the assessment log.
`deployment_window_minutes`	integer	prompted if absent	The maximum time available between first deploy and forced rollback, in minutes. Feeds Operational risk scoring (shorter windows increase Likelihood scores for deployment risks). Ask: "How many minutes does the team have to confirm the deploy is healthy before they must roll back?"

4. Steps

Read audit_file in full. For each of the four risk categories below, extract every signal that indicates potential risk within scope. Record all findings in output/risk-assessment-inventory-<timestamp>.json before scoring anything — scoring and extraction are separate passes.

Technical risk signals — extract from these sections:
- AUDIT.md §3.1 (fan-out): modules with fan-out count ≥ 9 are high-coupling risks; 4–8 are medium. Record the count.
- AUDIT.md §4.1 (coverage): modules with line coverage < 70% have undocumented behavior risk — tests cannot catch regressions the team does not know exist. Record the exact percentage.
- AUDIT.md §7 (implicit contracts from code-archaeologist): every entry in the Silent Error Swallows, Non-Deterministic Queries, and Magic Constants tables is a technical risk candidate. Record the table row verbatim.
- AUDIT.md §2 (dependency inventory): packages with a major version gap between current and latest (e.g., [email protected] when 4.x exists) have breaking-change risk. Record the package name, current version, and latest version.
- AUDIT.md §6 (CVEs): any Yellow or Red verdict introduces technical risk that the migration may carry forward. Record the CVE IDs and CVSS scores.
Operational risk signals — extract from these sections, and ask if absent:
- AUDIT.md §5.2 (startup time) and §5.3 (p99 latency): baselines that must not regress post-migration. If either is absent, flag as [UNCERTAIN] and treat as an Operational risk with Likelihood 2.
- AUDIT.md §1 (system overview): number of services that depend on the unit being migrated. More dependents = longer validation window = higher deployment-window risk.
- Deployment window: ask deployment_window_minutes if not provided.
- On-call coverage: ask "Is on-call coverage confirmed for the planned deployment window?" If the answer is no or unknown, record as an Operational risk with Likelihood 3.
- Change freezes: ask "Are there any upcoming change freezes (compliance audits, release cuts, partner integrations) in the 30 days following the planned Phase 4 start date?" If yes, record the freeze dates.
Data risk signals — extract from these sections:
- AUDIT.md §3 (coupling map): services that share a database schema with the unit being migrated. Any shared-schema service is a data risk candidate.
- AUDIT.md §7 (implicit contracts): entries in the Hardcoded SQL, Direct Table References, and Non-Deterministic Queries tables indicate schema coupling that a migration may break without obvious test failures.
- Look for migration script files in the target repo: find <repo_root> -name '*.migration.*' -o -name '*_migration.{js,ts,py,rb,go}' -o -name 'migrate-*.sql'. If schema changes are expected and no migration scripts exist, record as a Data risk with Likelihood 3 and Impact 3 (automatic score 9).
- Look for DOWN or rollback migrations: if up-migration files exist but no corresponding down-migration files, record as a Data risk — rollback after a schema change without a down-migration requires manual intervention.
External risk signals — extract from these sections, and search for additional signals:
- AUDIT.md §2 (dependency inventory): third-party SDKs that are being version-upgraded as part of target_stack. Search the SDK's changelog for breaking changes between current and target versions. If the changelog is not available locally, flag as [UNCERTAIN] and record.
- AUDIT.md §7 (implicit contracts): entries in the External Hardcoded URLs table. Any hardcoded external URL is a dependency on a third-party contract that may change.
- Browser compatibility: if scope includes any frontend unit, search AUDIT.md §1 or the repo for a stated browser support matrix. If the matrix exists, verify the target_stack supports the same browsers (e.g., confirm Vite 5 supports the minimum IE/Safari versions listed). If no matrix exists, record as an External risk with Likelihood 2 and Impact 2.
- Vendor SDK breaking changes: search <repo_root> for import paths matching major packages in target_stack that changed major versions (e.g., from @fastify/session@3 to @fastify/session@4). Run npm info <package> versions --json to confirm the version gap. Record any package with a major version gap.

Score each identified risk using the 3×3 Likelihood × Impact matrix. Write scores to output/risk-assessment-scores-<timestamp>.json.

Scoring rules:

Score = Likelihood × Impact. Both axes use a 1–3 integer scale. Do not use decimals or half-scores.

Score	Likelihood	Meaning
1	Unlikely	The condition rarely occurs in migrations of this type; the codebase has explicit test coverage for this scenario; or a structural property of the code makes it improbable.
2	Possible	The condition has occurred in similar migrations; the codebase has partial coverage; or no historical evidence is available in either direction. Default for `[UNCERTAIN]` signals.
3	Likely	The condition regularly occurs in migrations of this complexity; the codebase has no test coverage for this scenario; or audit evidence directly points to it (e.g., a silent error swallow in the module being migrated).

Score	Impact	Meaning
1	Low	The failure is isolated to one module, detectable within one deploy cycle, and fully reversible without data loss or user-visible degradation. Rollback completes in < 15 minutes.
2	Medium	The failure affects one service or user cohort, requires 1–4 hours of incident response, and may require data corrections on a bounded set of records. No permanent data loss.
3	High	The failure causes a production outage, data loss or corruption, a compliance breach, or is not fully reversible. Recovery time > 4 hours or requires manual data repair at scale.

risk_appetite adjustment (if set):

low: add +1 to all Likelihood scores, capped at 3. Record the adjustment and reason in the assessment log.
high: subtract 1 from the Likelihood score of any risk where AUDIT.md §4.1 shows ≥ 90% line coverage for the affected module, minimum 1. Record each adjustment individually.
Never adjust Impact scores — impact is a property of the failure consequence, not of appetite.

Scoring the [UNCERTAIN] signal default: any risk extracted from a [UNCERTAIN] signal in Step 1 defaults to Likelihood 2 unless evidence from another source raises or lowers it. Record the source of every score as the specific AUDIT.md section or other artifact that justified it.

For every risk with Score ≥ 4, write a mitigation entry. Populate all four fields for each. A risk with Score ≥ 4 and a missing or vague mitigation field is a validation failure.

Mitigation entry fields:

Field	Rules
Early warning signal	Must be an observable, measurable event: a log message, an alert threshold, a test failure, a metric crossing a bound. Not a process step. Bad: "Monitor the deployment closely." Good: "Error rate on `POST /api/users` exceeds 0.5% in any 5-minute window as measured by the APM dashboard."
Mitigation action	Must be a concrete, executable instruction. Not "monitor closely", "be careful", or "ensure quality". Bad: "Review the schema before migrating." Good: "Run `db-migrate status` and confirm every pending migration has a corresponding down-migration file before Phase 4 begins."
Owner	Must be a role that exists on the team (e.g., "Primary engineer", "On-call engineer", "Database administrator", "Tech lead") — not a person's name, so the register remains valid if the team changes.
Deadline	Must reference a specific phase gate: "Before Phase 3 begins", "Before Phase 4 begins for `<module>`", "Before Phase 6 cut-over". Not a calendar date — phases are the durable reference.

For risks with Score = 9 (both Likelihood 3 and Impact 3): the mitigation entry is required, but writing a mitigation does NOT unblock the migration. Score-9 risks are unconditional blockers regardless of mitigation quality — see Step 5.

Write output_register_file (RISK-REGISTER.md) using the template below. Replace every  with real content. Do not leave any table cell as "TBD" or copy placeholder text verbatim. The score-4-plus mitigation entries from Step 3 populate the per-category tables.

# Risk Register — <!-- project name from AUDIT.md header -->

> Produced by `skills/02-strategize/risk-assessment` · agent-revamp-skills
> Based on: `AUDIT.md` (audit date: <!-- ISO-8601 date from AUDIT.md header table -->)
> Assessment date: <!-- ISO-8601 -->
> Skill version: 0.1.0

| Field | Value |
|-------|-------|
| **Migration goal** | <!-- migration_goal input --> |
| **Target stack** | <!-- target_stack input --> |
| **Primary engineer** | <!-- primary_engineer input --> |
| **Risk appetite** | <!-- low \| medium \| high + reason if non-default --> |
| **Register status** | PENDING REVIEW |

---

## Risk Summary

> Score = Likelihood × Impact (both 1–3). Severity: Critical = 9 \| High = 6–8 \| Medium = 4–5 \| Low = 1–3.

| Severity | Count |
|----------|-------|
| Critical (score 9) | <!-- N --> |
| High (score 6–8) | <!-- N --> |
| Medium (score 4–5) | <!-- N --> |
| Low (score 1–3) | <!-- N --> |
| **Total** | <!-- N --> |

**Blocker check:** <!-- "No score-9 risks present — migration may proceed to Phase 3 once this register is signed off."
OR: "BLOCKED — risks #T2, #D1 score 9. Phase 3 must not begin until these are resolved. See §Score-9 Blockers." -->

---

## Technical Risks

> Scope: type system gaps, undocumented behavior, implicit coupling, dependency version gaps, carried-forward CVEs.

| # | Risk | Source | Likelihood (1–3) | Impact (1–3) | Score | Early Warning Signal | Mitigation Action | Owner (role) | Deadline |
|---|------|--------|-----------------|-------------|-------|---------------------|------------------|-------------|----------|
| T1 | <!-- description --> | AUDIT.md §<!-- N --> | <!-- 1–3 --> | <!-- 1–3 --> | <!-- L×I --> | <!-- observable signal --> | <!-- concrete action --> | <!-- role --> | Before Phase <!-- N --> |
| T2 | <!-- description --> | AUDIT.md §<!-- N --> | <!-- 1–3 --> | <!-- 1–3 --> | <!-- L×I --> | <!-- observable signal --> | <!-- concrete action --> | <!-- role --> | Before Phase <!-- N --> |

<!-- Add rows as needed. Risks with score < 4 still appear here but the Mitigation, Owner,
     and Deadline columns may be filled with "N/A — score below mitigation threshold." -->

---

## Operational Risks

> Scope: deployment window, rollback time, on-call coverage, change freezes, blast radius.

| # | Risk | Source | Likelihood (1–3) | Impact (1–3) | Score | Early Warning Signal | Mitigation Action | Owner (role) | Deadline |
|---|------|--------|-----------------|-------------|-------|---------------------|------------------|-------------|----------|
| O1 | <!-- description --> | <!-- AUDIT.md §N or "asked during assessment" --> | <!-- 1–3 --> | <!-- 1–3 --> | <!-- L×I --> | <!-- observable signal --> | <!-- concrete action --> | <!-- role --> | Before Phase <!-- N --> |
| O2 | <!-- description --> | <!-- source --> | <!-- 1–3 --> | <!-- 1–3 --> | <!-- L×I --> | <!-- observable signal --> | <!-- concrete action --> | <!-- role --> | Before Phase <!-- N --> |

---

## Data Risks

> Scope: schema changes, migration scripts, backfill risk, read/write parity during dual-write, shared-schema services.

| # | Risk | Source | Likelihood (1–3) | Impact (1–3) | Score | Early Warning Signal | Mitigation Action | Owner (role) | Deadline |
|---|------|--------|-----------------|-------------|-------|---------------------|------------------|-------------|----------|
| D1 | <!-- description --> | AUDIT.md §<!-- N --> | <!-- 1–3 --> | <!-- 1–3 --> | <!-- L×I --> | <!-- observable signal --> | <!-- concrete action --> | <!-- role --> | Before Phase <!-- N --> |
| D2 | <!-- description --> | <!-- source --> | <!-- 1–3 --> | <!-- 1–3 --> | <!-- L×I --> | <!-- observable signal --> | <!-- concrete action --> | <!-- role --> | Before Phase <!-- N --> |

---

## External Risks

> Scope: third-party API contracts, vendor SDK breaking changes, browser compatibility, regulatory constraints.

| # | Risk | Source | Likelihood (1–3) | Impact (1–3) | Score | Early Warning Signal | Mitigation Action | Owner (role) | Deadline |
|---|------|--------|-----------------|-------------|-------|---------------------|------------------|-------------|----------|
| E1 | <!-- description --> | AUDIT.md §<!-- N --> | <!-- 1–3 --> | <!-- 1–3 --> | <!-- L×I --> | <!-- observable signal --> | <!-- concrete action --> | <!-- role --> | Before Phase <!-- N --> |
| E2 | <!-- description --> | <!-- source --> | <!-- 1–3 --> | <!-- 1–3 --> | <!-- L×I --> | <!-- observable signal --> | <!-- concrete action --> | <!-- role --> | Before Phase <!-- N --> |

---

## Score-9 Blockers

> Each entry in this section is an unconditional migration blocker.
> Phase 3 must not begin until every row shows Resolved: Yes with a linked resolution artifact.
> A mitigation entry does NOT resolve a score-9 risk — only returning to Phase 1 and resolving
> the underlying signal (e.g., adding coverage, running a schema compatibility test, confirming
> the vendor API contract) reduces the score below 9 and clears the block.

<!-- If none: write "None." -->

| Risk ID | Description | What would reduce this score below 9 | Resolved? | Resolution artifact |
|---------|-------------|--------------------------------------|-----------|---------------------|
| <!-- T2 --> | <!-- description --> | <!-- e.g., "Raise coverage on src/auth/ to ≥70% (reduces Likelihood from 3 to 1)" --> | No | — |

---

## Risks Requiring Mitigation (score ≥ 4)

> Condensed cross-category view. Full mitigation details are in the category tables above.
> Every row must show Mitigation Status "In Progress" or "Complete" before Phase 3 begins.

| Risk ID | Category | Score | Owner | Deadline | Mitigation Status |
|---------|----------|-------|-------|----------|------------------|
| <!-- T1 --> | Technical | <!-- N --> | <!-- role --> | Before Phase <!-- N --> | Pending |
| <!-- O1 --> | Operational | <!-- N --> | <!-- role --> | Before Phase <!-- N --> | Pending |
| <!-- D1 --> | Data | <!-- N --> | <!-- role --> | Before Phase <!-- N --> | Pending |
| <!-- E1 --> | External | <!-- N --> | <!-- role --> | Before Phase <!-- N --> | Pending |

---

## Risk Materialization Protocol

> This section is operational guidance for Phase 4 and beyond.
> If any risk listed in this register materializes — its Early Warning Signal is triggered —
> follow this protocol immediately. Do not wait for the next checkpoint.

**Materialization defined:** the Early Warning Signal for a risk is observed in a monitoring
dashboard, log stream, test run, or manual check. A near-miss (signal briefly exceeds threshold
then recovers) counts as materialization and must be logged even if auto-resolved.

**Response by score:**

| Score at materialization | Response | Escalation |
|--------------------------|----------|------------|
| Score 1–3 | Log the event in the incident log. Continue migration. Re-evaluate this risk's Likelihood score. | None required. |
| Score 4–5 | Execute the Mitigation Action from this register immediately. Pause the current migration step. Resume only after the Mitigation Action is complete and the signal has cleared. | Notify Primary engineer within 30 minutes. |
| Score 6–8 | Execute the Mitigation Action. Halt Phase 4 migration. Do not proceed to the next migration unit until the risk is resolved and residual score is < 6. | Notify Primary engineer immediately. Notify MIGRATION-PLAN.md sign-off stakeholders within 15 minutes. |
| Score 9 (blocker) | Halt migration immediately. Do not execute any further Phase 4 steps. | Escalate to all MIGRATION-PLAN.md sign-off stakeholders immediately. Convene a post-mortem before any further migration work is scheduled. |

**Escalation contacts (from MIGRATION-PLAN.md § Sign-off):**

| Role | Name | Contact |
|------|------|---------|
| Primary engineer | <!-- primary_engineer --> | <!-- fill in --> |
| <!-- stakeholder role --> | <!-- name from MIGRATION-PLAN.md --> | <!-- fill in --> |

---

## Confidence and Assumptions

**Confidence:** <!-- High | Medium | Low -->

> High: all four categories have ≥ 2 signals sourced from AUDIT.md; no `[UNCERTAIN]` signals remain unresolved.
> Medium: one or two categories relied on `[UNCERTAIN]` signals or prompted responses rather than AUDIT.md evidence.
> Low: ≥ 2 categories are primarily based on `[UNCERTAIN]` signals or the audit data is sparse.

**Assumptions:**

1. <!-- Numbered list. One assumption per line. Be specific: name the module, signal, or evidence that was absent. -->
2. <!-- Example: "Coverage data for src/payments/ was absent from AUDIT.md §4.1; Likelihood scores for payments module risks default to 2." -->
3. <!-- Example: "Deployment window of N minutes was provided by the engineer during assessment; not independently verified." -->

---

## External Review Sign-off

> This register must be reviewed by at least one person outside the migration team
> (e.g., a tech lead from an adjacent team, a staff engineer, a security reviewer)
> before Phase 3 begins. The reviewer confirms that the risk scores are reasonable
> and the mitigations are actionable, not that they agree every risk will materialize.

| Reviewer | Role (outside migration team) | Date | Notes |
|----------|------------------------------|------|-------|
| <!-- name --> | <!-- e.g., Staff Engineer, Security Lead --> | | |

**Status:** PENDING REVIEW

> To approve: fill in your Date and Notes above, then change Status to APPROVED.
> The `migration-strategy` skill will copy this register's risk rows into MIGRATION-PLAN.md §4.
> Do not modify individual risk scores after sign-off without re-running this skill and
> getting a new sign-off — score inflation without evidence is an audit trail violation.

Run the blocker halt check. Read the completed Score-9 Blockers table in RISK-REGISTER.md. If any row has Resolved: No:
- Do not commit RISK-REGISTER.md.
- For each blocking risk, write to the assessment log: "Risk #<ID> (score 9, <Category>): MIGRATION BLOCKED. To reduce this score below 9, the team must: <specific artifact or action that addresses the root cause>." The specific artifact must name a concrete deliverable (e.g., "add integration tests for src/auth/session.ts to raise coverage from 42% to ≥70%, reducing Technical Likelihood from 3 to 1") — not a vague instruction ("look into it").
- STOP. Print: "Migration blocked by N score-9 risk(s). Phase 3 must not begin. Return to Phase 1 to resolve the blockers listed in the assessment log." Do not proceed to Step 6.
Commit output_register_file (RISK-REGISTER.md) to the repo root. The commit message must be: risk: establish risk register for <migration_goal> (Phase 2). Provide the path to RISK-REGISTER.md and its score summary (count of Critical, High, Medium, Low risks) to the engineer, and ask them to:
- Assign the risk rows that migration-strategy needs to populate MIGRATION-PLAN.md §4 — specifically, confirm that the rows from the "Risks Requiring Mitigation" table have been incorporated into the plan's risk register.
- Arrange external review sign-off before Phase 3 begins.
Write all outputs declared in Section 7. Run every Equivalence Test in Section 6 and record results in output/risk-assessment-equiv-<timestamp>.md. Evaluate every item in Section 9 Done Criteria; report pass/fail inline, then print the final verdict.

5. Agent Handoffs

code-archaeologist

File: agents/code-archaeologist.md
Triggered by: Step 1 — when AUDIT.md §7 (implicit contracts) is absent, sparse (fewer than 3 entries), or the scope includes modules not covered in the original audit.

Prompt template:

TASK:        Extract all implicit contracts from the modules listed in SCOPE that are
             relevant to migration risk assessment. Focus on: Silent Error Swallows,
             Non-Deterministic Queries, Magic Constants, External Hardcoded URLs,
             HACK/FIXME/WORKAROUND comments, and environment variable assumptions.
             For each finding, cite the file path and line number.
             Do NOT suggest fixes. Do NOT flag findings as "obvious" and omit them.
             Tag any finding you cannot confirm with evidence as [UNCERTAIN].
REPO_ROOT:   <repo_root>
SCOPE:       <comma-separated module paths from `scope` input>
DEPTH:       deep
INCLUDE_TESTS: false
OUTPUT_FILE: output/risk-assessment-implicit-contracts-<timestamp>.md
FORMAT:      markdown

Incorporate the archaeologist's findings into Step 1's Technical risk signals before scoring in Step 2. Every [UNCERTAIN] tag from the archaeologist defaults to Likelihood 2 in Step 2.

6. Equivalence Tests

Test Name	Input	Expected Output	Tool
`all-categories-assessed`	Read `RISK-REGISTER.md`; count data rows in each of the four category tables (Technical, Operational, Data, External).	Each category table has ≥ 1 data row. A table with only a header row means the category was skipped.	Read — count `\| T` `\| O` `\| D` `\| E` prefixed rows in each block; each count must be ≥ 1.
`score-math-correct`	Read `output/risk-assessment-scores-<timestamp>.json`; for each risk entry verify Score = Likelihood × Impact.	Every Score value equals Likelihood × Impact for that row. No rounding.	Bash: `python3 -c "import json,sys; d=json.load(open(sys.argv[1])); bad=[r for r in d['risks'] if r['score'] != r['likelihood']r['impact']]; print(bad)" output/risk-assessment-scores-.json` — output must be `[]`.
`no-blank-scores`	Read `RISK-REGISTER.md`; check that every row in all four category tables has non-empty Likelihood, Impact, and Score values.	Zero rows with blank or placeholder values (`<!-- 1–3 -->`, `L×I`, etc.) in score columns.	Bash: `grep -c '<!-- 1–3 -->\|<!-- L×I -->' RISK-REGISTER.md` — count must be 0.
`score-4-plus-fully-mitigated`	Read `RISK-REGISTER.md`; for every row where Score ≥ 4, check that Early Warning Signal, Mitigation Action, Owner, and Deadline columns are non-empty and non-placeholder.	Zero rows with Score ≥ 4 and any mitigation field blank or equal to a placeholder.	Read — scan each row in category tables; any row with Score ≥ 4 must have all four mitigation fields populated.
`no-vague-mitigations`	Read the Mitigation Action column for all rows in `RISK-REGISTER.md` where Score ≥ 4.	No Mitigation Action cell contains "monitor closely", "be careful", "ensure", "check", "review", or "make sure" as its primary verb — these indicate a process step, not an action.	Bash: `grep -i 'monitor closely\|be careful\|ensure quality\|check regularly\|make sure' RISK-REGISTER.md` — count must be 0.
`blocker-table-consistent`	Read `RISK-REGISTER.md §Score-9 Blockers`. Cross-check against all four category tables: every risk row with Score = 9 must appear in the blockers table, and no risk with Score < 9 must appear there.	Perfect 1-to-1 correspondence between score-9 rows in category tables and rows in the blockers table. No omissions, no false inclusions.	Read — list all Risk IDs with Score=9 from category tables; confirm each appears exactly once in blockers table; confirm no other IDs appear.
`external-reviewer-named`	Read `RISK-REGISTER.md §External Review Sign-off`.	At least one row has a non-empty Reviewer name and a role that is outside the migration team. Status is either PENDING (allowed pre-sign-off) or APPROVED.	Read — confirm reviewer name is not a placeholder and role does not include "primary engineer" or "migration team".
`register-committed`	`git log --oneline -1 -- <output_register_file>`	File appears in git history with a commit message matching `risk: establish risk register`.	Bash
`no-placeholders-remain`	`grep -c '<!-- placeholder\|<!-- description -->\|<!-- N -->\|<!-- fill in' <output_register_file>`	Returns 0 — no unfilled placeholder text remains in the committed register.	Bash: count must be 0.

7. Outputs

Artifact	Path Pattern	Format	Description
Risk register	`<output_register_file>` (default: `RISK-REGISTER.md` at repo root)	markdown	Primary deliverable. Committed to repo root. Contains all four category tables, score-9 blocker table, risk-materialization protocol, and external review sign-off block. Consumed by `migration-strategy` to populate `MIGRATION-PLAN.md §4`.
Risk inventory (raw)	`output/risk-assessment-inventory-<timestamp>.json`	json	All signals extracted in Step 1, before scoring, with source citations. Evidence that every signal was extracted before scoring, not cherry-picked after.
Risk scores	`output/risk-assessment-scores-<timestamp>.json`	json	Per-risk Likelihood, Impact, Score, and risk_appetite adjustment log. The computation record; used by `score-math-correct` equivalence test.
Assessment log	`output/risk-assessment-log-<timestamp>.md`	markdown	Halt check results, any score-9 blocker explanations, risk_appetite adjustments, confidence level, numbered assumptions list, and any code-archaeologist handoff results incorporated.
Equivalence test results	`output/risk-assessment-equiv-<timestamp>.md`	markdown	Pass/fail verdict for every row in Section 6. Required by Done Criteria.

8. References

skills/01-audit/codebase-audit/SKILL.md — produces AUDIT.md, the mandatory input; the seven audit sections (coupling map, coverage, CVEs, implicit contracts, performance baselines) are the primary signal sources for all four risk categories.
skills/02-strategize/migration-strategy/SKILL.md — runs in parallel with this skill in Phase 2; consumes RISK-REGISTER.md to populate MIGRATION-PLAN.md §4 Risk Register. The two skills must agree on risk IDs: any risk ID referenced in MIGRATION-PLAN.md must appear in RISK-REGISTER.md.
agents/code-archaeologist.md — invoked in Step 1 when AUDIT.md §7 (implicit contracts) is sparse; finds the implicit coupling, silent error swallows, and magic constants that automated tools cannot surface.
references/migration-anti-patterns.md — "The Big Bang Rewrite" (§1) and "Missing Rollback Plan" (§4) describe the most common risk materialization patterns; use these when assessing Operational and Technical risks to avoid missing known failure modes.
references/strangler-fig-pattern.md — the dual-write and traffic-shifting mechanics inform Data and Operational risk scoring; a migration that uses strangler-fig has materially lower deployment-window and rollback-time risks than a Big Bang migration, which should be reflected in Likelihood scores.
skills/05-validate/behavioral-equivalence/SKILL.md — the go/no-go criteria in MIGRATION-PLAN.md §7 reference the same shadow-mode and equivalence thresholds that are early warning signals for Technical and Operational risks in this register; the two documents must agree on thresholds.

9. Done Criteria