handarbeit
OrganizationDrive Claude Code through an SDLC pipeline on your GitHub Project board — Specify → Research → Plan → Implement → Review → Validate. Human in the loop, or on it. A Go CLI for automated, issue-driven development. Docs → fabrik.handarbeit.io
Categories
Indexed Skills (22)
cut-release
Cut a new Fabrik release — gathers changes since last tag, writes release notes, delegates publication to scripts/cut-release.sh
fabrik-setup
Bootstrap a project to use Fabrik (the GitHub-Project-driven SDLC pipeline orchestrator that drives Claude Code workers through Specify/Research/Plan/Implement/Review/Validate stages). Use this skill when the user wants to install, set up, initialize, or get started with Fabrik for the first time — especially when they ask "how do I get started with Fabrik", "install Fabrik", "set up Fabrik in this project", or mention Fabrik in a project where no `.fabrik/` directory exists yet. Walks through prerequisites, binary install, GitHub Project board setup, `fabrik init`, secret configuration, and the first run.
architecture-baseline
Interviews the technical architect to complete a project's architecture baseline — stack and boundaries, the shared domain model, interface contracts, cross-cutting policies, non-functional budgets, build order, and the fitness functions that make the whole thing checkable. Converts user-facing guarantees from the experience baseline into system guarantees. Use this after the product specifications, technical constraints and experience baseline all exist, and before any code is written. Trigger it when someone wants to finalize the architecture, decide the technical approach for a whole project, set the patterns every feature must follow, or work out what the system must guarantee before a build starts.
architecture-foundations
Interviews the technical architect about the foundations a project is built on — the immovable constraints, the shared domain model and which feature owns each field, the interface contracts between features, and the authority model governing who can do what. Runs early, before experience design, and is re-run as specifications accumulate. Deliberately stops short of budgets, mechanisms and build order, which need the experience work first. Use this once the first specifications exist, and again whenever a new specification introduces an entity, a state or an authority. Trigger it when someone wants to capture technical constraints, establish a shared data model, define what each feature owns, agree interface contracts, or work out the guardrails a design has to live within.
clarify
Finds the vague and missing parts of an existing feature specification and fixes them by asking up to five targeted questions, one at a time, writing each answer back into the spec as it is answered. Follows GitHub Spec Kit's clarify workflow. Use this when someone wants to review, tighten, sharpen, sanity-check, poke holes in, or fill the gaps in a spec or requirements document, when they ask "what's missing from this spec", "is this ready to hand to engineering", or "what did I forget" — and as the natural follow-up after a spec has been written.
experience-baseline
Interviews the experience or UX lead about how a product behaves for the people using it — the conditions they work in, the surface states every screen must handle, the component and pattern vocabulary, the words, the accessibility floor, and the interaction budgets — and writes it up as a project experience baseline that every feature inherits. Use this after the product specifications exist and the technical constraints are captured, and before the architecture baseline is written. Trigger it when someone wants to define the design system, establish UX foundations, agree interaction patterns, work out what the product looks like in each state, or set the design ground rules a whole product must follow.
onboard
Interviews someone about a software project as a whole — the problem it solves, who it serves, what is in and out of scope, the hard constraints, and the domain vocabulary — and writes it up as a project constitution that every later feature specification inherits. Use this at the start of a project, before any individual feature is specified, whenever someone says they want to onboard a project, kick off or start a new project, capture project goals or context, define scope, agree terminology, or record the ground rules and non-negotiables that all specs must respect. Also use it when an existing constitution needs revisiting because the project's goals or boundaries have shifted. This is about the software being built — not about configuring folders, instructions, or settings for a Cowork project, which is a different thing that happens to share the word "project".
write-spec
Creates a new feature specification from a plain-language feature description, written for a product manager or business owner rather than an engineer, following GitHub Spec Kit's specify workflow. Writes a numbered specs/NNN-short-name/spec.md plus a requirements quality checklist, validates the spec against it, and asks up to three high-impact clarifying questions. Use this whenever someone wants to write, draft, start, or create a spec, specification, feature spec, PRD, or requirements document — and also when they describe a feature they want built and ask to "spec this out", "spec out a feature", "write this up properly", or "turn this into a spec". Trigger it even if they never say the words "spec kit" or "speckit".
fabrik-status
Check the current state of the Fabrik project board and running workers
fabrik-implement-comment
Use when operating as the Fabrik Implement comment reviewer. This skill guides applying user-requested code changes during implementation, committing and pushing, and updating the task checklist — without signaling stage completion.
fabrik-implement
Use when operating as the Fabrik Implement stage agent. This skill guides the implementation of a planned feature, following the task checklist to produce committed, tested, pushed code on a feature branch.
fabrik-plan-comment
Use when operating as the Fabrik Plan comment reviewer. This skill guides adjustments to the implementation plan in response to user feedback, updating the task checklist and approach decisions — producing updated plan content that the engine writes back to the Plan stage comment.
fabrik-plan
Use when operating as the Fabrik Plan stage agent. This skill guides the design of an implementation approach, producing a concrete plan with task checklist that the Implement stage will follow.
fabrik-research-comment
Use when operating as the Fabrik Research comment reviewer. This skill guides incorporation of user answers into research findings, removing resolved questions and surfacing follow-ups — producing updated findings that the engine writes back to the Research stage comment.
fabrik-research
Use when operating as the Fabrik Research stage agent. This skill guides technical research and codebase analysis for a well-specified feature, producing findings that inform the planning stage.
fabrik-review-comment
Use when operating as the Fabrik Review comment reviewer. This skill guides applying user decisions on review findings — fixing issues, dismissing false positives, or deferring items — then committing and pushing without signaling stage completion.
fabrik-review
Use when operating as the Fabrik Review stage agent. This skill guides code review of an implementation, finding and fixing issues, and ensuring the PR is ready for human review.
fabrik-specify-comment
Use when operating as the Fabrik Specify comment reviewer. This skill guides incorporation of user answers into an evolving spec, removing resolved questions and surfacing follow-ups until the spec is complete.
fabrik-specify
Use when operating as the Fabrik Specify stage agent. This skill guides the specification and clarification of a feature request, turning a rough backlog issue into a clear, unambiguous spec before technical research begins.
fabrik-validate-comment
Use when operating as the Fabrik Validate comment reviewer. This skill guides updating the validation report, re-running checks, and applying minor fixes in response to user feedback — signaling completion only when the user explicitly indicates the issue is resolved.
fabrik-validate
Use when operating as the Fabrik Validate stage agent. This skill guides final validation of an implementation, verifying requirements are met, tests pass, and the PR is ready to merge.
build-check
Build, test, vet, and format the Fabrik codebase
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.