
Actualize
- 872 installs
- 1.3k repo stars
- Updated July 26, 2026
- neolabhq/context-engineering-kit
actualize is a context-engineering-kit skill that reconciles a project's FPF knowledge base in `.fpf/` with recent git changes for developers maintaining a living assurance case.
About
actualize is a skill from neolabhq/context-engineering-kit that keeps an FPF (Formal Product Framework) knowledge base synchronized with the evolving codebase. The command performs a three-part audit against recent git changes to surface context drift, stale evidence, and outdated decisions stored under `.fpf/`. It aligns with the Observe phase of the FPF Canonical Evolution Loop and helps manage Epistemic Debt called out in the kit documentation. Developers run actualize when architectural decisions, assurance claims, or evidence links may no longer match merged commits. Step one checks git changes since the last actualization, then compares repository reality against recorded FPF state. Reach for actualize during ongoing iteration—not at greenfield setup—when living documentation must stay trustworthy for agents and reviewers.
- Performs three-part audit against recent git changes
- Detects context drift in configuration files like package.json, Dockerfile, and .env.example
- Compares detected context against .fpf/context.md and presents diff to user
- Surfaces potential stale evidence and outdated decisions to manage epistemic debt
- Aligns with the Observe phase of the FPF Canonical Evolution Loop
Actualize by the numbers
- 872 all-time installs (skills.sh)
- +48 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Ranked #1,205 of 16,659 AI & Agent Building skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/neolabhq/context-engineering-kit --skill actualizeAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 872 |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 3 / 3 scanners passed |
| Last updated | July 26, 2026 |
| Repository | neolabhq/context-engineering-kit ↗ |
How do you sync FPF knowledge with git changes?
Keep their project's living knowledge base and assurance case synchronized with ongoing code changes.
Who is it for?
Developers using FPF `.fpf/` assurance cases who merge frequent changes and need automated drift detection.
Skip if: Repositories without an FPF knowledge base or teams that only need one-off architecture docs without ongoing assurance tracking.
When should I use this skill?
Recent git merges may have invalidated FPF decisions, evidence, or assurance claims stored under `.fpf/`.
What you get
Drift report, updated `.fpf/` reconciliation notes, and flagged stale evidence linked to recent commits.
- drift audit report
- reconciled FPF state notes
Files
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:
# 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> HEADStep 2: Analyze Report for Context Drift
1. Review changed files for core project configuration:
package.json,go.mod,Cargo.toml,requirements.txtDockerfile,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: abc123def456Step 6: Present Findings
Output a structured report:
## 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:
# FPF Actualization Baseline
last_actualized: 2025-01-15T16:00:00Z
commit: abc123def456789
branch: mainWhen 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
Related skills
FAQ
What does the actualize skill audit?
The actualize skill compares recent git changes against the project's `.fpf/` FPF knowledge base in a three-part audit, surfacing stale evidence, outdated decisions, and context drift tied to the FPF Canonical Evolution Loop.
When should developers run actualize?
Developers should run actualize after meaningful merges when assurance claims or architectural decisions in `.fpf/` may no longer match the repository, preventing epistemic debt from misleading agents and reviewers.
Is Actualize safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.