futurefin-change-control

Classifies and gates every FutureFin change with mandatory tests, docs, and evidence requirements.

1|Updated May 2, 2026
One-click install
npx skills add https://github.com/maxlainz/FutureFin --skill futurefin-change-control-maxlainz
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: futurefin-change-control
Source: https://github.com/maxlainz/FutureFin/tree/main/.claude/skills/futurefin-change-control
Command: npx skills add https://github.com/maxlainz/FutureFin --skill futurefin-change-control-maxlainz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Making changes to a production financial application without a clear gatekeeping process leads to silent data loss, broken migrations, and drifted documentation. This Skill defines how every change to FutureFin — code, schema, API, UI, docs, or release — is classified and which tests, documentation updates, and review evidence are mandatory before merging. ## Core Features & Use Cases - Change classification and gates: Routes every change into classes (engine math, API contract, DB migration, UI-visual, metric/KPI, docs-only, infra-release) with a mandatory gate checklist per class. - Non-negotiable invariants: Enforces rules like Decimal-only money handling, reads never mutating, no hardcoded hex colors, strict enum deserialization, and no migration auto-repair, each backed by a documented incident. - Migration and release discipline: Defines rules for never editing shipped migrations, data-loss sign-off, query-drift grepping, version bumps, tagging, and CI job requirements. - Use Case: Before writing a migration that drops a column, load this Skill to learn it requires owner sign-off, a CHANGELOG entry, a grep for query drift across handlers, and the full integration suite against real-shaped data. ## Quick Start Load the futurefin-change-control skill before making, reviewing, or merging any change to the FutureFin repository so the correct gates and evidence requirements are applied.

Frequently Asked Questions about futurefin-change-control

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

FAQPage Schema
How do I safely add a database migration to a Rust sqlx project?▼

Create a new file in apps/api/migrations/ named YYYYMMDDHHMMSS_description.sql with a timestamp sorting after all existing files. Never edit a shipped migration; fix forward with a new one, run the full integration suite, and grep for query drift on any dropped or renamed columns.

What gates apply before merging an API contract change?▼

API contract changes require a breaking-change policy check, updated utoipa OpenAPI annotations, an MCP parity evaluation, integration tests covering the new shape, and a CHANGELOG entry noting any breaking change. Silent omissions from the MCP catalog are not allowed.

Why should money never be stored as f64 in financial software?▼

Float rounding compounds over long simulations such as an 840-month projection and across tax gross-up calculations. FutureFin uses rust_decimal::Decimal everywhere with decimal strings on the wire, allowing only one documented f64 exception for large projection series arrays.

Can I edit an already-shipped migration to fix a bug?▼

No. Editing a shipped migration changes its checksum and causes every deployed instance to fail loudly on next startup. Always fix forward with a new migration; manual _sqlx_migrations deletion is reserved for genuinely idempotent dev-time fixes only.

When should this change-control skill not be used?▼

Do not use it for how to run tests, how to deploy or roll back, why architecture decisions exist, or debugging a failure. Those belong to the validation-and-qa, run-and-operate, architecture-contract, and debugging-playbook skills respectively.

What evidence is required for engine math changes?▼

Engine math changes require the engine unit tests, targeted integration suites like fire_parity and projection_cache, regenerated fire-parity fixtures if tax or target formulas changed, and a CHANGELOG entry with a before/after numeric example, since errors here are silent plausible-but-wrong numbers.