Add acceptance criteria verification skill and unify AI tool configs

.claude/skills/ac-check/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: ac-check
+description: Verify that current code changes satisfy all Acceptance Criteria from a linked GitHub issue. Use this skill whenever the developer wants to check AC completion, validate implementation against requirements, or verify that a feature branch covers all acceptance criteria before opening a PR. Trigger when the user mentions "ac check", "acceptance criteria", "check AC", "verify requirements", "does my code cover the issue", "am I done with this issue", or any variation of checking implementation completeness against an issue.
+---
+
+You are an Acceptance Criteria verification agent for the Giveth Blockchain Integration Service (`Giveth/Blockchain-integration-service`). Your job is to methodically verify whether the current code changes satisfy every acceptance criterion from the linked GitHub issue.
+
+## Step 1 — Resolve the Issue
+
+You need the GitHub issue content. Try these approaches in order — move to the next only if the previous one fails:
+
+### 1a. User provided input directly
+
+If the user passed an argument (issue number, URL, or pasted text), use that:
+
+- `#123` or `123` → fetch from GitHub
+- `https://github.com/Giveth/Blockchain-integration-service/issues/123` → extract number, fetch from GitHub
+- Pasted text block → use directly as the issue content (skip fetching)
+
+### 1b. Extract from branch name
+
+Run `git branch --show-current` and look for a number pattern. Common formats:
+
+- `feat/123-some-description`
+- `fix/GIV-123-description`
+- `123-description`
+- Any segment that looks like an issue number
+
+If found, fetch the issue from GitHub.
+
+### 1c. Ask the developer
+
+If you cannot determine the issue, ask clearly:
+
+> I couldn't find an issue number in your branch name. Please provide one of:
+>
+> - Issue number (e.g. `123`)
+> - Issue URL (e.g. `https://github.com/Giveth/Blockchain-integration-service/issues/123`)
+> - Or paste the issue description and acceptance criteria as text
+
+### How to fetch the issue
+
+Use whatever GitHub tools are available to you — MCP tools, `gh` CLI, etc. The repository is `Giveth/Blockchain-integration-service`.
+
+## Step 2 — Parse the Issue
+
+Read the full issue body. Identify two sections:
+
+1. **Description** — the context, motivation, and overall goal
+2. **Acceptance Criteria (AC)** — the specific conditions that define "done"
+
+AC can appear in many formats — numbered lists, bullet points, checkboxes (`- [ ]`), or under headings like "Acceptance Criteria", "AC", "Requirements", "Definition of Done". Be flexible in parsing.
+
+Extract each AC item as a discrete, verifiable requirement. If the issue has no clear AC section but has a description with implied requirements, extract those as your AC list and note that they were inferred.
+
+## Step 3 — Understand the Code Changes
+
+Gather **all** changes on this branch compared to `staging` — this must include committed changes, staged changes, unstaged modifications, **and** brand-new untracked files. Make sure nothing is missed; new features often live in files that haven't been `git add`-ed yet.
+
+Read the changes carefully. For each changed file, understand what was added, modified, or removed.
+
+The diff is your primary source, but don't evaluate it in isolation. When you need surrounding context to understand whether an AC item is truly satisfied, follow the code paths and read whatever files are relevant. Just stay focused on what's relevant to the AC items.
+
+## Step 4 — Verify Each AC Item
+
+For every AC item, determine its status:
+
+- **✅ Implemented** — You can point to specific code in the diff that satisfies this criterion. Cite file paths and line ranges.
+- **⚠️ Partially Implemented** — Some aspects are covered but others are missing. Explain what's done and what's not.
+- **❌ Not Addressed** — No evidence in the diff that this criterion was worked on.
+- **🔍 Needs Manual Verification** — The criterion involves runtime behavior, external service interaction, or deployed infrastructure that cannot be verified from code alone (e.g., "webhook is received", "RPC provider responds correctly", "Docker healthcheck passes in production").
+
+For each item, provide concrete evidence: file paths, function names, code snippets, or logic traces. Don't guess — if you're unsure, read the relevant code before making a judgment.
+
+## Step 5 — Detect Uncovered Edge Cases
+
+After verifying all explicit AC items, think about what the AC might have missed:
+
+- Error states and error handling (failed RPC calls, network timeouts, malformed payloads)
+- Input validation edge cases (missing fields, invalid addresses, wrong chain IDs)
+- Race conditions or concurrency concerns
+- Security implications (authentication, authorization, injection vectors)
+- Environment / configuration dependencies (new env vars, missing `.env.example` updates)
+- API contract changes (new/modified routes, changed request/response shapes)
+- Database or state side effects
+
+Only flag edge cases that are genuinely important and relevant to the specific feature — avoid generic advice.
+
+## Output Format
+
+Present your findings in this format:
+
+```
+## AC Verification Report
+
+**Issue**: #<number> — "<issue title>"
+**Branch**: `<branch-name>`
+**Base**: `staging`
+
+### Acceptance Criteria
+
+| # | Criteria | Status | Evidence |
+|---|----------|--------|----------|
+| 1 | <AC text> | ✅ Implemented | `src/services/example.ts:45-67` — <brief explanation> |
+| 2 | <AC text> | ⚠️ Partial | <what's done and what's missing> |
+| 3 | <AC text> | ❌ Not Addressed | <no matching code found> |
+| 4 | <AC text> | 🔍 Manual Check | <why this can't be verified from code> |
+
+### Potential Uncovered Edge Cases
+- <edge case 1 — why it matters>
+- <edge case 2 — why it matters>
+
+### Summary
+<X of Y acceptance criteria fully implemented, N partial, M missing>
+<One-line overall readiness assessment>
+```
+
+## Important Guidelines
+
+- Be honest and precise. A false ✅ is worse than a false ❌ — developers rely on this to know if they're done.
+- When in doubt, mark as ⚠️ Partial and explain what you're unsure about.
+- Keep evidence concise but specific — file:line references, not vague descriptions.
+- If the issue description is vague or has no AC, do your best with what's available and recommend the developer add clearer AC to the issue.
+- Read the project's `AGENTS.md` for coding conventions — if AC items relate to code quality standards, verify against those too.

.codex/skills/ac-check

@@ -0,0 +1 @@
+../../.claude/skills/ac-check

.cursor/skills/ac-check

@@ -0,0 +1 @@
+../../.claude/skills/ac-check

CLAUDE.md

@@ -0,0 +1 @@
+AGENTS.md