rebar-mcp 2.0.0

package/.claude/skills/test-skill/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: test-skill
+description: A test skill
+invocation: undefined
+context: undefined
+---
+
+## Test Writing Process
+
+### Step 1: Analyze What Needs Testing
+- Read the function/module signature, parameters, and return type
+- Identify the happy path (normal successful execution)
+- Identify error paths (what can go wrong?)
+- Identify edge cases (empty input, null, boundary values, max values)
+- Identify integration points (database calls, API calls, file system)
+
+### Step 2: Write Tests in This Order
+
+1. **Happy path test** — The most basic successful case
+2. **Input validation tests** — Invalid inputs, missing required fields, wrong types
+3. **Edge case tests** — Empty arrays, zero values, very long strings, special characters
+4. **Error handling tests** — Network failures, database errors, file not found
+5. **Integration tests** — Full request/response cycle (if applicable)
+
+### Step 3: Test Structure
+
+Every test MUST follow this structure:
+
+```
+// Descriptive name that explains what is being tested and expected outcome
+test("createUser returns the created user with a generated ID when given valid input", async () => {
+  // ARRANGE: Set up test data and dependencies
+  const input = { name: "Test User", email: "test@example.com" };
+
+  // ACT: Execute the function under test
+  const result = await createUser(input);
+
+  // ASSERT: Verify the outcome
+  expect(result.id).toBeDefined();
+  expect(result.name).toBe("Test User");
+  expect(result.email).toBe("test@example.com");
+});
+```
+
+### Mandatory Test Categories
+
+For EVERY function, write tests covering:
+
+| Category | Example | Required? |
+|---|---|---|
+| Valid input, expected output | Normal successful operation | ALWAYS |
+| Missing required field | Omit a required parameter | ALWAYS |
+| Invalid type | Pass string where number expected | ALWAYS |
+| Empty input | Empty string, empty array, null | ALWAYS |
+| Boundary values | 0, -1, MAX_INT, very long string | WHEN APPLICABLE |
+| Duplicate/conflict | Creating something that already exists | WHEN APPLICABLE |
+| Not found | Requesting something that does not exist | WHEN APPLICABLE |
+| Unauthorized | Accessing without proper permissions | WHEN AUTH EXISTS |
+| Concurrent access | Two operations on same resource | WHEN APPLICABLE |
+| Error recovery | Service dependency fails | WHEN EXTERNAL DEPS EXIST |
+
+### Rules
+- Test file names MUST match source file: `user.service.ts` → `user.service.test.ts`
+- NEVER test implementation details — test behavior and outcomes
+- NEVER use `test("should work")` — test names must describe the specific scenario and expected outcome
+- EVERY test must be independent — no test should depend on another test running first
+- ALWAYS clean up test data (use beforeEach/afterEach or setup/teardown)
+- Mock external dependencies (databases, APIs, file system) — do not make real network calls in unit tests
+- NEVER write a test that always passes — verify your test fails before the implementation exists

package/.claude/skills/test; rm -rf /; skill/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: test; rm -rf /; skill
+description: A test skill
+invocation: undefined
+context: undefined
+---
+
+## Test Writing Process
+
+### Step 1: Analyze What Needs Testing
+- Read the function/module signature, parameters, and return type
+- Identify the happy path (normal successful execution)
+- Identify error paths (what can go wrong?)
+- Identify edge cases (empty input, null, boundary values, max values)
+- Identify integration points (database calls, API calls, file system)
+
+### Step 2: Write Tests in This Order
+
+1. **Happy path test** — The most basic successful case
+2. **Input validation tests** — Invalid inputs, missing required fields, wrong types
+3. **Edge case tests** — Empty arrays, zero values, very long strings, special characters
+4. **Error handling tests** — Network failures, database errors, file not found
+5. **Integration tests** — Full request/response cycle (if applicable)
+
+### Step 3: Test Structure
+
+Every test MUST follow this structure:
+
+```
+// Descriptive name that explains what is being tested and expected outcome
+test("createUser returns the created user with a generated ID when given valid input", async () => {
+  // ARRANGE: Set up test data and dependencies
+  const input = { name: "Test User", email: "test@example.com" };
+
+  // ACT: Execute the function under test
+  const result = await createUser(input);
+
+  // ASSERT: Verify the outcome
+  expect(result.id).toBeDefined();
+  expect(result.name).toBe("Test User");
+  expect(result.email).toBe("test@example.com");
+});
+```
+
+### Mandatory Test Categories
+
+For EVERY function, write tests covering:
+
+| Category | Example | Required? |
+|---|---|---|
+| Valid input, expected output | Normal successful operation | ALWAYS |
+| Missing required field | Omit a required parameter | ALWAYS |
+| Invalid type | Pass string where number expected | ALWAYS |
+| Empty input | Empty string, empty array, null | ALWAYS |
+| Boundary values | 0, -1, MAX_INT, very long string | WHEN APPLICABLE |
+| Duplicate/conflict | Creating something that already exists | WHEN APPLICABLE |
+| Not found | Requesting something that does not exist | WHEN APPLICABLE |
+| Unauthorized | Accessing without proper permissions | WHEN AUTH EXISTS |
+| Concurrent access | Two operations on same resource | WHEN APPLICABLE |
+| Error recovery | Service dependency fails | WHEN EXTERNAL DEPS EXIST |
+
+### Rules
+- Test file names MUST match source file: `user.service.ts` → `user.service.test.ts`
+- NEVER test implementation details — test behavior and outcomes
+- NEVER use `test("should work")` — test names must describe the specific scenario and expected outcome
+- EVERY test must be independent — no test should depend on another test running first
+- ALWAYS clean up test data (use beforeEach/afterEach or setup/teardown)
+- Mock external dependencies (databases, APIs, file system) — do not make real network calls in unit tests
+- NEVER write a test that always passes — verify your test fails before the implementation exists

