@baselane/packs 0.1.5 → 0.1.7

package/packs/full-harness/rendered/.claude/commands/rust-review.md

@@ -0,0 +1,6 @@
+---
+description: Comprehensive Rust code review for ownership, lifetimes, error handling, unsafe usage, and idiomatic patterns. Invokes the rust-reviewer agent.
+argument-hint: [optional arguments]
+---
+
+# Rust Code Review This command invokes the **rust-reviewer** agent for comprehensive Rust-specific code review. ## What This Command Does 1. **Verify Automated Checks**: Run `cargo check`, `cargo clippy -- -D warnings`, `cargo fmt --check`, and `cargo test` — stop if any fail 2. **Identify Rust Changes**: Find modified `.rs` files via `git diff HEAD~1` (or `git diff main...HEAD` for PRs) 3. **Run Security Audit**: Execute `cargo audit` if available 4. **Security Scan**: Check for unsafe usage, command injection, hardcoded secrets 5. **Ownership Review**: Analyze unnecessary clones, lifetime issues, borrowing patterns 6. **Generate Report**: Categorize issues by severity ## When to Use Use `/rust-review` when: - After writing or modifying Rust code - Before committing Rust changes - Reviewing pull requests with Rust code - Onboarding to a new Rust codebase - Learning idiomatic Rust patterns ## Review Categories ### CRITICAL (Must Fix) - Unchecked `unwrap()`/`expect()` in production code paths - `unsafe` without `// SAFETY:` comment documenting invariants - SQL injection via string interpolation in queries - Command injection via unvalidated input in `std::process::Command` - Hardcoded credentials - Use-after-free via raw pointers ### HIGH (Should Fix) - Unnecessary `.clone()` to satisfy borrow checker - `String` parameter where `&str` or `impl AsRef<str>` suffices - Blocking in async context (`std::thread::sleep`, `std::fs`) - Missing `Send`/`Sync` bounds on shared types - Wildcard `_ =>` match on business-critical enums - Large functions (>50 lines) ### MEDIUM (Consider) - Unnecessary allocation in hot paths - Missing `with_capacity` when size is known - Suppressed clippy warnings without justification - Public API without `///` documentation - Consider `#[must_use]` on non-`must_use` return types where ignoring values is likely a bug ## Automated Checks Run ```bash # Build gate (must pass before review) cargo check # Lints and suggestions cargo clippy -- -D warnings # Formatting cargo fmt --check # Tests cargo test # Security audit (if available) if command -v cargo-audit >/dev/null; then cargo audit; else echo "cargo-audit not installed"; fi ``` ## Example Usage ````text User: /rust-review Agent: # Rust Code Review Report ## Files Reviewed - src/service/user.rs (modified) - src/handler/api.rs (modified) ## Static Analysis Results - Build: Successful - Clippy: No warnings - Formatting: Passed - Tests: All passing ## Issues Found [CRITICAL] Unchecked unwrap in Production Path File: src/service/user.rs:28 Issue: Using `.unwrap()` on database query result ```rust let user = db.find_by_id(id).unwrap(); // Panics on missing user ``` Fix: Propagate error with context ```rust let user = db.find_by_id(id) .context("failed to fetch user")?; ``` [HIGH] Unnecessary Clone File: src/handler/api.rs:45 Issue: Cloning String to satisfy borrow checker ```rust let name = user.name.clone(); process(&user, &name); ``` Fix: Restructure to avoid clone ```rust let result = process_name(&user.name); use_user(&user, result); ``` ## Summary - CRITICAL: 1 - HIGH: 1 - MEDIUM: 0 Recommendation: Block merge until CRITICAL issue is fixed ```` ## Approval Criteria | Status | Condition | |--------|-----------| | Approve | No CRITICAL or HIGH issues | | Warning | Only MEDIUM issues (merge with caution) | | Block | CRITICAL or HIGH issues found | ## Integration with Other Commands - Use `/rust-test` first to ensure tests pass - Use `/rust-build` if build errors occur - Use `/rust-review` before committing - Use `/code-review` for non-Rust-specific concerns ## Related - Agent: `agents/rust-reviewer.md` - Skills: `skills/rust-patterns/`, `skills/rust-testing/`

package/packs/full-harness/rendered/.claude/commands/rust-test.md

@@ -0,0 +1,6 @@
+---
+description: Enforce TDD workflow for Rust. Write tests first, then implement. Verify 80%+ coverage with cargo-llvm-cov.
+argument-hint: [optional arguments]
+---
+
+# Rust TDD Command This command enforces test-driven development methodology for Rust code using `#[test]`, rstest, proptest, and mockall. ## What This Command Does 1. **Define Types/Traits**: Scaffold function signatures with `todo!()` 2. **Write Tests**: Create comprehensive test module (RED) 3. **Run Tests**: Verify tests fail for the right reason 4. **Implement Code**: Write minimal code to pass (GREEN) 5. **Refactor**: Improve while keeping tests green 6. **Check Coverage**: Ensure 80%+ coverage with cargo-llvm-cov ## When to Use Use `/rust-test` when: - Implementing new Rust functions, methods, or traits - Adding test coverage to existing Rust code - Fixing bugs (write failing test first) - Building critical business logic - Learning TDD workflow in Rust ## TDD Cycle ``` RED -> Write failing test first GREEN -> Implement minimal code to pass REFACTOR -> Improve code, tests stay green REPEAT -> Next test case ``` ## Example Session ````text User: /rust-test I need a function to validate user registration Agent: # TDD Session: Registration Validator ## Step 1: Define Interface ```rust // src/validator.rs pub struct RegistrationRequest { pub name: String, pub email: String, pub password: String, } pub enum ValidationResult { Valid, Invalid(Vec<String>), } pub fn validate_registration(request: &RegistrationRequest) -> ValidationResult { todo!() } ``` ## Step 2: Write Tests (RED) ```rust #[cfg(test)] mod tests { use super::*; #[test] fn valid_registration_returns_valid() { let request = RegistrationRequest { name: "Alice".into(), email: "alice@example.com".into(), password: "SecureP@ss1".into(), }; assert!(matches!(validate_registration(&request), ValidationResult::Valid)); } #[test] fn blank_name_returns_invalid() { let request = RegistrationRequest { name: "".into(), email: "alice@example.com".into(), password: "SecureP@ss1".into(), }; match validate_registration(&request) { ValidationResult::Invalid(errors) => { assert!(errors.contains(&"Name is required".to_string())); } ValidationResult::Valid => panic!("expected Invalid"), } } #[test] fn invalid_email_returns_invalid() { let request = RegistrationRequest { name: "Alice".into(), email: "not-an-email".into(), password: "SecureP@ss1".into(), }; assert!(matches!( validate_registration(&request), ValidationResult::Invalid(_) )); } #[test] fn short_password_returns_invalid() { let request = RegistrationRequest { name: "Alice".into(), email: "alice@example.com".into(), password: "short".into(), }; assert!(matches!( validate_registration(&request), ValidationResult::Invalid(_) )); } } ``` ## Step 3: Run Tests — Verify FAIL ```bash $ cargo test running 4 tests test tests::valid_registration_returns_valid ... FAILED (not yet implemented) test tests::blank_name_returns_invalid ... FAILED test tests::invalid_email_returns_invalid ... FAILED test tests::short_password_returns_invalid ... FAILED ``` Tests fail as expected (todo! panic). ## Step 4: Implement Minimal Code (GREEN) ```rust pub fn validate_registration(request: &RegistrationRequest) -> ValidationResult { let mut errors = Vec::new(); if request.name.trim().is_empty() { errors.push("Name is required".into()); } if !request.email.contains('@') { errors.push("Invalid email format".into()); } if request.password.len() < 8 { errors.push("Password must be at least 8 characters".into()); } if errors.is_empty() { ValidationResult::Valid } else { ValidationResult::Invalid(errors) } } ``` ## Step 5: Run Tests — Verify PASS ```bash $ cargo test running 4 tests test tests::valid_registration_returns_valid ... ok test tests::blank_name_returns_invalid ... ok test tests::invalid_email_returns_invalid ... ok test tests::short_password_returns_invalid ... ok test result: ok. 4 passed; 0 failed ``` All tests passing! ## Step 6: Check Coverage ```bash $ cargo llvm-cov Coverage: 100.0% of lines ``` Coverage: 100% ## TDD Complete! ```` ## Test Patterns ### Unit Tests ```rust #[cfg(test)] mod tests { use super::*; #[test] fn adds_two_numbers() { assert_eq!(add(2, 3), 5); } #[test] fn handles_error() -> Result<(), Box<dyn std::error::Error>> { let result = parse_config(r#"port = 8080"#)?; assert_eq!(result.port, 8080); Ok(()) } } ``` ### Parameterized Tests with rstest ```rust use rstest::{rstest, fixture}; #[rstest] #[case("hello", 5)] #[case("", 0)] #[case("rust", 4)] fn test_string_length(#[case] input: &str, #[case] expected: usize) { assert_eq!(input.len(), expected); } ``` ### Async Tests ```rust #[tokio::test] async fn fetches_data_successfully() { let client = TestClient::new().await; let result = client.get("/data").await; assert!(result.is_ok()); } ``` ### Property-Based Tests ```rust use proptest::prelude::*; proptest! { #[test] fn encode_decode_roundtrip(input in ".*") { let encoded = encode(&input); let decoded = decode(&encoded).unwrap(); assert_eq!(input, decoded); } } ``` ## Coverage Commands ```bash # Summary report cargo llvm-cov # HTML report cargo llvm-cov --html # Fail if below threshold cargo llvm-cov --fail-under-lines 80 # Run specific test cargo test test_name # Run with output cargo test -- --nocapture # Run without stopping on first failure cargo test --no-fail-fast ``` ## Coverage Targets | Code Type | Target | |-----------|--------| | Critical business logic | 100% | | Public API | 90%+ | | General code | 80%+ | | Generated / FFI bindings | Exclude | ## TDD Best Practices **DO:** - Write test FIRST, before any implementation - Run tests after each change - Use `assert_eq!` over `assert!` for better error messages - Use `?` in tests that return `Result` for cleaner output - Test behavior, not implementation - Include edge cases (empty, boundary, error paths) **DON'T:** - Write implementation before tests - Skip the RED phase - Use `#[should_panic]` when `Result::is_err()` works - Use `sleep()` in tests — use channels or `tokio::time::pause()` - Mock everything — prefer integration tests when feasible ## Related Commands - `/rust-build` - Fix build errors - `/rust-review` - Review code after implementation - `verification-loop` skill - Run full verification loop ## Related - Skill: `skills/rust-testing/` - Skill: `skills/rust-patterns/`

