arboris-cli 1.0.0 → 1.1.0

package/prisma/skills/codebase-onboarding/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: codebase-onboarding
+description: Analyze an unfamiliar codebase and generate a structured onboarding guide with architecture map, key entry points, conventions, and a starter CLAUDE.md. Use when joining a new project or setting up Claude Code for the first time in a repo.
+metadata:
+  origin: ECC
+---
+
+# Codebase Onboarding
+
+Systematically analyze an unfamiliar codebase and produce a structured onboarding guide. Designed for developers joining a new project or setting up Claude Code in an existing repo for the first time.
+
+## When to Use
+
+- First time opening a project with Claude Code
+- Joining a new team or repository
+- User asks "help me understand this codebase"
+- User asks to generate a CLAUDE.md for a project
+- User says "onboard me" or "walk me through this repo"
+
+## How It Works
+
+### Phase 1: Reconnaissance
+
+Gather raw signals about the project without reading every file. Run these checks in parallel:
+
+```
+1. Package manifest detection
+   → package.json, go.mod, Cargo.toml, pyproject.toml, pom.xml, build.gradle,
+     Gemfile, composer.json, mix.exs, pubspec.yaml
+
+2. Framework fingerprinting
+   → next.config.*, nuxt.config.*, angular.json, vite.config.*,
+     django settings, flask app factory, fastapi main, rails config
+
+3. Entry point identification
+   → main.*, index.*, app.*, server.*, cmd/, src/main/
+
+4. Directory structure snapshot
+   → Top 2 levels of the directory tree, ignoring node_modules, vendor,
+     .git, dist, build, __pycache__, .next
+
+5. Config and tooling detection
+   → .eslintrc*, .prettierrc*, tsconfig.json, Makefile, Dockerfile,
+     docker-compose*, .github/workflows/, .env.example, CI configs
+
+6. Test structure detection
+   → tests/, test/, __tests__/, *_test.go, *.spec.ts, *.test.js,
+     pytest.ini, jest.config.*, vitest.config.*
+```
+
+### Phase 2: Architecture Mapping
+
+From the reconnaissance data, identify:
+
+**Tech Stack**
+- Language(s) and version constraints
+- Framework(s) and major libraries
+- Database(s) and ORMs
+- Build tools and bundlers
+- CI/CD platform
+
+**Architecture Pattern**
+- Monolith, monorepo, microservices, or serverless
+- Frontend/backend split or full-stack
+- API style: REST, GraphQL, gRPC, tRPC
+
+**Key Directories**
+Map the top-level directories to their purpose:
+
+<!-- Example for a React project — replace with detected directories -->
+```
+src/components/  → React UI components
+src/api/         → API route handlers
+src/lib/         → Shared utilities
+src/db/          → Database models and migrations
+tests/           → Test suites
+scripts/         → Build and deployment scripts
+```
+
+**Data Flow**
+Trace one request from entry to response:
+- Where does a request enter? (router, handler, controller)
+- How is it validated? (middleware, schemas, guards)
+- Where is business logic? (services, models, use cases)
+- How does it reach the database? (ORM, raw queries, repositories)
+
+### Phase 3: Convention Detection
+
+Identify patterns the codebase already follows:
+
+**Naming Conventions**
+- File naming: kebab-case, camelCase, PascalCase, snake_case
+- Component/class naming patterns
+- Test file naming: `*.test.ts`, `*.spec.ts`, `*_test.go`
+
+**Code Patterns**
+- Error handling style: try/catch, Result types, error codes
+- Dependency injection or direct imports
+- State management approach
+- Async patterns: callbacks, promises, async/await, channels
+
+**Git Conventions**
+- Branch naming from recent branches
+- Commit message style from recent commits
+- PR workflow (squash, merge, rebase)
+- If the repo has no commits yet or only a shallow history (e.g. `git clone --depth 1`), skip this section and note "Git history unavailable or too shallow to detect conventions"
+
+### Phase 4: Generate Onboarding Artifacts
+
+Produce two outputs:
+
+#### Output 1: Onboarding Guide
+
+```markdown
+# Onboarding Guide: [Project Name]
+
+## Overview
+[2-3 sentences: what this project does and who it serves]
+
+## Tech Stack
+<!-- Example for a Next.js project — replace with detected stack -->
+| Layer | Technology | Version |
+|-------|-----------|---------|
+| Language | TypeScript | 5.x |
+| Framework | Next.js | 14.x |
+| Database | PostgreSQL | 16 |
+| ORM | Prisma | 5.x |
+| Testing | Jest + Playwright | - |
+
+## Architecture
+[Diagram or description of how components connect]
+
+## Key Entry Points
+<!-- Example for a Next.js project — replace with detected paths -->
+- **API routes**: `src/app/api/` — Next.js route handlers
+- **UI pages**: `src/app/(dashboard)/` — authenticated pages
+- **Database**: `prisma/schema.prisma` — data model source of truth
+- **Config**: `next.config.ts` — build and runtime config
+
+## Directory Map
+[Top-level directory → purpose mapping]
+
+## Request Lifecycle
+[Trace one API request from entry to response]
+
+## Conventions
+- [File naming pattern]
+- [Error handling approach]
+- [Testing patterns]
+- [Git workflow]
+
+## Common Tasks
+<!-- Example for a Node.js project — replace with detected commands -->
+- **Run dev server**: `npm run dev`
+- **Run tests**: `npm test`
+- **Run linter**: `npm run lint`
+- **Database migrations**: `npx prisma migrate dev`
+- **Build for production**: `npm run build`
+
+## Where to Look
+<!-- Example for a Next.js project — replace with detected paths -->
+| I want to... | Look at... |
+|--------------|-----------|
+| Add an API endpoint | `src/app/api/` |
+| Add a UI page | `src/app/(dashboard)/` |
+| Add a database table | `prisma/schema.prisma` |
+| Add a test | `tests/` matching the source path |
+| Change build config | `next.config.ts` |
+```
+
+#### Output 2: Starter CLAUDE.md
+
+Generate or update a project-specific CLAUDE.md based on detected conventions. If `CLAUDE.md` already exists, read it first and enhance it — preserve existing project-specific instructions and clearly call out what was added or changed.
+
+```markdown
+# Project Instructions
+
+## Tech Stack
+[Detected stack summary]
+
+## Code Style
+- [Detected naming conventions]
+- [Detected patterns to follow]
+
+## Testing
+- Run tests: `[detected test command]`
+- Test pattern: [detected test file convention]
+- Coverage: [if configured, the coverage command]
+
+## Build & Run
+- Dev: `[detected dev command]`
+- Build: `[detected build command]`
+- Lint: `[detected lint command]`
+
+## Project Structure
+[Key directory → purpose map]
+
+## Conventions
+- [Commit style if detectable]
+- [PR workflow if detectable]
+- [Error handling patterns]
+```
+
+## Best Practices
+
+1. **Don't read everything** — reconnaissance should use Glob and Grep, not Read on every file. Read selectively only for ambiguous signals.
+2. **Verify, don't guess** — if a framework is detected from config but the actual code uses something different, trust the code.
+3. **Respect existing CLAUDE.md** — if one already exists, enhance it rather than replacing it. Call out what's new vs existing.
+4. **Stay concise** — the onboarding guide should be scannable in 2 minutes. Details belong in the code, not the guide.
+5. **Flag unknowns** — if a convention can't be confidently detected, say so rather than guessing. "Could not determine test runner" is better than a wrong answer.
+
+## Anti-Patterns to Avoid
+
+- Generating a CLAUDE.md that's longer than 100 lines — keep it focused
+- Listing every dependency — highlight only the ones that shape how you write code
+- Describing obvious directory names — `src/` doesn't need an explanation
+- Copying the README — the onboarding guide adds structural insight the README lacks
+
+## Examples
+
+### Example 1: First time in a new repo
+**User**: "Onboard me to this codebase"
+**Action**: Run full 4-phase workflow → produce Onboarding Guide + Starter CLAUDE.md
+**Output**: Onboarding Guide printed directly to the conversation, plus a `CLAUDE.md` written to the project root
+
+### Example 2: Generate CLAUDE.md for existing project
+**User**: "Generate a CLAUDE.md for this project"
+**Action**: Run Phases 1-3, skip Onboarding Guide, produce only CLAUDE.md
+**Output**: Project-specific `CLAUDE.md` with detected conventions
+
+### Example 3: Enhance existing CLAUDE.md
+**User**: "Update the CLAUDE.md with current project conventions"
+**Action**: Read existing CLAUDE.md, run Phases 1-3, merge new findings
+**Output**: Updated `CLAUDE.md` with additions clearly marked

