pdd-cli 0.0.90__py3-none-any.whl → 0.0.118__py3-none-any.whl

pdd/prompts/agentic_change_step12_create_pr_LLM.prompt

@@ -0,0 +1,131 @@
+% You are an expert software engineer. Your task is to create a pull request from the worktree branch and link it to the original GitHub issue.
+
+% Context
+
+You are working on step 12 of 12 in an agentic change workflow. This is the final step. All prompt changes have been made and verified. Now you create a PR for review.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Issue Title: {issue_title}
+- Worktree Path: {worktree_path}
+- Branch Name: change/issue-{issue_number}
+- Files Changed: {files_to_stage}
+
+% Issue Content
+<issue_content>
+{issue_content}
+</issue_content>
+
+% Change Summary (from previous steps)
+<step8_output>
+{step8_output}
+</step8_output>
+
+% Your Task
+
+1. **Stage all changes**
+   ```bash
+   cd {worktree_path}
+   git add -A
+   ```
+
+2. **Create commit**
+   - Use a clear commit message referencing the issue
+   - Format: `feat: [brief description] (#{issue_number})`
+
+3. **Push branch**
+   ```bash
+   git push -u origin change/issue-{issue_number}
+   ```
+
+4. **Create pull request**
+   Use `gh pr create` to create a PR that:
+   - References the original issue
+   - Summarizes the prompt changes made
+   - Lists files modified
+   - Includes next steps for reviewer
+
+5. **Link PR to issue**
+   - The PR body should include `Closes #{issue_number}` or `Fixes #{issue_number}`
+   - This ensures the issue is automatically closed when PR is merged
+
+% Output
+
+Create the PR using the gh CLI:
+
+```bash
+gh pr create --title "feat: [description] (#{issue_number})" --body "..." --base main --head change/issue-{issue_number}
+```
+
+Then post a final comment to the issue:
+
+```
+gh issue comment {issue_number} --repo {repo_owner}/{repo_name} --body "..."
+```
+
+**PR Body Format:**
+```markdown
+## Summary
+
+[1-2 sentence description of what this PR does]
+
+Closes #{issue_number}
+
+## Changes Made
+
+### Prompts Modified
+- `prompts/xxx_python.prompt` - [brief description]
+- `prompts/yyy_python.prompt` - [brief description]
+
+### Documentation Updated
+- `README.md` - [brief description]
+
+## Review Checklist
+
+- [ ] Prompt syntax is valid
+- [ ] PDD conventions followed
+- [ ] Documentation is up to date
+
+## Next Steps After Merge
+
+1. Run `pdd sync <module>` to regenerate code from modified prompts
+2. Run tests to verify functionality
+3. Deploy if applicable
+
+---
+*Created by pdd change workflow*
+```
+
+**Issue Comment Format:**
+```markdown
+## Step 12: Pull Request Created
+
+**Status:** PR Ready for Review
+
+### Pull Request
+[PR #{{pr_number}}]({{pr_url}})
+
+### Summary
+- Branch: `change/issue-{issue_number}`
+- Files changed: {{N}}
+- Ready for review
+
+### What's Next
+1. Review the PR
+2. Run `pdd sync` on affected modules after merge
+3. Run tests to verify
+
+---
+*Agentic change workflow complete. Total cost: ${{total_cost:.4f}}*
+```
+
+% Important
+
+- Always link the PR to the issue using "Closes #N" or "Fixes #N"
+- Push to origin before creating PR
+- Include clear next steps for the reviewer
+- Report the PR URL in the issue comment
+- This is the final step - workflow is complete after this

pdd/prompts/agentic_change_step1_duplicate_LLM.prompt

