skills/create-great-prompts/SKILL.md
Write effective prompts for LLM agents — system prompts, workflow instructions, skill files, and agent configurations. Use when creating or improving prompts that agents will execute.
npx skillsauth add technickai/openclaw-config create-great-promptsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You write prompts that LLMs execute — system prompts, agent instructions, workflow definitions, skill files. The model running your prompt is likely more capable than you expect. Communicate what you want clearly and trust it to figure out how.
State what success looks like. Trust the executing model to determine the approach.
Remove the 'I' prefix from all TypeScript interface names throughout the codebase,
updating all references. Ensure type checking still passes.
Include specific steps only when order is critical and non-obvious, or when the process itself is the deliverable (like a deployment checklist).
Positive instructions are unambiguous. "Write in flowing prose" gives the model a clear target. State what you want, not what you want to avoid — the model executes toward a destination, not away from one.
LLMs encode patterns from what they see, regardless of labels. When teaching through examples, flood with 3-5 correct examples following identical structure. Describe exceptions and edge cases in prose.
LLMs weight early content more heavily. Lead with identity, context, and the primary objective. Save edge cases for later.
For complex prompts: identity/role → objective → constraints → examples → output format.
Constraints with reasoning generalize better than bare rules.
Use try-catch blocks in all API handlers — unhandled exceptions crash the worker
process and require manual restart.
Use XML-style tags when a prompt has multiple distinct sections that need clear
boundaries. Use semantic tag names (<task-preparation> not <phase-1>), keep them
consistent throughout, and skip them entirely for simple prompts.
<context>
Working in a Next.js 14 app with TypeScript and Tailwind
</context>
<objective>
Create a reusable modal component with Radix UI primitives
</objective>
<requirements>
- Accessible keyboard navigation
- Support controlled and uncontrolled modes
</requirements>
When writing prompts that another LLM will execute (not a human reading):
Be explicit. Spell out context that a human would infer. "Update webpack.config.js to enable source maps in development mode by setting devtool: 'source-map'" — not "update the config."
Use consistent terminology. Same word for the same concept throughout. Varying vocabulary for style introduces ambiguity that humans resolve but LLMs may not.
Name your references. "After updating the UserProfile component, test user authentication" — pronouns without clear antecedents create parsing ambiguity.
Keep formatting functional. Headings for structure, code blocks for patterns, plain text for instructions. Every formatting choice should aid parsing, not decoration.
When someone asks you to write a prompt:
Understand the goal. What will the executing model produce? What does success look like? Ask if it's unclear.
Understand the context. What model runs this? What tools does it have? What does it already know? What's the input format?
Write the prompt. Apply the principles above. Start with the simplest version that could work — you can always add specificity.
Stress-test mentally. Could a different model interpret this differently than you intend? Are there ambiguities? Would this work without your implicit knowledge of the project?
Apply the principles as a lens. The single most important question: can another LLM execute this without your implicit knowledge?
development
A pause before an artifact goes into the world. Reviews external comms, money, calendar, public posts, or send-as-operator actions through a small panel of independent lenses (empathy first) and returns a verdict of pass / edit / hold / block.
development
Route real repo work to Claude Code instead of editing by hand. Triggers on "claude code" or "cc", and on any request to edit, fix, refactor, or open a PR in a repo outside ~/.openclaw/workspace. Claude Code picks up the repo's CLAUDE.md / AGENTS.md, applies its standards, and knows the /ai-coding-config:multi-review and /ai-coding-config:address-pr-comments workflows we want bug bots checking against.
testing
Drive a task all the way to a verified done state — write DoD first, verify each item with evidence, stop only at named stop conditions.
tools
Design, build, and maintain autonomous OpenClaw workflows (stewards). Use when creating new workflow agents, improving existing ones, evaluating automation opportunities, or debugging workflow reliability. Triggers on "build a workflow", "create a steward", "automate this process", "workflow audit", "what should I automate", "create a cron job", "schedule a recurring task", "build a scheduled job".