package/prisma/skills/codehealth-mcp/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: codehealth-mcp
+description: Real-time structural Code Health via CodeScene MCP — review before edits, verify score deltas after changes, gate commits and PRs. Use when reviewing code quality, refactoring, checking if AI changes degraded a file, or before commit/PR.
+metadata:
+  origin: community
+---
+
+# Code Health MCP (CodeScene)
+
+Structural maintainability feedback for AI-assisted coding. Complements style/lint skills (`coding-standards`, `plankton-code-quality`) with **design-level** health scores and regression gates.
+
+**Upstream:** [codescene-oss/codescene-mcp-server](https://github.com/codescene-oss/codescene-mcp-server)
+**Package:** `@codescene/codehealth-mcp` (stdio via npx)
+
+## Security and boundaries
+
+**Opt-in (ECC):** The `codescene` block in `mcp-configs/mcp-servers.json` is a template only. ECC plugin installs do not auto-enable bundled MCP servers. Copy the entry into your config only if you want it. You can exclude it during ECC install/sync with `ECC_DISABLED_MCPS=codescene,...`.
+
+**Credentials:** No bundled token. Set `CS_ACCESS_TOKEN` yourself (see [getting-a-personal-access-token.md](https://github.com/codescene-oss/codescene-mcp-server/blob/main/docs/getting-a-personal-access-token.md) in the upstream repo). Never commit tokens to the repo.
+
+**What the tools read:** When invoked, tools analyze files and git state **in the local repository** you point them at (paths you pass, plus branch context for `analyze_change_set`). They do not run by themselves. For standalone mode, follow upstream privacy docs: [codescene-mcp-server README](https://github.com/codescene-oss/codescene-mcp-server#frequently-asked-questions) and [CodeScene policies](https://codescene.com/policies). Do not use this skill for secrets, credentials, or paths you do not want analyzed.
+
+**If the MCP is unavailable (offline, bad token, server crash):** Do not invent Code Health scores. Tell the user the check was skipped. Continue only with explicit user approval. Prefer lint/tests/verification-loop for gating when MCP is down. Re-enable checks once the server connects.
+
+## When to Use
+
+- User asks to **review code quality**, **refactor** a file, or check if **AI changes degraded** maintainability
+- Before editing a **hotspot**, legacy module, or unfamiliar file
+- Before **commit** or **pull request** when you need a maintainability safeguard
+- After a large agent-written diff — verify Code Health did not regress
+- Pair with `verification-loop`, `tdd-workflow`, or `/quality-gate` as a structural check (not a replacement for tests/lint)
+
+## When to Activate
+
+Same triggers as **When to Use** above — this heading is what ECC uses for skill auto-activation.
+
+## How It Works
+
+### 1. Connect the MCP server
+
+Copy the `codescene` entry from `mcp-configs/mcp-servers.json` into your harness MCP config.
+
+**Claude Code** (`~/.claude.json` → `mcpServers`):
+
+```json
+"codescene": {
+  "command": "npx",
+  "args": ["-y", "@codescene/codehealth-mcp"],
+  "env": {
+    "CS_ACCESS_TOKEN": "YOUR_CS_ACCESS_TOKEN_HERE"
+  }
+}
+```
+
+**Project-scoped:** merge the same block into `.mcp.json` at the repo root.
+
+Token setup is documented in the upstream repo (link above). Standalone mode does not require a paid CodeScene platform account for the four tools listed below. Restart the session and confirm the `codescene` server is connected before relying on scores.
+
+### 2. Call standalone tools only
+
+| Tool | When to use |
+|------|-------------|
+| `code_health_review` | Full structural analysis **before** modifying a file |
+| `code_health_score` | Quick numeric score after each change (delta check) |
+| `pre_commit_code_health_safeguard` | Block commits that introduce Code Health regressions |
+| `analyze_change_set` | Branch-level check **before** opening a PR |
+
+Do **not** call platform-only tools (e.g. repository-wide technical debt hotspot lists). Do **not** reference `delta_analysis` — not available on standalone.
+
+### 3. Interpret scores (1–10)
+
+| Range | Meaning | Agent behavior |
+|-------|---------|----------------|
+| **9.0–10.0** | Green — healthy | Safer to extend; still prefer vertical slices |
+| **4.0–8.9** | Yellow — debt | Tread carefully; no drive-by refactors |
+| **1.0–3.9** | Red — severe debt | Narrow scope only |
+
+### 4. Run the feedback loop
+
+**Before touching a file**
+
+1. Run `code_health_review` on the target path.
+2. Record baseline score and listed code smells.
+3. Plan the smallest change that addresses the task.
+
+Scope by score: **below 5** — minimal diff only; **5–7** — no broad refactors; **above 7** — safer to refactor, still verify after each edit.
+
+**After each change**
+
+1. Run `code_health_score` on the same file.
+2. Compare to the baseline from `code_health_review`.
+3. If the score **regressed**, fix before continuing. Never mark the task done while the score is lower than when you started.
+
+**Before every commit** — run `pre_commit_code_health_safeguard` on the repository path.
+
+**Before a PR** — run `analyze_change_set` against the base branch (e.g. `main`).
+
+## Examples
+
+### Example: Flask maintainability improvement
+
+On `pallets/flask`, an agent loop using only standalone tools:
+
+1. `code_health_review` on a target module (baseline **4.82**)
+2. Targeted refactor addressing listed smells
+3. `code_health_score` after each edit
+4. `pre_commit_code_health_safeguard` before commit
+5. `analyze_change_set` before PR
+
+Result: Code Health **4.82 → 9.1** (free standalone token only).
+
+### Example: AGENTS.md enforcement block
+
+Paste into the project `AGENTS.md` or `CLAUDE.md`:
+
+```md
+## Code Health (CodeScene MCP)
+
+Before modifying any file: run `code_health_review`, note score and issues.
+
+- Score below 5: problematic range — scope changes narrowly.
+- Score 5–7: warning range — no broad refactors.
+
+After each change: run `code_health_score` to verify delta.
+
+- If score regressed: fix before continuing; never declare done if score dropped.
+
+Before every commit: run `pre_commit_code_health_safeguard`.
+
+Before PR: run `analyze_change_set`.
+```
+
+### Example: anti-patterns vs correct loop
+
+```markdown
+# BAD: Edit first, check later
+[large refactor without code_health_review]
+
+# BAD: Ignore score drop
+"Tests pass" → mark task done while Code Health decreased
+
+# BAD: Broad refactor on red-score file (below 5)
+Drive-by cleanup across the module
+
+# GOOD: review → small change → score → commit safeguard → analyze_change_set
+```
+
+## Pairing with ECC
+
+| ECC skill / flow | Code Health MCP role |
+|------------------|----------------------|
+| `coding-standards` | Style/naming; Code Health = structure/complexity |
+| `plankton-code-quality` | Write-time lint/format; Code Health = pre/post edit structural gate |
+| `verification-loop` / `/quality-gate` | Add structural regression check before "done" |
+| `security-review` | Security vs maintainability — use both when relevant |
+| `tdd-workflow` | Tests pass ≠ healthy design — check score after refactors |
+
+**Context tip:** ECC recommends keeping MCP count low. Enable `codescene` when doing substantive edits; disable when not needed.
+
+## Related Skills
+
+- `coding-standards` — baseline conventions
+- `plankton-code-quality` — write-time lint/format hooks
+- `verification-loop` — build/test/lint gate
+- `tdd-workflow` — test-first development
+- `security-review` — security checklist
+- `documentation-lookup` — library docs via Context7 (orthogonal)