Remove all SessionStart and PostToolUse hooks across the marketplace, retaining only PreToolUse safety hooks and UserPromptSubmit quality hooks. Add /project and /adr command families, /hygiene check, /cv status. Create 7 new projman skills for project lifecycle management. Remove /pm-debug, /suggest-version, /proposal-status commands. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1.6 KiB
1.6 KiB
description
| description |
|---|
| Epic decomposition and management conventions using Gitea labels and projects |
Epic Conventions
What Is an Epic
An epic is a large body of work that spans multiple sprints. Epics are tracked as Gitea labels (Epic/*) and optionally as Gitea Project boards.
Label Convention
Labels follow the pattern Epic/{Name}:
Epic/Database— Schema design, migrations, seed dataEpic/API— Backend endpoints, middleware, authEpic/Frontend— UI components, routing, state managementEpic/Auth— Authentication and authorizationEpic/Infrastructure— CI/CD, deployment, monitoring
Epics are defined during /project initiation as part of the charter's Epic Decomposition table.
Epic-to-Sprint Mapping
Each sprint focuses on one or more epics. The sprint milestone description references the active epics:
**Epics:** Epic/Database, Epic/API
**Project:** Driving School SaaS
Wiki Cross-References
- Project Charter (
Project: {Name}) contains the Epic Decomposition table - Sprint Roadmap (
Roadmap: {Name}) maps epics to sprint sequence - WBS (
WBS: {Name}) breaks epics into work packages - Sprint Lessons (
Sprint-Lessons: Sprint-X) reference which epics were active
Issue-Epic Relationship
Every issue in an epic-aligned sprint gets the Epic/* label. This enables:
- Filtering all issues by epic across sprints
- Tracking epic completion percentage
- Epic velocity analysis in lessons learned
DO NOT
- Create epics for single-sprint work — use regular labels
- Mix unrelated work under one epic label
- Skip epic labels during sprint planning — they're the traceability link