---
name: request-to-spec-issues
description: Use after a grill-change session is complete to turn the agreement record into an intent-first spec candidate and vertical TDD-ready issue briefs.
---

<!-- Generated by Agent Profile Compiler. Do not edit by hand. -->

# Request To Spec Issues

## Purpose

Convert a completed `grill-change` agreement record into an intent-first spec candidate and vertical TDD-ready issue briefs. Preserve product intent and decision rules so implementation choices follow the agreed direction.

## Preconditions

- The grill is complete.
- The user has confirmed the direction is ready for synthesis.
- Relevant local specs, ADRs, docs, fixtures, and code context have been checked.
- If there is no completed grill agreement, stop and run `grill-change` first.

## Synthesis Rules

1. Do not re-interview the user unless the grill record contains a contradiction or a genuinely missing decision.
2. Keep product intent, non-goals, durable terms, and hard-to-reverse decisions above implementation mechanics.
3. Preserve existing spec contracts and safety rules unless the user explicitly approved changing them.
4. Split work into vertical behavior slices, not file layers.
5. Make every issue small enough for a focused RED, GREEN, refactor loop.
6. Mark dependencies and parallel-safe work explicitly.
7. Propose architecture rescue candidates before feature slices when a change would deepen an already fragmented codebase.

## Architecture Rescue Candidates

When architecture rescue is needed, propose candidates before feature issues. Each candidate must include:

- Files or modules involved
- Current friction
- Proposed deeper module or clearer interface
- Expected locality and leverage improvement
- Expected test improvement
- ADR or spec conflicts
- Recommended dependency state: prerequisite, parallel, or later cleanup

## Spec Candidate

Include these sections:

- Status
- Problem
- Goal
- Intent
- Decision Rules
- Non-Goals
- User Flow
- Inputs
- Outputs
- Contracts
- Security Rules
- Acceptance Criteria
- Tests
- TDD Strategy
- Issue Plan
- Documentation Updates
- Final Review Checklist

`TDD Strategy` complements `Tests`; it must not replace the required `Tests`
section from `docs/specs/SPEC_TEMPLATE.md`.

## Issue Brief Format

Each issue brief must include:

- Title
- Parent spec or request
- Intent summary
- Behavior slice
- Non-goals
- Acceptance criteria
- Expected RED proof
- Expected GREEN proof
- Test command guidance
- Likely file ownership
- Dependencies
- Parallelism notes
- Contract impact
- Security impact
- Documentation impact
- Implementation context
- Review expectations

## Dependency States

Use these states:

- `ready`
- `blocked`
- `parallel-safe`
- `sequenced`
- `human-gate`

## Output

Return:

- Spec candidate or spec patch
- Vertical issue briefs
- Dependency map
- Parallelism map
- Human gates
- Recommended next step

## Safety

- Do not upload source code.
- Do not read or print secrets.
- Do not include credentials, environment values, production data, or private endpoints.
- Do not create GitHub issues, labels, projects, or milestones.
- Do not write files unless the user explicitly asks for local file writes after reviewing the synthesis.
- Do not propose `bypassPermissions`, tool pre-approval, dependency auto-installation, hosted execution, or remote MCP behavior.