prompt-enhancer

Name: prompt-enhancer
Author: comol

388stars86forks

How to install prompt-enhancer?

comol/ai_rules_1c/prompt-enhancer

$npx -y skills add comol/ai_rules_1c --skill prompt-enhancer

Installs into the current project.

Summary

Improve and structure short, unstructured prompts and task statements, turning them into detailed imperative specifications with numbered analysis steps, explicit edge cases, and a clearly described expected output format. Preserves all terms and conditions from the source, does

Files · 1

View on GitHub

SKILL.md

1	# prompt-enhancer — improving prompts and task statements
2
3	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.
4
5	## When to use
6
7	Trigger this skill on user phrases like:
8
9	- "improve the prompt", "make the prompt better / more precise / more detailed"
10	- "refine the task statement", "formalize this task", "polish the task"
11	- "structure the spec", "prepare a spec from a note"
12	- "expand the task description", "turn this into a detailed instruction"
13
14	The skill works with any subject area, but specifically accounts for 1C task specifics (terminology, attribute names, object names, form names).
15
16	## Modes
17
18	\| Mode \| Trigger \| What it does \|
19	\|------\|---------\|--------------\|
20	\| Inline \| argument is arbitrary text \| Improved prompt is printed in chat \|
21	\| File \| argument is a path to an existing file \| Result is saved next to the source with `-enhanced.md` suffix \|
22	\| Interactive \| argument is empty \| Ask the user for the prompt text or a file path \|
23
24	## Mode detection algorithm
25
26	The mode is selected deterministically, without heuristic on the argument text:
27
28	1. If the argument is empty — Interactive mode. Ask the user for the prompt text or a file path with a regular message.
29	2. Otherwise try reading the argument via the Read tool.
30	- If Read returns file content — File mode.
31	- 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.
32	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.
33
34	## Transformation principles
35
36	The core of the skill. Re-check this list on every generation:
37
38	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".
39	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.
40	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.
41	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.
42	5. No new requirements. Do not add requirements that were not in the source: tests, documentation, roles, rollback, logging. Improvement is form, not content.
43	6. Numbering of analysis steps. Split user wishes into discrete verifiable operations 1..N. Each step — one operation.
44	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.
45	8. Neutral business register. Remove conversational and emotional elements ("would be nice", "somehow", "we'd like"), keep neutral phrasing.
46	9. Short essence in the first line. Before the step-by-step plan — one sentence stating the task goal.
47	10. Formatting per repo rules. No long or short dashes (only the regular hyphen), no letter "ё" with dots, no time or ROI estimates.
48
49	## Improved prompt template
50
51	Mandatory result blocks:
52
53	1. Goal — one sentence, what to do.
54	2. Analysis steps — numbered list of imperatives (Analyze, Study, Determine, Output).
55	3. Edge cases — explicit "if ..., then ..." conditions with concrete names and values from the source.
56	4. Output format — name of the format (table / structured list / JSON) and the list of fields the result must contain.
57	5. Additional clarifications (optional) — details, if the source mentioned deadlines, owners, dependencies.
58
59	## Before / after example
60
61	Source prompt (short, unstructured):
62
63	> 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

People who liked this also viewed

6 picks

Type

prompt-enhancer

388stars86forks

View on GitHub

How to install prompt-enhancer?

comol/ai_rules_1c/prompt-enhancer

$npx -y skills add comol/ai_rules_1c --skill prompt-enhancer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# prompt-enhancer — improving prompts and task statements
2
3	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.
4
5	## When to use
6
7	Trigger this skill on user phrases like:
8
9	- "improve the prompt", "make the prompt better / more precise / more detailed"
10	- "refine the task statement", "formalize this task", "polish the task"
11	- "structure the spec", "prepare a spec from a note"
12	- "expand the task description", "turn this into a detailed instruction"
13
14	The skill works with any subject area, but specifically accounts for 1C task specifics (terminology, attribute names, object names, form names).
15
16	## Modes
17
18	\| Mode \| Trigger \| What it does \|
19	\|------\|---------\|--------------\|
20	\| Inline \| argument is arbitrary text \| Improved prompt is printed in chat \|
21	\| File \| argument is a path to an existing file \| Result is saved next to the source with `-enhanced.md` suffix \|
22	\| Interactive \| argument is empty \| Ask the user for the prompt text or a file path \|
23
24	## Mode detection algorithm
25
26	The mode is selected deterministically, without heuristic on the argument text:
27
28	1. If the argument is empty — Interactive mode. Ask the user for the prompt text or a file path with a regular message.
29	2. Otherwise try reading the argument via the Read tool.
30	- If Read returns file content — File mode.
31	- 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.
32	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.
33
34	## Transformation principles
35
36	The core of the skill. Re-check this list on every generation:
37
38	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".
39	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.
40	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.
41	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.
42	5. No new requirements. Do not add requirements that were not in the source: tests, documentation, roles, rollback, logging. Improvement is form, not content.
43	6. Numbering of analysis steps. Split user wishes into discrete verifiable operations 1..N. Each step — one operation.
44	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.
45	8. Neutral business register. Remove conversational and emotional elements ("would be nice", "somehow", "we'd like"), keep neutral phrasing.
46	9. Short essence in the first line. Before the step-by-step plan — one sentence stating the task goal.
47	10. Formatting per repo rules. No long or short dashes (only the regular hyphen), no letter "ё" with dots, no time or ROI estimates.
48
49	## Improved prompt template
50
51	Mandatory result blocks:
52
53	1. Goal — one sentence, what to do.
54	2. Analysis steps — numbered list of imperatives (Analyze, Study, Determine, Output).
55	3. Edge cases — explicit "if ..., then ..." conditions with concrete names and values from the source.
56	4. Output format — name of the format (table / structured list / JSON) and the list of fields the result must contain.
57	5. Additional clarifications (optional) — details, if the source mentioned deadlines, owners, dependencies.
58
59	## Before / after example
60
61	Source prompt (short, unstructured):
62
63	> 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

People who liked this also viewed

6 picks

Type