Best for
- Craft better prompts using proven optimization techniques — use when your prompt needs refinement
nyldn/claude-octopus/skills/skill-meta-prompt/SKILL.md
Craft better prompts using proven optimization techniques — use when your prompt needs refinement
Decision brief
Craft better prompts using proven optimization techniques — use when your prompt needs refinement
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/nyldn/claude-octopus --skill "skills/skill-meta-prompt"Inspect the Agent Skill "skill-meta-prompt" from https://github.com/nyldn/claude-octopus/blob/bc76e7c8248c93cfc4ba621ac5421077710777d0/skills/skill-meta-prompt/SKILL.md at commit bc76e7c8248c93cfc4ba621ac5421077710777d0. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What: Use different "experts" for creation vs. validation. Never use the same expert to both create and verify.
What: Build explicit verification steps into the task, especially for error-prone outputs.
If information is missing, ask ONE clarifying question at a time.
After gathering requirements, analyze internally:
Review the “Task Complexity Assessment” section in the pinned source before continuing.
Permission review
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 94/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 4,000 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than
/octo:*slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, seeskills/blocks/codex-host-adapter.md.
Generate well-structured, verifiable prompts for any use case. Applies proven meta-prompting techniques to minimize hallucination and maximize effectiveness.
┌─────────────────────────────────────────────────────────────────────────────┐
│ META-PROMPT GENERATION │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Phase 1: Requirement Gathering │
│ → Understand the primary goal/role │
│ → Clarify expected outputs │
│ → Identify accuracy requirements │
│ ↓ │
│ Phase 2: Task Analysis │
│ → Apply Technique 1: Task Decomposition │
│ → Identify if complex enough for subtasks │
│ → Map dependencies between subtasks │
│ ↓ │
│ Phase 3: Expert Assignment │
│ → Apply Technique 5: Specialized Experts │
│ → Assign personas to subtasks │
│ → Apply Technique 2: Fresh Eyes Review │
│ ↓ │
│ Phase 4: Verification Design │
│ → Apply Technique 3: Iterative Verification │
│ → Build in checking steps │
│ → Apply Technique 4: No Guessing │
│ ↓ │
│ Phase 5: Prompt Assembly │
│ → Structure: Role, Context, Instructions, Constraints, Format │
│ → Add verification hooks │
│ → Include uncertainty disclaimers │
│ ↓ │
│ Phase 6: Output & Iteration │
│ → Present generated prompt │
│ → Offer refinement │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
What: Break complex tasks into smaller, manageable subtasks.
When to use:
How to apply:
Example:
Task: "Create a technical blog post about OAuth 2.0"
Decomposition:
1. Research Phase
- Gather OAuth 2.0 specifications
- Find common implementation examples
- Identify security best practices
2. Structure Phase
- Outline main sections
- Plan code examples
- Design diagrams/visuals
3. Writing Phase
- Write introduction
- Write technical sections
- Write conclusion/CTA
4. Review Phase
- Technical accuracy check
- Code example testing
- Readability review
What: Use different "experts" for creation vs. validation. Never use the same expert to both create and verify.
When to use:
How to apply:
Example:
Creator: "Expert Technical Writer" produces article
Reviewer: "Expert Security Engineer" verifies OAuth claims
Reviewer: "Expert Developer" tests code examples
NOT: Same expert writes AND reviews their own work
What: Build explicit verification steps into the task, especially for error-prone outputs.
When to use:
How to apply:
Example:
Step 1: Calculate discount price
Step 2: VERIFY - recalculate from opposite direction
Step 3: If mismatch, identify error and recalculate
Step 4: Only proceed when both methods match
What: Never assume unverified facts. Disclaim uncertainty explicitly.
When to use:
How to apply:
Disclaimer templates:
"Note: This figure is approximate and should be verified."
"I don't have access to [specific data]. Please provide or verify."
"This is based on general patterns; your specific case may differ."
What: Spawn domain-specific personas for complex subtasks.
When to use:
Available expert archetypes:
| Expert | Use For |
|---|---|
| Expert Writer | Content, copy, documentation |
| Expert Mathematician | Calculations, proofs, statistics |
| Expert Python | Python code, data analysis |
| Expert Security | Security review, threat modeling |
| Expert Architect | System design, trade-offs |
| Expert Reviewer | Quality assurance, error-finding |
| Expert Strategist | Planning, prioritization |
How to apply:
"For this subtask, adopt the persona of Expert [X].
Your expertise includes [specific areas].
Focus exclusively on [your assigned task].
You have no memory of previous context—all needed information is below."
**Meta-Prompt Generator**
I'll help you create an effective, verifiable prompt.
**Questions:**
1. **What is the main goal?**
What should this prompt help someone accomplish?
2. **What's the expected output?**
(e.g., document, code, analysis, decision)
3. **How important is accuracy?**
- Critical (factual, technical, or high-stakes)
- Moderate (useful but not mission-critical)
- Flexible (creative, exploratory)
4. **Any specific constraints?**
(length, format, tone, tools available)
If information is missing, ask ONE clarifying question at a time.
After gathering requirements, analyze internally:
| Complexity | Indicators | Approach |
|---|---|---|
| Simple | Single step, one output | Direct prompt, no decomposition |
| Moderate | 2-3 steps, clear sequence | Light decomposition, one expert |
| Complex | 4+ steps, dependencies | Full decomposition, multiple experts |
| Task Type | Creator Expert | Reviewer Expert |
|---|---|---|
| Technical writing | Expert Writer | Expert Engineer |
| Code generation | Expert Developer | Expert Reviewer |
| Analysis | Expert Analyst | Expert Strategist |
| Creative | Expert Creative | Expert Editor |
For the task, identify where verification is needed:
| Step | Risk | Verification Method |
|---|---|---|
| [step] | [what could go wrong] | [how to verify] |
You MUST return the generated prompt in this exact format:
# [Prompt Title]
## Role
[Short, direct role definition]
[Emphasize verification and uncertainty disclaimers]
## Context
[User's task and goals]
[Background information provided]
[Clarifications gathered]
## Instructions
### Phase 1: [First Phase Name]
1. [Step 1]
2. [Step 2]
3. **Verification:** [How to verify this phase]
### Phase 2: [Second Phase Name]
1. [Step 1]
2. [Step 2]
3. **Verification:** [How to verify this phase]
[Continue phases as needed...]
### Expert Assignments (if applicable)
- **[Expert Type]:** Handles [specific subtask]
- **[Reviewer Type]:** Validates [what they check]
## Constraints
- [Constraint 1]
- [Constraint 2]
- [Accuracy requirement: how to handle uncertainty]
## Output Format
[Specify exactly how the output should be structured]
[Include all required sections]
## Verification Checklist
Before considering complete:
- [ ] [Verification item 1]
- [ ] [Verification item 2]
- [ ] [Accuracy disclaimers added where needed]
## Examples (if provided)
[Context or examples from user]
Tune the assembled prompt to the model that will execute it:
skills/blocks/frontier-model-routing.md when choosing between Opus 5, GPT-5.6, Sonnet 5, Fable 5, or cheaper seats.claude-fable-5 pin): apply skills/blocks/fable5-prompting.md. In short: never instruct the model to reveal or transcribe its reasoning (triggers a refusal); replace step-by-step micromanagement with a boundary plus checkable acceptance criteria; drop "CRITICAL"/"MUST" emphasis unless strict compliance is required; add grounded-progress and act-when-ready language for long runs.docs/GPT-5.6-PROMPTING.md; give it a concrete outcome, scoped repository constraints, checkable acceptance criteria, non-goals, and the required verification.**Generated Meta-Prompt**
[The prompt in the format above]
**Techniques Applied:**
- ✓ Task Decomposition: [Yes/No, how]
- ✓ Fresh Eyes Review: [Yes/No, which experts]
- ✓ Iterative Verification: [Yes/No, where]
- ✓ No Guessing: [Where disclaimers needed]
- ✓ Specialized Experts: [Which ones assigned]
**Would you like me to:**
1. Refine any section
2. Add more verification steps
3. Adjust the complexity level
4. Execute this prompt now
"Create a prompt to help me write API documentation"
# API Documentation Generator
## Role
You are an Expert Technical Writer specializing in API documentation.
Your documentation will be reviewed by an Expert Developer for accuracy.
When uncertain about behavior, note "Verify with implementation" rather than guessing.
## Context
Creating comprehensive API documentation for developers.
Documentation should be usable without reading source code.
## Instructions
### Phase 1: API Discovery
1. List all endpoints with methods (GET, POST, etc.)
2. Document request/response schemas
3. Identify authentication requirements
4. **Verification:** Cross-reference with OpenAPI spec if available
### Phase 2: Documentation Writing
1. Write endpoint descriptions (what it does, not how)
2. Create request examples with all parameters
3. Create response examples for success and error cases
4. Document rate limits and constraints
5. **Verification:** Each example should be valid JSON/code
### Phase 3: Review Cycle
Expert Developer reviews for:
- Technical accuracy of examples
- Missing edge cases
- Unclear descriptions
### Expert Assignments
- **Expert Technical Writer:** Creates documentation prose
- **Expert Developer:** Validates examples and accuracy
## Constraints
- Use consistent terminology throughout
- Examples must be syntactically valid
- Note any undocumented or unclear behaviors
- Accuracy: Mark assumptions with "Assumed behavior - verify"
## Output Format
```markdown
# [Endpoint Name]
**Method:** [HTTP method]
**Path:** [/api/path]
**Auth:** [Required/Optional/None]
## Description
[What this endpoint does]
## Request
[Parameters, body schema, headers]
## Response
[Success and error responses with examples]
## Notes
[Rate limits, deprecation, related endpoints]
## Error Handling
### Unclear Requirements
```markdown
I need a bit more clarity to create an effective prompt.
**Specifically:**
[Question about the unclear part]
[Offer 2-3 options if applicable]
This task has [N] distinct components. I recommend:
1. **Split into multiple prompts** - One per major component
2. **Simplify scope** - Focus on [core element] first
3. **Proceed as-is** - Full complexity, longer prompt
Which approach works best for you?
If techniques don't fit the task:
ℹ️ **Note on Techniques**
This task is straightforward enough that some techniques
don't apply:
- Task Decomposition: Not needed (single step)
- Fresh Eyes: [Explain why/why not]
- Specialized Experts: Not needed (single domain)
The generated prompt focuses on clarity and verification instead.
Generate prompts for content creation based on anatomy guides.
Transform brainstorming insights into actionable prompts.
Enhance PRD generation with meta-prompting techniques.
Generate implementation prompts with built-in verification.
Meta-prompt → Decompose → Assign experts → Build verification → Generate
Otherwise → Vague prompts → Hallucination → Unreliable output
Structure breeds reliability. Verification breeds accuracy. Experts breed quality.
Frequently asked questions
Craft better prompts using proven optimization techniques — use when your prompt needs refinement
The source record exposes this install command: npx skills add https://github.com/nyldn/claude-octopus --skill "skills/skill-meta-prompt". Inspect the command and pinned source before running it.
Alternatives
nyldn/claude-octopus
Craft better prompts using proven optimization techniques — use when your prompt needs refinement
NintendaDev/unikit-ai
Generate and maintain the project's TECHNICAL documentation from its codebase — scans the project structure, tech stack, and module boundaries, then writes a lean README landing page plus detailed topic pages (architecture, modules, setup, build, APIs), only the docs that are relevant. Use whenever the user wants to create, update, or validate documentation of the CODE or the project itself, e.g. "generate documentation", "create docs", "write the README", "update the project docs", "document th
eugenelim/agent-ready-repo
Use when implementing or resuming a non-trivial repository change: a feature, behavior-changing fix, refactor, migration, framework or dependency upgrade, schema or API change, performance work, infrastructure or build-system change, reversion, or an existing build spec under `docs/specs/`. Also use for bare continuation commands ('resume', 'continue', 'keep going', 'pick up where I left off', 'let's get going') when conversation or workspace context identifies active build work. Do not use for
mgiovani/cc-arsenal
Multi-agent review team: architecture, security, performance, testing, style, docs/UX, plus an adversary that cross-examines the other 6, for security-sensitive, architectural, or large PRs (15+ files) where a single-agent pass risks missing cross-cutting issues. Use for auth/payments/PII changes, schema/pattern changes, compliance sign-off, or when asked to 'get the review team on this' / 'multi-agent review' / 'thorough review before merge'. For a standard PR or a quick pre-merge check, use /r