AI Configs

.claude/skills/changelog/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: Write Changelog
+description: Write a concise developer changelog focused on breaking changes and new features with before/after examples
+---
+
+## Write Changelog
+
+Write a changelog entry for the current branch or a specified set of commits.
+
+### Steps
+
+1. Determine scope: use `git log main..HEAD --oneline` (or the specified range) to identify commits.
+2. For each changed file, use `detect_changes` to identify what shifted and its risk level.
+3. Identify breaking changes: anything that removes or renames a public symbol, changes a function signature, alters config structure, or requires a migration step.
+4. Identify new features: new public APIs, new CLI flags, new config fields, new behaviour behind existing APIs.
+5. Skip internal refactors, test-only changes, and lint fixes unless they affect callers.
+6. Write the file to `changelog/YYYY-MM-DD_<slug>.md` using today's date (check current date from the environment or `date +%F`).
+
+### Output Format
+
+```
+# <Short title — what shipped>
+
+## Summary
+
+One or two sentences. What changed and why.
+
+---
+
+## Breaking change: <what broke>
+
+<Concise explanation. One paragraph max.>
+
+| What | Before | After |
+|------|--------|-------|
+| ... | ... | ... |
+
+Before:
+```go
+// old usage
+```
+
+After:
+```go
+// new usage
+```
+
+---
+
+## New: <feature name>
+
+<Concise explanation.>
+
+```go
+// minimal usage example
+```
+
+---
+
+## Bug fixes
+
+- **<Component>**: one-line description.
+
+---
+
+## Recommended additions  *(optional)*
+
+- Doc or test gaps worth filing.
+```
+
+### Rules
+
+- **Brief**: each section should fit on a screen. Cut prose, not examples.
+- **Examples first**: before/after code blocks beat paragraph explanations.
+- **Breaking changes go first**, even if there are many new features.
+- **Omit sections** that have no content — don't write empty headers.
+- File name slug is lowercase, words separated by underscores, ≤5 words (e.g. `2026-04-27_executor_jd_migration.md`).
+- Use the before/after table for structural changes (config shape, struct fields, interface methods); use code blocks for API or invocation changes.

.claude/skills/debug-issue/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: Debug Issue
+description: Systematically debug issues using graph-powered code navigation
+---
+
+## Debug Issue
+
+Use the knowledge graph to systematically trace and debug issues.
+
+### Steps
+
+1. Use `semantic_search_nodes` to find code related to the issue.
+2. Use `query_graph` with `callers_of` and `callees_of` to trace call chains.
+3. Use `get_flow` to see full execution paths through suspected areas.
+4. Run `detect_changes` to check if recent changes caused the issue.
+5. Use `get_impact_radius` on suspected files to see what else is affected.
+
+### Tips
+
+- Check both callers and callees to understand the full context.
+- Look at affected flows to find the entry point that triggers the bug.
+- Recent changes are the most common source of new issues.
+
+## Token Efficiency Rules
+- ALWAYS start with `get_minimal_context(task="<your task>")` before any other graph tool.
+- Use `detail_level="minimal"` on all calls. Only escalate to "standard" when minimal is insufficient.
+- Target: complete any review/debug/refactor task in ≤5 tool calls and ≤800 total output tokens.

