Build

Skill domengabrovsek/claude/skills/build

Custom configuration for Claude Code that turns it into a disciplined engineering partner with structured workflows, strict guardrails, and domain-specific expertise.

Install

npx -y skills add domengabrovsek/claude --skill build

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Implement code incrementally with quality gates. Use when the user says 'build', 'implement', or when starting the implementation phase of an approved plan.

SKILL.md

2.9 KB, as published. Nobody here has run it

Implement the approved plan incrementally: $ARGUMENTS

Follow these disciplines:

Before Starting

why-not-mechanizable: skill workflow guidance; each step requires understanding the surrounding context (repo, task shape, prior state).

Verify an approved plan exists (in .claude/state/plans/ or the current conversation) (review-time: see section note)
If no plan exists, stop and ask the user to run /plan first (review-time: see section note)
Read the plan and identify the task list (review-time: see section note)
Load relevant expert agents based on the plan's domain (see rules/agent-routing.md) - their guardrails apply to every increment (review-time: see section note)
If the plan has 2+ file-isolated lanes, execute it in lane mode - spawn one lane-mode teammate per lane (see rules/parallel-agents.md); single-lane plans stay in this session (review-time: lane-vs-single judgment from the plan shape)

Increment Rules

For each task in the plan:

Ask: "What is the simplest thing that could work?" (review-time: see section note)
Scope: touch only what the task requires - no drive-by refactors, no "while I'm here" changes (review-time: see section note)
Follow rules/engineering-principles.md: vertical slicing, change sizing (~100 lines per commit, max 300, split at 1000+), and anti-rationalization rules all apply (review-time: see section note)
Compile continuously: the project must build after every increment. Run typecheck after each file change. (review-time: see section note)
Test alongside: write tests as part of the increment, not as a separate step afterward (review-time: see section note)
Checkpoint: after completing each task: (review-time: see section note)
- Run /verify-done (typecheck + lint + tests + build) - do not rely on post-edit hooks alone (review-time: see section note)
- If all pass, commit with a conventional commit message (review-time: see section note)
- If any fail, fix before moving to the next task - never accumulate errors across tasks (review-time: see section note)

Feature Flags

If the feature is large and will take multiple sessions:

Use a feature flag to keep incomplete work behind a toggle (review-time: see section note)
Each increment should be independently mergeable (behind the flag) (review-time: see section note)
The flag is removed only when the full feature is complete and tested (review-time: see section note)

Completion

After all tasks are done:

Run /verify-done one final time (review-time: see section note)
Summarize what was built and what changed (review-time: see section note)
Flag any deferred items or follow-up work as issues (review-time: see section note)