refactor(workflow): comprehensive spec-driven workflow prompt refactoring #26
Conversation
This commit introduces a detailed refactoring roadmap for the Spec-Driven Development Workflow that maintains simplicity while improving newcomer accessibility. Key improvements include: - Enhanced prompt clarity with workflow guidance and next steps - Scope size recommendations with concrete examples (too large/small/just right) - Centralized directory structure for specs, tasks, and proofs - Simplified numbering system (01, 02, 03 instead of 0001, 0002, 0003) - Implementation steps for migration and prompt updates - Research-based prompt engineering best practices The document consolidates previous scattered improvements into a single, actionable plan that preserves the workflow's core differentiation: simplicity.
…nd workflow guidance This commit implements comprehensive enhancements to the generate-spec prompt based on extensive prompt engineering research and the spec-driven workflow refactoring plan. **Applied findings from 2025 prompt engineering best practices research: - Role-based prompting: Added Senior Product Manager and Technical Lead persona to improve domain-specific response quality and expertise alignment - Chain-of-thought reasoning: Implemented step-by-step scope assessment process to prevent premature task generation and improve decision quality - Negative constraints: Added NEVER/ALWAYS sections to prevent common failure modes and establish clear behavioral guardrails - Output format templates: Provided exact markdown structure with concrete examples to ensure consistent, actionable specification output - Progressive disclosure: Structured questioning approach that starts with core understanding and expands based on feature complexity **Enhanced newcomer accessibility without external documentation dependencies: - Added "You are here in the workflow" section providing current position and next steps guidance - Clear workflow progression: idea → spec → tasks → implementation → validation - Enhanced process overview with 5-step structured approach - Explicit "What comes next" guidance pointing to task generation command **Implemented proactive scope management to prevent inappropriate spec sizes: - Chain-of-thought reasoning for scope evaluation - Concrete examples categorizing features as too large/small/just right - Three-tiered assessment with specific actionable recommendations - Validation step after gathering user requirements **Improved clarifying questions while maintaining original flexibility: - Reduced from 18 formal questions to 9 guided questions - Thematic grouping: Core Understanding, Success & Boundaries, Design & Technical, Demo & Proof - Preserved adaptive questioning: "Adapt your questions based on user input" - Progressive disclosure guidance for intelligent question expansion **Updated to align with new directory structure and numbering system: - File location: /tasks/ → ./docs/specs/ for centralized artifact management - Numbering system: 4-digit (0001) → 2-digit (01) for improved navigation - Enhanced FR1/FR2/FR3 requirement numbering for better traceability - Integrated proof artifacts throughout the specification process **Enhanced output quality and maintainability: - Comprehensive review and refinement process with specific validation questions - Enhanced spec structure with detailed templates and examples - Improved proof artifact integration and validation criteria - Better alignment with junior developer audience needs **Achieved optimal balance between comprehensiveness and efficiency: - Original: ~1133 tokens across 75 lines - Enhanced: ~1929 tokens across 248 lines - 70% increase delivers substantial value: workflow guidance, scope validation, research-based improvements, and enhanced newcomer experience - Maintains original's elegance and flexibility while adding robust capabilities This enhancement represents a thoughtful evolution that preserves the original's core philosophy while addressing key workflow pain points and incorporating modern prompt engineering research findings.
This commit restructures the spec-driven workflow to move context assessment from the task generation phase to the specification creation phase for better decision-making and more realistic specifications. ## Workflow Improvements **Enhanced generate-spec.md:** - Added Step 3: Context Assessment (Optional) to review existing codebase and documentation for architecture patterns, components, and constraints - Updated Process Overview from 5 to 6 steps to include context assessment - Enhanced Scope Validation to consider both user requirements AND existing codebase context for more accurate scope decisions - Updated Final Instructions to reflect the new 9-step process **Streamlined generate-task-list-from-spec.md:** - Removed redundant Step 4: Assess Current State since context is now gathered during spec creation - Reduced process from 11 to 10 steps for cleaner workflow - Updated Phase 1 to reference existing codebase context captured during spec creation process ## Benefits **Better Scope Decisions:** - Context available when making scope validation decisions - Can identify if existing infrastructure makes features easier/harder - More realistic assessment of feature complexity and feasibility **Improved Spec Quality:** - Requirements can reference existing patterns and constraints - Prevents specifying impossible or redundant functionality - Better alignment with established architecture and conventions **Cleaner Workflow Separation:** - Spec phase handles "what exists" context gathering - Task phase focuses on "how to build" implementation planning - Eliminates redundant codebase analysis across workflow phases **Enhanced Documentation Coverage:** - Context assessment includes both codebase AND existing documentation - Captures architectural decisions, API specs, and design patterns - Prevents missing important documented constraints or standards This change maintains the workflow's focus on specification while providing better context for realistic planning and implementation decisions.
This commit refines the generate-spec template to address verbosity concerns and eliminate content duplication across specification sections. ## Template Structure Improvements **Enhanced Section Guidance:** - Updated User Stories to focus on user motivation and WHY - Clarified Demoable Units to focus on tangible progress and WHAT - Refined Functional Requirements to focus on system behavior and WHAT - Improved Design Considerations to focus on UI/UX requirements - Enhanced Technical Considerations to focus on implementation constraints and HOW **Formatting Consistency:** - Changed "Work Unit" to "Unit" for conciseness - Updated FR1/FR2/FR3 format to standard numbered lists with bold requirements - Improved Non-Goals, Success Metrics, and Open Questions formatting - Added explicit fallback text for Design and Technical Considerations **Duplication Prevention:** - Added comprehensive guidance in Final Instructions section - Explicit instruction to ensure each section has distinct purpose - Clear mapping of sections to their specific focus areas (WHY vs WHAT vs HOW) - Guidance to avoid restating content from previous sections ## Benefits **Reduced Verbosity:** - Each section now has clear, distinct purpose - Eliminates redundant content across sections - More concise, focused specifications **Improved Clarity:** - Users understand what each section should contain - Clear separation between user value, demonstration, system behavior, and implementation - Better readability and maintainability **Better Implementation Guidance:** - Developers get clear requirements without duplication - Technical considerations focus on constraints, not restating requirements - Demoable units focus on tangible proof, not user stories This refinement maintains all research-based improvements while producing leaner, more focused specifications that avoid content redundancy.
This commit updates the generate-spec prompt to use a subdirectory structure for specification files instead of flat files in the specs directory. ## Directory Structure Changes **Previous Structure:** - Location: ./docs/specs/ - Format: [n]-spec-[feature-name].md (flat files) **New Structure:** - Location: ./docs/specs/[n]-spec-[feature-name]/ - Format: [n]-spec-[feature-name]/[n]-spec-[feature-name].md ## Benefits **Better Organization:** - Each spec gets its own dedicated directory - Related files can be co-located with the spec - Cleaner directory listing with logical grouping **Enhanced Extensibility:** - Room for additional spec-related artifacts - Can include diagrams, examples, or supporting documents - Future-proof for spec evolution needs **Improved Navigation:** - Clear separation between different specifications - Easier to find all files related to a specific feature - Better support for spec versioning or iterations ## Updated References - Updated Output Requirements section with new path structure - Modified Final Instructions to reflect new save location - Maintains all existing functionality while improving organization This change supports better long-term maintenance and organization of specification artifacts while preserving the established numbering system and workflow compatibility.
…integration - Resolve conflicting process sequences causing unpredictable AI behavior - Add comprehensive Workflow Integration section with value chain mapping - Standardize section naming across workflow prompts - Fix directory structure instructions to ensure proper subdirectory creation - Simplify process from 6-step to 5-step sequence removing duplicate validation - Enhance Output Requirements with explicit directory creation guidance These changes improve prompt reliability and consistency in the SDD workflow.
- Add separate Phase 2 (parent tasks only) and Phase 3 (complete) output formats - Remove conflicting examples that caused AI to skip phase separation - Simplify overly restrictive instructions now that format confusion is resolved - Add fallback logic to auto-select oldest spec without tasks file - Enhance save process to preserve parent tasks before confirmation wait These changes ensure consistent two-phase behavior: generate parent tasks → save → wait for confirmation → generate sub-tasks.
…neering - Apply structured workflow patterns from agentic AI research - Implement Chain-of-Verification (CoV) technique for self-checking - Add explicit command execution with immediate verification steps - Create blocking verification mechanisms that prevent progression - Replace heavy-handed enforcement with structured protocols - Use task-driven proof artifact requirements instead of prescriptive lists - Apply schema enforcement through checklist-based verification - Implement error recovery protocols with clear fix-verify cycles Research-backed techniques applied: 1. Structured workflows with validation gates (Skywork AI, 2024) 2. Self-verification mechanisms (Medium CoVe research, 2024) 3. Schema enforcement and structured outputs (OpenAI, 2024) 4. Chain-of-thought reasoning with verification checkpoints 5. Positive directives over negative constraints (PromptHub principles) Key improvements achieved: - Task list management: ✅ Working consistently - Git commits: ✅ Created after each parent task - Proof artifacts: ✅ Generated with proper naming convention - Progress tracking: ✅ Real-time task file updates - Verification: ✅ Built-in checkpoints prevent errors The refactor transforms prompt behavior from 0% compliance to consistent workflow adherence through structured guidance rather than authoritarian enforcement.
…per task Replace complex multi-file artifact creation with single markdown file approach: - Change from multiple files with naming conventions to one [spec]-task-[number]-proofs.md file - Include structured sections for CLI output, test results, screenshots, and configuration - Simplify verification from checking multiple files to validating one comprehensive file - Maintain all blocking verification and checkpoint mechanisms - Reduce cognitive load while preserving proof quality and validation requirements This addresses user feedback about naming convention complexity and follows the pattern where the AI successfully implemented simpler, single-action workflows.
…ucture - Update Auto-Discovery Protocol to scan ./docs/specs/ for directories - Change pattern from flat files to [n]-spec-[feature-name]/ directories - Maintain consistency with other workflow prompts - Ensure validation works with new subdirectory-based spec organization
…idance - Add 'You are here in the workflow' section to validation prompt - Add 'Your Role' section defining QA Engineer persona - Standardize 'What comes next' format across all prompts - Include final code review instruction in validation phase - Ensure consistent workflow progression messaging
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughUpdates the local pre-push hook to run Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant User as Developer
participant Spec as Spec Generator\n(prompts/generate-spec.md)
participant Planner as Task Planner\n(prompts/generate-task-list-from-spec.md)
participant Executor as Execution Engine\n(prompts/manage-tasks.md)
participant Validator as Validator\n(prompts/validate-spec-implementation.md)
rect rgb(230,245,255)
User->>Spec: Request spec / provide context
Spec-->>User: Ask clarifying questions / deliver draft
User->>Spec: Confirm and save spec (./docs/specs/)
end
rect rgb(245,255,230)
User->>Planner: Request task plan from spec
Planner-->>User: Produce parent tasks (pause for confirmation)
User->>Planner: Confirm to generate sub-tasks
Planner-->>User: Produce sub-tasks (save under ./docs/specs/[NN]-*)
end
rect rgb(255,245,230)
User->>Executor: Execute sub-task (record proof-artifact)
Executor-->>User: Mark progress / store proof
end
rect rgb(255,230,245)
Executor->>Validator: Submit commits + proof-artifacts
Validator-->>User: Validation report (gates, coverage, issues)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
prompts/manage-tasks.md (1)
220-258: Git workflow protocol is comprehensive; consider documenting branch naming convention.The commit format (conventional commits with task/spec references) is well-specified and will create good traceability. However, the prompt doesn't provide guidance on branch naming conventions (line 237 says "appropriate branch" without specifics).
Consider adding a brief note about expected branch naming pattern (e.g.,
feature/spec-[n]-[feature-name]) to help users organize their work and maintain consistency with the spec directory structure.prompts/validate-spec-implementation.md (1)
59-69: Auto-Discovery protocol has hard-coded time window that may miss some specs.The protocol scans for specs with recent git activity using
git log --since="2 weeks ago"(line 68), but this assumes all active specs will have commits within the past 2 weeks. In slower-moving projects or for specs with longer task implementation periods, this cutoff could exclude valid specs from being discovered.Consider either:
- Removing the time-based filter and selecting the highest-numbered spec with incomplete tasks
- Documenting the 2-week window as a configurable threshold users should adjust based on their pace
- Asking the user which spec to validate if multiple candidates are found
prompts/generate-task-list-from-spec.md (1)
192-201: Interaction model is clear but could specify confirmation string flexibility.The two-phase confirmation is well-described with an example interaction (lines 200–201) showing "Generate sub tasks" as the confirmation string. However, the prompt doesn't specify whether this string is case-sensitive or if variations ("generate sub tasks", "GENERATE SUB TASKS", etc.) are acceptable.
Consider clarifying that the confirmation can accept minor variations (case-insensitive, extra punctuation, etc.) to improve UX and reduce friction. For example: "Accept any variation of 'generate sub tasks' (case-insensitive)."
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.pre-commit-config.yaml(1 hunks)docs/archive/refactor-sdd-workflow-prompts.md(1 hunks)prompts/generate-spec.md(2 hunks)prompts/generate-task-list-from-spec.md(2 hunks)prompts/manage-tasks.md(2 hunks)prompts/validate-spec-implementation.md(1 hunks)
🔇 Additional comments (16)
.pre-commit-config.yaml (1)
40-40: Verifyuvis documented as a development requirement.This change introduces an implicit dependency on
uvfor the pre-commit hook. If developers don't haveuvinstalled, the pre-push hook will fail with an unclear error message about command not found.Please verify:
- Is
uvdocumented in the project's setup/installation instructions (README, CONTRIBUTING, etc.)?- Is
uvlisted in project dependencies (pyproject.toml, requirements-dev.txt, etc.)?- Should this instead fall back to
pytestifuvis not available, or isuva hard requirement for the project?docs/archive/refactor-sdd-workflow-prompts.md (1)
1-148: Comprehensive and well-structured archival documentation.This document effectively captures the refactoring rationale and provides valuable reference material for understanding the SDD workflow improvements. The scope sizing examples (lines 69–96) are particularly helpful for guiding users on appropriate feature size.
Recommend cross-checking this document against the actual prompt implementations (especially sections 15–50 on prompt enhancements and 109–148 on directory/naming conventions) to ensure all documented improvements are reflected in the working prompts.
prompts/manage-tasks.md (3)
113-114: Verify proof artifact naming consistency across workflow prompts.The proof artifact naming scheme
[spec-number]-task-[task-number]-proofs.md(e.g.,03-task-01-proofs.md) is clearly defined, but needs verification that the validate-spec-implementation prompt expects the same naming pattern when discovering proof artifacts.Additionally, ensure the directory path reference
./docs/specs/[n]-spec-[feature-name]/[n]-proofs/is consistent with:
- How validate-spec-implementation discovers proof files
- How generate-task-list-from-spec references the same location
- The actual directory structure used in practice
Also applies to: 175-175, 203-203
51-73: Checkpoint modes are well-defined with clear defaults.The three checkpoint options (Continuous/Task/Batch, lines 51–72) provide good flexibility with Task Mode as the sensible default. The emphasis on remembering user preferences (line 72) from earlier in the conversation is a useful UX improvement.
134-140: Blocking verification checkpoints are clearly defined.The three-point BLOCKING VERIFICATION gate (lines 134–140) provides explicit criteria that must be satisfied before proceeding. The summary in lines 289–294 reinforces these checkpoints at a higher level.
Verify that these blocking criteria align with the validation gates (GATE A–D) defined in
prompts/validate-spec-implementation.mdto ensure consistency across the workflow.Also applies to: 289-294
prompts/validate-spec-implementation.md (3)
71-76: Validation gates are clear and comprehensive.The four mandatory gates create a well-structured quality framework:
- Gate A (severity-based fail) maps to the rubric scoring
- Gate B (no Unknown entries) prevents ambiguous validation results
- Gate C (proof artifact accessibility) directly validates the proof artifacts created during task implementation
- Gate D (file scope verification) maintains scope consistency
Confirm these gates align with what
prompts/manage-tasks.mdwill prepare (particularly the BLOCKING VERIFICATION checkpoints around proof artifact creation and file staging).
78-86: Evaluation rubric is well-dimensioned and clear.The five rubric dimensions (R1–R5) cover the essential validation concerns: spec coverage, proof artifacts, file integrity, git traceability, and evidence quality. The 0–3 scale with severity mapping (CRITICAL → HIGH → MEDIUM → OK) is straightforward.
One note: R3 (File Integrity) assumes that
prompts/generate-task-list-from-spec.mdpopulates a "Relevant Files" section accurately. Verify that section is consistently created during task generation.
148-154: Red flags are concrete and appropriately severe.The listed red flags (missing proof artifacts, untracked file changes, Unknown matrix entries, unrelated commits) are the right circuit-breakers for quality. These directly support Gates A–D.
prompts/generate-spec.md (4)
64-105: Scope assessment examples are concrete and well-chosen.The scope sizing guidance (Too Large, Too Small, Just Right) with specific examples is valuable for preventing users from creating over-scoped specs. These examples align well with the scope guidance documented in
docs/archive/refactor-sdd-workflow-prompts.mdand provide clear guardrails.
151-218: Spec template is comprehensive with clear section purposes.The template structure is well-designed with distinct purposes for each section (User Stories → WHY, Demoable Units → WHAT demos, Functional Requirements → system behavior, Technical Considerations → HOW). The Final Instructions (lines 262–273) helpfully reinforce these distinctions to prevent duplication.
Also applies to: 262-273
231-236: Output requirements are clear and consistent with other prompts.The directory structure
./docs/specs/[n]-spec-[feature-name]/and filename[n]-spec-[feature-name].mdwith zero-padded 2-digit numbering is clearly specified and matches expectations in other prompts (manage-tasks.md,validate-spec-implementation.md).
238-255: Critical constraints provide good guardrails.The NEVER and ALWAYS sections are well-chosen to prevent common failure modes (premature implementation, oversized specs, unclear language). These serve as useful reminders for consistent behavior.
prompts/generate-task-list-from-spec.md (4)
51-56: Critical constraints clearly emphasize the two-phase approval process.Lines 51–56 use warning symbols (
⚠️ ) to highlight the critical requirement: "DO NOT generate sub-tasks until explicitly requested by the user." This clear emphasis combined with the two-phase process (Phase 2 parent tasks → user confirmation → Phase 3 sub-tasks) prevents uncontrolled prompt drift.
98-100: Output formats are clearly distinguished between Phase 2 and Phase 3.Phase 2 template (lines 136–152) shows parent tasks without sub-tasks, and Phase 3 template (lines 154–190) expands with Relevant Files and full sub-task breakdown. This progression is clear and helps users understand what each phase delivers.
The filename convention
[n]-tasks-[feature-name].md(line 100) matches expectations inmanage-tasks.mdandvalidate-spec-implementation.md.One note: Verify that the Relevant Files section format (lines 159–166) and task numbering scheme (1.0, 1.1, 1.2) align with what actual implementers will encounter in the codebase.
Also applies to: 136-152, 154-190
213-224: Quality checklist is comprehensive and actionable.The eight-item checklist covers the essential quality gates (demoability, scope, dependencies, spec coverage) before finalizing the task list. This provides a good self-check before user confirmation.
230-240: Final instructions provide clear execution sequence with proper workflow progression.The 9-step final instructions (lines 230–240) properly emphasize the two-phase requirement (CRITICAL tag on step 4) and correctly guide users to the next workflow step (
/manage-tasks). Step 9 ensures work stops at the appropriate point.
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
prompts/generate-spec.md (1)
234-236: Clarify directory path format in output requirements.Line 234 specifies: "Where
nis a zero-padded 2-digit sequence starting from 01, e.g.,01-spec-user-authentication/". However, line 152 in the spec template shows filename as[n]-spec-[feature-name].mdwithout clarifying the zero-padded format. Ensure consistency by making the format explicit in both the spec filename and directory name examples.Consider adding: "All numbering uses zero-padded two-digit format (01, 02, 03, etc.)" to the Output Requirements section for absolute clarity.
prompts/generate-task-list-from-spec.md (1)
55-55: Fix hyphenation for compound adjectives.Line 55 reads: "
⚠️ DO NOT create tasks that are too large (multi-day) or too small (single line changes)". The phrase "single line" should be hyphenated as "single-line" when used as a compound adjective before a noun. As per static analysis hint.Apply this diff:
- ⚠️ **DO NOT** create tasks that are too large (multi-day) or too small (single line changes) + ⚠️ **DO NOT** create tasks that are too large (multi-day) or too small (single-line changes)prompts/validate-spec-implementation.md (1)
63-69: Auto-discovery protocol assumptions should match the directory structure created by manage-tasks.Lines 63-69 specify searching for directories matching
[n]-spec-[feature-name]/with corresponding[n]-tasks-[feature-name].mdfiles. However, the protocol selects based on "highest sequence number where task list exists" and "most recent git activity".This assumes:
- Task files ALWAYS exist where manage-tasks.md created them
- Git history is reliable indicator of active specs
Consider adding defensive logic: "If no specs can be auto-discovered, exit with clear error message listing what was checked."
docs/archive/refactor-sdd-workflow-prompts.md (1)
45-45: Fix hyphenation for compound adjective.Line 45 reads: "Add guidance on how to evaluate top level tasks against the spec". The phrase "top level" should be hyphenated as "top-level" when used as a compound adjective. As per static analysis hint.
Apply this diff:
- Add guidance on how to evaluate top level tasks against the spec + Add guidance on how to evaluate top-level tasks against the spec
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.pre-commit-config.yaml(1 hunks)docs/archive/refactor-sdd-workflow-prompts.md(1 hunks)prompts/generate-spec.md(2 hunks)prompts/generate-task-list-from-spec.md(2 hunks)prompts/manage-tasks.md(2 hunks)prompts/validate-spec-implementation.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/archive/refactor-sdd-workflow-prompts.md
[grammar] ~45-~45: Use a hyphen to join words.
Context: ...st - Add guidance on how to evaluate top level tasks against the spec - Enhance t...
(QB_NEW_EN_HYPHEN)
prompts/generate-task-list-from-spec.md
[grammar] ~55-~55: Use a hyphen to join words.
Context: ...o large (multi-day) or too small (single line changes)
(QB_NEW_EN_HYPHEN)
🔇 Additional comments (8)
prompts/generate-spec.md (1)
269-273: The spec structure's distinct section purposes are clearly defined and helpful.Lines 269-273 provide valuable guidance on how User Stories, Demoable Units, Functional Requirements, and Technical Considerations should differ in focus (WHY vs. WHAT vs. HOW). This prevents the common mistake of duplicating content across sections.
prompts/generate-task-list-from-spec.md (2)
99-100: Verify filename convention matches the spec directory structure.Line 99 specifies saving to
./docs/specs/[n]-spec-[feature-name]/, and line 100 specifies filename[n]-tasks-[feature-name].md. However, line 106 instructs finding "the oldest spec in./docs/specs/that doesn't have an accompanying tasks file". This creates ambiguity: should it search for specs without matching[n]-tasks-[feature-name].mdfiles?Clarify the auto-discovery logic to explicitly state: "A spec is considered 'without tasks' if
[n]-tasks-[feature-name].mddoes not exist in the same directory as the spec file."Is the filename convention intentionally different from the spec? (Spec:
[n]-spec-[feature-name].mdvs. Tasks:[n]-tasks-[feature-name].md)
136-152: Phase 2 output format is clear and actionable.The parent task structure (lines 136-152) with Demo Criteria and Proof Artifacts sections provides excellent guidance for task generation. The formatting example is specific and easy to follow, which will help downstream tools (manage-tasks, validate-spec-implementation) parse and use the structure consistently.
prompts/manage-tasks.md (2)
113-118: Proof artifact creation is critical; ensure the single-file approach is enforced consistently.Lines 113-118 specify: Create a single markdown file per task with naming
[spec-number]-task-[task-number]-proofs.md, containing all evidence (CLI output, test results, screenshots, config examples). This is a major change from typical multi-file artifact approaches.However, line 210 in the Proof Artifact Creation Checklist mentions "Screenshots section with image references" but doesn't clarify: should image files be embedded in markdown or referenced separately? If referenced separately, where should they live relative to the proof artifact markdown file?
Clarify the artifact structure: Are all artifacts text-only in the markdown file, or do image/binary artifacts go in a subdirectory?
134-140: Blocking verification checkpoints are well-structured for preventing partial completion.The three mandatory verifications before proceeding (lines 135-137) explicitly check:
- Proof file exists and contains evidence
- Git commit exists and is correct
- Parent task marked [x] in task file
This triple-check approach prevents developers from skipping critical steps and ensures validation can access required artifacts.
prompts/validate-spec-implementation.md (1)
148-154: Red flags section correctly reinforces validation gates.Lines 148-154 list specific red flags (missing artifacts, files outside scope, unknown coverage, etc.) that map directly to GATE A-D (lines 71-76). This consistency makes the validation process easier to audit and follow.
docs/archive/refactor-sdd-workflow-prompts.md (1)
137-143: Key principles for spec organization are well-articulated and support long-term maintainability.Lines 137-143 establish clear principles:
- Spec-based organization (each spec gets its own directory)
- Co-located artifacts (proofs organized by task within each spec)
- Team-managed lifecycle (flexibility for archival)
- Clear traceability (easy to see which proofs belong to which tasks)
- Consistent naming (standardized
[spec]-[task]-[artifact]pattern)These principles are excellent and should prevent future organizational drift.
.pre-commit-config.yaml (1)
40-40: ****The change is consistent with the project's established tooling. Your codebase extensively documents
uvas the required package manager and task runner—setup instructions inCONTRIBUTING.mdbegin withuv sync, anddocs/operations.mdstandardizes onuv runcommands throughout. The pre-commit hook aligns with this existing convention rather than introducing an undocumented dependency.Likely an incorrect or invalid review comment.
There was a problem hiding this comment.
Pull Request Overview
This PR implements a comprehensive refactoring of the Spec-Driven Development (SDD) workflow prompts to improve consistency, clarity, and user experience. The refactoring addresses inconsistent naming conventions, missing workflow context, unclear directory structures, and lack of standardized guidance by applying research-backed prompt engineering best practices across all four workflow prompts.
Key Changes:
- Standardized prompt structure with consistent "You are here in the workflow" sections, role definitions, and next-step guidance across all prompts
- Enhanced scope management with proactive assessment, chain-of-thought reasoning, and explicit non-goals sections to prevent inappropriate feature sizes
- Updated directory structure from flat
./tasks/to hierarchical./docs/specs/[n]-spec-[feature-name]/with simplified numbering (01, 02 vs 0001, 0002)
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| prompts/validate-spec-implementation.md | New validation prompt with comprehensive workflow integration, QA engineer persona, and evidence-based verification protocols |
| prompts/manage-tasks.md | Enhanced implementation prompt with structured checklists, checkpoint options, and mandatory proof artifact creation protocols |
| prompts/generate-task-list-from-spec.md | Improved task generation with two-phase approach, demoable unit focus, and spec-to-task mapping guidance |
| prompts/generate-spec.md | Enhanced spec creation with initial scope assessment, clarifying questions framework, and structured specification template |
| docs/archive/refactor-sdd-workflow-prompts.md | Archive document describing the refactoring rationale, best practices, and implementation approach |
| .pre-commit-config.yaml | Updated pre-push test command to use uv run pytest instead of pytest |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
There are some great improvements here @ryderstorm I thought I would compare the previous version to your new PR using the identical prompt and right away there are some excellent improvements
Here is the full v1 vs v2 analysis and don't feel like these improvements need to be made in this PR but here are some suggested improvements to the prompts based on this analysis |
…riven workflow This commit implements comprehensive repository pattern compliance guidance across all four SDD workflow prompts, ensuring AI implementations follow established project standards regardless of technology stack. **Applied research-backed prompt engineering findings:** - Context Engineering: Grounded pattern discovery in repository documentation and configuration rather than prescribing specific tools - Progressive Disclosure: Integrated pattern guidance throughout workflow phases rather than treating as separate concern - Structured Verification: Added repository compliance as validation gates and verification checkpoints following existing research-backed patterns - Framework-Agnostic Design: Used generic examples (pytest, npm test, cargo test, etc.) to work across any technology stack **Enhanced Prompts with Pattern Integration:** 1. **generate-spec.md**: Added repository pattern discovery to Context Assessment and 'Repository Standards' section to spec template 2. **generate-task-list-from-spec.md**: Enhanced Current State Assessment to identify repository standards and added pattern compliance to Quality Checklist 3. **manage-tasks.md**: Added repository pattern review to all execution phases with framework-agnostic quality gate integration 4. **validate-spec-implementation.md**: Added repository compliance as validation gate (GATE E) with dedicated coverage matrix table **Key Improvements Achieved:** - Repository Standards Discovery: AI now automatically identifies coding standards, testing patterns, quality gates, and workflows from project documentation - Framework-Agnostic Guidance: Works with any repository (Python, JavaScript, Rust, etc.) without prescribing specific tools - Seamless Workflow Integration: Pattern compliance woven throughout existing verification mechanisms - Blocking Verification: Repository standards enforced through same checkpoints that ensure workflow adherence **Technical Implementation:** - Enhanced verification checkpoints from 3 to 4 in manage-tasks.md to include pattern compliance - Added R6 Repository Compliance to validation rubric with dedicated evidence collection - Fixed consistency issues (table count, validation process references) - Maintained backward compatibility while adding comprehensive pattern guidance This enhancement ensures that any AI using these prompts will automatically discover and follow existing repository patterns, addressing the critical gap where implementations previously ignored project conventions and standards. Research sources: Context engineering best practices (DAIR AI), structured workflow verification (Skywork AI), and the repository's established research-backed prompt patterns.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
prompts/manage-tasks.md (1)
182-183: Define the[n]placeholder format explicitly for file locations.Line 117 (past review) flagged this inconsistency. The file location requirements use
[n]without explicit definition. While the example at line 118 shows03-task-01-proofs.mdwith zero-padded two-digit format, this should be stated explicitly in the requirements to avoid user confusion.-**Task List**: `./docs/specs/[n]-spec-[feature-name]/[n]-tasks-[feature-name].md` -**Proof Artifacts**: `./docs/specs/[n]-spec-[feature-name]/[n]-proofs/` -**Naming Convention**: `[spec]-[task]-[artifact-type].[ext]` +**Task List**: `./docs/specs/[n]-spec-[feature-name]/[n]-tasks-[feature-name].md` (where `[n]` is a zero-padded 2-digit number: 01, 02, 03, etc.) +**Proof Artifacts**: `./docs/specs/[n]-spec-[feature-name]/[n]-proofs/` (where `[n]` matches the spec number) +**Naming Convention**: `[NN]-task-[TT]-[artifact-type].[ext]` (e.g., `03-task-01-proofs.md` where NN is spec number, TT is task number)
🧹 Nitpick comments (4)
prompts/generate-spec.md (1)
250-252: Clarify the[n]placeholder notation in output requirements.The directory structure uses
[n]as a placeholder, but this is never explicitly defined. While the example at line 252 shows01-spec-user-authentication/, users unfamiliar with the convention may not realize[n]represents a zero-padded two-digit number (01, 02, 03, etc.). Add explicit clarification.-**Directory:** Create `./docs/specs/[n]-spec-[feature-name]/` (Where `n` is a zero-padded 2-digit sequence starting from 01, e.g., `01`, `02`, `03`) +**Directory:** Create `./docs/specs/[n]-spec-[feature-name]/` where `[n]` is a zero-padded 2-digit sequence number starting from 01 (e.g., `01`, `02`, `03`). For example, `01-spec-user-authentication/`, `02-spec-payment-integration/`, etc.prompts/generate-task-list-from-spec.md (3)
55-55: Fix hyphenation in constraint description.The phrase "single line changes" should be hyphenated per grammar rules.
-⚠️ **DO NOT** create tasks that are too large (multi-day) or too small (single line changes) +⚠️ **DO NOT** create tasks that are too large (multi-day) or too small (single-line changes)
99-100: Clarify the[n]placeholder notation for output file locations.Similar to the previous files, the
[n]placeholder in directory and filename patterns needs explicit definition. Add clarity that[n]represents a zero-padded two-digit number.-- **Location:** `./docs/specs/[n]-spec-[feature-name]/` -- **Filename:** `[n]-tasks-[feature-name].md` (e.g., if the Spec is `01-spec-user-profile-editing.md`, save as `01-tasks-user-profile-editing.md`) +- **Location:** `./docs/specs/[n]-spec-[feature-name]/` (where `[n]` is a zero-padded 2-digit number: 01, 02, 03, etc.) +- **Filename:** `[n]-tasks-[feature-name].md` (e.g., if the Spec is `01-spec-user-profile-editing.md`, save as `01-tasks-user-profile-editing.md`)
137-153: Ensure Phase 2 output format notes are preserved when user confirms sub-task generation.Line 106 instructs the prompt to look for "the oldest spec in
./docs/specs/" if the user doesn't provide a reference. However, Phase 2 Output Format section (lines 137-153) doesn't include a "Notes" subsection like Phase 3 does (lines 169-174). For consistency with Phase 3 format and to maintain guidance continuity, consider adding a comparable "Notes" section to Phase 2 output to remind users about repository patterns and testing conventions even during the parent task phase.This isn't critical since Phase 2 is just the parent task level, but aligning the structure of both outputs would improve consistency and user guidance flow.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
prompts/generate-spec.md(2 hunks)prompts/generate-task-list-from-spec.md(3 hunks)prompts/manage-tasks.md(2 hunks)prompts/validate-spec-implementation.md(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- prompts/validate-spec-implementation.md
🧰 Additional context used
🪛 LanguageTool
prompts/generate-task-list-from-spec.md
[grammar] ~55-~55: Use a hyphen to join words.
Context: ...o large (multi-day) or too small (single line changes)
(QB_NEW_EN_HYPHEN)
…older consistency - Fix proof artifact structure conflict in archive document to show single markdown files - Clarify [n] placeholder format to [NN] with explicit zero-padded definition across all prompt files - Fix grammar: 'single line changes' → 'single-line changes' - All quality gates pass: pre-commit hooks, tests, and linting
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
prompts/manage-tasks.md (1)
82-89: Standardize placeholder notation for spec number across all path specifications.Line 83 uses
[n]-spec-[feature-name]but lines 182-183 use[NN]. For consistency, all paths should use[NN](two-digit, zero-padded) notation as specified in the File Location Requirements section (line 182).- [ ] Locate task file: `./docs/specs/[n]-spec-[feature-name]/[n]-tasks-[feature-name].md` + [ ] Locate task file: `./docs/specs/[NN]-spec-[feature-name]/[NN]-tasks-[feature-name].md`Also apply this consistency to line 209:
- [ ] **Directory Ready**: `./docs/specs/[n]-spec-[feature-name]/[n]-proofs/` exists + [ ] **Directory Ready**: `./docs/specs/[NN]-spec-[feature-name]/[NN]-proofs/` exists
🧹 Nitpick comments (5)
docs/archive/refactor-sdd-workflow-prompts.md (2)
45-45: Fix hyphenation in compound adjective.Line 45 should use "top-level" (hyphenated) as a compound adjective modifying "tasks."
- Add guidance on how to evaluate top level tasks against the spec + Add guidance on how to evaluate top-level tasks against the spec
137-137: Capitalize "Markdown" as a proper noun.Line 137 references the formatting language; per style conventions, "Markdown" should be capitalized.
- **Consistent naming**: Proof artifacts follow single markdown file pattern `[spec]-[task]-proofs.md` containing all evidence as markdown code blocks + **Consistent naming**: Proof artifacts follow single markdown file pattern `[spec]-[task]-proofs.md` containing all evidence as Markdown code blocksprompts/generate-spec.md (1)
206-214: Enhance Repository Standards section with actionable guidance.The Repository Standards section (lines 206-214) is well-positioned but could be more actionable. Currently, it provides a list of what to look for but not explicit next steps. Consider:
- Action clarity: Add "Review and document findings" to make the assessment active
- Integration point: Clarify how these findings are incorporated into scope assessment (Step 1) and clarifying questions (Step 2)
- Fallback guidance: Line 214 states "Follow established repository patterns and conventions" but doesn't guide what to do if no standards are clearly identified
The section is adequate but could benefit from explicit connection to earlier workflow steps.
prompts/generate-task-list-from-spec.md (2)
172-174: Add clarity on testing command reference and repository patterns.Line 172 states "Use the repository's established testing command and patterns (e.g.,
npx jest [optional/path/to/test/file],pytest [path],cargo test, etc.)." This is good guidance, but consider:
- Discovery mechanism: How does the implementer know what the repository's testing command is? Should there be a reference to where this was captured (e.g., from the Spec's Repository Standards section)?
- Consistency with Phase 1: Lines 114 state "Testing patterns and infrastructure" should be assessed, but Phase 1 doesn't explicitly require documenting the testing command.
Suggest adding a note: "Refer to the testing patterns and commands identified during codebase assessment (Phase 1, step 3)."
137-153: Verify Phase 2 Output Format example clarity.The Phase 2 output format (lines 137-153) is well-structured, but the demo criteria and proof artifacts examples could be more explicit. For instance:
- Line 145:
Demo Criteria: "Open /path and complete X end-to-end; acceptance: Y visible/returned"- The placeholders (X, Y) are abstract; a concrete example would help.- Line 146:
Proof Artifact(s): "URL: https://..., CLI: command & expected output, Test: MyFeature.test.ts"- Should clarify that this is a list of evidence types, not literal format.Consider adding a concrete example with a filled-in parent task (e.g., for a user registration feature) to make the output format more tangible.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
docs/archive/refactor-sdd-workflow-prompts.md(1 hunks)prompts/generate-spec.md(2 hunks)prompts/generate-task-list-from-spec.md(3 hunks)prompts/manage-tasks.md(2 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/archive/refactor-sdd-workflow-prompts.md
[grammar] ~45-~45: Use a hyphen to join words.
Context: ...st - Add guidance on how to evaluate top level tasks against the spec - Enhance t...
(QB_NEW_EN_HYPHEN)
[uncategorized] ~137-~137: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...]-proofs.md` containing all evidence as markdown code blocks ### Simplify numbering sys...
(MARKDOWN_NNP)
🔇 Additional comments (1)
prompts/manage-tasks.md (1)
117-122: Clarify proof artifact creation expectations and execution timing.Line 121 states "Execute commands immediately: Capture command output directly in the markdown file," but this guidance conflicts with typical workflows where proof artifacts are created after implementation, not during the checklist. Clarify whether proof artifacts should be:
- Generated during implementation (as sub-tasks complete) and captured in the single markdown file, or
- Gathered after all sub-tasks complete and compiled into the proof file before committing
The current phrasing suggests real-time capture, which may not align with the sub-task execution flow (lines 94-106).
…and grammar - Fix remaining [n] → [NN] placeholder inconsistencies in generate-spec.md and generate-task-list-from-spec.md - Fix grammar: 'top level' → 'top-level' in archive document - Fix capitalization: 'markdown' → 'Markdown' as proper noun - All quality gates pass: pre-commit hooks, tests (79/85%), and linting
- Fixed remaining [n] placeholders in validate-spec-implementation.md - Fixed [n] → [NN] in generate-spec.md template header - Fixed [n] → [NN] in generate-task-list-from-spec.md final instructions - Fixed [n] → [NN] in manage-tasks.md checklist and protocol sections - All prompt files now consistently use [NN] for zero-padded two-digit spec numbers - Quality gates pass: pre-commit hooks, linting, and formatting
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
prompts/generate-spec.md (1)
160-234: Spec template structure is well-organized, but verify sections avoid duplication.The template distinguishes between User Stories (motivation/"WHY"), Demoable Units (progress/"WHAT will be shown"), Functional Requirements (behavior/"WHAT the system must do"), and Technical Considerations (constraints/"HOW it will be built"). Line 287–291 in Final Instructions clarifies these distinctions.
However, confirm with users that Repository Standards (lines 206–214) and Technical Considerations (lines 216–218) remain separate concerns: Standards capture existing patterns to follow; Technical Considerations capture constraints specific to this feature. This dual approach is intentional but could be clearer in the template itself.
Consider adding a clarifying note within the template (after line 206 or as a footnote) explicitly stating: "Repository Standards documents patterns the codebase already follows; Technical Considerations documents constraints unique to this feature's implementation."
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
docs/archive/refactor-sdd-workflow-prompts.md(1 hunks)prompts/generate-spec.md(2 hunks)prompts/generate-task-list-from-spec.md(3 hunks)prompts/manage-tasks.md(2 hunks)prompts/validate-spec-implementation.md(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- prompts/validate-spec-implementation.md
🔇 Additional comments (15)
prompts/generate-spec.md (2)
250-292: All placeholder notation uses [NN] consistently throughout the file. ✓Line 250 correctly establishes
[NN]as the zero-padded 2-digit placeholder. Examples (line 252:01-spec-user-authentication/) and Final Instructions (line 292) maintain this convention. This resolves the prior standardization flag.
275-295: "What Comes Next" and Final Instructions properly guide to task generation.Line 277 correctly directs the user to
/generate-task-list-from-specand Final Instructions (lines 281–295) consolidate the workflow sequence. This aligns well with the next prompt in the workflow.docs/archive/refactor-sdd-workflow-prompts.md (2)
113-138: Directory structure example correctly shows one markdown proof file per task, aligning with updated specification.Lines 118–128 display
01-01-proofs.md,01-02-proofs.md, etc., which ARE single markdown files per task. Line 137's description ("single Markdown file pattern ... containing all evidence as Markdown code blocks") confirms this approach. This resolves the prior conflict flagged in review comments.Cross-verify: manage-tasks.md line 118 specifies
[spec-number]-task-[task-number]-proofs.md(e.g.,03-task-01-proofs.md), which matches the archive's intent.
1-9: Document clearly states workflow goals and configuration philosophy.Lines 3–8 articulate the intent to keep the workflow simple and accessible while handling customization via prompts. This framing helps readers understand the design rationale.
prompts/generate-task-list-from-spec.md (4)
51-56: Critical Constraints clearly enforce planning discipline with explicit "DO NOT" statements.Lines 51–56 establish non-negotiable boundaries:
- DO NOT generate sub-tasks until explicitly requested (line 53)
- DO NOT begin implementation (line 54)
- DO NOT create inappropriately-sized tasks (line 55)
- DO NOT skip user confirmation (line 56)
These are strong safeguards against premature implementation and ensure the two-phase workflow is followed.
137-154: Phase 2 Output format explicitly omits sub-tasks, preventing accidental full spec generation.The template at lines 137–153 shows parent tasks only (
1.0,2.0,3.0) with Demo Criteria and Proof Artifact(s), clearly distinct from Phase 3 (lines 155–193) which adds sub-tasks and Relevant Files sections. This structure enforces the checkpoint between phases.
195-204: Interaction Model clearly enforces explicit user confirmation between phases.Lines 195–204 establish the two-phase checkpoint:
- "After generating parent tasks, you must stop and present them for review" (line 199)
- "Only proceed to sub-tasks after user responds with 'Generate sub tasks'" (line 200)
- Example interaction shows AI prompting user for confirmation (line 204)
This prevents auto-progression and enforces deliberate user review. ✓
172-174: Repository-pattern guidance includes framework-agnostic testing examples.Line 172 shows testing patterns for multiple frameworks (
npx jest,pytest,cargo test), making this prompt accessible across different tech stacks. Consistent with PR objectives for framework-agnostic patterns.prompts/manage-tasks.md (7)
51-72: Checkpoint Options clearly present three modes with defaults and preferences.Lines 51–72 offer:
- Continuous Mode: After each sub-task (1.1, 1.2, 1.3)
- Task Mode: After each parent task (1.0, 2.0, 3.0) — marked as default (line 70)
- Batch Mode: After all tasks complete
Each mode includes Pros/Cons and use-case guidance. Line 72 notes that any previously-specified preference from the user in the conversation should be remembered.
111-147: Parent Task Completion Checklist enforces correct sequence and blocking verification.The checklist (lines 111–147) follows a strict sequence:
- Run Test Suite (line 115)
- Quality Gates (line 116)
- Create Proof Artifacts (line 117–122) — creates single markdown file with all evidence
- Verify Demo Criteria (line 123)
- Stage Changes (line 124)
- Create Commit (line 125–130)
- Mark Parent Complete (line 135)
- Save Task File (line 136)
Blocking Verification (lines 138–145) requires all four items checked before proceeding:
- Proof File exists and contains evidence
- Git Commit verified via
git log- Task File shows parent as [x]
- Pattern Compliance verified
This creates a clear, auditable workflow. ✓
117-122: Proof artifact file naming uses correct notation: [NN] for spec, [TT] for task.Line 118 specifies:
[spec-number]-task-[task-number]-proofs.md(e.g.,03-task-01-proofs.md)This is correct: 03 = spec 3, 01 = task 1 within that spec. Format matches archive doc (line 137 of refactor-sdd-workflow-prompts.md) and is zero-padded as intended.
182-184: File location requirements define consistent naming with [NN] and [TT] placeholders.Lines 182–184 establish:
- Task List:
./docs/specs/[NN]-spec-[feature-name]/[NN]-tasks-[feature-name].md(zero-padded 2-digit spec number)- Proof Artifacts:
./docs/specs/[NN]-spec-[feature-name]/[NN]-proofs/(zero-padded 2-digit spec number)- Naming Convention:
[NN]-task-[TT]-[artifact-type].[ext](e.g.,03-task-01-proofs.md)All placeholders use consistent zero-padded notation aligned with other prompts. ✓
125-130: Git commit protocol uses conventional commits with task/spec references.Lines 124–130 define the sequence and format:
git add . git commit -m "feat: [task-description]" -m "- [key-details]" -m "Related to T[task-number] in Spec [spec-number]"Format is clear and includes task/spec traceability. However, verify the variable placeholders match actual task numbering (e.g., "T01" vs "T1.1" vs "Task 1.1").
Does the commit message template correctly reflect task numbering from the task file? For example, if the task is "1.0 Parent Task Title", should the reference be "T1.0", "T01", or something else?
202-226: Proof Artifact Creation Protocol defines single markdown file with clear sections.Lines 205–225 prescribe one markdown file per parent task containing:
- CLI Output section
- Test Results section
- Screenshots section
- Configuration section
- Demo Validation section
Line 221 states: "One file per task, all evidence included" and line 225 reinforces: "The single markdown proof file must be created BEFORE the parent task commit."
This enforces the proof-before-commit sequence required for validation. ✓
268-278: "What Happens Next" section properly guides progression to validation.Lines 268–278 clearly state:
- After ALL tasks complete, run Final Verification
- Demo Validation (verify all demo criteria from spec are met)
- Test Suite (comprehensive final run)
- Documentation updates
- Handoff to
/validate-spec-implementationLine 278 explains validation will use proof artifacts as evidence. This maintains workflow progression from spec → tasks → implementation → validation.
RobertKelly
left a comment
RobertKelly
left a comment
There was a problem hiding this comment.
Good addition of adherence to repository patterns and standards.
Why?
This PR implements a comprehensive refactoring of the Spec-Driven Development (SDD) workflow prompts to improve consistency, clarity, and user experience. The original prompts had several issues: inconsistent naming conventions, missing workflow context sections, unclear directory structure references, lack of standardized next-step guidance, no proactive scope management, and no guidance for following existing repository patterns. This refactoring addresses these problems by applying research-backed prompt engineering best practices and ensuring all prompts follow a consistent structure that guides users seamlessly through the workflow from idea to validation while automatically adapting to any repository's established patterns and conventions.
What Changed?
Key Changes:
New Repository Pattern Compliance Feature:
Repository Pattern Integration Details:
New Scoping Functionality:
Technical Improvements:
Additional Notes
Review Checklist
Summary by CodeRabbit
Documentation
Chores