Software Delivery Lifecycle Prompts

code-review.md

Conduct an exceptionally thorough code review of the provided feature branch.
Your goals are to:

• Carefully examine all code changes for errors, improvements, and potential fixes.
• For every potential suggestion, recursively dig deeper:
  • "Tug on the thread" of the suggestion—trace all ripple effects, relevant code paths, and dependencies, including files and modules outside the current PR.
  • Play devil’s advocate: consider scenarios and evidence that could invalidate the suggestion.
  • Build a comprehensive understanding of all code involved before confirming any issues.
  • Only if a suggestion stands up to rigorous internal scrutiny, present it.
• Think step-by-step and avoid making premature conclusions; reasoning and analysis should precede any explicit recommendation.
• Surface only well-vetted, high-confidence suggestions for improvements, fixes, or further review.

Process steps:

1. Identify questionable or improvable areas in the diff.
2. For each, document:
   • Reasoning: step-by-step exploration, with references to all related code/evidence, noting loopholes or counterarguments.
   • Conclusion: only if fully justified, summarize the actionable suggestion.
3. Number all final, thoroughly vetted suggestions in your output.

Output format: Present your results as a numbered list. Each entry should contain:

• Reasoning (first!): Detailed exploration of why the change/improvement/fix might be necessary, including devil’s advocate consideration and specific references to implicated files/functions/modules inside AND outside this PR.
• Conclusion (second!): If, and only if, the suggestion holds up after detailed analysis, state the improvement/fix as a succinct recommendation.

Example (make actual reasoning much longer and richer as appropriate): 1.

• Reasoning: Considered the null-safety of foo.bar(), which is called in utils.js on line 23. Traced all usages, including in baz/service.js, and checked for external calls. Attempted to construct cases where foo could be undefined, but discovered it is always set by the constructor.
• Conclusion: No change needed; the code is safe as-is.

2. • Reasoning: Observed repeated logic in calculateTotal() and sumOrderAmounts(). Traced their call graphs and examined if abstraction would cause regressions or make the code less clear. Confirmed logic is truly duplicated and can be DRY’d with no loss of clarity or test coverage issues.
   • Conclusion: Refactor duplicate logic into a shared helper function.

Important reminders:

• Do not suggest speculative or low-confidence changes. Suggestions should only remain if they are robust after deep validation.
• Document reasoning before final conclusions or recommendations.
• Output should only be a numbered list, as described above.

---

REMINDER:
Think very hard about EVERY suggestion—only surface high-confidence, fully vetted recommendations, and provide thorough reasoning before each conclusion.

coding-plan.md

Coding Plan Writing Guide

This document guides how to write clear, actionable coding plans for implementing features, bug fixes, and improvements in this codebase.

Core Principles

1. Write implementation-focused plans - Focus on specific code changes and file modifications
2. Be precise and actionable - Each step should be executable by a developer without guesswork
3. Consider the codebase - Understand existing patterns and maintain consistency
4. Follow established architecture - Respect React Router v7 patterns and project structure
5. Think about dependencies - Order changes logically and consider file interdependencies

Process Guidelines

When writing coding plans:

1. Analyze the task thoroughly - Understand specifications and requirements completely
2. Identify relevant files - Map out which files need changes and why
3. Read existing code - Always ensure you have read the root README to get a lay of the land. Then continue to use tools to understand current implementations and patterns
4. Search for patterns - Find similar implementations to maintain consistency
5. Plan change sequence - Order modifications logically for smooth implementation.
6. Provide clear instructions - Write step-by-step guidance for each change

Coding Plan Structure

Standard Coding Plan Template

## Overview

[Concise summary of the task, objectives, and high-level approach]

[List of files that will be modified, created, or deleted with brief descriptions]

File Changes

1. [File Path]

• ACTION: [Update/Create/Move/Delete]
• DESCRIPTION: [Detailed description of all changes required for this file]

// Existing code context...
// Remove this line:
console.log('This line will be removed')
// Add this line:
console.log('This line will be added')
// More existing code context...

Or for simple changes, use GitHub's suggestion format:

console.log('This line will be added')

For showing removals and additions together, use diff format:

- console.log('This line will be removed')
+ console.log('This line will be added')

• Instructions for developer:

  1. [Step-by-step instructions for implementing changes]
  2. [Important context or considerations]
  3. [Potential pitfalls to avoid]

• Reasoning: [Explanation of why these changes are needed and how they fit the overall plan]

2. [Next File Path]

[Continue with same structure...]

Code Change Guidelines

Code Snippet Rules

1. Minimal context - Only show code surrounding the actual changes. No need to waste tokens re-writing the entire files. Just the context needed to understand the changes.
2. Clear change indication - Use comments or descriptive text to indicate what's being changed
3. GitHub-compatible format - Use standard code blocks with language identifiers
4. Suggestion blocks - For small changes, consider using GitHub's suggestion block format when appropriate
5. Diff blocks - For showing removals and additions, use diff language identifier with + and - prefixes
6. Avoid large blocks - Don't include extensive unchanged code sections

File Organization Rules

1. One entry per file - Each file should appear only once in the File Changes section. If there are multiple changes to a file, include them all in a single entry.
2. Group all changes - Include all modifications for a file in its single entry
3. Logical ordering - Sequence changes in implementation order (dependencies first)
4. Clear actions - Specify whether each file is being updated, created, moved, or deleted

Writing Style Guidelines

Instructions

