---
description: Create a new backlog task
---

Let's create a new backlog task via a predefined process. **IT'S CRITICAL YOU FOLLOW THIS PROCESS**.

To start, ask me for:

1. A title
2. A description

Use the answers to create the backlog task WITHOUT acceptance criteria or implementation plan.

The proceed to make a determination if the task requires research to determine the best implementation route.

If there is more than one route, write your analysis into a backlog document and reference it in the backlog task. **Use a flat document path with no subfolders** (e.g., `doc-14 - Research-Exposing-additional-data-points.md`), consistent with the convention used by other documents in the project.

Present all available implementation routes to me, so that I can offer feedback. Once I have picked a direction, update the backlog task with implementation plan and acceptance criteria.

For a plan to be valid, it has to cover these requirements:

1. **Objective alignment** — The plan clearly states how it achieves the stated objective of the issue, with a direct mapping between the problem and the proposed solution.

2. **Simplicity and alternatives considered** — The plan identifies the simplest viable approach. It documents alternatives that were evaluated, explains why they were rejected or deferred, and
   justifies why the chosen approach is the right trade-off for the objective.

3. **Completeness and sequencing** — The plan covers every implementation step in a logical order. No gaps exist between "current state" and "done state." Dependencies between steps are
   explicit so the plan can be executed sequentially without backtracking.

4. **Verifiability** — Each implementation step includes concrete verification instructions (tests to run, manual checks to perform, queries to validate) that prove the step was completed
   correctly before moving on.

5. **Architecture impact analysis** — The plan identifies all architectural touchpoints affected by the change (schemas, contexts, PubSub topics, supervision tree, routes, external APIs, UI
   components) and describes how each is impacted, including any migration or deprecation path.

6. **Performance profile** — The plan explains the performance characteristics of the chosen approach: expected runtime complexity, database query patterns (including N+1 risks), memory
   footprint, and any latency or throughput implications under realistic load.

7. **Benchmarking requirements** — The plan identifies whether one-off or ongoing benchmarks are needed to validate or monitor the performance profile, and if so, specifies what to measure, how
   to measure it, and what thresholds define acceptable performance.

8. **Cost profile** — If the implementation consumes paid resources (API calls, compute, storage, third-party services), the plan includes a cost estimate or model so the financial impact is
   understood before implementation begins.

9. **Production infrastructure steps** — Any manual changes required in production (environment variables, service provisioning, database migrations with special handling, DNS changes, firewall
   rules) are documented in a dedicated "Production Changes" section, separate from the implementation steps, with rollout and rollback instructions.

10. **Documentation updates** — The plan enumerates which project documentation files must be created or updated as part of the implementation (e.g., `docs/architecture.md`,
    `docs/project-conventions.md`, README, API docs), with a summary of what changes each file needs.

At the end, do not offer to start implementation. Instead, offer to start a new session so that I can review the plan via `/review-task-plan`.
