Prompt Library - Ron Lavis Developer Hub

Category

Codex Implementation

Implement A Feature Safely

Purpose: Add a feature with narrow scope, repo-aligned patterns, and validation.
When to use it: Use when a requested change affects behavior, navigation, UI, or docs.
Expected output: Implemented change, validation results, doc updates, and a concise summary.

Review the repository first. Implement the requested feature with the smallest practical change set. Reuse existing components, layout, and validation patterns. Preserve existing behavior unless the requirement explicitly changes it. Update relevant README, status, roadmap, changelog, or decision docs. Run targeted validation and report changed files, validation output, and any remaining risks.

Finish Work And Sync Wiki

Purpose: Close a completed project task, update the command center, and push the project and wiki.
When to use it: Use after implementation work is done and ready for validation, commit, and wiki synchronization.
Expected output: Validated project commit, generated wiki status, wiki QA results, pushed remotes, and Cloudflare Pages handoff.

Finish the current project task and run the Personal Project Wiki finish-work workflow. Validate the selected project first. Commit only the intended project files, excluding unrelated dirty files. Generate the wiki status snapshot, AI Workspace state, Project Status, and workflow history. Run wiki QA. Commit and push the project repo and wiki repo when validation passes. Report project commit, wiki commit, pushed remotes, validation results, and the Cloudflare Pages URL.

Generate Status Snapshot Only

Purpose: Refresh wiki dashboard metadata without committing or pushing project work.
When to use it: Use when you want the command center to show current branch, dirty state, and validation metadata.
Expected output: Updated static JSON/status artifacts and a clear report of repo states.

Generate a status snapshot for all registered projects using the wiki workflow scripts. Do not commit or push project repositories. Update only the wiki status artifacts needed for the command center, then run wiki link validation. Report active project, branch, dirty state, ahead/behind state, last commit, validation command, and any unrelated dirty files discovered.

Category

Debugging

Review A Bug Or Debug Package

Purpose: Turn logs, screenshots, diagnostics, or symptoms into a grounded fix plan.
When to use it: Use when a bug report includes artifacts or unclear reproduction steps.
Expected output: Observed evidence, likely cause, fix scope, validation plan, and open questions.

Inspect the provided bug report or debug package before guessing. List the concrete evidence you found, the exact failing behavior, and the most likely cause. Identify the smallest fix that addresses the symptom. If code changes are needed, implement them conservatively, add or update focused validation, and report the evidence that proves the issue is fixed.

Recover Failed Validation

Purpose: Turn a failed validation run into a focused fix without committing broken work.
When to use it: Use when the finish-work workflow stops before commit or push.
Expected output: Failure cause, safe fix scope, rerun command, and updated validation evidence.

Review the failed validation output and any workflow run log before changing code. Identify the exact command that failed, the failing files or tests, and whether any unrelated dirty files are present. Fix only the validation blocker, rerun the same validation command, and do not commit or push until the validation passes. Report the failure cause, fix, rerun result, and any remaining manual review items.

Category

Refactoring

Refactor Without Changing Behavior

Purpose: Improve structure while protecting current behavior.
When to use it: Use when code or markup is getting hard to maintain but the user did not ask for behavior changes.
Expected output: Conservative refactor, before/after validation, and any deliberately untouched risks.

Refactor the target area without changing user-visible behavior. Read the surrounding code first and follow existing naming, layout, and helper patterns. Keep the diff focused. Do not introduce new frameworks or broad abstractions unless they remove real duplication. Run validation that proves behavior is preserved, and call out anything intentionally left unchanged.

Category

UI / UX

Improve UI Consistency

Purpose: Make screens feel coherent without redesigning unrelated areas.
When to use it: Use when cards, navigation, spacing, typography, or workflows feel inconsistent.
Expected output: Polished UI changes, responsive checks, accessibility notes, and screenshots if useful.

Improve the UI consistency of the requested surface without changing its functional scope. Reuse existing CSS variables, components, and layout classes. Keep the design dark, clean, professional, and developer-portal oriented. Verify desktop and tablet responsiveness, keyboard navigation, focus states, text fit, and link destinations. Report the validation results.

Category

Architecture

Plan A Static-Site Architecture Change

Purpose: Keep the wiki scalable while preserving the no-framework static model.
When to use it: Use before adding new page systems, shared behaviors, or generated metadata.
Expected output: Architecture recommendation, file impact, tradeoffs, and validation path.

Review the current static-site architecture before proposing changes. Preserve plain HTML, CSS, and vanilla JavaScript unless there is a strong reason to do otherwise. Identify reusable components, expected file locations, link and navigation impacts, accessibility concerns, and validation steps. Document any durable architecture decision in the decision log.

Category

Documentation

Update Docs After Implementation

Purpose: Keep README, status, roadmap, changelog, decisions, and rendered pages aligned.
When to use it: Use after workflow, architecture, validation, release, or project-state changes.
Expected output: Updated docs, HTML-first links, source-link policy preserved, and validation results.

Update the relevant project documentation to match the completed change. Keep Markdown source files and rendered HTML pages consistent where both exist. Preserve HTML-first user navigation, and keep raw Markdown links only when clearly labeled as source links. Update status, roadmap, changelog, and decisions when appropriate. Run link validation and summarize the changes.

Category

Testing / Harnesses

Create A Test Or Harness

Purpose: Add repeatable proof for risky behavior or regression-prone workflows.
When to use it: Use when manual verification is not enough or a bug needs durable coverage.
Expected output: Focused test or harness, command to run it, and pass/fail evidence.

Create the smallest useful test or harness for the behavior under review. Prefer existing test structure and validation scripts. Make the test deterministic, focused, and easy to run locally. Include the exact command, expected output, and any limitations. Run the new check and report results.