.claude/skills/integration-tests/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: Integration Tests
+description: Run local devenv integration/smoke tests, including Chainlink node (-cl) variants
+---
+
+## Integration Tests
+
+All commands run from `build/devenv` unless noted otherwise.
+
+### Test matrix (from CI workflows)
+
+**Standalone tests** (`test-smoke.yaml`):
+- `TestE2ESmoke_Basic` — profile: `standard.profile`
+- `TestE2ESmoke_Basic_OneExecPerChain` — profile: `standard.one-exec-per-chain.profile`
+- `TestE2ESmoke_TokenVerification` — profile: `standard.profile`
+- `TestE2ESmoke_ExtraArgsV2` — profile: `standard.profile`
+- `TestE2ESmoke_ChainStatus` — profile: `standard.profile`
+- `TestE2ESmoke_JobQueue` — profile: `standard.profile`
+- `TestE2ESmoke_Replay` — profile: `standard.profile`
+- `TestE2EReorg` — profile: `standard.src-auto-mine.profile`
+- `TestChaos_AggregatorOutageRecovery` — profile: `standard.profile`
+- Phased `TestE2ESmoke_Basic` — profile: `phased.profile`
+
+**Chainlink node tests** (`test-cl-smoke.yaml`):
+- `TestE2ESmoke_Basic` — profile: `standard.clnode.profile`
+- `TestE2ESmoke_Basic_OneExecPerChain` — profile: `standard.one-exec-per-chain.profile` (clnode variant)
+- `TestE2ESmoke_TokenVerification` — profile: `standard.clnode.profile`
+- `TestE2ESmoke_ExtraArgsV2` — profile: `standard.clnode.profile`
+- `TestHA_CrossComponentDown` — profile: `standard.ha.clnode.profile`
+- Phased `TestE2ESmoke_Basic` — profile: `phased.clnode.profile`
+
+When the user describes a CI failure, match it to the test name and profile above to know what to run locally.
+
+---
+
+### The preferred way: `ccv test`
+
+`ccv test` handles build, env startup, and test execution in one command. Run from `build/devenv`.
+
+```bash
+# Full cycle (build images, start env, run test, all output to log):
+ccv test --profile standard.clnode.profile --pattern TestE2ESmoke_Basic --timeout 20m --log /tmp/test.log
+
+# Skip rebuild if images are already up-to-date:
+ccv test --profile standard.profile --pattern TestE2ESmoke_Basic --build=false --log /tmp/test.log
+
+# Named suite aliases (no --pattern needed):
+ccv test smoke --profile standard.profile --log /tmp/test.log
+ccv test load  --profile standard.profile --log /tmp/test.log
+
+# Against an already-running environment (no profile, no build):
+ccv test --pattern TestE2ESmoke_Basic --build=false --log /tmp/test.log
+```
+
+**Key flags:**
+
+| Flag | Default | Notes |
+|------|---------|-------|
+| `--profile` | — | Profile file (`.profile`) that selects env config + type |
+| `--pattern` | — | Raw Go test pattern; mutually exclusive with suite name |
+| `--build` | `true` | Build Docker images first; pass `--build=false` to skip |
+| `--timeout` | `0` (unlimited) | Go test timeout |
+| `--log <path>` | — | Write ALL output to file; terminal shows only progress lines |
+
+The `--log` flag redirects at the OS fd level — it captures docker build output, env startup, CTF framework subprocess output, and go test output. Always use it when running from Claude Code to avoid token-heavy output.
+
+> ⚠️ Do NOT use CI-only profiles (e.g. `standard.clnode.ci.profile`) locally — they reference CI-specific image tags and paths that fail locally. Use the non-CI variants (`standard.clnode.profile`, `phased.clnode.profile`, etc.).
+
+---
+
+### Manual steps (if not using `ccv test`)
+
+#### 1. Rebuild Docker images
+
+```bash
+ccv down
+just build-docker-dev
+```
+
+#### 2. For Chainlink node (-cl) tests only: update the chainlink repo
+
+The `-cl` environment loads the `chainlink` repo from the directory next to `chainlink-ccv`. It must reference the current commit of this repo.
+
+```bash
+COMMIT=$(git -C /path/to/chainlink-ccv rev-parse HEAD)
+cd /path/to/chainlink   # must be a sibling of chainlink-ccv
+go get github.com/smartcontractkit/chainlink-ccv@$COMMIT
+gomods tidy
+```
+
+#### 3. Start the environment
+
+```bash
+ccv up --profile standard.profile
+ccv up --profile standard.clnode.profile    # CL node variant
+ccv up --profile phased.profile             # phased runtime
+```
+
+Only one environment at a time — overlapping startups collide on Docker resources.
+
+#### 4. Run the tests
+
+```bash
+cd build/devenv/tests/e2e
+go test -v -timeout 15m -count=1 -run TestE2ESmoke_Basic
+```

.kiro/steering/code-review-graph.md

@@ -0,0 +1,38 @@
+<!-- code-review-graph MCP tools -->
+## MCP Tools: code-review-graph
+
+**IMPORTANT: This project has a knowledge graph. ALWAYS use the
+code-review-graph MCP tools BEFORE using Grep/Glob/Read to explore
+the codebase.** The graph is faster, cheaper (fewer tokens), and gives
+you structural context (callers, dependents, test coverage) that file
+scanning cannot.
+
+### When to use graph tools FIRST
+
+- **Exploring code**: `semantic_search_nodes` or `query_graph` instead of Grep
+- **Understanding impact**: `get_impact_radius` instead of manually tracing imports
+- **Code review**: `detect_changes` + `get_review_context` instead of reading entire files
+- **Finding relationships**: `query_graph` with callers_of/callees_of/imports_of/tests_for
+- **Architecture questions**: `get_architecture_overview` + `list_communities`
+
+Fall back to Grep/Glob/Read **only** when the graph doesn't cover what you need.
+
+### Key Tools
+
+| Tool | Use when |
+|------|----------|
+| `detect_changes` | Reviewing code changes — gives risk-scored analysis |
+| `get_review_context` | Need source snippets for review — token-efficient |
+| `get_impact_radius` | Understanding blast radius of a change |
+| `get_affected_flows` | Finding which execution paths are impacted |
+| `query_graph` | Tracing callers, callees, imports, tests, dependencies |
+| `semantic_search_nodes` | Finding functions/classes by name or keyword |
+| `get_architecture_overview` | Understanding high-level codebase structure |
+| `refactor_tool` | Planning renames, finding dead code |
+
+### Workflow
+
+1. The graph auto-updates on file changes (via hooks).
+2. Use `detect_changes` for code review.
+3. Use `get_affected_flows` to understand impact.
+4. Use `query_graph` pattern="tests_for" to check coverage.

.mcp.json

@@ -0,0 +1,11 @@
+{
+  "mcpServers": {
+    "code-review-graph": {
+      "command": "code-review-graph",
+      "args": [
+        "serve"
+      ],
+      "type": "stdio"
+    }
+  }
+}