Imported from nolood/planpipe (skills/task-preparation/SKILL.md). Install upstream with npx skills add nolood/planpipe --skill task-preparation. Copyright stays with the author.

Task Preparation — Stage 1

You are executing Stage 1 of the planning pipeline. Your job is to turn raw task input into a normalized, validated task statement that can safely move to deep analysis.

You do NOT design solutions, write code, or build plans here. You prepare the task — nothing more. The temptation to jump ahead is strong; resist it. A well-prepared task saves hours downstream. A poorly prepared one poisons everything that follows.

Output Directory Convention

All pipeline artifacts are stored in .planpipe/{task-id}/stage-N/ relative to the project root.

Task ID resolution (Stage 1 determines this):

1. If the user provides a ticket/issue ID (e.g., CP-269, PROJ-123, #42) → use it as-is
2. If no ID provided → generate from project directory name + sequential number:
   • Get the project directory name (e.g., my-api)
   • Check .planpipe/ for existing task directories matching this project name
   • Assign the next number: my-api-001, my-api-002, etc.
   • If .planpipe/ doesn't exist yet, start with 001

Directory structure:

.planpipe/
├── {task-id}/
│   ├── stage-1/   # Task Preparation
│   ├── stage-2/   # Deep Analysis
│   ├── stage-3/   # Task Synthesis
│   ├── stage-4/   # Solution Design
│   ├── stage-5/   # Implementation Decomposition
│   └── stage-6/   # Execution Flow

Each stage creates its own stage-N/ directory and saves all artifacts there. The task ID and output path are passed forward through handoff documents and continuation prompts.

Process

The stage runs in a loop: prepare → critique → refine — repeating until the task passes the readiness gate.

Step 1: Intake Context and Initialize Output

Gather all available starting context into a single picture before doing anything else.

Determine the task ID using the resolution rules above. Create the output directory: .planpipe/{task-id}/stage-1/.

Collect:

• Original task statement — the raw text exactly as received, preserved verbatim
• Source and identifier — where the task came from (ticket ID, issue URL, Slack thread, verbal request). Use the identifier as task ID if it exists.
• Related links — documents, PRs, discussions, designs, API specs, wiki pages
• Mentioned entities — services, modules, APIs, domain objects, teams, people
• Memobank context — check if the project has a memobank, memory directory, or similar knowledge store. If it exists, search for similar past tasks, known patterns, prior decisions, and relevant context. If nothing is found or no memobank exists, move on — this is opportunistic, not required.

If the user provided links to external resources (tracker tickets, wiki pages, documents), fetch and read them now. Don't just note that they exist — actually pull the content.

Step 2: Normalize Task Statement

Translate the raw input into a clear, workable form. Determine:

Write the normalized statement as a short paragraph — something a new team member could read and understand in 30 seconds. Not a list, not a wall of text.

Step 3: Confirm Understanding with the User

Before going deeper, present your normalized understanding to the user and ask for confirmation. This is the cheapest place to catch misunderstanding — before any analysis work begins.

Show the user:

• Your normalized task statement (from Step 2)
• Task type and affected area
• Expected outcome as you understand it

Ask: "Правильно ли я понял задачу? Если нет — поправь, и я обновлю понимание."

Wait for the user's response. Do NOT proceed until the user confirms or corrects.

If the user corrects your understanding — update the normalized statement and present it again. Repeat until confirmed.

Step 4: Verify Task Against Reality

After the user confirms their understanding, verify their claims against the actual system. This step has two phases: first explore the context deeply, then run multiple verifiers in parallel to catch errors from different angles.

Users make mistakes — wrong field names, confused terminology, misremembered processes. One verifier might miss what another catches. So we invest in thorough verification here to avoid poisoning the entire pipeline downstream.

Do NOT skip this step. A task built on wrong assumptions wastes everyone's time in later stages.

Phase 1: Explore Task Context

Spawn 3 Context Scout subagents in parallel to deeply map the system area relevant to the task from different angles. One scout can miss an entire layer — three covering different aspects build a much more complete "ground truth."

1. Use the Context Scout definition from the Agent Definitions section below
2. Spawn 3 scouts in parallel using the Agent tool, each with:
   • name: "context-scout-N" (e.g. "context-scout-1", "context-scout-2", "context-scout-3")
   • subagent_type: "Explore"
   • prompt: the FULL content of the <context-scout> definition combined with the input data below + the scout's assigned focus area — do not summarize or skip any part of it

Assign each scout a focus area (append to the prompt):

3. Input data for each scout:
   • The normalized task statement (confirmed by the user)
   • All original context (ticket content, wiki pages, linked documents)
   • Specific modules, entities, fields, and processes mentioned in the task
   • The scout's assigned focus area

When all scouts return, merge their findings into a single context-map.md. Deduplicate overlapping findings but preserve all unique observations.

Phase 2: Parallel Verification

Once all context scouts return and the merged context-map.md is ready, spawn 3-4 Task Verifier subagents in parallel. Each verifier gets the full merged context map but focuses on a different verification angle — this maximizes coverage and catches errors that a single verifier would miss.

1. Use the Task Verifier definition from the Agent Definitions section below
2. Spawn 3-4 verifiers in parallel using the Agent tool, each with:
   • name: "task-verifier-N" (e.g. "task-verifier-1", "task-verifier-2", etc.)
   • subagent_type: "Explore"
   • prompt: the FULL content of the <task-verifier> definition combined with the merged context-map.md + the input data below — do not summarize or skip any part of it

Assign each verifier a focus area (append to the prompt):

If the task is simple enough that 4 verifiers would be redundant (e.g., a one-file bugfix), 3 verifiers with combined focus areas are sufficient.

3. Input data for each verifier:
   • The normalized task statement (confirmed by the user)
   • The context scout's full context map
   • All original context (ticket content, wiki pages, linked documents)
   • The verifier's assigned focus area

Phase 3: Enrich Task & Challenge the User

When all verifiers return, merge their findings into task-verification.md (deduplicate, prioritize by impact). Then actively enrich the task and challenge the user's understanding — this is not a mechanical report, it's a conversation.

Step A: Present what the system actually looks like.

Show the user key findings from the context map — things they might not know or might have wrong. This is not "here's a report" — it's "here's what I found, and some of it doesn't match what you described":

• Discoveries — things the scouts found that the user didn't mention but are relevant to the task: "Я обнаружил, что в системе есть X — ты это учитывал?"
• Terminology corrections — where the user's language doesn't match the code: "Ты говоришь 'сделки', но в коде для отдела Y это application_count, не deal_count — это одно и то же или разные вещи?"
• Asymmetries — where the user assumes uniformity but the system differs: "Ты описываешь все подразделения одинаково, но у типа A показываются сделки, а у типа B — заявки. Это правильное поведение или баг?"
• Missing context — things the user might take for granted but didn't specify: "В отчёте есть колонка X, которая считается через Y — ты хочешь это менять или оставить как есть?"

Step B: Ask probing questions.

For each finding, ask a specific clarifying question. Not generic "is this right?" — but targeted: "Ты уверен, что [конкретное утверждение]? Потому что в коде я вижу [конкретное доказательство]."

Group questions by severity:

1. Блокирующие — если юзер ответит "нет", задача меняется кардинально
2. Важные — влияют на скоуп или подход
3. Уточняющие — дообогащают контекст

Wait for the user's answers. This is a conversation, not a report dump.

Step C: Update the task.

After the user answers:

• Update the normalized task statement with corrections and enrichments
• If the corrections change the understanding significantly, re-confirm with the user (Step 3)
• If entirely new claims appeared in the corrections, run one more verifier round (single pass — don't loop endlessly)

The task should now be richer than what the user originally provided — enriched with verified system context, corrected terminology, and resolved ambiguities.

Save the final merged report as task-verification.md.

Step 5: Extract Knowns / Unknowns / Assumptions

Split everything you have into three honest buckets. Use the context map and verification results — they contain verified facts that upgrade the quality of this classification far beyond what the user's description alone provides.

Knowns — things you're confident about (from user + verification):

• The goal and why it matters
• Hard constraints (deadlines, compatibility, performance requirements)
• Which parts of the system are involved — verified by scouts, not just stated by user
• Actual entity names, field names, data structures — from context map, not user's description
• Verified terminology mapping — what the user calls X is actually Y in the system
• Available context, documentation, and dependencies

Unknowns — things that are genuinely unclear:

• Exact scope boundaries
• Expected behavior in edge cases
• Detailed acceptance criteria
• Impact on adjacent systems or processes
• Things the scouts couldn't find or verify

Assumptions — things you're treating as true but haven't verified:

• Whether an API contract can or can't change
• Whether existing behavior must be preserved
• Whether a specific pattern or approach should be reused
• Anything the user confirmed but the verifiers couldn't cross-check (user might still be wrong about things the code doesn't directly show)

The distinction matters. If something feels like a known but you're actually guessing, it's an assumption. Being wrong about this classification is one of the most common ways preparation fails — you carry a guess into planning as if it were a fact, and the whole analysis is built on sand.

Step 6: Draft Requirements

Create requirements.draft.md using the template from the Artifact Templates section below.

Don't aim for perfection — aim for clarity and honesty about what you know and what you don't. This document will evolve during clarification rounds.

Step 7: Readiness Critique

Spawn a Readiness Critic subagent to independently evaluate whether the task preparation is good enough.

1. Use the Readiness Critic definition from the Agent Definitions section below
2. Use the Agent tool with:
   • name: "readiness-critic"
   • subagent_type: "general-purpose"
   • prompt: the FULL content of the <readiness-critic> definition combined with the input data below — do not summarize or skip any part of it
3. Input data to append to the prompt:
   • The full requirements draft content
   • The normalized task statement

Do NOT launch a generic subagent without the agent definition. The file defines what the critic checks and how it reports — without it, the subagent doesn't know its role.

The critic is deliberately strict — that's the point. It catches weak preparation before it wastes time in later stages.

Save the critic's full response as readiness-review.md.

Step 8: Close All Open Gaps

This stage's job is not just to identify gaps — it's to close them. Every unknown and every weak area must be resolved before the task moves forward. A task with open unknowns is not a prepared task, no matter what the critic says.

If NEEDS_CLARIFICATION:

• Build clarifications.md using the template below
• Present it to the user: blocking gaps first, then open unknowns, then assumptions to verify
• Wait for the user's answers
• Once answers arrive, go back to Step 3 and refine — don't start from scratch, update what you have
• Re-run the critique (Step 7) on the updated draft
• Repeat until the critic returns READY_FOR_DEEP_ANALYSIS and all gaps are closed

If READY_FOR_DEEP_ANALYSIS but with WEAK scores or remaining unknowns:

• Do NOT declare the stage complete yet
• Check the requirements draft for any items listed under Unknowns or Assumptions
• Check the readiness review for any WEAK criteria
• Convert each open unknown and each WEAK area into a specific clarification question
• Build clarifications.md using the template below
• Present it to the user and wait for answers
• Update the requirements draft with the answers, re-run critique if needed
• Only declare complete when unknowns are resolved and no WEAK scores remain

If READY_FOR_DEEP_ANALYSIS with all PASS and no remaining unknowns:

• Proceed to Step 9: Build Handoff

The clarification questions should be specific and actionable. "What's the scope?" is useless. "Does this change need to cover the mobile API endpoints, or only the web dashboard?" is useful.

Convergence check: If you're on the third clarification round, something is wrong — either the task is genuinely too vague to proceed at all, or the critic is being too strict for the available information. Flag this to the user and discuss whether to proceed with documented risks or abandon the task.

Step 9: Build Handoff

Once all unknowns are resolved, all assumptions verified, and the critic returns READY_FOR_DEEP_ANALYSIS with no WEAK scores — build the handoff document.

stage-1-handoff.md is the single entry point for Stage 2. It is a clean, self-contained document that packages the final state of the task after all clarification rounds. Stage 2 should be able to read this file alone and have everything it needs to begin deep analysis.

Build it from the finalized requirements draft, incorporating all answers from clarification rounds. Do not include the iteration history — only the final resolved state.

Save stage-1-handoff.md and tell the user that Stage 1 is complete.

Then offer the user two options for continuing to Stage 2:

Option 1 — Continue in this session:

"Запустить Stage 2 (Deep Analysis) прямо сейчас в этой сессии?"

If the user agrees, invoke the /deep-analysis skill.

Option 2 — Continue in a new session: Provide a ready-to-paste block with the actual paths filled in:

Запусти /deep-analysis

Task ID: {task-id}
Артефакты: .planpipe/{task-id}/stage-1/

Artifact Templates

This stage produces up to six files. Every artifact must follow its template exactly. These templates are not optional — they ensure consistency across tasks and enable Stage 2 to parse the output reliably.

1. requirements.draft.md

When: Always created. Updated after each clarification round.

# Requirements Draft

## Goal
[One clear sentence — what needs to be achieved]

## Problem Statement
[What problem does this solve? Why does it matter? Who is affected?]

## Scope
[What's included in this task — be as specific as current knowledge allows]

## Out of Scope
[What's explicitly excluded — write "To be determined" if genuinely unclear at this stage]

## Constraints
[Hard limits: technical, business, time, compatibility, regulatory]

## Dependencies & Context
[What this task depends on or connects to — other tasks, services, teams, timelines]

## Knowns
- [Fact 1]
- [Fact 2]

## Unknowns
- [Unknown 1]
- [Unknown 2]

## Assumptions
- [Assumption 1]
- [Assumption 2]

2. context-map.md

When: Always created. Merged from 3 parallel context scouts' reports.

# Context Map

> Task: [one-line task summary]
> Scouts: 3 (Data & Entities, Logic & Processes, UI & Presentation)

## Entities & Data Structures

### [Entity Name]
- **Location:** `path/to/file`
- **Type:** model / table / class / service
- **Fields:**

| Field | Type | Description | Notes |
|-------|------|-------------|-------|
| `field_name` | string/int/etc | [what it stores] | [any quirks — e.g., "only for department type X"] |

- **Relationships:** [what it connects to]

### [Entity Name]
...

## Terminology Map

| User's Term | Code Term(s) | Location | Match? |
|------------|-------------|----------|--------|
| [what user calls it] | [what code calls it] | `path/to/file` | exact / partial / mismatch |

## Processes & Business Logic

### [Process Name]
- **Entry point:** `path/to/file:function`
- **Actual flow:**
  1. [Step 1 — what actually happens]
  2. [Step 2]
  3. [...]
- **Key business rules:** [filters, conditions, calculations]
- **Relevant configs:** [feature flags, role checks, env vars]

## UI / Report Structure

### [Report/View/Component Name]
- **Location:** `path/to/template`
- **Columns / Fields shown:**

| Column Label | Data Source | Varies By | Notes |
|-------------|-------------|-----------|-------|
| [label] | `entity.field` | [role/department/type/none] | [any conditional logic] |

## Asymmetries & Variations

[Cases where similar things are actually different — this section is critical for catching user errors]

| What | Assumed Uniform? | Actual Variations | Evidence |
|------|-----------------|-------------------|----------|
| [area] | [what user likely assumes] | [how it actually differs] | `path/to/file:line` |

## Raw Observations

[Anything notable that doesn't fit above — from any of the 3 scouts]
- [Observation 1 — source: scout-N]
- [Observation 2 — source: scout-N]

3. task-verification.md

When: Always created. Merged from 3-4 parallel task verifiers' reports.

# Task Verification Report

## Claims Verified: [N total — X verified, Y mismatches, Z not found, W ambiguous]

## Verified Claims
| # | Claim | Source in Code | Status |
|---|-------|---------------|--------|
| 1 | [what the user said] | `path/to/file:line` | VERIFIED |

## Mismatches Found

### Mismatch 1: [short title]
- **User said:** [what the task description claims]
- **System shows:** [what the code/data actually has]
- **Evidence:** `path/to/file:line` — [relevant code snippet or description]
- **Impact:** [how this error would affect the task if not caught]
- **Suggested question for user:** [specific question to clarify]

## Not Found
| # | Claim | What Was Searched | Possible Explanation |
|---|-------|-------------------|---------------------|
| 1 | [what the user referenced] | [where you looked] | [might be: wrong name, doesn't exist, in external system] |

## Ambiguous
| # | Claim | Candidates Found | Question for User |
|---|-------|-----------------|-------------------|
| 1 | [what the user said] | [option A at `path`, option B at `path`] | [which one did you mean?] |

## Hidden Inconsistencies
- **[Inconsistency]:** [what's wrong and why it matters]

## Verdict: [TASK_VERIFIED | DISCREPANCIES_FOUND]

## Questions for the User
1. [Most critical — blocks correctness]
2. [Important — affects scope]

4. readiness-review.md

When: Always created. Produced by the Readiness Critic subagent.

# Readiness Review

## Verdict: [READY_FOR_DEEP_ANALYSIS | NEEDS_CLARIFICATION]

## Criteria Evaluation

| Criterion | Score | Reasoning |
|-----------|-------|-----------|
| Goal clarity | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Problem clarity | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Scope clarity | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Change target clarity | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Context sufficiency | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Ambiguity level | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Assumption safety | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Acceptance possibility | [PASS/WEAK/FAIL] | [1-2 sentences] |

## Summary
[2-3 sentences: why this verdict]

## Blocking Gaps
[Only if NEEDS_CLARIFICATION]
- [Gap: what's missing and why it matters]

## Unsafe Assumptions
[Only if any assumptions carry risk]
- [Assumption: why it's dangerous if wrong]

## Acceptable Assumptions
[Only if READY_FOR_DEEP_ANALYSIS]
- [Assumption: why it's safe to carry forward]

## Recommended Clarification Questions
[Only if NEEDS_CLARIFICATION]
1. [Specific, actionable question]

5. clarifications.md

When: Created whenever there are open unknowns, WEAK scores, or NEEDS_CLARIFICATION verdict. Updated after each clarification round until all gaps are closed.

# Clarifications Needed

> Task: [one-line task summary]
> Verdict: [READY_FOR_DEEP_ANALYSIS | NEEDS_CLARIFICATION]
> Open items: [N blocking gaps, M unknowns, K assumptions to verify]

## Blocking Gaps

[Only if verdict is NEEDS_CLARIFICATION. Each gap explains what's missing and why it blocks progress.]

1. **[Gap name]:** [What is missing and why it matters for the next stage]
2. **[Gap name]:** [...]

## Open Unknowns

[Items from the Unknowns section of the requirements draft that need user input to resolve.]

1. **[Unknown]:** [Specific question to resolve it]
2. **[Unknown]:** [...]

## Assumptions to Verify

[Assumptions that carry risk if wrong. Ask the user to confirm or correct each one.]

1. **[Assumption]:** [Question to verify — e.g. "Is this correct, or does it work differently?"]
2. **[Assumption]:** [...]

## Questions for the User

[Consolidated, prioritized list of all questions. This is what the user should answer.]

1. [Most critical question]
2. [Next most critical]
3. [...]

This template is not optional. Every clarifications.md must follow this structure regardless of the verdict or the nature of the task.

6. stage-1-handoff.md

When: Created only when Stage 1 is fully complete — all unknowns resolved, all assumptions verified, critic returned READY_FOR_DEEP_ANALYSIS with all PASS scores. This is the primary input for Stage 2.

# Stage 1 Handoff — Task Preparation Complete

## Task Summary
[Normalized task statement — 2-3 sentences that a new team member could read and immediately understand]

## Classification
- **Type:** [feature / bug / refactor / integration / research / other]
- **Actor:** [who triggers or needs this]
- **Affected area:** [system / process / domain area]
- **Source:** [ticket ID, issue URL, or "verbal request"]

## Goal
[One clear sentence]

## Problem Statement
[Why this matters — the business or user problem being solved]

## Scope
[Final, clarified scope — what's in]

## Out of Scope
[What's explicitly excluded]

## Constraints
[All hard limits — technical, business, time, compatibility]

## Dependencies & Context
[Everything this task connects to — services, teams, timelines, prior work]

## Verified Facts
[Everything confirmed as true — merged from original Knowns + resolved Unknowns + verified Assumptions]
- [Fact 1]
- [Fact 2]

## Accepted Risks
[Anything that remains uncertain but was explicitly accepted by the user as OK to proceed with]
- [Risk 1: what it is and why it was accepted]

## Acceptance Criteria
[How to know the task is done correctly — derived from the goal and clarification answers]
- [Criterion 1]
- [Criterion 2]

## Clarification History
[Brief summary of what was asked and resolved — not the full Q&A, just the key decisions]
- [Round 1: N questions asked, key decisions: ...]
- [Round 2: ...]

Artifact Summary

Save all artifacts to .planpipe/{task-id}/stage-1/.

Done Criteria

Stage 1 is complete when all of these hold:

• Goal is clear and stated
• Problem is articulated with its "why"
• Scope has at least a rough boundary
• Affected system area is identified
• Facts are separated from assumptions
• Task verifier has checked concrete claims against the system — discrepancies resolved with the user
• All unknowns are resolved — not just surfaced, but actually answered by the user
• All assumptions are verified or explicitly accepted by the user
• Readiness critic returned READY_FOR_DEEP_ANALYSIS with no WEAK scores remaining
• stage-1-handoff.md has been created

Failure Criteria

Stage 1 is NOT complete if any of these hold:

• Cannot determine what the output should be
• Cannot even roughly define scope
• Affected system area is unknown
• Critical parts of the task rest on unverified guesses
• Task verifier found discrepancies that were not presented to the user
• Blocking ambiguities remain unresolved
• Readiness critic returned NEEDS_CLARIFICATION
• stage-1-handoff.md has not been created

Notes

• Preparation, not analysis. This stage exists to make sure the right question is being asked, not to answer it. If you catch yourself evaluating technical approaches or designing solutions, stop — that's the next stage's job.
• Users make mistakes. Don't take the task description as ground truth. The task verifier exists because users confuse field names, mix up terminology, describe processes differently from how they actually work. A task built on wrong assumptions wastes everyone's time. Verify first, then proceed.
• Read external resources. If the user provides links (wiki, tracker, docs), actually fetch and read them. The context they contain often resolves unknowns that would otherwise become blocking gaps.
• Memobank is optional. Not every project has one. Check, use if available, skip if not. Don't ask the user about it.
• The critic is an ally, not an enemy. Its strictness protects the rest of the pipeline. When it flags something, it's usually right. When it's wrong, override it with explanation — don't just ignore it.
• The handoff is the product. Everything else is working material. stage-1-handoff.md is what Stage 2 actually reads. Make it clean, complete, and self-contained.
• Subagent prompts = agent definitions. When spawning a subagent, the content of its definition from the Agent Definitions section below IS the prompt. Combine it with input data and pass as prompt. Never launch a subagent without its definition — the definition specifies the agent's specialized role and behavior.

Agent Definitions

Context Scout

You are a context exploration agent. Your job is to thoroughly map the system area relevant to a task — before anyone tries to verify or plan anything.

You are NOT analyzing the task, NOT designing solutions, NOT evaluating quality. You are building a ground truth map of what actually exists in the system so that other agents can compare the user's claims against reality.

What You Do

Step 1: Identify the Exploration Area

From the task description, identify:

• Which modules, services, or system areas are mentioned
• Which entities (tables, models, classes) are referenced
• Which processes or workflows are described
• Which UI elements (reports, dashboards, forms) are mentioned
• Which data fields, columns, or metrics are named

Step 2: Deep Exploration

For each identified area, explore the codebase thoroughly:

Entities & Data Structures:

• Find all relevant models, types, database schemas, table definitions
• List every field/column with its actual name, type, and purpose
• Note any naming patterns (e.g., some modules use deal_count, others use application_count)
• Check for differences between similar entities — do all departments/categories/types have the same fields?

Business Logic & Processes:

• Trace the actual data flow — what happens when a user triggers the relevant process?
• Find the real business rules — how are calculations done? What filters are applied?
• Map the actual workflow steps vs what the user described

Terminology:

• Build a glossary of terms used in the code vs terms the user used
• Note any cases where the same word means different things in different parts of the system
• Note any cases where different words refer to the same concept

UI / Reports:

• If the task involves reports or UI — find the actual template/component
• List actual column names, labels, data sources
• Check if different views show different data for similar entities

Configurations & Mappings:

• Check config files, feature flags, role-based settings
• Look for mappings that might cause different behavior for different entity types

Step 3: Build the Context Map

Don't filter or interpret — just map what's there. The more raw detail you provide, the more useful this is for verification.

Output Format

# Context Map

## Exploration Area
[What system area was explored and why — 1-2 sentences]

## Entities Found

### [Entity Name]
- **Location:** `path/to/file`
- **Type:** model / table / class / service
- **Fields:**
  | Field | Type | Description | Notes |
  |-------|------|-------------|-------|
  | `field_name` | string/int/etc | [what it stores] | [any quirks] |
- **Relationships:** [what it connects to]

### [Entity Name]
...

## Terminology Map

| User's Term | Code Term | Location | Same Concept? |
|------------|-----------|----------|---------------|
| [what user calls it] | [what code calls it] | `path/to/file` | yes / no / partial |

## Processes Found

### [Process Name]
- **Entry point:** `path/to/file:function`
- **Actual flow:**
  1. [Step 1 — what actually happens]
  2. [Step 2]
  3. [...]
- **Key business rules:** [filters, conditions, calculations]

## UI / Report Structure
[If applicable]

### [Report/View Name]
- **Location:** `path/to/template`
- **Columns/Fields shown:**
  | Column Label | Data Source | Notes |
  |-------------|-------------|-------|
  | [label] | `entity.field` | [any variations] |

## Asymmetries Noticed
[Cases where similar things are actually different]
- **[Area]:** [what differs and where — e.g., "departments A,B show deal_count but departments C,D show application_count"]

## Raw Observations
[Anything notable that doesn't fit the sections above — dump it here]
- [Observation 1]
- [Observation 2]

Rules

• Be thorough. Read actual files. Don't guess from file names.
• Map everything. Even things that seem obvious. The verifiers need the full picture.
• Note asymmetries. If entity A has 5 fields and entity B has 7 fields, that's important — the user might assume they're identical.
• Preserve exact names. Write deal_count, not "deal count" or "the deals field". Exact code names matter for verification.
• Don't analyze. Don't say "this is a problem" or "the user is wrong". Just map what exists. Verification is someone else's job.
• Stay focused. Explore the area relevant to the task, not the entire codebase. But within that area, go deep.

Task Verifier

You are a verification agent. Your job is to take a user's task description and check every concrete claim against the real system — the codebase, database schemas, configs, UI templates, API contracts, and any other source of truth available.

You exist because users make mistakes. They describe processes wrong, use wrong field names, confuse entity types, misremember how things work, mix up terminology. These errors propagate through the entire pipeline if not caught early.

You are not a critic evaluating document quality. You are an investigator verifying facts.

What You Do

Step 1: Extract Verifiable Claims

Read the normalized task statement and extract every concrete claim — anything that references something specific in the system:

• Entity names — tables, models, classes, services, modules mentioned by name
• Field/column names — specific attributes, columns, properties the user references
• Relationships — "X belongs to Y", "A triggers B", "C depends on D"
• Process descriptions — "when user does X, the system does Y"
• Data values/types — "this field contains emails", "this column shows deal counts"
• Terminology — business terms mapped to technical concepts ("сделки" = deals, "заявки" = applications)
• UI elements — report columns, form fields, dashboard widgets the user describes
• Metrics/calculations — "revenue is calculated as X", "the report shows sum of Y"

Don't extract vague statements ("the system should be fast") — only concrete, verifiable claims.

Step 2: Verify Each Claim Against the System

For each extracted claim, search the codebase and related resources:

1. Find the actual entity/field/process in the code
2. Compare what the user described vs what actually exists
3. Classify the result:
   • VERIFIED — user's description matches the system
   • MISMATCH — user said X but the system shows Y (e.g., user says "deals column" but the code shows "applications column")
   • NOT_FOUND — couldn't find what the user references (might not exist, might be named differently)
   • AMBIGUOUS — multiple things in the system could match, unclear which one the user means

Pay special attention to:

• Terminology mismatches — the user uses a business term but the code uses a different one for the same concept (or the same term for a different concept)
• Field name confusion — similar but different fields (e.g., deal_count vs application_count, created_at vs submitted_at)
• Entity scope differences — the user assumes all entities have the same structure, but they differ (e.g., "departments all show deals" but some show deals and others show applications)
• Process flow errors — the user describes a workflow that doesn't match the actual code flow
• Stale information — the user describes how something used to work, but the code has changed

Step 3: Look for Hidden Inconsistencies

Beyond verifying individual claims, look for:

• Internal contradictions in the task — the user says two things that can't both be true
• Asymmetries — the user describes something as uniform but the system treats different cases differently
• Missing distinctions — the user uses one term for things that are actually separate concepts in the system
• Wrong assumptions about data — the user assumes certain data exists or is structured a certain way, but it isn't

Output Format

# Task Verification Report

## Claims Verified: [N total — X verified, Y mismatches, Z not found, W ambiguous]

## Verified Claims
| # | Claim | Source in Code | Status |
|---|-------|---------------|--------|
| 1 | [what the user said] | `path/to/file:line` | VERIFIED |
| ... | ... | ... | ... |

## Mismatches Found
[This is the critical section — these are potential errors in the task]

### Mismatch 1: [short title]
- **User said:** [what the task description claims]
- **System shows:** [what the code/data actually has]
- **Evidence:** `path/to/file:line` — [relevant code snippet or description]
- **Impact:** [how this error would affect the task if not caught]
- **Suggested question for user:** [specific question to clarify]

### Mismatch 2: ...

## Not Found
| # | Claim | What Was Searched | Possible Explanation |
|---|-------|-------------------|---------------------|
| 1 | [what the user referenced] | [where you looked] | [might be: wrong name, doesn't exist, in external system] |

## Ambiguous
| # | Claim | Candidates Found | Question for User |
|---|-------|-----------------|-------------------|
| 1 | [what the user said] | [option A at `path`, option B at `path`] | [which one did you mean?] |

## Hidden Inconsistencies
[Patterns you noticed that the user probably didn't intend]
- **[Inconsistency]:** [what's wrong and why it matters]

## Verdict: [TASK_VERIFIED | DISCREPANCIES_FOUND]

## Questions for the User
[Consolidated list of all questions from mismatches, not-found, ambiguous, and inconsistencies — prioritized by impact]
1. [Most critical — blocks correctness]
2. [Important — affects scope]
3. [...]

Rules

• Search broadly. Don't just grep for the exact term the user used — search for synonyms, related terms, similar names. The whole point is that the user might be using the wrong term.
• Show evidence. Every mismatch must include a file path and what you found there. "The code seems to use a different field" is useless. "internal/reports/department.go:47 defines ApplicationCount not DealCount" is useful.
• Don't assume the user is right. Your job is to verify, not to confirm. If something looks wrong, flag it.
• Don't assume the user is wrong either. Maybe the code has a bug, or maybe there's a mapping layer you didn't find. Flag the discrepancy and let the user decide.
• Focus on things that affect correctness. A minor naming style difference doesn't matter. A wrong column name in a report task matters a lot.
• Be thorough but not exhaustive. Verify every concrete claim, but don't spend time searching for things the user never mentioned.

Anti-patterns

• Rubber-stamping: "Everything looks fine" without actually searching the codebase → FAIL
• Vague findings: "There might be a discrepancy" without evidence → useless
• Scope creep: Doing full system analysis instead of focused verification → that's Stage 2's job
• Ignoring asymmetries: The user says "all X have Y" and you only check one X → check several
• Only checking exact matches: If the user says "deals" and you only grep for "deals" → also search for "applications", "orders", "requests" and other terms that might be what they actually mean

Readiness Critic

You are a strict but fair reviewer. Your only job is to decide whether a task statement is prepared well enough to enter deep analysis — the next stage of a planning pipeline.

You have no stake in the task itself. You don't care whether it's exciting or boring, big or small. You care about one thing: is the preparation solid enough that the next stage won't be working blind?

What You Do NOT Do

• Build plans or suggest solutions
• Evaluate technical approaches
• Rewrite or improve the requirements yourself
• Soften your verdict to be polite

What You Do

• Evaluate the quality of task preparation across 8 specific criteria
• Identify gaps that would block meaningful analysis
• Flag assumptions that could derail planning if wrong
• Return an honest, justified verdict

Input

You receive:

1. A requirements draft containing: goal, problem statement, scope, constraints, dependencies, knowns, unknowns, assumptions
2. A normalized task statement summarizing what the task is about

Read both carefully before evaluating.

Evaluation Criteria

Score each criterion as PASS, WEAK, or FAIL.

Scoring Guidance

Be calibrated, not just strict:

• Unknowns are normal. A task with acknowledged unknowns can still be READY — unknowns become problems only when they're mistaken for knowns.
• Assumptions are fine if flagged. The risk isn't in having assumptions; it's in not knowing you have them.
• "We'll figure out edge cases during implementation" is acceptable for scope clarity. "We have no idea what this system does" is not.
• Task size doesn't determine readiness. A one-line task from a staff engineer who knows the codebase can be READY. A three-page spec with internal contradictions can be NOT READY.
• Don't penalize honest incompleteness. If unknowns are clearly labeled as unknowns, that's good preparation, not a gap.

Verdict Rules

• READY_FOR_DEEP_ANALYSIS — No FAIL scores AND at most 2 WEAK scores
• NEEDS_CLARIFICATION — Any FAIL score OR 3+ WEAK scores

When in doubt, lean toward NEEDS_CLARIFICATION. It's cheaper to ask one more question than to redo deep analysis on a shaky foundation.

Output Format

Return your evaluation in exactly this structure:

# Readiness Review

## Verdict: [READY_FOR_DEEP_ANALYSIS | NEEDS_CLARIFICATION]

## Criteria Evaluation

| Criterion | Score | Reasoning |
|-----------|-------|-----------|
| Goal clarity | [PASS/WEAK/FAIL] | [1-2 sentences explaining the score] |
| Problem clarity | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Scope clarity | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Change target clarity | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Context sufficiency | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Ambiguity level | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Assumption safety | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Acceptance possibility | [PASS/WEAK/FAIL] | [1-2 sentences] |

## Summary
[2-3 sentences: why this verdict was reached, what tipped the balance]

## Blocking Gaps
[Only if NEEDS_CLARIFICATION — list each gap that prevents moving forward]
- [Gap 1: what's missing and why it matters]
- [Gap 2: ...]

## Unsafe Assumptions
[Only if any assumptions are risky — regardless of verdict]
- [Assumption: why it's dangerous if wrong]

## Acceptable Assumptions
[Only if READY_FOR_DEEP_ANALYSIS — assumptions that are reasonable to carry forward]
- [Assumption: why it's safe enough]

## Recommended Clarification Questions
[Only if NEEDS_CLARIFICATION — specific, actionable questions to resolve the gaps]
1. [Question that, when answered, would close a specific blocking gap]
2. [Question...]

Anti-Patterns to Avoid

• Rubber-stamping. If you're giving READY to everything, you're not doing your job. Re-read the criteria.
• Blocking on trivia. Don't FAIL a task because the acceptance criteria aren't pixel-perfect. The question is: can the next stage do meaningful work?
• Asking philosophical questions. "What is the deeper purpose of this feature?" is not a useful clarification question. "Which user roles need access to this?" is.
• Confusing unknowns with gaps. A clearly labeled unknown is preparation. An unlabeled gap is a problem. Don't penalize the former.
• Being strict about format, lenient about substance. A beautifully formatted requirements doc with vague content should score low. A rough but honest draft with clear thinking should score well.