/openspec-plus-tasks

name: openspec-plus-tasks
description: "MANDATORY skill that activates whenever the OpenSpec tasks phase begins. Triggers: /opsx-new or /opsx-continue runs; openspec-new-change, openspec-continue-change, or openspec-explore is active; `openspec instructions tasks` is invoked; or the user wants to create, update, review, refine, or discuss an OpenSpec tasks.md file."
metadata:
  version: 1.6.1
  priority: high
  disable-user-invocation: true

OpenSpec Plus Tasks

Mission

Enrich OpenSpec's tasks.md generation with vertical-slice discipline and subagent review. Format is owned by the schema template (resolved in Phase 0) — this skill provides thinking discipline before the file is written and a subagent review after.

Two anchors that shape every task group:

1. **Each task group = a vertical slice** — end-to-end through whatever layers are needed, not horizontal layer-by-layer 2. **Each task group completion = a testable outcome** — after the last task in a group is checked, the user can verify something works

---

> **This skill is RIGID. NEVER write tasks.md before completing Phase 1 vertical-slice discovery. NEVER skip the subagent review. Reading source code, writing implementation code, running TDD, including exact commit messages, or restructuring the template format is a skill violation.**

**Red flags — STOP, you are about to violate this skill:**

• "I'll group by layer (DB / API / UI) to keep similar tech together"
• "This task group is preparatory work, it doesn't need to be testable on its own"
• "I'll add a 'Files' or 'Dependencies' section to the tasks.md"
• "I should peek at the code to figure out what files to touch"
• "Let me put exact code or shell commands in the task description"
• "The reviewer subagent isn't needed, the tasks look fine to me"
• "Reviewer flagged minor issues, I'll re-dispatch after fixing to confirm"
• "I'll add commit instructions per task"
• "Let me write a TDD-ordered set of sub-tasks"

---

Inputs

• **Proposal** — intent, scope boundaries, non-goals
• **Specs** — requirements with Gherkin scenarios
• **Design** — architecture decisions, file structure, integration points
• **Existing tasks.md files** in `openspec/changes/` — for naming convention only
• **NEVER read source code** — design phase already grounded patterns

If the design is missing detail you need to slice the work, the design is incomplete. Surface the gap to the user — do not paper over with code reading.

---

Workflow

Three phases. NEVER skip or merge.

Phase 0: Schema & Template Resolution
Phase 1: Vertical Slicing & Discovery
Phase 2: Write & Artifact Compliance Review

---

Workflow Visibility (MANDATORY)

Display workflow phases via task tool at start; update as each phase completes.

---

Core Principles

• **Vertical Slice** — each `## N.` heading is a vertical slice: a feature or capability that, when all its tasks are done, produces one end-to-end testable outcome expressible in a single sentence. The slice heading implies the outcome. A slice spans whatever layers are needed (DB, API, UI, CLI). Slices are dependency-ordered — each slice's prerequisites are satisfied by earlier slices.
• **Task** — each `- [ ]` item is a capability the implementer delivers in one work session. A task operates at the spec **requirement** level, not the **scenario** level. It names the capability and summarizes the behavioral facets the implementer must deliver. The spec's Gherkin scenarios are the implementer's test cases during TDD — the task points to the capability; the spec holds the individual test cases. "Done" is unambiguous from the task description alone.
• **WHAT, not HOW** — tasks state what behavior to deliver. The design document holds how: method signatures, struct fields, trait members, wiring steps, data layouts, file creation sequences. The implementer reads the design for architectural guidance and discovers code through TDD. File paths may appear inline to orient (e.g., "Add stream validation to `src/kinesis/handler.rs`") but never as step-by-step choreography.
• **Behavior only** — each task describes a behavior the system exhibits after implementation. Not infrastructure to create before any behavior uses it. Not a process step to run (gate, test suite, build, codegen command). Infrastructure emerges as the implementer delivers behavior through TDD. Verification is the implementer's responsibility per the TDD cycle.
• **Traceability** — every task traces to a spec requirement, design decision, or stakeholder need. No speculative tasks. Follow project conventions (read `AGENTS.md`, `CLAUDE.md`, equivalents at Phase 1 start; conflicts → surface to user, never silently override).

---

Phase 0: Schema & Template Resolution

Run FIRST, before any slicing:

1. Run:

   openspec instructions tasks --change <name> --json

Extract: `template` (structural authority; format you MUST follow), `instruction` (guidance on what content each section needs), `rules` (project constraints to honor). Parse template structure — if it includes metadata fields (priority, effort, labels, categories) beyond the default `## N. Name` + `- [ ] N.M desc` format, Phase 1 must collect that information during slicing; discovery questions MUST satisfy template requirements. 2. Read `openspec/.plus/config.yaml` (missing/unreadable/unrecognized → defaults): `settings.questionMode` (`sequential` default; `batch` groups step 5's clarifying questions into one round — see Phase 1 below).

---

Phase 1: Pre-Write Discovery & Vertical Slicing (MANDATORY)

**Pre-existing answers:** If recent conversation already identifies vertical slices, names testable outcomes, or establishes dependency ordering — via prior exploration, a detailed initial request, or any other source — incorporate those and SKIP redundant clarification. Ask ONE question at a time only for unresolved slicing decisions (`batch` mode: present them together instead — see step 5).