workflow-spec-writer

Stars9

Forks0

UpdatedJuly 21, 2026 at 17:51

Write a feature spec for the AI development workflow. Use when a new feature needs to move from backlog into the spec stage.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

lhpaul

lhpaul/ai-dev-framework-template

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name	workflow-spec-writer
description	Write a feature spec for the AI development workflow. Use when a new feature needs to move from backlog into the spec stage.

Workflow Spec Writer

Recommended model tier: premium

Read AGENTS.md for repository-wide rules and branch overrides.
Read docs/workflow/development-workflow/protocols/01-generate-spec-protocol.md.
Follow that protocol exactly.
Keep the spec product-focused; implementation details belong in the plan stage.
When the handoff includes output from scripts/development-workflow/spec-dispatch-context.sh, read it before the alignment conversation. Preserve confirmed decisions and non-blocking relationship outcomes as product constraints. Do not turn helper mechanics, token matching, JSON fields, or implementation algorithms into spec requirements. If context is blocking=true or Unclear, stop for the named human relationship decision.
When BATCH_CONTEXT=true, complete the isolation self-check before the first file edit, branch-changing command, commit, push, PR mutation, or tracker mutation: verify isolation: "worktree", expected worktree path, expected branch, artifact repo root, approved base branch, and mutation classification are present; ensure pwd -P equals the expected worktree path or begins with the expected worktree path followed by / and compare only the expected branch to git rev-parse --abbrev-ref HEAD. Stop before mutation on missing metadata, wrong CWD, main-repo CWD, or wrong branch; escalate if mutation may already have occurred outside the assigned worktree.
For substantial or multi-part mutating spec work, commit immediately after each completed logical sub-part, do not intentionally batch all completed sub-parts into one end-of-run commit, and never commit incomplete, failing, or incoherent edits only to satisfy the requirement.
Before opening the draft spec PR, complete Protocol 01's Document Quality Gate and include the gate log in the PR description. For tracker-backed briefs, include the mandatory Brief Objective List, Coverage Matrix, and PR-visible Deferral Notes as part of that gate. For complex workflow decision-gate specs, include Protocol 01's consistency matrix or not-applicable rationale.
Before opening the draft spec PR, call ensure_on_project_board <issue_number> "Writing Spec" from scripts/development-workflow/workflow-lib.sh. This is a no-op when the issue is already on the board.
Before creating the spec branch or opening the spec PR for a tracker-backed item, run run-nested-artifact-guard.sh with required --mode, --issue, --expected-branch, --approved-base, plus the expected spec/* branch and approved artifact base. Stop on missing base, duplicate artifacts, wrong-base PRs, or scan failures.
When creating the development folder, discover design assets per docs/workflow/development-workflow/design-assets.md. If confirmed tracker design assets exist, copy or download them into <dev-folder>/assets/ and update the issue-body location note. Do not invent assets when none exist.
When the branch is created, continue through reviewer gate, PR creation, and PR readiness unless the protocol surfaces a real human decision.
Resolve repository mode, artifact owner, and artifact base branch before writing: single_repo uses the current repository; workflow_hub keeps specs and spec PRs hub-owned on the hub artifact base branch, even when the product implementation base is different; product_repo should report the configured hub owner or stop if ownership is ambiguous.

More from this repository

same repository

workflow-retrospective

lhpaul/ai-dev-framework-template

Run a retrospective analysis on completed work to identify process improvement opportunities. Use when the user wants to review a completed batch or item run, or invoke on-demand with a PR number, branch, or date as scope hint.

2026-07-309

run-epic

lhpaul/ai-dev-framework-template

Compatibility/advanced alias: resolve a native GitHub epic into a bounded workflow execution scope, with optional delegated review and merge gates. For the recommended starting point, use /run-work <epic-target> instead. Use /run-epic when you need direct control over delegation flags (--delegate-review, --may-merge, --max-risk). For explicit item lists, use /run-items.

2026-07-309

run-items

lhpaul/ai-dev-framework-template

Bounded multi-item execute command: advance two or more explicit workflow items through Protocol 90 explicit_list mode. For a single item use $run-item; for an epic use $run-epic; for a read-only portfolio scan use $run-work.

2026-07-309

run-work

lhpaul/ai-dev-framework-template

Read-only portfolio scan. No-target scan proposes batches with no dispatch. Two or more targets redirect to $run-items. Single targets redirect to $run-item or $run-epic. No mutation in any mode.

2026-07-309

workflow-orchestrator

lhpaul/ai-dev-framework-template

Batch-orchestrate the repository's staged AI development workflow. Use when the user wants Codex to discover what can advance or start across multiple items, propose the largest safe batch by priority and parallelization feasibility, and supervise approved item work until it reaches a real terminal condition.

2026-07-309

run-item

lhpaul/ai-dev-framework-template

Primary bounded command: advance exactly one non-epic workflow item. Use when the user asks for /run-item or wants to resume a specific development, branch, PR, or issue with the shared bounded prelude before Protocol 91. /run-item-work is a deprecated alias with identical behavior.

2026-07-299

Workflow Spec Writer

Recommended model tier: premium

Read AGENTS.md for repository-wide rules and branch overrides.

Read docs/workflow/development-workflow/protocols/01-generate-spec-protocol.md.

Follow that protocol exactly.

Keep the spec product-focused; implementation details belong in the plan stage.

When the handoff includes output from scripts/development-workflow/spec-dispatch-context.sh, read it before the alignment conversation. Preserve confirmed decisions and non-blocking relationship outcomes as product constraints. Do not turn helper mechanics, token matching, JSON fields, or implementation algorithms into spec requirements. If context is blocking=true or Unclear, stop for the named human relationship decision.

When BATCH_CONTEXT=true, complete the isolation self-check before the first file edit, branch-changing command, commit, push, PR mutation, or tracker mutation: verify isolation: "worktree", expected worktree path, expected branch, artifact repo root, approved base branch, and mutation classification are present; ensure pwd -P equals the expected worktree path or begins with the expected worktree path followed by / and compare only the expected branch to git rev-parse --abbrev-ref HEAD. Stop before mutation on missing metadata, wrong CWD, main-repo CWD, or wrong branch; escalate if mutation may already have occurred outside the assigned worktree.

For substantial or multi-part mutating spec work, commit immediately after each completed logical sub-part, do not intentionally batch all completed sub-parts into one end-of-run commit, and never commit incomplete, failing, or incoherent edits only to satisfy the requirement.

Before opening the draft spec PR, complete Protocol 01's Document Quality Gate and include the gate log in the PR description. For tracker-backed briefs, include the mandatory Brief Objective List, Coverage Matrix, and PR-visible Deferral Notes as part of that gate. For complex workflow decision-gate specs, include Protocol 01's consistency matrix or not-applicable rationale.

Before opening the draft spec PR, call ensure_on_project_board <issue_number> "Writing Spec" from scripts/development-workflow/workflow-lib.sh. This is a no-op when the issue is already on the board.

Before creating the spec branch or opening the spec PR for a tracker-backed item, run run-nested-artifact-guard.sh with required --mode, --issue, --expected-branch, --approved-base, plus the expected spec/* branch and approved artifact base. Stop on missing base, duplicate artifacts, wrong-base PRs, or scan failures.

When creating the development folder, discover design assets per docs/workflow/development-workflow/design-assets.md. If confirmed tracker design assets exist, copy or download them into <dev-folder>/assets/ and update the issue-body location note. Do not invent assets when none exist.

When the branch is created, continue through reviewer gate, PR creation, and PR readiness unless the protocol surfaces a real human decision.

Resolve repository mode, artifact owner, and artifact base branch before writing: single_repo uses the current repository; workflow_hub keeps specs and spec PRs hub-owned on the hub artifact base branch, even when the product implementation base is different; product_repo should report the configured hub owner or stop if ownership is ambiguous.