package/.claude/skills/test<script>alert(1)</script>skill/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: test<script>alert(1)</script>skill
+description: A test skill
+invocation: undefined
+context: undefined
+---
+
+## Test Writing Process
+
+### Step 1: Analyze What Needs Testing
+- Read the function/module signature, parameters, and return type
+- Identify the happy path (normal successful execution)
+- Identify error paths (what can go wrong?)
+- Identify edge cases (empty input, null, boundary values, max values)
+- Identify integration points (database calls, API calls, file system)
+
+### Step 2: Write Tests in This Order
+
+1. **Happy path test** — The most basic successful case
+2. **Input validation tests** — Invalid inputs, missing required fields, wrong types
+3. **Edge case tests** — Empty arrays, zero values, very long strings, special characters
+4. **Error handling tests** — Network failures, database errors, file not found
+5. **Integration tests** — Full request/response cycle (if applicable)
+
+### Step 3: Test Structure
+
+Every test MUST follow this structure:
+
+```
+// Descriptive name that explains what is being tested and expected outcome
+test("createUser returns the created user with a generated ID when given valid input", async () => {
+  // ARRANGE: Set up test data and dependencies
+  const input = { name: "Test User", email: "test@example.com" };
+
+  // ACT: Execute the function under test
+  const result = await createUser(input);
+
+  // ASSERT: Verify the outcome
+  expect(result.id).toBeDefined();
+  expect(result.name).toBe("Test User");
+  expect(result.email).toBe("test@example.com");
+});
+```
+
+### Mandatory Test Categories
+
+For EVERY function, write tests covering:
+
+| Category | Example | Required? |
+|---|---|---|
+| Valid input, expected output | Normal successful operation | ALWAYS |
+| Missing required field | Omit a required parameter | ALWAYS |
+| Invalid type | Pass string where number expected | ALWAYS |
+| Empty input | Empty string, empty array, null | ALWAYS |
+| Boundary values | 0, -1, MAX_INT, very long string | WHEN APPLICABLE |
+| Duplicate/conflict | Creating something that already exists | WHEN APPLICABLE |
+| Not found | Requesting something that does not exist | WHEN APPLICABLE |
+| Unauthorized | Accessing without proper permissions | WHEN AUTH EXISTS |
+| Concurrent access | Two operations on same resource | WHEN APPLICABLE |
+| Error recovery | Service dependency fails | WHEN EXTERNAL DEPS EXIST |
+
+### Rules
+- Test file names MUST match source file: `user.service.ts` → `user.service.test.ts`
+- NEVER test implementation details — test behavior and outcomes
+- NEVER use `test("should work")` — test names must describe the specific scenario and expected outcome
+- EVERY test must be independent — no test should depend on another test running first
+- ALWAYS clean up test data (use beforeEach/afterEach or setup/teardown)
+- Mock external dependencies (databases, APIs, file system) — do not make real network calls in unit tests
+- NEVER write a test that always passes — verify your test fails before the implementation exists

package/.claudeignore

@@ -0,0 +1,5 @@
+node_modules/
+dist/
+.git/
+*.lock
+coverage/

package/.mcp.json

@@ -0,0 +1,3 @@
+{
+  "mcpServers": {}
+}

package/CHANGELOG.md

