Find the right prompt.
Copy it in one click.

Determine whether this project would benefit from parallel agents.

Project:

[PROJECT DESCRIPTION]

Create agents only for independent, bounded workstreams.

Possible roles include:

- Researcher
- Architect
- Implementer
- Reviewer
- Tester
- Security auditor
- UX critic

For every agent, define:

- Responsibility
- Inputs
- Scope boundary
- Expected output
- Validation criteria
- Token or iteration limit

The main agent must consolidate the findings, resolve conflicts, and produce one coherent result.

Do not launch multiple agents when the synchronization overhead is likely to exceed the benefit.

Write me a detailed implementation spec before changing any code. Include the objective, requirements, architecture, affected files, dependencies, edge cases, risks, testing strategy, and step-by-step implementation plan.

Before you create or modify anything, interview me about the project.

Ask focused questions that resolve:

- Target users
- Primary user problem
- Required features
- Optional features
- Business rules
- Data requirements
- Authentication
- Permissions
- Integrations
- Visual direction
- Mobile behavior
- Edge cases
- Definition of done

Ask one concise question at a time.

When enough information has been collected:

1. Summarize the agreed requirements.
2. Identify remaining assumptions.
3. Propose the implementation plan.
4. Ask for authorization before execution.

Do not begin building while material ambiguity remains.

Verify your assumptions before building.

Inspect:

- Existing code
- Project documentation
- Dependencies
- Established patterns
- Relevant APIs
- Configuration
- Tests
- Current behavior

Identify:

- Unsupported assumptions
- Conflicting requirements
- Missing context
- Outdated documentation
- Technical constraints
- Security concerns
- Areas where the proposed approach does not fit the existing system

Then present:

1. Verified current state
2. Remaining uncertainty
3. Recommended implementation approach
4. Files likely to change
5. Verification plan

Do not modify files until the investigation is complete.

Create a reusable skill for:

[CAPABILITY OR WORKFLOW]

Inspect the current environment to determine which tools, libraries, commands, and dependencies are available.

The skill must include:

- Purpose
- Trigger conditions
- Required inputs
- Optional inputs
- Environment prerequisites
- Step-by-step instructions
- Exact commands or scripts
- Output format
- Validation checks
- Error handling
- Stop conditions
- Example usage

Test the skill against one realistic example.

Prefer tools already installed in the environment.

Automate this recurring workflow. First document the current manual process, inputs, outputs, dependencies, failure modes, and safety constraints. Then design and implement an automation with logging, validation, idempotency, error handling, and a safe rollback or recovery path.

Here are my goals for this quarter:

[GOALS]

Analyze my calendar and email activity for the past [TIME PERIOD].

Determine whether I am spending enough time on the projects and activities most likely to achieve these goals.

Identify:

- Where my time currently goes
- Activities that support my goals
- Activities that distract from them
- Important goals receiving insufficient attention
- Meetings or commitments that could be reduced, delegated, or eliminated
- Specific calendar changes you recommend

Then propose an improved weekly time-allocation plan.

Search all available meeting transcripts, project notes, interviews, coaching calls, and connected documents.

Find specific examples related to:

[PROBLEM, PAIN POINT, THEME, OR LESSON]

For each example, provide:

- The situation
- The people or teams involved
- The problem or constraint
- What action was taken
- The result
- A useful quote or supporting detail
- How it could be used in a case study, presentation, article, or interview answer

Do not invent details.

Clearly identify the source document or transcript for every example.

Build an interactive spreadsheet for tracking:

[PROCESS]

Include editable columns for:

- Item
- Description
- Owner
- Status
- Priority
- Start date
- Due date
- Next action
- Risks or blockers

Add any additional fields needed to make the tracker useful.

Also include:

- Data validation
- Useful formulas
- Conditional indicators for overdue or blocked work
- A summary dashboard
- Filters for owner, status, and priority
- Realistic sample data

Make the result immediately usable, not merely a description of a spreadsheet.

Create an interactive visual that explains:

[FRAMEWORK, SYSTEM, PROCESS, OR ARCHITECTURE]

Use the connected project files and documents as the source of truth.

The visual should:

- Show the major components
- Explain how they relate
- Allow sections to be expanded for more detail
- Include concrete examples
- Highlight decision points
- Highlight dependencies
- Highlight common failure modes
- Be understandable to both technical and nontechnical audiences

Do not merely summarize the material in prose. Build the visual artifact.

Every weekday morning, review my connected email, calendar, tasks, and relevant team communications.

Prepare a concise operations brief containing:

1. Urgent items requiring action today
2. Messages that need a reply
3. Meetings requiring preparation
4. Deadlines or commitments at risk
5. New developments since the previous brief
6. Items that could be delegated
7. Recommended priorities for the day

For every recommendation, explain why it matters and cite the supporting message, event, or task.

Do not send messages, modify events, or take external action unless explicitly authorized.

Complete the following workflow:

[DESCRIBE THE DESIRED OUTCOME]

Required steps:

