easysdd-feature-acceptance

At this point, the code has been written, but the workflow is not yet complete. This phase involves two indispensable tasks:

Verify if implementation deviates from the plan – Check layer by layer against the four sections of
```
{slug}-design.md
```
. If deviations are found, fix them immediately, do not just "note them down" in the report and move on
Integrate the feature into the overall architecture – Refer to Section 4 of the design document, and actually update the relevant documents in the architecture center directory

Why are both tasks important? If only the first task is done, the new feature is added but the project-level architecture documentation still describes the old structure, so the next feature's design phase will read outdated information. If only the second task is done, the fact that "the implementation has deviated from the plan" may be buried – the architecture documentation looks perfect, but the code does not match.

The acceptance report is the closed-loop proof of the workflow. No report produced = workflow not completed. This is not a formality – when future team members check "what behaviors were confirmed during the acceptance of this feature last time", without a report, they can only infer by reviewing git diffs.

See Section 0 of
easysdd/reference/shared-conventions.md
for shared paths and naming conventions.

Strong dependency on design sections

All comparison tables, template sections, and prompts of this skill are hard-coded according to the current section numbers and naming of the design document. If the design document refactors section names / adjusts numbers, this skill must be updated synchronously – otherwise, all subsequent pointers to "Section X XX" will be incorrect.

The following two section snapshots are the source of truth consumed by this skill. Every time the design is updated, first check if these two snapshots still match the current status of the design document; if not, modify here first before proceeding:

Standard design section snapshot:

Section 0: Terminology conventions
Section 1: Decisions and constraints (including requirement summary / key decisions / predecessor dependencies / main workflow overview)
Section 2: Interface contracts
Section 3: Implementation prompts (including change plan / implementation risks / promotion sequence / test design)
Section 4: Relationship with project-level architecture documentation

Fastforward design section snapshot:

Section 0: Requirement summary
Section 1: Design plan
Section 2: Acceptance criteria
Section 3: Promotion steps

Startup checks

1. Code is fully implemented

The code changes for this feature can be seen in git status / recent commits. If not, the implement phase is not yet completed; go back first.

2. Design document is complete

The file header has YAML frontmatter, with

doc_type=feature-design

feature

matching the current directory,

status=approved

, non-empty

summary

, and

tags

≥ 2.

Standard design: All four sections (0 Terminology conventions, 1 Decisions and constraints, 2 Interface contracts, 3 Implementation prompts) have substantial content, and Section 4 (Relationship with project-level architecture documentation) has been filled out.

Fastforward design: All four sections (0 Requirement summary, 1 Design plan, 2 Acceptance criteria, 3 Promotion steps) have substantial content. Map the plan to the acceptance report using the following comparison table:

Acceptance report section	Standard design reference	Fastforward design reference
1 Interface contract check	Section 2 (Interface contracts) of the design	Change points in Section 1 (Design plan) of the design
2 Behavior and decision check	Section 1 (Decisions and constraints) of the design	Section 0 (Requirement summary) of the design
3 Test constraint check	Section 3 (Test design) of the design	Section 2 (Acceptance criteria) of the design
4 Terminology consistency	Section 0 (Terminology conventions) of the design	No terminology table; just check code naming consistency
5 Architecture integration	Section 4 (Architecture relationship) of the design	Usually no architecture changes; if indeed irrelevant, write "No architecture dimension changes in this fastforward"

3. Status of {slug}-checklist.yaml

See

easysdd/reference/shared-conventions.md

for the lifecycle of

{slug}-checklist.yaml

. In this phase, only check and update the

checks

section:

The file exists, and the
```
feature
```
field matches the current feature directory
All entries in
```
steps
```
have status
```
done
```
(if there are
```
pending
```
entries, the implement phase is not completed; return first)
The
```
checks
```
list is non-empty, and all entries have status
```
pending
```
If it does not exist → stop and ask the user to go back to the design phase to generate it

4. Read all context

Full content of the design document (focus on Section 1 Requirement summary / Explicitly not doing, Section 2 Interface contracts, Section 3 Test design)
```
{slug}-checklist.yaml
```
All documents mentioned in Section 4 of the design document under the architecture center directory
```
AGENTS.md
```
Code changes for this feature (git log / git diff)

5. Breakpoint recovery

{slug}-acceptance.md

already exists and has some completed sections, check which sections have substantial content (with checklist ticks or filled-in text), and continue from the next incomplete section. At the same time, check the items in