package/packs/full-harness/rendered/.claude/commands/santa-loop.md

@@ -0,0 +1,6 @@
+---
+description: Adversarial dual-review convergence loop — two independent model reviewers must both approve before code ships.
+argument-hint: [optional arguments]
+---
+
+# Santa Loop Adversarial dual-review convergence loop using the santa-method skill. Two independent reviewers — different models, no shared context — must both return NICE before code ships. ## Purpose Run two independent reviewers (Claude Opus + an external model) against the current task output. Both must return NICE before the code is pushed. If either returns NAUGHTY, fix all flagged issues, commit, and re-run fresh reviewers — up to 3 rounds. ## Usage ``` /santa-loop [file-or-glob | description] ``` ## Workflow ### Step 1: Identify What to Review Determine the scope from `$ARGUMENTS` or fall back to uncommitted changes: ```bash git diff --name-only HEAD ``` Read all changed files to build the full review context. If `$ARGUMENTS` specifies a path, file, or description, use that as the scope instead. ### Step 2: Build the Rubric Construct a rubric appropriate to the file types under review. Every criterion must have an objective PASS/FAIL condition. Include at minimum: | Criterion | Pass Condition | |-----------|---------------| | Correctness | Logic is sound, no bugs, handles edge cases | | Security | No secrets, injection, XSS, or OWASP Top 10 issues | | Error handling | Errors handled explicitly, no silent swallowing | | Completeness | All requirements addressed, no missing cases | | Internal consistency | No contradictions between files or sections | | No regressions | Changes don't break existing behavior | Add domain-specific criteria based on file types (e.g., type safety for TS, memory safety for Rust, migration safety for SQL). ### Step 3: Dual Independent Review Launch two reviewers **in parallel** using the Agent tool (both in a single message for concurrent execution). Both must complete before proceeding to the verdict gate. Each reviewer evaluates every rubric criterion as PASS or FAIL, then returns structured JSON: ```json { "verdict": "PASS" | "FAIL", "checks": [ {"criterion": "...", "result": "PASS|FAIL", "detail": "..."} ], "critical_issues": ["..."], "suggestions": ["..."] } ``` The verdict gate (Step 4) maps these to NICE/NAUGHTY: both PASS → NICE, either FAIL → NAUGHTY. #### Reviewer A: Claude Agent (always runs) Launch an Agent (subagent_type: `code-reviewer`, model: `opus`) with the full rubric + all files under review. The prompt must include: - The complete rubric - All file contents under review - "You are an independent quality reviewer. You have NOT seen any other review. Your job is to find problems, not to approve." - Return the structured JSON verdict above #### Reviewer B: External Model (Claude fallback only if no external CLI installed) First, detect which CLIs are available: ```bash command -v codex >/dev/null 2>&1 && echo "codex" || true command -v gemini >/dev/null 2>&1 && echo "gemini" || true ``` Build the reviewer prompt (identical rubric + instructions as Reviewer A) and write it to a unique temp file: ```bash PROMPT_FILE=$(mktemp /tmp/santa-reviewer-b-XXXXXX.txt) cat > "$PROMPT_FILE" << 'EOF' ... full rubric + file contents + reviewer instructions ... EOF ``` Use the first available CLI: **Codex CLI** (if installed) ```bash codex exec --sandbox read-only -m gpt-5.4 -C "$(pwd)" - < "$PROMPT_FILE" rm -f "$PROMPT_FILE" ``` **Gemini CLI** (if installed and codex is not) ```bash gemini -p "$(cat "$PROMPT_FILE")" -m gemini-2.5-pro rm -f "$PROMPT_FILE" ``` **Claude Agent fallback** (only if neither `codex` nor `gemini` is installed) Launch a second Claude Agent (subagent_type: `code-reviewer`, model: `opus`). Log a warning that both reviewers share the same model family — true model diversity was not achieved but context isolation is still enforced. In all cases, the reviewer must return the same structured JSON verdict as Reviewer A. ### Step 4: Verdict Gate - **Both PASS** → **NICE** — proceed to Step 6 (push) - **Either FAIL** → **NAUGHTY** — merge all critical issues from both reviewers, deduplicate, proceed to Step 5 ### Step 5: Fix Cycle (NAUGHTY path) 1. Display all critical issues from both reviewers 2. Fix every flagged issue — change only what was flagged, no drive-by refactors 3. Commit all fixes in a single commit: ``` fix: address santa-loop review findings (round N) ``` 4. Re-run Step 3 with **fresh reviewers** (no memory of previous rounds) 5. Repeat until both return PASS **Maximum 3 iterations.** If still NAUGHTY after 3 rounds, stop and present remaining issues: ``` SANTA LOOP ESCALATION (exceeded 3 iterations) Remaining issues after 3 rounds: - [list all unresolved critical issues from both reviewers] Manual review required before proceeding. ``` Do NOT push. ### Step 6: Push (NICE path) When both reviewers return PASS: ```bash git push -u origin HEAD ``` ### Step 7: Final Report Print the output report (see Output section below). ## Output ``` SANTA VERDICT: [NICE / NAUGHTY (escalated)] Reviewer A (Claude Opus): [PASS/FAIL] Reviewer B ([model used]): [PASS/FAIL] Agreement: Both flagged: [issues caught by both] Reviewer A only: [issues only A caught] Reviewer B only: [issues only B caught] Iterations: [N]/3 Result: [PUSHED / ESCALATED TO USER] ``` ## Notes - Reviewer A (Claude Opus) always runs — guarantees at least one strong reviewer regardless of tooling. - Model diversity is the goal for Reviewer B. GPT-5.4 or Gemini 2.5 Pro gives true independence — different training data, different biases, different blind spots. The Claude-only fallback still provides value via context isolation but loses model diversity. - Strongest available models are used: Opus for Reviewer A, GPT-5.4 or Gemini 2.5 Pro for Reviewer B. - External reviewers run with `--sandbox read-only` (Codex) to prevent repo mutation during review. - Fresh reviewers each round prevents anchoring bias from prior findings. - The rubric is the most important input. Tighten it if reviewers rubber-stamp or flag subjective style issues. - Commits happen on NAUGHTY rounds so fixes are preserved even if the loop is interrupted. - Push only happens after NICE — never mid-loop.

package/packs/full-harness/rendered/.claude/commands/save-session.md

