/prompt-enhancer

name: prompt-enhancer
description: "Turn a short, unstructured prompt or task statement into a detailed imperative spec — numbered analysis steps, edge cases, expected output format — keeping every source term and adding no requirements. Use to improve, refine or structure a prompt or spec; takes text or a .md path."

prompt-enhancer — improving prompts and task statements

Turns a short note or unstructured task into a detailed imperative specification. Suitable for 1C developers who need to formalize a quickly written thought into a clear task statement.

When to use

Trigger this skill on user phrases like:

• "improve the prompt", "make the prompt better / more precise / more detailed"
• "refine the task statement", "formalize this task", "polish the task"
• "structure the spec", "prepare a spec from a note"
• "expand the task description", "turn this into a detailed instruction"

The skill works with any subject area, but specifically accounts for 1C task specifics (terminology, attribute names, object names, form names).

Modes

| Mode | Trigger | What it does | |------|---------|--------------| | Inline | argument is arbitrary text | Improved prompt is printed in chat | | File | argument is a path to an existing file | Result is saved next to the source with `-enhanced.md` suffix | | Interactive | argument is empty | Ask the user for the prompt text or a file path |

Mode detection algorithm

The mode is selected deterministically, without heuristic on the argument text:

1. If the argument is empty — Interactive mode. Ask the user for the prompt text or a file path with a regular message. 2. Otherwise try reading the argument via the Read tool.

• If Read returns file content — File mode.
• If Read returns a "file does not exist / not found" error — that is the normal path, not a failure. Switch to Inline: use the entire argument as the prompt text.

3. Do not detect mode by the presence of `.md` in the text. A phrase like "prepare a spec about .md generation" must not be interpreted as a path. File existence is checked by Read, not by string parsing.

Transformation principles

The core of the skill. Re-check this list on every generation:

1. **Source as the single source of truth.** All terms, attribute names, tab names, object names, form names, subsystem names, numbers, enumerations are carried over verbatim. Do not replace `Айс_КодИсточника77` with "service attribute". 2. **Imperative instead of description.** "needs to be displayed" becomes "Display"; "we should analyze" becomes "Analyze". The result is a plan of actions, not a story. 3. **Explicit edge cases.** Exception conditions are extracted into a separate sentence in the form "if ..., then ...", not hidden inside parentheses. An edge case must stand out. 4. **Fixed expected output.** Add a "For each item, specify" section with a numbered list of fields. State the result format (table, structured list, JSON) explicitly. 5. **No new requirements.** Do not add requirements that were not in the source: tests, documentation, roles, rollback, logging. Improvement is form, not content. 6. **Numbering of analysis steps.** Split user wishes into discrete verifiable operations 1..N. Each step — one operation. 7. **Preserve intent, not literal text.** If the source says "prepare a list" but then lists analytical tasks, analysis comes first, list compilation second. Restore the correct order. 8. **Neutral business register.** Remove conversational and emotional elements ("would be nice", "somehow", "we'd like"), keep neutral phrasing. 9. **Short essence in the first line.** Before the step-by-step plan — one sentence stating the task goal. 10. **Formatting per repo rules.** No long or short dashes (only the regular hyphen), no letter "ё" with dots, no time or ROI estimates.

Improved prompt template

Mandatory result blocks:

1. **Goal** — one sentence, what to do. 2. **Analysis steps** — numbered list of imperatives (Analyze, Study, Determine, Output). 3. **Edge cases** — explicit "if ..., then ..." conditions with concrete names and values from the source. 4. **Output format** — name of the format (table / structured list / JSON) and the list of fields the result must contain. 5. **Additional clarifications** (optional) — details, if the source mentioned deadlines, owners, dependencies.

Before / after example

**Source prompt (short, unstructured):**

> The task — display all non-typical attributes of typical objects on the "Доп. реквизиты Айс" tab. Place the tab last. If only one attribute is added, Айс_КодИсточника77, do nothing. Prepare a list of objects, analyze element forms, determine where and how to add the tab.

**Improved prompt (structured, detailed):**

> Analyze all typical configuration objects and prepare a list of those that contain non-typical attributes. Study the element forms of these objects. Add a new "Доп. реквизиты Айс" tab last in order to each form. Move all non-typical attributes onto the tab, except when the only non-typical attribute is Айс_КодИсточника77 (then no changes are made). For each object, specify: > > 1. Object name. > 2. List of non-typical attributes. > 3. Name of the element form used and current tab structure. > 4. Recommended changes to tab placement and attribute movement, taking interface logic into account. > > Format the output as a convenient table or structured list ready for implementation.

Additional cases — see `examples/`.

DO / DON'T

**DO:**

• Preserve names of objects, attributes, tabs, constants, enumerations verbatim.
• Turn requests into imperatives, add structure and numbering.
• Extract exceptions and edge cases into separate sentences.
• Specify the expected result format explicitly.
• Add a short essence on the first line before the step-by-step plan.

**DON'T:**

• Invent new requirements that were not in the source (roles, tests, rollback, printing, logging).
• Replace concrete terms with generalizations.
• Add technical sol