spike

Name: spike
Author: dan-the-dev

27stars0forks

How to install spike?

dan-the-dev/xp-developer-skills/spike

$npx -y skills add dan-the-dev/xp-developer-skills --skill spike

Installs into the current project.

Summary

XP-style spike — time-boxed experiment on an isolated branch; code is disposable. Answer one technical or design question (feasibility, library fit, performance bound, integration). Use automated checks only when they help prove the goal — no delivery test pyramid, no ATDD/TDD di

Files · 1

View on GitHub

SKILL.md

1	# Spike (time-boxed experiment)
2
3	## Mission
4
5	A spike is a small, time-boxed experiment to reduce uncertainty: prove a point, test an idea, a feature approach, or a library / API / integration — not to deliver production-ready software.
6
7	All spike code lives on an isolated branch (see [references/charter-and-timebox.md](references/charter-and-timebox.md)). Treat that branch as throwaway: merge to main only after explicit promotion into normal delivery workflows; default outcome is discard the branch and keep the spike report.
8
9	Optimize for:
10
11	- One clear question (hypothesis) and evidence (yes / no / inconclusive)
12	- Isolation — experiment does not pollute main or production paths
13	- Speed of learning — ignore polish, pyramid, and “proper” architecture unless they are the question
14	- Honest handoff — promotion to `skills/atdd`, `skills/tdd`, or `skills/legacy-testing` when building for real
15
16	NOT for:
17
18	- shipping user-facing behavior from the spike branch as-is
19	- full test pyramid, example catalogs, or test lists on the spike branch
20	- `skills/bugfix`, `skills/refactoring` (delivery hats), or legacy harness unless the spike question is specifically “can we test this seam?”
21
22	---
23
24	## What a spike is (XP)
25
26	From Extreme Programming: a very simple program (or script) that explores a tough technical or design problem, addresses only that problem, and is often thrown away. Goal: reduce risk or improve estimates — “What is the simplest thing we can try that convinces us we are on the right track?” (Kent Beck / Ward Cunningham).
27
28	Use spikes when you are knowledge-limited, not merely time-limited. See [references/definition-and-when.md](references/definition-and-when.md).
29
30	---
31
32	## Isolated branch (mandatory)
33
34	Before writing spike code:
35
36	1. Create a dedicated branch — e.g. `spike/<short-question-slug>` off the agreed base (`main` / `develop`).
37	2. Do all spike edits on that branch only — no mixed commits on feature or main branches.
38	3. Assume disposal — do not depend on spike structure in production; do not ask reviewers to treat spike code as product.
39
40	When the spike ends:
41
42	- Discard: delete branch or abandon without merge; keep spike report (charter artifact).
43	- Promote: open a new branch / slice and re-implement (or carefully port ideas, not bulk paste) under `skills/atdd` / `skills/tdd` / `skills/legacy-testing`.
44
45	---
46
47	## Tests on a spike (pragmatic only)
48
49	Spikes are not governed by the delivery test pyramid ([references/spike-vs-other-skills.md](references/spike-vs-other-skills.md)).
50
51	\| Use automated checks when… \| Skip when… \|
52	\|----------------------------\|------------\|
53	\| They directly prove the hypothesis (script assertion, one integration call, timing log) \| You would be building a “proper” unit/integration suite for maintainability \|
54	\| A failing check would invalidate the approach quickly \| ATDD example catalog or TDD test list is required \|
55	\| A one-off test is faster than manual clicking \| Refactoring for testability is unrelated to the question \|
56
57	No requirement for: layered pyramid, characterization of full modules, Gherkin, CI gates on the spike branch, or green-before-every-step TDD. Manual proof (logs, screenshots, measured latency) is valid when it answers the charter.
58
59	---
60
61	## Workflow
62
63	### 1. Charter (before code)
64
65	Record in chat or `docs/spikes/<slug>.md` (see [references/charter-and-timebox.md](references/charter-and-timebox.md)):
66
67	- Hypothesis / question (one sentence)
68	- Success signal / failure signal
69	- Time box
70	- Out of scope (including: “no production design”, “no full test suite”)
71	- Branch name (`spike/…`)
72
73	### 2. Explore (on spike branch only)
74
75	- Smallest code, script, or config to learn
76	- Stop when the question is answered or the time box expires
77	- Prefer prove the point over clean code
78
79	### 3. Stop and report
80
81	Produce a spike report (template in [Output format](#output-format)):
82
83	- Verdict: yes / no / inconclusive
84	- Evidence
85	- Recommendation: discard branch \| promote (which skill next) \| follow-up spike (narrower question)
86
87	### 4. Promotion (explicit only)
88
89	If building product:
90
91	\| Situation \| Next skill \|
92	\|-----------\|------------\|
93	\| Need agreed business examples + acceptance \| **`skills/atdd`

People who liked this also viewed

6 picks

Type

spike

27stars0forks

View on GitHub

How to install spike?

dan-the-dev/xp-developer-skills/spike

$npx -y skills add dan-the-dev/xp-developer-skills --skill spike

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Spike (time-boxed experiment)
2
3	## Mission
4
5	A spike is a small, time-boxed experiment to reduce uncertainty: prove a point, test an idea, a feature approach, or a library / API / integration — not to deliver production-ready software.
6
7	All spike code lives on an isolated branch (see [references/charter-and-timebox.md](references/charter-and-timebox.md)). Treat that branch as throwaway: merge to main only after explicit promotion into normal delivery workflows; default outcome is discard the branch and keep the spike report.
8
9	Optimize for:
10
11	- One clear question (hypothesis) and evidence (yes / no / inconclusive)
12	- Isolation — experiment does not pollute main or production paths
13	- Speed of learning — ignore polish, pyramid, and “proper” architecture unless they are the question
14	- Honest handoff — promotion to `skills/atdd`, `skills/tdd`, or `skills/legacy-testing` when building for real
15
16	NOT for:
17
18	- shipping user-facing behavior from the spike branch as-is
19	- full test pyramid, example catalogs, or test lists on the spike branch
20	- `skills/bugfix`, `skills/refactoring` (delivery hats), or legacy harness unless the spike question is specifically “can we test this seam?”
21
22	---
23
24	## What a spike is (XP)
25
26	From Extreme Programming: a very simple program (or script) that explores a tough technical or design problem, addresses only that problem, and is often thrown away. Goal: reduce risk or improve estimates — “What is the simplest thing we can try that convinces us we are on the right track?” (Kent Beck / Ward Cunningham).
27
28	Use spikes when you are knowledge-limited, not merely time-limited. See [references/definition-and-when.md](references/definition-and-when.md).
29
30	---
31
32	## Isolated branch (mandatory)
33
34	Before writing spike code:
35
36	1. Create a dedicated branch — e.g. `spike/<short-question-slug>` off the agreed base (`main` / `develop`).
37	2. Do all spike edits on that branch only — no mixed commits on feature or main branches.
38	3. Assume disposal — do not depend on spike structure in production; do not ask reviewers to treat spike code as product.
39
40	When the spike ends:
41
42	- Discard: delete branch or abandon without merge; keep spike report (charter artifact).
43	- Promote: open a new branch / slice and re-implement (or carefully port ideas, not bulk paste) under `skills/atdd` / `skills/tdd` / `skills/legacy-testing`.
44
45	---
46
47	## Tests on a spike (pragmatic only)
48
49	Spikes are not governed by the delivery test pyramid ([references/spike-vs-other-skills.md](references/spike-vs-other-skills.md)).
50
51	\| Use automated checks when… \| Skip when… \|
52	\|----------------------------\|------------\|
53	\| They directly prove the hypothesis (script assertion, one integration call, timing log) \| You would be building a “proper” unit/integration suite for maintainability \|
54	\| A failing check would invalidate the approach quickly \| ATDD example catalog or TDD test list is required \|
55	\| A one-off test is faster than manual clicking \| Refactoring for testability is unrelated to the question \|
56
57	No requirement for: layered pyramid, characterization of full modules, Gherkin, CI gates on the spike branch, or green-before-every-step TDD. Manual proof (logs, screenshots, measured latency) is valid when it answers the charter.
58
59	---
60
61	## Workflow
62
63	### 1. Charter (before code)
64
65	Record in chat or `docs/spikes/<slug>.md` (see [references/charter-and-timebox.md](references/charter-and-timebox.md)):
66
67	- Hypothesis / question (one sentence)
68	- Success signal / failure signal
69	- Time box
70	- Out of scope (including: “no production design”, “no full test suite”)
71	- Branch name (`spike/…`)
72
73	### 2. Explore (on spike branch only)
74
75	- Smallest code, script, or config to learn
76	- Stop when the question is answered or the time box expires
77	- Prefer prove the point over clean code
78
79	### 3. Stop and report
80
81	Produce a spike report (template in [Output format](#output-format)):
82
83	- Verdict: yes / no / inconclusive
84	- Evidence
85	- Recommendation: discard branch \| promote (which skill next) \| follow-up spike (narrower question)
86
87	### 4. Promotion (explicit only)
88
89	If building product:
90
91	\| Situation \| Next skill \|
92	\|-----------\|------------\|
93	\| Need agreed business examples + acceptance \| **`skills/atdd`

People who liked this also viewed

6 picks

Type