Task Check

Task Check (QA Verification)

Verify that the implementation on the current branch satisfies the requirements defined in the linked GitHub issue. This is a QA gate that ensures we built what was asked for.

Arguments

• {issue} -- GitHub issue number (optional, extracted from branch name if not provided)
• --strict -- Fail on any unmet criterion (default: fail only on "Must Have" criteria)

Configuration

Auto-detect the GitHub repository from git remote -v (extract owner and repo name). If cloudstack.json exists, it may contain a project.repository field as a fallback.

Process

Step 1: Identify the Issue

# Get current branch
BRANCH=$(git branch --show-current)

# Extract issue number from branch name (e.g., username/42-feature-name)
ISSUE=$(echo "$BRANCH" | grep -oE '/[0-9]+' | tr -d '/')

# If no issue in branch name and not provided as argument, fail
if [ -z "$ISSUE" ]; then
  echo "ERROR: Could not determine issue number. Provide as argument: /task-check 42"
  exit 1
fi

# Auto-detect repo from git remote
REPO_URL=$(git remote get-url origin)
OWNER=$(echo "$REPO_URL" | sed -E 's#.*[:/]([^/]+)/[^/]+(\.git)?$#\1#')
REPO=$(echo "$REPO_URL" | sed -E 's#.*[:/][^/]+/([^/]+?)(\.git)?$#\1#')

Step 2: Fetch Issue Details

Use MCP for structured issue data:

mcp__github-mcp-server__get_issue(owner: "${OWNER}", repo: "${REPO}", issue_number: $ISSUE)

This returns structured JSON with number, title, body, labels, state, and comments -- no CLI output parsing needed.

Step 3: Parse Acceptance Criteria

Extract acceptance criteria from the issue body. Look for:

• Checkbox lists: - [ ] Criterion
• "Acceptance Criteria" section
• "Requirements" section
• "Definition of Done" section
• User stories with "so that" format

Categorize each criterion:

• Must Have: Explicitly marked as required, or in "Acceptance Criteria"
• Should Have: Listed but not critical
• Nice to Have: Suggestions, future improvements mentioned

Step 4: Analyze Implementation

For each acceptance criterion, search the codebase to verify it was implemented:

# Get all changes on this branch
git diff origin/main...HEAD --name-only

# Get the actual changes
git diff origin/main...HEAD

Verification methods by criterion type:

Step 5: Evidence Gathering

For each criterion, collect evidence:

• File paths where the implementation exists
• Code snippets showing the implementation
• Test names that cover the requirement
• Commit messages that reference the criterion

Step 6: Generate Report

## Task Check: Issue #{number}

**Title:** {issue title}
**Branch:** {branch name}
**Labels:** {labels}

---

### Acceptance Criteria Verification

#### Must Have

| # | Criterion | Status | Evidence |
|---|-----------|--------|----------|
| 1 | {criterion text} | {MET/UNMET/PARTIAL} | {file:line or description} |
| 2 | {criterion text} | {MET/UNMET/PARTIAL} | {file:line or description} |

**Details:**

##### Criterion 1: {criterion}
- **Status:** MET
- **Evidence:**
  - Implementation: `src/{Service}/Application/Commands/CreateResource.cs:45`
  - Test: `tests/{Service}.Tests/CreateResourceHandlerTests.cs:TestCreation`
  ```csharp
  {relevant code snippet}

Criterion 2: {criterion}

• Status: UNMET
• Missing: {what's missing}
• Suggestion: {how to implement}

Should Have

Nice to Have (Not Required)

Implementation Summary

Files Changed: {count} New Files: {list} Tests Added: {count}

Key Changes:

• {summary of major change 1}
• {summary of major change 2}

Gaps Identified

{If any criteria are UNMET or PARTIAL:}

1. {Criterion}
   • Missing: {description}
   • Effort estimate: {Small/Medium/Large}
   • Suggested implementation: {brief approach}

Summary

Result: {PASS / FAIL}

{If PASS: "All Must Have criteria are met. Ready for code review."} {If FAIL: "X Must Have criteria are unmet. See Gaps Identified above."}

Recommendations

{If PASS with warnings:}

• Consider addressing Should Have items: {list}
• Nice to Have items deferred to future: {list}

{If FAIL:}

• Priority fixes needed:
  1. {Most critical gap}
  2. {Second priority}

## Handling Edge Cases

**No acceptance criteria in issue:**
- Look for implicit requirements in the description
- Check comments for clarifications
- If truly undefined, WARN and suggest adding criteria before proceeding

**Vague criteria:**
- Flag as "NEEDS CLARIFICATION"
- Make best-effort assessment
- Include recommendation to clarify with stakeholder

**Scope creep detected:**
- If implementation includes features not in issue, note as "EXTRA"
- Not a failure, but worth flagging for review

## Integration with /complete-task

When called as an agent from `/complete-task`:
- Return pass/fail status and count of unmet Must Have criteria
- Include list of gaps if any
- Unmet Must Have criteria cause the parent workflow to pause

## Guidelines

- Be thorough but practical -- focus on what matters
- Evidence is key -- always show where something is implemented
- Partial credit counts -- note progress even if incomplete
- Consider intent -- sometimes requirements evolve during implementation
- Flag scope creep -- extra work is good but should be acknowledged