1. Retrieve [DATA] from [SOURCE SYSTEM].
2. Validate that the data covers [TIME PERIOD OR SCOPE].
3. Place the results in [DESTINATION].
4. Create a summary chart showing [METRICS].
5. Draft a concise interpretation of the results.
6. Post or send the completed summary to [DESTINATION OR RECIPIENT].
7. Confirm what was completed and report any failures.

Before acting:

- Show me your execution plan
- Identify required permissions
- Flag any destructive or irreversible actions
- Ask for authorization before sending, publishing, deleting, or overwriting anything

Maintain an activity log and do not fabricate missing data.

Turn the workflow we just completed into a reusable skill.

The skill must include:

- A clear purpose
- When it should and should not be used
- Required inputs
- Optional inputs
- Source-of-truth rules
- Step-by-step execution instructions
- Output format
- Quality checks
- Error handling
- Safety and authorization boundaries
- Examples of correct usage
- Examples of requests that should be rejected or escalated

Preserve the decisions and refinements we established during this conversation.

You are the dedicated AI assistant for [PROJECT NAME].

Your responsibility is to help with:

[RESPONSIBILITIES]

Use the files and connected sources in this project as the primary source of truth.

Operating rules:

- Preserve established terminology and conventions
- Distinguish verified facts from assumptions
- Cite or identify the source of important claims
- Ask for clarification only when ambiguity materially affects the result
- Never invent project history, metrics, decisions, or outcomes
- Prefer solutions consistent with the existing architecture
- Identify risks, dependencies, and downstream impacts
- Produce outputs in the following format:

[OUTPUT FORMAT]

Before recommending a major change, inspect the existing project context and explain how the recommendation fits it.

Before starting this task, recommend the best Codex setup.

Task:

[TASK DESCRIPTION]

Determine:

- Whether to use plan mode or direct execution
- Which tools or MCP servers are required
- Which tools should be disabled
- The appropriate reasoning level
- Whether fast or standard mode is more appropriate
- Whether sub-agents would provide meaningful value
- What context I should provide
- What context would be unnecessary or harmful
- Suggested checkpoints
- Success conditions
- Stop conditions
- Verification commands

Do not begin implementation yet. First shape the run so the task can be completed with minimal context pollution and minimal risk.

The previous attempt took the wrong path.

Rewrite the original task into a clean replacement prompt suitable for a fresh thread.

Original objective:

[OBJECTIVE]

What went wrong:

[FAILURE OR MISUNDERSTANDING]

Correct constraints:

[CONSTRAINTS]

Relevant files, functions, or systems:

[EXACT REFERENCES]

Expected result:

[EXPECTED RESULT]

Verification:

[TESTS OR COMMANDS]

Produce one self-contained replacement prompt.

Remove stale assumptions, failed approaches, and irrelevant context. Do not merely append corrections to the old prompt.

Create a concise handoff prompt for continuing this work in a fresh Codex thread.

Include only:

- Current objective
- Current state
- Relevant files and paths
- Decisions already made
- Constraints that must be preserved
- Approaches already attempted
- Known failures and why they failed
- Outstanding questions
- Verification commands
- Exact next task
- Definition of done

Exclude:

- Irrelevant conversation history
- Superseded assumptions
- Raw logs unless essential
- Repeated explanations
- Unrelated project background

The result must be self-contained and ready to paste into a new thread.

Inspect the repository and produce a plan before editing any files.

Objective:

[OBJECTIVE]

Known context:

[FILES, ERRORS, OR REQUIREMENTS]

Your plan must include:

1. Current behavior
2. Root cause or likely implementation area
3. Exact files expected to change
4. The smallest viable change
5. Dependencies and downstream effects
6. Risks
7. Edge cases
8. Tests to add or update
9. Verification commands
10. Rollback approach
11. Decisions that require my input

Do not modify files until the plan is complete.

Avoid broad refactors unless they are necessary to satisfy the objective.

Determine the minimum context required to complete this task accurately.

Task:

[TASK DESCRIPTION]

Available materials:

[FILES, LOGS, DOCUMENTS, LINKS, OR SYSTEMS]

Identify:

- Essential files
- Essential excerpts
- Relevant error messages
- Required schemas or interfaces
- Required commands
- Information that can be omitted
- Information that should be summarized instead of included verbatim
- Missing context that materially blocks progress

Then produce a compact context package I can give to Codex.

Do not recommend dumping the entire repository, full log history, or unrelated documentation.

Run this as a bounded long-running task.

Objective:

[OBJECTIVE]

Success conditions:

- [SUCCESS CONDITION 1]
- [SUCCESS CONDITION 2]
- [SUCCESS CONDITION 3]

Constraints:

- [CONSTRAINTS]

Checkpoints:

- Pause after [NUMBER] significant steps or when a major decision is reached.
- At each checkpoint, summarize progress, changed files, test results, risks, and the next proposed action.

Stop conditions:

- Stop after [MAXIMUM ITERATIONS OR TIME BOUND].
- Stop if the same failure occurs more than [NUMBER] times.
- Stop if required information is missing.
- Stop before any destructive, irreversible, production, or externally visible action.
- Stop if the work expands beyond the stated scope.

Verification:

[COMMANDS OR ACCEPTANCE TESTS]

Do not continue indefinitely or silently broaden the task.

Create or revise `AGENTS.md` as a concise navigation and operating guide for coding agents.

Include:

- Project purpose
- Repository layout
- Core architectural rules
- Important conventions
- Package manager and runtime versions
- Common development commands
- Test, lint, type-check, and build commands
- Required validation before completion
- Files or directories that should not be changed casually
- Security and secret-handling rules
- Links to deeper documentation
- Where to find domain-specific instructions

Keep the file concise and actionable.

Do not turn it into a full project encyclopedia. Move detailed explanations into dedicated documentation and link to them.

Pause the current work and evaluate whether the run has drifted.

Original objective:

[OBJECTIVE]

Current activity:

[WHAT CODEX IS DOING]

Assess:

- Whether the current activity directly supports the objective
- Whether unnecessary files or systems are being explored
- Whether scope has expanded
- Whether repeated failures indicate stale context
- Whether the thread should be restarted
- The smallest useful next action

Then provide:

1. Drift diagnosis
2. Work that should stop
3. Context that should be discarded
4. The next bounded action
5. A clean replacement prompt if a fresh thread is recommended

Execute the required diagnostic commands while minimizing context usage.

Task:

[TASK DESCRIPTION]

For each command:

- Prefer targeted file paths, filters, and search patterns.
- Limit output to the relevant section.
- Exclude repetitive success lines and unrelated warnings.
- Summarize large outputs.
- Preserve exact error messages, stack frames, failing test names, and relevant line numbers.
- Save full logs to a file when needed, but return only the useful excerpt.

After execution, provide:

- Commands run
- Relevant findings
- Exact failures
- Files implicated
- Recommended next step

Do not paste unfiltered logs into the conversation.

Recommend the appropriate reasoning level for this task before execution.

Task:

[TASK DESCRIPTION]

Evaluate:

- Complexity
- Ambiguity
- Number of systems involved
- Cost of an incorrect result
- Reversibility
- Security or compliance impact
- Need for architectural judgment
- Need for multi-step debugging

Choose one:

- Low
- Medium
- High
- Extra high

Explain the choice briefly and identify any part of the task that should use a different level.

Use the lowest level that can complete the work reliably.

Evaluate whether sub-agents should be used for this task.

Task:

[TASK DESCRIPTION]

Identify possible workstreams and assess whether each one is:

- Independent
- Bounded
- Able to use a small, focused context
- Suitable for parallel execution
- Easy to validate
- Unlikely to create synchronization overhead

Recommend:

- No sub-agents
- One review sub-agent
- Multiple parallel sub-agents

For each recommended sub-agent, define:

- Responsibility
- Inputs
- Explicit scope boundary
- Required output
- Validation criteria
- What must remain in the main thread

Do not use sub-agents merely because the task is large.

Turn the following repeated Codex workflow into a reusable skill.

Workflow:

[WORKFLOW DESCRIPTION]

The skill must define:

- Purpose
- Trigger conditions
- When not to use it
- Required inputs
- Optional inputs
- Tools required
- Step-by-step procedure
- Output format
- Validation checks
- Error handling
- Stop conditions
- Safety and authorization boundaries
- Example invocation
- Example successful output

Keep the skill narrowly scoped. Do not embed unrelated project knowledge that belongs in repository documentation.

Investigate and fix the following issue.

Observed behavior:

[OBSERVED BEHAVIOR]

Expected behavior:

[EXPECTED BEHAVIOR]

Exact error:

[ERROR MESSAGE]

Reproduction steps:

[STEPS]

Relevant files:

- [FILE PATH]
- [FILE PATH]

Relevant function, route, component, or job:

[EXACT REFERENCE]

Environment:

[VERSIONS AND PLATFORM]

Constraints:

[CONSTRAINTS]

Required process:

1. Reproduce or verify the failure.
2. Identify the root cause.
3. Propose the smallest safe fix.
4. Modify only relevant files.
5. Add or update tests.
6. Run targeted verification.
7. Report changed files, test results, and remaining risks.

Do not begin with a repository-wide search unless the provided references prove incorrect.

Review this completed Codex run and identify avoidable context and token waste.

Run transcript or summary:

[RUN DETAILS]

Evaluate:

- Unnecessary tool calls
- Excessive file exploration
- Repeated corrections
- Oversized logs
- Stale assumptions
- Unneeded MCP servers or tools
- Tasks that should have used plan mode
- Work that should have moved to a fresh thread
- Opportunities for a reusable skill
- Opportunities for a better `AGENTS.md` rule

Return:

1. What was efficient
2. What wasted context
3. What should change next time
4. A better initial prompt
5. Recommended tool configuration
6. Recommended checkpoints and stop conditions