@@ -0,0 +1,73 @@
+% You are an expert software engineer investigating a change request. Your task is to check if this issue is a duplicate of an existing issue.
+
+% Context
+
+You are working on step 1 of 12 in an agentic change workflow. Your findings will be posted as a comment on the GitHub issue.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+
+% Issue Content
+<issue_content>
+{issue_content}
+</issue_content>
+
+% Your Task
+
+1. **Search for duplicates**
+   - Use `gh issue list` to search for similar issues in this repository
+   - Look for issues with similar feature requests, enhancement descriptions, or change proposals
+   - Consider both open and closed issues
+   - Search using key terms from the request (feature names, affected modules, desired behavior)
+
+2. **Evaluate matches**
+   - For each potential duplicate, read the issue to verify similarity
+   - Consider: same feature request? same affected modules? same desired outcome?
+   - A true duplicate requests the same change, not just uses similar keywords
+
+3. **Handle duplicates**
+   If duplicates are found:
+   - Merge any unique information from this issue into the original
+   - Add a comment to the original issue noting the additional context
+   - Close this issue with a comment linking to the original
+   - Report which issue is the canonical one
+
+   If no duplicates:
+   - Report that this appears to be a new change request
+   - Proceed with investigation
+
+% Output
+
+After completing your analysis, use `gh issue comment` to post your findings to issue #{issue_number}:
+
+```
+gh issue comment {issue_number} --repo {repo_owner}/{repo_name} --body "..."
+```
+
+Your comment should follow this format:
+
+```markdown
+## Step 1: Duplicate Check
+
+**Status:** [No duplicates found | Duplicate of #XXX]
+
+### Search Performed
+- Searched for: [key terms used]
+- Issues reviewed: [count]
+
+### Findings
+[If duplicates found: explanation of why they match and what action was taken]
+[If no duplicates: brief confirmation this is a new change request]
+
+---
+*Proceeding to Step 2: Documentation Check*
+```
+
+% Important
+
+- Always post your findings as a GitHub comment before completing
+- If this is a duplicate, still post a comment explaining the closure
+- Be thorough but efficient in your search

pdd/prompts/agentic_change_step2_docs_LLM.prompt

@@ -0,0 +1,101 @@
+% You are an expert software engineer investigating a change request. Your task is to check if the requested change is already implemented or documented.
+
+% Context
+
+You are working on step 2 of 12 in an agentic change workflow. Previous step checked for duplicate issues.
+
+**This step may terminate the workflow** if the feature is already implemented.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Issue Author: @{issue_author}
+
+% Issue Content
+<issue_content>
+{issue_content}
+</issue_content>
+
+% Previous Step Output
+<step1_output>
+{step1_output}
+</step1_output>
+
+% Your Task
+
+1. **Locate documentation**
+   - Find README.md, docs/, CONTRIBUTING.md, and any relevant documentation
+   - Look for API documentation, usage guides, or configuration docs
+   - Check for inline documentation in relevant code files
+
+2. **Check for existing implementation**
+   - Is the requested feature already implemented?
+   - Are there documented ways to achieve the same outcome?
+   - Does the documentation describe how to do what the user wants?
+
+3. **Evaluate**
+   - **Already Implemented**: Feature exists and is documented → STOP workflow
+   - **Partially Implemented**: Feature exists but needs enhancement → Continue workflow
+   - **Not Implemented**: Feature doesn't exist → Continue workflow
+   - **Documentation Gap**: Feature exists but isn't documented → Continue (fix docs)
+
+% Output
+
+After completing your analysis, use `gh issue comment` to post your findings to issue #{issue_number}:
+
+```
+gh issue comment {issue_number} --repo {repo_owner}/{repo_name} --body "..."
+```
+
+Your comment should follow this format:
+
+**If Not Implemented or Needs Enhancement:**
+```markdown
+## Step 2: Documentation Check
+
+**Status:** [Not Implemented | Partially Implemented | Documentation Gap]
+
+### Documentation Reviewed
+- [List of files/sections checked]
+
+### Findings
+[Explanation of current state vs. what the user requests]
+
+---
+*Proceeding to Step 3: Identify Dev Units*
+```
+
+**If Already Implemented (STOP workflow):**
+```markdown
+## Step 2: Documentation Check
+
+**Status:** Already Implemented
+
+### Documentation Reviewed
+- [List of files/sections checked]
+
+### Findings
+The requested feature is already available. Here's how to use it:
+
+**Current implementation:**
+[Quote or summarize relevant documentation]
+
+**How to achieve your goal:**
+[Step-by-step instructions for the user]
+
+### Recommendation
+The feature you requested already exists. Please try the approach above. If this doesn't meet your needs, please reopen this issue with more specific requirements.
+
+---
+*Investigation paused - feature already exists.*
+```
+
+% Important
+
+- **STOP the workflow** if status is "Already Implemented"
+- **CONTINUE the workflow** if status is "Not Implemented", "Partially Implemented", or "Documentation Gap"
+- Tag the issue author when providing guidance
+- Be helpful and provide clear instructions if feature exists
+- Always post your findings as a GitHub comment before completing

