bmad-tech-spec

Name: bmad-tech-spec
Author: aj-geddes

23installs73forks

How to install bmad-tech-spec?

aj-geddes/claude-code-bmad-skills/bmad-tech-spec

$npx -y skills add aj-geddes/claude-code-bmad-skills --skill bmad-tech-spec

Installs into the current project.

Summary

Quick Flow lightweight technical specification for small-scope work (1-15 stories). Replaces the full PRD + architecture pair when scope is small and requirements are clear. Produces bmad-output/tech-spec.md as the single planning artifact before story creation. Use when the user

Files · 1

View on GitHub

SKILL.md

1	# BMAD Tech Spec — Quick Flow
2
3	This skill produces a focused `tech-spec.md` for Quick Flow work: small, well-scoped
4	features or changes that sit in the 1-15 story range. It consolidates the product
5	rationale, technical approach, and story backlog into a single lightweight document,
6	skipping the separate PRD + architecture artifacts that larger tracks require.
7
8	> Track guidance
9	> - 1-15 stories, single team, clear requirements → Quick Flow (this skill)
10	> - 10-50+ stories, multiple concerns, or uncertain scope → use bmad-prd then bmad-architecture
11	> - 30+ stories, cross-org, security/compliance/DevOps dimensions → Enterprise track
12
13	---
14
15	## Workflow
16
17	### Step 1 — Identify intent
18
19	Ask the user (or infer from context) which of three intents applies:
20
21	\| Intent \| When \|
22	\|--------\|------\|
23	\| Create \| No tech-spec.md exists yet \|
24	\| Update \| Revising scope, requirements, or approach in an existing spec \|
25	\| Validate \| Checking a draft spec for BMAD completeness before moving to stories \|
26
27	### Step 2 — Gather context
28
29	For Create, collect (interactively or from existing project files):
30
31	1. Problem & solution — what are we solving and how?
32	2. Scope — what is in scope? What is explicitly out of scope?
33	3. Functional requirements — numbered, MoSCoW-tagged (MUST / SHOULD / COULD)
34	4. Non-functional requirements — performance, security, accessibility targets that are relevant; omit boilerplate that does not apply
35	5. Technical approach — stack, key components, data model sketch, API surface (if any)
36	6. Story list — high-level backlog items; the scrum-master skill will compile them into full story files
37	7. Dependencies & risks — third-party libs, external services, known unknowns
38	8. Decision log entries — any choices made during this conversation that belong in `bmad-output/decision-log.md`
39
40	Load `bmad-output/project-context.md` if present — it is the project constitution and must
41	not be contradicted without a recorded decision.
42
43	For Update, read the existing `bmad-output/tech-spec.md` first, then apply targeted
44	edits and log what changed in the decision log.
45
46	For Validate, read the existing spec and report against the checklist in the
47	[Validation Checklist](#validation-checklist) section below.
48
49	### Step 3 — Draft or revise
50
51	Render the template at:
52
53	```
54	${CLAUDE_PLUGIN_ROOT}/skills/bmad-tech-spec/templates/tech-spec.template.md
55	```
56
57	Fill every section. Omit sections that genuinely do not apply (e.g., no API design for a
58	pure-CLI tool) and note the omission inline. Do not leave unreplaced `{{placeholders}}`.
59
60	Testing strategy in the spec is planning only — describe what should be tested and
61	why. Do not write test code. Do not set coverage numbers as mandatory targets; frame them
62	as guidance for the dev team.
63
64	### Step 4 — Write output
65
66	Write to `bmad-output/tech-spec.md` (respecting the `outputFolder` user config if set).
67
68	If decision-log entries were made, append them to `bmad-output/decision-log.md`
69	(create the file if it does not exist, using the format: `## [YYYY-MM-DD] <title>` /
70	`Decision: ...` / `Rationale: ...`).
71
72	### Step 5 — Confirm next steps
73
74	After writing, tell the user:
75
76	- The spec is the Quick Flow planning artifact. Story creation is the next step.
77	- Use bmad-epics-and-stories to compile stories from the story list in the spec.
78	- If scope has grown during this conversation beyond ~15 stories, recommend switching to
79	the BMad Method track (bmad-prd + bmad-architecture) before proceeding.
80
81	---
82
83	## Validation Checklist
84
85	When intent is Validate, report pass/fail for each item:
86
87	- [ ] Problem statement is clear and specific
88	- [ ] Solution is described without implementation code
89	- [ ] All functional requirements are numbered and MoSCoW-tagged
90	- [ ] Non-functional requirements include at least one performance or security entry if applicable
91	- [ ] Technical approach names the stack and descr

People who liked this also viewed

6 picks

Type

bmad-tech-spec

23installs73forks

View on GitHub

How to install bmad-tech-spec?

aj-geddes/claude-code-bmad-skills/bmad-tech-spec

$npx -y skills add aj-geddes/claude-code-bmad-skills --skill bmad-tech-spec

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# BMAD Tech Spec — Quick Flow
2
3	This skill produces a focused `tech-spec.md` for Quick Flow work: small, well-scoped
4	features or changes that sit in the 1-15 story range. It consolidates the product
5	rationale, technical approach, and story backlog into a single lightweight document,
6	skipping the separate PRD + architecture artifacts that larger tracks require.
7
8	> Track guidance
9	> - 1-15 stories, single team, clear requirements → Quick Flow (this skill)
10	> - 10-50+ stories, multiple concerns, or uncertain scope → use bmad-prd then bmad-architecture
11	> - 30+ stories, cross-org, security/compliance/DevOps dimensions → Enterprise track
12
13	---
14
15	## Workflow
16
17	### Step 1 — Identify intent
18
19	Ask the user (or infer from context) which of three intents applies:
20
21	\| Intent \| When \|
22	\|--------\|------\|
23	\| Create \| No tech-spec.md exists yet \|
24	\| Update \| Revising scope, requirements, or approach in an existing spec \|
25	\| Validate \| Checking a draft spec for BMAD completeness before moving to stories \|
26
27	### Step 2 — Gather context
28
29	For Create, collect (interactively or from existing project files):
30
31	1. Problem & solution — what are we solving and how?
32	2. Scope — what is in scope? What is explicitly out of scope?
33	3. Functional requirements — numbered, MoSCoW-tagged (MUST / SHOULD / COULD)
34	4. Non-functional requirements — performance, security, accessibility targets that are relevant; omit boilerplate that does not apply
35	5. Technical approach — stack, key components, data model sketch, API surface (if any)
36	6. Story list — high-level backlog items; the scrum-master skill will compile them into full story files
37	7. Dependencies & risks — third-party libs, external services, known unknowns
38	8. Decision log entries — any choices made during this conversation that belong in `bmad-output/decision-log.md`
39
40	Load `bmad-output/project-context.md` if present — it is the project constitution and must
41	not be contradicted without a recorded decision.
42
43	For Update, read the existing `bmad-output/tech-spec.md` first, then apply targeted
44	edits and log what changed in the decision log.
45
46	For Validate, read the existing spec and report against the checklist in the
47	[Validation Checklist](#validation-checklist) section below.
48
49	### Step 3 — Draft or revise
50
51	Render the template at:
52
53	```
54	${CLAUDE_PLUGIN_ROOT}/skills/bmad-tech-spec/templates/tech-spec.template.md
55	```
56
57	Fill every section. Omit sections that genuinely do not apply (e.g., no API design for a
58	pure-CLI tool) and note the omission inline. Do not leave unreplaced `{{placeholders}}`.
59
60	Testing strategy in the spec is planning only — describe what should be tested and
61	why. Do not write test code. Do not set coverage numbers as mandatory targets; frame them
62	as guidance for the dev team.
63
64	### Step 4 — Write output
65
66	Write to `bmad-output/tech-spec.md` (respecting the `outputFolder` user config if set).
67
68	If decision-log entries were made, append them to `bmad-output/decision-log.md`
69	(create the file if it does not exist, using the format: `## [YYYY-MM-DD] <title>` /
70	`Decision: ...` / `Rationale: ...`).
71
72	### Step 5 — Confirm next steps
73
74	After writing, tell the user:
75
76	- The spec is the Quick Flow planning artifact. Story creation is the next step.
77	- Use bmad-epics-and-stories to compile stories from the story list in the spec.
78	- If scope has grown during this conversation beyond ~15 stories, recommend switching to
79	the BMad Method track (bmad-prd + bmad-architecture) before proceeding.
80
81	---
82
83	## Validation Checklist
84
85	When intent is Validate, report pass/fail for each item:
86
87	- [ ] Problem statement is clear and specific
88	- [ ] Solution is described without implementation code
89	- [ ] All functional requirements are numbered and MoSCoW-tagged
90	- [ ] Non-functional requirements include at least one performance or security entry if applicable
91	- [ ] Technical approach names the stack and descr

People who liked this also viewed

6 picks

Type