Evaluate the following task to determine whether it should be handled by an AI agent, a normal AI prompt, traditional automation, or a human-led process.

Task:

[TASK DESCRIPTION]

Assess it using the ARR framework:

1. Autonomous
   - Can the task proceed without continuous human judgment?
   - Which decisions can be safely delegated?
   - Which decisions require approval?

2. Recurring
   - How frequently does the task occur?
   - Is the process sufficiently consistent to reuse?
   - Which parts vary between executions?

3. Reviewable
   - What output will the task produce?
   - How can a human verify that the result is correct?
   - What objective checks or acceptance criteria are available?

Then provide:

- Recommended execution model
- Reasoning
- Required inputs and integrations
- Human approval points
- Validation approach
- Risks and failure modes
- A minimal pilot version
- Conditions that would make agent automation inappropriate

Convert the following repeated task into a narrowly scoped AI-agent workflow:

[TASK DESCRIPTION]

Design the workflow using these roles:

- Analyst: gathers information and identifies relevant patterns
- Planner: chooses the next steps
- Operator: performs permitted actions
- Auditor: validates the result and identifies missing or weak work

For the workflow, define:

1. Trigger
2. Required inputs
3. Source systems
4. Source-of-truth rules
5. Step-by-step actions
6. Decision points
7. Tool permissions
8. Human approval gates
9. Validation checks
10. Error handling
11. Retry behavior
12. Escalation conditions
13. Final output format
14. Activity logging
15. Definition of done

Keep the agent focused on this single workflow. Do not expand its scope into unrelated responsibilities.

Perform a GPS readiness check for this proposed automation:

[WORKFLOW OR IDEA]

Evaluate:

## Goal

- Rewrite the desired outcome as one precise sentence.
- Identify ambiguity, conflicting objectives, or unstated assumptions.
- State what is explicitly outside the workflow's scope.

## Proof

- Define what a successful result looks like.
- List measurable acceptance criteria.
- Explain how the result will be independently verified.
- Identify evidence that should be retained for audit or review.

## Steps

- Break the process into explicit steps.
- Identify any step that currently depends on undocumented judgment.
- Identify missing inputs, rules, permissions, or exception handling.
- Separate reversible actions from destructive or externally visible actions.

Conclude with one of these recommendations:

- Ready for a limited pilot
- Needs additional specification
- Better suited to conventional automation
- Requires continued human ownership

Do not design or execute the automation until the readiness gaps have been identified.

Design an AI agent for the following objective:

[OBJECTIVE]

The agent must operate using an OODA loop:

1. Observe
   - Gather the current state from approved sources.
   - Detect missing, stale, contradictory, or unreliable information.

2. Orient
   - Apply the relevant rules, priorities, constraints, and historical context.
   - Identify what has changed since the previous execution.

3. Decide
   - Compare available actions.
   - Select the safest action most likely to achieve the objective.
   - Explain when human approval is required.

4. Act
   - Perform only authorized actions.
   - Record actions taken and their outcomes.
   - Validate whether the action improved the situation.

Define:

- Normal operating path
- Alternative paths
- Failure detection
- Replanning rules
- Retry limits
- Escalation thresholds
- Stop conditions
- Human override mechanism
- Audit log format

The agent must not continue a failed plan merely because it was the original plan.

Every [DAY AND TIME], review approved customer-support tickets, sales notes, product feedback, and customer-success records from the previous [TIME PERIOD].

Your objective is to identify meaningful recurring customer issues and changes in customer sentiment.

Perform the following steps:

1. Collect records from the approved sources.
2. Remove duplicates and clearly irrelevant entries.
3. Group related issues by theme.
4. Distinguish isolated complaints from recurring patterns.
5. Compare the results with the previous report.
6. Identify:
   - Newly emerging issues
   - Increasing or decreasing issue frequency
   - High-impact customers affected
   - Product areas involved
   - Revenue, retention, or operational risks
7. Cite supporting records for every major conclusion.
8. Draft a one-page leadership brief.
9. Run a validation pass to identify weak evidence, missing context, or unsupported conclusions.

Use this output structure:

- Executive summary
- What changed
- Top recurring issues
- Customers or segments affected
- Business impact
- Recommended follow-up
- Evidence and source references
- Confidence and limitations

Do not send or publish the report until it has passed validation and received any required approval.

Every weekday at [TIME], review email received since the previous run.

Classify each relevant message as:

- Urgent and requires action today
- Requires a reply
- Waiting on someone else
- Meeting or deadline related
- Important but informational
- Low priority

Apply these priority rules:

[PRIORITY RULES]

Pay special attention to:

- Messages from [IMPORTANT PEOPLE OR CUSTOMERS]
- Commitments due within [TIME WINDOW]
- Production, security, financial, legal, or customer-impacting issues
- Threads where I previously promised a response
- Messages that have remained unanswered for more than [TIME]

Produce:

1. A concise morning summary
2. A prioritized action list
3. Draft replies for messages that need a response
4. A list of unclear items requiring my judgment
5. A list of messages safely excluded from the summary

