From tp-fpf
FPF lifecycle — reset reasoning cycles (soft/hard), reconcile knowledge base with code changes, manage evidence freshness (classify, refresh, deprecate, waive).
How this skill is triggered — by the user, by Claude, or both
Slash command
/tp-fpf:fpf-maintenanceWhen to use
Use when the user says 'reset FPF', 'soft reset', 'hard reset', 'archive FPF', 'clear FPF state', 'fresh start with FPF'. IMMEDIATELY when the user asks to 'actualize', 'reconcile FPF', 'sync FPF with code', 'detect drift', or 'check for stale evidence'. BEFORE starting a new hypothesis cycle after significant codebase changes. BEFORE major releases to review outstanding evidence.
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
IF resetting FPF state -> Offer soft reset (archive session) or hard reset (clear knowledge base)
IF resetting FPF state -> Offer soft reset (archive session) or hard reset (clear knowledge base) IF reconciling project state with recent code changes -> Detect context drift from git diff, flag stale evidence, flag outdated decisions IF checking or managing evidence freshness -> Classify evidence as fresh/stale/expired, offer refresh/deprecate/waive IF archived session exists from prior reset -> Ask user if they want to restore it IF combining with new investigation cycle -> Run reset before starting fresh propose flow
Evidence is perishable and tied to code. When the codebase changes, evidence may lose validity. When time passes, evidence expires. Regular maintenance prevents decisions based on outdated information -- fresh thinking requires clean state, not old assumptions.
Clear the FPF state for a fresh start. Archive what you have learned -- do not carry old assumptions.
Option 1: Soft Reset (Archive)
.fpf/sessions/ recording:
Option 2: Hard Reset
.fpf/ directory to .fpf/archive/.fpf/ structure## Reset Complete
- Action: {soft/hard}
- Archived to: {path}
- Next: Start a fresh hypothesis cycle
Reconcile the project's FPF state with recent repository changes -- detect context drift, stale evidence, and outdated decisions.
Step 1: Check Git Changes Run git commands to identify changes since last actualization:
git diff --name-only <baseline_commit> HEAD
git diff --stat <baseline_commit> HEAD
Step 2: Check Context Drift
If config files changed (package.json, Dockerfile, etc.), compare detected state with .fpf/context.md.
Step 3: Check Evidence Staleness
Cross-reference evidence carrier_ref fields with changed files from git diff. Flag affected evidence.
Step 4: Check Decision Relevance Trace DRR files back to source evidence. If foundational files changed, flag as potentially outdated.
Step 5: Update Baseline
# .fpf/.baseline
last_actualized: {timestamp}
commit: {current_sha}
Step 6: Present Report
## Actualization Report
**Files Changed**: {n}
**Context Drift**: {yes/no}
**Stale Evidence**: {n}
**Decisions to Review**: {n}
Structured actualization report with action items for each drift category.
Identify stale decisions, refresh evidence, deprecate obsolete hypotheses, or waive acceptable risk.
| Term | Meaning |
|---|---|
| Stale | Evidence valid_until has passed. Decision is questionable, not wrong. |
| Expired | Stale and unwaived. Requires action. |
| Waive | "I know it's stale, I accept the risk temporarily." Documents explicit acceptance. |
| Refresh | Re-run the validation to create fresh evidence. |
| Deprecate | Decision is obsolete. Downgrade hypothesis, restart evaluation. |
| WLNK | Weakest Link principle: reliability = min(all evidence). One stale piece makes the whole decision questionable. |
Step 1: Generate Freshness Report
.fpf/evidence/valid_until from frontmatterStep 2: Present Report
### EXPIRED (Requires Action)
| Evidence | Hypothesis | Expired | Days Overdue |
|----------|------------|---------|--------------|
### STALE (Warning)
| Evidence | Hypothesis | Expires | Days Left |
|----------|------------|---------|-----------|
### FRESH
| Evidence | Hypothesis | Expires |
|----------|------------|---------|
Step 3: Handle User Actions
.fpf/evidence/ with expiration date and rationaleWeekly maintenance: /fpf:fpf-maintenance -> refresh, deprecate, or waive each item
Pre-release: /fpf:fpf-maintenance -> waive with documented rationale for release docs
After major change: /fpf:fpf-maintenance -> deprecate obsolete decisions, start new cycle
All actions recorded in .fpf/evidence/:
deprecate-{hypothesis}-{date}.mdwaiver-{evidence}-{date}.mdnpx claudepluginhub git-fg/taches-principled --plugin tp-fpfProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.