prompt-evaluation-runn…
Use when evaluating prompts, LLM outputs, red-team suites, or model behavior with local eval configs and safe provider/cost controls.
Use when writing technical documentation that needs to be readable by both humans and AI models, converting existing docs to HADS format, validating a HADS document, or optimizing documentation for token-efficient AI consumption.
$ npx -y skills add yeaight7/agent-powerups --skill agent-readable-docs --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/agent-readable-docsContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when writing technical documentation that needs to be readable by both humans and AI models, converting existing docs to HADS format, validating a HADS document, or optimizing documentation for token-efficient AI consumption.
name: agent-readable-docs description: Use when writing technical documentation that needs to be readable by both humans and AI models, converting existing docs to HADS format, validating a HADS document, or optimizing documentation for token-efficient AI consumption.
---
This skill teaches the agent how to read, generate, and validate HADS documents. Read all `[SPEC]` blocks before responding to any HADS-related request. Read `[NOTE]` blocks if you need context on intent or edge cases.
---
**[SPEC]**
---
**[SPEC]**
**[SPEC]** Authoritative fact. Terse. Bullet lists, tables, code. AI reads always. **[NOTE]** Human context, history, examples. AI may skip. **[BUG]** Verified failure + fix. Required fields: symptom, cause, fix. Always read. **[?]** Unverified / inferred. Lower confidence. Always flagged.
Block tag rules:
---
**[SPEC]**
# Document Title **Version X.Y.Z** · Author · Date · [metadata] --- ## AI READING INSTRUCTION Read `[SPEC]` and `[BUG]` blocks for authoritative facts. Read `[NOTE]` only if additional context is needed. `[?]` blocks are unverified — treat with lower confidence. --- ## 1. First Section **[SPEC]** ...
Required elements in order: 1. H1 title 2. Version block in header 3. AI manifest section before first content section 4. Content sections (H2), subsections (H3)
---
**[SPEC]** When encountering a HADS document: 1. Find and read the AI manifest first 2. Read all `[SPEC]` blocks — these are ground truth 3. Read all `[BUG]` blocks — always, before generating any code or config 4. Read `[NOTE]` blocks only if `[SPEC]` is insufficient to answer the query 5. Treat `[?]` content as hypothesis — note uncertainty in response
Token optimization: for large documents, scan section headings first, then read only `[SPEC]` and `[BUG]` blocks in relevant sections.
---
**[SPEC]** When asked to write documentation in HADS format:
1. Start with header block (title, version, metadata) 2. Add AI manifest — always include, never skip 3. Organize content into numbered H2 sections 4. For each fact: write as `[SPEC]` — terse, bullet or table or code 5. For each "why" or context: write as `[NOTE]` 6. For each known failure mode with confirmed fix: write as `[BUG]` 7. For each unverified claim: write as `[?]` 8. End with changelog section
Content rules for `[SPEC]`:
Content rules for `[BUG]`:
**[NOTE]** When converting existing documentation to HADS: extract facts into `[SPEC]`, move narrative and history to `[NOTE]`, surface all known issues as `[BUG]`. Do not duplicate content between block types.
---
**[SPEC]** A valid HADS document must have:
---
**[NOTE]** HADS exists because AI models increasingly read documentation before humans do. The format optimizes for this reality without sacrificing human readability.
Key insight: the AI manifest is the core innovation. It lets the model know what to read and what to skip — without requiring it to reason about document structure. Explicit is better than implicit for model consumption.
Curated power-ups for coding agents: skills, slash commands, MCP configs, hooks, AGENTS.md templates, and workflows for serious software engineering. Claude Code, Codex, Antigravity CLI, Cursor and more
Repo: yeaight7/agent-powerups
Use when evaluating prompts, LLM outputs, red-team suites, or model behavior with local eval configs and safe provider/cost controls.
Use when creating or reviewing red-team eval plugins, attack templates, grader rubrics, safety fixtures, or model-risk test metadata.
Use when designing, running, debugging, or hardening deterministic eval suites for agent skills, prompts, tool workflows, or MCP-backed cases.
Use when designing tool definitions for a new agent or subagent, an agent shows high retry rates, ambiguous tool invocations, or silent failures, or an…
Use when routing a prompt to a local provider CLI for a second opinion, review, or plan -- you are about to call a provider directly, need the response saved…
Use when starting work in an unfamiliar area of a codebase, spawning a subagent that needs targeted file context, a first search pass missed the relevant file,…