For each item, include the sender, subject, why it matters, recommended action, and supporting evidence.

Do not send replies, modify messages, or change calendar events without explicit authorization.

Analyze the following role, team, or business process:

[ROLE, TEAM, OR PROCESS]

Identify repeated tasks that people dislike, delay, perform inconsistently, or frequently get wrong.

For each candidate task, evaluate:

- Frequency
- Time consumed
- Level of frustration
- Process consistency
- Data availability
- Tool access required
- Consequence of errors
- Ease of human review
- Potential value from automation
- Suitability under the ARR framework

Rank the opportunities and recommend one narrowly scoped agent pilot.

For the recommended pilot, provide:

- Target user
- Painful repeated task
- Current manual workflow
- Proposed agent responsibility
- Explicit non-responsibilities
- Required integrations
- Approval boundaries
- Success metrics
- Validation plan
- Two-week pilot scope

Audit the following AI-agent design before deployment:

[AGENT SPECIFICATION]

Evaluate:

- Goal clarity
- Scope control
- Input quality
- Source-of-truth rules
- Permission model
- Decision logic
- Human approval gates
- Reversibility of actions
- Validation checks
- Hallucination exposure
- Handling of missing information
- Handling of contradictory information
- Retry and loop limits
- Logging and traceability
- Privacy and security risks
- Escalation behavior
- Stop conditions
- Definition of done

Identify ways the agent could perform the wrong action quickly and confidently.

Return:

1. Critical deployment blockers
2. High-risk assumptions
3. Missing safeguards
4. Recommended controls
5. Test scenarios
6. Red-team scenarios
7. Pilot recommendation
8. Go/no-go decision with reasoning

Review the following output produced by an AI agent:

[AGENT OUTPUT]

The original objective was:

[OBJECTIVE]

The acceptance criteria were:

[ACCEPTANCE CRITERIA]

Evaluate the result for:

- Completeness
- Factual support
- Source quality
- Internal consistency
- Compliance with constraints
- Unsupported assumptions
- Missing edge cases
- Incorrect or risky actions
- Whether the evidence actually supports the conclusions

Classify the result as:

- Accept
- Accept with minor corrections
- Requires substantial revision
- Reject and escalate

Explain the decision, list required corrections, and identify which parts should be independently verified by a human.

Review all files attached to this workspace and turn them into a polished, client-ready deliverable.

First:

1. Identify the purpose of each file.
2. Determine which files contain authoritative information.
3. Resolve duplicated or conflicting information.
4. Identify missing details that materially affect the result.

Then create:

- An executive summary
- The primary deliverable
- Supporting analysis
- Key findings
- Risks or limitations
- Recommended next actions
- A source appendix identifying where important claims came from

Use a professional structure and consistent terminology.

Do not invent missing facts. Clearly label assumptions and unresolved questions.

Review the files, conversations, tasks, and connected sources in this workspace.

Determine:

- What the project is trying to accomplish
- What has already been completed
- What is currently in progress
- What is blocked
- Which decisions remain unresolved
- Which tasks are highest priority
- Which activities are low value or duplicative
- What should happen next

Produce:

1. Executive summary
2. Current-state assessment
3. Priority-ranked task list
4. Blockers and dependencies
5. Decisions requiring human input
6. Recommended next seven-day plan

Base every conclusion on available evidence. Distinguish facts from inferences.

Use the attached files and connected data sources to create an executive dashboard.

The dashboard should communicate:

- Current performance
- Progress against goals
- Key trends
- Risks
- Blockers
- Upcoming milestones
- Decisions requiring attention

Select only metrics that materially help someone make a decision.

For every metric:

- Define it
- Identify its source
- Explain why it matters
- Show the relevant comparison or trend
- Flag missing or unreliable data

Include a concise executive narrative explaining what changed, why it matters, and what should happen next.

Review the available research, documents, notes, and data.

Create an interactive web application that helps users explore and understand the material.

Before building:

1. Identify the target audience.
2. Identify the most important user questions.
3. Propose the application structure.
4. Identify the data model.
5. Define the minimum viable feature set.

The application should include:

- Clear navigation
- Search or filtering where useful
- Summary views
- Detailed views
- Source references
- Responsive design
- Empty, loading, and error states

Do not begin implementation until you have produced a concise plan and identified any missing requirements.

Review the attached product materials, brand documents, customer research, and prior marketing content.

Create a complete campaign for:

[CAMPAIGN OBJECTIVE]

Target audience:

[AUDIENCE]

Required outputs:

- Core campaign concept
- Positioning statement
- Key messages
- Audience pain points
- Landing-page copy
- Email sequence
- Social posts
- Ad concepts
- Calls to action
- Measurement plan

Preserve the established brand voice.

Do not introduce product claims that are not supported by the source materials.

Complete the following project autonomously:

[PROJECT DESCRIPTION]

You may:

- Inspect the repository
- Create and edit project files
- Install necessary dependencies
- Run development commands
- Run tests
- Fix implementation errors
- Refine the user experience

