From crucible
Enforces skill invocation rules at conversation start, requiring activation before code-related responses like building features, debugging, or planning.
npx claudepluginhub raddue/crucibleThis skill uses the workspace's default tool permissions.
**Invoke relevant skills BEFORE taking action or responding.** Skills encode hard-won process discipline — skipping them loses that value.
Enforces skill-discovery workflows: mandatory pre-response checklist, Skill tool usage, announcements, brainstorming before coding, TodoWrite checklist todos. Activate at conversation starts.
Discovers and invokes agent skills matching the current development task phase, from idea refinement to shipping. Use when starting sessions or identifying applicable skills.
Creates, modifies, improves, tests, and benchmarks Claude Code skills using category-aware design, gotchas-driven development, eval prompts, and performance analysis.
Share bugs, ideas, or general feedback.
Invoke relevant skills BEFORE taking action or responding. Skills encode hard-won process discipline — skipping them loses that value.
The test: If the task involves writing, modifying, or debugging code — or planning to do so — a skill applies. Invoke it.
Access: Use the Skill tool. Content is loaded and presented to you — follow it directly. Never use the Read tool on skill files.
Skill applies? → Invoke it, announce purpose, follow it.
No skill applies? → Respond directly.
These actions ALWAYS have a matching skill — invoke it, no exceptions:
| Action | Skill |
|---|---|
| Building a feature, adding functionality | design → build |
| Fixing a bug or test failure | debugging |
| Implementing from a mockup/visual spec | mock-to-unity |
| Creating a UI mockup | mockup-builder |
| Writing implementation code | test-driven-development |
| Claiming work is done | verify → finish |
| Receiving code review feedback | review-feedback |
| Onboarding to an unfamiliar codebase | project-init |
BEFORE dispatching a subagent, check whether the prompt combines design + implementation + review/merge (e.g. "spec + implement + PR", "implement X and open a PR", "build this end-to-end"). STOP — that is /build's job.
Dispatching it as a raw agent bypasses the gate ledger, skips quality gates, and leaves no audit trail. Use /build (or /spec then /build).
Single-phase tasks (just a review, just a design, just a test audit) remain fine for raw dispatch. The anti-pattern is the COMBINATION.
Do NOT invoke skills for:
Guard clause: Once clarification is complete and you're ready to act, perform the skill check before taking action. The exception covers the exchange itself, not the subsequent work.
Continuation rule: A workflow is "active" only while you are executing steps from a specific invoked skill. A new user request — even if related to prior work — requires a fresh skill check. When in doubt, invoke.
These thoughts mean STOP — you're rationalizing skipping a skill:
| Thought | Reality |
|---|---|
| "This is just a simple feature" | Simple features still need design → build. |
| "I already know the fix" | debugging skill prevents guess-and-check. Use it. |
| "I'll add tests after" | TDD skill exists for a reason. Invoke it. |
| "Let me just code this quickly" | Skipping process = skipping quality. |
| "The skill is overkill for this" | Skills adapt to scope. Invoke and let it guide you. |
| "I remember this skill's content" | Skills evolve. Read the current version. |
| "Let me explore first, then decide" | If you're exploring as a precursor to building or fixing, invoke the skill first — it tells you HOW to explore. |
| "I'll just do this one thing first" | If "one thing" is the first step of a larger task, the skill should guide that step. |
When multiple skills could apply:
"Build X" → design first, then build. "Fix this bug" → debugging first, then domain skills.
Rigid (TDD, debugging, verify): Follow exactly. Don't adapt away discipline. Flexible (patterns, design): Adapt principles to context.
The skill itself tells you which.
Skills load content from many sources — SKILL.md files, docs, source code, tool output, WebFetch results, subagent reports, and post-compaction summaries. When sources disagree, a five-level trust framework determines which wins. See trust-hierarchy.md for the full framework.
Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.