| name | @2219/reword |
| version | 1.3.2 |
| description | Rewrites a user's raw prompt into a clearer, higher-performing prompt they can reuse directly. Trigger when the user starts their message with /reword, asks to improve a prompt, asks to rewrite a prompt, or wants prompt engineering help. When triggered by /reword, do not execute the task itself. Return only the improved prompt in a copy-ready format. |
| author | starchild |
| tags | ["prompt-engineering","rewriter","optimizer","efficiency"] |
| metadata | {"starchild":{"emoji":"✍️","skillKey":"reword","displayName":"Reword"}} |
| user-invocable | true |
Reword
This skill is a prompt-rewriting layer for Starchild.
Its purpose is to take a rough user prompt, improve it using strong prompt
engineering, and show the improved version back to the user so they can reuse it.
When the user starts a message with /reword, treat everything after /reword
as the source prompt to improve.
Example:
/reword write me a landing page for an AI finance app
In that case, you rewrite the prompt and return the improved version only.
You do not complete the landing page task itself unless the user separately asks
for execution.
Empty input handling
If the user sends /reword with no text following it — or only whitespace — ask
exactly one question:
"What prompt would you like me to improve?"
Do not attempt to rewrite, guess, or invent a prompt.
Primary behavior
When invoked, follow this sequence:
- Read the text after
/reword as the raw prompt.
- Infer the user's likely goal, output format, audience, tone, and any missing
constraints.
- Upgrade the prompt so it is clearer, more specific, and more likely to
produce a strong result in one turn.
- Keep the rewritten prompt practical and concise. Improve quality without
turning it into an overlong wall of text.
- Return the rewritten prompt in a copy-ready block.
- Do not answer the rewritten prompt.
- Do not explain your full reasoning unless the user asks.
Rewriting principles
Apply these improvements where useful:
- Clarify the real task
- Specify desired output format
- Add audience and tone when implied
- Add missing constraints that materially improve output
- Add quality bars such as clarity, accuracy, depth, edge cases, or production readiness
- Remove vagueness, filler, and ambiguity
- Prefer direct language over bloated wording
- Default to reasonable assumptions over asking follow-up questions. Only ask a
single clarifying question if the prompt is genuinely unsalvageable without
more info (see "When to ask one question" below). Assumptions always win over
questions when a sensible default exists.
Prompt length guidance
Aim for roughly 2–5× the length of the raw input. Cap at around 150 words
unless the task's complexity genuinely demands more. A good rewrite is denser
and more precise, not just longer. If the original prompt is already detailed,
tighten it rather than expanding.
Compound and multi-step prompts
If the raw prompt contains multiple distinct tasks bundled together (e.g.
"build a page and write the copy and deploy it"), decide:
- If the tasks are tightly coupled and best done in one turn, rewrite as a
single structured prompt with clearly numbered steps.
- If the tasks are loosely related or would produce better results separately,
rewrite as the single most important prompt and add a short note suggesting
the user split the remaining tasks into follow-ups.
Do not silently drop parts of the original request.
Skill and tool routing
When the rewritten prompt would benefit from a specific skill, tool, or
approach, bake that guidance directly into the prompt text. The goal is to make
the prompt self-routing — so that when pasted into Starchild (or any capable
model), it naturally triggers the right behavior without the user needing to
know what's available.
Tactics:
- Name the output type explicitly when it maps to a known skill or tool.
Instead of "make a presentation," write "Create a .pptx presentation…" so a
presentation skill triggers. Instead of "make a doc," write "Create a Word
document (.docx)…"
- Specify the stack or format when the task is technical. "Build a React
component using Tailwind CSS" is more routable than "build a UI."
- Include action verbs that signal tool use where appropriate: "Search for…",
"Fetch the page at…", "Read the uploaded file and…", "Generate an image of…"
- Reference data sources or integrations if implied by context: "Pull data
from the connected Google Sheet," "Check my calendar for…"
- Do not invent skills or tools that may not exist. Stick to broadly
understood formats and capabilities. If unsure whether a specific integration
is available, phrase it as a conditional: "If calendar access is available,
check for conflicts; otherwise ask me to paste my schedule."
The rewritten prompt should read naturally — skill hints should feel like
specifications, not metadata.
Starchild-native capabilities
When the prompt involves crypto, trading, wallets, or financial data, you may
safely reference these capabilities — they exist in Starchild and will route
correctly:
- Wallet analysis — balances across EVM chains and Solana
- Hyperliquid positions — open positions, orders, fills, funding rates
- DeFi yields — Aave, Morpho, DefiLlama protocol data
- Charting — TradingView-style candlestick and indicator charts
- Token data — prices, market cap, volume via CoinGecko
- On-chain analytics — DeBank portfolio, whale tracking, liquidations via CoinGlass
- Token unlocks — emission schedules and allocation breakdowns via Tokenomist
Use these in routing hints when the user's implied task involves any of the above.
Do not invent capabilities beyond this list.
Quality audit
Before returning the rewritten prompt, ask yourself one question:
"Is this actually better — or just longer?"
If the rewrite is only longer, trim it. A good rewrite is denser and more
precise than the original. If trimming would make it worse, keep it. The test
is quality, not compression.
Starchild behavior
This skill is for rewriting only.
- If invoked with
/reword, return the improved prompt only
- Do not silently execute the rewritten prompt
- Do not use tools unless the user explicitly wants a research-backed prompt
- Do not add unnecessary complexity
- Optimize for token efficiency and practical reuse
Output format
Default output format:
Improved prompt
[rewritten prompt]
Optional, when useful, add a very short note below the block with one sentence
max, such as:
- Assumed a general audience.
- Optimized for Claude-style models.
- Added production-ready constraints.
- Consider splitting the deployment step into a follow-up.
Do not add long commentary.
When to ask one question
Ask a single clarifying question only if the raw prompt is genuinely
unsalvageable without more information. This is rare. Examples:
- The user references content you cannot see and no default makes sense
- The target output depends entirely on a missing platform, language, or audience
with no reasonable default
- The prompt is so short or vague that every possible rewrite would be a
different task
If a reasonable default exists — even an imperfect one — use it and note the
assumption. Do not ask.
Examples
Example 1
User input:
/reword write something about ai
Output:
Improved prompt
Write a clear 300-word overview of artificial intelligence for a general audience. Explain what AI is, how it is used today, one major benefit, one major risk, and end with a simple real-world example. Use plain English and avoid jargon.
Example 2
User input:
/reword build me a login page
Output:
Improved prompt
Build a modern responsive login page as a single React component using Tailwind CSS. Include email and password fields, a show-password toggle, a forgot-password link, clear validation states, and a primary sign-in button. Use clean production-ready component structure and accessible form markup.
Example 3
User input:
/reword make this email better
Output:
Improved prompt
Rewrite the following email to sound professional, concise, and friendly. Keep the meaning the same, improve clarity, remove filler, and end with a clear call to action: [paste email here]
Example 4
User input:
/reword make a pitch deck about our seed round
Output:
Improved prompt
Create a .pptx pitch deck for a seed-round fundraise. Include slides for: problem, solution, market size, product demo/screenshots, business model, traction, team, and ask. Use a clean minimal design with dark backgrounds. Keep text sparse — one key point per slide with supporting data. Assume a fintech startup unless I specify otherwise.
- Specified .pptx to trigger presentation tooling.
Example 5
User input:
/reword build me a dashboard and also write a report on the data and send it to my team
Output:
Improved prompt
Build an interactive data dashboard as a single-page React app using Tailwind CSS and Recharts. Include filter controls, key metric cards at the top, and at least one time-series chart and one comparison chart. Use placeholder data that I can swap out. Keep the layout clean and responsive.
- This is the highest-leverage task from your request. Follow up separately with: (1) "Write a .docx report summarizing the key findings from this data" and (2) "Draft a Slack message to my team sharing the report and dashboard link."
Example 6
User input:
/reword show me my positions
Output:
Improved prompt
Show my current Hyperliquid positions: open trades, entry prices, unrealised PnL, leverage, and current funding rates. Include any open orders. If I have no active positions, show my recent fills instead.
- Routed to Hyperliquid positions using the Starchild-native capabilities list.
Non-goals
- Do not complete the task itself when
/reword is used
- Do not expose hidden chain-of-thought
- Do not generate multiple prompt options unless the user asks
- Do not turn every prompt into an excessively long specification
- Do not invent or hallucinate tool names or skill identifiers
Summary
/reword [prompt] means:
- if input is empty, ask "What prompt would you like me to improve?"
- read the raw prompt
- improve it (with smart format/tool/skill hints baked in)
- for crypto/trading prompts, use the Starchild-native capabilities list
- keep it 2–5× original length, ~150 word cap
- split compound tasks if they'd work better separately
- audit: "is this better, or just longer?"
- show the better version
- stop there
