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

pdd/prompts/agentic_crash_explore_LLM.prompt

@@ -0,0 +1,49 @@
+You are fixing a crash in a PDD (Prompt-Driven Development) project.
+You are running as FALLBACK after PDD's normal crash loop failed multiple times. This loop was only allowed to change the code and/or program file.
+The error(s) is likely outside of these files.
+
+## PDD Principle
+The PROMPT FILE is the source of truth. Code is a generated artifact.
+The PROGRAM FILE calls the code and crashed. Both files may need fixes.
+
+## Files (you have full read/write access)
+- Prompt file (THE SPEC): {prompt_path}
+- Code file: {code_path}
+- Program file: {program_path}
+- Project root: {project_root}
+
+## Previous Fix Attempts
+The following shows what PDD's normal crash loop already tried.
+DO NOT repeat these approaches - try something different.
+
+<previous_attempts>
+{previous_attempts}
+</previous_attempts>
+
+## Your Task
+1. Read the prompt file to understand the intended behavior
+2. Read the code and program files
+3. Analyze the crash traceback to identify the root cause
+4. Explore related files (imports, dependencies, conftest.py) if needed
+5. Determine what needs fixing:
+   - Code has a bug -> fix the code
+   - Program calls code incorrectly -> fix the program
+   - Both have issues -> fix both
+   - Issue requires changes to other files -> make those changes
+6. Make ALL necessary changes to stop the crash including other files if needed
+7. Run the program file to verify the fix
+8. Repeat steps 4-7 until the program output aligns with the prompt's intent
+9. Output a JSON string with the following fields:
+   - success: bool
+   - message: str
+   - cost: float
+   - model: str
+   - changed_files: list[str]
+
+## Critical Rules
+- The prompt file defines what's correct - code should conform to it
+- DO NOT repeat approaches from the fix history above
+- You MAY modify BOTH the code file AND the program file
+- IMPORTANT: Read actual source files before assuming what functions/classes exist
+  - Do NOT guess at imports or API names
+  - Explore the codebase to understand actual exports

pdd/prompts/agentic_e2e_fix_step1_unit_tests_LLM.prompt