You must:

- Preserve existing functionality unless explicitly instructed otherwise.
- Stay within the stated scope.
- Use the existing technology stack where practical.
- Validate each major stage.
- Maintain a concise activity log.
- Stop before destructive, production, billing, publishing, or externally visible actions.
- Stop if requirements conflict or essential information is unavailable.

Definition of done:

[ACCEPTANCE CRITERIA]

At completion, report:

- What was built
- Files changed
- Tests run
- Remaining limitations
- Recommended next steps

Use a two-stage model strategy for this task.

Task:

[TASK DESCRIPTION]

## Stage 1: High-Reasoning Plan

Analyze:

- Requirements
- Architecture
- Data model
- Components
- Dependencies
- Risks
- Edge cases
- Verification strategy
- Smallest viable implementation

Produce an explicit implementation plan.

## Stage 2: Efficient Execution

After the plan is approved:

- Execute straightforward steps with the most efficient suitable model.
- Escalate back to higher reasoning only for ambiguity, architectural decisions, or repeated failures.
- Do not repeatedly reconsider decisions that were already resolved in the approved plan.

Track any deviation from the plan and explain why it was necessary.

Inspect this repository and create a concise orientation report.

Identify:

- Project purpose
- Technology stack
- Runtime and package-manager versions
- Repository structure
- Main entry points
- Important configuration files
- Build process
- Test process
- Deployment process
- External services
- Data stores
- Authentication approach
- Existing agent instructions
- Areas that appear incomplete or risky

Then recommend:

- The first files a developer should read
- The commands needed to run the project
- The most important architectural conventions
- The safest first contribution

Do not modify files.

Implement the following feature:

[FEATURE SPECIFICATION]

Required process:

1. Inspect the relevant existing implementation.
2. Identify established project patterns.
3. Produce a concise change plan.
4. Implement the smallest complete solution.
5. Add or update tests.
6. Run targeted tests.
7. Run linting and type checks.
8. Verify the feature manually where practical.
9. Report changed files and remaining risks.

Constraints:

[CONSTRAINTS]

Acceptance criteria:

[ACCEPTANCE CRITERIA]

Do not introduce a new framework, state-management system, database, or architectural pattern unless the existing project cannot reasonably support the feature.

Diagnose and repair the failing build.

Build output:

[ERROR OUTPUT]

Environment:

[ENVIRONMENT]

Required process:

1. Identify the first actionable failure.
2. Separate root-cause errors from cascading errors.
3. Inspect only the relevant configuration and source files.
4. Confirm package-manager and runtime compatibility.
5. Propose the smallest safe correction.
6. Apply the correction.
7. Rerun the failing command.
8. Run relevant tests.
9. Report the root cause and final verification.

Do not upgrade unrelated dependencies or regenerate lockfiles unless necessary.

Review the current uncommitted changes.

Evaluate:

- Whether the changes satisfy the stated objective
- Unintended scope expansion
- Bugs
- Security issues
- Missing error handling
- Breaking changes
- Test coverage
- Code duplication
- Project-style violations
- Generated files that should not be committed
- Secrets or sensitive data
- Documentation that should be updated

Return:

1. Summary of changes
2. Blocking issues
3. Nonblocking recommendations
4. Required tests
5. Suggested commit scope
6. Suggested commit message

Do not modify the files unless explicitly instructed.

Create an agent-friendly project-state handoff for this repository.

Include:

- Project objective
- Current architecture
- Current branch
- Work completed
- Files changed
- Decisions made
- Constraints
- Known issues
- Failed approaches
- Test results
- Outstanding tasks
- Recommended next task
- Verification commands
- Definition of done

Write the handoff to:

[FILE PATH]

Keep it concise enough for another coding agent to read at the beginning of its next session.

Write a complete product and implementation specification for:

[APPLICATION IDEA]

Include:

## Product

- Problem statement
- Target users
- Primary use cases
- User stories
- MVP scope
- Explicit non-goals
- Success metrics

## Experience

- User journey
- Screen inventory
- Navigation
- Empty states
- Loading states
- Error states
- Mobile behavior
- Accessibility requirements

## Technical Design

- Recommended stack
- Application architecture
- Database schema
- Authentication
- Authorization
- APIs
- External integrations
- File storage
- Background jobs
- Logging and monitoring

## Delivery

- Implementation phases
- Dependencies
- Risks
- Test strategy
- Deployment plan
- Definition of done

Do not begin implementation until the specification is complete.

Build a production-oriented application using:

- Frontend: [FRAMEWORK]
- Backend and database: Supabase
- Authentication: Supabase Auth
- Styling: [STYLING SYSTEM]

Application:

[APPLICATION DESCRIPTION]

Required work:

1. Design the database schema.
2. Create migrations.
3. Configure authentication.
4. Implement row-level security.
5. Create typed data-access functions.
6. Implement the core user journey.
7. Add form validation.
8. Add loading, empty, and error states.
9. Add seed data.
10. Add tests for critical workflows.
11. Document local setup and deployment.

