ClaudeKit is not a standalone app or a new IDE. It is an advanced Framework integrated directly into your native Claude Code configuration (.claude) on your machine, transforming your terminal chat into a professional task automation system.
Background scripts that run automatically. They initialize configs and project rules so you don't have to copy-paste them manually.
Specialized knowledge packages (SKILL.md) with prompts, references and scripts. The primary execution unit when you type /ck:* commands.
Specialized models (Planner, Tester, Reviewer) with internal prompts and tools, focusing on a single task domain.
Pipelines of Hooks, Skills and Agents running sequentially from your command input to handle complex workflows end-to-end.
Let's see how Hooks, Skills, Agents and Workflows coordinate a real command. Pick a workflow below and press Play to explore the internal mechanism.
VividKit is finalizing the detailed guide for Marketing Kit.
steps •
No combos for this kit
VividKit is finalizing the detailed guide for Marketing Kit.
Quick Ref / Brainstorm command
Before /ck:plan
Use it when the right approach is still unclear. Scout first, lock exact requirements, debate trade-offs, then write a report and hand off to /ck:plan.
Scout
Exact reqs
Debate
Report path
Scout first
Summarize 3-6 findings before Discovery.
Report first
The plan handoff receives the brainstorm report path.
No Task-spawn
planner/docs-manager are inline consultation.
Four lanes: scout, clarify, evaluate, then close with report/handoff.
Scout
Context before questions
Clarify
Lock the 5 exact fields
Evaluate
Trade-offs and brutal honesty
Handoff
Report, then plan/end
Use different prompts for a new brainstorm, a same-session plan handoff, and a fresh-session plan.
/ck:brainstorm Choose the best auth approach for our current SaaS app Use when: The direction is unclear and needs repo scouting plus trade-off debate first.
Expected: Writes the report at plans/reports/brainstorm-260524-1908-auth-approach.md.
/ck:plan Create an implementation plan for the auth approach we selected in brainstorm, using the report just created as context Use when: You are still inside the brainstorm session and the agent just wrote the report.
Expected: Plan uses current context plus the report path handed off by brainstorm.
/ck:plan plans/reports/brainstorm-260524-1908-auth-approach.md Use when: After a long brainstorm, start a fresh session to avoid context bloat.
Expected: Mention the file path so plan reads the correct brainstorm artifact.
Inside the brainstorm session, offer only after proposal approval, no open questions, and a written report. If starting a fresh session, make sure the brainstorm artifact exists and pass its file path to plan.
/ck:plan --tdd Recommend when: Refactor, critical logic, or strong existing test contracts.
Result: Same session: use the report context just created. Fresh session: include the artifact path.
/ck:plan Recommend when: Standard new feature or moderate change.
Result: Phase-by-phase implementation plan from the brainstorm report.
End session Recommend when: Plan later or hand off elsewhere.
Result: Stop after report/journal.
Markdown Summary Report
Brainstorm ends with one Markdown file. This file is the primary context for the /ck:plan handoff.
Concrete path
plans/reports/brainstorm-YYMMDD-HHMM-slug.md plans/reports/brainstorm-260524-1908-auth-approach.md Report Contents
This is the outline inside the report file, not separate artifacts.
Source: SKILL.md / Anti-Rationalization
Common-sounding excuses that SKILL.md blocks before planning or coding.
Thought
This is too simple to need a design
Reality
Simple work wastes time when assumptions stay implicit.
Thought
I already know the solution
Reality
Then writing it down is quick. The written design is the alignment checkpoint.
Thought
The user wants action, not talk
Reality
Bad action wastes more time than a short planning loop.
Thought
Let me explore the code first
Reality
Brainstorming decides how to explore. Follow the process first.
Thought
I'll just prototype quickly
Reality
Prototypes become production code. Design first.
Quick Ref / Planning command
After brainstorm / when scope is clear
Use it when the brief is clear enough to split into phases, validation gates, and a clean /ck:cook handoff.
handoff
/ck:cook {absolute-path}
Clear brief
Plan phases
Validate / red-team
/ck:cook
No implementation
Only creates plan and phase files.
Clear handoff
Ends with validate, red-team, cook, or stop.
Four lanes: orient scope, research, stress test, then hand off.
Orient
Set context before planning
Research
Collect enough evidence
Stress Test
Find weak points early
Handoff
Make the plan executable
Start with auto. Escalate only when scope or risk demands it.
--auto Auto-detect Sample prompt
/ck:plan Redesign checkout flow to reduce payment failures Use when
The brief is clear, but the right planning depth is not obvious.
Expected
The agent chooses research, validation, and red-team depth by risk.
--fast Fast Sample prompt
/ck:plan --fast Change the CTA copy in the Pricing section Use when
The task is small, low-dependency, and easy to roll back.
Expected
A quick plan without heavy research, red-team, or validation.
--hard Hard Sample prompt
/ck:plan --hard Refactor auth flow while preserving backward compatibility Use when
There are real technical constraints, but not a per-phase deep refactor.
Expected
Research and red-team catch architectural risk early.
--deep Deep Sample prompt
/ck:plan --deep Split billing into subscription, invoice, webhook modules Use when
The refactor is large, dependency-heavy, and touches multiple modules.
Expected
Deeper research, stronger validation, and evidence-backed phases.
--parallel Parallel Sample prompt
/ck:plan --parallel Optimize dashboard loading and chart rendering Use when
The work can be split into independent tracks.
Expected
Clear boundaries that can be handed to cook with --parallel.
--two Two approaches Sample prompt
/ck:plan --two Choose an offline-first data sync architecture Use when
Two approaches must be compared before committing to a plan.
Expected
Both approaches are analyzed first, then one direction is selected.
Combine with a mode to change how the plan handles tests or tasks.
--tdd Tests-first per phase
Composable flag: adds tests-first structure to each phase.
Sample prompt
/ck:plan --deep --tdd Refactor the billing module Use when
--deep --tdd is the main combo for major refactors or logic with important contracts.
--no-tasks Skip task hydration
Do not create Claude Tasks after the plan is generated.
Sample prompt
/ck:plan --fast --no-tasks Update guide copy Use when
Best for small or docs-only plans where extra task creation is not needed yet.
Compose With Modes
--tdd can combine with any mode, but pick the mode from scope first.
--hard --tdd Complex, needs research
Use when the task is complex but not a major multi-area refactor.
--deep --tdd Recommended Recommended for risky refactors
Use for large refactors, 5+ areas, architectural debt, or per-phase scouting.
--parallel --tdd Niche: parallel + tests-first
Use only when independent workstreams can run in parallel and each lane still needs test gates.
--deep --tdd → Quick Ref / Implementation command
After /ck:plan or feature brief
Use it when a plan or feature brief must become working code. Scout first, lock 5 requirements, pass plan gates, implement, test, review, then sync plan/docs/git/journal.
Plan path / brief
Scout + reqs
Code + test
Review + sync
Plan-first
Even small work needs plan review before code.
Scout-first
Summarize 3-6 repo findings before any AskUser.
No side effects
Acceptance, tests, contracts, lint/type/build must stay clean.
Four lanes: orient intent, create an evidence-backed plan, implement/test, then review and sync artifacts.
Orient
Mode, scout, requirements
Plan
Research + plan review
Build
Implement, simplify, test
Close
Review, sync, journal
Interactive is the default. Use flags to skip research, auto-approve, run in parallel, or execute an existing plan path.
plan path Code mode
Skip scout/research/plan and execute existing phase files.
Prompt
/ck:cook /abs/plans/260524-auth/plan.md Use when: A reviewed plan was produced by /ck:plan or handed off from another session.
Expected: Reads phase files, implements each phase, then tests/reviews/finalizes.
--fast Fast
Skip heavy research but still run scout -> plan -> code.
Prompt
/ck:cook --fast Change CTA copy in Pricing Use when: Small scope, easy rollback, few dependencies.
Expected: Short plan with user gates still held before code.
--auto Auto
Auto-approve low-risk work when artifacts + validator pass; high-risk changes still stop for user approval before finalize/commit/ship.
Prompt
/ck:cook --auto Add cache to the stats endpoint Use when: You trust the agent, risk is low, and acceptance is clear.
Expected: Runs low-risk phases continuously while still testing and reviewing; score is advisory, never approves on its own.
--parallel Parallel
Split independent features into separate lanes.
Prompt
/ck:cook --parallel Implement search, filters, export CSV Use when: 3+ workstreams have clear file ownership.
Expected: Multi-agent lanes merge through review gates.
/ck:cook /abs/plans/260524-auth/plan.md Use when: A plan.md and phase files already exist.
Expected: Uses plan context instead of rediscovering the task.
/ck:cook Add email/password login with httpOnly session Use when: No plan exists, but the desired output is clear.
Expected: Scout -> 5 requirements -> research/plan -> implement.
/ck:cook --tdd Refactor billing calculation while preserving behavior Use when: Refactor or critical logic.
Expected: Tests current behavior first, then verifies after implementation.
Implementation Complete
Commits + plan status synced + journal entry Code merged via git-manager
Tests 100% pass
code-reviewer approved (no regression, contracts intact)
plan.md + all phase-XX.md status synced via /ck:project-management
docs updated
/ck:journal entry recorded
Thought
This is simple, just code it
Reality
Simple tasks still hide contracts. Planning is cheaper than rewriting.
Thought
Ask the user before reading the repo
Reality
AskUser options must come from scout findings, not generic questions.
Thought
Tests pass, done
Reality
Touchpoints, contracts, lint/type/build, and code-review still have to clear.
Quick Ref / Review command
After /ck:cook or /ck:fix, before /ck:ship
Use it when code needs adversarial-rigor review. Resolve input mode, pass the spec-compliance gate, scout edge cases, run the code-reviewer sub-agent, then let the adversarial red-team actively try to break the code before verify + report.
Input + diff
Spec gate
Quality + scout
Adversarial + report
Spec-first gate
Stage 1 must pass — never skip to Stage 2 with spec mismatch.
Adversarial always-on
Stage 3 red-team runs every time. Scope gate exempts only trivial.
Fresh evidence
No "done" claim without rerunning tests/build with new output.
Four lanes: resolve input + diff, pass the spec gate, run quality review with scout, then adversarial red-team + verify + report.
Resolve
Input mode + diff acquisition
Spec gate
Stage 1 — code matches plan/spec?
Quality
Scout edge cases + Stage 2 code-reviewer
Adversarial + Prove
Stage 3 red-team, verify, report
Input mode picks the review target. Pick ONE — agent auto-detects from the argument, or AskUserQuestion when ambiguous. No "fast/auto" flag — every mode runs through all 3 stages.
#123 PR mode
Fetch full PR diff via gh pr diff #N.
Prompt
/ck:code-review #123 Use when: Reviewing an open GitHub PR.
Expected: Full PR diff → 3-stage review → APPROVE / REQUEST CHANGES / BLOCK recommendation.
--pending Pending
Review staged + unstaged changes in the working tree.
Prompt
/ck:code-review --pending Use when: Before commit, right after /ck:cook or /ck:fix.
Expected: git diff (staged + unstaged) → 3-stage review → inline findings.
abc1234 Commit
Review a specific commit via git show <sha>.
Prompt
/ck:code-review abc1234 Use when: Auditing an old commit, post-mortem regression.
Expected: That commit's diff → 3-stage review scoped to the commit.
codebase parallel Codebase parallel
Ultrathink edge cases, then spawn adversarial reviewers in parallel.
Prompt
/ck:code-review codebase parallel Use when: Deep audits — security review, pre-launch hardening.
Expected: Multiple scoped reviewers, dedupe + prioritize by severity.
/ck:code-review --pending Use when: Just finished /ck:cook or /ck:fix, not yet committed.
Expected: Reviews all staged + unstaged before commit / ship.
/ck:code-review #42 Use when: PR is open, needs adversarial review before merge.
Expected: Findings grouped by severity + verdict per item.
/ck:code-review codebase parallel Use when: Pre-launch or whole-project security audit.
Expected: Multiple scoped reviewers, severity-dedupe in the report.
Adversarial Review Report
Findings grouped by severity (Critical / Important / Minor) + verdict per finding + merge recommendation Each finding: description, file:line, severity, verdict (Accept / Reject / Defer)
Critical → BLOCK merge
Deferred → GitHub issue
Recommendation: APPROVE | REQUEST CHANGES | BLOCK
Verification gate (tests + build) MUST pass before report finalizes
Thought
Code compiles → review passes
Reality
Stage 1 spec compliance must verify intent matches plan/spec — compile says nothing.
Thought
Small diff, just skim it
Reality
Adversarial Stage 3 is still mandatory unless the scope gate hits (≤2 files, ≤30 lines, no security).
Thought
Tests pass = safe to merge
Reality
Critical findings still block merge. Need fresh build + test evidence — no "should/probably".
Quick Ref / Fix command
Bug, failing CI, regression, production issue
Use it when a failure needs an evidence-based repair. Pick mode, scout first, diagnose root cause, fix the cause, verify/prevent, review, then finalize.
Mode
Scout + diagnose
Root-cause fix
Verify + prevent
Root cause first
No symptom patches, no probably.
Exact repro
Capture pre-fix failure and rerun the same path.
Prevention
Regression test, blast-radius sweep, guards against recurrence.
Four lanes: mode/scout, root-cause diagnosis, targeted repair, then verify/prevent + finalize.
Start
Mode + scout evidence
Diagnose
RCA with file:line
Repair
Address the root cause
Prove
Verify, prevent, finalize
Autonomous is the default. Use review for high risk, quick only for tiny lint/type fixes, and parallel for independent issues.
--auto Autonomous
Auto-approve only when artifacts + validator pass.
Prompt
/ck:fix --auto login button returns 500 Use when: The bug is clear, risk is low/moderate, and verification is straightforward.
Expected: Still runs scout/diagnose/review before finalize.
--review Human review
Pause at each step for user approval.
Prompt
/ck:fix --review webhook duplicate charge Use when: Production, billing, auth, data loss, or public contract risk.
Expected: Stops after diagnosis/fix/verify with concrete findings.
--quick Quick
Scout -> diagnose -> fix -> lighter review.
Prompt
/ck:fix --quick TypeScript error in pricing card Use when: Trivial lint/type/single-file issue.
Expected: Faster cycle without skipping root-cause checks.
--parallel Parallel
One fullstack-developer lane per independent issue.
Prompt
/ck:fix --parallel checkout errors and dashboard chart crash Use when: 2+ independent failures with separate touchpoints.
Expected: Separate task trees; main agent surfaces cross-issue conflicts.
/ck:fix Login submit returns 500 in local dev Use when: Let the agent choose mode and scout the repo.
Expected: Mode -> Scout -> Diagnose -> Root-cause fix -> Verify.
/ck:fix --review Payment webhook double-charges paid orders Use when: You want a user gate at every step.
Expected: No finalize/commit before user approval.
/ck:fix --quick npm run build fails after latest merge Use when: Build/type/lint failure appears small.
Expected: Fast repair while rerunning the exact failing command.
Bug Fix Report
Step markers + confidence score + journal entry Root cause cited file:line
Fix targeted
Regression test added
Blast-radius swept
Prevention guards in place
Plan/tasks synced
Docs updated
Journal recorded
Thought
I can see the bug, just fix it
Reality
Seeing symptoms is not root cause. Scout + diagnose first.
Thought
Try changing X and see
Reality
Random fixes create new bugs. Build an evidence chain.
Thought
Fixed, tests pass
Reality
The prevention gate still needs to stop this bug class from recurring.
Quick Ref / Team orchestration
Parallel multi-session
Use it to spawn N independent Claude Code teammates in parallel — research from multiple angles, cook many files, review multiple focuses, or debug competing hypotheses.
Invoke
Pre-flight
Spawn N
Synth + close
Four lanes: setup pre-flight, parallel spawn, event-driven coordination, then synthesize and close.
Setup
Invoke + pre-flight check
Spawn
Derive N + spawn in parallel
Coordinate
Hooks + teammate DM
Close
Synthesize + shutdown
Pick a template by need. Each one has its own default N, behaviour, and artifact.
research Default N: 3 Research from N angles
Sample prompt
/ck:team research Compare auth strategies for our SaaS app Use when
Architecture decisions, technology evaluation, multi-angle investigation.
Output
research-summary-<slug>.md — exec summary, comparative analysis, recommendations.
cook Default N: 4 devs + 1 tester Cook with file-owned devs
Sample prompt
/ck:team cook plans/.../plan.md --devs 4 --worktree Use when
Multi-file feature implementation with parallel devs in isolated worktrees.
Output
Merged branches via git merge --no-ff + MANDATORY docs sync eval + test results.
review Default N: 3 Review N focuses
Sample prompt
/ck:team review src/api --reviewers 3 Use when
Pre-merge review with security, performance, and test-coverage lanes in parallel.
Output
review-<slug>.md — severity-dedupe (CRITICAL / IMPORTANT / MODERATE) + action items.
debug Default N: 3 Debug competing hypotheses
Sample prompt
/ck:team debug "Webhook returns 500 intermittently" --debuggers 3 Use when
Hard-to-reproduce bugs where you want adversarial disproof to converge on root cause.
Output
debug-<slug>.md — root cause + evidence chain + disproven hypotheses.
Per-Template Report
Lead synthesizes the report after every teammate finishes. Fixed location at plans/reports/.
research-summary / cook merge+docs / review-<slug> / debug-<slug>.md These five rules apply to every template — violating them breaks team execution.
Quick Ref / Visual utility
Read-only · never modifies code
View files or generate visual explanations, diagrams, and slide decks — in the browser or as a self-contained HTML page. A read/visualize utility that never modifies code.
Input
Route
Generate
Output
One input (file path or generate flag + topic) runs through four stages: receive, route, generate, then emit to the browser or a self-contained HTML page.
Receive
File path or generate flag + topic
Route + generate
Pick a shape, build prose + ASCII + Mermaid
Emit
Live browser or self-contained HTML
View (no flag) takes a path to read/walk through a file. Eight flags in three groups: Generate picks an output shape from a topic; --html wraps any generate flag into a standalone page; the Review group requires --html.
View · no flag
Read an existing file/dir — plans in novel UI
<file.md> View one markdown file (plan, phase, doc) in the novel-reader UI — Mermaid renders live.
Sample prompt
/ck:preview plans/.../plan.md <dir/> Pass a folder to browse every doc inside — e.g. a whole plan folder (plan.md + all phase files).
Sample prompt
/ck:preview plans/260527-.../ <path> View reads the file as-is. Contrast with generate flags (--explain / --diagram / --slides / --ascii): they take a topic in plain words and build a new visual — not a path.
Sample prompt
/ck:preview src/auth/middleware.ts Generate
Pick one output shape from a topic
--explain Visual explanation of code or a concept — narrative + ASCII + Mermaid diagrams
Sample prompt
/ck:preview --explain "auth middleware flow" --diagram Architecture and data-flow diagrams
Sample prompt
/ck:preview --diagram "request lifecycle" --slides Step-by-step walkthrough as a slide deck
Sample prompt
/ck:preview --slides "onboarding flow" --ascii Terminal-friendly ASCII diagram (no browser needed)
Sample prompt
/ck:preview --ascii "folder structure" Output
Composes with any generate flag
--html Self-contained HTML page — composes with any generate flag, opens directly in browser
Sample prompt
/ck:preview --html --diagram "DB schema" Review · implies --html
Diff, plan-vs-code, and recap views
--diff [ref] Visual diff review of changes (requires --html)
Sample prompt
/ck:preview --diff HEAD~3 --plan-review [plan-file] Compare a plan file against the actual codebase — implies --html. Omit the path to use the active plan.
Sample prompt
/ck:preview --plan-review plans/.../plan.md Omit path → active plan
/ck:preview --plan-review --recap [timeframe] Project context snapshot over a timeframe (requires --html)
Sample prompt
/ck:preview --recap "last week" Which modes need a local server, which are self-contained.
Local server
markdown-novel-viewer
Self-contained
No server — opens in browser
/ck:preview --stop {slug}.md (browser) · {slug}.html (self-contained){plan_dir}/visuals/ plans/visuals/ With an active plan, visuals live inside that plan folder. No plan → falls back to plans/visuals/.
Five rules that shape how preview behaves — always safe, always shareable.
Keyboard: Space = Play/Pause · ← → = Prev/Next step