Add prompts for backlog-driven development

.pi/prompts/new-backlog-task.md

@@ -0,0 +1,48 @@
+---
+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.
+
+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.

.pi/prompts/review-task-implementation.md

@@ -0,0 +1,15 @@
+---
+description: Code review for a task implementation
+argument-hint: "<TASK-ID>"
+---
+
+We're going to review the implementation of task $1.
+
+Perform the review considering:
+
+1. Best practices for development in Elixir, Erlang, OTP, Phoenix, and LiveView
+2. Performance impact and profile
+3. Security in depth
+4. Test coverage and thoroughness. In particular make sure that tests actually exercise the behaviour under test, and that assertions are meaningful and exhaustive
+5. Duplication, repetition, excessive or insufficient abstraction
+6. If the implementation includes HTML, CSS, and client-side JavaScript evaluate accessibility, compliance with light/dark mode requirements, responsive design. Use the configured browser-based tooling to preview and evaluate pages as needed.

.pi/prompts/review-task-plan.md

@@ -0,0 +1,19 @@
+---
+description: Review for a task plan
+argument-hint: "<TASK-ID>"
+---
+
+We're going to review the implementation plan for task $1.
+
+Perform the review considering:
+
+1. Does the plan achieve the objective of the issue?
+2. Is the plan too complex for the objective of the issue? Are there alternatives that should be considered and that could achieve an equal result with a simpler implementation?
+3. Is the plan thorough, covering all implementation steps in a reasonable order?
+4. Are there clear instructions and verification steps that guarantee the soundness of the implementation?
+5. Does the plan take into account any significant architecture variation, and its impact on the rest of the application?
+6. Is the performance profile of the chosen implementation route clearly explained and understood?
+7. Does the implementation require benchmarks (either one off or regular ones)?
+8. If the implementation requires using paid resources, does the plan include a cost prediction/profile?
+9. In case the implementation requires manual steps in the production infrastructure (e.g. setting new environment variables, provisioning resources, etc.), are these steps clearly documented in a separate section?
+10. Does the plan include instructions on what documentation needs to be created or updated?