@@ -0,0 +1,6 @@
+---
+description: Save current session state to a dated file in ~/.claude/session-data/ so work can be resumed in a future session with full context.
+argument-hint: [optional arguments]
+---
+
+# Save Session Command Capture everything that happened in this session — what was built, what worked, what failed, what's left — and write it to a dated file so the next session can pick up exactly where this one left off. ## When to Use - End of a work session before closing Claude Code - Before hitting context limits (run this first, then start a fresh session) - After solving a complex problem you want to remember - Any time you need to hand off context to a future session ## Process ### Step 1: Gather context Before writing the file, collect: - Read all files modified during this session (use git diff or recall from conversation) - Review what was discussed, attempted, and decided - Note any errors encountered and how they were resolved (or not) - Check current test/build status if relevant ### Step 2: Create the sessions folder if it doesn't exist Create the canonical sessions folder in the user's Claude home directory: ```bash mkdir -p ~/.claude/session-data ``` ### Step 3: Write the session file Create `~/.claude/session-data/YYYY-MM-DD-<short-id>-session.tmp`, using today's actual date and a short-id that satisfies the rules enforced by `SESSION_FILENAME_REGEX` in `session-manager.js`: - Compatibility characters: letters `a-z` / `A-Z`, digits `0-9`, hyphens `-`, underscores `_` - Compatibility minimum length: 1 character - Recommended style for new files: lowercase letters, digits, and hyphens with 8+ characters to avoid collisions Valid examples: `abc123de`, `a1b2c3d4`, `frontend-worktree-1`, `ChezMoi_2` Avoid for new files: `A`, `test_id1`, `ABC123de` Full valid filename example: `2024-01-15-abc123de-session.tmp` The legacy filename `YYYY-MM-DD-session.tmp` is still valid, but new session files should prefer the short-id form to avoid same-day collisions. ### Step 4: Populate the file with all sections below Write every section honestly. Do not skip sections — write "Nothing yet" or "N/A" if a section genuinely has no content. An incomplete file is worse than an honest empty section. ### Step 5: Show the file to the user After writing, display the full contents and ask: ``` Session saved to [actual resolved path to the session file] Does this look accurate? Anything to correct or add before we close? ``` Wait for confirmation. Make edits if requested. --- ## Session File Format ```markdown # Session: YYYY-MM-DD **Started:** [approximate time if known] **Last Updated:** [current time] **Project:** [project name or path] **Topic:** [one-line summary of what this session was about] --- ## What We Are Building [1-3 paragraphs describing the feature, bug fix, or task. Include enough context that someone with zero memory of this session can understand the goal. Include: what it does, why it's needed, how it fits into the larger system.] --- ## What WORKED (with evidence) [List only things that are confirmed working. For each item include WHY you know it works — test passed, ran in browser, Postman returned 200, etc. Without evidence, move it to "Not Tried Yet" instead.] - **[thing that works]** — confirmed by: [specific evidence] - **[thing that works]** — confirmed by: [specific evidence] If nothing is confirmed working yet: "Nothing confirmed working yet — all approaches still in progress or untested." --- ## What Did NOT Work (and why) [This is the most important section. List every approach tried that failed. For each failure write the EXACT reason so the next session doesn't retry it. Be specific: "threw X error because Y" is useful. "didn't work" is not.] - **[approach tried]** — failed because: [exact reason / error message] - **[approach tried]** — failed because: [exact reason / error message] If nothing failed: "No failed approaches yet." --- ## What Has NOT Been Tried Yet [Approaches that seem promising but haven't been attempted. Ideas from the conversation. Alternative solutions worth exploring. Be specific enough that the next session knows exactly what to try.] - [approach / idea] - [approach / idea] If nothing is queued: "No specific untried approaches identified." --- ## Current State of Files [Every file touched this session. Be precise about what state each file is in.] | File | Status | Notes | | ----------------- | -------------- | -------------------------- | | `path/to/file.ts` | PASS: Complete | [what it does] | | `path/to/file.ts` | In Progress | [what's done, what's left] | | `path/to/file.ts` | FAIL: Broken | [what's wrong] | | `path/to/file.ts` | Not Started | [planned but not touched] | If no files were touched: "No files modified this session." --- ## Decisions Made [Architecture choices, tradeoffs accepted, approaches chosen and why. These prevent the next session from relitigating settled decisions.] - **[decision]** — reason: [why this was chosen over alternatives] If no significant decisions: "No major decisions made this session." --- ## Blockers & Open Questions [Anything unresolved that the next session needs to address or investigate. Questions that came up but weren't answered. External dependencies waiting on.] - [blocker / open question] If none: "No active blockers." --- ## Exact Next Step [If known: The single most important thing to do when resuming. Be precise enough that resuming requires zero thinking about where to start.] [If not known: "Next step not determined — review 'What Has NOT Been Tried Yet' and 'Blockers' sections to decide on direction before starting."] --- ## Environment & Setup Notes [Only fill this if relevant — commands needed to run the project, env vars required, services that need to be running, etc. Skip if standard setup.] [If none: omit this section entirely.] ``` --- ## Example Output ```markdown # Session: 2024-01-15 **Started:** ~2pm **Last Updated:** 5:30pm **Project:** my-app **Topic:** Building JWT authentication with httpOnly cookies --- ## What We Are Building User authentication system for the Next.js app. Users register with email/password, receive a JWT stored in an httpOnly cookie (not localStorage), and protected routes check for a valid token via middleware. The goal is session persistence across browser refreshes without exposing the token to JavaScript. --- ## What WORKED (with evidence) - **`/api/auth/register` endpoint** — confirmed by: Postman POST returns 200 with user object, row visible in Supabase dashboard, bcrypt hash stored correctly - **JWT generation in `lib/auth.ts`** — confirmed by: unit test passes (`npm test -- auth.test.ts`), decoded token at jwt.io shows correct payload - **Password hashing** — confirmed by: `bcrypt.compare()` returns true in test --- ## What Did NOT Work (and why) - **Next-Auth library** — failed because: conflicts with our custom Prisma adapter, threw "Cannot use adapter with credentials provider in this configuration" on every request. Not worth debugging — too opinionated for our setup. - **Storing JWT in localStorage** — failed because: SSR renders happen before localStorage is available, caused React hydration mismatch error on every page load. This approach is fundamentally incompatible with Next.js SSR. --- ## What Has NOT Been Tried Yet - Store JWT as httpOnly cookie in the login route response (most likely solution) - Use `cookies()` from `next/headers` to read token in server components - Write middleware.ts to protect routes by checking cookie existence --- ## Current State of Files | File | Status | Notes | | -------------------------------- | -------------- | ----------------------------------------------- | | `app/api/auth/register/route.ts` | PASS: Complete | Works, tested | | `app/api/auth/login/route.ts` | In Progress | Token generates but not setting cookie yet | | `lib/auth.ts` | PASS: Complete | JWT helpers, all tested | | `middleware.ts` | Not Started | Route protection, needs cookie read logic first | | `app/login/page.tsx` | Not Started | UI not started | --- ## Decisions Made - **httpOnly cookie over localStorage** — reason: prevents XSS token theft, works with SSR - **Custom auth over Next-Auth** — reason: Next-Auth conflicts with our Prisma setup, not worth the fight --- ## Blockers & Open Questions - Does `cookies().set()` work inside a Route Handler or only in Server Actions? Need to verify. --- ## Exact Next Step In `app/api/auth/login/route.ts`, after generating the JWT, set it as an httpOnly cookie using `cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' })`. Then test with Postman — the response should include a `Set-Cookie` header. ``` --- ## Notes - Each session gets its own file — never append to a previous session's file - The "What Did NOT Work" section is the most critical — future sessions will blindly retry failed approaches without it - If the user asks to save mid-session (not just at the end), save what's known so far and mark in-progress items clearly - The file is meant to be read by Claude at the start of the next session via `/resume-session` - Use the canonical global session store: `~/.claude/session-data/` - Prefer the short-id filename form (`YYYY-MM-DD-<short-id>-session.tmp`) for any new session file

package/packs/full-harness/rendered/.claude/commands/security-scan.md

@@ -0,0 +1,6 @@
+---
+description: Run AgentShield against agent, hook, MCP, permission, and secret surfaces.
+argument-hint: [optional arguments]
+---
+
+# Security Scan Command Run AgentShield against the current project or a target path, then turn the findings into a prioritized remediation plan. ## Usage `/security-scan [path] [--format text|json|markdown|html] [--min-severity low|medium|high|critical] [--fix]` - `path` (optional): defaults to the current project. Use a `.claude/` path, a repo root, or a checked-in template directory. - `--format`: output format. Use `json` for CI, `markdown` for handoffs, and `html` for standalone review reports. - `--min-severity`: filters lower-priority findings. - `--fix`: applies only AgentShield fixes explicitly marked as safe and auto-fixable. ## Deterministic Engine Prefer the packaged scanner: ```bash npx ecc-agentshield scan --path "${TARGET_PATH:-.}" --format text ``` For local AgentShield development, run from the AgentShield checkout: ```bash npm run scan -- --path "${TARGET_PATH:-.}" --format text ``` Do not invent findings. Use AgentShield output as the source of truth and separate scanner facts from follow-up judgment. ## Review Checklist 1. Identify active runtime findings first: - hardcoded secrets - broad permissions - executable hooks - MCP servers with shell, filesystem, remote transport, or unpinned `npx` - agent prompts that handle untrusted content without defenses 2. Separate lower-confidence inventory: - docs examples - template examples - plugin manifests - project-local optional settings 3. For each critical or high finding, return: - file path - severity - runtime confidence - why it matters - exact remediation - whether it is safe to auto-fix 4. If `--fix` is requested, state the planned edits before applying fixes. 5. Re-run the scan after fixes and report the before/after score. ## Output Contract Return: 1. Security grade and score. 2. Counts by severity and runtime confidence. 3. Critical/high findings with exact paths. 4. Lower-confidence findings grouped separately. 5. A remediation order. 6. Commands run and whether the scan was local, CI, or npx-backed. ## CI Pattern Use AgentShield in GitHub Actions for enforced gates: ```yaml - uses: affaan-m/agentshield@v1 with: path: "." min-severity: "medium" fail-on-findings: true ``` ## Links - Skill: `skills/security-scan/SKILL.md` - Agent: `agents/security-reviewer.md` - Scanner: <https://github.com/affaan-m/agentshield> ## Arguments $ARGUMENTS: - optional target path - optional AgentShield flags