@@ -0,0 +1,90 @@
+% You are an expert software engineer fixing bugs identified in a GitHub issue. Your task is to run the **issue-specific unit tests** (created by `pdd bug`) and fix any failures using pdd fix.
+
+% Context
+
+You are working on step 1 of 9 in an agentic e2e fix workflow. This issue was typically created by `pdd bug` and contains unit tests that need to pass.
+
+**Important distinction from Step 8:**
+- Step 1 (this step): Runs unit tests **explicitly listed in the GitHub issue** (created by `pdd bug`) and fixes their associated dev units
+- Step 8: Runs pdd fix on dev units **identified during e2e failure analysis** in Steps 3-5 (may be different dev units)
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Cycle: {cycle_number}/{max_cycles}
+
+% Issue Content
+<issue_content>
+{issue_content}
+</issue_content>
+
+% Your Task
+
+1. **Identify unit tests from the issue**
+   - Parse the issue content to find unit test file paths
+   - Look for patterns like `tests/test_*.py`, `FILES_CREATED:`, or test code blocks
+   - Extract the test file paths and test function names
+
+2. **Run the unit tests**
+   - Execute pytest with the test files you identified above (e.g., `pytest tests/test_foo.py -v`)
+   - Capture the output including any failures
+   - Note which tests pass and which fail
+
+3. **For each failing test, run pdd fix**
+   - Identify the dev unit (module) associated with each failing test
+   - For each failing dev unit, run pdd fix in manual mode:
+     ```bash
+     # Create a temp error file for pdd fix
+     touch /tmp/pdd_fix_errors_{{dev_unit}}.log
+     pdd fix --manual prompts/{{dev_unit}}_python.prompt pdd/{{dev_unit}}.py tests/test_{{dev_unit}}.py /tmp/pdd_fix_errors_{{dev_unit}}.log --loop
+     ```
+   - Run pdd fix sequentially, one dev unit at a time
+   - Capture the output of each pdd fix run
+
+4. **Re-run unit tests to verify fixes**
+   - After all pdd fix runs complete, re-run the unit tests
+   - Report which tests now pass vs still fail
+
+% 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: Unit Test Execution (Cycle {cycle_number})
+
+**Status:** [All Tests Pass | N Tests Still Failing]
+
+### Unit Tests Identified
+- `{{test_file}}::{{test_function}}`
+- ...
+
+### Initial Test Results
+- Passed: {{N}}
+- Failed: {{N}}
+
+### pdd fix Runs
+| Dev Unit | Result |
+|----------|--------|
+| {{name}} | Fixed / Still Failing |
+
+### Final Test Results
+- Passed: {{N}}
+- Failed: {{N}}
+
+---
+*Proceeding to Step 2: E2E Test Check*
+```
+
+% Important
+
+- Run pdd fix sequentially, not in parallel
+- If a dev unit has already been fixed in a previous cycle, skip it unless tests still fail
+- Always post your findings as a GitHub comment before completing

pdd/prompts/agentic_e2e_fix_step2_e2e_tests_LLM.prompt

@@ -0,0 +1,91 @@
+% You are an expert software engineer fixing bugs identified in a GitHub issue. Your task is to run e2e tests and check if they all pass.
+
+% Context
+
+You are working on step 2 of 9 in an agentic e2e fix workflow. This step checks if all e2e tests pass, which is the exit condition for the outer loop.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Cycle: {cycle_number}/{max_cycles}
+
+% Issue Content
+<issue_content>
+{issue_content}
+</issue_content>
+
+% Previous Step Output
+<step1_output>
+{step1_output}
+</step1_output>
+
+% Your Task
+
+1. **Identify e2e tests from the issue**
+   - Parse the issue content to find e2e test file paths
+   - Look for `E2E_FILES_CREATED:` markers from `pdd bug` output
+   - Also check for patterns like `tests/e2e/`, `tests/integration/`, or `test_e2e_*.py`
+
+2. **Run the e2e tests**
+   - Execute pytest with the e2e test files you identified above (e.g., `pytest tests/e2e/test_foo.py -v`)
+   - Capture the full output including any failures
+   - Note specific error messages and stack traces
+
+3. **Evaluate results**
+   - If ALL tests pass: Output includes "ALL_TESTS_PASS" (triggers outer loop exit)
+   - If ANY tests fail: Document failures for root cause analysis
+
+% 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 all tests pass:**
+```markdown
+## Step 2: E2E Test Check (Cycle {cycle_number})
+
+**Status:** ALL_TESTS_PASS
+
+### E2E Tests Run
+- `{{test_file}}::{{test_function}}` ✓
+- ...
+
+### Summary
+All {{N}} e2e tests pass. Bug fix complete!
+
+---
+*Workflow complete - all tests passing*
+```
+
+**If tests fail:**
+```markdown
+## Step 2: E2E Test Check (Cycle {cycle_number})
+
+**Status:** {{N}} Tests Failing
+
+### E2E Tests Run
+- `{{test_file}}::{{test_function}}` ✓
+- `{{test_file}}::{{test_function}}` ✗
+
+### Failures
+#### `{{test_name}}`
+```
+{{error_message_and_stack_trace}}
+```
+
+---
+*Proceeding to Step 3: Root Cause Analysis*
+```
+
+% Important
+
+- The exact string "ALL_TESTS_PASS" triggers the outer loop exit - only output it if ALL tests truly pass
+- Capture complete error messages and stack traces for failing tests
+- Always post your findings as a GitHub comment before completing

pdd/prompts/agentic_e2e_fix_step3_root_cause_LLM.prompt

@@ -0,0 +1,89 @@
+% You are an expert software engineer fixing bugs identified in a GitHub issue. Your task is to root cause the e2e test failures.
+
+% Context
+
+You are working on step 3 of 9 in an agentic e2e fix workflow. E2e tests are failing and you need to determine whether the problem is in the code, the tests, or both.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Cycle: {cycle_number}/{max_cycles}
+
+% 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. **Analyze the test failures**
+   - Review the error messages and stack traces from Step 2
+   - Identify the assertion that failed or exception that was raised
+   - Trace back to understand what behavior was unexpected
+
+2. **Review the documentation**
+   - Check project README, CLAUDE.md, or other docs
+   - Look for the expected behavior of the functionality being tested
+   - Understand what the correct behavior should be
+
+3. **Compare expected vs actual**
+   - Based on documentation, what should the code do?
+   - What is the test expecting?
+   - What is the code actually doing?
+
+4. **Determine root cause category**
+   - **CODE_BUG**: Code behavior doesn't match documented/expected behavior
+   - **TEST_BUG**: Test expectations don't match documented/expected behavior
+   - **BOTH**: Both code and tests have issues
+   - **UNCLEAR**: Need more 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 3: Root Cause Analysis (Cycle {cycle_number})
+
+**Status:** [CODE_BUG | TEST_BUG | BOTH | UNCLEAR]
+
+### Failure Analysis
+
+#### Test: `{test_name}`
+- **Expected behavior (per docs):** {description}
+- **Test expects:** {description}
+- **Code does:** {description}
+
+### Root Cause
+{detailed_explanation}
+
+### Recommendation
+[If CODE_BUG: Which dev units need fixing]
+[If TEST_BUG: Which test assertions need updating]
+[If BOTH: Both fixes needed]
+
+---
+*Proceeding to Step 4: Fix E2E Tests (if needed)*
+```
+
+% Important
+
+- Be thorough in understanding the documented expected behavior
+- If documentation is unclear, note that and make a reasonable judgment
+- Always post your findings as a GitHub comment before completing

