@rubix0270/arboris 1.0.2 → 1.0.4

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

@@ -1,234 +0,0 @@
----
-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

@@ -1,167 +0,0 @@
----
-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)