easysdd-feature-fastforward

Original：🇨🇳 Chinese

Translated

Fast Track for Feature Process - When requirements are clear and scope is small, skip the complete design process, write a compact {slug}-design.md, and proceed directly to implementation after one confirmation from the user. What is compressed is divergent discussions and phased reviews, not quality standards - code pointers, acceptance criteria, etc., must not be omitted. Trigger scenarios: User says "quick mode", "fastforward", "cut the steps", "just start working". Not suitable for complex features involving cross-subsystem integration, new terminology sorting, or more than 4 promotion steps - in these cases, proactively inform the user to revert to the complete process.

5installs

Sourceliuzhengdongfortest/easysdd

Added on2026-04-20

NPX Install

npx skill4agent add liuzhengdongfortest/easysdd easysdd-feature-fastforward

SKILL.md Content (Chinese)

View Translation Comparison →

easysdd-feature-fastforward

Not every feature deserves the full four-step brainstorm → design → implement → acceptance process. When requirements can be explained in one sentence, changes are limited to two or three files, and there is no risk of terminology conflicts—forcing such features through the full process will make users feel "the AI is overcomplicating things". Fastforward is the quick channel designed for such scenarios.

But what is compressed is the process, not the quality—code pointers, acceptance criteria, and clearly defined out-of-scope items must not be omitted. Fastforward is not a "perfunctory version of design", but a "design that skips divergent discussions and phased reviews".

When to Use Fastforward

Only use fastforward when all the following conditions are met:

Clear Requirements – The user can state "what to do, for whom, and how to define success", no divergent discussions needed
Clear Scope – Changes are concentrated in a few files or modules, no need to sort out integration points across multiple subsystems
Low Complexity – No complex state machines, concurrency logic, terminology conflict risks, or architecture changes
User's Active Choice – The user explicitly says "quick mode", "fastforward", "hurry up", "cut the steps", "just start working", etc.

Proactively inform the user to revert to the complete feature process in the following situations:

Involves data flow changes across multiple subsystems
Needs to introduce new terminology or has concept conflict risks
Has more than 4 promotion steps
The user cannot clarify the boundaries themselves
Changes may affect the existing core architecture

Why are these rules so strict? What fastforward skips is not rituals, but "the user's opportunity to review the plan at multiple checkpoints". When the scope is large or concepts are new, skipping these checkpoints means the user only realizes your understanding differs after implementation—rework costs at that point are much higher than following the complete process.

What You Need to Do

For shared paths and naming conventions (feature directories,
{slug}-design.md
/
{slug}-checklist.yaml
filenames), see Section 0 of
easysdd/reference/shared-conventions.md
. Fastforward has no additional path conventions.

After the user explains the requirements, quickly read the relevant code (must check the main files involved, no need to read all architecture documents), then produce a compact

{slug}-design.md

(including YAML frontmatter) in one go, let the user confirm it as a whole, and provide implementation guidelines after confirmation.

Startup Checks

Confirm Applicability – Judge if fastforward is suitable based on the above criteria. If not, proactively inform the user of the reason and suggest following the complete process
Duplicate Check – Check if there is already a feature directory with the same name under
```
easysdd/features/
```
. If yes, first ask whether to continue or create a new one
Read Code – Use Glob + Read to quickly browse the main files mentioned in the user's description; use Grep to confirm the scope of changes if necessary

Producing

{slug}-design.md

without reading relevant code is an anti-pattern—fastforward still requires checking the main files. The reason is that a plan written without reading code will most likely not match the actual project structure, and skipping this step will derail the entire subsequent phase.

{slug}-design.md Structure

The

{slug}-design.md

for fastforward is more streamlined than the standard plan, but must include YAML frontmatter + the following 4 sections, produced in one go, not in batches.

YAML frontmatter

Must start with a unified frontmatter to facilitate

search-yaml.py

to search under

features/

. Required fields:

```
doc_type
```
: Fixed as
```
feature-design
```
```
feature
```
: Current feature directory name
```
status
```
: Write
```
draft
```
for the initial version, change to
```
approved
```
after user confirmation; write
```
superseded
```
when replaced
```
summary
```
: One-sentence description of the feature's goal
```
tags
```
: List of searchable tags, at least 2

Template:

markdown

---
doc_type: feature-design
feature: 2026-04-12-export-csv
status: draft
summary: Add CSV export capability to the order list
tags: [export, csv, orders]
---

Section 0: Requirements Summary

Use 2-4 sentences to clarify: what to do, for whom, how to define success, and clearly defined out-of-scope items.

markdown

## 0. Requirements Summary

- **What to do**: ...
- **For whom**: ...
- **Success Criteria**: ...
- **Clearly Out of Scope**: ... (at least 1-2 items)

"Clearly Out of Scope" is not a formality—it is the most important part of this section. Later acceptance will rely on it to define scope boundaries; not writing it means the scope is open.

Section 1: Design Solution

Key design decisions, clarify:

Main files and locations to be modified (code pointers: file path + function / type name)
New types / interfaces (if any, use TypeScript / Rust pseudocode)
Handling methods for key boundary cases

markdown

## 1. Design Solution

### Modification Points

| File | Modification Content |
|---|---|
| `path/to/file.ts` | Describe specific changes |

### New Types (if any)

```typescript
// Pseudocode, write full field names and types
```

### Boundary Cases

- Case A: Handling method
- Case B: Handling method

Section 2: Acceptance Criteria

This is the key difference between fastforward and standard plan docs—acceptance criteria must be written here, no placeholders allowed.

{slug}-acceptance.md

will directly extract acceptance points from here; leaving placeholders means there is no basis for later acceptance.

Each acceptance point must be operable steps + expected results, unaccepting unverifiable descriptions like "function runs normally". The reason is simple: unverifiable standards are equivalent to no standards.

markdown

## 2. Acceptance Criteria

### Function Acceptance

- [ ] (Operation steps) → (Expected result)
- [ ] ...

### Exceptions and Boundaries

- [ ] When boundary case X occurs, behaves as Y
- [ ] ...

### Regression Checks

- [ ] Existing feature X is not affected (specify how to verify)

Section 3: Promotion Steps

Simplified promotion sequence, no more than 4 steps. Each step must have an exit signal (how to define completion of this step).

Why limit to 4 steps? More than 4 steps means the task is no longer "simple"—continuing with fastforward will only disrupt the rhythm of the implementation phase. In such cases, inform the user to switch to the complete process.

markdown

## 3. Promotion Steps

1. **Step Name**: Modification description → Exit signal
2. **Step Name**: ...

User Confirmation and {slug}-checklist.yaml

After producing

{slug}-design.md

, send the user an overall confirmation prompt:

"fastforward {slug}-design.md is ready, please review and confirm as a whole:

Is the requirements summary accurate? Are there any omissions in the clearly out-of-scope items?

Are there any omitted files or functions in the modification points?

Can the acceptance criteria cover the scenarios you expect?

After confirmation, proceed directly to the implementation phase."

The user can propose revision suggestions, and you need to revise and confirm again. When the user explicitly says "it's okay", it is considered approved, and change the

status

in the frontmatter to

approved

After confirmation, immediately extract the action checklist from
{slug}-design.md
and save it to
{slug}-checklist.yaml
in the same directory. For the checklist format and lifecycle, see

easysdd/reference/shared-conventions.md

; this phase only responsible for initial generation. Extraction rules:

```
steps
```
: Extract step by step from Section 3 "Promotion Steps"
```
checks
```
: Extract from Section 0 "Clearly Out of Scope" items + each item in Section 2 "Acceptance Criteria"

After saving, use

validate-yaml.py --file {slug-checklist.yaml path} --yaml-only

to verify syntax.

Exit Conditions

Section 0 includes "Clearly Out of Scope" (at least 1-2 items)
YAML frontmatter exists, with
```
doc_type
```
/
```
feature
```
/
```
status
```
/
```
summary
```
/
```
tags
```
all filled
Each modification point in Section 1 has a code pointer (file path + function / type name)
Section 2 includes function acceptance + at least one exception or regression check, each verifiable
Section 3 has ≤ 4 promotion steps, each with an exit signal
User explicitly confirms
After user confirmation,
```
status
```
in frontmatter has been changed to
```
approved
```

{slug}-checklist.yaml

has been extracted from

{slug}-design.md

and passed verification by

validate-yaml.py

File Paths: Both the plan doc and

{slug}-checklist.yaml

are in the same feature directory; create the feature directory in this step if it does not exist. For the location, see Section 0 of

easysdd/reference/shared-conventions.md

After Exit

Tell the user: "{slug}-design.md has been confirmed, action checklist

{slug}-checklist.yaml

has been generated, proceed directly to the implementation phase. You can trigger the

easysdd-feature-implement

skill."

Do not start writing code on your own—user confirmation is a hard constraint, for the same reason as the standard process: running continuously across phases without pausing will leave the user no time to review.

Common Pitfalls

Forcing fastforward when requirements are unclear—first clarify or suggest following the complete process
Producing
```
{slug}-design.md
```
without reading relevant code
Writing unverifiable descriptions like "function works normally" or "behaves as expected" in Section 2 acceptance criteria
Not prompting to switch to the complete process when Section 3 has more than 4 steps
Starting implementation without user confirmation after production
Treating fastforward as an "excuse for perfunctory work"—compact does not mean rough, code pointers and acceptance criteria must not be omitted

easysdd-feature-fastforward

NPX Install

Tags

SKILL.md Content (Chinese)

easysdd-feature-fastforward

When to Use Fastforward

What You Need to Do

Startup Checks

{slug}-design.md Structure

YAML frontmatter

Section 0: Requirements Summary

Section 1: Design Solution

Section 2: Acceptance Criteria

Section 3: Promotion Steps

User Confirmation and {slug}-checklist.yaml

Exit Conditions

After Exit

Common Pitfalls