speckit-full

name	speckit-full
description	Autonomous end-to-end speckit pipeline: specify → clarify (self-answered) → plan → tasks → implement → open PR. No human input required.
compatibility	Requires spec-kit project structure with .specify/ directory and gh CLI
metadata	{"author":"azdo-cli"}

User Input

$ARGUMENTS

The text after the command invocation is the feature description. You MUST use it — do not ask the user to repeat it.

Goal

Run the full speckit pipeline completely autonomously through to a merged-ready pull request. At every step where the standard workflow would pause and ask the user a question, answer it yourself using:

1. Existing code patterns in src/
2. Project conventions in CLAUDE.md and .specify/memory/constitution.md
3. Persistent repo memory in .specify/memory/speckit-memory.md (if present)
4. Relevant project-local helper skills under .agents/skills/ (if present)
5. Industry-standard defaults for a TypeScript CLI tool
6. Conservative scope (never add features not mentioned in the description)

Document every autonomous decision as an assumption in the spec's Assumptions section.

Before Phase 1, load .specify/memory/speckit-memory.md if it exists. Treat it as reusable project memory, not as authority: current code, the constitution, and the active feature spec always win if they conflict.

If a project-local helper skill exists for a repo-specific workflow discovered in prior runs, follow it rather than re-deriving the process from scratch.

---

Phase 1 — Specify

Execute the full speckit-specify workflow using $ARGUMENTS as the feature description.

Autonomous clarification rule: If the specify step generates any [NEEDS CLARIFICATION] markers or presents multiple-choice questions, do NOT wait for user input. Instead:

1. Evaluate each option against the project's existing patterns (TypeScript CLI, commander.js, Azure DevOps API).
2. Select the option that best fits the existing codebase conventions and minimizes scope.
3. Replace the marker with your chosen answer.
4. Record your decision in the spec's ## Assumptions section as: - [AUTO] <topic>: chose <answer> because <one-line rationale>

Proceed when the spec file is written and the checklist passes.

---

Phase 2 — Clarify (Autonomous)

Execute the speckit-clarify workflow, but answer every question yourself without pausing.

For each question the clarify step raises:

1. Analyze all options against:
   • Existing code in src/ (read relevant files if needed)
   • CLAUDE.md tech stack and conventions
   • .specify/memory/constitution.md principles
   • Reasonable defaults for a TypeScript Node.js CLI tool targeting Azure DevOps
2. Select the best option — prefer consistency with existing code over novelty.
3. Immediately record the answer: append - Q: <question> → A: <answer> [AUTO: <rationale>] to the ## Clarifications section in the spec.
4. Apply the clarification to the relevant spec section as the standard clarify workflow would.
5. Do not present questions to the user — treat every question as if the user replied "recommended" (accept your own recommendation).

If the clarify step reports "No critical ambiguities detected", proceed immediately.

Stop after all questions are processed (max 5 per clarify rules). Save the updated spec.

---

Phase 3 — Plan

Execute the full speckit-plan workflow.

Autonomous clarification rule: If the plan step encounters any NEEDS CLARIFICATION items during Phase 0 research, resolve them autonomously using the same approach as Phase 2. Document each resolution in research.md under an ## Autonomous Decisions section.

Proceed when plan.md, research.md, and all Phase 1 artifacts are written. Ensure planning decisions remain explicit in research.md using the standard Decision / Rationale / Alternatives considered structure so they can be transferred into the separate PR appendix later.

---

Phase 4 — Tasks

Execute the full speckit-tasks workflow.

Generate tasks.md following the standard task generation rules. No user interaction required.

---

Phase 5 — Prepare PR Artifacts

Before implementation begins, initialise the reviewer-facing PR artifacts from their templates so they can be incrementally updated during implementation while keeping summary and planning decisions separate.

Steps

1. Read .specify/templates/pr-report-template.md and .specify/templates/spec-decisions-template.md.

