quint-fpf

Validate architectural claims through six formal reasoning phases into auditable decision artifacts.

5|Updated Apr 18, 2026
One-click install
npx skills add https://github.com/russosalv/NONoise --skill quint-fpf
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: quint-fpf
Source: https://github.com/russosalv/NONoise/tree/main/packages/skills/quint-fpf
Command: npx skills add https://github.com/russosalv/NONoise --skill quint-fpf

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Quint FPF provides a disciplined, auditable process to turn vague architectural or product claims into traceable decisions by guiding teams through six formal phases: Initialize, Abduct, Deduce, Induce, Audit, and Decide. It eliminates informal reasoning and undocumented assertions that lead to hidden technical risk by enforcing tool-backed state transitions and evidence tracking.

Core Features & Use Cases

  • Structured reasoning workflow: Enforces phase-by-phase progression (L0→L1→L2) with exact verdicts and mandatory tool calls in tooled mode.
  • Audit and trust calculus: Computes effective reliability (R_eff) via WLNK, visualizes dependency trees, and surfaces weakest links and epistemic debt.
  • Dual execution modes: Integrates with a quint MCP server for persistent holons and slash commands, or produces conversational markdown artifacts in docs/fpf when MCP is absent.
  • Use cases: Validating PRDs and ADRs, stress-testing architectural claims before implementation, generating Design Rationale Records for compliance and review.

Quick Start

Run a full FPF cycle against a PRD by invoking the skill with the PRD path and mode set to auto to produce an audit-ready decision artifact.

Frequently Asked Questions about quint-fpf

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

FAQPage Schema
How do I validate architectural claims in an ADR for hidden technical risk?

To validate architectural claims in an ADR, you can enforce a structured reasoning workflow that progresses through abduction, deduction, induction, auditing, and a documented decision phase. This eliminates informal reasoning by tracking evidence and computing effective reliability.

What is the best way to document product requirements into auditable decisions?

Documenting product requirements into auditable decisions requires turning vague claims into traceable chains of reasoning. You apply formal phases like Initialize, Abduct, Deduce, Induce, Audit, and Decide to generate an audit-ready Design Rationale Record.

Can I audit design proposals without setting up a quint MCP server?

Yes, you can audit design proposals without a quint MCP server. When the MCP server is absent, the system falls back to producing conversational markdown artifacts in the docs/fpf directory to maintain an auditable decision trail.

How does the audit phase calculate effective reliability for dependency trees?

The audit phase calculates effective reliability (R_eff) using WLNK to visualize dependency trees and surface weakest links. This trust calculus identifies epistemic debt and ensures tool-backed state transitions are validated.

Do I need a specific environment to run a full FPF cycle against a PRD?

To run a full FPF cycle against a PRD, you invoke the skill with the PRD path and mode set to auto. This produces an audit-ready decision artifact, operating either with a quint MCP server for persistent holons or via markdown fallback.