pdd/prompts/agentic_change_step3_research_LLM.prompt

@@ -0,0 +1,126 @@
+% You are an expert software engineer using Prompt-Driven Development (PDD). Your task is to research and clarify the feature change request using web search.
+
+% Context
+
+You are working on step 3 of 12 in an agentic change workflow. Previous steps confirmed this is not a duplicate and the feature is not already implemented. Now you need to research the topic to better understand the requirements.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+
+% Issue Content
+<issue_content>
+{issue_content}
+</issue_content>
+
+% Previous Step Outputs
+<step1_output>
+{step1_output}
+</step1_output>
+
+<step2_output>
+{step2_output}
+</step2_output>
+
+% Your Task
+
+1. **Identify knowledge gaps**
+   - What technical concepts in the issue need clarification?
+   - Are there industry standards or best practices to consider?
+   - Are there existing libraries, tools, or patterns that could inform the implementation?
+
+2. **Conduct web research**
+   - Search for relevant documentation, tutorials, or examples
+   - Look for similar implementations in other projects
+   - Find best practices for the type of feature being requested
+   - Check for any security considerations or common pitfalls
+
+3. **Synthesize findings**
+   - Summarize the key insights from your research
+   - Identify how these findings affect the implementation approach
+   - Note any constraints or requirements discovered during research
+   - Highlight any alternative approaches worth considering
+
+4. **Refine specifications**
+   - Based on research, clarify any ambiguous requirements
+   - Suggest specific implementation details informed by best practices
+   - Identify edge cases or considerations the original issue may have missed
+
+% Output
+
+After completing your research, use `gh issue comment` to post your findings to issue #{issue_number}:
+
+```
+gh issue comment {issue_number} --repo {repo_owner}/{repo_name} --body "..."
+```
+
+Your comment should follow this format:
+
+```markdown
+## Step 3: Research & Clarification
+
+**Status:** [Research Complete | Additional Clarification Needed]
+
+### Summary
+[1-2 sentence summary of the research focus and key findings]
+
+### Research Findings
+
+#### Technical Background
+[Key concepts, standards, or patterns relevant to this feature]
+
+#### Best Practices
+[Industry best practices or patterns that should inform the implementation]
+
+#### Similar Implementations
+[Examples from other projects or libraries, if found]
+
+#### Security/Edge Cases
+[Any security considerations or edge cases discovered]
+
+### Refined Specifications
+Based on the research, here are clarified requirements:
+1. [Clarified requirement or specification]
+2. [Additional consideration from research]
+3. [Edge case to handle]
+
+### Alternative Approaches Considered
+- [Alternative 1]: [pros/cons]
+- [Alternative 2]: [pros/cons]
+
+### Recommended Approach
+[Brief recommendation based on research]
+
+---
+*Proceeding to Step 4: Documentation Changes*
+```
+
+**If additional user input is needed (PAUSE workflow):**
+```markdown
+## Step 3: Research & Clarification
+
+**Status:** Additional Clarification Needed
+
+### Research Summary
+[What was researched and found]
+
+### Questions for Clarification
+1. [Specific question that needs user input]
+2. [Another question if applicable]
+
+### Why This Matters
+[Brief explanation of how the answer affects implementation]
+
+---
+*Awaiting user response before proceeding.*
+```
+
+% Important
+
+- Focus on research that directly informs the implementation
+- Be thorough but concise in summarizing findings
+- Prioritize authoritative sources (official docs, established libraries)
+- If the issue is already well-specified, acknowledge this and proceed
+- Always post your findings as a GitHub comment before completing

pdd/prompts/agentic_change_step4_clarify_LLM.prompt

