From 42ca81b940bf2f2ff4863b2a2ea27dbe2b1afe72 Mon Sep 17 00:00:00 2001 From: Claudio Ortolina Date: Sat, 2 May 2026 20:51:59 +0100 Subject: [PATCH] Add prompts for backlog-driven development --- .pi/prompts/new-backlog-task.md | 48 +++++++++++++++++++++++ .pi/prompts/review-task-implementation.md | 15 +++++++ .pi/prompts/review-task-plan.md | 19 +++++++++ 3 files changed, 82 insertions(+) create mode 100644 .pi/prompts/new-backlog-task.md create mode 100644 .pi/prompts/review-task-implementation.md create mode 100644 .pi/prompts/review-task-plan.md diff --git a/.pi/prompts/new-backlog-task.md b/.pi/prompts/new-backlog-task.md new file mode 100644 index 00000000..16caecdc --- /dev/null +++ b/.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. diff --git a/.pi/prompts/review-task-implementation.md b/.pi/prompts/review-task-implementation.md new file mode 100644 index 00000000..d277c362 --- /dev/null +++ b/.pi/prompts/review-task-implementation.md @@ -0,0 +1,15 @@ +--- +description: Code review for a task implementation +argument-hint: "" +--- + +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. diff --git a/.pi/prompts/review-task-plan.md b/.pi/prompts/review-task-plan.md new file mode 100644 index 00000000..5f3e22b3 --- /dev/null +++ b/.pi/prompts/review-task-plan.md @@ -0,0 +1,19 @@ +--- +description: Review for a task plan +argument-hint: "" +--- + +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?