package/packs/full-harness/rendered/.claude/commands/sessions.md

@@ -0,0 +1,6 @@
+---
+description: Manage Claude Code session history, aliases, and session metadata.
+argument-hint: [optional arguments]
+---
+
+# Sessions Command Manage Claude Code session history - list, load, alias, and edit sessions stored in `~/.claude/session-data/` with legacy reads from `~/.claude/sessions/`. ## Usage `/sessions [list|load|alias|info|help] [options]` ## Actions ### List Sessions Display all sessions with metadata, filtering, and pagination. Use `/sessions info` when you need operator-surface context for a swarm: branch, worktree path, and session recency. ```bash /sessions # List all sessions (default) /sessions list # Same as above /sessions list --limit 10 # Show 10 sessions /sessions list --date 2026-02-01 # Filter by date /sessions list --search abc # Search by session ID ``` **Script:** ```bash node -e " const _r = (function(){var p=require('path'),f=require('fs'),o=require('os');var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var d=p.join(o.homedir(),'.claude');function L(x){try{return require(p.join(x,'scripts','lib','resolve-ecc-root')).resolveEccRoot()}catch(_){return null}}var r=L(d);if(r)return r;var s=['ecc','ecc@ecc','marketplaces/ecc','everything-claude-code','everything-claude-code@everything-claude-code','marketplaces/everything-claude-code'];for(var i=0;i<s.length;i++){r=L(p.join(d,'plugins',s[i]));if(r)return r}try{var g=['ecc','everything-claude-code'];for(var j=0;j<g.length;j++){var c=p.join(d,'plugins','cache',g[j]);var O=f.readdirSync(c);for(var k=0;k<O.length;k++){var q=p.join(c,O[k]);var V=f.readdirSync(q);for(var m=0;m<V.length;m++){r=L(p.join(q,V[m]));if(r)return r}}}}catch(_){}return d})(); const sm = require(_r + '/scripts/lib/session-manager'); const aa = require(_r + '/scripts/lib/session-aliases'); const path = require('path'); const result = sm.getAllSessions({ limit: 20 }); const aliases = aa.listAliases(); const aliasMap = {}; for (const a of aliases) aliasMap[a.sessionPath] = a.name; console.log('Sessions (showing ' + result.sessions.length + ' of ' + result.total + '):'); console.log(''); console.log('ID Date Time Branch Worktree Alias'); console.log('────────────────────────────────────────────────────────────────────'); for (const s of result.sessions) { const alias = aliasMap[s.filename] || ''; const metadata = sm.parseSessionMetadata(sm.getSessionContent(s.sessionPath)); const id = s.shortId === 'no-id' ? '(none)' : s.shortId.slice(0, 8); const time = s.modifiedTime.toTimeString().slice(0, 5); const branch = (metadata.branch || '-').slice(0, 12); const worktree = metadata.worktree ? path.basename(metadata.worktree).slice(0, 18) : '-'; console.log(id.padEnd(8) + ' ' + s.date + ' ' + time + ' ' + branch.padEnd(12) + ' ' + worktree.padEnd(18) + ' ' + alias); } " ``` ### Load Session Load and display a session's content (by ID or alias). ```bash /sessions load <id|alias> # Load session /sessions load 2026-02-01 # By date (for no-id sessions) /sessions load a1b2c3d4 # By short ID /sessions load my-alias # By alias name ``` **Script:** ```bash node -e " const _r = (function(){var p=require('path'),f=require('fs'),o=require('os');var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var d=p.join(o.homedir(),'.claude');function L(x){try{return require(p.join(x,'scripts','lib','resolve-ecc-root')).resolveEccRoot()}catch(_){return null}}var r=L(d);if(r)return r;var s=['ecc','ecc@ecc','marketplaces/ecc','everything-claude-code','everything-claude-code@everything-claude-code','marketplaces/everything-claude-code'];for(var i=0;i<s.length;i++){r=L(p.join(d,'plugins',s[i]));if(r)return r}try{var g=['ecc','everything-claude-code'];for(var j=0;j<g.length;j++){var c=p.join(d,'plugins','cache',g[j]);var O=f.readdirSync(c);for(var k=0;k<O.length;k++){var q=p.join(c,O[k]);var V=f.readdirSync(q);for(var m=0;m<V.length;m++){r=L(p.join(q,V[m]));if(r)return r}}}}catch(_){}return d})(); const sm = require(_r + '/scripts/lib/session-manager'); const aa = require(_r + '/scripts/lib/session-aliases'); const id = process.argv[1]; // First try to resolve as alias const resolved = aa.resolveAlias(id); const sessionId = resolved ? resolved.sessionPath : id; const session = sm.getSessionById(sessionId, true); if (!session) { console.log('Session not found: ' + id); process.exit(1); } const stats = sm.getSessionStats(session.sessionPath); const size = sm.getSessionSize(session.sessionPath); const aliases = aa.getAliasesForSession(session.filename); console.log('Session: ' + session.filename); console.log('Path: ' + session.sessionPath); console.log(''); console.log('Statistics:'); console.log(' Lines: ' + stats.lineCount); console.log(' Total items: ' + stats.totalItems); console.log(' Completed: ' + stats.completedItems); console.log(' In progress: ' + stats.inProgressItems); console.log(' Size: ' + size); console.log(''); if (aliases.length > 0) { console.log('Aliases: ' + aliases.map(a => a.name).join(', ')); console.log(''); } if (session.metadata.title) { console.log('Title: ' + session.metadata.title); console.log(''); } if (session.metadata.started) { console.log('Started: ' + session.metadata.started); } if (session.metadata.lastUpdated) { console.log('Last Updated: ' + session.metadata.lastUpdated); } if (session.metadata.project) { console.log('Project: ' + session.metadata.project); } if (session.metadata.branch) { console.log('Branch: ' + session.metadata.branch); } if (session.metadata.worktree) { console.log('Worktree: ' + session.metadata.worktree); } " "$ARGUMENTS" ``` ### Create Alias Create a memorable alias for a session. ```bash /sessions alias <id> <name> # Create alias /sessions alias 2026-02-01 today-work # Create alias named "today-work" ``` **Script:** ```bash node -e " const _r = (function(){var p=require('path'),f=require('fs'),o=require('os');var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var d=p.join(o.homedir(),'.claude');function L(x){try{return require(p.join(x,'scripts','lib','resolve-ecc-root')).resolveEccRoot()}catch(_){return null}}var r=L(d);if(r)return r;var s=['ecc','ecc@ecc','marketplaces/ecc','everything-claude-code','everything-claude-code@everything-claude-code','marketplaces/everything-claude-code'];for(var i=0;i<s.length;i++){r=L(p.join(d,'plugins',s[i]));if(r)return r}try{var g=['ecc','everything-claude-code'];for(var j=0;j<g.length;j++){var c=p.join(d,'plugins','cache',g[j]);var O=f.readdirSync(c);for(var k=0;k<O.length;k++){var q=p.join(c,O[k]);var V=f.readdirSync(q);for(var m=0;m<V.length;m++){r=L(p.join(q,V[m]));if(r)return r}}}}catch(_){}return d})(); const sm = require(_r + '/scripts/lib/session-manager'); const aa = require(_r + '/scripts/lib/session-aliases'); const sessionId = process.argv[1]; const aliasName = process.argv[2]; if (!sessionId || !aliasName) { console.log('Usage: /sessions alias <id> <name>'); process.exit(1); } // Get session filename const session = sm.getSessionById(sessionId); if (!session) { console.log('Session not found: ' + sessionId); process.exit(1); } const result = aa.setAlias(aliasName, session.filename); if (result.success) { console.log('✓ Alias created: ' + aliasName + ' → ' + session.filename); } else { console.log('✗ Error: ' + result.error); process.exit(1); } " "$ARGUMENTS" ``` ### Remove Alias Delete an existing alias. ```bash /sessions alias --remove <name> # Remove alias /sessions unalias <name> # Same as above ``` **Script:** ```bash node -e " const _r = (function(){var p=require('path'),f=require('fs'),o=require('os');var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var d=p.join(o.homedir(),'.claude');function L(x){try{return require(p.join(x,'scripts','lib','resolve-ecc-root')).resolveEccRoot()}catch(_){return null}}var r=L(d);if(r)return r;var s=['ecc','ecc@ecc','marketplaces/ecc','everything-claude-code','everything-claude-code@everything-claude-code','marketplaces/everything-claude-code'];for(var i=0;i<s.length;i++){r=L(p.join(d,'plugins',s[i]));if(r)return r}try{var g=['ecc','everything-claude-code'];for(var j=0;j<g.length;j++){var c=p.join(d,'plugins','cache',g[j]);var O=f.readdirSync(c);for(var k=0;k<O.length;k++){var q=p.join(c,O[k]);var V=f.readdirSync(q);for(var m=0;m<V.length;m++){r=L(p.join(q,V[m]));if(r)return r}}}}catch(_){}return d})(); const aa = require(_r + '/scripts/lib/session-aliases'); const aliasName = process.argv[1]; if (!aliasName) { console.log('Usage: /sessions alias --remove <name>'); process.exit(1); } const result = aa.deleteAlias(aliasName); if (result.success) { console.log('✓ Alias removed: ' + aliasName); } else { console.log('✗ Error: ' + result.error); process.exit(1); } " "$ARGUMENTS" ``` ### Session Info Show detailed information about a session. ```bash /sessions info <id|alias> # Show session details ``` **Script:** ```bash node -e " const _r = (function(){var p=require('path'),f=require('fs'),o=require('os');var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var d=p.join(o.homedir(),'.claude');function L(x){try{return require(p.join(x,'scripts','lib','resolve-ecc-root')).resolveEccRoot()}catch(_){return null}}var r=L(d);if(r)return r;var s=['ecc','ecc@ecc','marketplaces/ecc','everything-claude-code','everything-claude-code@everything-claude-code','marketplaces/everything-claude-code'];for(var i=0;i<s.length;i++){r=L(p.join(d,'plugins',s[i]));if(r)return r}try{var g=['ecc','everything-claude-code'];for(var j=0;j<g.length;j++){var c=p.join(d,'plugins','cache',g[j]);var O=f.readdirSync(c);for(var k=0;k<O.length;k++){var q=p.join(c,O[k]);var V=f.readdirSync(q);for(var m=0;m<V.length;m++){r=L(p.join(q,V[m]));if(r)return r}}}}catch(_){}return d})(); const sm = require(_r + '/scripts/lib/session-manager'); const aa = require(_r + '/scripts/lib/session-aliases'); const id = process.argv[1]; const resolved = aa.resolveAlias(id); const sessionId = resolved ? resolved.sessionPath : id; const session = sm.getSessionById(sessionId, true); if (!session) { console.log('Session not found: ' + id); process.exit(1); } const stats = sm.getSessionStats(session.sessionPath); const size = sm.getSessionSize(session.sessionPath); const aliases = aa.getAliasesForSession(session.filename); console.log('Session Information'); console.log('════════════════════'); console.log('ID: ' + (session.shortId === 'no-id' ? '(none)' : session.shortId)); console.log('Filename: ' + session.filename); console.log('Date: ' + session.date); console.log('Modified: ' + session.modifiedTime.toISOString().slice(0, 19).replace('T', ' ')); console.log('Project: ' + (session.metadata.project || '-')); console.log('Branch: ' + (session.metadata.branch || '-')); console.log('Worktree: ' + (session.metadata.worktree || '-')); console.log(''); console.log('Content:'); console.log(' Lines: ' + stats.lineCount); console.log(' Total items: ' + stats.totalItems); console.log(' Completed: ' + stats.completedItems); console.log(' In progress: ' + stats.inProgressItems); console.log(' Size: ' + size); if (aliases.length > 0) { console.log('Aliases: ' + aliases.map(a => a.name).join(', ')); } " "$ARGUMENTS" ``` ### List Aliases Show all session aliases. ```bash /sessions aliases # List all aliases ``` **Script:** ```bash node -e " const _r = (function(){var p=require('path'),f=require('fs'),o=require('os');var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var d=p.join(o.homedir(),'.claude');function L(x){try{return require(p.join(x,'scripts','lib','resolve-ecc-root')).resolveEccRoot()}catch(_){return null}}var r=L(d);if(r)return r;var s=['ecc','ecc@ecc','marketplaces/ecc','everything-claude-code','everything-claude-code@everything-claude-code','marketplaces/everything-claude-code'];for(var i=0;i<s.length;i++){r=L(p.join(d,'plugins',s[i]));if(r)return r}try{var g=['ecc','everything-claude-code'];for(var j=0;j<g.length;j++){var c=p.join(d,'plugins','cache',g[j]);var O=f.readdirSync(c);for(var k=0;k<O.length;k++){var q=p.join(c,O[k]);var V=f.readdirSync(q);for(var m=0;m<V.length;m++){r=L(p.join(q,V[m]));if(r)return r}}}}catch(_){}return d})(); const aa = require(_r + '/scripts/lib/session-aliases'); const aliases = aa.listAliases(); console.log('Session Aliases (' + aliases.length + '):'); console.log(''); if (aliases.length === 0) { console.log('No aliases found.'); } else { console.log('Name Session File Title'); console.log('─────────────────────────────────────────────────────────────'); for (const a of aliases) { const name = a.name.padEnd(12); const file = (a.sessionPath.length > 30 ? a.sessionPath.slice(0, 27) + '...' : a.sessionPath).padEnd(30); const title = a.title || ''; console.log(name + ' ' + file + ' ' + title); } } " ``` ## Operator Notes - Session files persist `Project`, `Branch`, and `Worktree` in the header so `/sessions info` can disambiguate parallel tmux/worktree runs. - For command-center style monitoring, combine `/sessions info`, `git diff --stat`, and the cost metrics emitted by `scripts/hooks/cost-tracker.js`. ## Arguments $ARGUMENTS: - `list [options]` - List sessions - `--limit <n>` - Max sessions to show (default: 50) - `--date <YYYY-MM-DD>` - Filter by date - `--search <pattern>` - Search in session ID - `load <id|alias>` - Load session content - `alias <id> <name>` - Create alias for session - `alias --remove <name>` - Remove alias - `unalias <name>` - Same as `--remove` - `info <id|alias>` - Show session statistics - `aliases` - List all aliases - `help` - Show this help ## Examples ```bash # List all sessions /sessions list # Create an alias for today's session /sessions alias 2026-02-01 today # Load session by alias /sessions load today # Show session info /sessions info today # Remove alias /sessions alias --remove today # List all aliases /sessions aliases ``` ## Notes - Sessions are stored as markdown files in `~/.claude/session-data/` with legacy reads from `~/.claude/sessions/` - Aliases are stored in `~/.claude/session-aliases.json` - Session IDs can be shortened (first 4-8 characters usually unique enough) - Use aliases for frequently referenced sessions

