Prompt file imported from loiane/specs-driven-development-spring-angular (.github/prompts/spec.prompt.md). Copyright stays with the author.

/spec

Name: spec
Author: loiane

Phase: 1 — specify Owning agent: .github/chatmodes/spec-author.chatmode.md Skills used: ears-spec-authoring, issue-tracker-ingestion, requirements-traceability

Purpose

Turn raw intent (a sentence, a paragraph, or a ticket URL) into a complete EARS-style specification at .specs/<feature-id>/01-spec.md.

Inputs

Either:

Free text describing the feature, OR
A ticket reference (JIRA-123, GitHub issue URL, Linear ID, Azure work item URL).

If a ticket is supplied, fetch it via the configured MCP server (see .github/skills/issue-tracker-ingestion/SKILL.md) and treat its body as the source.

Reads

The supplied text or ticket.
.specs/_onboarding.md (for stack context).
.github/templates/spec.template.md.
.github/checklists/spec-review.md (so the spec is born review-ready).

Writes

.specs/<feature-id>/01-spec.md (feature-id = kebab-case slug derived from the title, prefixed with date YYYY-MM-DD-).

Process

Derive <feature-id>. Refuse if a folder with that id already exists unless the user passes --continue.
Extract: business goal, primary actor, in-scope, explicitly-out-of-scope.
Write acceptance criteria as AC-001, AC-002, ... using strict EARS forms (Ubiquitous, Event-driven, State-driven, Unwanted-behavior, Optional). Every AC must be testable.
List non-functional requirements (latency, throughput, security, observability) with concrete numbers. If unknown, file an Open Question instead of guessing.
Capture Open Questions as Q-001, Q-002. Never invent answers. Stop and surface the questions to the user.
Render the file using .github/templates/spec.template.md.

Refuse if

The input has fewer than 3 distinct nouns/verbs (likely too vague — ask the user to expand).
Any acceptance criterion would require unstated assumptions.

Done when

01-spec.md exists with at least one AC and zero invented answers.
All ambiguities are listed under ## Open Questions with Q-NNN IDs.
The user has been told the next command is /spec-review (after they answer any Q-NNN).

# /spec **Phase:** 1 — specify **Owning agent:** `.github/chatmodes/spec-author.chatmode.md` **Skills used:** `ears-spec-authoring`, `issue-tracker-ingestion`, `requirements-traceability` ## Purpose Turn raw intent (a sentence, a paragraph, or a ticket URL) into a complete EARS-style specification at `.specs/<feature-id>/01-spec.md`. ## Inputs Either: - Free text describing the feature, OR - A ticket reference (`JIRA-123`, GitHub issue URL, Linear ID, Azure work item URL). If a ticket is supplied, fetch it via the configured MCP server (see `.github/skills/issue-tracker-ingestion/SKILL.md`) and treat its body as the source. ## Reads - The supplied text or ticket. - `.specs/_onboarding.md` (for stack context). - `.github/templates/spec.template.md`. - `.github/checklists/spec-review.md` (so the spec is born review-ready). ## Writes - `.specs/<feature-id>/01-spec.md` (feature-id = kebab-case slug derived from the title, prefixed with date `YYYY-MM-DD-`). ## Process 1. Derive `<feature-id>`. Refuse if a folder with that id already exists unless the user passes `--continue`. 2. Extract: business goal, primary actor, in-scope, explicitly-out-of-scope. 3. Write acceptance criteria as `AC-001`, `AC-002`, ... using strict EARS forms (Ubiquitous, Event-driven, State-driven, Unwanted-behavior, Optional). Every AC must be testable. 4. List non-functional requirements (latency, throughput, security, observability) with concrete numbers. If unknown, file an `Open Question` instead of guessing. 5. Capture `Open Questions` as `Q-001`, `Q-002`. **Never invent answers.** Stop and surface the questions to the user. 6. Render the file using `.github/templates/spec.template.md`. ## Refuse if - The input has fewer than 3 distinct nouns/verbs (likely too vague — ask the user to expand). - Any acceptance criterion would require unstated assumptions. ## Done when - `01-spec.md` exists with at least one AC and zero invented answers. - All ambiguities are listed under `## Open Questions` with `Q-NNN` IDs. - The user has been told the next command is `/spec-review` (after they answer any Q-NNN).

{ "prompt": "# /spec\n\n**Phase:** 1 — specify\n**Owning agent:** `.github/chatmodes/spec-author.chatmode.md`\n**Skills used:** `ears-spec-authoring`, `issue-tracker-ingestion`, `requirements-traceability`\n\n## Purpose\nTurn raw intent (a sentence, a paragraph, or a ticket URL) into a complete EARS-style specification at `.specs/<feature-id>/01-spec.md`.\n\n## Inputs\nEither:\n- Free text describing the feature, OR\n- A ticket reference (`JIRA-123`, GitHub issue URL, Linear ID, Azure work item URL).\n\nIf a ticket is supplied, fetch it via the configured MCP server (see `.github/skills/issue-tracker-ingestion/SKILL.md`) and treat its body as the source.\n\n## Reads\n- The supplied text or ticket.\n- `.specs/_onboarding.md` (for stack context).\n- `.github/templates/spec.template.md`.\n- `.github/checklists/spec-review.md` (so the spec is born review-ready).\n\n## Writes\n- `.specs/<feature-id>/01-spec.md` (feature-id = kebab-case slug derived from the title, prefixed with date `YYYY-MM-DD-`).\n\n## Process\n1. Derive `<feature-id>`. Refuse if a folder with that id already exists unless the user passes `--continue`.\n2. Extract: business goal, primary actor, in-scope, explicitly-out-of-scope.\n3. Write acceptance criteria as `AC-001`, `AC-002`, ... using strict EARS forms (Ubiquitous, Event-driven, State-driven, Unwanted-behavior, Optional). Every AC must be testable.\n4. List non-functional requirements (latency, throughput, security, observability) with concrete numbers. If unknown, file an `Open Question` instead of guessing.\n5. Capture `Open Questions` as `Q-001`, `Q-002`. **Never invent answers.** Stop and surface the questions to the user.\n6. Render the file using `.github/templates/spec.template.md`.\n\n## Refuse if\n- The input has fewer than 3 distinct nouns/verbs (likely too vague — ask the user to expand).\n- Any acceptance criterion would require unstated assumptions.\n\n## Done when\n- `01-spec.md` exists with at least one AC and zero invented answers.\n- All ambiguities are listed under `## Open Questions` with `Q-NNN` IDs.\n- The user has been told the next command is `/spec-review` (after they answer any Q-NNN).", "variables": [], "notes": "Run /spec — see .github/prompts/spec.prompt.md for the authoritative spec. Mode: agent. Tools: codebase, editFiles, search, runCommands, runTests.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/loiane/specs-driven-development-spring-angular", "path": ".github/prompts/spec.prompt.md", "ref": "3f177c1524042bf093bd5b26cf646a4933d0a906", "url": "https://github.com/loiane/specs-driven-development-spring-angular/blob/3f177c1524042bf093bd5b26cf646a4933d0a906/.github/prompts/spec.prompt.md", "key": "loiane/specs-driven-development-spring-angular/.github/prompts/spec.prompt.md" } }, "model_hints": [ "GPT-5" ] }

spec

About

/spec

Purpose

Inputs

Reads

Writes

Process

Refuse if

Done when

Use it

Manifest

Reviews