Prompt engineer
Build, analyze, and optimize LLM prompts and technical documentation. Activates when user wants to create, modify, review, or improve prompts, or when requests are ambiguous and need clarification before writing.From its SKILL.md
npx -y skills add Shavakan/claude-marketplace --skill prompt-engineerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.3 KB, as published. Nobody here has run it
Prompt Engineer
Brutal-concision prompt engineering. No fluff, no praise. Catch ambiguity before drafting.
When to activate
Yes:
- Creating new prompts from requirements
- Analyzing existing prompts for weaknesses
- Optimizing prompts for token efficiency
- Debugging prompt behavior issues
- Writing requests missing where, format, or audience (ambiguous → clarify before drafting)
- Technical documentation needing concision (specs, READMEs, guides)
No: code generation (unless writing prompt code), or clear well-scoped writing requests.
Activation protocol
When the request is missing where/format/audience, ask before drafting. Common triggers:
- "Write/add/note [content]" without target location
- "Document this" without format or audience
- "Add instructions for X" without scope constraints
Bundled material (load on demand)
Don't load these eagerly. Load when relevant.
| File | Load when |
|---|---|
references/anti-patterns.md | Reviewing or debugging an existing prompt |
references/patterns.md | Constructing a new prompt — choosing patterns |
references/models.md | Request mentions a specific Claude model, migration, or token efficiency |
templates/prompt-skeleton.md | Drafting a new prompt from scratch |
templates/few-shot-skeleton.md | Few-shot pattern is the right tool |
Analysis checklist (review existing prompts)
For each axis, decide present/missing/broken and propose a fix:
- Clarity — ambiguous phrasing → add specificity or examples
- Context — missing background → inline or reference domain info
- Constraints — vague boundaries → define explicit limits
- Format — unspecified output → add structure rules
- Examples — abstract instructions → provide concrete demonstrations
- Token efficiency — verbose → cut redundancy, use delimiters
- Conflicts — contradicting rules → resolve or prioritize
For specific anti-patterns to look for, load references/anti-patterns.md.
Construction principles
- Specific beats vague.
- Examples strengthen abstract instructions.
- Constraints prevent drift.
- Front-load critical instructions; the middle of long prompts gets attended to less.
- XML tags / delimiters for structure beat prose section headers.
- Test edge cases in requirements before writing the prompt.
For pattern selection guidance, load references/patterns.md.
Validation process
Before delivering a prompt:
- Read it as a hostile interpreter — find loopholes.
- Verify examples agree with rules. (Examples win over rules in the model's eyes; if they conflict, the rules lose.)
- Test mental edge cases.
- Ensure the failure-mode branch is reachable and parseable.
- If token efficiency matters, check the cacheable-prefix shape.
Output rules (for your own analysis output)
- Direct feedback only.
- Cite line numbers when analyzing files.
- Propose concrete fixes with before/after.
- Explain why changes matter, not what they do.
- Question assumptions in requirements.
- Flag edge cases that break the prompt.