Spec
Scaffold a spec-driven prompt before non-trivial implementation. Forces Context/Objective/Boundaries/Validation framing so the agent ships reviewable code in one pass instead of refactoring files it was never asked to touch. Triggers "/spec", "spec this out", "write a spec prompt", "scope this task".
Install
$ agentstack add skill-ao92265-claude-code-playbook-spec ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Links to your public security report.[](https://agentstack.voostack.com/security/report/skill-ao92265-claude-code-playbook-spec) Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Spec
Turns a vague request into a four-part specification before any code is written. Prevents the two recurring failures: vague scope (agent rewrites working modules) and missing validation (green CI theater).
When to use
- Before non-trivial implementation (multi-file, refactor, new feature).
- When a request reads like a conversation ("improve the API") instead of a spec.
Skip for: one-line fixes, lookups, trivial edits.
The four parts (ALL required)
Fill every section. A blank section means STOP and ask — do not guess.
- Context — What exists right now. Exact file paths, current behavior, relevant constraints. No "the codebase" — name the files.
- Objective — What the change must accomplish, NOT what the code should look like. Describe the outcome, let the implementation follow.
- Boundaries — What must NOT change. Files off-limits, behaviors to preserve, external interfaces/schemas frozen. Always include an explicit "do not modify outside X" line.
- Validation — How to confirm it works. Exact test/build command + expected result. New behavior requires new tests.
Template
Context:
Objective:
Boundaries: Do not modify . Do not change .
Validation: Run . . Add tests for .Rules
- Objective describes outcome, never implementation detail ("validate disposable emails", not "add a regex").
- Boundaries names real paths from the repo — verify they exist before listing them.
- Validation command must be runnable and its pass/fail observable. No "make sure it works".
- Respects existing repo caps (e.g. bugfix ~50-line / one-concern limits) — fold them into Boundaries.
Output
The filled spec, ready to hand to an executor or run inline. No preamble. If a section can't be filled from available context → single batched question, then fill and proceed.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: ao92265
- Source: ao92265/claude-code-playbook
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.