domains / software-engineering / pre-merge-verification / check

check

Skill card

combined

The two skills share the name 'check' and the high-level goal of verifying work before it is finalized, but they define completely different procedures, tools, and outputs. The first is a domain-specific skill for running 'CIAgent' regression tests on AI agent code using a specific CLI and interpreting JSON results. The second is a general-purpose software engineering skill that routes to either a runtime verification mode (driving the app) or a code review mode (using a different LLM). They do not overlap in steps or constraints; one is a specific tool wrapper, the other is a workflow orchestrator. Combining them is necessary to preserve both distinct verification strategies.

Repositories

Other copies

Combined skill

---
name: check
description: Verify changes before merge. Supports CIAgent regression checks for AI agents and general pre-merge verification (runtime proof or fresh-model code review).
allowed-tools: Bash, Read, Grep, Glob, Write, Agent
---

# Check

This skill provides two distinct verification paths. Determine which applies based on the repository context and user intent.

## Path 1: CIAgent Regression Checks

Use this path if the repository contains `agentci_spec.yaml` and the change involves AI agent code, prompts, or knowledge bases.

1. **Select Command**:
   - Spec/wiring changed or no API keys: `ciagent test --mock`
   - Agent code/prompt changed: `ciagent test --yes --format json`
   - Flakiness suspected: `ciagent test --runs 3 --yes`
   - Knowledge base changed: `ciagent generate-checks --dry-run`, review, then apply.
   - Judge verdicts look wrong: `ciagent judge-audit`

2. **Interpret Results**:
   - Exit 0: Pass.
   - Exit 1: Correctness failure. Fix the agent or the check (if factually wrong). Never weaken a correct check.
   - Exit 2: Infra/config error. Fix setup.
   - If `--runs N` is used, check `stability` block for `flip_source` (agent-variance, judge-flake, infra-error, mixed).

3. **Report**: Summarize score, failures, and flip sources in 1-2 sentences.

## Path 2: General Pre-Merge Verification

Use this path for standard software changes. Ask the user to choose a mode if not specified:

```
Which check do you want to run? Type one:
  • verify  run the real app and prove the change works against its spec
  • review  a fresh model senior read of the diff, ranked findings
  • both    verify first, then review
```

### Mode: Verify
- Drive the real application to prove behavior against the spec.
- Ensure every acceptance criterion is met.
- Do not edit code. Point failures to `/debug` or `/develop`.

### Mode: Review
- Perform a senior code review on the diff using a model different from the one that wrote the code.
- Write findings ranked by severity to `docs/reviews/`.
- Do not edit code.

## Output Style
- Use plain, simple language.
- Avoid hyphens and dashes in prose (e.g., use "read only" not "read-only").
- Keep technical terms and code flags as-is.