@@ -0,0 +1,164 @@
+% You are an expert software engineer using Prompt-Driven Development (PDD). Your task is to determine if the feature change request is clear enough to proceed with implementation.
+
+% Context
+
+You are working on step 4 of 12 in an agentic change workflow. Previous steps confirmed this is not a duplicate, is not already implemented, and conducted research. Now you must determine if the requirements are sufficiently clear.
+
+**This step may STOP the workflow** if clarifying questions are needed. When the user answers and runs `pdd change` again, this step will re-evaluate.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Issue Author: {issue_author}
+
+% Issue Content
+<issue_content>
+{issue_content}
+</issue_content>
+
+% Previous Step Outputs
+<step1_output>
+{step1_output}
+</step1_output>
+
+<step2_output>
+{step2_output}
+</step2_output>
+
+<step3_output>
+{step3_output}
+</step3_output>
+
+% Your Task
+
+1. **Analyze clarity of requirements**
+   Review the issue content and research findings to assess:
+   - Is the problem statement clear and unambiguous?
+   - Are the expected outcomes/behaviors well-defined?
+   - Are there conflicting or vague requirements?
+   - Are edge cases and error handling addressed?
+   - Is the scope bounded (not too broad)?
+
+2. **Check for missing information**
+   Identify gaps that would block implementation:
+   - Missing input/output specifications
+   - Undefined behavior for edge cases
+   - Unclear integration points with existing code
+   - Ambiguous terminology or concepts
+   - Missing acceptance criteria
+
+3. **Decide: Clear or Needs Clarification**
+
+   **CLEAR ENOUGH** if:
+   - Core functionality is well-defined
+   - Implementation approach can be determined
+   - Edge cases can be reasonably inferred
+   - Minor ambiguities can be resolved during implementation
+
+   **NEEDS CLARIFICATION** if:
+   - Core requirements are ambiguous
+   - Multiple valid interpretations exist
+   - Critical edge cases are undefined
+   - Implementation would require guessing user intent
+
+4. **If clarification needed, formulate questions with options**
+   - Ask specific, actionable questions
+   - Provide context for why the answer matters
+   - **Always provide 2-3 possible answers** with explanations
+   - Explain the implications of each option
+   - Make a recommendation if you have a preference
+   - Limit to 2-4 most critical questions
+
+% Output
+
+After completing your analysis, use `gh issue comment` to post your findings to issue #{issue_number}:
+
+```
+gh issue comment {issue_number} --repo {repo_owner}/{repo_name} --body "..."
+```
+
+**If requirements are CLEAR ENOUGH:**
+```markdown
+## Step 4: Requirements Clarity Check
+
+**Status:** Requirements Clear
+
+### Clarity Assessment
+| Aspect | Status |
+|--------|--------|
+| Problem statement | :white_check_mark: Clear |
+| Expected outcomes | :white_check_mark: Defined |
+| Scope | :white_check_mark: Bounded |
+| Edge cases | :white_check_mark: Addressable |
+
+### Understanding Summary
+[1-2 sentence summary of what will be implemented]
+
+### Assumptions Made
+- [Any reasonable assumptions for minor ambiguities]
+
+---
+*Proceeding to Step 5: Documentation Changes*
+```
+
+**If CLARIFICATION NEEDED (STOP workflow):**
+```markdown
+## Step 4: Requirements Clarity Check
+
+**Status:** Clarification Needed
+
+### Clarity Assessment
+| Aspect | Status |
+|--------|--------|
+| Problem statement | :white_check_mark: Clear |
+| Expected outcomes | :x: Unclear |
+| Scope | :warning: Partially defined |
+| Edge cases | :x: Not addressed |
+
+### What's Clear
+[Summary of well-defined aspects]
+
+### Questions for @{issue_author}
+
+To proceed with implementation, I need clarification on the following:
+
+1. **[Topic - e.g., "Input Validation"]**
+
+   [Brief context explaining why this matters for implementation]
+
+   **Options:**
+   - **A) [Option name]**: [Description of this approach]
+     - Implications: [What this means for the implementation]
+   - **B) [Option name]**: [Description of this approach]
+     - Implications: [What this means for the implementation]
+   - **C) [Option name]**: [Description of this approach]
+     - Implications: [What this means for the implementation]
+
+   **Recommendation:** [Your suggestion if you have one, and why]
+
+2. **[Topic]**
+
+   [Context]
+
+   **Options:**
+   - **A)** [Option and implications]
+   - **B)** [Option and implications]
+
+### Next Steps
+Please reply with your preferred options (e.g., "1A, 2B"). Then run `pdd change {issue_url}` again to continue.
+
+---
+*Workflow paused - awaiting clarification from @{issue_author}*
+```
+
+% Important
+
+- Be pragmatic: don't block on minor details that can be reasonably inferred
+- Focus on questions that would significantly impact implementation approach
+- If requirements are 80%+ clear, proceed rather than block
+- Consider that the issue author may not be technical - phrase questions accessibly
+- Always tag the issue author (@{issue_author}) in clarification requests
+- This is a HARD STOP - if clarification is needed, the workflow terminates here
+- When `pdd change` is run again, this step will re-evaluate based on new comments