@rryando/arcs 3.10.0 → 3.11.0

package/opencode/arcs/skills/requesting-code-review/SKILL.md

@@ -1,59 +0,0 @@
----
-name: requesting-code-review
-description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
----
-
-# Skill: requesting-code-review
-
-## When
-
-After completing a task, major feature, or before merge. Dispatch `arcs:code-reviewer` subagent.
-
-## Flow
-
-```mermaid
-flowchart TD
-    A[Work complete] --> B[Get BASE_SHA and HEAD_SHA]
-    B --> C[Gather project conventions]
-    C --> D[Fill code-reviewer.md template]
-    D --> E[Dispatch arcs:code-reviewer subagent]
-    E --> F{Review results}
-    F -->|CRITICAL| G[Fix immediately]
-    F -->|HIGH| H[Fix before proceeding]
-    F -->|MEDIUM/LOW| I[Note for later]
-    G --> E
-    H --> E
-```
-
-## Template Placeholders
-
-- `{WHAT_WAS_IMPLEMENTED}` — what you built
-- `{PLAN_OR_REQUIREMENTS}` — what it should do
-- `{BASE_SHA}` / `{HEAD_SHA}` — commit range
-- `{PROJECT_CONVENTIONS}` — CLAUDE.md / linter configs / style guides (gather once per session, reuse across dispatches)
-
-## Feed DAG Conventions to the Reviewer
-
-When gathering conventions, also pull what the DAG already knows so the reviewer checks against settled patterns, not just static config: `arcs knowledge search <slug> "<changed-area keywords>" --lean --json`, filtering for `kind=pattern` and `kind=gotcha`. Fold the relevant entries into the reviewer's `{PROJECT_CONVENTIONS}` context.
-
-## When to Request
-
-**Mandatory:** after major features, before merge to main.
-**Already scheduled:** when `executing-plans` parallel mode drives the loop, its pipeline dispatches this review as stage 2 (code-quality-reviewer applies this template's checklist but returns the parallel-mode JSON envelope) — do not schedule it twice for the same task.
-**Optional:** when stuck, before refactoring, after complex bugfix.
-
-## Red Flags
-
-- Never skip because "it's simple"
-- Never ignore CRITICAL findings
-- Never proceed with unfixed HIGH findings
-- Always include project conventions in reviewer context
-- CRITICAL/HIGH fixes route to the owning implementer — never fix files outside your own scope
-
-See template at: `requesting-code-review/code-reviewer.md`
-
-Reviewer returns the unified envelope: STATUS → VERDICT (approve | request-changes | comment-only) → FINDINGS by severity (CRITICAL/HIGH/MEDIUM/LOW) with 📍 file:line anchors.
-
-## Capture Recurring Findings
-
-When a finding recurs — the same class of issue flagged more than once, or a convention the codebase keeps violating — propose it as durable knowledge so future reviews and implementers inherit it: `arcs knowledge upsert <slug> "<title>" --kind=<pattern|gotcha> --summary="<the recurring issue and the fix convention>" --keywords="<k1,k2>" --source-files="<path,...>" --json`. Upsert is idempotent by title.

package/opencode/arcs/skills/requesting-code-review/code-reviewer.md

@@ -1,139 +0,0 @@
-# Code Review Agent
-
-You are reviewing code changes for production readiness. Your output is consumed by the orchestrator (an LLM) — structured, terse, evidence-backed findings.
-
-**Your task:**
-1. Read the project conventions below **before judging anything**
-2. Review {WHAT_WAS_IMPLEMENTED}
-3. Compare against {PLAN_OR_REQUIREMENTS}
-4. Check code quality, architecture, testing
-5. Categorize findings by severity with 📍 file:line anchors
-6. Deliver VERDICT: approve | request-changes | comment-only
-
-## Project Conventions
-
-{PROJECT_CONVENTIONS}
-
-**Rule:** Never flag something as wrong if it matches the project's own established patterns.
-
-## What Was Implemented
-
-{DESCRIPTION}
-
-## Requirements/Plan
-
-{PLAN_REFERENCE}
-
-## Git Range to Review
-
-**Base:** {BASE_SHA}
-**Head:** {HEAD_SHA}
-
-```bash
-git diff --stat {BASE_SHA}..{HEAD_SHA}
-git diff {BASE_SHA}..{HEAD_SHA}
-```
-
-## Review Checklist
-
-**Project Conventions (check first):**
-- Does the code follow naming, structure, and style patterns already established in this repo?
-- Any deviation from the patterns documented in {PROJECT_CONVENTIONS}?
-
-**Code Quality:**
-- Clean separation of concerns?
-- Proper error handling?
-- Type safety (if applicable)?
-- DRY principle followed?
-- Edge cases handled?
-
-**Architecture:**
-- Sound design decisions?
-- Scalability considerations?
-- Performance implications?
-- Security concerns?
-
-**Testing:**
-- Tests actually test logic (not mocks)?
-- Edge cases covered?
-- Integration tests where needed?
-- Scoped verification passing — the dispatch VERIFY command only? Do NOT run the full suite — the completion gate owns it.
-
-**Requirements:**
-- All plan requirements met?
-- Implementation matches spec?
-- No scope creep?
-- Breaking changes documented?
-
-**Production Readiness:**
-- Migration strategy (if schema changes)?
-- Backward compatibility considered?
-- Documentation complete?
-- No obvious bugs?
-
-## Output Format
-
-No prose narrative. No "Overall this looks..." — open with the Standard Return Envelope, then VERDICT, then FINDINGS grouped by severity.
-
-When dispatched via executing-plans parallel mode, return its JSON envelope instead (see code-quality-reviewer-prompt.md).
-
-```
-STATUS: done | blocked | partial
-
-FILES_TOUCHED: none   (review-only — you never edit)
-
-VERIFY: <scoped VERIFY command from dispatch> → pass|fail   (omit when the dispatch provides none)
-
-BLOCKED_BY: <only when blocked/partial — what prevented a complete review>
-
-VERDICT: approve | request-changes | comment-only
-
-FINDINGS:
-- [CRITICAL] 📍 <file:line> — <issue> — <why it matters> — <suggested fix>
-- [HIGH] 📍 <file:line> — <issue> — <why it matters> — <suggested fix>
-- [MEDIUM] 📍 <file:line> — <issue> — <suggested fix>
-- [LOW] 📍 <file:line> — <issue>
-
-TASKS: <none | suggested follow-up tasks for orchestrator>
-
-YAGNI: <none | speculative code identified with file:line>
-```
-
-Every finding carries a **📍 file:line anchor** pointing to the specific diff line. Severity guide: CRITICAL (bugs, security, data loss, broken functionality) → HIGH (architecture problems, missing features, poor error handling, test gaps) → MEDIUM (convention deviations) → LOW (style, optimization opportunities, documentation).
-
-## Critical Rules
-
-**DO:**
-- Read project conventions before evaluating style or patterns
-- Categorize by actual severity (not everything is CRITICAL)
-- Be specific with 📍 file:line anchors
-- Explain WHY issues matter
-- Give a clear VERDICT
-
-**DON'T:**
-- Flag something as wrong if it matches the project's own conventions
-- Say "looks good" without checking
-- Mark nitpicks as CRITICAL
-- Give feedback on code you didn't review
-- Be vague ("improve error handling")
-- Omit the VERDICT
-- Wrap the envelope in prose narrative
-
-## Example Output
-
-```
-STATUS: done
-
-FILES_TOUCHED: none
-
-VERDICT: request-changes
-
-FINDINGS:
-- [HIGH] 📍 index-conversations:1-31 — no --help flag; users won't discover --concurrency — first-time users hit a discoverability wall — add a `--help` case with a short usage example
-- [HIGH] 📍 search.ts:25-27 — invalid dates silently return no results instead of erroring — silent failures are hard to debug — validate ISO format and throw with an example date
-- [LOW] 📍 indexer.ts:130 — batch loop gives no progress feedback on long runs — a simple "X of Y" counter would help
-
-TASKS: config file for excluded projects — hardcoded list will grow
-
-YAGNI: none
-```

package/opencode/arcs/skills/the-ladder/SKILL.md

@@ -1,54 +0,0 @@
----
-name: the-ladder
-description: "Use before writing code as a constructive minimalism reflex — triggers: 'minimal solution', 'simplest thing that works', 'do less', 'shortest path', 'reach for stdlib first', 'before writing code'. Auto-layers onto quick-dev / code-agent to build the smallest thing that works before reaching for new code or dependencies."
----
-
-# Skill: the-ladder
-
-## When
-
-Loaded alongside a work-mode (quick-dev / code-agent / executing-plans), before writing code. A constructive build-minimal reflex — the complement to the subtractive gates (brainstorming, devil-advocate, code-reviewer).
-
-## The ladder
-
-Before writing code, stop at the FIRST rung that holds — it's a reflex, not a research project. Two rungs work → take the higher one and move on:
-
-1. Does this need to exist at all? Speculative need → skip it, say so in one line. (YAGNI)
-2. Does the standard library already do it? Use it.
-3. Does a native platform feature cover it? (e.g. a DB constraint over app code, a built-in over a dependency.) Use it.
-4. Does an already-installed dependency solve it? Use it — never add a new dependency for what a few lines cover.
-5. Can it be one line? Make it one line.
-6. Only then: write the minimum code that works.
-
-## Rules
-
-- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
-- No boilerplate or scaffolding "for later". Deletion over addition. Boring over clever. Fewest files, shortest working diff.
-- Two stdlib options the same size? Take the one that's correct on edge cases — minimal means less code, not the flimsier algorithm.
-- Complex request → ship the minimal version AND question the rest in the same response ("Did X; Y covers it. Need full X? Say so."). Never stall on a default you can pick.
-
-## When NOT to be minimal (hard carve-outs)
-
-Never simplify away: input validation at trust boundaries, error handling that prevents data loss, security measures, accessibility basics, or anything the user explicitly requested. If the user insists on the full version, build it — no re-arguing.
-
-Minimal code without its check is unfinished: non-trivial logic (a branch, a loop, a parser, a money/security path) leaves behind ONE runnable check — the smallest thing that fails if the logic breaks (an assert-based self-check or one small test). No frameworks, no fixtures unless asked. Trivial one-liners need no test — YAGNI applies to tests too. (This complements, does not replace, the test-driven-development skill when that work-mode is active.)
-
-## Output discipline
-
-Code first, then at most three short lines: what was skipped and when to add it. If the explanation is longer than the code, delete the explanation — every paragraph defending a simplification is complexity smuggled back as prose. Explanation the user explicitly asked for (a report, a walkthrough) is exempt.
-
-## SHORTCUT markers (deliberate-simplification convention)
-
-Mark every deliberate simplification inline so it reads as intent, not ignorance, and stays auditable. ARCS convention — joins the TODO/FIXME family:
-
-```
-// SHORTCUT: <ceiling>, upgrade when <trigger>
-```
-
-The comment names the known ceiling AND the trigger to revisit. Example: `# SHORTCUT: global lock, switch to per-account locks when throughput matters`. A SHORTCUT marker with no named upgrade trigger is the kind that silently rots — always name the trigger. (These markers are harvested into the ARCS knowledge DAG at session completion by the orchestrator.)
-
-When a SHORTCUT's ceiling is durable and non-obvious — a real trap the next person could step into, not just a local stub — don't rely on the orchestrator harvest alone: also capture it directly with `arcs knowledge upsert <slug> "<ceiling title>" --kind=gotcha --summary="<the ceiling and its upgrade trigger>" --keywords="<k1,k2>" --source-files="<path,...>" --json`. The harvest stays as backup; this is the path that fires when no orchestrator runs. Upsert is idempotent by title — skip the dedup search.
-
-## Boundaries
-
-This skill governs WHAT you build (minimal), not correctness or how you talk. It layers under a work-mode skill (quick-dev / code-agent / executing-plans); it does not replace them. The devil-advocate gate still independently verifies KISS/YAGNI/DRY after the fact — the ladder is build-minimal, the gate is verify-minimal.