package/packs/full-harness/rendered/.claude/commands/setup-pm.md

@@ -0,0 +1,6 @@
+---
+description: Configure your preferred package manager (npm/pnpm/yarn/bun)
+argument-hint: [optional arguments]
+---
+
+# Package Manager Setup Configure your preferred package manager for this project or globally. ## Usage ```bash # Detect current package manager node scripts/setup-package-manager.js --detect # Set global preference node scripts/setup-package-manager.js --global pnpm # Set project preference node scripts/setup-package-manager.js --project bun # List available package managers node scripts/setup-package-manager.js --list ``` ## Detection Priority When determining which package manager to use, the following order is checked: 1. **Environment variable**: `CLAUDE_PACKAGE_MANAGER` 2. **Project config**: `.claude/package-manager.json` 3. **package.json**: `packageManager` field 4. **Lock file**: Presence of package-lock.json, yarn.lock, pnpm-lock.yaml, or bun.lockb 5. **Global config**: `~/.claude/package-manager.json` 6. **Fallback**: First available package manager (pnpm > bun > yarn > npm) ## Configuration Files ### Global Configuration ```json // ~/.claude/package-manager.json { "packageManager": "pnpm" } ``` ### Project Configuration ```json // .claude/package-manager.json { "packageManager": "bun" } ``` ### package.json ```json { "packageManager": "pnpm@8.6.0" } ``` ## Environment Variable Set `CLAUDE_PACKAGE_MANAGER` to override all other detection methods: ```bash # Windows (PowerShell) $env:CLAUDE_PACKAGE_MANAGER = "pnpm" # macOS/Linux export CLAUDE_PACKAGE_MANAGER=pnpm ``` ## Run the Detection To see current package manager detection results, run: ```bash node scripts/setup-package-manager.js --detect ```

package/packs/full-harness/rendered/.claude/commands/skill-create.md

