Prompt file imported from rhixecompany/sandbox (
.github/prompts/development/dev/dev.prompt.md). Copyright stays with the author.
Table of Contents
Goal
Drive a development workflow with intake, execution, and verification phases using plans-and-specs artifacts and Hermes tooling.
Context
Phases
Table of Contents
The purpose of the prompt is to get my codebase optimized and refactored.
Phase 1
Task1- list all test in src/backuptests and src/tests then triage- if test already exists, merge intelligently - preserve valuable content while updating outdated sections- Delete src/backuptests and modify playwright.config.mts and vitest.config.mts for this project- modify src/actions/auth.actions.ts to include a custom signOut function- modify src/components/layout/navbar.tsx,src/components/layout/navbar-client.tsx,src/components/layout/nav-user.tsx,src/components/layout/nav-secondary.tsx,src/components/layout/nav-main.tsx,src/components/layout/nav-documents.tsx,src/components/layout/app-sidebar.tsx,src/components/layout/site-header.tsx to handle both authenticated and unauthenticated users with next-auth- list all pages in src/apps and triage- for each page in the list of pages in src/apps modify all of them to use actions in src/actions not dal in src/actions, create a corresponding vitest for all actions and a corresponding playwright test for all pages all test must be basic with valid page navigation and displaying information skip all pages that need authentication in this phase ensure all vitest and playwright test run successfully if a test fails debug by executing the individual failing test# Task2- for each page in the list of pages in src/apps that need authentication create a corresponding playwright test, test must be basic with valid page navigation and displaying information ensure all vitest and playwright test run successfully if a test fails debug by executing the individual failing test
Template References
Templates in templates/:- phase_1.md
Personas
See templates/personas.md for shared persona templates.
| Persona | When to Use |
|---|---|
| Developer | Implementation, debugging, refactoring |
| Reviewer | Code review, quality assurance |
| User | General purpose, operations |
Personality
See templates/personality.md for shared personality guidelines.
- Tone: Direct, practical, actionable
- Style: Structured with clear steps and verification
- Avoid: Ambiguity, assumptions, scope creep
- Encourage: Evidence-based decisions, minimal changes
Use when implementing, modifying, or debugging code. Read the codebase first, understand patterns, then apply changes with tests.
Rules
See core rules: templates/rules-core.md
Domain Rules
- Read existing code before writing new code.
- Match project conventions and style.
- Add tests for new functionality.
Standing Rules
- Map before touch — Understand before making changes.
- Smallest safe change — Minimal change that achieves the goal.
- Verify before claim — Test before reporting complete.
- Report blockers — State when something fails.
Phase 1: Intake
- Read the request and identify scope.
- Locate relevant files, diffs, references.
Phase 2: Execute
- Perform work with smallest safe change set.
- Keep steps explicit and reproducible.
Phase 3: Verify
- Check result against goal, rules, inputs.
- Confirm output is usable and complete.
Phase 4: Hand Off
- Return final artifact or findings .
- Stop once the requested result is delivered.
Best Practices
See templates/best-practices.md for cross-cutting best practices.
- DRY — Reference shared templates instead of duplicating content.
- Structured output — Use clear sections with consistent heading levels.
- Verification gates — Always verify before claiming completion.
- Minimal changes — Fix root cause, not symptoms.
Verification Checklist
| # | Gate | Criterion |
|---|---|---|
| 1 | Scope | Change matches the original request |
| 2 | Quality | Meets project standards |
| 3 | Tests | Tests pass (if applicable) |
| 4 | Regression | No unintended side effects |
| 5 | Docs | Changes documented if needed |
Dependencies
See templates/deps-core.md for shared dependency patterns.
Subgoals
- Prepare — Understand requirements and prerequisites.
- Execute — Follow structured workflow with incremental progress.
- Verify — Confirm output meets requirements and standards.
- Document — Record results, decisions, and lessons learned.
Skills Required
See templates/skills-table-core.md for shared skills table.
| Skill | Purpose |
|---|---|
using-superpowers |
Foundational skill workflow |
systematic-debugging |
Root cause analysis and fix |
git-patch-management |
Patch creation and management |
executing-plans |
Execute plans step by step |
verification-before-completion |
Validate before claiming done |
MCP Servers & Tools
The following MCP servers and tools are available for this task. Use them in preference to native equivalents per MCP-first tooling policy.
| ast-grep | AST-based code search and replace |
| filesystem | File read/write operations |
| sequential-thinking | Structured reasoning for complex problems |
| fetch | Web page content extraction |
| playwright | Browser automation for interactive pages |
| github | GitHub API operations |
Tasks
- Understand requirements and scope
- Plan approach and identify resources
- Execute work incrementally
- Verify against acceptance criteria
- Document results and decisions
Hooks
Shared workspace hooks run around this prompt's execution — see .github/hooks/README.md: session-logger, session-auto-commit, governance-audit, pre-exec-validate.sh, post-exec-state-log.py.
Scripts
Prompt-library tooling (see .enhance/):
.enhance/analyze_prompts.py— prompt-library analyzer (Phase 5/7 gate).enhance/verify_phase3.py,.enhance/fix_class_e.py,.enhance/fix_frontmatter_plan.py— Class C–E repair/verify tooling.github/hooks/*— hook implementations referenced in the Hooks section
Related Prompts
Workflow
Same-family prompts:
# Prompt template
Execute the workflow defined in this file.