@@ -0,0 +1,29 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+## [2.0.0] - 2026-03-09
+
+### Breaking Changes
+- Renamed from `ccboot-mcp-server` to `rebar-mcp`
+- All tool names changed from `ccboot_*` to `rebar_*`
+- Package name changed to `rebar-mcp`
+- Binary name changed to `rebar`
+
+### Added
+- **Multi-platform support:** Generates configurations for Claude Code, Cursor, Windsurf, and Codex CLI
+- **Strictness profiles:** Standard (notify), Strict (block on test/lint failures), Paranoid (block on any types, file size, TODOs)
+- **`rebar doctor`:** 10-point health check for enforcement setup
+- **Standalone CLI:** `rebar init`, `rebar audit`, `rebar doctor`, `rebar metrics`, `rebar badge` commands
+- **CI/CD integration:** `rebar audit --threshold` exits with code 1 for pipeline gating
+- **Quality score tracking:** `.rebar/metrics.json` stores score history with trend analysis
+- **Quality score badge:** SVG badge generation for README embedding
+- **Custom rules engine:** `.rebar/rules.yaml` for project-specific quality rules
+- **`rebar_add_rule` tool:** Add custom rules via MCP or CLI
+- **`rebar_set_strictness` tool:** Change enforcement profile without re-initializing
+- **`rebar_metrics` tool:** View quality score trends and improvement rate
+
+### Changed
+- `rebar_init_project` now generates config for all detected AI coding platforms
+- `rebar_audit` (formerly `ccboot_audit_code_quality`) now supports custom rules and auto-generates metrics snapshots
+- All templates updated to include platform-specific formatting for Cursor and Windsurf

package/CLAUDE.md