@@ -0,0 +1,6 @@
+---
+description: Analyze local git history to extract coding patterns and generate SKILL.md files. Local version of the Skill Creator GitHub App.
+argument-hint: [optional arguments]
+---
+
+# /skill-create - Local Skill Generation Analyze your repository's git history to extract coding patterns and generate SKILL.md files that teach Claude your team's practices. ## Usage ```bash /skill-create # Analyze current repo /skill-create --commits 100 # Analyze last 100 commits /skill-create --output ./skills # Custom output directory /skill-create --instincts # Also generate instincts for continuous-learning-v2 ``` ## What It Does 1. **Parses Git History** - Analyzes commits, file changes, and patterns 2. **Detects Patterns** - Identifies recurring workflows and conventions 3. **Generates SKILL.md** - Creates valid Claude Code skill files 4. **Optionally Creates Instincts** - For the continuous-learning-v2 system ## Analysis Steps ### Step 1: Gather Git Data ```bash # Get recent commits with file changes git log --oneline -n ${COMMITS:-200} --name-only --pretty=format:"%H|%s|%ad" --date=short # Get commit frequency by file git log --oneline -n 200 --name-only | grep -v "^$" | grep -v "^[a-f0-9]" | sort | uniq -c | sort -rn | head -20 # Get commit message patterns git log --oneline -n 200 | cut -d' ' -f2- | head -50 ``` ### Step 2: Detect Patterns Look for these pattern types: | Pattern | Detection Method | |---------|-----------------| | **Commit conventions** | Regex on commit messages (feat:, fix:, chore:) | | **File co-changes** | Files that always change together | | **Workflow sequences** | Repeated file change patterns | | **Architecture** | Folder structure and naming conventions | | **Testing patterns** | Test file locations, naming, coverage | ### Step 3: Generate SKILL.md Output format: ```markdown --- name: {repo-name}-patterns description: Coding patterns extracted from {repo-name} version: 1.0.0 source: local-git-analysis analyzed_commits: {count} --- # {Repo Name} Patterns ## Commit Conventions {detected commit message patterns} ## Code Architecture {detected folder structure and organization} ## Workflows {detected repeating file change patterns} ## Testing Patterns {detected test conventions} ``` ### Step 4: Generate Instincts (if --instincts) For continuous-learning-v2 integration: ```yaml --- id: {repo}-commit-convention trigger: "when writing a commit message" confidence: 0.8 domain: git source: local-repo-analysis --- # Use Conventional Commits ## Action Prefix commits with: feat:, fix:, chore:, docs:, test:, refactor: ## Evidence - Analyzed {n} commits - {percentage}% follow conventional commit format ``` ## GitHub App Integration For advanced features (10k+ commits, team sharing, auto-PRs), use the [Skill Creator GitHub App](https://github.com/apps/skill-creator): - Install: [github.com/apps/skill-creator](https://github.com/apps/skill-creator) - Comment `/skill-creator analyze` on any issue - Receives PR with generated skills ## Related Commands - `/instinct-import` - Import generated instincts - `/instinct-status` - View learned instincts - `/evolve` - Cluster instincts into skills/agents --- *Part of [Everything Claude Code](https://github.com/affaan-m/everything-claude-code)*

package/packs/full-harness/rendered/.claude/commands/skill-health.md

@@ -0,0 +1,6 @@
+---
+description: Show skill portfolio health dashboard with charts and analytics
+argument-hint: [optional arguments]
+---
+
+# Skill Health Dashboard Shows a comprehensive health dashboard for all skills in the portfolio with success rate sparklines, failure pattern clustering, pending amendments, and version history. ## Implementation Run the skill health CLI in dashboard mode: ```bash ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(function(){var p=require('path'),f=require('fs'),o=require('os');var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var d=p.join(o.homedir(),'.claude');function L(x){try{return require(p.join(x,'scripts','lib','resolve-ecc-root')).resolveEccRoot()}catch(_){return null}}var r=L(d);if(r)return r;var s=['ecc','ecc@ecc','marketplaces/ecc','everything-claude-code','everything-claude-code@everything-claude-code','marketplaces/everything-claude-code'];for(var i=0;i<s.length;i++){r=L(p.join(d,'plugins',s[i]));if(r)return r}try{var g=['ecc','everything-claude-code'];for(var j=0;j<g.length;j++){var c=p.join(d,'plugins','cache',g[j]);var O=f.readdirSync(c);for(var k=0;k<O.length;k++){var q=p.join(c,O[k]);var V=f.readdirSync(q);for(var m=0;m<V.length;m++){r=L(p.join(q,V[m]));if(r)return r}}}}catch(_){}return d})();console.log(r)")}" node "$ECC_ROOT/scripts/skills-health.js" --dashboard ``` For a specific panel only: ```bash ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(function(){var p=require('path'),f=require('fs'),o=require('os');var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var d=p.join(o.homedir(),'.claude');function L(x){try{return require(p.join(x,'scripts','lib','resolve-ecc-root')).resolveEccRoot()}catch(_){return null}}var r=L(d);if(r)return r;var s=['ecc','ecc@ecc','marketplaces/ecc','everything-claude-code','everything-claude-code@everything-claude-code','marketplaces/everything-claude-code'];for(var i=0;i<s.length;i++){r=L(p.join(d,'plugins',s[i]));if(r)return r}try{var g=['ecc','everything-claude-code'];for(var j=0;j<g.length;j++){var c=p.join(d,'plugins','cache',g[j]);var O=f.readdirSync(c);for(var k=0;k<O.length;k++){var q=p.join(c,O[k]);var V=f.readdirSync(q);for(var m=0;m<V.length;m++){r=L(p.join(q,V[m]));if(r)return r}}}}catch(_){}return d})();console.log(r)")}" node "$ECC_ROOT/scripts/skills-health.js" --dashboard --panel failures ``` For machine-readable output: ```bash ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(function(){var p=require('path'),f=require('fs'),o=require('os');var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var d=p.join(o.homedir(),'.claude');function L(x){try{return require(p.join(x,'scripts','lib','resolve-ecc-root')).resolveEccRoot()}catch(_){return null}}var r=L(d);if(r)return r;var s=['ecc','ecc@ecc','marketplaces/ecc','everything-claude-code','everything-claude-code@everything-claude-code','marketplaces/everything-claude-code'];for(var i=0;i<s.length;i++){r=L(p.join(d,'plugins',s[i]));if(r)return r}try{var g=['ecc','everything-claude-code'];for(var j=0;j<g.length;j++){var c=p.join(d,'plugins','cache',g[j]);var O=f.readdirSync(c);for(var k=0;k<O.length;k++){var q=p.join(c,O[k]);var V=f.readdirSync(q);for(var m=0;m<V.length;m++){r=L(p.join(q,V[m]));if(r)return r}}}}catch(_){}return d})();console.log(r)")}" node "$ECC_ROOT/scripts/skills-health.js" --dashboard --json ``` ## Usage ``` /skill-health # Full dashboard view /skill-health --panel failures # Only failure clustering panel /skill-health --json # Machine-readable JSON output ``` ## What to Do 1. Run the skills-health.js script with --dashboard flag 2. Display the output to the user 3. If any skills are declining, highlight them and suggest running /evolve 4. If there are pending amendments, suggest reviewing them ## Panels - **Success Rate (30d)** — Sparkline charts showing daily success rates per skill - **Failure Patterns** — Clustered failure reasons with horizontal bar chart - **Pending Amendments** — Amendment proposals awaiting review - **Version History** — Timeline of version snapshots per skill

package/packs/full-harness/rendered/.claude/commands/test-coverage.md

@@ -0,0 +1,6 @@
+---
+description: Analyze coverage, identify gaps, and generate missing tests toward the target threshold.
+argument-hint: [optional arguments]
+---
+
+# Test Coverage Analyze test coverage, identify gaps, and generate missing tests to reach 80%+ coverage. ## Step 1: Detect Test Framework | Indicator | Coverage Command | |-----------|-----------------| | `jest.config.*` or `package.json` jest | `npx jest --coverage --coverageReporters=json-summary` | | `vitest.config.*` | `npx vitest run --coverage` | | `pytest.ini` / `pyproject.toml` pytest | `pytest --cov=src --cov-report=json` | | `Cargo.toml` | `cargo llvm-cov --json` | | `pom.xml` with JaCoCo | `mvn test jacoco:report` | | `go.mod` | `go test -coverprofile=coverage.out ./...` | ## Step 2: Analyze Coverage Report 1. Run the coverage command 2. Parse the output (JSON summary or terminal output) 3. List files **below 80% coverage**, sorted worst-first 4. For each under-covered file, identify: - Untested functions or methods - Missing branch coverage (if/else, switch, error paths) - Dead code that inflates the denominator ## Step 3: Generate Missing Tests For each under-covered file, generate tests following this priority: 1. **Happy path** — Core functionality with valid inputs 2. **Error handling** — Invalid inputs, missing data, network failures 3. **Edge cases** — Empty arrays, null/undefined, boundary values (0, -1, MAX_INT) 4. **Branch coverage** — Each if/else, switch case, ternary ### Test Generation Rules - Place tests adjacent to source: `foo.ts` → `foo.test.ts` (or project convention) - Use existing test patterns from the project (import style, assertion library, mocking approach) - Mock external dependencies (database, APIs, file system) - Each test should be independent — no shared mutable state between tests - Name tests descriptively: `test_create_user_with_duplicate_email_returns_409` ## Step 4: Verify 1. Run the full test suite — all tests must pass 2. Re-run coverage — verify improvement 3. If still below 80%, repeat Step 3 for remaining gaps ## Step 5: Report Show before/after comparison: ``` Coverage Report ────────────────────────────── File Before After src/services/auth.ts 45% 88% src/utils/validation.ts 32% 82% ────────────────────────────── Overall: 67% 84% PASS: ``` ## Focus Areas - Functions with complex branching (high cyclomatic complexity) - Error handlers and catch blocks - Utility functions used across the codebase - API endpoint handlers (request → response flow) - Edge cases: null, undefined, empty string, empty array, zero, negative numbers

