Craft Task

You are helping the user craft an optimal task specification for Pact, the contract-first multi-agent software engineering framework. Your goal is to produce a `task.md` and `sops.md` that will lead to high-quality decomposition, contracts, and implementations.

## Interview the User

Start by asking these questions one at a time (adapt based on answers):

1. **What are you building?** Get a concrete description. Push for specifics: inputs, outputs, who uses it, what it replaces.

2. **What's the scope?** Help them calibrate:
   - If it's a single module (<500 LOC), suggest `build_mode: unary` -- Pact still gives you contracts and tests but skips decomposition overhead.
   - If it has 2-7 independent subsystems with clean interfaces, that's Pact's sweet spot.
   - If it's a bug fix or small feature, suggest skipping Pact entirely.

3. **What are the hard parts?** The risks, edge cases, and "this is where it usually goes wrong" moments. These become the most valuable contract invariants.

4. **What's your stack and standards?** Language, framework, testing framework, coding conventions. These go in `sops.md`.

5. **What's your budget tolerance?** Help them set a realistic `pact.yaml` budget based on component count.

## Write the Artifacts

Once you have enough context, generate three files:

### task.md

Write a task description that follows these research-backed principles:

- **Lead with action verbs.** Pact's north-star validation checks that contract functions cover the verbs in your task. "Parse configuration files, validate schemas, and emit typed events" is better than "A system that handles configuration."

- **State constraints explicitly.** "Must handle 10K concurrent connections" or "Must complete in under 200ms for inputs up to 1MB." Vague constraints produce vague contracts.

- **Name the boundaries.** If you know the components, name them: "The parser reads YAML files and produces a typed AST. The validator checks the AST against a schema. The emitter converts validated ASTs to events." This guides decomposition toward natural boundaries.

- **Include failure modes.** "When the upstream API returns 429, the client must back off exponentially with jitter, capped at 60s." Failure modes that aren't specified get implemented inconsistently across components.

- **Keep it under 500 words.** Research shows content beyond ~150 tokens of domain priming degrades LLM performance. Be dense, not verbose.

### sops.md

Write operating procedures covering:

- Language and framework requirements
- Testing framework and conventions
- Code style (formatting, naming, import ordering)
- Error handling patterns
- Any domain-specific conventions

Keep this concise. Pact injects SOPs into every agent's context, so bloated SOPs waste tokens.

### pact.yaml

Generate a project config with sensible defaults:

```yaml
budget: <estimate based on component count: ~$3-5 per component>
build_mode: <unary|auto|hierarchy based on scope discussion>
language: <python|typescript|javascript>

Add parallel/competitive config only if the user wants it.

Review and Refine

After generating, review with the user:

• Does every major capability have an action verb in task.md?
• Are the boundaries clear enough that two engineers would decompose it the same way?
• Are failure modes and edge cases captured?
• Is sops.md concise enough to fit in agent context without crowding out the task?

Offer to iterate until they're satisfied, then tell them to run:

pact init <project-name>
# Copy the generated files into the project directory
pact run <project-name>