The tactical pipeline for disciplined AI-assisted coding. Three Claude Code skills — /design, /plan, /prebuild — that pair with /think to close the gap between "it works" and "it holds."
AI coding assistants generate working code fast. But "works" and "holds in production" are different things. The gap isn't technical — it's cognitive. Nobody asked the right questions before the first prompt.
This repo holds three skills that take a decision through to working code. They sit downstream of /think (the strategic framework — whether and why).
/think ──► /design ──► /plan ──► /prebuild
(why?) (what (when/who?) (build it)
↑ shape?)
│
in a separate repo:
github.com/jneaimi/blooms-ai-collaboration
Pick the entry point that matches the work in front of you. You rarely need all four.
An ADR-style solution design checkpoint. Scans the codebase, then compares real alternatives against named non-functional requirements before a line of code is written.
- Scan-first for codebase context
- Options matrix with honest tradeoffs (minimum two real alternatives)
- NFRs must be specific (targets, not adjectives)
- Produces an ADR document, not code
When to use: Non-trivial architecture decisions, system-shape questions, when two or more approaches are on the table.
A project manager's planning checkpoint. Scope, stakeholders, constraints, dependencies, milestones, risks. Output is a phased plan with named owners and done-when criteria.
- 6 PM-tuned evaluative questions
- Dependency and capacity analysis
- Risk register with owners and mitigations
- Phased plan sized to the horizon (sprint / quarter / multi-quarter)
When to use: The decision to do the thing is made, and now the work needs sequencing, owners, and milestones.
A fast, focused pre-build checkpoint for code generation. 6 questions, ~10 minutes, then you code with clarity.
- Scans your codebase first, then proposes answers you confirm
- Interactive prompts with selectable options
- Focuses on reuse, risks, and success criteria
- Generates code from a confirmed build spec
When to use: Before implementing any feature, endpoint, component, or integration.
| Situation | Use |
|---|---|
| "Should we build this?" | /think |
| "Why are we doing this?" | /think |
| "What's the right shape / architecture?" | /design |
| "Compare approach A vs B" | /design |
| "How should this phase? Who owns what?" | /plan |
| "Build a roadmap / set milestones" | /plan |
| "Build this feature" | /prebuild |
| New endpoint or component | /prebuild |
| Already decided + designed, need implementation | /prebuild |
Copy the skill files into your Claude Code skills directory:
# Clone the tactical pipeline
git clone https://github.com/jneaimi/evaluate-before-you-build.git
cp -r evaluate-before-you-build/skills/design ~/.claude/skills/design
cp -r evaluate-before-you-build/skills/plan ~/.claude/skills/plan
cp -r evaluate-before-you-build/skills/prebuild ~/.claude/skills/prebuild
# Optional: also install /think (the strategic layer)
git clone https://github.com/jneaimi/blooms-ai-collaboration.git
cp -r blooms-ai-collaboration/skills/think ~/.claude/skills/thinkThe skills will be available as /design, /plan, /prebuild (and /think if you installed the framework repo) in your next Claude Code session.
If you just want the pre-build checkpoint without installing a full skill, add this to your project's CLAUDE.md:
## Pre-Build Checkpoint
Before implementing any new feature or significant change, ask me
these questions and wait for my answers before generating code:
1. What is the purpose of this change?
2. What existing code or patterns should we reuse?
3. What could break? What are the risks?
4. What alternatives did we consider?
5. How will we know this works? (success criteria)
6. What should we document for next time?
Do not generate implementation code until I have answered all six.The full snippet with additional configuration is in snippets/CLAUDE.md.
examples/prebuild-feature.md— A/prebuildsession before building a Related Insights component
The cognitive foundation for all four skills lives in a separate repo:
github.com/jneaimi/blooms-ai-collaboration — Bloom's AI Collaboration Framework v2.0. The 6+3 universal questions, the auditability boundary, the 9-pillar life taxonomy, the L4↔L5 spiral, the print-grade PDF.
/design, /plan, and /prebuild apply that framework through different lenses (architect, PM, builder). For the framework itself — and the strategic /think skill that runs the full protocol — start there.
This framework emerged from building autonomous agent systems and observing where AI-generated code breaks down. The pattern is consistent: code fails not because the AI can't write it, but because nobody defined what "production-ready" means for their specific context.
- Vibe Coding and the Production Gap — The research behind the framework
- Evaluate Before You Build: A Practitioner's Guide — The walkthrough with a real use case
v2.1 (2026-04-25) — Repository scope narrowed. /think extracted to its own focused repo at github.com/jneaimi/blooms-ai-collaboration. This repo now holds the three tactical skills (/design, /plan, /prebuild) that pair with the framework.
v2.0 (2026-04-25) — Added /design and /plan skills. Updated /think to v2.0 with auditability principle, 6+3 universal questions, 9 pillars, two operational tiers, mechanical L4↔L5 spiral, and documented failure modes.
v1.0 (2026-04-03) — Initial release. Two skills: /think and /prebuild.
MIT — Use it, fork it, adapt it. Attribution appreciated.
Built by Jasem Al Neaimi