{slug}-checklist.yaml

checks

that have status

passed

, and skip the verified checks. Report: "The last acceptance was completed up to Section X, I will continue from Section Y."

Acceptance report template

Fill in section by section, do not skip sections. The report path is in the feature directory, aggregated with

{slug}-design.md

(see Section 0 of

easysdd/reference/shared-conventions.md

for the specific location).

markdown

# {Feature Name} Acceptance Report

> Phase: Phase 3 (Acceptance Closed Loop)
> Acceptance Date: YYYY-MM-DD
> Associated Design Document: {Design Document Path}

## 1. Interface Contract Check

Check the consistency between implementation and contract one by one against Section 2 Interface contracts of the design document:

**Item-by-item check of contract examples**:

- [ ] Example A ({File Path + Function Name}): Input→Output in example → Actual behavior in code: {Consistent / Deviation description}
- [ ] Example B: ...

**Formal type definition check** (if supplementary type definitions are included in the design document):

- [ ] Type X: {Key fields} → Corresponding definition in code: {Consistent / Deviation description}

**Flowchart check** (if there is a Mermaid diagram in the design document):

- [ ] All nodes / call relationships in the diagram have actual implementations in the code (confirmed via grep)

If deviations are found, **stop and fix the code or update the design document first**. Writing "Known deviation, temporarily not processed" in the report is an anti-pattern – the next person looking for code according to the plan will be tripped by this deviation.

## 2. Behavior and Decision Check

Check against Section 1 Decisions and constraints of the design document:

**Item-by-item verification of requirement summary**:

- [ ] Behavior A: {Description + Actual test result}
- [ ] Behavior B: {Description + Actual test result}

**Item-by-item check of explicitly not doing**:

- [ ] Out-of-scope item X **is indeed not implemented** (confirmed via grep / code review)
- [ ] Out-of-scope item Y **is indeed not implemented**

**Key decision implementation**:

- [ ] Decision D1: {Decision content} → How it is reflected in code: {Description}

## 3. Test Constraint Check

Verify each test constraint against Section 3 Test design of the design document:

- [ ] **C1**: {Constraint assertion}
  - Verification method: {Type system / Unit test / Integration test / Visual inspection}
  - Result: {Passed / Failed + Reason + Remedial plan}
- [ ] **C2**: ...

**Frontend changes must be verified visually in the browser** (hard requirement in AGENTS.md – typecheck passing does not mean it works correctly for users):

- [ ] UI Area X: Verified OK in browser / Screenshot link
- [ ] Interaction Behavior Y: Verified OK in browser

## 4. Terminology Consistency

Check via grep in code against Section 0 Terminology conventions of the design document:

- Terminology X: Hit N times in code, all consistent ✓
- Terminology Y: Hit N times in code, all consistent ✓
- **Conflict prevention**: No hits for forbidden words listed in Section 0 of the design document (if any) ✓

If inconsistencies are found, go back to the code to correct them; do not write "Known difference" in the report and skip it – same reason as Section 1.

## 5. Architecture Integration

Refer to Section 4 "Relationship with project-level architecture documentation" of the design document, and **actually perform updates** item by item:

- [ ] Document X ({Path}) under the architecture center directory:
  - Content to be updated: {Description}
  - Updated: ✓ / Not updated (Reason: {Specific reason for not needing update})
- [ ] Document Y under the architecture center directory: ...

If Section 4 of the design document is empty or too brief, supplement the evaluation here:

- Which modules this feature has added / which interfaces it has changed
- Whether the architecture main entry needs to add a reference to this feature's design document
- Whether `AGENTS.md` needs to supplement new conventions or known pitfalls

Architecture integration is **an actual action of writing files**, not a self-assessment of "should not need to change". Each item must have a clear conclusion.

## 6. Outstanding Items

- Follow-up optimization points (already created as issues or added to the issue list): {List}
- Known limitations: {List}
- "Found along the way" list from the implementation phase: {List}

Check Rhythm

Do section by section, do not skip:

Section 1 (Interface contract) and Section 2 (Behavior and decision) – These two sections are most likely to expose "implementation does not match the plan", do them first
Section 3 (Test constraint) – Check item by item; for type system-related constraints, run typecheck; for unit test / integration-related ones, run tests
Section 4 (Terminology) – Use Grep, write the hit count and positions into the report
Section 5 (Architecture integration) – After reading Section 4 of the design document, execute item by item. Writing "No overall impact on architecture" in one sentence is an anti-pattern; either find where the impact is, or explicitly write "Confirmed no impact on item listed in Section X (Reason)"
Section 6 (Outstanding items) – Record all "found along the way" and known limitations accumulated during the implementation phase

