ferrox-spec-phase

Clarify ambiguous phase requirements and generate a SPEC.md with acceptance criteria.

21|9|Updated Jul 21, 2026
One-click install
npx skills add https://github.com/FerroxLabs/ferrox-factory --skill ferrox-spec-phase
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ferrox-spec-phase
Source: https://github.com/FerroxLabs/ferrox-factory/tree/main/skills/ferrox-spec-phase
Command: npx skills add https://github.com/FerroxLabs/ferrox-factory --skill ferrox-spec-phase

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill resolves ambiguity in a project phase before implementation begins, so teams do not waste time building the wrong thing or debating unclear requirements later.

Core Features & Use Cases

  • Structured requirement clarification: Uses a Socratic interview loop to surface missing details and edge cases.
  • Quantitative ambiguity scoring: Measures uncertainty across multiple dimensions and gates progress until requirements are clear enough.
  • Phase-spec generation: Produces a falsifiable SPEC.md that locks down what the phase must deliver before discuss-phase and planning continue.
  • Use case: A developer has a loosely defined feature request and needs the phase scope pinned down before any design or code work starts.

Quick Start

Ask the skill to clarify phase 3 requirements and generate the phase SPEC.md.

Frequently Asked Questions about ferrox-spec-phase

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

FAQPage Schema
How do I clarify ambiguous phase requirements before planning starts?

Clarifying ambiguous phase requirements requires structured Socratic questioning to surface missing details, followed by quantitative ambiguity scoring to gate progress until scope is sufficiently defined for downstream planning.

What is a falsifiable specification for phase-based software workflows?

A falsifiable specification is a SPEC.md document that locks down explicit boundaries and acceptance criteria for a phase, ensuring requirements can be objectively tested before implementation or delivery begins.

How do I generate a SPEC.md with acceptance criteria from a loosely defined feature request?

Generating a SPEC.md involves running a Socratic interview loop on the feature request to extract edge cases, scoring ambiguity across multiple dimensions, and outputting falsifiable acceptance criteria.

Does this requirement clarification approach work for phase-based delivery workflows?

Yes, requirement clarification through Socratic interviewing and ambiguity scoring is specifically designed for phase-based software workflows where teams need scoped, falsifiable requirements before discuss-phase and planning continue.

What's the best way to measure ambiguity in software requirements before execution?

Measuring ambiguity in software requirements involves quantitative scoring across multiple uncertainty dimensions, creating a spec gate that blocks progress until the requirements reach a sufficiently clear threshold for execution.

When should I not use a Socratic interview loop for requirement specification?

Socratic interview loops for requirement specification are unnecessary for trivial or fully predetermined phases where no ambiguity exists, as the quantitative scoring and spec gate would add overhead without clarifying any undefined boundaries.