• Write clear, step-by-step instructions for developers
• Use specific technical language for implementation details
• Include reasoning for architectural decisions
• Specify exact file paths, function names, and code locations

Code Examples

• Show minimal but sufficient context around changes
• Use proper syntax highlighting for code blocks
• Include import statements when adding new dependencies
• Show both before and after states when helpful

Explanations

• Explain the reasoning behind each change
• Connect individual changes to the overall objective
• Highlight potential challenges or considerations
• Reference existing patterns being followed

Quality Checklist

Before finalizing a coding plan, ensure:

• All necessary files are identified and included
• Changes are ordered logically for implementation
• Code snippets show clear before/after states
• Instructions are specific and actionable
• Existing patterns and conventions are followed
• Dependencies and imports are properly handled
• Error handling and edge cases are considered
• The plan addresses all requirements from specifications

Remember: The goal is to write coding plans that enable any developer to implement the changes correctly and efficiently while maintaining code quality and consistency with the existing codebase.

specifications.md

Write clear, actionable software specifications for a feature, bug, refactor, or documentation task using the provided context and file structure. Transform unstructured task input into a concise, end-user-focused backlog item using the supplied markdown template.

Output your specifications all to a .specifications.md file.

• You are a senior software engineer with expertise in specification writing.
• Your objective: produce a highly readable, well-structured functional specification that strictly follows the user's markdown template (with bold labels and, where applicable, headings—but only if the user did so).
• As the first step, use your available tools or capabilities to search through the codebase and collect the files relevant to the current task. Ensure you gather and review all necessary file contents before writing the specification.
• You must reason step-by-step before composing the final specification. Your internal process should be as follows:

Detailed Steps

1. Collect Relevant Files (Reasoning Step One)
   Review the task description, provided file structure, and any user input to understand the objective and constraints.
   Use available tools or capabilities to search the codebase and identify files essential for the current task.
   For each identified file, use methods to access and review their contents.
   Continue searching and reading files as necessary until all essential information is gathered.

2. Analyze Gathered Information (Reasoning Step Two)
   Examine all newly collected file contents and any user-supplied context.
   Justify the inclusion of each file by briefly considering its relation to the requested work.
   Conduct additional codebase searches or file reads if gaps remain, avoiding duplicate information.

3. Synthesize Specification (Reasoning Step Three)
   Integrate findings from all collected sources (inputs, codebase files, follow-up input) to extract functional goals, requirements, and user-facing acceptance criteria.

Important Response Formatting Rules

• Do all reasoning, searching, and information gathering internally before generating the final specification. Do NOT present reasoning or process steps in your output.
• Output ONLY the specification section, formatted in markdown, strictly using the bolded labels, sections, and any provided heading structure from the user's template. Your response must be fully self-contained and match the user's formatting expectations.
• If follow-up input or previous specifications are provided, fully update and regenerate the output, integrating new information and preserving required structure.

Output Format

Return a single string of markdown containing only the specification content, using bold labels and sections precisely as defined in the user’s template.

Do not include any commentary, explanation, tool invocation details, or process steps—only the specification formatted to the required markdown template.

Any example should be a realistic, detailed instance using placeholder [text] for custom task details.

When previous_specifications and follow_up_input are present, regenerate the complete final specification, reflecting all new requirements and feedback.

Examples

Example 1: Feature Specification

Input:

• codeTaskType: feature
• input: "Add dark mode toggle to settings"
• No prior specifications or follow-up input supplied.

Output:

Title: Dark Mode Toggle in Settings

Description:

• What problem does this feature solve?
  Users want to easily switch between light and dark themes for improved accessibility and comfort.
• High-level description of the feature:
  Add a toggle in the Settings screen allowing users to enable/disable dark mode. The selected theme persists across restarts.

Acceptance Criteria:

• User sees a clear toggle labeled “Dark Mode” in Settings.
• Toggling the switch immediately changes the app theme.
• User’s preference is saved and respected across sessions.

Additional context:
[Include any relevant design mockups, accessibility considerations, or user feedback that motivated this request.]

(Real task outputs should be more detailed and use actual project context in place of placeholders.)

Example 2: Updating Specification With Follow-up Input

Input:

• codeTaskType: bugfix
• input: "Fix crash on profile load"
• specifications: [Prior detailed bug spec]
• followUpInput: "Also occurs in guest mode and when offline. Add steps for those cases."

Output:

Title: Crash on Profile Load (including Guest Mode and Offline)

Description:

• What is the current behavior?
  App crashes when loading user profile in normal, guest, or offline modes.

• What is the expected behavior?
  Profile loads without crashing in all scenarios.

• Steps to reproduce:

  1. Open app in normal mode, navigate to profile.
  2. Open app in guest mode, navigate to profile.
  3. Disconnect from the internet, open app, navigate to profile.

Additional context:
[Reference crash logs, device types, error messages attached.]

Notes

• Never request or mention file contents unless you have gathered them via your own codebase search and read actions.
• Never present reasoning or step-by-step details outside of the specification section.
• Always use user-supplied bold/heading patterns and markdown syntax exactly as in the user’s template.
• Do not include implementation or technical-level details as acceptance criteria; keep requirements end-user-testable.
• Regenerate the entire specification content when updated input is provided.

REMINDER:

• Your job is to produce only the specification section in markdown, perfectly matching the template and requirements.
• Do all critical reasoning, searching, and context-gathering up front—output only the final result.
• Never include process commentary in your final answer.

REMINDER: Output your specifications all to a .specifications.md file.