adhoc prompts for software development(planning and debugging focused)

adhoc-prompts.txt

DEBUGGING:
——————————————————————————————————————— 
STOP. Before making any code changes, conduct a thorough root cause analysis.

Using all available tools (codebase access, terminal, @web), investigate the issue systematically:

1. **Reproduce and observe** the exact error/behavior
2. **Trace the execution path** that leads to this issue
3. **Examine dependencies** and their versions if relevant
4. **Check assumptions** about how the code should work vs. how it actually works
5. **Review recent changes** that might have introduced the issue

List ALL potential root causes, even if uncertain. For each one, include:
- What specifically is broken/misconfigured
- Why this would cause the observed symptoms
- What evidence supports or contradicts this theory

Do NOT propose solutions yet. Focus only on understanding what's actually wrong.

remember to use the internet to look into things whenever helpful @Web 


———————————————————————————————————————

Now systematically validate each potential root cause from your list:

For EACH potential cause:
1. Mark as [CONFIRMED], [RULED OUT], or [UNCERTAIN]
2. Provide specific evidence for your determination
3. If CONFIRMED, note the minimal change needed to fix it

After validation, create a focused fix plan that:
- Addresses ONLY the confirmed root causes
- Uses the simplest, most direct solution
- Preserves all existing functionality
- Requires minimal code changes

Explicitly state what is OUT OF SCOPE for this fix (optimizations, refactoring, new features).

———————————————————————————————————————

Review the conversation context and your proposed solution against these specific criteria:

**MUST CHECK:**
□ Does the fix directly address each confirmed root cause?
□ Are all changes necessary for fixing the issue?
□ Will this preserve existing functionality?
□ Have you avoided introducing new dependencies or complexity?

**RED FLAGS to reconsider:**
□ Adding "while we're at it" improvements
□ Refactoring unrelated code
□ Optimizing performance (unless that IS the issue)
□ Adding new features or capabilities
□ Changing architectural patterns

If the plan passes these checks, confirm it's ready for implementation.
If any red flags are present, revise to focus ONLY on the essential fix.

State clearly: "This fix changes only [X] to solve [specific issue]."

———————————————————————————————————————


NEW FEATURE, FIX or REFACTOR PROMPTS(8 Steps)
———————————————————————————————————————

I need you to create a comprehensive implementation plan for [describe feature/refactor/fix].

Analyze the codebase and provide:

1. **Scope Definition**
   - What exactly will be changed
   - What will NOT be changed (boundaries)
   - Dependencies and impacts on other systems

2. **Detailed Implementation Steps**
   - Break into phases (1.1, 1.2, etc.)
   - Each step should be independently testable
   - Include estimated complexity (simple/medium/complex)

3. **Risk Assessment**
   - What could break?
   - What needs extra attention?
   - Rollback considerations

4. **Open Questions**
   List any clarifications needed with specific context:
   - "Should [X] behavior change when [Y] happens?"
   - "Which approach for [Z]: Option A (pros/cons) or Option B (pros/cons)?"

Do not start implementation. Focus only on understanding the full scope.

———————————————————————————————————————

Create a structured plan document at `./IMPLEMENTATION_PLAN.md` with this format:

# Implementation Plan: [Feature/Fix Name]
## Overview
[One paragraph summary]

