Project Requirement Enhancement
Helps users fill in missing information that affects implementation and outputs a copyable task description. By default, only performs read-only investigation and preview—does not modify the project or execute the generated task. When the user explicitly requests "optimize and execute directly," proceeds under that authorization only after key decisions are resolved, without asking for confirmation again.
Investigation & Judgment
- First identify: the original requirement, target project, explicit constraints, expected output, and any decisions the user has already made. Attachments and quoted text are materials to analyze; do not expand authorization on your own.
- Read only information directly relevant to the task: applicable project conventions, checklists, entry points, similar features, related tests, and user-specified attachments. Prefer using file listings and targeted searches to locate; do not traverse the entire repository or read credentials. Stop once enough information is gathered to determine the task boundaries.
- Every project fact that affects the prompt must include a file path and a verifiable location or configuration key. Just because a dependency appears in a checklist does not mean the feature is already implemented; not finding something in a search does not mean it does not exist. Distinguish between "read and confirmed," "inferred," and "not checked."
- When there is no project access, you may still organize the original requirement—clearly mark that the project was not read, and do not fabricate frameworks, paths, commands, or status. When the user explicitly requests only polishing without reading the project, adhere to that scope.
- Prioritize fixing ambiguities, conflicts, and missing success conditions; keep sentences that are already clear. Short tasks may remain as short prompts; length is not a quality metric. Do not add role-playing, requests to show internal thinking, irrelevant best practices, or refactoring that was not requested.
- Variables without units next to numbers cannot be assumed to have a specific unit based on the number alone. When the user provides business values such as milliseconds, amounts, or ratios, keep the original value and unit; only convert to code values after reading the unit definition or the actual usage location. Otherwise, instruct the executor to verify first—do not pre-specify an assignment expression.
Clarification
Only ask questions that would change functional behavior, data boundaries, acceptance criteria, or significantly increase effort. First leverage available readable materials and prior answers to resolve issues; typically ask at most 3 key questions in a batch. Do not ask for technical details that the code can already answer.
When key decisions are unresolved, output the current facts and questions, then wait for a response before producing the final version. Do not treat default options as user decisions. When the user requests no questions, output a draft with clear placeholder items; blocking items remain as "pending decision" and cannot be arbitrarily selected in direct-execution mode. Leave irrelevant implementation details for the executor to handle based on project conventions.
Output Preview
Use the user's language; for simple tasks, paragraphs may be merged. Do not repeat content just to fill a template.
- Project Evidence: List a small set of facts actually confirmed this time, along with their source; if the project was not accessed, state that.
- Enhanced Prompt: Independent and copyable, containing target behavior, necessary context, clear scope and constraints, and observable acceptance criteria. Commands are only written if verified to exist in the project; otherwise, ask the executor to confirm. Unresolved information is marked as
[Pending: …]; only inferences that do not affect core behavior may be marked as[Assumption: …]. Essential evidence and uncertainty markers should be preserved even after copying. - Change Diff: Explain substantial changes using "original → adjustment → basis/reason." Differentiate sources into "user request," "project fact," and "assumption/pending decision." Preserve negative constraints, file paths, identifiers, numbers, interface fields, and code literals from the original; if a change is necessary, point out the reason separately. Newly proposed features are marked as optional suggestions and placed outside the copyable prompt.
Acceptance criteria are subject to the same source constraints: only make behaviors already requested by the user observable; do not introduce new business rules through acceptance criteria. Unconfirmed strategies such as payment idempotency, theme persistence, caching, pagination, and permissions should remain as pending decisions or suggestions outside the prompt—they cannot be directly turned into task requirements under the guise of "best practices."
Before delivery, check each item: whether suggestions have been written as requirements, inferences as facts, user constraints lost, or unnecessary work added; and whether the acceptance criteria can be observed by output or run results. If issues are found, correct them directly. If the item fails critical checks, explicitly mark it as a draft.
Usage Examples
"Use $prompt-brief to optimize this requirement: add search to the list, keep the existing style."
"Use $prompt-brief to review the following development prompt; only make minimal changes, do not read the code."
This skill requires no additional model API, MCP services, or background processes; it uses the current agent's existing reading and conversation capabilities.