lss-story

Generate a story-sized functional specification with flows and acceptance criteria.

Updated Mar 16, 2026
One-click install
npx skills add https://github.com/liminal-ai/code-steward --skill lss-story
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: lss-story
Source: https://github.com/liminal-ai/code-steward/tree/main/.claude/skills/lss-story
Command: npx skills add https://github.com/liminal-ai/code-steward --skill lss-story

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

The lss-story skill provides a compact, rigorous framework to define a single story-sized epic with clear acceptance criteria, ensuring scope stays focused and testable.

Core Features & Use Cases

  • Guides teams to articulate a user-facing capability in a story-sized scope with explicit flows, acceptance criteria, and test conditions.
  • Includes sections for User Profile, Objective, Scope, Flows, Error Paths, Data Contracts, and Definition of Done to enable consistent delivery.
  • Enables downstream enrichment by lss-tech to add technical design and implementation details while preserving the functional spec as the primary source of truth.

Quick Start

Write a complete functional story starting from a user profile and objective, detailing one or two flows with testable acceptance criteria, then add error paths and a data contract if applicable.

Frequently Asked Questions about lss-story

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

FAQPage Schema
How do I write a functional specification for a story-sized epic?

A story-sized epic contains 1-2 cohesive flows and 5-15 testable acceptance criteria, keeping the deliverable focused on a single user-facing capability rather than a sprawling multi-feature project.

What should I include in acceptance criteria to cover error paths?

Yes, data contracts are included when needed to define the structure and rules of data exchanged within flows, ensuring the functional specification captures integration requirements alongside user-facing behavior.

How do I structure a functional spec with test conditions and definition of done?

Yes, the generated functional spec serves as the primary source of truth for downstream technical design, allowing technical implementation details to be enriched separately without altering the original acceptance criteria.

When should I define error paths in a functional spec?

This approach suits projects described as one cohesive story with 1-2 flows and 5-15 acceptance criteria, specifically targeting single feature deliverables rather than large, multi-flow epics.