
build
by howells
Claude Code plugin. From idea to working implementation—explore, validate, plan, and build in one flow.
SKILL.md
name: build description: | Quick build for small-to-medium scope work without formal planning. Still uses TDD and verification. Use when asked to "build this", "add a quick feature", "make this change", or for straightforward implementation tasks that don't need extensive design work. license: MIT metadata: author: howells website: order: 7 desc: Quick implementation summary: Fast implementation for small-to-medium scope work without formal planning. what: | Build is for when the path is clear and you want to move fast. It still uses test-driven development and runs TypeScript checks after every change, but skips the formal planning phase that /arc:detail and /arc:implement require. why: | Not everything needs a plan document. Small features, bug fixes, and refactors benefit from momentum. Build gives you TDD discipline without bureaucratic overhead. decisions: - Tests first, always—even in 'quick' mode. No exceptions. - Type checks after every file change catch drift early. - No plan file means no audit trail. Use /arc:implement for anything you might need to explain later.
<rules_context> Check for project coding rules:
Use Glob tool: .ruler/*.md
If .ruler/ exists, detect stack and read relevant rules:
| Check | Read from .ruler/ |
|---|---|
| Always | code-style.md |
next.config.* exists | nextjs.md |
react in package.json | react.md |
tailwindcss in package.json | tailwind.md |
.ts or .tsx files | typescript.md |
vitest or jest in package.json | testing.md |
These rules define MUST/SHOULD/NEVER constraints. Follow them during implementation.
If .ruler/ doesn't exist: Continue without rules — they're optional.
For UI/frontend work, also load interface rules:
| Check | Read from ${CLAUDE_PLUGIN_ROOT}/rules/interface/ |
|---|---|
| Building components/pages | design.md, colors.md, spacing.md, layout.md |
| Typography changes | typography.md |
| Adding animations | animation.md, performance.md |
| Form work | forms.md, interactions.md |
| Interactive elements | interactions.md |
| Marketing pages | marketing.md |
Reference: ${CLAUDE_PLUGIN_ROOT}/references/frontend-design.md for fonts and anti-patterns.
Reference: ${CLAUDE_PLUGIN_ROOT}/references/component-design.md for React component patterns.
Reference: ${CLAUDE_PLUGIN_ROOT}/references/tailwind-v4.md for Tailwind v4 syntax (if using Tailwind).
</rules_context>
Build Workflow
Quick build for small-to-medium scope work. No formal plan, but still uses TDD and verification disciplines.
Announce at start: "I'm using the build skill for quick implementation with TDD."
Process
Step 1: Assess Scope
Read the request. Consider:
- How many files will this touch?
- How many distinct components/features?
- Are there complex interactions?
- Is there significant new architecture?
If scope is large (>5 files, multiple features, new patterns):
"This looks substantial. It would benefit from proper design and planning.
Want me to run /arc:ideate instead?"
Wait for response. If yes, invoke ideate workflow.
If scope is small/medium: Proceed to Step 2.
Step 1b: Consider Worktree
If not already on a feature branch:
git branch --show-current
If on main/master:
Use AskUserQuestion tool:
Question: "You're on main. Want to create a worktree for this work?"
Header: "Worktree"
Options:
1. "Yes, set up worktree" (Recommended) — Keeps main clean, easy rollback
2. "No, work on main" — Fine for trivial single-file fixes
If option 1: Follow ${CLAUDE_PLUGIN_ROOT}/disciplines/using-git-worktrees.md
If option 2: Proceed on main
Step 2: Quick Mental Model
Briefly outline (don't write a doc):
- What needs to change
- What order to do it
- What to test
Share with user: "Here's my approach: [2-3 bullets]. Sound right?"
Step 3: Build with TDD
Follow ${CLAUDE_PLUGIN_ROOT}/disciplines/test-driven-development.md:
For each piece:
- Write failing test
- Verify it fails
- Write minimal code to pass
- Verify it passes
- Refactor if needed
Step 4: Continuous Quality
After each implementation:
pnpm tsc --noEmit # TypeScript check
pnpm biome check . # Lint
Fix issues immediately.
Step 5: Verify Before Done
Follow ${CLAUDE_PLUGIN_ROOT}/disciplines/verification-before-completion.md:
- Run full test suite
- Check all tests pass
- Confirm no TypeScript errors
- Confirm no lint errors
Only then claim completion.
Step 5b: E2E Tests (If Any)
If e2e tests exist for the changed code:
Task Bash run_in_background: true: "Run e2e tests and report any failures"
Spawning a background task keeps verbose e2e output from filling context.
Step 5b: React/Next.js Performance Check (Optional)
For React/Next.js projects, if vercel-react-best-practices skill is available:
Skill vercel-react-best-practices: "Quick review of [component/feature] for performance issues"
Step 6: Offer Next Steps
Use AskUserQuestion tool:
Question: "Build complete. What's next?"
Header: "Next step"
multiSelect: false
Options:
1. "Verify test coverage" — Run /arc:test
2. "Document what we built" — Run /arc:document
3. "Add follow-up tasks" — Update /arc:tasklist
4. "Done for now" — End session
<progress_context>
Use Read tool: docs/progress.md (first 50 lines)
Check for related prior work. </progress_context>
<progress_append> After completing the build, append to progress journal:
## YYYY-MM-DD HH:MM — /arc:build
**Task:** [What was built]
**Outcome:** Complete
**Files:** [Key files created/modified]
**Decisions:**
- [Key decision if any]
**Next:** Continue working
---
</progress_append>
What Build is NOT
- Not for large features (use /arc:ideate)
- Not for exploratory work (use /arc:ideate)
- Not for things needing design review
- Not a shortcut to skip quality
スコア
総合スコア
リポジトリの品質指標に基づく評価
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
3ヶ月以内に更新がある
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
レビュー
レビュー機能は近日公開予定です