From fabrik
Writes and iterates on project specs in docs/spec.md defining objectives, users, features, non-goals, constraints, and success criteria. Use for spec creation, updates, or product decisions.
npx claudepluginhub maragudk/fabrik --plugin fabrikThis skill uses the workspace's default tool permissions.
The spec is the living product document. It defines _what_ to build and _why_. It does not define _how_ -- that belongs in CLAUDE.md, skills, and the code itself.
Guides Next.js Cache Components and Partial Prerendering (PPR): 'use cache' directives, cacheLife(), cacheTag(), revalidateTag() for caching, invalidation, static/dynamic optimization. Auto-activates on cacheComponents: true.
Processes PDFs: extracts text/tables/images, merges/splits/rotates pages, adds watermarks, creates/fills forms, encrypts/decrypts, OCRs scans. Activates on PDF mentions or output requests.
Share bugs, ideas, or general feedback.
The spec is the living product document. It defines what to build and why. It does not define how -- that belongs in CLAUDE.md, skills, and the code itself.
The spec lives at docs/spec.md. Create the docs/ directory if it doesn't exist.
Follow the brainstorm pattern: one question at a time, multiple choice where possible.
Walk through the spec sections one at a time. For each section, ask focused questions to draw out what the user actually wants. Don't assume -- even for projects that sound straightforward, the interesting constraints are the ones the user hasn't said yet.
Once all sections are covered, write the spec section by section, asking for approval after each before moving to the next.
Assemble approved sections into docs/spec.md.
docs/spec.md first.When a product decision comes up during other work (implementation, brainstorm, etc.), suggest capturing it in the spec. If the user agrees, read the existing spec, propose where the decision fits, and show the update for approval.
The spec always has these sections in this order:
# [Project Name]
## Objective
What is this? One paragraph. Name the problem, the audience, and the core value proposition.
## Users
Who uses this and what do they care about? Describe distinct user types or personas if there are more than one.
## Features
What can users do? Organize by area. Each feature is a short description of observable behavior, not implementation detail.
## Non-goals
What this project deliberately does not do. Explicit non-goals prevent scope creep and give contributors permission to say no.
## Constraints
Hard requirements that shape decisions: regulatory, performance, compatibility, data residency, budget, etc. Only include real constraints, not preferences.
## Success criteria
How do we know this is working? Concrete, observable indicators -- not vanity metrics. "Users can complete X without Y" is better than "increase engagement".
## Open questions
Decisions not yet made. Each entry should state the question and why it matters. Remove entries as they get resolved into other sections.
Implementation details belong elsewhere:
If you find yourself writing about how something is built rather than what it does or why it matters, it doesn't belong here.