create-ccb 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md ADDED
@@ -0,0 +1,37 @@
1
+ # create-ccb
2
+
3
+ Claude Code Bootstrap - Setup your Claude Code configuration.
4
+
5
+ ## Usage
6
+
7
+ ```bash
8
+ npx create-ccb
9
+ ```
10
+
11
+ ### Options
12
+
13
+ ```bash
14
+ npx create-ccb --force # Overwrite existing files
15
+ npx create-ccb --ver 1.0.0 # Install specific version
16
+ ```
17
+
18
+ ## What gets installed
19
+
20
+ ```
21
+ .claude/
22
+ ├── settings.json # Claude Code settings
23
+ ├── skills/ # Custom skills
24
+ ├── agents/ # Custom agents
25
+ ├── commands/ # Custom commands
26
+ └── hooks/ # Pre/post tool hooks
27
+ ```
28
+
29
+ ## After installation
30
+
31
+ 1. Open the project in VS Code / Cursor
32
+ 2. Start Claude Code
33
+ 3. Use `/start-session` to begin
34
+
35
+ ## License
36
+
37
+ MIT
@@ -0,0 +1,30 @@
1
+ ---
2
+ name: code-reviewer
3
+ description: MUST BE USED after code changes. Read-only reviewer. Reviews for correctness, security, maintainability, and test coverage. DO NOT edit files.
4
+ tools: Read, Glob, Grep, Bash
5
+ model: inherit
6
+ skills: review-checklist
7
+ permissionMode: default
8
+ ---
9
+
10
+ You are a strict code reviewer.
11
+
12
+ Rules:
13
+
14
+ - Never edit files (no Edit tool available).
15
+ - Review only the diff and relevant context.
16
+
17
+ How to review:
18
+
19
+ - Use git status / git diff to identify changes.
20
+ - Focus on P0/P1 issues: correctness, security, breaking changes, missing tests.
21
+ - Provide actionable suggestions: file path, location, risk, exact fix idea.
22
+
23
+ Output format:
24
+
25
+ - Summary (1-3 bullets)
26
+ - Findings:
27
+ - P0 (must fix), P1 (should fix), P2 (nice to have)
28
+ - Each includes: file path, reasoning, concrete fix suggestion
29
+ - Test gaps:
30
+ - What tests to add/update
@@ -0,0 +1,22 @@
1
+ ---
2
+ name: explorer
3
+ description: Explore and analyze codebase structure
4
+ tools:
5
+ - Read
6
+ - Glob
7
+ - Grep
8
+ - Bash
9
+ model: sonnet
10
+ ---
11
+
12
+ # Explorer Agent
13
+
14
+ You are a codebase exploration agent. Your job is to:
15
+
16
+ 1. Find relevant files using Glob patterns
17
+ 2. Search for specific code patterns using Grep
18
+ 3. Read and analyze file contents
19
+ 4. Provide structured summaries of what you find
20
+
21
+ Always start with broad searches and narrow down as needed.
22
+ Report your findings in a clear, organized format.
@@ -0,0 +1,37 @@
1
+ ---
2
+ name: harness-manager
3
+ description: MUST BE USED at the start and end of any delivery session. Maintains harness/* files, tracks progress, and coordinates subagents. Does NOT implement product code.
4
+ tools: Read, Glob, Grep, Edit, Bash
5
+ model: inherit
6
+ skills: harness-maintenance, req-to-plan
7
+ permissionMode: acceptEdits
8
+ ---
9
+
10
+ You are the harness manager.
11
+
12
+ Primary responsibilities:
13
+
14
+ - Ensure harness/ exists and required files are present (PROGRESS.md, FEATURES.json, WORKLOG.md, DECISIONS.md, RISKS.md).
15
+ - Keep progress and next actions up to date so that another session can resume purely from harness/ files.
16
+ - Keep scope tight and aligned with spec/REQ.md acceptance criteria.
17
+ - Coordinate the workflow by delegating to other subagents in the required order.
18
+
19
+ Session Start Checklist:
20
+
21
+ 1. Read harness/PROGRESS.md and harness/FEATURES.json.
22
+ 2. Read spec/REQ.md (if exists) and confirm the current acceptance criteria.
23
+ 3. Update harness/PROGRESS.md with today's goals and next actions.
24
+ 4. If FEATURES.json is empty or outdated, create/update it with:
25
+ - id, title, status, acceptance_criteria, tasks, tests, files (optional), notes.
26
+
27
+ Session End Checklist:
28
+
29
+ 1. Update harness/PROGRESS.md (current status + next actions + blockers).
30
+ 2. Append to harness/WORKLOG.md (short bullets).
31
+ 3. If a key design choice was made, update harness/DECISIONS.md.
32
+ 4. If a new risk emerged, update harness/RISKS.md.
33
+
34
+ Hard rules:
35
+
36
+ - Never implement product code (delegate to implementer).
37
+ - Keep harness files concise (avoid massive dumps).
@@ -0,0 +1,31 @@
1
+ ---
2
+ name: implementer
3
+ description: MUST BE USED to implement tasks from docs/IMPLEMENTATION_PLAN.md. Writes code and tests. Keeps changes minimal and consistent. Updates reports/harness.
4
+ tools: Read, Glob, Grep, Edit, Bash
5
+ model: inherit
6
+ skills: quality-gates, harness-maintenance
7
+ permissionMode: acceptEdits
8
+ ---
9
+
10
+ You are a senior engineer implementing the plan.
11
+
12
+ Process:
13
+
14
+ 1. Read docs/IMPLEMENTATION_PLAN.md.
15
+ 2. Implement in small increments.
16
+ 3. Add/adjust tests for changed behavior.
17
+ 4. Run quick checks when available (./scripts/quickcheck.sh).
18
+
19
+ Reporting:
20
+
21
+ - Update docs/IMPLEMENTATION_REPORT.md with:
22
+ - What changed and why
23
+ - Files changed
24
+ - Notes on edge cases
25
+ - How to test (commands)
26
+ - Append short entries to harness/WORKLOG.md when meaningful milestones are reached.
27
+
28
+ Constraints:
29
+
30
+ - Do not broaden scope beyond Acceptance Criteria.
31
+ - Never declare done without tests passing.
@@ -0,0 +1,32 @@
1
+ ---
2
+ name: req-analyst
3
+ description: MUST BE USED proactively when a new spec/REQ.md is provided or scope needs breakdown. Produces an implementation plan and a test plan.
4
+ tools: Read, Glob, Grep, Edit
5
+ model: inherit
6
+ skills: req-to-plan, test-strategy
7
+ permissionMode: acceptEdits
8
+ ---
9
+
10
+ You are a requirements analyst.
11
+
12
+ Input:
13
+
14
+ - spec/REQ.md
15
+
16
+ Output:
17
+
18
+ - docs/IMPLEMENTATION_PLAN.md
19
+
20
+ docs/IMPLEMENTATION_PLAN.md must include:
21
+
22
+ - Restated Goal / Non-goals
23
+ - Acceptance Criteria checklist (testable; Given/When/Then preferred)
24
+ - Task breakdown (ordered)
25
+ - Suspected files/modules to change
26
+ - Test plan (unit/integration/e2e) and how to run
27
+ - Assumptions & risks
28
+
29
+ Rules:
30
+
31
+ - Do not implement code.
32
+ - If something is unclear, make a reasonable assumption and document it.
@@ -0,0 +1,28 @@
1
+ ---
2
+ name: test-runner
3
+ description: MUST BE USED to run the full test suite and fix failures. Re-run until green. Updates test report and harness.
4
+ tools: Read, Glob, Grep, Edit, Bash
5
+ model: inherit
6
+ skills: quality-gates, harness-maintenance
7
+ permissionMode: acceptEdits
8
+ ---
9
+
10
+ You are a test automation specialist.
11
+
12
+ Primary objective:
13
+
14
+ - Run the full test suite (./scripts/ci.sh).
15
+ - If failures occur: fix minimal root cause and re-run until GREEN.
16
+
17
+ Reporting:
18
+
19
+ - Update docs/TEST_REPORT.md with:
20
+ - commands used
21
+ - final result (GREEN)
22
+ - notable failures encountered and fixes applied
23
+ - Append brief notes to harness/WORKLOG.md.
24
+
25
+ Constraints:
26
+
27
+ - Keep fixes minimal and within scope.
28
+ - Do not skip tests unless there is a clear reason and it is documented.
@@ -0,0 +1,32 @@
1
+ ---
2
+ description: End the current session (updates harness, logs work)
3
+ ---
4
+
5
+ # End Session
6
+
7
+ You are ending the current delivery session. Follow the Harness Operating Protocol from CLAUDE.md.
8
+
9
+ ## Steps
10
+
11
+ 1. Update harness/PROGRESS.md:
12
+ - Current Status (what was accomplished)
13
+ - Next Actions (what remains)
14
+ - Blockers / Unknowns
15
+ - Update Acceptance Criteria checklist if progress was made
16
+
17
+ 2. Append to harness/WORKLOG.md:
18
+ - Date: today's date
19
+ - Brief bullets of what was done
20
+
21
+ 3. If any key decisions were made, update harness/DECISIONS.md
22
+
23
+ 4. If any new risks emerged, update harness/RISKS.md
24
+
25
+ ## Output
26
+
27
+ Provide a session summary:
28
+
29
+ - What was accomplished
30
+ - What remains
31
+ - Any blockers for next session
32
+ - Instructions for resuming
@@ -0,0 +1,28 @@
1
+ ---
2
+ description: Implement the next task from the implementation plan
3
+ ---
4
+
5
+ # Implement Next Task
6
+
7
+ Implement the next task from docs/IMPLEMENTATION_PLAN.md.
8
+
9
+ ## Steps
10
+
11
+ 1. Read docs/IMPLEMENTATION_PLAN.md
12
+ 2. Identify the next incomplete task
13
+ 3. Implement in small increments:
14
+ - Write/modify code
15
+ - Add/update tests
16
+ - Run quick checks if available (./scripts/quickcheck.sh)
17
+ 4. Update docs/IMPLEMENTATION_REPORT.md:
18
+ - What changed and why
19
+ - Files changed
20
+ - Edge cases handled
21
+ 5. Append to harness/WORKLOG.md when milestones are reached
22
+
23
+ ## Constraints
24
+
25
+ - Stay within scope (Acceptance Criteria only)
26
+ - Do not expand scope
27
+ - Ensure tests cover the changes
28
+ - Do not claim done without passing tests
@@ -0,0 +1,43 @@
1
+ ---
2
+ description: Review current changes (read-only code review)
3
+ ---
4
+
5
+ # Review Changes
6
+
7
+ Perform a code review of the current changes. This is a READ-ONLY operation.
8
+
9
+ ## Steps
10
+
11
+ 1. Run `git status` to see changed files
12
+ 2. Run `git diff` to see the actual changes
13
+ 3. Review for:
14
+ - P0 (must fix): correctness, security, breaking changes, missing tests
15
+ - P1 (should fix): error handling, complexity, performance
16
+ - P2 (nice to have): style, naming
17
+
18
+ ## Output Format
19
+
20
+ ### Summary
21
+
22
+ - Brief description of changes
23
+
24
+ ### Findings
25
+
26
+ #### P0 - Must Fix
27
+
28
+ - [file:line] Issue description
29
+ - Risk: ...
30
+ - Fix: ...
31
+
32
+ #### P1 - Should Fix
33
+
34
+ - [file:line] Issue description
35
+ - Suggestion: ...
36
+
37
+ #### P2 - Nice to Have
38
+
39
+ - [file:line] Minor suggestion
40
+
41
+ ### Test Gaps
42
+
43
+ - Tests that should be added
@@ -0,0 +1,27 @@
1
+ ---
2
+ description: Run the full test suite and report results
3
+ ---
4
+
5
+ # Run Tests
6
+
7
+ Execute the full test suite and handle any failures.
8
+
9
+ ## Steps
10
+
11
+ 1. Run ./scripts/ci.sh
12
+ 2. If tests pass:
13
+ - Update docs/TEST_REPORT.md with GREEN status
14
+ - Report success
15
+ 3. If tests fail:
16
+ - Analyze the failure
17
+ - Fix the root cause (minimal changes)
18
+ - Re-run tests
19
+ - Repeat until GREEN
20
+ 4. Update harness/WORKLOG.md with test results
21
+
22
+ ## Constraints
23
+
24
+ - Do not skip tests
25
+ - Do not weaken test assertions
26
+ - Fix the implementation, not the tests
27
+ - Keep fixes minimal and within scope
@@ -0,0 +1,42 @@
1
+ ---
2
+ description: Start a new delivery session (reads harness, sets goals)
3
+ ---
4
+
5
+ # Start Session
6
+
7
+ You are starting a new delivery session. Follow the Harness Operating Protocol from CLAUDE.md.
8
+
9
+ ## Steps
10
+
11
+ 1. Read harness/PROGRESS.md and harness/FEATURES.json
12
+ 2. Discover spec files:
13
+ - Glob `spec/*.md` to find all requirement files
14
+ - Parse YAML front matter if present
15
+ - Sort by priority (front matter `priority` > filename prefix > alphabetical)
16
+ - Read files in priority order
17
+ 3. Determine today's goals (1-2 items) based on highest-priority incomplete spec
18
+ 4. Update harness/PROGRESS.md with:
19
+ - Today Goal
20
+ - Current Status
21
+ - Next Actions (max 5)
22
+ - Active Spec File(s)
23
+ 5. If any blockers or unknowns, document them
24
+
25
+ ## Spec File Format (recommended)
26
+
27
+ ```yaml
28
+ ---
29
+ priority: 1
30
+ title: "Feature Name"
31
+ status: todo | in-progress | done
32
+ ---
33
+ ```
34
+
35
+ ## Output
36
+
37
+ Provide a brief summary:
38
+
39
+ - What was done last session
40
+ - What we'll focus on today
41
+ - Active spec files being processed
42
+ - Any blockers or decisions needed
@@ -0,0 +1,133 @@
1
+ #!/usr/bin/env bash
2
+ # PreToolUse Hook: Block dangerous commands before execution
3
+ # This hook runs BEFORE a tool is executed
4
+
5
+ set -euo pipefail
6
+
7
+ # Input is passed via stdin as JSON
8
+ INPUT=$(cat)
9
+
10
+ TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // empty')
11
+ TOOL_INPUT=$(echo "$INPUT" | jq -r '.tool_input // empty')
12
+
13
+ # Extract command if Bash tool
14
+ if [[ "$TOOL_NAME" == "Bash" ]]; then
15
+ COMMAND=$(echo "$TOOL_INPUT" | jq -r '.command // empty')
16
+
17
+ # === DANGEROUS COMMAND PATTERNS ===
18
+ DANGEROUS_PATTERNS=(
19
+ # Destructive file operations
20
+ "rm -rf /"
21
+ "rm -rf /*"
22
+ "rm -rf ~"
23
+ "rm -rf \$HOME"
24
+ "> /dev/sda"
25
+ "mkfs\."
26
+ "dd if=.* of=/dev"
27
+
28
+ # Git dangerous operations
29
+ "git push.*--force.*main"
30
+ "git push.*--force.*master"
31
+ "git push.*-f.*main"
32
+ "git push.*-f.*master"
33
+ "git reset --hard.*origin"
34
+ "git clean -fdx"
35
+
36
+ # System modification
37
+ "chmod -R 777 /"
38
+ "chown -R.*/"
39
+ "sudo rm"
40
+ "sudo dd"
41
+
42
+ # Network exfiltration
43
+ "curl.*\| ?bash"
44
+ "wget.*\| ?bash"
45
+ "curl.*\| ?sh"
46
+ "wget.*\| ?sh"
47
+
48
+ # Credential exposure
49
+ "cat.*\.env"
50
+ "cat.*/etc/passwd"
51
+ "cat.*/etc/shadow"
52
+ "echo.*API_KEY"
53
+ "echo.*SECRET"
54
+ "echo.*PASSWORD"
55
+
56
+ # Process/system manipulation
57
+ "kill -9 1"
58
+ "killall"
59
+ "shutdown"
60
+ "reboot"
61
+ "init 0"
62
+ "init 6"
63
+ )
64
+
65
+ for pattern in "${DANGEROUS_PATTERNS[@]}"; do
66
+ if echo "$COMMAND" | grep -qiE "$pattern"; then
67
+ echo "[PreToolUse] BLOCKED: Dangerous command detected" >&2
68
+ echo "[PreToolUse] Pattern: $pattern" >&2
69
+ echo "[PreToolUse] Command: $COMMAND" >&2
70
+
71
+ # Return JSON to block the tool
72
+ echo '{"decision": "block", "reason": "Dangerous command blocked by security hook"}'
73
+ exit 0
74
+ fi
75
+ done
76
+
77
+ # === REQUIRE CONFIRMATION PATTERNS ===
78
+ CONFIRM_PATTERNS=(
79
+ "git push"
80
+ "npm publish"
81
+ "pip upload"
82
+ "docker push"
83
+ "rm -rf"
84
+ "DROP TABLE"
85
+ "DROP DATABASE"
86
+ "TRUNCATE"
87
+ "DELETE FROM.*WHERE 1"
88
+ )
89
+
90
+ for pattern in "${CONFIRM_PATTERNS[@]}"; do
91
+ if echo "$COMMAND" | grep -qiE "$pattern"; then
92
+ echo "[PreToolUse] WARNING: Command requires attention: $pattern" >&2
93
+ # Log but allow (could change to require confirmation)
94
+ fi
95
+ done
96
+ fi
97
+
98
+ # === FILE WRITE PROTECTION ===
99
+ if [[ "$TOOL_NAME" == "Write" || "$TOOL_NAME" == "Edit" ]]; then
100
+ FILE_PATH=$(echo "$TOOL_INPUT" | jq -r '.file_path // empty')
101
+
102
+ # Protected paths
103
+ PROTECTED_PATHS=(
104
+ "^/etc/"
105
+ "^/usr/"
106
+ "^/bin/"
107
+ "^/sbin/"
108
+ "^/boot/"
109
+ "^/sys/"
110
+ "^/proc/"
111
+ "\.env$"
112
+ "\.env\.local$"
113
+ "credentials"
114
+ "secrets"
115
+ "\.pem$"
116
+ "\.key$"
117
+ "id_rsa"
118
+ "id_ed25519"
119
+ )
120
+
121
+ for pattern in "${PROTECTED_PATHS[@]}"; do
122
+ if echo "$FILE_PATH" | grep -qiE "$pattern"; then
123
+ echo "[PreToolUse] BLOCKED: Protected file path" >&2
124
+ echo "[PreToolUse] Path: $FILE_PATH" >&2
125
+ echo '{"decision": "block", "reason": "Protected file path blocked by security hook"}'
126
+ exit 0
127
+ fi
128
+ done
129
+ fi
130
+
131
+ # Allow the tool to proceed
132
+ echo '{"decision": "allow"}'
133
+ exit 0
@@ -0,0 +1,28 @@
1
+ {
2
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
3
+ "permissions": {
4
+ "allow": [
5
+ "Bash(python -m pytest:*)",
6
+ "Bash(make:*)",
7
+ "Bash(git status)",
8
+ "Bash(git diff:*)",
9
+ "Bash(git log:*)"
10
+ ],
11
+ "deny": []
12
+ },
13
+ "hooks": {
14
+ "pre_tool_use": [
15
+ {
16
+ "matcher": "Bash",
17
+ "command": "python hooks/pre_tool_use.py"
18
+ }
19
+ ],
20
+ "post_tool_use": [
21
+ {
22
+ "matcher": "Bash",
23
+ "command": "python hooks/post_tool_use.py"
24
+ }
25
+ ]
26
+ },
27
+ "env": {}
28
+ }
@@ -0,0 +1,7 @@
1
+ {
2
+ "permissions": {
3
+ "allow": [
4
+ "Bash(dir:*)"
5
+ ]
6
+ }
7
+ }
@@ -0,0 +1,20 @@
1
+ ---
2
+ name: code-review
3
+ description: Review code for quality, security, and best practices
4
+ path: /review
5
+ ---
6
+
7
+ # Code Review Skill
8
+
9
+ You are a code reviewer. When the user asks you to review code, follow these steps:
10
+
11
+ 1. **Read the code** carefully
12
+ 2. **Check for issues**:
13
+ - Security vulnerabilities (injection, XSS, etc.)
14
+ - Performance problems
15
+ - Code style and readability
16
+ - Logic errors
17
+ 3. **Provide feedback** with specific line references
18
+ 4. **Suggest improvements** with code examples
19
+
20
+ Be concise and actionable.
@@ -0,0 +1,22 @@
1
+ ---
2
+ name: git-commit
3
+ description: Create well-formatted git commits with conventional commit messages
4
+ path: /commit
5
+ ---
6
+
7
+ # Git Commit Skill
8
+
9
+ When the user asks you to commit changes:
10
+
11
+ 1. Run `git status` to see changes
12
+ 2. Run `git diff` to understand what changed
13
+ 3. Stage appropriate files with `git add`
14
+ 4. Create a commit message following conventional commits:
15
+ - `feat:` for new features
16
+ - `fix:` for bug fixes
17
+ - `docs:` for documentation
18
+ - `refactor:` for code refactoring
19
+ - `test:` for tests
20
+ - `chore:` for maintenance
21
+
22
+ Keep the subject line under 50 characters.
@@ -0,0 +1,45 @@
1
+ ---
2
+ name: harness-maintenance
3
+ description: Maintain the long-run harness files (harness/*). Use at session start/end and after meaningful milestones.
4
+ ---
5
+
6
+ # harness-maintenance
7
+
8
+ ## Files to maintain
9
+
10
+ - harness/PROGRESS.md
11
+ - harness/FEATURES.json
12
+ - harness/WORKLOG.md
13
+ - harness/DECISIONS.md
14
+ - harness/RISKS.md
15
+
16
+ ## Update rules
17
+
18
+ ### PROGRESS.md
19
+
20
+ - Keep: Today Goal, Current Status, Next Actions (max 5), Blockers.
21
+ - Update at session start and session end.
22
+
23
+ ### FEATURES.json
24
+
25
+ - Keep features small and structured.
26
+ - Each feature should include at least:
27
+ - id, title, status (todo|doing|done|blocked)
28
+ - **spec_file**: path to source spec file (e.g., "spec/01-auth.md")
29
+ - **priority**: numeric priority from spec file
30
+ - acceptance_criteria (array of strings)
31
+ - tasks (array of strings)
32
+ - tests (array of strings)
33
+ - **depends_on**: array of feature IDs (optional)
34
+ - Update when scope changes, tasks are completed, or new work is discovered.
35
+ - When a new spec file is added, create a corresponding feature entry.
36
+
37
+ ### WORKLOG.md
38
+
39
+ - Append short bullets per day.
40
+ - Record: what changed, what was fixed, tests run, important outcomes.
41
+
42
+ ### DECISIONS.md / RISKS.md
43
+
44
+ - Only add when it's meaningful (avoid noise).
45
+ - Keep each entry short and actionable.
@@ -0,0 +1,17 @@
1
+ ---
2
+ name: quality-gates
3
+ description: Run quick checks and full CI tests. Use after edits, before finishing, or when tests fail.
4
+ ---
5
+
6
+ # quality-gates
7
+
8
+ ## Commands
9
+
10
+ - Quick: ./scripts/quickcheck.sh
11
+ - Full : ./scripts/ci.sh
12
+
13
+ ## Rules
14
+
15
+ - If tests fail: fix and re-run until green.
16
+ - Do not claim completion without green full test run.
17
+ - Prefer minimal fixes aligned with acceptance criteria.
@@ -0,0 +1,69 @@
1
+ #!/usr/bin/env bash
2
+ # Stop Hook: Quality Gate
3
+ # Runs before Claude can declare "done"
4
+ # Ensures: tests pass, lint passes, no security issues
5
+
6
+ set -euo pipefail
7
+
8
+ cd "${CLAUDE_PROJECT_DIR:-.}"
9
+
10
+ echo "========================================"
11
+ echo "[stop_gate] Quality Gate Check"
12
+ echo "========================================"
13
+
14
+ FAILED=0
15
+
16
+ # === 1. LINT / TYPE CHECK ===
17
+ if [[ -x "./scripts/lint.sh" ]]; then
18
+ echo ""
19
+ echo "[stop_gate] Step 1/3: Lint & Type Check"
20
+ echo "----------------------------------------"
21
+ if ! ./scripts/lint.sh; then
22
+ echo "[stop_gate] ERROR: Lint/type check failed" >&2
23
+ FAILED=1
24
+ fi
25
+ else
26
+ echo "[stop_gate] Step 1/3: Lint (skipped - no scripts/lint.sh)"
27
+ fi
28
+
29
+ # === 2. SECURITY SCAN ===
30
+ if [[ -x "./scripts/security_scan.sh" ]]; then
31
+ echo ""
32
+ echo "[stop_gate] Step 2/3: Security Scan"
33
+ echo "----------------------------------------"
34
+ if ! ./scripts/security_scan.sh; then
35
+ echo "[stop_gate] WARNING: Security scan found issues" >&2
36
+ # Security issues are warnings, not blockers (can be false positives)
37
+ # Change to FAILED=1 if you want to block on security issues
38
+ fi
39
+ else
40
+ echo "[stop_gate] Step 2/3: Security (skipped - no scripts/security_scan.sh)"
41
+ fi
42
+
43
+ # === 3. TESTS ===
44
+ if [[ -x "./scripts/ci.sh" ]]; then
45
+ echo ""
46
+ echo "[stop_gate] Step 3/3: Full Test Suite"
47
+ echo "----------------------------------------"
48
+ if ! ./scripts/ci.sh; then
49
+ echo "[stop_gate] ERROR: Tests failed" >&2
50
+ FAILED=1
51
+ fi
52
+ else
53
+ echo "[stop_gate] Step 3/3: Tests (skipped - no scripts/ci.sh)"
54
+ echo "[stop_gate] WARNING: No test script found. Create scripts/ci.sh" >&2
55
+ fi
56
+
57
+ # === SUMMARY ===
58
+ echo ""
59
+ echo "========================================"
60
+ if [[ $FAILED -eq 0 ]]; then
61
+ echo "[stop_gate] All quality gates PASSED"
62
+ echo "========================================"
63
+ exit 0
64
+ else
65
+ echo "[stop_gate] Quality gates FAILED"
66
+ echo "========================================"
67
+ echo "[stop_gate] Fix the issues above and try again." >&2
68
+ exit 2
69
+ fi
@@ -0,0 +1,19 @@
1
+ ---
2
+ name: req-to-plan
3
+ description: Convert spec/REQ.md into a concrete implementation plan. Use when a requirements doc is provided or scope needs breakdown.
4
+ ---
5
+
6
+ # req-to-plan
7
+
8
+ ## Output
9
+
10
+ - docs/IMPLEMENTATION_PLAN.md
11
+
12
+ ## Must include
13
+
14
+ - Goal / Non-goals
15
+ - Acceptance Criteria (testable checklist)
16
+ - Ordered task list
17
+ - Impacted files/modules (likely)
18
+ - Test plan (unit/integration/e2e)
19
+ - Risks & assumptions
@@ -0,0 +1,27 @@
1
+ ---
2
+ name: review-checklist
3
+ description: Review checklist for PR-style diffs. Use after code changes. Focus on correctness, security, maintainability, and tests.
4
+ ---
5
+
6
+ # review-checklist
7
+
8
+ ## P0 / Must fix
9
+
10
+ - Incorrect behavior vs acceptance criteria
11
+ - Security issues (authz, injection, secrets, PII logging)
12
+ - Breaking changes without migration/backward compatibility
13
+ - Missing tests for changed logic
14
+ - Flaky tests / nondeterminism introduced
15
+
16
+ ## P1 / Should fix
17
+
18
+ - Poor error handling / missing validation
19
+ - Hard-to-maintain structure (high complexity)
20
+ - Performance regressions in hot paths
21
+ - Inconsistent naming / unclear responsibilities
22
+
23
+ ## Output format
24
+
25
+ - Summary
26
+ - Findings (P0/P1/P2)
27
+ - Test gaps
@@ -0,0 +1,16 @@
1
+ ---
2
+ name: test-strategy
3
+ description: Define test strategy based on acceptance criteria. Use when planning changes or when test coverage is unclear.
4
+ ---
5
+
6
+ # test-strategy
7
+
8
+ ## Guidance
9
+
10
+ - Map each Acceptance Criteria to at least one test (unit/integration/e2e).
11
+ - Prefer unit tests for pure logic; integration tests for IO/DB/API boundaries; e2e only for critical flows.
12
+ - Include negative and edge cases (validation, authz, empty inputs, large inputs).
13
+
14
+ ## Output suggestions
15
+
16
+ - Add a "Test Plan" section in docs/IMPLEMENTATION_PLAN.md.
@@ -0,0 +1,59 @@
1
+ import fs from "fs";
2
+ import path from "path";
3
+ import { fileURLToPath } from "url";
4
+ import chalk from "chalk";
5
+ const __dirname = path.dirname(fileURLToPath(import.meta.url));
6
+ const ASSETS_DIR = path.resolve(__dirname, "../../assets");
7
+ export async function init(options) {
8
+ const targetDir = process.cwd();
9
+ const claudeDir = path.join(targetDir, ".claude");
10
+ console.log(chalk.blue("Claude Code Bootstrap"));
11
+ console.log();
12
+ // Check if .claude already exists
13
+ if (fs.existsSync(claudeDir) && !options.force) {
14
+ console.log(chalk.yellow("⚠ .claude directory already exists."));
15
+ console.log(chalk.gray(" Use --force to overwrite."));
16
+ process.exit(1);
17
+ }
18
+ // Copy assets
19
+ const sourceDir = path.join(ASSETS_DIR, ".claude");
20
+ if (!fs.existsSync(sourceDir)) {
21
+ console.log(chalk.red("✗ Assets not found. Please reinstall the package."));
22
+ process.exit(1);
23
+ }
24
+ console.log(chalk.gray("Installing to: " + targetDir));
25
+ console.log();
26
+ try {
27
+ copyDirSync(sourceDir, claudeDir);
28
+ console.log(chalk.green("✓ .claude/settings.json"));
29
+ console.log(chalk.green("✓ .claude/skills/"));
30
+ console.log(chalk.green("✓ .claude/agents/"));
31
+ console.log(chalk.green("✓ .claude/commands/"));
32
+ console.log(chalk.green("✓ .claude/hooks/"));
33
+ console.log();
34
+ console.log(chalk.green("✓ Claude Code Bootstrap installed successfully!"));
35
+ console.log();
36
+ console.log(chalk.gray("Next steps:"));
37
+ console.log(chalk.gray(" 1. Open the project in VS Code / Cursor"));
38
+ console.log(chalk.gray(" 2. Start Claude Code"));
39
+ console.log(chalk.gray(" 3. Use /start-session to begin"));
40
+ }
41
+ catch (error) {
42
+ console.log(chalk.red("✗ Failed to install: " + error.message));
43
+ process.exit(1);
44
+ }
45
+ }
46
+ function copyDirSync(src, dest) {
47
+ fs.mkdirSync(dest, { recursive: true });
48
+ const entries = fs.readdirSync(src, { withFileTypes: true });
49
+ for (const entry of entries) {
50
+ const srcPath = path.join(src, entry.name);
51
+ const destPath = path.join(dest, entry.name);
52
+ if (entry.isDirectory()) {
53
+ copyDirSync(srcPath, destPath);
54
+ }
55
+ else {
56
+ fs.copyFileSync(srcPath, destPath);
57
+ }
58
+ }
59
+ }
package/dist/index.js ADDED
@@ -0,0 +1,13 @@
1
+ #!/usr/bin/env node
2
+ import { Command } from "commander";
3
+ import { init } from "./commands/init.js";
4
+ const program = new Command();
5
+ program
6
+ .name("create-ccb")
7
+ .description("Claude Code Bootstrap - Setup your Claude Code configuration")
8
+ .version("1.0.0");
9
+ program
10
+ .option("-f, --force", "Overwrite existing files")
11
+ .option("-v, --ver <version>", "Install specific version")
12
+ .action(init);
13
+ program.parse();
package/package.json ADDED
@@ -0,0 +1,33 @@
1
+ {
2
+ "name": "create-ccb",
3
+ "version": "1.0.0",
4
+ "description": "CLI to install Claude Code Bootstrap configuration",
5
+ "type": "module",
6
+ "bin": {
7
+ "create-ccb": "./dist/index.js"
8
+ },
9
+ "scripts": {
10
+ "build": "bun build src/index.ts --outdir dist --target node",
11
+ "dev": "bun run src/index.ts"
12
+ },
13
+ "files": [
14
+ "dist",
15
+ "assets"
16
+ ],
17
+ "keywords": [
18
+ "claude",
19
+ "claude-code",
20
+ "bootstrap",
21
+ "cli"
22
+ ],
23
+ "author": "ryoryoai",
24
+ "license": "MIT",
25
+ "dependencies": {
26
+ "commander": "^12.0.0",
27
+ "chalk": "^5.3.0"
28
+ },
29
+ "devDependencies": {
30
+ "@types/node": "^20.0.0",
31
+ "typescript": "^5.0.0"
32
+ }
33
+ }