anthropics-claude-automation-recommender

gistfile1.txt

❯ /anthropics-claude-automation-recommender

⏺ I'll analyze your Newton Prover AVS codebase to recommend the most valuable Claude Code automations.

  Read 1 file (ctrl+o to expand)

⏺ Bash(ls Cargo.toml package.json 2>/dev/null; echo "---TOOLS---"; cat Makefile | head -30; echo "---HOOKS---"; cat
      .claude/settings.json 2>/dev/null | python3 -c "imp…)
  ⎿  Error: Exit code 1
            Cargo.toml
     ---TOOLS---
     # Core targets
     .PHONY: run operator admin fund_operators build build-pr pr check fmt fmt-check clippy gitleaks check-foundry-version
     install-foundry
     .PHONY: generate-bindings generate-version build-circuits version-bump

     # Contract deployment
     .PHONY: deploy-avs deploy-eigenlayer deploy-all deploy-succinct deploy-multichain-source
     .PHONY: deploy-policy-and-data-factory deploy-test-policy deploy-policy deploy-policy-client deploy-uam-permissions
     … +25 lines (ctrl+o to see all)

  Searched for 2 patterns, read 1 file (ctrl+o to expand)

⏺ Bash(cat /Users/denniswon/projects/newton-prover-avs/.mcp.json 2>/dev/null | head -60; echo "---GLOBAL MCP---"; cat
      /Users/denniswon/.claude/.mcp.json 2>/dev/null |…)
  ⎿  ---GLOBAL MCP---
     MCP_DOCKER
     ai_validation_auto
     … +14 lines (ctrl+o to expand)

  Read 1 file (ctrl+o to expand)

⏺ Bash(wc -l /Users/denniswon/projects/newton-prover-avs/Makefile; echo "---"; grep -c '\.rs$' <(find
      /Users/denniswon/projects/newton-prover-avs/crates -name '*.rs' 2…)
  ⎿      1827 /Users/denniswon/projects/newton-prover-avs/Makefile
     ---
     223
     … +6 lines (ctrl+o to expand)

⏺ Now I have a complete picture. Here are the recommendations:

  ---
  Claude Code Automation Recommendations

  Codebase Profile

  - Type: Rust (nightly) + Solidity 0.8.x monorepo
  - Framework: Tokio/Axum/jsonrpsee (Rust), Foundry (Solidity)
  - Scale: 223 Rust files, 43 Solidity contracts, 1827-line Makefile
  - Key Libraries: alloy, eigensdk, sqlx, moka, redis, sp1-zkvm
  - Existing Automations: 3 agents (pr-reviewer, perf-rust, vision), 1 skill (prompt-engineering), no hooks, extensive permissions list
  - MCP Servers: context7, linear, notion, recall-local, filesystem, sequential-thinking, and more (global)

  ---
  ★ Insight ─────────────────────────────────────
  Your setup is heavy on MCP servers and agents but has zero hooks — the biggest automation gap. Hooks are the lowest-effort,
  highest-impact automation because they run automatically on every tool use without you thinking about it. Your
  .claude/rules/lessons.md documents recurring mistakes (stale bindings, formatting, .unwrap() usage) that hooks can prevent
  mechanically.
  ─────────────────────────────────────────────────

  ---
  Hooks (Biggest Gap)

  1. Auto-format on file edit

  Your feedback_always_run_fmt.md memory says to always run make fmt before commits. A PostToolUse hook eliminates forgetting.

  Where: .claude/settings.json → add hooks key

  {
    "hooks": {
      "PostToolUse": [
        {
          "matcher": "Edit|Write",
          "command": "if echo \"$TOOL_INPUT\" | grep -q '\\.rs\"'; then cargo fmt --quiet 2>/dev/null; elif echo \"$TOOL_INPUT\" | grep
  -q '\\.sol\"'; then cd contracts && forge fmt --quiet 2>/dev/null; fi",
          "timeout": 10000
        }
      ]
    }
  }

  Why: Your memory, CLAUDE.md, and rules all emphasize make fmt before commits. This runs silently after every Rust/Solidity file edit —
   zero cost, prevents every formatting nit.

  2. Block edits to auto-generated files

  .claude/rules/agent-guide.md and CLAUDE.md both say "NEVER edit crates/core/src/generated/*.rs or contracts/lib/". A PreToolUse hook
  enforces this mechanically.

  {
    "hooks": {
      "PreToolUse": [
        {
          "matcher": "Edit|Write",
          "command": "if echo \"$TOOL_INPUT\" | grep -qE '(crates/core/src/generated/|contracts/lib/)'; then echo 'BLOCKED:
  Auto-generated file. Run make generate-bindings instead.' >&2; exit 1; fi",
          "timeout": 5000
        }
      ]
    }
  }

  Why: This is a hard invariant in your project. Instead of relying on CLAUDE.md instructions (which I can still accidentally violate),
  a hook makes it physically impossible.

  ---
  Skills

  1. e2e — Unified E2E test runner

  Your Makefile has 15+ E2E targets with complex env var combinations. A skill wrapping the common scenarios saves context and prevents
  mistakes.

  Create: .claude/skills/e2e.md

  ---
  name: e2e
  description: "Run E2E tests with scenario presets. Usage: /e2e [scenario] [options]. Scenarios: basic, full, privacy, privacy-full,
  routing, threshold, frost, watcher, multichain-watcher, challenger. Options: force, skip_registration, two_phase_consensus,
  validate_attestation, privacy."
  ---

  Run the appropriate E2E test based on the scenario argument.

  Scenario mappings:
  - `basic` → `make e2e scenario=basic`
  - `full` → `make e2e scenario=full`
  - `privacy` → `make e2e scenario=privacy`
  - `privacy-full` → `make e2e scenario=privacy-full`
  - `routing` → `make e2e scenario=routing`
  - `threshold` → `make threshold-e2e`
  - `frost` → `make threshold-e2e frost=true`
  - `watcher` → `make test-onchain-direct-e2e`
  - `multichain-watcher` → `make test-multichain-onchain-direct-e2e`
  - `challenger` → `make challenger-e2e`

  Append any additional options as make variables (e.g., `force=true`).

  Before running, verify prerequisites:
  1. Check if anvil containers are running (`docker ps | grep anvil`)
  2. Check if Postgres is running (`docker ps | grep postgres`)
  3. Check if Redis is running for watcher scenarios (`docker ps | grep redis`)

  If prerequisites are missing, start them with `make local-dev` or `make dual-anvil` as appropriate.

  After the test completes, summarize: pass/fail, duration, and any error context.

  Why: Your testing.md documents 30+ test commands with intricate env var interactions. This skill encapsulates the decision tree so
  /e2e frost just works instead of remembering make threshold-e2e frost=true.

  2. deploy — Contract deployment with safety checks

  ---
  name: deploy
  description: "Deploy contracts with environment safety checks. Usage: /deploy [target] [chain_id] [env]. Targets: avs,
  multichain-source, all. Validates env, chain_id, and confirms before broadcast."
  disable-model-invocation: true
  ---

  Deploy contracts with pre-flight safety checks.

  ALWAYS perform these checks before deploying:
  1. Verify `DEPLOYMENT_ENV` matches the target (stagef/prod)
  2. Verify chain_id is correct for the target network
  3. Run `make generate-bindings` if any .sol files changed since last build
  4. Show the deployment command and ASK FOR CONFIRMATION before running

  Deployment commands:
  - `avs` → `make deploy-avs chain_id={chain_id} env={env} upgrade=true`
  - `multichain-source` → `make deploy-multichain-source chain_id={chain_id} env={env} upgrade=true`
  - `all` → `make deploy-all`

  For production (env=prod): REQUIRE explicit confirmation with chain name.
  After deployment: remind to run `make transport-sync` if cross-chain contracts changed.

  Why: Your lessons.md documents multiple deployment gotchas (stale BN254TableCalculator, ECDSAOperatorTableUpdater owner mismatch).
  This skill codifies the safety checklist so deployments don't silently break cross-chain flows. disable-model-invocation: true ensures
   it's user-triggered only — deployments should never be autonomous.

  ---
  Subagents

  1. solidity-security agent

  You already have pr-reviewer (Rust-focused) and perf-rust. The gap is Solidity-specific security review — critical given the slashing,
   challenge, and cross-chain flows.

  Create: .claude/agents/solidity-security.md

  ---
  name: solidity-security
  description: |
    Solidity security specialist for Newton Prover AVS contracts.
    Reviews for: reentrancy, access control, cross-chain replay,
    selector collision, hash encoding mismatches, slashing invariants,
    and EIP-170 size limits. Knows Newton-specific gotchas from lessons.md.

    USE THIS AGENT:
    - When modifying contracts/src/*.sol
    - Before deploying upgraded contracts
    - When adding new slashing or challenge paths
    - When changing struct layouts used in function parameters

  tools:
    - Read
    - Grep
    - Glob
    - Bash
  model: opus
  ---

  You are a Solidity security reviewer for Newton Prover AVS.

  ## Newton-Specific Checks (from lessons.md)
  1. Struct changes break selectors silently — verify all callers
  2. Hash encodings must match across storage paths (abi.encode vs TaskLib.taskHash)
  3. Cross-chain slashing must mirror same-chain validation (ZK proof binding + BLS cert)
  4. Dedup keys must be content-addressed, not caller-supplied
  5. All time-dependent fields must be in identity hashes
  6. expireAfter == 0 creates DOA attestations
  7. raiseAndResolveChallenge has known hash mismatch — use slashForCrossChainChallenge

  ## Review Process
  1. Read the changed .sol files
  2. Check for the Newton-specific gotchas above
  3. Run `forge build --sizes` to check EIP-170 limits
  4. Grep for selector usage of any changed function signatures
  5. Report findings with file:line references

  Why: Your lessons.md has 8+ Solidity-specific gotchas (selector mismatches, hash encoding, cross-chain replay). These are
  Newton-specific — generic security scanners miss them. This agent encodes your hard-won institutional knowledge.

  ---
  MCP Servers

  You already have a strong MCP setup (context7, linear, notion, recall-local). Two additions specific to this codebase:

  1. Sentry MCP (if using Sentry for error tracking)

  If Newton uses Sentry in production, the Sentry MCP server lets you investigate production errors directly from Claude Code —
  correlating stack traces to the codebase.

  2. Datadog MCP (already configured globally)

  You have datadog in your deferred tools. Make sure it's configured with the right API keys for Newton's monitoring. This lets you
  check latency dashboards and error rates when debugging performance issues — directly relevant given the sub-millisecond hot path
  targets.

  ---
  Summary of Recommendations

  ┌───────┬───────────────────────────────────────┬──────────────────────────────────────────────────┬────────┐
  │ Type  │            Recommendation             │                      Impact                      │ Effort │
  ├───────┼───────────────────────────────────────┼──────────────────────────────────────────────────┼────────┤
  │ Hook  │ Auto-format on edit (Rust + Solidity) │ Eliminates all formatting nits                   │ 5 min  │
  ├───────┼───────────────────────────────────────┼──────────────────────────────────────────────────┼────────┤
  │ Hook  │ Block edits to generated files        │ Prevents a documented recurring mistake          │ 5 min  │
  ├───────┼───────────────────────────────────────┼──────────────────────────────────────────────────┼────────┤
  │ Skill │ /e2e unified test runner              │ Simplifies 15+ test commands to one              │ 10 min │
  ├───────┼───────────────────────────────────────┼──────────────────────────────────────────────────┼────────┤
  │ Skill │ /deploy with safety checks            │ Prevents deployment gotchas from lessons.md      │ 10 min │
  ├───────┼───────────────────────────────────────┼──────────────────────────────────────────────────┼────────┤
  │ Agent │ solidity-security reviewer            │ Catches Newton-specific contract vulnerabilities │ 15 min │
  └───────┴───────────────────────────────────────┴──────────────────────────────────────────────────┴────────┘

  ★ Insight ─────────────────────────────────────
  The hooks are the highest-ROI items here. Your project already has excellent documentation (CLAUDE.md, rules/, lessons.md) — but
  documentation is advisory, hooks are enforcement. The auto-format hook alone would have prevented every "please run make fmt" feedback
   loop in your history. The generated-file block hook prevents a class of mistakes that your CLAUDE.md warns about in bold but can
  still happen under context pressure.
  ─────────────────────────────────────────────────

  ---
  Want me to implement any of these? I can set up the hooks in settings.json or create the skill/agent files. You can also ask for more
  recommendations in any specific category (e.g., "more hooks" or "more skills for the Makefile targets").