@@ -0,0 +1,76 @@
+# rebar-mcp
+
+## Project Overview
+Reinforcement for AI-generated code. An MCP server that generates, validates, and manages Claude Code configuration artifacts (CLAUDE.md, skills, agents, hooks, commands, MCP configs, knowledge docs) with enforcement hooks that prevent AI coding tools from shipping broken code.
+
+## Tech Stack
+- TypeScript (strict mode) targeting ES2022
+- Node.js 18+ runtime
+- @modelcontextprotocol/sdk for MCP server
+- Zod for input validation
+- stdio transport (primary), streamable HTTP (secondary)
+
+## Architecture Rules
+- ALWAYS use server.registerTool() (never deprecated server.tool())
+- All tool names use rebar_ prefix with snake_case
+- All Zod schemas use .strict() enforcement
+- No use of `any` type — use `unknown` or proper types
+- All async functions have explicit Promise<T> return types
+- Log to stderr ONLY (stdout is reserved for MCP protocol)
+- Never use console.log() — use console.error() for debug output
+- All file writes are atomic (write to temp, then rename)
+- Never overwrite files without checking merge_existing flag
+
+## Tool Annotations
+Every tool MUST include annotations:
+- readOnlyHint: true for read operations, false for writes
+- destructiveHint: false (we never delete without explicit request)
+- idempotentHint: true if re-running produces same result
+- openWorldHint: false (we only touch local filesystem)
+
+## File Structure
+- src/index.ts          — Entry point, server init, transport
+- src/types.ts          — Shared TypeScript interfaces
+- src/constants.ts      — Enums, defaults, limits
+- src/tools/*.ts        — Tool implementations (one file per domain)
+- src/services/*.ts     — Shared utilities (file ops, templates, validation)
+- src/schemas/*.ts      — Zod schemas
+- templates/**/*.md     — Raw template files
+
+## Build & Test
+- Build: `npm run build` (must pass with zero errors)
+- Lint: `npx tsc --noEmit`
+- Test: `npm run test`
+- Dev: `npx tsx src/index.ts` (for local MCP testing)
+
+## Template Conventions
+- Variables: `{{variable_name}}` (double curly braces)
+- Conditionals: `{{#if condition}}...{{/if}}`
+- Templates are plain markdown with substitution markers
+- All generated YAML must parse cleanly
+- All generated JSON must be valid
+- Skills MUST have name (max 64 chars) and description (max 200 chars)
+
+## Code Quality
+- Extract common functionality into src/services/
+- DRY: if logic appears twice, extract to a function
+- Every tool description includes: purpose, args, return schema, examples
+- Error messages suggest next steps (not just what failed)
+- No hardcoded paths — use path.join() and respect project_path input
+
+## MCP Server Best Practices
+- Use Zod schemas with .describe() on every field for self-documenting APIs
+- Tool descriptions must include: purpose summary, all args with types, return schema with field descriptions, 2-3 usage examples, and error handling notes
+- Support both JSON and Markdown response formats where applicable
+- Paginate list results with has_more, next_offset, total_count
+- Return { isError: true, content: [...] } for recoverable errors with actionable suggestions
+
+## Implementation Priority
+1. src/index.ts + transport setup
+2. src/services/ (file-ops, template-engine, validation)
+3. src/types.ts + src/constants.ts + src/schemas/
+4. src/tools/scaffolding.ts (init_project, generate_claudemd, create_skill, create_agent, create_hook, create_command)
+5. templates/ (CLAUDE.md templates, skill templates, agent templates, hook templates)
+6. src/tools/knowledge.ts (create_knowledge, create_adr)
+7. src/tools/management.ts (list_artifacts, validate_config, audit_context)
+8. src/tools/enterprise.ts (apply_compliance, create_ci_workflow, create_security_hook, generate_mcp_config)

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Ryan Colkitt
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,149 @@
+# Rebar
+
+**Reinforcement for AI-generated code.**
+
+Rebar prevents AI coding tools from shipping broken, incomplete, or insecure code. It embeds enforcement hooks, quality audits, and opinionated templates directly into your development environment — catching shortcuts at the moment of creation, not after the PR is opened.
+
+Works with: **Claude Code** • **Cursor** • **Windsurf** • **Codex CLI**
+
+![Rebar Quality Score](.rebar/badge.svg)
+
+---
+
+## What Rebar Does
+
+| Problem | Without Rebar | With Rebar |
+|---------|---------------|------------|
+| Claude skips tests | "I've completed the implementation" (no tests run) | Hook runs tests after every file change. Strict mode blocks until tests pass. |
+| Empty catch blocks | Errors silently swallowed | Audit detects and flags every empty catch block |
+| `any` types everywhere | TypeScript without type safety | Paranoid mode blocks files containing `any` |
+| Incomplete implementations | TODO comments shipped to production | Paranoid mode blocks commits with TODO/FIXME |
+| Hardcoded secrets | API keys in source code | Pre-commit hook detects and blocks secret patterns |
+| Destructive commands | `rm -rf /` | Pre-execution hook blocks dangerous commands |
+| Inconsistent setup | Every developer configures differently | One `rebar init` standardizes the entire team |
+
+---
+
+## Quick Start
+
+### As an MCP Server (Claude Code)
+
+```bash
+claude mcp add rebar -- npx rebar-mcp
+```
+
+Then in Claude Code:
+```
+> Initialize Rebar with strict enforcement
+```
+
+### As a CLI
+
+```bash
+# Initialize a project
+npx rebar-mcp init --strictness strict --platforms all
+
+# Audit code quality
+npx rebar-mcp audit --threshold 70
+
+# Check setup health
+npx rebar-mcp doctor
+```
+
+### In CI/CD
+
+```yaml
+# .github/workflows/rebar.yml
+- run: npx rebar-mcp audit --threshold 70 --format json
+```
+
+---
+
+## Strictness Profiles
+
+| Profile | Tests | Lint | Secrets | Danger | File Size | `any` Types | TODOs |
+|---------|-------|------|---------|--------|-----------|-------------|-------|
+| **Standard** | ⚠️ Notify | ⚠️ Notify | 🛑 Block | 🛑 Block | — | — | — |
+| **Strict** | 🛑 Block | 🛑 Block | 🛑 Block | 🛑 Block | — | — | — |
+| **Paranoid** | 🛑 Block | 🛑 Block | 🛑 Block | 🛑 Block | 🛑 Block >400 lines | 🛑 Block | 🛑 Block |
+
+```bash
+# Set strictness
+npx rebar-mcp set-strictness paranoid
+```
+
+---
+
+## What Gets Generated
+
+Running `rebar init` creates:
+
+**Claude Code:** CLAUDE.md, .claude/settings.json (enforcement hooks), .claude/skills/ (5 skills), .claude/agents/ (4 agents), .claudeignore
+
+**Cursor:** .cursor/rules/ (project rules + 4 skill rules)
+
+**Windsurf:** .windsurf/rules/ (project rules + 4 skill rules)
+
+**Codex CLI:** AGENTS.md
+
+---
+
+## Quality Audit
+
+```bash
+npx rebar-mcp audit
+```
+
+Checks for:
+1. TODO/FIXME/HACK/XXX comments
+2. Empty catch blocks
+3. `any` type usage
+4. console.log in production code
+5. Files over 400 lines
+6. Functions over 50 lines
+7. Hardcoded secrets
+8. Custom rules (.rebar/rules.yaml)
+
+Returns a quality score from 0–100.
+
+---
+
+## Custom Rules
+
+Add project-specific rules in `.rebar/rules.yaml`:
+
+```yaml
+rules:
+  - name: no-direct-axios
+    description: "Use the API client in src/lib/api.ts"
+    pattern: "import.*from ['\"]axios['\"]"
+    severity: HIGH
+    file_patterns: ["*.ts", "*.tsx"]
+    exclude_files: ["src/lib/api.ts"]
+```
+
+---
+
+## Metrics
+
+```bash
+npx rebar-mcp metrics --period 30d
+```
+
+Tracks quality score over time with trend analysis and improvement rate.
+
+---
+
+## Doctor
+
+```bash
+npx rebar-mcp doctor
+```
+
+Runs 10 health checks on your Rebar setup: CLAUDE.md presence, hook installation, skill configuration, context budget, cross-platform consistency, and more.
+
+---
+
+## License
+
+MIT