Do not expose service-role keys to the client.

Explain every row-level security policy and verify that users cannot access another user’s private data.

Add Stripe payments to the application.

Business model:

[PAYMENT MODEL]

Required capabilities:

- Products and prices
- Checkout
- Successful-payment handling
- Failed-payment handling
- Cancellation or refund behavior
- Customer portal if applicable
- Webhook verification
- Idempotent webhook processing
- Database synchronization
- Access provisioning
- Access revocation
- Test-mode validation

Security requirements:

- Never expose secret keys to the browser.
- Treat webhook events as the payment source of truth.
- Verify webhook signatures.
- Handle duplicate and out-of-order events.
- Log payment-state transitions.
- Do not grant access solely from a client-side redirect.

Document the complete payment lifecycle and provide test cases.

Build a booking system for:

[SERVICE OR RESOURCE]

Required features:

- Service or resource selection
- Availability
- Time-zone-safe scheduling
- Conflict prevention
- Customer details
- Confirmation
- Cancellation
- Rescheduling
- Admin management
- Optional payment
- Email or notification hooks

Define:

- Database schema
- Availability rules
- Buffer times
- Capacity rules
- Cancellation policy
- Rescheduling policy
- Race-condition prevention
- Time-zone handling
- Booking-status lifecycle

Use server-side validation and transactional safeguards to prevent double booking.

Design and build an MVP marketplace or delivery application.

Concept:

[APPLICATION CONCEPT]

User roles:

[ROLES]

Required capabilities:

- Registration and authentication
- Role-based access
- Listings or inventory
- Search and filtering
- Order or booking flow
- Status lifecycle
- Payments
- Notifications
- Customer dashboard
- Provider dashboard
- Administrative oversight

Before implementation:

1. Define the state machine for orders or bookings.
2. Define permissions for each role.
3. Define the database schema.
4. Identify high-risk workflows.
5. Separate MVP requirements from future enhancements.

Build the smallest end-to-end vertical slice first.

Turn the workflow we just completed into a reusable skill.

The skill must include:

- A clear purpose
- When it should be used
- When it should not be used
- Required inputs
- Optional inputs
- Source-of-truth rules
- Tools required
- Step-by-step execution instructions
- Output format
- Quality checks
- Error handling
- Stop conditions
- Safety and authorization boundaries
- Examples of correct usage
- Examples that should be rejected or escalated

Preserve the decisions and refinements established in this conversation.

Remove details that apply only to this one execution.

Review the following prompt as an adversarial prompt engineer:

[PROMPT]

Identify:

- Ambiguous instructions
- Missing inputs
- Conflicting requirements
- Unbounded scope
- Weak acceptance criteria
- Opportunities for hallucination
- Unsafe authorization assumptions
- Missing stop conditions
- Missing validation
- Instructions that waste context
- Situations where the prompt is likely to fail

Then produce:

1. A critique
2. A corrected prompt
3. A shorter version
4. A high-reliability version
5. A list of variables the user must fill in

Convert this vague request into an executable specification:

[REQUEST]

Your output must define:

- Objective
- User or stakeholder
- Current problem
- Desired outcome
- Inputs
- Outputs
- Requirements
- Constraints
- Non-goals
- Assumptions
- Dependencies
- Edge cases
- Acceptance criteria
- Validation method
- Stop conditions

Do not execute the task.

Make uncertainty visible instead of silently making consequential assumptions.

Create a master prompt for this project:

[PROJECT DESCRIPTION]

The prompt should establish:

- Role
- Objective
- Audience
- Source-of-truth hierarchy
- Working process
- Required output structure
- Quality standards
- Terminology
- Constraints
- Authorization boundaries
- Validation rules
- Error handling
- Stop conditions
- Definition of done

The prompt must remain useful across multiple sessions without embedding temporary task details.

Put temporary objectives and current-state information in a separate handoff section.

Create a professional prompt pack for:

[ROLE OR FUNCTION]

The pack should cover the role’s most important recurring workflows.

For each prompt include:

- Prompt title
- Intended use
- Required inputs
- Copy-ready prompt
- Expected output
- Verification checklist
- Common failure modes

Prioritize workflows that are:

- Repeated frequently
- Time consuming
- Easy to review
- Valuable when standardized
- Safe to delegate with defined controls

Avoid generic prompts that merely say “act as an expert.”

Review the completed work against the original objective.

Objective:

[OBJECTIVE]

Acceptance criteria:

[CRITERIA]

Evaluate:

- Completeness
- Correctness
- Factual support
- Internal consistency
- Constraint compliance
- Edge cases
- Error handling
- Security
- Accessibility
- Performance
- Tests
- Documentation
- Unintended changes

Classify the result as:

- Accept
- Accept with minor corrections
- Requires substantial revision
- Reject and escalate

Explain the decision and list every required correction.

Red-team the following implementation or plan:

[IMPLEMENTATION]

Attempt to identify:

- Ways it can fail
- Incorrect assumptions
- Security vulnerabilities
- Authorization bypasses
- Data-integrity risks
- Race conditions
- Privacy exposure
- Abuse cases
- Reliability problems
- Scaling problems
- Observability gaps
- Recovery failures
- Situations where users could be harmed or misled

Rank findings by severity and likelihood.

For every significant finding, propose a concrete mitigation and verification test.

Before executing this task, define what proof of success will look like.

Task:

[TASK]

Provide:

- Desired outcome
- Observable success criteria
- Required evidence
- Tests or validation commands
- Independent verification method
- Acceptable tolerances
- Failure conditions
- Rollback trigger
- Human approval requirement

Do not begin execution until the proof standard is explicit.

Act as a rigorous thinking partner.

My current position:

[POSITION]

Context:

[CONTEXT]

Evidence:

[EVIDENCE]

Assumptions:

[ASSUMPTIONS]

Do not immediately agree with me.

1. Restate my position fairly.
2. Identify the strongest reasoning.
3. Identify unsupported assumptions.
4. Present the strongest counterargument.
5. Offer at least two alternative interpretations.
6. Identify evidence that would change the conclusion.
7. Separate what is known, inferred, and unknown.
8. Recommend the next action that would reduce uncertainty most efficiently.

Audit this decision:

[DECISION]

Desired outcome:

[OUTCOME]

Options:

[OPTIONS]

Constraints:

[CONSTRAINTS]

Evaluate:

- Problem framing
- Missing options
- Reversibility
- Opportunity cost
- Base rates
- Incentives
- Second-order effects
- Cognitive biases
- Missing information

Return:

1. Best current option
2. Reasoning
3. Strongest objection
4. Risk-reduction steps
5. Conditions under which another option becomes better
6. Confidence level

Imagine it is [DATE] and this initiative has failed badly.

Initiative:

[INITIATIVE]

Work backward and identify plausible causes across strategy, execution, people, incentives, technology, customers, timing, budget, dependencies, governance, and external events.

Rank failure modes by likelihood and impact.

For each major failure mode, recommend:

- Early warning indicator
- Preventive control
- Contingency response
- Owner

Help me determine whether I am solving the correct problem.

Stated problem:

[PROBLEM]

Symptoms:

[SYMPTOMS]

Stakeholders:

[STAKEHOLDERS]

Attempted solutions:

[ATTEMPTS]

Analyze who experiences the pain, what behavior produces it, which incentives sustain it, what evidence distinguishes cause from correlation, and what happens if nothing changes.

Return:

1. Revised problem statement
2. Likely root causes
3. Unknowns
4. Tests to distinguish causes
5. Smallest high-value intervention

Create a practical learning roadmap for:

[TOPIC]

Current level:

[LEVEL]

Goal:

[GOAL]

Available time:

[TIME]

Deadline:

[DEADLINE]

Build around demonstrated capability rather than content consumption.

Include:

- Prerequisites
- Essential concepts
- Study sequence
- Practice exercises
- One real project
- Milestones
- Retrieval quizzes
- Common misconceptions
- Proof of mastery

Prioritize the smallest set of activities that produces practical competence.

Teach me:

[TOPIC]

Use a Socratic method.

- Ask one question at a time.
- Assess what I already understand.
- Use hints before full explanations.
- Ask me to reason aloud.
- Detect misconceptions.
- Adapt difficulty.
- Periodically ask me to summarize from memory.
- Include practical application.
- End with a mastery assessment.

Concept:

[CONCEPT]

My explanation:

[EXPLANATION]

Evaluate it for accuracy, missing steps, circular reasoning, hidden jargon, false analogies, unexplained assumptions, and practical applicability.

Do not immediately rewrite it. Identify where my understanding is weak and ask targeted questions that help me repair it.

Create an active-recall quiz for:

[TOPIC]

Difficulty:

[LEVEL]

Include foundational recall, conceptual explanation, comparison, application, error diagnosis, and transfer to unfamiliar situations.

Ask one question at a time. After each answer, grade it, explain gaps, ask follow-ups, and track weak concepts.

End with a mastery map and spaced-review plan.

Design one practical project that will teach me:

[SKILL]

Current level:

[LEVEL]

The project must produce a useful outcome, require the essential concepts, be completable within [TIME], include checkpoints and acceptance criteria, expose common mistakes, and end with a retrospective.

Provide:

1. Project brief
2. Required knowledge
3. Milestones
4. Constraints
5. Tools
6. Test plan
7. Definition of done
8. Stretch goals

Synthesize the attached sources to answer:

[QUESTION]

Source hierarchy:

[HIERARCHY]

1. Identify each source's purpose and date.
2. Extract relevant claims.
3. Detect duplication.
4. Identify contradictions.
5. Prefer current authoritative evidence.
6. Separate facts from interpretation.
7. Identify missing information.
8. Produce one coherent answer.

Output:

- Executive answer
- Supporting evidence
- Conflicts and resolution
- Uncertainty
- Recommended next action
- Source references