Enhance

Enhance

Turn the user's current request into a precise software-engineering prompt without changing its intent or committing to an unsupported solution.

Determine handoff and permissions

Interpret the user's natural-language instruction; do not expect command-specific argument interpolation.

• Enhance and execute: Default. Build the enhanced prompt, present it, and immediately continue with the downstream task without waiting for confirmation.
• Enhance only: Use only when the user explicitly asks to return, rewrite, or copy the prompt without executing the downstream task, including wording such as "only enhance," "do not execute," or "prompt only."
• Permission boundary: Preserve the original request's authority independently of the handoff mode. Requests to analyze, compare, recommend, plan, avoid modification, or remain read-only still execute the downstream analysis but must not modify project files or external state.

Treat legacy -x wording as an explicit enhance-and-execute request when it appears, but do not require or advertise the flag because execution is already the default.

Workflow

1. Restate the intended outcome in one sentence.
2. Identify the task shape and risk: debugging, feature work, refactoring, tests, documentation, review, exploration, architecture, migration, infrastructure, or another clear category.
3. Decide whether repository context would materially improve the prompt. Skip repository discovery for generic writing, conceptual, or greenfield requests that do not depend on an existing codebase.
4. Gather only enough evidence to identify the relevant scope, existing pattern, constraints, and verification path.
5. Build the enhanced prompt using confirmed facts, explicit inferences, and unresolved questions.
6. Present the enhanced prompt, then immediately execute the downstream task within the user's stated permissions. Stop after presenting the prompt only in enhance-only mode.

Select context capabilities

Choose tools by capability instead of requiring a named provider.

1. For an unknown implementation location or behavior described in natural language, use any semantic repository search capability currently available.
2. For definitions, references, implementations, or symbol relationships, use any available symbol-navigation or code-intelligence capability.
3. For exact names, paths, errors, configuration keys, or strings, use fast text and file search such as rg, rg --files, or git grep.
4. Open the actual files and relevant line ranges before treating search results as evidence.

Exclude dependency, environment, generated, cache, and build directories such as .git, node_modules, venv, .venv, dist, build, coverage, and runtime storage unless the task specifically targets them.

Treat configuration, environment, CI, deployment, and compose files as potentially credential-bearing. Do not use context flags such as -A, -B, or -C, or broad range reads, on those files. Locate exact keys first, then use a structured parser or isolated single-line reads that cannot include neighboring environment values. Never copy secret values into the enhanced prompt or response; redact any credential-like value and cite only the setting name and location when it is relevant.

Augment, Semble, Serena, LSP-backed tools, and similar providers are optional examples, not dependencies. Never fail merely because a particular provider is absent. When richer retrieval is unavailable or insufficient, fall back to repository search and direct file reads. If no repository context is available, enhance from the supplied request and label missing context explicitly.

Do not repeat the same search through multiple providers unless the first result is ambiguous or incomplete.

Keep context bounded

• Simple task: Inspect at most 1–3 relevant files or equivalent focused excerpts.
• Medium task: Inspect at most 3–7 relevant files, including the nearest implementation and tests.
• Complex task: First map the affected modules and critical path, then expand only where a decision or acceptance criterion requires evidence.

Stop collecting context once the prompt has enough evidence to state the goal, scope, constraints, deliverables, and verification. Prefer relevant evidence over exhaustive repository summaries.

Read project instructions

Apply the closest scoped project instructions first. Check relevant files such as:

• AGENTS.md
• CLAUDE.md or GEMINI.md
• dependency and build configuration
• test configuration
• task-relevant README or CONTRIBUTING guidance

Do not load every documentation file by default. Preserve higher-priority user and system instructions.

Build the enhanced prompt

Use the smallest structure that makes the request directly executable.

Simple tasks

## Enhanced Prompt

### Outcome
[One precise sentence]

### Scope and evidence
- `[path or component]` — [confirmed relevance]

### Acceptance criteria
- [Observable completion condition]

### Assumptions or open decisions
- [Only behavior-changing choices not established by the request; omit when none]

Medium and complex tasks

## Enhanced Prompt

### Outcome
[Desired behavior and user-visible result]

### Confirmed context
- `[path:line or component]` — [fact established from the project]

### Scope
- In: [included modules, behaviors, and deliverables]
- Out: [explicit exclusions when known]

### Constraints
- [Project conventions, compatibility requirements, and permission boundaries]

### Deliverables
- [Code, tests, documents, or analysis expected]

### Acceptance criteria
- [Observable, testable condition]

### Open questions
- [Only unresolved decisions that could materially change the result]

### Execution mode
- Enhance and execute | Enhance only

### Permission boundary
- Read-only | Modifications allowed by the original request

Add architecture impact, rollback, migration, security, or risk sections only when the task actually requires them. Do not add a generic expert role, invent file names, prescribe an architecture without evidence, or pad a simple task into a large specification.

For greenfield or underspecified prompts, do not silently turn plausible choices into requirements. Mark decisions about dependencies, frameworks, data formats, compatibility, localization, error behavior, or testing tools as assumptions or open questions unless the user or project has already established them.

Accuracy and handoff rules

• Preserve the user's original intent, terminology, non-goals, and permission boundaries.
• Distinguish confirmed facts, inferences, and unknowns. Never present a search guess as repository fact.
• Include paths and line numbers when they make the prompt more actionable; do not manufacture precision.
• If retrieval exposes a credential, token, private key, or sensitive endpoint, do not repeat it. Record only that a sensitive value exists and where it must be reviewed.
• Do not ask the user for repository facts that can be discovered safely.
• Group related uncertainties and keep open questions to the 3–5 highest-leverage decisions that could materially change the result.
• Do not force another Skill to run or assume it is installed. Describe any needed capability or recommend an optional workflow; let the runtime select available Skills.
• In enhance-only mode, end after presenting the enhanced prompt.
• Otherwise, present the enhanced prompt first, then immediately execute it under the downstream workflow's tests, risk gates, verification requirements, and original permission boundary.
• A read-only permission boundary constrains downstream actions but does not prevent executing analysis, comparison, recommendation, planning, review, or exploration.