package/packs/full-harness/rendered/.claude/commands/update-codemaps.md

@@ -0,0 +1,6 @@
+---
+description: Scan project structure and generate token-lean architecture codemaps.
+argument-hint: [optional arguments]
+---
+
+# Update Codemaps Analyze the codebase structure and generate token-lean architecture documentation. ## Step 1: Scan Project Structure 1. Identify the project type (monorepo, single app, library, microservice) 2. Find all source directories (src/, lib/, app/, packages/) 3. Map entry points (main.ts, index.ts, app.py, main.go, etc.) ## Step 2: Generate Codemaps Create or update codemaps in `docs/CODEMAPS/` (or `.reports/codemaps/`): | File | Contents | |------|----------| | `architecture.md` | High-level system diagram, service boundaries, data flow | | `backend.md` | API routes, middleware chain, service → repository mapping | | `frontend.md` | Page tree, component hierarchy, state management flow | | `data.md` | Database tables, relationships, migration history | | `dependencies.md` | External services, third-party integrations, shared libraries | ### Codemap Format Each codemap should be token-lean — optimized for AI context consumption: ```markdown # Backend Architecture ## Routes POST /api/users → UserController.create → UserService.create → UserRepo.insert GET /api/users/:id → UserController.get → UserService.findById → UserRepo.findById ## Key Files src/services/user.ts (business logic, 120 lines) src/repos/user.ts (database access, 80 lines) ## Dependencies - PostgreSQL (primary data store) - Redis (session cache, rate limiting) - Stripe (payment processing) ``` ## Step 3: Diff Detection 1. If previous codemaps exist, calculate the diff percentage 2. If changes > 30%, show the diff and request user approval before overwriting 3. If changes <= 30%, update in place ## Step 4: Add Metadata Add a freshness header to each codemap: ```markdown <!-- Generated: 2026-02-11 | Files scanned: 142 | Token estimate: ~800 --> ``` ## Step 5: Save Analysis Report Write a summary to `.reports/codemap-diff.txt`: - Files added/removed/modified since last scan - New dependencies detected - Architecture changes (new routes, new services, etc.) - Staleness warnings for docs not updated in 90+ days ## Tips - Focus on **high-level structure**, not implementation details - Prefer **file paths and function signatures** over full code blocks - Keep each codemap under **1000 tokens** for efficient context loading - Use ASCII diagrams for data flow instead of verbose descriptions - Run after major feature additions or refactoring sessions

package/packs/full-harness/rendered/.claude/commands/update-docs.md

@@ -0,0 +1,6 @@
+---
+description: Sync documentation from source-of-truth files such as scripts, schemas, routes, and exports.
+argument-hint: [optional arguments]
+---
+
+# Update Documentation Sync documentation with the codebase, generating from source-of-truth files. ## Step 1: Identify Sources of Truth | Source | Generates | |--------|-----------| | `package.json` scripts | Available commands reference | | `.env.example` | Environment variable documentation | | `openapi.yaml` / route files | API endpoint reference | | Source code exports | Public API documentation | | `Dockerfile` / `docker-compose.yml` | Infrastructure setup docs | ## Step 2: Generate Script Reference 1. Read `package.json` (or `Makefile`, `Cargo.toml`, `pyproject.toml`) 2. Extract all scripts/commands with their descriptions 3. Generate a reference table: ```markdown | Command | Description | |---------|-------------| | `npm run dev` | Start development server with hot reload | | `npm run build` | Production build with type checking | | `npm test` | Run test suite with coverage | ``` ## Step 3: Generate Environment Documentation 1. Read `.env.example` (or `.env.template`, `.env.sample`) 2. Extract all variables with their purposes 3. Categorize as required vs optional 4. Document expected format and valid values ```markdown | Variable | Required | Description | Example | |----------|----------|-------------|---------| | `DATABASE_URL` | Yes | PostgreSQL connection string | `postgres://user:pass@host:5432/db` | | `LOG_LEVEL` | No | Logging verbosity (default: info) | `debug`, `info`, `warn`, `error` | ``` ## Step 4: Update Contributing Guide Generate or update `docs/CONTRIBUTING.md` with: - Development environment setup (prerequisites, install steps) - Available scripts and their purposes - Testing procedures (how to run, how to write new tests) - Code style enforcement (linter, formatter, pre-commit hooks) - PR submission checklist ## Step 5: Update Runbook Generate or update `docs/RUNBOOK.md` with: - Deployment procedures (step-by-step) - Health check endpoints and monitoring - Common issues and their fixes - Rollback procedures - Alerting and escalation paths ## Step 6: Staleness Check 1. Find documentation files not modified in 90+ days 2. Cross-reference with recent source code changes 3. Flag potentially outdated docs for manual review ## Step 7: Show Summary ``` Documentation Update ────────────────────────────── Updated: docs/CONTRIBUTING.md (scripts table) Updated: docs/ENV.md (3 new variables) Flagged: docs/DEPLOY.md (142 days stale) Skipped: docs/API.md (no changes detected) ────────────────────────────── ``` ## Rules - **Single source of truth**: Always generate from code, never manually edit generated sections - **Preserve manual sections**: Only update generated sections; leave hand-written prose intact - **Mark generated content**: Use `<!-- AUTO-GENERATED -->` markers around generated sections - **Don't create docs unprompted**: Only create new doc files if the command explicitly requests it

package/packs/full-harness/rendered/.claude/commands/vue-review.md

@@ -0,0 +1,6 @@
+---
+description: Comprehensive Vue.js code review for Composition API correctness, reactivity, composable patterns, template security, accessibility, and Vue-specific performance. Invokes the vue-reviewer agent (and typescript-reviewer alongside on .vue/.ts changes).
+argument-hint: [optional arguments]
+---
+
+# Vue Code Review This command invokes the **vue-reviewer** agent for Vue-specific code review. For pull requests touching `.vue` files or Vue-containing `.ts`/`.js` files, both `vue-reviewer` and `typescript-reviewer` should run — each owns a distinct lane. ## What This Command Does 1. **Identify Vue Changes**: Find modified `.vue` files and Vue-related `.ts`/`.js` files via `git diff` 2. **Run Lint**: Execute `eslint` with `eslint-plugin-vue` 3. **Typecheck**: Run `vue-tsc --noEmit` or the project's canonical typecheck command 4. **Review Vue Lanes Only**: Reactivity, composables, template security, accessibility, Vue-specific performance 5. **Generate Report**: Categorize issues by severity (CRITICAL / HIGH / MEDIUM) ## When to Use Use `/vue-review` when: - A PR or commit touches `.vue` files - After writing or modifying Vue components, composables, or Pinia stores - Before merging Vue code - Auditing template security (`v-html`, URL bindings) - Reviewing a new composable for correctness - Auditing Vue Router guards and navigation - Reviewing Nuxt server routes or SSR-specific code For pure `.ts`/`.js` changes with no Vue imports, use `/code-review` (general) or invoke `typescript-reviewer` directly. ## Scope vs `/code-review` and TypeScript Review | Tool | Scope | |---|---| | `vue-reviewer` (this command) | Reactivity, composables, template security, a11y, Vue performance, Pinia/Router | | `typescript-reviewer` | Generic TS/JS — `any` abuse, async correctness, Node security | | `security-reviewer` | Project-wide security audit | | `/code-review` | Generic uncommitted-changes or PR review | On a `.vue` / Vue-related PR, invoke both `vue-reviewer` and `typescript-reviewer`. Findings from each are non-overlapping by design. ## Review Categories ### CRITICAL (Must Fix) - `v-html` with unsanitized input - `:href`/`:src` with unvalidated user URLs (`javascript:`, `data:`) - Secret in client bundle (`VITE_*`, Nuxt `public` runtimeConfig) - Server endpoint without input validation (Nuxt Nitro) - `localStorage`/`sessionStorage` for session tokens - Destructuring reactive props in Vue < 3.5 (breaks reactivity) - `reactive()` object replacement (breaks watchers) - Watcher source tracking a ref object instead of `.value` ### HIGH (Should Fix) - Composable with module-scope side effects - Missing cleanup in composable (watcher, interval, listener) - `v-for` without `:key` or with `key={index}` - `v-if` + `v-for` on same element - Props mutation - Missing prop validation - Route guard returning false without redirect - `useRoute().params` destructured at top-level (snapshot) - `v-model` bound to computed without setter - Accessibility violations (missing labels, non-semantic interactive elements) - Direct store property mutation outside actions ### MEDIUM (Consider) - Options API in new Vue 3 code - Component over 300 lines - `v-show` where `v-if` is more appropriate (or vice versa) - Missing `:max` on `<KeepAlive>` - Missing `shallowRef` for large replaced data - Custom validation instead of vetted form library - `defineExpose` exposing more than necessary - `inheritAttrs` not disabled when using `v-bind="$attrs"` ## Automated Checks Run ```bash # Lint (required) npx eslint . --ext .vue,.ts,.js # Vue-specific typecheck vue-tsc --noEmit # Targeted security rules npx eslint . --rule 'vue/no-v-html: warn' \ --rule 'vue/no-template-target-blank: error' # Supply-chain npm audit ``` If `eslint-plugin-vue` or `vue-tsc` is not configured, the review will flag the gap as a HIGH config issue and continue. ## Example Usage ````text User: /vue-review Agent: # Vue Code Review Report ## Files Reviewed - src/components/UserCard.vue (modified) - src/composables/useUser.ts (new) - src/stores/useUserStore.ts (modified) ## Lint Results PASS: eslint clean PASS: vue-tsc clean ## Issues Found [CRITICAL] Unsanitized v-html File: src/components/UserCard.vue:15 Issue: User-controlled bio rendered as raw HTML via v-html. Why: XSS via stored script tags in user input. Fix: Sanitize with DOMPurify or render as text: ```vue <script setup> import DOMPurify from "dompurify"; const safeBio = computed(() => DOMPurify.sanitize(user.bio)); </script> <template> <div v-html="safeBio" /> </template> ``` [HIGH] Watcher in composable missing cleanup File: src/composables/useUser.ts:22 Issue: `watch` callback fires fetch without AbortController; stale responses can overwrite newer data. Fix: Use onCleanup to abort: ```ts watch(userId, async (newId, _old, onCleanup) => { const controller = new AbortController(); onCleanup(() => controller.abort()); const data = await fetch(`/api/users/${newId}`, { signal: controller.signal }); user.value = await data.json(); }); ``` ## Summary - CRITICAL: 1 - HIGH: 1 - MEDIUM: 0 Recommendation: FAIL: Block merge until CRITICAL issue is fixed ```` ## Approval Criteria | Status | Condition | |---|---| | PASS: Approve | No CRITICAL or HIGH issues | | WARNING: Warning | Only MEDIUM issues (merge with caution) | | FAIL: Block | CRITICAL or HIGH issues found | ## Integration with Other Commands - Run your project's build command first if the build is broken - Run tests to ensure component tests pass - Run `/vue-review` before merging Vue code - Use `/code-review` for non-Vue-specific concerns on the same PR ## Related - Agent: `agents/vue-reviewer.md` - Companion agent: `agents/typescript-reviewer.md` (run alongside for Vue-related TS/JS) - Skills: `skills/vue-patterns/` - Rules: `rules/vue/`

