---

name: prompt-refiner description: Improve prompts before sending them to get better results. Use when you want to refine a task description.

Prompt Refiner

When to Use

Invoke this skill when you have a task that:

• Involves multiple steps or files
• Requires specific output formatting
• Needs careful reasoning or analysis
• Would benefit from structured context

Refinement Process

1. Analyze the Draft Prompt

Review the user's prompt for:

• Clear outcome definition
• Sufficient context
• Explicit constraints
• Success criteria

2. Apply Claude-Specific Patterns

Structure with XML tags:

• <context> - Background information, codebase state
• <task> - The specific action to take
• <requirements> - Must-have criteria
• <constraints> - Limitations and boundaries
• <examples> - Sample inputs/outputs if helpful

Ordering matters:

1. Context first (what exists)
2. Task second (what to do)
3. Requirements third (how to do it)
4. Examples last (clarifying edge cases)

3. FlexTime-Specific Context

Always include relevant FlexTime context:

• Schedule-first architecture (use schedule_id)
• Orchestration stages (intake → phase1 → phase2 → review → publish)
• Brand names: HELiiX and FlexTime
• Quality scores use 0-100 scale

4. Enhance for Reasoning

For complex tasks, add:

• "Think through the approach before implementing"
• "Consider these edge cases: ..."
• "Explain your reasoning for key decisions"

5. Output the Refined Prompt

Present the improved prompt with:

• Clear section headers
• XML tags where beneficial
• Specific, measurable criteria

Example Transformation

Before: "Add caching to the schedule API"

After:

Copy<context>
The /api/schedules/:scheduleId endpoint currently queries Supabase on every request.
Average response time is 200ms. We use schedule_id as the canonical identifier.
</context>

<task>
Add caching to reduce database load for frequently accessed schedules.
</task>

<requirements>
- Cache TTL of 5 minutes for active schedules
- Immediate invalidation when schedule is modified
- Graceful fallback to database if cache unavailable
- Add cache hit/miss logging with schedule_id context
</requirements>

<constraints>
- Don't change the response format
- Must pass existing integration tests
- Follow FlexTime logging conventions
</constraints>