Repository: DiamondForgeFr/SaaSFoundry
Author: AGachet
Objective
Produce a concrete examples gallery — one filled-in reference ticket per type (epic, story, task, issue) — that the AI can read while drafting real tickets, so it imports the pattern (tone, section density, table shape, title convention) instead of guessing from the empty skeleton.
Context
.claude/skills/sf-srs/templates/tickets/README.md and the render*TicketBody renderers (added in #254) describe the shape of each ticket type. What is missing is a specimen — a fully-written example that demonstrates good tone, right density of acceptance criteria, well-scoped completion criteria, and the bilingual title convention (FR separator from #257). Today, when an AI is asked to draft a Task or an Issue, it falls back to a generic empty body or copies from random past tickets — the quality is uneven.
This ticket is meta-SRS tooling (it improves ticket authoring itself), so it bypasses the SRS draft gate.
Scope
Included
- Four new files under .claude/skills/sf-srs/templates/tickets/examples/:
- epic.md — archetypal Epic (multi-story initiative, with Goal / Business Value / Dates / DoD)
- story.md — archetypal Story (user-facing capability, with Objective / AC table / DS refs)
- task.md — archetypal Task (non-user-facing deliverable, with CC table / Specs / Constraints)
- issue.md — archetypal Issue (bug report, with Behavior observed / Repro / Impact / Evidence)
- Byte-identical copy under scaffolds/skills-templates/sf-srs/templates/tickets/examples/ (drift guard enforced by tool-skill-drift.spec.ts).
- References added to SKILL.md ("see templates/tickets/examples/<type>.md") and to each section of templates/tickets/README.md.
- Unit test src/__tests__/unit/srs/templates/examples-contract.spec.ts that verifies each example contains the mandatory sections of its type (reuses the section-header list already encoded in the render*TicketBody renderers).
- Each example file starts with a <!-- Why this example --> HTML-comment preamble explaining what pattern it demonstrates, so the AI copies the pattern not the literal content.
Excluded
- Generating examples automatically from fixtures / renderers (maintenance cost > value at this stage — fixed files are simpler to review).
- Changing the existing renderers or the type flag behavior (owned by #254 / #255).
- Adding examples for non-ticket artifacts (PR descriptions, commit messages) — separate scope if needed.
Completion Criteria
CC1 .claude/skills/sf-srs/templates/tickets/examples/{epic,story,task,issue}.md exist, each with a preamble explaining the archetype and a fully-written body
CC2 Byte-identical copies exist under scaffolds/skills-templates/sf-srs/templates/tickets/examples/; tool-skill-drift.spec.ts passes
CC3 SKILL.md and templates/tickets/README.md link to each example file from the relevant type section
CC4 examples-contract.spec.ts asserts each example contains the mandatory section headers of its type (e.g. Issue has Behavior observed, Expected Behavior, Steps to Reproduce, Impact, Evidence)
CC5 Examples reviewed and approved by the user before implementation begins (see workflow-anomaly note below)
Specifications
.claude/skills/sf-srs/templates/tickets/README.md — existing spec contract for each type, defines the section order examples must match
src/builders/srs/templates/tickets/{epic,story,task,issue}.tpl.ts — the renderers whose section list is the source of truth for the contract test
.claude/skills/sf-workflow/SKILL.md → "🧩 Ticket Hierarchy" section — defines what each type is for, which examples must illustrate
Reference: the FR title separator constant (shared in src/builders/srs/title.ts after #257) governs the title format used in each example
Dependencies
#253 (Epic versionin…