package/packs/full-harness/rendered/.claude/skills/accessibility/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: accessibility
+description: Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA
+---
+
+# Accessibility (WCAG 2.2)
+
+This skill ensures that digital interfaces are Perceivable, Operable, Understandable, and Robust (POUR) for all users, including those using screen readers, switch controls, or keyboard navigation. It focuses on the technical implementation of WCAG 2.2 success criteria.
+
+## When to Use
+
+- Defining UI component specifications for Web, iOS, or Android.
+- Auditing existing code for accessibility barriers or compliance gaps.
+- Implementing new WCAG 2.2 standards like Target Size (Minimum) and Focus Appearance.
+- Mapping high-level design requirements to technical attributes (ARIA roles, traits, hints).
+
+## Core Concepts
+
+- **POUR Principles**: The foundation of WCAG (Perceivable, Operable, Understandable, Robust).
+- **Semantic Mapping**: Using native elements over generic containers to provide built-in accessibility.
+- **Accessibility Tree**: The representation of the UI that assistive technologies actually "read."
+- **Focus Management**: Controlling the order and visibility of the keyboard/screen reader cursor.
+- **Labeling & Hints**: Providing context through `aria-label`, `accessibilityLabel`, and `contentDescription`.
+
+## How It Works
+
+### Step 1: Identify the Component Role
+
+Determine the functional purpose (e.g., Is this a button, a link, or a tab?). Use the most semantic native element available before resorting to custom roles.
+
+### Step 2: Define Perceivable Attributes
+
+- Ensure text contrast meets **4.5:1** (normal) or **3:1** (large/UI).
+- Add text alternatives for non-text content (images, icons).
+- Implement responsive reflow (up to 400% zoom without loss of function).
+
+### Step 3: Implement Operable Controls
+
+- Ensure a minimum **24x24 CSS pixel** target size (WCAG 2.2 SC 2.5.8).
+- Verify all interactive elements are reachable via keyboard and have a visible focus indicator (SC 2.4.11).
+- Provide single-pointer alternatives for dragging movements.
+
+### Step 4: Ensure Understandable Logic
+
+- Use consistent navigation patterns.
+- Provide descriptive error messages and suggestions for correction (SC 3.3.3).
+- Implement "Redundant Entry" (SC 3.3.7) to prevent asking for the same data twice.
+
+### Step 5: Verify Robust Compatibility
+
+- Use correct `Name, Role, Value` patterns.
+- Implement `aria-live` or live regions for dynamic status updates.
+
+## Accessibility Architecture Diagram
+
+```mermaid
+flowchart TD
+  UI["UI Component"] --> Platform{Platform?}
+  Platform -->|Web| ARIA["WAI-ARIA + HTML5"]
+  Platform -->|iOS| SwiftUI["Accessibility Traits + Labels"]
+  Platform -->|Android| Compose["Semantics + ContentDesc"]
+
+  ARIA --> AT["Assistive Technology (Screen Readers, Switches)"]
+  SwiftUI --> AT
+  Compose --> AT
+```
+
+## Cross-Platform Mapping
+
+| Feature            | Web (HTML/ARIA)          | iOS (SwiftUI)                        | Android (Compose)                                           |
+| :----------------- | :----------------------- | :----------------------------------- | :---------------------------------------------------------- |
+| **Primary Label**  | `aria-label` / `<label>` | `.accessibilityLabel()`              | `contentDescription`                                        |
+| **Secondary Hint** | `aria-describedby`       | `.accessibilityHint()`               | `Modifier.semantics { stateDescription = ... }`             |
+| **Action Role**    | `role="button"`          | `.accessibilityAddTraits(.isButton)` | `Modifier.semantics { role = Role.Button }`                 |
+| **Live Updates**   | `aria-live="polite"`     | `.accessibilityLiveRegion(.polite)`  | `Modifier.semantics { liveRegion = LiveRegionMode.Polite }` |
+
+## Examples
+
+### Web: Accessible Search
+
+```html
+<form role="search">
+  <label for="search-input" class="sr-only">Search products</label>
+  <input type="search" id="search-input" placeholder="Search..." />
+  <button type="submit" aria-label="Submit Search">
+    <svg aria-hidden="true">...</svg>
+  </button>
+</form>
+```
+
+### iOS: Accessible Action Button
+
+```swift
+Button(action: deleteItem) {
+    Image(systemName: "trash")
+}
+.accessibilityLabel("Delete item")
+.accessibilityHint("Permanently removes this item from your list")
+.accessibilityAddTraits(.isButton)
+```
+
+### Android: Accessible Toggle
+
+```kotlin
+Switch(
+    checked = isEnabled,
+    onCheckedChange = { onToggle() },
+    modifier = Modifier.semantics {
+        contentDescription = "Enable notifications"
+    }
+)
+```
+
+## Anti-Patterns to Avoid
+
+- **Div-Buttons**: Using a `<div>` or `<span>` for a click event without adding a role and keyboard support.
+- **Color-Only Meaning**: Indicating an error or status _only_ with a color change (e.g., turning a border red).
+- **Uncontained Modal Focus**: Modals that don't trap focus, allowing keyboard users to navigate background content while the modal is open. Focus must be contained _and_ escapable via the `Escape` key or an explicit close button (WCAG SC 2.1.2).
+- **Redundant Alt Text**: Using "Image of..." or "Picture of..." in alt text (screen readers already announce the role "Image").
+
+## Best Practices Checklist
+
+- [ ] Interactive elements meet the **24x24px** (Web) or **44x44pt** (Native) target size.
+- [ ] Focus indicators are clearly visible and high-contrast.
+- [ ] Modals **contain focus** while open, and release it cleanly on close (`Escape` key or close button).
+- [ ] Dropdowns and menus restore focus to the trigger element on close.
+- [ ] Forms provide text-based error suggestions.
+- [ ] All icon-only buttons have a descriptive text label.
+- [ ] Content reflows properly when text is scaled.
+
+## References
+
+- [WCAG 2.2 Guidelines](https://www.w3.org/TR/WCAG22/)
+- [WAI-ARIA Authoring Practices](https://www.w3.org/TR/wai-aria-practices/)
+- [iOS Accessibility Programming Guide](https://developer.apple.com/documentation/accessibility)
+- [iOS Human Interface Guidelines - Accessibility](https://developer.apple.com/design/human-interface-guidelines/accessibility)
+- [Android Accessibility Developer Guide](https://developer.android.com/guide/topics/ui/accessibility)
+
+## Related Skills
+
+- `frontend-patterns`
+- `design-system`
+- `liquid-glass-design`
+- `swiftui-patterns`