
Actualize
Keep an FPF assurance knowledge base aligned with real git changes so agent context and evidence do not drift from the codebase.
Overview
Actualize is an agent skill most often used in Operate (also Ship, Build) that reconciles `.fpf/` assurance state with recent git changes via context-drift, evidence-staleness, and decision audits.
Install
npx skills add https://github.com/neolabhq/context-engineering-kit --skill actualizeWhat is this skill?
- Runs a three-part git-backed audit: context drift, evidence staleness, and outdated decisions against `.fpf/`
- Diffs changed config manifests (package.json, go.mod, Dockerfile, etc.) against `.fpf/context.md`
- Reads or establishes a baseline via `.fpf/.baseline` and `git diff` since last actualization
- Prompts optional updates to `context.md` when configuration reality diverges from recorded context
- Ties to FPF Canonical Evolution Loop Observe phase for living assurance cases
- Three-part audit: context drift, evidence staleness, outdated decisions
Adoption & trust: 527 installs on skills.sh; 1.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your FPF knowledge base still describes an old stack and evidence set while git already reflects new dependencies, configs, and shipped behavior.
Who is it for?
Teams or solo builders using FPF `.fpf/` folders who merge often and need assurance context to track the repo.
Skip if: Projects without an FPF layout, one-off prototypes with no recorded assurance case, or repos where you only need a generic changelog summary.
When should I use this skill?
Repository changes have landed and `.fpf/` may be out of date with configs, evidence, or decisions.
What do I get? / Deliverables
You get a structured drift and staleness report and can refresh `context.md` and related FPF artifacts so the next agent session works from current reality.
- Git change report scoped to baseline
- Context drift diff vs `.fpf/context.md`
- User-guided context.md update recommendations
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Operate because actualize is the recurring reconcile loop once a project is running; it audits live repo state against `.fpf/` rather than greenfield design. Iterate is where you sync decisions, evidence, and context.md with what shipped—matching the FPF Observe phase and epistemic-debt management after changes land.
Where it fits
After a release branch merge, run actualize to see if `.fpf/context.md` still matches Docker and dependency files.
Before sign-off, audit whether recorded evidence still covers modules touched in the last sprint.
When onboarding a contractor, actualize first so planning docs reflect the current monorepo layout.
How it compares
Use instead of ad-hoc “re-read the whole repo” prompts when you already committed to FPF-style structured context.
Common Questions / FAQ
Who is actualize for?
Indie builders and small teams maintaining a living FPF assurance case in `.fpf/` who use coding agents and need context to match git reality.
When should I use actualize?
After meaningful merges or config changes in Operate/iterate, before major Ship reviews, or during Build/pm when stack docs must match manifests.
Is actualize safe to install?
It expects git and filesystem access to read `.fpf/` and diff the repo; review the Security Audits panel on this page before enabling in sensitive environments.
SKILL.md
READMESKILL.md - Actualize
# Actualize Knowledge Base This command is a core part of maintaining a living assurance case. It keeps your FPF knowledge base (`.fpf/`) in sync with the evolving reality of your project's codebase. The command performs a three-part audit against recent git changes to surface potential context drift, stale evidence, and outdated decisions. This aligns with the **Observe** phase of the FPF Canonical Evolution Loop (B.4) and helps manage **Epistemic Debt** (B.3.4). ## Action (Run-Time) ### Step 1: Check Git Changes Run git commands to identify changes since last actualization: ```bash # Get current commit hash git rev-parse HEAD # Check for changes since last known baseline # (Read .fpf/.baseline file if it exists, otherwise use initial commit) git diff --name-only <baseline_commit> HEAD # List all changed files git diff --stat <baseline_commit> HEAD ``` ### Step 2: Analyze Report for Context Drift 1. Review changed files for core project configuration: - `package.json`, `go.mod`, `Cargo.toml`, `requirements.txt` - `Dockerfile`, `docker-compose.yml` - `.env.example`, config files 2. If configuration files changed: - Re-read project structure (README, config files) - Compare detected context with `.fpf/context.md` - Present diff to user 3. Ask user if they want to update `context.md` ### Step 3: Analyze Report for Evidence Staleness (Epistemic Debt) 1. Read all evidence files in `.fpf/evidence/` 2. Check `carrier_ref` field in each evidence file 3. Cross-reference with changed files from git diff 4. If a referenced file changed: - Flag the evidence as **STALE** - Note which hypothesis is affected ### Step 4: Analyze Report for Decision Relevance 1. Read all DRR files in `.fpf/decisions/` 2. Trace back to source evidence and hypothesis files 3. If foundational files changed: - Flag the DRR as **POTENTIALLY OUTDATED** ### Step 5: Update Baseline Create/update `.fpf/.baseline` file: ``` # FPF Actualization Baseline # Last actualized: 2025-01-15T16:00:00Z commit: abc123def456 ``` ### Step 6: Present Findings Output a structured report: ```markdown ## Actualization Report **Baseline**: abc123 (2025-01-10) **Current**: def456 (2025-01-15) **Files Changed**: 42 ### Context Drift The following configuration files have changed: - package.json (+5 dependencies) - Dockerfile (base image updated) **Action Required**: Review and update `.fpf/context.md` if constraints have changed. ### Stale Evidence (3 items) | Evidence | Hypothesis | Changed File | |----------|------------|--------------| | ev-benchmark-api | api-optimization | src/api/handler.ts | | ev-test-auth | auth-module | src/auth/login.ts | | ev-perf-db | db-indexing | migrations/002.sql | **Action Required**: Re-validate to refresh evidence for affected hypotheses. ### Decisions to Review (1 item) | DRR | Affected By | |-----|-------------| | DRR-2025-01-10-api-design | src/api/handler.ts changed | **Action Required**: Consider re-evaluating decision via `/fpf:propose-hypotheses`. ### Summary - Context drift detected: YES - Stale evidence: 3 items - Decisions to review: 1 item Run `/fpf:decay` for detailed freshness management. ``` ## File: .fpf/.baseline Track the last actualization point: ```yaml # FPF Actualization Baseline last_actualized: 2025-01-15T16:00:00Z commit: abc123def456789 branch: main ``` ## When to Run - **Before starting new work**: Ensure knowledge base is current - **After major changes**: Sync evidence with code changes - **Weekly maintenance**: Part of regular hygiene - **Before decisions**: Ensure evidence is still valid