fux-plan

Converts feature requests into requirements, design, and task entries stored as durable Fux records.

1|Updated Jun 1, 2026
One-click install
npx skills add https://github.com/arpitarya/fux --skill fux-plan-arpitarya
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: fux-plan
Source: https://github.com/arpitarya/fux/tree/main/archive/v0.1/fux/data/skills/plan
Command: npx skills add https://github.com/arpitarya/fux --skill fux-plan-arpitarya

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Planning documents typically become stale, orphaned markdown files that drift away from the code they describe. This Skill turns a plain-language request into a spec-driven plan where requirements, design, and tasks live as durable, code-linked Fux entries that stay synchronized with the repository. ## Core Features & Use Cases - Spec-driven stages: Turns a request into requirements (EARS acceptance criteria), design (with real code references from the Fux graph), and trackable task entries. - Code-linked planning: Uses fux refs and the graph to identify affected modules, and fux check flags tasks whose referenced code changed while still marked todo. - Graduation to durable knowledge: After implementation, design notes graduate into ADR and rule entries so the reasoning survives. - Use Case: Ask to plan a rollback feature; the Skill scaffolds a spec entry with user stories, links design to the actual modules in the graph, creates task entries with status tracking, and records decisions as ADRs. ## Quick Start Ask the assistant to run /fux plan with a feature request such as "plan adding rollback support to the release pipeline" and review the generated spec entry.

Frequently Asked Questions about fux-plan

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

FAQPage Schema
How do I create a spec-driven plan from a feature request?▼

Run /fux plan with your request in plain language. The Skill scaffolds a spec entry with user stories and EARS acceptance criteria, then builds design and task entries linked to the actual code through the Fux graph.

What are EARS acceptance criteria in requirements?▼

EARS (Easy Approach to Requirements Syntax) formats acceptance criteria as 'WHEN <trigger> THE SYSTEM SHALL <response>'. The Skill uses this pattern in the Requirements section of each spec entry to make criteria testable and unambiguous.

How does the plan stay synchronized with code changes?▼

Each task entry carries code_refs pointing to the files it will change. Running fux check flags any task whose referenced code changed while its status is still todo, catching drift between plan and implementation automatically.

Does fux plan require a Fux-initialized project?▼

Yes, the Skill requires the fux CLI and a .fux/ project directory, created with fux init if missing. It also runs fux build before the design stage so the code graph is current for identifying affected modules.

When should I not write a standalone planning markdown doc?▼

The Skill explicitly forbids writing orphan docs like docs/*-plan.md. Instead, plans should be spec and task entries in the Fux index so they remain durable, code-linked, and maintainable rather than becoming stale scaffolding.