2. Pre-fill every placeholder in pr-report-template.md that is already known at this point:

   • [FEATURE NAME] → feature name from the spec header
   • [###-feature-name] → output of git rev-parse --abbrev-ref HEAD
   • [DATE] → today's date in YYYY-MM-DD format
   • [Link to spec.md …] → relative path from repo root to spec.md
   • Summary → derived from the spec's first user story and overall description (2–3 sentences, non-technical)
   • Leave What's New, Testing, and optional sections as placeholders — they are completed in Phase 7.

3. Pre-fill spec-decisions-template.md using planning artifacts:

   • [FEATURE NAME] → feature name from the spec header
   • [###-feature-name] → output of git rev-parse --abbrev-ref HEAD
   • [DATE] → today's date in YYYY-MM-DD format
   • [Link to spec.md …], [Link to plan.md …], [Link to research.md …] → relative paths from repo root
   • Planning Decisions → convert each planning-phase decision captured in research.md, plus any explicit structure decision recorded in plan.md, into one bullet containing the chosen approach, rationale, and alternatives considered
   • Keep this file limited to planning decisions only; do not duplicate implementation progress, testing, or release notes from pr-report.md

4. Write the files to FEATURE_DIR/pr-report.md and FEATURE_DIR/spec-decisions.md.

5. Commit them to the feature branch:

   git add FEATURE_DIR/pr-report.md FEATURE_DIR/spec-decisions.md
   git commit -m "docs: initialise PR artifacts for [FEATURE NAME]"
   

---

Phase 6 — Implement

Execute the full speckit-implement workflow.

• Follow TDD approach: write tests before implementation where tasks specify it.
• Complete every task in tasks.md and mark each as [X] when done.
• Run npm test && npm run lint (or project equivalent) after all tasks are complete. Fix any failures before proceeding.
• Do NOT open the PR yet.

---

Phase 7 — Finalise PR Artifacts

After implementation is confirmed green, complete the remaining PR artifacts.

Filling guidelines

Load FEATURE_DIR/pr-report.md (already partially filled in Phase 5) and complete the remaining sections:

Section	How to fill
What's New	One bullet per meaningful concern (command, service, config key, etc.) — not per file. Derive from completed tasks in tasks.md and architecture sections of plan.md.
New Libraries / Dependencies	List only packages that did not exist before this branch. Pull versions from package.json. Remove the section if none were added.
Breaking Changes	Include only if existing public behaviour (CLI flags, config keys, API contracts) changed. Remove section if none.
Testing	List test types used (unit, integration, e2e, manual) and what each covers. Derive from test tasks in tasks.md.
Notes	Known limitations, deferred scope, or follow-up issues. Remove section if none.

Then validate FEATURE_DIR/spec-decisions.md against the final plan.md and research.md:

• Keep it limited to planning-phase decisions and their rationale
• Update it only if planning artifacts changed during implementation
• Do not add implementation status, testing notes, or release-summary content to this file

Replace ALL remaining […] markers across both files. Remove optional sections that do not apply.

Commit the finalised artifacts:

git add FEATURE_DIR/pr-report.md FEATURE_DIR/spec-decisions.md
git commit -m "docs: finalise PR artifacts for [FEATURE NAME]"

---

Phase 8 — Update Run Memory

After implementation is green and PR artifacts are final, persist reusable lessons from this execution for later runs.

Steps

1. Execute the speckit-memory workflow in .agents/skills/speckit-memory/SKILL.md.

2. Update .specify/memory/speckit-memory.md with stable, reusable lessons from this run only.

3. If this run revealed a repeatable repo-specific workflow that deserves its own helper skill, create or update that skill under .agents/skills/.

4. If the memory file or helper skill files changed, commit them:

   git add .specify/memory/speckit-memory.md <helper-skill-paths>
   git commit -m "docs: refresh speckit memory for [FEATURE NAME]"
   

5. If no memory-related files changed, continue without creating a commit.

---

Phase 9 — Open Pull Request

Use the completed pr-report.md followed by spec-decisions.md as the PR body, keeping the two sections distinct.

Steps

1. Push the feature branch:

   git push -u origin HEAD
   

2. Derive the PR title from the Summary section: use the first sentence, truncated to 70 characters, prefixed with feat(<branch-number>): .

3. Open the PR:

   gh pr create \
     --title "<PR title>" \
       --body "$(cat FEATURE_DIR/pr-report.md && printf '\n\n---\n\n' && cat FEATURE_DIR/spec-decisions.md)" \
     --base develop \
     --head <feature-branch>
   

4. Report the PR URL to the user.

---

Completion Report

After all phases complete, output:

## speckit-full Complete

**Feature**: <branch name>
**Spec**: <path to spec.md>
**Plan**: <path to plan.md>
**Tasks**: <path to tasks.md>
**PR Report**: <path to pr-report.md>
**Spec Decisions**: <path to spec-decisions.md>
**Memory**: <path to .specify/memory/speckit-memory.md>
**Helper Skills Updated**: <list or "none">
**Pull Request**: <PR URL>

**Autonomous decisions made**: <count>
<list each AUTO decision with its rationale>

---

Failure Handling

• If any phase fails with a hard error (missing script, invalid branch state), stop and report the error with the exact command output. Do not silently skip phases.
• If the spec quality checklist fails after 3 iterations, document remaining issues and continue to Phase 2 rather than blocking.
• If gh is not installed or not authenticated, print the contents of pr-report.md followed by spec-decisions.md with a clear separator and instruct the user to open the PR manually.
• If the push fails, report the error and do NOT force-push.
• If later phases fail after useful repo-specific lessons were discovered, update .specify/memory/speckit-memory.md before exiting when possible.
• Never fabricate file paths or script outputs — always run scripts and use real output.