writing-good-ticketslisted

# Writing Good Noctra Tickets Use this playbook when preparing a ticket for Noctra or diagnosing a PR that missed the intended scope. Noctra hands the ticket text to a coding agent with no shared hallway context. Write the ticket as if a competent developer joined the team for one day and needs enough context to finish the work without asking follow-up questions. ## Ticket Template ```markdown ## Context [What exists today and why this needs to change. Link to relevant code, errors, or docs.] ## Requirements 1. [Specific, implementable requirement] 2. [Another requirement] 3. [Continue as needed] ## Acceptance Criteria - [ ] [Testable criterion that describes observable behavior] - [ ] [Another criterion] - [ ] All existing tests pass - [ ] Linter passes with no new warnings ## Files likely involved - `path/to/file` - [why this file matters] - `path/to/another-file` - [why this file matters] ## Out of scope - [Explicitly state what not to touch] ``` ## Checklist Before moving a ticket to the trigger state or adding the trigger label: 1. State the current behavior and the desired behavior. 2. Name the exact files, symbols, routes, commands, screenshots, logs, or docs that give context. 3. Include verbatim errors, stack traces, failed test output, or API responses for bug fixes. 4. Break requirements into concrete implementation steps, not broad outcomes. 5. Write acceptance criteria as observable checks a reviewer or test can verify. 6. Add test and lint expectation