## Success Criteria
- [ ] Criterion 1 (how we'll know it works)
- [ ] Criterion 2
- [ ] etc.

## Implementation Phases
### Phase 1.1: [Name]
**Objective:** [What this accomplishes]
**Files to modify:** [List files]
**Validation:** [How to test this step works]
**Commit message:** "[Type]: Description"

### Phase 1.2: [Name]
[Same structure...]

## Risk Mitigation
[Specific risks and how we'll handle them]

## Rollback Plan
[How to undo if needed]

## Progress Tracking
- [ ] Phase 1.1 - Not started
- [ ] Phase 1.2 - Not started
[etc.]

———————————————————————————————————————

Before we start implementing, conduct a thorough review:

**Code Analysis:**
1. For each phase in your plan, examine the ACTUAL code that will be modified
2. Trace through the execution paths that will be affected
3. Identify any hidden dependencies you missed

**Validation Check:**
□ Each phase has clear success criteria
□ No phase breaks existing functionality
□ Dependencies between phases are explicit
□ Each phase can be tested independently

**Final Questions:**
- Are there any edge cases not covered?
- Will any of these changes affect performance?
- Have I missed any files that need updating?

If you identify gaps, update the plan. Otherwise, confirm: "Plan is comprehensive and ready for implementation."

———————————————————————————————————————

Set up version control for this implementation:

1. Ensure all current work is committed: `git status`
2. Push to main: `git push origin main`
3. Create feature branch: `git checkout -b [branch-type]/[descriptive-name]`
   - Use: feature/, fix/, refactor/, or chore/ prefix
   - Example: feature/subscription-management

4. Update IMPLEMENTATION_PLAN.md to include:
   - Branch name: [name]
   - Each phase's planned commit message

Confirm: "Working on branch [name], ready to begin Phase 1.1"

———————————————————————————————————————

Implement Phase [X.X]: [Phase Name]

Refer to IMPLEMENTATION_PLAN.md for:
- Objective
- Files to modify
- Success criteria

Implement ONLY this phase. Do not touch code for future phases.
After implementation, run the validation steps listed in the plan.

———————————————————————————————————————

Phase [X.X] implementation complete. Now:

**Self-Review Checklist:**
□ Does this exactly match the plan's objective?
□ Have I modified ONLY the files listed?
□ Do the validation steps pass?
□ No unintended side effects?
□ No temporary debug code left behind?

**Quick Test:**
[Run the specific test for this phase]

If all checks pass:
1. Stage changes: `git add -A`
2. Commit: `git commit -m "[planned commit message]"`
3. Update IMPLEMENTATION_PLAN.md progress tracker
4. Report: "Phase [X.X] complete and committed. Ready for Phase [X.X+1]"

If any issues found, fix them before committing.

———————————————————————————————————————

We've completed Phase [X]. Conduct a critical integration review:

**Functionality Check:**
1. Test the combined functionality of all completed phases
2. Verify no regressions in existing features
3. Check that phases work together as expected

**Code Quality Check:**
□ No duplicate code introduced
□ Consistent patterns used throughout
□ Error handling is comprehensive
□ No performance degradation

**Documentation Check:**
□ Code comments added where needed
□ IMPLEMENTATION_PLAN.md updated with actual results
□ Any deviations from plan are noted

Run: [specific integration tests]

Issues found: [List any problems]
Status: [GREEN - Continue | YELLOW - Minor fixes needed | RED - Stop and reassess]

If GREEN: "All phases integrated successfully. Proceeding to Phase [X+1]"
If YELLOW/RED: [Specific remediation plan]

———————————————————————————————————————

Implementation complete. Final comprehensive review:

**Acceptance Criteria:**
Review each success criterion from IMPLEMENTATION_PLAN.md:
- [ ] Criterion 1: [PASS/FAIL - evidence]
- [ ] Criterion 2: [PASS/FAIL - evidence]

**Full Test Suite:**
Run all relevant tests and document results:
- Unit tests: [command and result]
- Integration tests: [command and result]
- Manual testing: [what was tested and result]

**Change Summary:**
Generate a summary of all changes:
- git log --oneline [branch-name]
- git diff main...[branch-name] --stat

**Cleanup:**
□ Remove any TODO comments addressed
□ Delete any temporary files
□ Update relevant documentation
□ Plan document reflects reality

Create final commit if needed:
git commit -m "chore: final cleanup and documentation"

Ready for PR: "Implementation complete. Branch [name] ready for review."
———————————————————————————————————————


CLEANUP PROMPTS(3 steps)
———————————————————————————————————————
Time for repository cleanup. Review our entire conversation and the current repository state.

**Step 1: Identify Cleanup Candidates**
List all files that may need attention:

TEMPORARY FILES:
□ Test files created during debugging (test.*, tmp.*, debug.*)
□ Backup files (.bak, .old, .copy)
□ Console output logs or dumps
□ One-off scripts for testing

PLANNING DOCUMENTS:
□ IMPLEMENTATION_PLAN.md (if implementation is complete)
□ TODO.md or NOTES.md files
□ Old design documents
□ Scratch files with pseudo-code

MISPLACED FILES:
□ Files in root that belong in specific directories
□ Test files not in test directories
□ Documentation not in docs folder
□ Config files in wrong locations

DEAD CODE:
□ Commented-out code blocks
□ Unused imports
□ Unreferenced functions/variables
□ Old implementations replaced by new ones
□ Console.log/print statements for debugging

For each item found, note:
- File path
- Why it exists (from our conversation)
- Recommendation: [REMOVE | MOVE to: path | KEEP because: reason]

DO NOT take any action yet. Just create the audit list.

This is a cleanup operation. If you're unsure whether to remove something:
1. Check if it's referenced anywhere: grep -r "filename" .
2. Check git history: git log --oneline -- filename
3. If unused and temporary: remove it
4. If unsure: mark for manual review
———————————————————————————————————————

Review the repository's established patterns and standards:

**Project Structure Analysis:**
1. Examine existing directory structure
2. Identify naming conventions (camelCase, kebab-case, etc.)
3. Note file organization patterns
4. Check for existing style guides or linting rules

**Standards Checklist:**
□ File naming follows existing patterns
□ Directory structure matches project conventions
□ Import statements follow project style
□ Comment style is consistent
□ Configuration files are in standard locations

**Inconsistencies Found:**
[List any files/code that doesn't match repo standards]

**Proposed Standardization:**
[For each inconsistency, how to fix it]

———————————————————————————————————————

Execute the cleanup plan systematically:

**Pre-cleanup Backup:**
git add -A
git commit -m "chore: pre-cleanup checkpoint"

**Cleanup Actions:**

1. REMOVE temporary files:
   For each file to delete:
   - Confirm it's not imported/referenced anywhere
   - Run: git rm [file] or rm [file]
   - Record: "Removed [file] - [reason]"

2. MOVE misplaced files:
   For each file to relocate:
   - Create destination directory if needed
   - Run: git mv [old-path] [new-path]
   - Update any import statements
   - Record: "Moved [file] from X to Y"

3. CLEAN code files:
   For each file with dead code:
   - Remove commented-out blocks
   - Remove unused imports
   - Remove debug statements
   - Keep meaningful comments
   - Record: "Cleaned [file] - removed [what]"

4. STANDARDIZE to match repo conventions:
   For each non-conforming file:
   - Apply naming conventions
   - Fix formatting/style issues
   - Record: "Standardized [file] - [changes]"

**Validation:**
After each category, run tests to ensure nothing broke.

**Final Commit:**
git add -A
git commit -m "chore: post-implementation cleanup
- Removed temporary test files
- Reorganized file structure
- Removed dead code and debug statements
- Standardized to repo conventions"

Report: "Cleanup complete. Removed X files, moved Y files, cleaned Z files."

———————————————————————————————————————

ETC Prompts
———————————————————————————————————————
Improved LLM generated writing:
You are a master stylist, editor, creative director, and auditor.  
Your mission: transform the provided “vibe-coded” text into a **polished, platform-ready piece** while preserving its raw emotional core.  
You must also perform a **self-audit** before finalizing to ensure accuracy, alignment, and usability.  

### MASTER RULESET (Condensed 120 Controls)

#### 1. Core Vibe
- Preserve rhythm, mood, and edge.  
- Keep tone consistent, length controlled, key phrases sharp.  
- Strip clichés and fluff; balance rawness with readability.  
- Use whitespace, breaks, and symbols with intent.  

#### 2. Style & Flow
- Maintain POV/tense; polish metaphors.  
- Vary pacing and sentence length.  
- Build arcs; weave rhythm, internal rhyme if fitting.  
- Offer alternative wordings, openings, closings, and 3–4 stylistic variants (dreamy, gothic, cyber, minimal).  

#### 3. Structure & Formatting
- Provide skeleton outline and section headers.  
- Label lines by function (hook, pivot, climax).  
- Ensure logical progression; prune redundancy.  
- Suggest typographic emphasis (caps, em-dash, dividers).  

#### 4. Emotional Expansion
- Tag emotions per section; modulate intensity.  
- Cross-map imagery, colors, archetypes.  
- Generate moodboard + soundtrack cues.  
- Provide “light” vs “shadow” variants.  

#### 5. Platform Optimization
- Condense for: Twitter/X, IG carousel, TikTok caption, LinkedIn variant.  
- Provide blog-ready SEO and newsletter-ready formatting.  
- Include alt-text and suggested hashtags.  

#### 6. Accessibility & Inclusivity
- Check dyslexia-friendly spacing and screen reader order.  
- Ensure neurodivergent-friendly layout and clear rhythm.  
- Avoid symbol clutter; use global English.  
- Note translation/localization cues.  

#### 7. Technical QA
- Validate Markdown/HTML, escape characters, lint formatting.  
- Regex-check for repetition; provide plaintext fallback.  

#### 8. Quality Control
- Spellcheck, grammar, readability audit.  
- Generate meta-description, keywords, one-line takeaway.  
- Flag contradictions; summarize with final audit loop.  

#### 9. Expanded Dials
- Preview as spoken word, poster, or lyrics.  
- Show platform mockups (IG/Twitter/blog).  
- Highlight emotional load (heavy/light spots).  
- Provide plain-language version alongside polished.  
- Always finalize only if compliant after 2nd-pass audit.  

---

### INPUT
[Paste vibe-coded text here]

### OUTPUT
- Polished main version (full aesthetic)  
- Condensed caption-ready version  
- Alt variants (light, shadow, gothic, dreamy, etc.)  
- Platform previews (IG, blog, Twitter)  
- Accessibility notes  
- Audit confirmation (summary of checks + corrections applied)
———————————————————————————————————————