pdd/prompts/agentic_e2e_fix_step4_fix_e2e_tests_LLM.prompt

@@ -0,0 +1,96 @@
+% You are an expert software engineer fixing bugs identified in a GitHub issue. Your task is to fix e2e tests if they are the problem.
+
+% Context
+
+You are working on step 4 of 9 in an agentic e2e fix workflow. Based on root cause analysis, you may need to fix the e2e tests themselves.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Cycle: {cycle_number}/{max_cycles}
+
+% 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. **Check if test fixes are needed**
+   - Review Step 3's root cause analysis
+   - If status was "CODE_BUG" only, skip to Step 5
+   - If status was "TEST_BUG" or "BOTH", proceed with test fixes
+
+2. **Fix the e2e tests**
+   - Identify which test assertions are incorrect
+   - Update the tests to match the documented expected behavior
+   - Ensure tests still exercise the intended functionality
+
+3. **Re-run e2e tests to verify fix**
+   - Execute the modified e2e tests
+   - Confirm the test changes work as expected
+   - If tests still fail due to code bugs, that's expected (will be fixed in later steps)
+
+% 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 no test fixes needed:**
+```markdown
+## Step 4: Fix E2E Tests (Cycle {cycle_number})
+
+**Status:** No Test Fixes Needed
+
+Root cause analysis indicates CODE_BUG only. Skipping to dev unit identification.
+
+---
+*Proceeding to Step 5: Identify Dev Units*
+```
+
+**If test fixes applied:**
+```markdown
+## Step 4: Fix E2E Tests (Cycle {cycle_number})
+
+**Status:** Test Fixes Applied
+
+### Changes Made
+| File | Change |
+|------|--------|
+| `{test_file}` | {description_of_change} |
+
+### Verification
+- Tests run: {N}
+- Tests passing (after test fix): {N}
+- Tests still failing (code bugs): {N}
+
+FILES_MODIFIED: {comma_separated_list_of_test_files}
+
+---
+*Proceeding to Step 5: Identify Dev Units*
+```
+
+% Important
+
+- Only fix tests if Step 3 indicated TEST_BUG or BOTH
+- Test fixes should align tests with documented expected behavior, not make tests pass bad code
+- Always output FILES_MODIFIED line if any test files were changed
+- Always post your findings as a GitHub comment before completing

pdd/prompts/agentic_e2e_fix_step5_identify_devunits_LLM.prompt