After checking each section, update the
checks
in
{slug}-checklist.yaml
item by item:

Verified passed → Change
```
status
```
to
```
passed
```
Verified failed → Change
```
status
```
to
```
failed
```
, fix the code / design document first then change back to
```
passed
```
The acceptance report is only considered complete when all checks are
```
passed
```

Exit Conditions

All 6 sections of the acceptance report are filled out
All items in Section 1 Interface contract check are ticked, no unprocessed deviations
All items in Section 2 Behavior and decision check are ticked
All items in Section 3 Test constraint check are ticked (failed items have remedial plans), frontend changes have been verified in the browser
No omissions in Section 4 Terminology consistency
Each item in Section 5 Architecture integration has a clear conclusion, and the documents that need to be updated have been actually written
All checks in
```
{slug}-checklist.yaml
```
have status updated to
```
passed
```
User final approval confirmed

Final Commit

Execute according to the rules of Section 4 "Final Commit (scoped-commit)" in

easysdd/reference/shared-conventions.md

. Specific points for this phase:

Commit scope: Feature code + design document + acceptance report + architecture documents actually updated in this phase. Code delivery must include documentation, otherwise the next person working on a feature will not find the context.
The commit is the last step in the recommended closing sequence (see "After Exit" below) – ask about the previous items first, then return to the commit.

After Exit

Tell the user: "The acceptance report is ready, the architecture documents have been integrated, and the easysdd-feature workflow is completed. If bugs are found later, follow the issue fix workflow (do not return to this workflow)."

Then, according to the recommended closing sequence in Section 3 of

easysdd/reference/shared-conventions.md

, give item-by-item prompts in one sentence (skip immediately if the user says "no"):

This feature exposed pitfalls or experiences worth reusing → "Do you need to create a learning document? (Follow
```
easysdd-learning
```
, will be written to
```
easysdd/compound/
```
)"
Introduced long-term constraints / technical selections beyond a single feature → "Do you need to archive this decision? (Follow
```
easysdd-decisions
```
)"
Section 2 of the design document has interface changes / Section 1 has user-visible behavior changes → "Do you need to update the developer or user guide? (Follow
```
easysdd-guidedoc
```
)"
Added / modified public library interfaces (components, functions, commands, etc.) → "Do you need to update the library API reference documentation? (Follow
```
easysdd-libdoc
```
)"
Finally ask once if you need to commit this code and documentation on behalf of the user (scoped-commit). When the user agrees, execute according to the final commit rules until the commit is completed.

You can suggest:

Include the design document + acceptance report + updated architecture documents as part of the same commit
If the follow-up optimization points in the "Outstanding Items" section of the acceptance report are to be implemented, start a new round of easysdd-feature workflow instead of adding them to the existing PR

Common Pitfalls

"All tests passed" → Test constraints ≠ test cases; check Section 3 Test design item by item
"I checked visually and it's fine" → Follow the checklist and tick items one by one
After finding interface deviations in Section 1, write "Known deviation" in the report instead of fixing the code or updating the design document
After finding terminology inconsistencies via grep in Section 4, write "Known difference" in the report instead of fixing the code
Only ran typecheck for frontend changes in Section 3 without verifying in the browser → Hard requirement in AGENTS.md
In Section 5 Architecture integration, only wrote "No overall impact on architecture" in one sentence without checking each item in Section 4 of the design document
Needed to update architecture documents but only wrote "Suggest updating later" – integration is an immediate action, not a suggestion
Declared "workflow completed" without getting user final approval after writing the report
Did not ask the user if they need help with the commit when closing the workflow
Directly ran
```
git commit
```
without explicit user consent

easysdd-feature-acceptance

NPX Install

Tags

SKILL.md Content (Chinese)

easysdd-feature-acceptance

Strong dependency on design sections

Startup checks

1. Code is fully implemented

2. Design document is complete

3. Status of {slug}-checklist.yaml

4. Read all context

5. Breakpoint recovery

Acceptance report template

Check Rhythm

Exit Conditions

Final Commit

After Exit

Common Pitfalls