codoop-ticketlisted

# Codoop-Ticket — Ticket Design Orchestration Help users systematically design work tickets in-session through three stages: requirements, technical specs, and task breakdown. ## Scope Boundary This skill ends after an explicitly approved ticket is validated, committed, and promoted to `pending/`. Do not implement, run, verify, review, or ship the ticket; do not invoke `codoop-execute` or otherwise consume the pending queue. Those are Phase 3 responsibilities and require a separate user request. ## What is a Ticket? A ticket is a complete design document package for one feature module: | File | Purpose | Author | |------|---------|--------| | `module_prd.md` | Business requirements (pure business language, no tech) | PM agent | | `spec.md` | Technical specification (APIs, DB, implementation details) | Architect agent | | `preview.html` | Static, reviewable preview of a user-visible feature | Ticket agent, when required | | `plan.md` | Implementation plan (steps) | Auto-inferred | | `todo.md` | Atomic task list (≤100 lines code/task) | Auto-inferred | | `metadata.json` | Ticket metadata (modules, execution settings) | Auto-inferred | The table above shows a **feature** ticket (需求单). A **fix** ticket (修复单) is lighter — see "Ticket Types" below. ## Ticket Types Every ticket has a `ticket_type` (stored in `metadata.json`, default `feature`): | Type | For | Required docs | Skips | |------|-----|---------------|-------| | `feature` (需求单) | New capability from a business n