arboris-cli 1.0.0 → 1.1.0

package/prisma/skills/agent-self-evaluation/templates/evaluation-report.md

@@ -0,0 +1,86 @@
+# Agent Self-Evaluation Report Template
+
+Copy this template and fill in after completing a task. The format matches `scripts/evaluate.py` output.
+
+```
+============================================================
+AGENT SELF-EVALUATION REPORT
+============================================================
+Summary: Overall score X.X/5 across 5 quality axes.
+
+  Accuracy         █████ 5/5    or    ███░░ 3/5
+    + [Evidence: passing tests, verified claims]
+    - [Gaps: unverified claims, hedging language]
+    → [Improvement if score < 5]
+
+  Completeness      █████ 5/5
+    + [What's covered: all requirements + edge cases]
+    - [What's missing: explicitly acknowledge gaps]
+    → [Improvement if score < 5]
+
+  Clarity           █████ 5/5
+    + [Structure: headings, code blocks, bullet points]
+    - [Issues: undefined terms, wall of text, no summary]
+    → [Improvement if score < 5]
+
+  Actionability     █████ 5/5
+    + [User can: merge PR, run command, review file]
+    - [Blockers: missing steps, vague suggestions]
+    → [Improvement if score < 5]
+
+  Conciseness       █████ 5/5
+    + [Tight: no repetition, high information density]
+    - [Bloat: filler, meta-commentary, repeated points]
+    → [Improvement if score < 5]
+
+  OVERALL           X.X/5
+
+CRITICAL ISSUES (axes ≤ 2):
+  [Axis] Score N/5 — specific fix needed
+  (or "None" if no axis ≤ 2)
+
+Self-check: Would the user agree with this assessment? [Yes/No + brief justification]
+
+TOP IMPROVEMENTS:
+  1. [Highest impact fix]
+  2. [Second highest]
+  (Only list axes scoring < 4, ranked by user impact)
+
+VERDICT: [Deliver as-is / Fix N issues then deliver / Redo from scratch]
+```
+
+## Quick Reference: Scoring Triggers
+
+| If you see this... | Accuracy | Completeness | Clarity | Actionability | Conciseness |
+|---|---|---|---|---|---|
+| "should work" / "probably fine" | ≤4 | — | — | — | — |
+| "I think" / "I believe" | ≤4 | — | — | — | — |
+| No test output cited | ≤4 | — | — | — | — |
+| "TODO" / "FIXME" left behind | ≤3 | ≤3 | — | ≤3 | — |
+| Missing error handling | — | ≤3 | — | — | — |
+| Only happy path covered | — | ≤3 | — | — | — |
+| Wall-of-text paragraph (>200 words) | — | — | ≤3 | — | — |
+| No headings or structure | — | — | ≤3 | — | — |
+| "You should..." without specifics | — | — | — | ≤3 | — |
+| No PR or file created | — | — | — | ≤3 | — |
+| User needs to figure out next step | — | — | — | ≤2 | — |
+| Repeated points (3+ times) | — | — | — | — | ≤3 |
+| "Let me explain..." / "To summarize..." x3+ | — | — | — | — | ≤3 |
+| Output >15x longer than task | — | — | — | — | ≤3 |
+
+## When to Skip
+
+Skip the evaluation if:
+- Task was a single tool call (e.g., "read this file" — nothing to evaluate)
+- User explicitly says "don't evaluate" or "just do it"
+- Task is purely conversational (greeting, small talk)
+- You're mid-workflow and the user will judge the final output, not intermediate steps
+
+## Post-Evaluation Actions
+
+| Overall Score | What to do |
+|---|---|
+| ≥4.5 | Deliver as-is. No changes needed. |
+| 3.5–4.4 | Flag top improvement but deliver. Fix if <30 seconds. |
+| 2.5–3.4 | State what you'd change. Ask user: "Should I redo [axis] or deliver as-is?" |
+| <2.5 | Don't deliver. Say: "This scored [score] because [evidence]. Let me redo this with [specific fix]." Then redo. |

package/prisma/skills/agent-sort/SKILL.md

