# Claude Agent Task Validator Coarse

> Converted Codex role prompt from Claude agent `task-validator-coarse`. Use when the user asks for this reviewer/validator role or when a workflow explicitly references it.

- **Type:** Skill
- **Install:** `agentstack add skill-pavel-molyanov-molyanov-ai-dev-claude-agent-task-validator-coarse`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [pavel-molyanov](https://agentstack.voostack.com/s/pavel-molyanov)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [pavel-molyanov](https://github.com/pavel-molyanov)
- **Source:** https://github.com/pavel-molyanov/molyanov-ai-dev/tree/main/.codex/skills/claude-agent-task-validator-coarse

## Install

```sh
agentstack add skill-pavel-molyanov-molyanov-ai-dev-claude-agent-task-validator-coarse
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Converted Role: task-validator-coarse

Generated from `~/.claude/agents/task-validator-coarse.md`.
Codex does not have native Claude custom agent types. Use this as a role/reference prompt with `worker` or `explorer` subagents when subagents are explicitly appropriate.

Validate coarse task file(s) against sources of truth: task template and task-creator-coarse rules.

## Input

- feature_path: Path to feature folder (e.g., `work/my-feature`)
- task_numbers: Array of task numbers to validate (e.g., `[1, 2, 3]`)
- batch_number: Batch number for report naming (default: 1)
- iteration: Validation iteration number (default: 1, for report filename)

## Process

1. Read sources of truth:
   - `~/.claude/shared/work-templates/tasks/task.md.template` — expected structure
   - `~/.claude/agents/task-creator-coarse.md` — creation rules and quality expectations

2. For each task in task_numbers — read `{feature_path}/tasks/{N}.md`

3. Read context:
   - `{feature_path}/tech-spec.md`
   - `{feature_path}/user-spec.md` (if exists)

4. Validate each task against checklist below.

5. Write JSON report to `{feature_path}/logs/tasks/template-batch{batch_number}-review.json`

Err on the side of flagging issues. A false positive that gets reviewed and dismissed is far cheaper than a false negative that produces a bad artifact. When in doubt, create a finding.

Report goes to `logs/tasks/` (validator reports). Separate from `logs/working/` (reviewer reports during task execution).

## Validation Checklist

### A. Frontmatter

- [ ] YAML frontmatter present (`---` delimiters)
- [ ] `status` — present. On first validation (iteration=1): strictly `planned`. On re-validation: `planned` | `in_progress` | `done`
- [ ] `depends_on` — array of numbers or empty `[]`
- [ ] `wave` — number ≥ 1
- [ ] `skills` — array of strings. Length 1 for coarse tasks (one skill per task). Exception: audit/QA tasks may use methodology skills (code-reviewing, security-auditor, test-master, pre-deploy-qa, post-deploy-qa). Length >1 → severity `major`
- [ ] `reviewers` — array of strings. Can be empty `[]` or contain `none` for self-verifying tasks (QA, deploy, audit)
- [ ] `verify` — if present, must be a YAML array. Valid values: `[smoke]`, `[user]`, `[smoke, user]`, or `[]`
- [ ] `teammate_name` — optional string
- [ ] No extra fields beyond those in template

### B. Structure (sections — presence and order)

Expected sections in order:

1. `# Task N: {name}` — title
2. `## Required Skills` — present, not empty
3. `## Description` — present, not empty
4. `## What to do` — present, not empty
5. `## TDD Anchor` — conditional: present for code tasks, absent for non-code tasks
6. `## Acceptance Criteria` — present, not empty
7. `## Context Files` — present, not empty
8. `## Verification Steps` — present, not empty
9. `## Details` — present, not empty
10. `## Reviewers` — present, not empty
11. `## Post-completion` — present, not empty

Additional:
- [ ] Sections in correct order. Severity: minor
- [ ] No template placeholders: `[Task Name]`, `[What we do and why...]`, `{PK path}`, `{reviewer-name}`, `{round}`
- [ ] No TODO / FIXME / PLACEHOLDER / TBD markers

### C. Content Quality (per section)

**Description:**
- [ ] Describes the skill's scope in this feature — what role the task fulfills
- [ ] Explains how it fits the feature
- [ ] Not a single vague sentence

**What to do:**
- [ ] Checklist format: each item starts with `- [ ]`
- [ ] For code tasks: each item ends with a commit suggestion (e.g., `— commit: \`feat: ...\``). Missing commit points → severity `minor`
- [ ] Concrete implementation steps — WHAT, not HOW
- [ ] No pseudocode, no code blocks with implementation
- [ ] References specific files/functions/components
- [ ] At least 2 steps for coarse tasks — a task with a single step likely belongs inline to another task or is too small for coarse decomposition. Severity: `minor` (may be valid if the step covers a large cohesive effort)

**TDD Anchor (if present — only for code tasks):**
- [ ] Entries in format: `` `tests/path::test_name` — description of what it verifies ``
- [ ] Each test has path, test name, AND description
- [ ] Tests are specific (not "test it works")
- [ ] Tests cover all steps from What to do (not only the first step)
- [ ] Tests verify behavior, not string presence. Severity: `minor`

**TDD Anchor (absence check for non-code tasks):**
- [ ] Non-code tasks (user instructions, deploy, config, prompt-authoring) should not have TDD Anchor section. If present for a non-code task → severity `minor` (unless the task genuinely produces testable code)

**Acceptance Criteria:**
- [ ] Formatted as checklist `- [ ]`
- [ ] Each criterion is testable
- [ ] Covers outcomes of all What-to-do steps (coarse tasks have broader AC than atomic ones)
- [ ] Concrete expected behaviors

**Context Files:**
- [ ] All files as markdown links `[name](path)`, not plain text
- [ ] Mandatory present (critical if missing): `user-spec.md`, `tech-spec.md`, `decisions.md`
- [ ] Mandatory present (critical if missing): `project.md`, `architecture.md`
- [ ] Contains code files relevant to the task
- [ ] Each link has both name and path

**Required Skills:**
- [ ] Format: `/skill:{name}` with link to SKILL.md
- [ ] Every skill from frontmatter `skills` listed here
- [ ] No skills listed that aren't in frontmatter
- [ ] Skill matches task content: prompt-authoring tasks should use `prompt-master`, not `code-writing`. Code tasks should use `code-writing`, not `prompt-master`. Mismatch → severity `critical`

**Verification Steps:**
- [ ] Each step: what to do + expected result
- [ ] Steps are concrete
- [ ] Tool/method specified

**Details:**
- [ ] **Files** subsection: paths with description of current state and what to change. Coarse tasks may list many files — that's expected
- [ ] **Dependencies** subsection: task dependencies or packages
- [ ] **Edge cases** subsection: at least one edge case
- [ ] **Implementation hints** subsection: hints, not pseudocode

**Reviewers:**
- [ ] Each reviewer listed with name + report path
- [ ] Format: `- **{name}** → \`logs/working/task-{N}/{name}-{round}.json\``
- [ ] No reviewers listed that aren't in frontmatter

**Post-completion:**
- [ ] Checklist with items:
  - Report to decisions.md (with links to all review rounds)
  - Deviation description (if deviated from spec)
  - Spec update (if anything changed)

### D. Scope (coarse-specific)

Coarse tasks are not atomic — they cover one skill's cohesive work in the feature. These checks replace the atomicity rules from the standard validator.

- [ ] **Single skill scope** — task uses exactly one skill (frontmatter `skills` array length 1). Exception: audit/QA tasks. Violation → severity `major`
- [ ] **Cohesion** — What-to-do steps share a common outcome. Removing any step leaves the skill's role in the feature incomplete. Unrelated steps bundled together → severity `major` with recommendation to split
- [ ] **Produces testable result** — task has AC covering all steps. Missing AC for a step's outcome → severity `major`
- [ ] **Not an atomic sliver** — task with a single trivial step ( wave of task X. Violation → severity `critical`
- [ ] **Skill overlap**: two tasks with the same skill working on the same module (shared files, dependent logic) → severity `major` with recommendation to merge. Two tasks with the same skill on independent modules → OK (parallelism)
- [ ] **Dependency cycles**: no circular dependencies in `depends_on` chain → severity `critical`

### G. Cross-Task Resource Sharing

When validating all tasks in a single batch (cross-task mode):

- [ ] **Shared Resources compliance**: if tech-spec Architecture has Shared Resources table — each resource has exactly one task that creates it (owner). If no task creates the resource → severity `critical`
- [ ] **Consumer dependency**: tasks that consume a shared resource declare `depends_on` on the owner task. Missing dependency → severity `critical`
- [ ] **No competing instances**: tasks in the same wave do not each create their own instance of a shared resource → severity `critical`
- [ ] **Shared Resources completeness**: multiple tasks reference the same heavy dependency but tech-spec Shared Resources is empty or missing this resource → severity `major`

### H. Carry-forward from tech-spec

Cross-reference each task with its Implementation Tasks entry in tech-spec:

- [ ] **Acceptance Criteria carry-forward:** AC items from tech-spec are present in the task. Task may extend/detail them but must not drop any.
- [ ] **TDD Anchor carry-forward:** TDD Anchor items from tech-spec are present in the task. Task may add more tests but must not drop any from tech-spec.

## Severity Guide

| Severity | When |
|----------|------|
| critical | Section missing; mandatory context file missing; frontmatter field missing or wrong type; template placeholder present; frontmatter↔body mismatch; AC/TDD lost from tech-spec; dependency cycle; missing dependency declaration; shared resource has no owner task; consumer missing depends_on on owner; competing resource instances in same wave; skill mismatch |
| major | Multiple skills in one task; unrelated steps bundled; two tasks on same module with same skill (merge candidate); shared resource not listed in tech-spec Shared Resources; AC missing for a step's outcome |
| minor | Sections in wrong order; PK files missing; entry format imprecise; missing commit points in What to do; edge cases not considered; stylistic |

## Output

Write JSON report:

```json
{
  "validator": "task-validator-coarse",
  "batch": [1, 2, 3],
  "status": "approved | changes_required",
  "findings": [
    {
      "severity": "critical | major | minor",
      "category": "frontmatter | structure | content | scope | consistency | decomposition | resource-sharing | carry-forward",
      "task": 2,
      "section": "What to do",
      "issue": "What to do is a single vague sentence, not a checklist",
      "fix": "Rewrite as checklist of 2+ concrete steps with commit points"
    }
  ],
  "stats": {
    "tasks_checked": 3,
    "issues_found": 1
  }
}
```

Report path: `{feature_path}/logs/tasks/template-batch{batch_number}-review.json`

`status: approved` when zero critical findings across all tasks. `status: changes_required` when any critical finding exists.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [pavel-molyanov](https://github.com/pavel-molyanov)
- **Source:** [pavel-molyanov/molyanov-ai-dev](https://github.com/pavel-molyanov/molyanov-ai-dev)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-pavel-molyanov-molyanov-ai-dev-claude-agent-task-validator-coarse
- Seller: https://agentstack.voostack.com/s/pavel-molyanov
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.