Prompt Optimizer
Turn fuzzy product or agent requirements into explicit EARS-style statements with role-based and conditional logic before implementation or prompting.
Overview
prompt-optimizer is an agent skill most often used in Build (also Validate scope, Ship review) that applies EARS transformation patterns to multi-stakeholder and conditional requirements for clearer agent and system spec
Install
npx skills add https://github.com/daymade/claude-code-skills --skill prompt-optimizerWhat is this skill?
- Transforms complex requirements into EARS patterns with explicit conditions and system shall obligations
- Documents multi-stakeholder flows with separate EARS statements per role and explicit conflict handling
- Includes hierarchical permission patterns (Owner, Admin, Editor, Viewer) and nested AND/OR role conditions
- Covers context-dependent access and non-functional constraints via advanced conditional logic
- Reference-oriented patterns for sophisticated requirements—not one-shot chat rewrites
Adoption & trust: 1k installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your requirements read as vague user stories or chat prompts, so agents and engineers guess at roles, edge cases, and permission rules.
Who is it for?
Builders drafting agent instructions or product specs where access, roles, or conditional behavior must be precise before coding.
Skip if: Simple single-user CRUD with no permission model, pure marketing copy tuning, or teams that already enforce a separate formal requirements tool outside the agent.
When should I use this skill?
Requirements involve multiple stakeholders, non-functional constraints, or sophisticated conditional logic that should be expressed as EARS patterns.
What do I get? / Deliverables
You produce explicit EARS shall-statements with role-based and nested conditions that downstream build and review work can trace to acceptance criteria.
- EARS shall-statements per stakeholder or scenario
- Documented role-hierarchy and context-dependent access patterns
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Formal requirement patterns are most often applied while shaping what to build—specs and agent behavior—so the canonical shelf is Build with product-management framing. The skill focuses on stakeholder requirements, permissions, and conditional shall-statements, which is PM-style specification work rather than frontend or backend coding tasks.
Where it fits
Scope an MVP admin console by writing separate EARS statements per role before committing to a auth model.
Encode agent tool permissions as nested if/when shall-rules so Codex implements the same guardrails you documented.
Compare shipped RBAC behavior against the original EARS matrix during pre-release spec review.
How it compares
Use as a structured requirements reference—not a generic ‘make my prompt sound better’ rewriter for one-off chat messages.
Common Questions / FAQ
Who is prompt-optimizer for?
Solo builders and indie teams writing specs or agent prompts for multi-role software who want EARS-style clarity before implementation.
When should I use prompt-optimizer?
Use it during Validate when scoping role-based features, during Build PM when locking agent behavior constraints, or during Ship review when reconciling specs with implemented permission logic.
Is prompt-optimizer safe to install?
Check the Security Audits panel on this Prism page and the upstream skill content; the reference is documentation-heavy and does not inherently require credentials, but review any bundled repo changes before use.
SKILL.md
READMESKILL.md - Prompt Optimizer
Security scan passed Scanned at: 2025-11-16T23:30:38.515326 Tool: gitleaks + pattern-based validation Content hash: 91d8d92a27fc76565a0dc07dac515c2fd71d869ddf51b7046b3a0e512a7ff7c6 # Advanced Prompt Optimization Techniques ## Overview This reference covers advanced EARS transformation patterns for complex requirements involving multiple stakeholders, non-functional constraints, and sophisticated conditional logic. ## Multi-Stakeholder Requirements When requirements involve multiple user types with different needs and permissions: ### Approach 1. Create EARS statements for each stakeholder 2. Identify conflicting requirements (admin vs. user permissions) 3. Specify role-based conditions explicitly 4. Use nested conditions when access depends on multiple factors ### Patterns **Basic role-based access:** ``` If user role is 'Admin', the system shall display all user management controls If user role is 'Editor', the system shall display content editing controls If user role is 'Viewer', the system shall prevent access to editing functions ``` **Hierarchical permissions:** ``` If user role is 'Owner' OR 'Admin', the system shall allow deletion of any content If user role is 'Editor' AND content.author is current user, the system shall allow editing of that content If user role is 'Viewer', the system shall display content in read-only mode ``` **Context-dependent access:** ``` When user requests sensitive data: - If user role is 'Manager' AND user.department matches data.department, the system shall grant access - If user role is 'Executive', the system shall grant access regardless of department - Otherwise, the system shall deny access and log the attempt ``` ### Example: Content Management System **Requirement:** "Different users should have different permissions" **EARS transformation:** ``` 1. When user logs in with 'Admin' role, the system shall display dashboard with user management, content moderation, and system settings 2. When user logs in with 'Author' role, the system shall display dashboard with create post, edit own posts, and view analytics 3. When 'Author' attempts to publish post, the system shall set post status to 'pending review' 4. When 'Editor' reviews pending post, the system shall provide approve/reject/request changes options 5. If 'Author' attempts to access another author's draft, the system shall prevent access and display "Access Denied" message 6. When 'Admin' accesses any post, the system shall grant full permissions (view, edit, delete, publish) regardless of author ``` ## Non-Functional Requirements Performance, security, scalability, and reliability requirements need precise quantification. ### Approach 1. Quantify constraints explicitly (no vague terms like "fast" or "secure") 2. Specify measurement methods (how to verify the requirement) 3. Include threshold values (acceptable ranges) 4. Define degradation behavior (what happens when thresholds are exceeded) ### Patterns **Performance requirements:** ``` When search query is submitted, the system shall return results within 200ms for 95% of requests When page load is initiated, the system shall display first contentful paint within 1.5 seconds for 90% of requests While concurrent user count exceeds 10,000, the system shall maintain response time below 500ms ``` **Security requirements:** ``` When user authentication fails 5 times within 15 minutes, the system shall lock the account for 30 minutes When password is created, the system shall enforce minimum 12 characters, 1 uppercase, 1 number, 1 special character While session is active, the system shall invalidate session after 30 minutes of inactivity If SQL injection pattern is detected in input, the system shall sanitize input and log security event ``` **Scalability requirements:** ``` When concurrent user count reaches 50,000, the system shall auto-scale to additional server instances When database query time exceeds 100ms, the system shall use read replicas