@@ -0,0 +1,216 @@
+---
+name: agent-sort
+description: Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.
+metadata:
+  origin: ECC
+---
+
+# Agent Sort
+
+Use this skill when a repo needs a project-specific ECC surface instead of the default full install.
+
+The goal is not to guess what "feels useful." The goal is to classify ECC components with evidence from the actual codebase.
+
+## When to Use
+
+- A project only needs a subset of ECC and full installs are too noisy
+- The repo stack is clear, but nobody wants to hand-curate skills one by one
+- A team wants a repeatable install decision backed by grep evidence instead of opinion
+- You need to separate always-loaded daily workflow surfaces from searchable library/reference surfaces
+- A repo has drifted into the wrong language, rule, or hook set and needs cleanup
+
+## Non-Negotiable Rules
+
+- Use the current repository as the source of truth, not generic preferences
+- Every DAILY decision must cite concrete repo evidence
+- LIBRARY does not mean "delete"; it means "keep accessible without loading by default"
+- Do not install hooks, rules, or scripts that the current repo cannot use
+- Prefer ECC-native surfaces; do not introduce a second install system
+
+## Outputs
+
+Produce these artifacts in order:
+
+1. DAILY inventory
+2. LIBRARY inventory
+3. install plan
+4. verification report
+5. optional `skill-library` router if the project wants one
+
+## Classification Model
+
+Use two buckets only:
+
+- `DAILY`
+  - should load every session for this repo
+  - strongly matched to the repo's language, framework, workflow, or operator surface
+- `LIBRARY`
+  - useful to retain, but not worth loading by default
+  - should remain reachable through search, router skill, or selective manual use
+
+## Evidence Sources
+
+Use repo-local evidence before making any classification:
+
+- file extensions
+- package managers and lockfiles
+- framework configs
+- CI and hook configs
+- build/test scripts
+- imports and dependency manifests
+- repo docs that explicitly describe the stack
+
+Useful commands include:
+
+```bash
+rg --files
+rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
+cat package.json
+cat pyproject.toml
+cat Cargo.toml
+cat pubspec.yaml
+cat go.mod
+```
+
+## Parallel Review Passes
+
+If parallel subagents are available, split the review into these passes:
+
+1. Agents
+   - classify `agents/*`
+2. Skills
+   - classify `skills/*`
+3. Commands
+   - classify `commands/*`
+4. Rules
+   - classify `rules/*`
+5. Hooks and scripts
+   - classify hook surfaces, MCP health checks, helper scripts, and OS compatibility
+6. Extras
+   - classify contexts, examples, MCP configs, templates, and guidance docs
+
+If subagents are not available, run the same passes sequentially.
+
+## Core Workflow
+
+### 1. Read the repo
+
+Establish the real stack before classifying anything:
+
+- languages in use
+- frameworks in use
+- primary package manager
+- test stack
+- lint/format stack
+- deployment/runtime surface
+- operator integrations already present
+
+### 2. Build the evidence table
+
+For every candidate surface, record:
+
+- component path
+- component type
+- proposed bucket
+- repo evidence
+- short justification
+
+Use this format:
+
+```text
+skills/frontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | core frontend stack
+skills/django-patterns   | skill | LIBRARY | no .py files, no pyproject.toml       | not active in this repo
+rules/typescript/*       | rules | DAILY | package.json + tsconfig.json            | active TS repo
+rules/python/*           | rules | LIBRARY | zero Python source files             | keep accessible only
+```
+
+### 3. Decide DAILY vs LIBRARY
+
+Promote to `DAILY` when:
+
+- the repo clearly uses the matching stack
+- the component is general enough to help every session
+- the repo already depends on the corresponding runtime or workflow
+
+Demote to `LIBRARY` when:
+
+- the component is off-stack
+- the repo might need it later, but not every day
+- it adds context overhead without immediate relevance
+
+### 4. Build the install plan
+
+Translate the classification into action:
+
+- DAILY skills -> install or keep in `.claude/skills/`
+- DAILY commands -> keep as explicit shims only if still useful
+- DAILY rules -> install only matching language sets
+- DAILY hooks/scripts -> keep only compatible ones
+- LIBRARY surfaces -> keep accessible through search or `skill-library`
+
+If the repo already uses selective installs, update that plan instead of creating another system.
+
+### 5. Create the optional library router
+
+If the project wants a searchable library surface, create:
+
+- `.claude/skills/skill-library/SKILL.md`
+
+That router should contain:
+
+- a short explanation of DAILY vs LIBRARY
+- grouped trigger keywords
+- where the library references live
+
+Do not duplicate every skill body inside the router.
+
+### 6. Verify the result
+
+After the plan is applied, verify:
+
+- every DAILY file exists where expected
+- stale language rules were not left active
+- incompatible hooks were not installed
+- the resulting install actually matches the repo stack
+
+Return a compact report with:
+
+- DAILY count
+- LIBRARY count
+- removed stale surfaces
+- open questions
+
+## Handoffs
+
+If the next step is interactive installation or repair, hand off to:
+
+- `configure-ecc`
+
+If the next step is overlap cleanup or catalog review, hand off to:
+
+- `skill-stocktake`
+
+If the next step is broader context trimming, hand off to:
+
+- `strategic-compact`
+
+## Output Format
+
+Return the result in this order:
+
+```text
+STACK
+- language/framework/runtime summary
+
+DAILY
+- always-loaded items with evidence
+
+LIBRARY
+- searchable/reference items with evidence
+
+INSTALL PLAN
+- what should be installed, removed, or routed
+
+VERIFICATION
+- checks run and remaining gaps
+```

package/prisma/skills/agentic-engineering/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: agentic-engineering
+description: Operate as an agentic engineer using eval-first execution, decomposition, and cost-aware model routing.
+metadata:
+  origin: ECC
+---
+
+# Agentic Engineering
+
+Use this skill for engineering workflows where AI agents perform most implementation work and humans enforce quality and risk controls.
+
+## Operating Principles
+
+1. Define completion criteria before execution.
+2. Decompose work into agent-sized units.
+3. Route model tiers by task complexity.
+4. Measure with evals and regression checks.
+
+## Eval-First Loop
+
+1. Define capability eval and regression eval.
+2. Run baseline and capture failure signatures.
+3. Execute implementation.
+4. Re-run evals and compare deltas.
+
+## Task Decomposition
+
+Apply the 15-minute unit rule:
+- each unit should be independently verifiable
+- each unit should have a single dominant risk
+- each unit should expose a clear done condition
+
+## Model Routing
+
+- Haiku: classification, boilerplate transforms, narrow edits
+- Sonnet: implementation and refactors
+- Opus: architecture, root-cause analysis, multi-file invariants
+
+## Session Strategy
+
+- Continue session for closely-coupled units.
+- Start fresh session after major phase transitions.
+- Compact after milestone completion, not during active debugging.
+
+## Review Focus for AI-Generated Code
+
+Prioritize:
+- invariants and edge cases
+- error boundaries
+- security and auth assumptions
+- hidden coupling and rollout risk
+
+Do not waste review cycles on style-only disagreements when automated format/lint already enforce style.
+
+## Cost Discipline
+
+Track per task:
+- model
+- token estimate
+- retries
+- wall-clock time
+- success/failure
+
+Escalate model tier only when lower tier fails with a clear reasoning gap.