Feature flow

Skill tienenwu/fables/en/feature-flow

Self-evolving skill packs that give Claude Code & Codex judgment, not knowledge — decidable rules, per-playbook regression quizzes for models, and a project harness generator. zh-TW canon + full EN mirror.

Install

npx -y skills add tienenwu/fables --skill feature-flow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when a feature or refactor changes public contracts, schemas, shared integration points, cross-layer data flow, release behavior, or other high-risk architecture decisions.

SKILL.md

4.7 KB, as published. Nobody here has run it

🌐 繁體中文（canonical） · English mirror

feature-flow — Harness high-risk-feature Profile

Core Principles

This skill supplies spec/design/implementation techniques and artifact templates for high-risk features. When Harness exists, Harness owns risk routing, state transitions, evidence, and contract lifecycle. This skill never creates a second state machine.

Without Harness, use the same profile after creating a risk assessment and one artifact root: docs/plans/<slug>/.

When to Use

Use for public APIs, schemas, shared integration points, cross-layer data flow, migrations, releases, auth/payments/production data, or features with both costly ambiguity and rollback.

Do not use merely because many files change. Low-risk mechanical changes use quick/standard. If design has no material tradeoff and no absolute escalation trigger, return to the risk router and downgrade.

Profile States

1. Discovery / Risk

Add Risk Assessment to plan.md: five signals, absolute triggers, matching contracts, reusable patterns, external side effects, and verification limits.

File count records blast radius but never selects the profile alone.

2. Spec

Create spec.md: Why, in/out scope, GIVEN-WHEN-THEN AC, assumptions, non-goals, and rollback conditions.

Ask the user only for costly ambiguity, product/scope tradeoffs, public contracts, irreversible actions, or external side effects. Decide reversible internals and record assumptions.

UI/UX ambiguity requires a mockup, walkthrough, or annotated screenshot before implementation.

3. Design / Plan

Create plan.md: architecture/data flow, Key Decisions, interfaces, migration/rollback, phases, phase acceptance, and planned evidence for every AC.

Every phase must be independently verifiable. Split phases that span unrelated risk surfaces. Prefer established adjacent patterns over generic design.

4. Implement

Before each phase, create a test/schema check/simulation/diff assertion that fails because the behavior is missing; then implement minimally. Red mechanical checks cannot transition.

When implementation disproves design, add a deviation record and revised evidence plan to plan.md. Never hide scope change or preserve a wrong design for document consistency.

5. Verify / Review

Record claim→evidence in evidence.md. Executable verification runs AC/build/test/baseline; semantic review checks requirements/contracts/architecture/scope; auth/data/release/irreversible surfaces add adversarial challenge.

The same model, prompt, and evidence path are not independent redundancy. Without a fresh reviewer, record "limited independence" and compensate with execution plus fresh read-back.

6. Close

Complete only when every required claim has evidence, no new baseline failure exists, and scope audit passes. review.md records residual risks, rollout/rollback, and omissions.

Put observations in contract-candidates.md; one observation remains candidate until repetition, explicit user ruling, or incident evidence promotes it.

Minimum Evidence

Every AC: at least one test/command/read-back/manual item with source and result.
Regression: compare to the opening baseline; do not merely say "green."
Scope: map changed files to tasks; record unrelated existing bugs without fixing them.
Release/device-only behavior: real-environment evidence; debug/simulator results are insufficient.

Failure Signals

One design assumption fails twice → return to Design; stop adding exceptions.
AC cannot be verified or achieved → return to Spec and ask for scope adjudication.
One phase opens unrelated risk surfaces → return to Plan and split it.
A reviewer offers opinion without an evidence gap or failure scenario → downgrade to suggestion.
Both specs/changes/ and docs/plans/ receive process artifacts → stop; keep docs/plans/<slug>/ canonical.

Red Lines

Push, merge, deploy, delete, or perform irreversible operations without explicit authorization.
Substitute reviewer PASS, green CI, or checked boxes for functional evidence.
Select this profile solely because 3+ files change.
Promote a one-off preference directly to active contract.

References Index

File	Read when
`references/artifact-templates.md`	Creating `spec.md`, `plan.md`, `evidence.md`, `review.md`, or `contract-candidates.md`
`references/lessons.md`	Routing is unclear, review independence is weak, design is disproved, or ceremony costs too much