From sorah-spec
Provides conventions for writing self-contained, implementation-ready spec documents. Distinguishes specs from docs; covers structure including data model, architecture, security, operations, scope, and deliverables.
npx claudepluginhub sorah/config --plugin sorah-specThis skill uses the workspace's default tool permissions.
Conventions for writing implementation-ready specification documents that serve as the single source of truth for feature design and implementation.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
Conventions for writing implementation-ready specification documents that serve as the single source of truth for feature design and implementation.
Projects often maintain two distinct documentation layers. Understand the distinction to keep each layer focused.
When a spec lists documentation files as deliverables, verify their scope is clear. The spec itself must contain enough inline detail to be self-contained — never defer design details to documentation files.
A well-structured spec includes:
Inline all design details directly in the spec:
A reader should never need to open another file to understand the complete design.
Before a spec is considered interview-complete:
Every spec must end with a "Current Status" section. Its format differs by phase. See references/current-status-format.md for detailed examples across interview and implementation phases.
Keep concise — list covered areas with key decisions and remaining areas with rough question count:
## Current Status
Interview in progress.
Covered:
- Data Model: field types finalized, indexes decided
- Architecture: service object pattern chosen
Remaining (~8 questions):
- Behavior & Logic: error handling details
- Security: rate limiting defaults
- Operations: cleanup strategy
Expand into a checklist and updates format:
## Current Status
Implementation in progress. Implementors MUST keep this section updated as they work.
### Checklist
- [ ] Create database migration
- [ ] Implement service object
- [ ] Add request specs
- [ ] Write documentation
### Updates
- YYYY-MM-DD: Migration created, model specs passing
- YYYY-MM-DD: Service object implemented with error handling
references/current-status-format.md — Detailed examples of Current Status sections across interview and implementation phases