@@ -0,0 +1,91 @@
+% You are an expert software engineer fixing bugs identified in a GitHub issue. Your task is to identify which dev units are involved in the failures.
+
+% Context
+
+You are working on step 5 of 9 in an agentic e2e fix workflow. You need to identify which dev units (modules) are responsible for the remaining test failures.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Cycle: {cycle_number}/{max_cycles}
+
+% 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>
+
+<step4_output>
+{step4_output}
+</step4_output>
+
+% Your Task
+
+1. **Analyze the stack traces**
+   - Review error stack traces from Step 2
+   - Identify which source files are involved in the failures
+   - Map source files to their corresponding dev units (modules)
+
+2. **Map files to dev units**
+   - List all prompts in the `prompts/` directory: `ls prompts/*_python.prompt`
+   - For each involved source file, find its corresponding prompt
+   - A dev unit name is derived from the prompt file: `{name}_python.prompt` -> `{name}`
+
+3. **List dev units to fix**
+   - Create a prioritized list of dev units that need fixing
+   - Consider dependencies between dev units
+   - Note which dev units were already fixed in previous cycles
+
+% 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 5: Identify Dev Units (Cycle {cycle_number})
+
+**Status:** {N} Dev Units Identified
+
+### Stack Trace Analysis
+| Source File | Dev Unit | Error Type |
+|-------------|----------|------------|
+| `pdd/{file}.py` | `{dev_unit}` | {error_type} |
+
+### Dev Units to Fix
+1. `{dev_unit_1}` - {reason}
+2. `{dev_unit_2}` - {reason}
+
+### Previously Fixed (This Session)
+- `{dev_unit}` - Cycle {N}
+
+DEV_UNITS_IDENTIFIED: {comma_separated_list}
+
+---
+*Proceeding to Step 6: Create Unit Tests*
+```
+
+% Important
+
+- The DEV_UNITS_IDENTIFIED line is machine-readable and used by subsequent steps
+- Only include dev units that have corresponding prompts (PDD-managed modules)
+- Skip dev units that don't have prompts (external dependencies)
+- Always post your findings as a GitHub comment before completing

pdd/prompts/agentic_e2e_fix_step6_create_unit_tests_LLM.prompt

@@ -0,0 +1,106 @@
+% You are an expert software engineer fixing bugs identified in a GitHub issue. Your task is to create or append unit tests for the involved dev units.
+
+% Context
+
+You are working on step 6 of 9 in an agentic e2e fix workflow. You need to create unit tests that will detect the bugs in the identified dev units.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Cycle: {cycle_number}/{max_cycles}
+
+% 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>
+
+<step4_output>
+{step4_output}
+</step4_output>
+
+<step5_output>
+{step5_output}
+</step5_output>
+
+% Dev Units to Fix
+{dev_units_identified}
+
+% Your Task
+
+1. **For each identified dev unit:**
+   - Read the module's source code: `pdd/{dev_unit}.py`
+   - Read the module's prompt: `prompts/{dev_unit}_python.prompt`
+   - Understand the expected behavior from the prompt
+
+2. **Design unit tests that detect the bug**
+   - Create tests that specifically exercise the buggy code path
+   - Tests should FAIL on current buggy code
+   - Tests should PASS once the bug is fixed
+
+3. **Write or append to test files**
+   - Check if `tests/test_{dev_unit}.py` exists
+   - If exists: append new test functions
+   - If not: create new test file
+
+4. **Follow testing conventions**
+   - Use pytest framework
+   - Include clear docstrings explaining what each test verifies
+   - Use appropriate assertions and mocking
+
+% 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 6: Create Unit Tests (Cycle {cycle_number})
+
+**Status:** {N} Tests Created/Updated
+
+### Tests Created
+
+#### `tests/test_{dev_unit}.py`
+```python
+{test_code}
+```
+
+**What this tests:** {explanation}
+
+### Summary
+| Dev Unit | Test File | Tests Added |
+|----------|-----------|-------------|
+| `{name}` | `tests/test_{name}.py` | {N} |
+
+FILES_CREATED: {comma_separated_new_files}
+FILES_MODIFIED: {comma_separated_modified_files}
+
+---
+*Proceeding to Step 7: Verify Tests Detect Bugs*
+```
+
+% Important
+
+- Tests MUST fail on current buggy code (this is verified in Step 7)
+- Focus on testing the specific bug behavior, not general functionality
+- Always output FILES_CREATED and/or FILES_MODIFIED lines
+- Always post your findings as a GitHub comment before completing