decision

Name: decision
Author: AlpacaLabsLLC

260stars54forks

How to install decision?

alpacalabsllc/skills-for-architects/decision

$npx -y skills add AlpacaLabsLLC/skills-for-architects --skill decision

Installs into the current project.

Summary

Capture a project decision as an ADR-style record in decisions/NNNN-slug.md — context, options considered, the call, consequences, status. Use when the user makes or reports a design, code, zoning, or procurement choice ("we're going with...", "the client decided..."), when an an

Files · 1

View on GitHub

SKILL.md

1	# /decision — Project Decision Records
2
3	You capture decisions the way software teams capture ADRs (Architecture Decision Records) — except these are for actual architecture. One file per decision, numbered, in `decisions/` at the project root. The record survives the email thread, the meeting, and the personnel change that would otherwise lose it.
4
5	## Usage
6
7	```
8	/decision → interview for a decision in the air, then record it
9	/decision we're going with X → record it, asking only for what's missing
10	/decision supersede 0003 → mark 0003 superseded, record its replacement
11	/decision list → show the index with statuses
12	```
13
14	## Hard rules
15
16	1. One decision per record. "Schemes B and code edition 2022" is two records.
17	2. Never renumber, never delete. Numbers are permanent references. Wrong decisions get `superseded`, not removed — the reasoning trail is the point.
18	3. Capture options honestly. A record with one option isn't a decision, it's an announcement. Ask what else was considered, even briefly.
19	4. Keep the dossier index in sync. Every create/supersede updates the Decisions table in `PROJECT.md` (create the dossier via `/project-dossier init` first if it doesn't exist).
20	5. Brevity. Context in 2–4 sentences, options as one line each, consequences as bullets. A record nobody reads records nothing.
21
22	## Recording flow
23
24	1. Find the next number: `Glob decisions/*.md`, take max + 1, zero-padded to 4 digits.
25	2. Gather the pieces — from the conversation first, ask only for gaps (one grouped question): what was decided, what options were on the table, why, who made the call.
26	3. Write `decisions/NNNN-{kebab-slug}.md` from the template.
27	4. Update the Decisions index in `PROJECT.md`.
28	5. Confirm with the path and a one-line restatement of the decision.
29
30	## Template
31
32	```markdown
33	# NNNN — {Decision title, stated as the choice made}
34
35	- Status: decided
36	- Date: {YYYY-MM-DD}
37	- Deciders: {who made the call}
38
39	## Context
40
41	{2–4 sentences: the situation that forced a choice. Link the analysis that surfaced it if one exists.}
42
43	## Options considered
44
45	1. {Option A} — {one line: what it would mean}
46	2. {Option B} — {one line}
47
48	## Decision
49
50	{The choice, and the load-bearing reason in 1–3 sentences.}
51
52	## Consequences
53
54	- {What this enables, costs, or constrains downstream}
55	- {What must now happen as a result}
56	```
57
58	Statuses: `proposed` (on the table, not yet made — record it so the options aren't lost), `decided`, `superseded by NNNN`.
59
60	## On `supersede`
61
62	1. Read the old record. Set its status to `superseded by NNNN` (naming the new record) — touch nothing else in it.
63	2. Record the new decision normally; its Context section names what it replaces and why the reversal.
64	3. Update both rows in the dossier index.
65
66	## When analysis skills propose a decision
67
68	Skills in this marketplace surface choice points (zoning paths, code editions, GWP thresholds) and suggest running `/decision`. When that happens, the analysis is your Context — quote its numbers with their source rather than re-deriving them.
69
70	## Collaboration
71
72	Records are plain files in the project folder — share them the way the project is already shared (git, Drive, Dropbox). Review happens in version control or in conversation; this skill imposes no workflow beyond the files.

People who liked this also viewed

6 picks

Type

decision

260stars54forks

View on GitHub

How to install decision?

alpacalabsllc/skills-for-architects/decision

$npx -y skills add AlpacaLabsLLC/skills-for-architects --skill decision

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# /decision — Project Decision Records
2
3	You capture decisions the way software teams capture ADRs (Architecture Decision Records) — except these are for actual architecture. One file per decision, numbered, in `decisions/` at the project root. The record survives the email thread, the meeting, and the personnel change that would otherwise lose it.
4
5	## Usage
6
7	```
8	/decision → interview for a decision in the air, then record it
9	/decision we're going with X → record it, asking only for what's missing
10	/decision supersede 0003 → mark 0003 superseded, record its replacement
11	/decision list → show the index with statuses
12	```
13
14	## Hard rules
15
16	1. One decision per record. "Schemes B and code edition 2022" is two records.
17	2. Never renumber, never delete. Numbers are permanent references. Wrong decisions get `superseded`, not removed — the reasoning trail is the point.
18	3. Capture options honestly. A record with one option isn't a decision, it's an announcement. Ask what else was considered, even briefly.
19	4. Keep the dossier index in sync. Every create/supersede updates the Decisions table in `PROJECT.md` (create the dossier via `/project-dossier init` first if it doesn't exist).
20	5. Brevity. Context in 2–4 sentences, options as one line each, consequences as bullets. A record nobody reads records nothing.
21
22	## Recording flow
23
24	1. Find the next number: `Glob decisions/*.md`, take max + 1, zero-padded to 4 digits.
25	2. Gather the pieces — from the conversation first, ask only for gaps (one grouped question): what was decided, what options were on the table, why, who made the call.
26	3. Write `decisions/NNNN-{kebab-slug}.md` from the template.
27	4. Update the Decisions index in `PROJECT.md`.
28	5. Confirm with the path and a one-line restatement of the decision.
29
30	## Template
31
32	```markdown
33	# NNNN — {Decision title, stated as the choice made}
34
35	- Status: decided
36	- Date: {YYYY-MM-DD}
37	- Deciders: {who made the call}
38
39	## Context
40
41	{2–4 sentences: the situation that forced a choice. Link the analysis that surfaced it if one exists.}
42
43	## Options considered
44
45	1. {Option A} — {one line: what it would mean}
46	2. {Option B} — {one line}
47
48	## Decision
49
50	{The choice, and the load-bearing reason in 1–3 sentences.}
51
52	## Consequences
53
54	- {What this enables, costs, or constrains downstream}
55	- {What must now happen as a result}
56	```
57
58	Statuses: `proposed` (on the table, not yet made — record it so the options aren't lost), `decided`, `superseded by NNNN`.
59
60	## On `supersede`
61
62	1. Read the old record. Set its status to `superseded by NNNN` (naming the new record) — touch nothing else in it.
63	2. Record the new decision normally; its Context section names what it replaces and why the reversal.
64	3. Update both rows in the dossier index.
65
66	## When analysis skills propose a decision
67
68	Skills in this marketplace surface choice points (zoning paths, code editions, GWP thresholds) and suggest running `/decision`. When that happens, the analysis is your Context — quote its numbers with their source rather than re-deriving them.
69
70	## Collaboration
71
72	Records are plain files in the project folder — share them the way the project is already shared (git, Drive, Dropbox). Review happens in version control or in conversation; this skill imposes no workflow beyond the files.

People who liked this also viewed

6 picks

Type