create-cadmo 0.0.1 → 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +17 -11
- package/index.js +44 -0
- package/package.json +34 -26
- package/templates/AGENTS.md +31 -0
- package/templates/decision.md +20 -0
- package/templates/plan.md +21 -0
- package/templates/spec.md +24 -0
- package/templates/value-gate.md +12 -0
package/README.md
CHANGED
|
@@ -1,11 +1,17 @@
|
|
|
1
|
-
# create-cadmo
|
|
2
|
-
|
|
3
|
-
Scaffold the **Cadmo** method into your project — a right-sized method for building software with AI as your pair.
|
|
4
|
-
|
|
5
|
-
```bash
|
|
6
|
-
npm create cadmo
|
|
7
|
-
```
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
1
|
+
# create-cadmo
|
|
2
|
+
|
|
3
|
+
Scaffold the **Cadmo** method into your project — a right-sized method for building software with AI as your pair.
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
npm create cadmo
|
|
7
|
+
```
|
|
8
|
+
|
|
9
|
+
Drops into the current directory, never overwriting anything:
|
|
10
|
+
|
|
11
|
+
- `AGENTS.md` — the local map your AI pair reads first (it will offer to fill it in for you)
|
|
12
|
+
- `cadmo/value-gate.md` — 5 lines before any spec: is it worth building?
|
|
13
|
+
- `cadmo/spec.md` — the rules, in the client's language, criteria first
|
|
14
|
+
- `cadmo/plan.md` — the internal route: tasks, constraints, how to validate
|
|
15
|
+
- `cadmo/decision.md` — architecture decisions with a "when to reconsider" trigger
|
|
16
|
+
|
|
17
|
+
The method, docs and protocols: **https://github.com/tiagotorres91/cadmo** · **https://cadmo.dev**
|
package/index.js
ADDED
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
/*
|
|
3
|
+
* create-cadmo — scaffold the Cadmo method into the current project.
|
|
4
|
+
* No dependencies. Never overwrites an existing file.
|
|
5
|
+
* https://github.com/tiagotorres91/cadmo
|
|
6
|
+
*/
|
|
7
|
+
const fs = require('fs');
|
|
8
|
+
const path = require('path');
|
|
9
|
+
|
|
10
|
+
const here = (...p) => path.join(__dirname, 'templates', ...p);
|
|
11
|
+
const cwd = process.cwd();
|
|
12
|
+
|
|
13
|
+
const FILES = [
|
|
14
|
+
// [source in package, destination in project]
|
|
15
|
+
['AGENTS.md', 'AGENTS.md'],
|
|
16
|
+
['value-gate.md', path.join('cadmo', 'value-gate.md')],
|
|
17
|
+
['spec.md', path.join('cadmo', 'spec.md')],
|
|
18
|
+
['plan.md', path.join('cadmo', 'plan.md')],
|
|
19
|
+
['decision.md', path.join('cadmo', 'decision.md')],
|
|
20
|
+
];
|
|
21
|
+
|
|
22
|
+
console.log('\n Cadmo — write it down before you build it.\n');
|
|
23
|
+
|
|
24
|
+
let placed = 0, skipped = 0;
|
|
25
|
+
for (const [src, dest] of FILES) {
|
|
26
|
+
const target = path.join(cwd, dest);
|
|
27
|
+
if (fs.existsSync(target)) {
|
|
28
|
+
console.log(` = kept ${dest} (already exists — not touched)`);
|
|
29
|
+
skipped++;
|
|
30
|
+
continue;
|
|
31
|
+
}
|
|
32
|
+
fs.mkdirSync(path.dirname(target), { recursive: true });
|
|
33
|
+
fs.copyFileSync(here(src), target);
|
|
34
|
+
console.log(` + created ${dest}`);
|
|
35
|
+
placed++;
|
|
36
|
+
}
|
|
37
|
+
|
|
38
|
+
console.log(`\n ${placed} file(s) created, ${skipped} kept.\n`);
|
|
39
|
+
console.log(' Next steps:');
|
|
40
|
+
console.log(' 1. Fill in AGENTS.md — the local map your AI pair reads first');
|
|
41
|
+
console.log(' (using CLAUDE.md? link or rename it — same idea).');
|
|
42
|
+
console.log(' 2. For your next relevant feature: cadmo/value-gate.md (5 lines, before any spec).');
|
|
43
|
+
console.log(' 3. For any 3+ step task: copy cadmo/plan.md — acceptance criteria before code.');
|
|
44
|
+
console.log('\n The method in one page: https://github.com/tiagotorres91/cadmo\n');
|
package/package.json
CHANGED
|
@@ -1,26 +1,34 @@
|
|
|
1
|
-
{
|
|
2
|
-
"name": "create-cadmo",
|
|
3
|
-
"version": "0.0
|
|
4
|
-
"description": "Scaffold the Cadmo method into your project
|
|
5
|
-
"keywords": [
|
|
6
|
-
"cadmo",
|
|
7
|
-
"create-cadmo",
|
|
8
|
-
"spec-driven-development",
|
|
9
|
-
"ai",
|
|
10
|
-
"methodology",
|
|
11
|
-
"framework",
|
|
12
|
-
"agents",
|
|
13
|
-
"claude",
|
|
14
|
-
"scaffold"
|
|
15
|
-
],
|
|
16
|
-
"homepage": "https://cadmo.dev",
|
|
17
|
-
"repository": {
|
|
18
|
-
"type": "git",
|
|
19
|
-
"url": "git+https://github.com/tiagotorres91/cadmo.git"
|
|
20
|
-
},
|
|
21
|
-
"author": "Tiago Torres
|
|
22
|
-
"license": "MIT",
|
|
23
|
-
"files": [
|
|
24
|
-
"
|
|
25
|
-
|
|
26
|
-
|
|
1
|
+
{
|
|
2
|
+
"name": "create-cadmo",
|
|
3
|
+
"version": "0.1.0",
|
|
4
|
+
"description": "Scaffold the Cadmo method into your project \u2014 a right-sized method for building software with AI as your pair.",
|
|
5
|
+
"keywords": [
|
|
6
|
+
"cadmo",
|
|
7
|
+
"create-cadmo",
|
|
8
|
+
"spec-driven-development",
|
|
9
|
+
"ai",
|
|
10
|
+
"methodology",
|
|
11
|
+
"framework",
|
|
12
|
+
"agents",
|
|
13
|
+
"claude",
|
|
14
|
+
"scaffold"
|
|
15
|
+
],
|
|
16
|
+
"homepage": "https://cadmo.dev",
|
|
17
|
+
"repository": {
|
|
18
|
+
"type": "git",
|
|
19
|
+
"url": "git+https://github.com/tiagotorres91/cadmo.git"
|
|
20
|
+
},
|
|
21
|
+
"author": "Tiago Torres",
|
|
22
|
+
"license": "MIT",
|
|
23
|
+
"files": [
|
|
24
|
+
"index.js",
|
|
25
|
+
"templates/",
|
|
26
|
+
"README.md"
|
|
27
|
+
],
|
|
28
|
+
"bin": {
|
|
29
|
+
"create-cadmo": "index.js"
|
|
30
|
+
},
|
|
31
|
+
"engines": {
|
|
32
|
+
"node": ">=16"
|
|
33
|
+
}
|
|
34
|
+
}
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# AGENTS.md — <project name>
|
|
2
|
+
|
|
3
|
+
> Drop this at the root of your project so any AI pair works the Cadmo way from the first message.
|
|
4
|
+
> This is the *local map*: what this project is, where things live, and how to verify. The method
|
|
5
|
+
> itself is in AGENTS.md at the Cadmo repo; this file is the project-specific instance.
|
|
6
|
+
>
|
|
7
|
+
> **AI pair reading this while it still has `<placeholders>`:** your first job is to fill it —
|
|
8
|
+
> scan the repository (structure, package files, scripts, CI) and propose the map to your human:
|
|
9
|
+
> what the project is, where specs/plans should live, and the actual verify commands. Then remove
|
|
10
|
+
> this paragraph.
|
|
11
|
+
|
|
12
|
+
## What this project is
|
|
13
|
+
<one paragraph: the product, the client/owner, the stack>
|
|
14
|
+
|
|
15
|
+
## Where things live
|
|
16
|
+
- Specs / decisions: <path>
|
|
17
|
+
- Plans: <path>
|
|
18
|
+
- Demands / task board: <where>
|
|
19
|
+
|
|
20
|
+
## How to verify (the harness — run before saying "done")
|
|
21
|
+
- Build/type-check: `<command>`
|
|
22
|
+
- Tests: `<command>`
|
|
23
|
+
- End-to-end / smoke: `<command>`
|
|
24
|
+
- Staging URL: <url> · Production: <url>
|
|
25
|
+
|
|
26
|
+
## Gates
|
|
27
|
+
- Plan approved before building; production ships only with explicit human approval.
|
|
28
|
+
- <any project-specific rule or gotcha>
|
|
29
|
+
|
|
30
|
+
## The method
|
|
31
|
+
Opening choreography, definition of done, the layers — see the Cadmo method (link).
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# ADR — <short title of the decision>
|
|
2
|
+
|
|
3
|
+
**Status:** accepted · **Date:** <YYYY-MM-DD> · **Deciders:** <who>
|
|
4
|
+
|
|
5
|
+
## Context
|
|
6
|
+
The forces at play: the problem, the constraints, what makes this decision necessary now (3–6 lines).
|
|
7
|
+
|
|
8
|
+
## Decision
|
|
9
|
+
What was decided, stated as a full sentence ("We will…").
|
|
10
|
+
|
|
11
|
+
## Alternatives considered
|
|
12
|
+
- **<Alternative A>** — why not: …
|
|
13
|
+
- **<Alternative B>** — why not: …
|
|
14
|
+
(Real alternatives you weighed — this section is what saves the re-investigation in six months.)
|
|
15
|
+
|
|
16
|
+
## Consequences
|
|
17
|
+
What becomes easier, what becomes harder, what debt is knowingly taken on.
|
|
18
|
+
|
|
19
|
+
## When to reconsider
|
|
20
|
+
The trigger that should reopen this decision (a scale threshold, a price change, a vendor event) — a decision without a reconsider-trigger quietly becomes dogma.
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# <Demand name> — plan (internal)
|
|
2
|
+
|
|
3
|
+
Pairs with `spec.md` (acceptance criteria live there — don't repeat them).
|
|
4
|
+
|
|
5
|
+
## Objective
|
|
6
|
+
What changes in the world when this is done (1–3 lines).
|
|
7
|
+
|
|
8
|
+
## Investigation (optional)
|
|
9
|
+
What was tried/considered before and why it was discarded (3–6 lines) — avoids re-investigating dead ends.
|
|
10
|
+
|
|
11
|
+
## Context & constraints
|
|
12
|
+
Current state, decisions already made, what NOT to change.
|
|
13
|
+
|
|
14
|
+
## Technical plan
|
|
15
|
+
Files/tables/endpoints touched; approach; alternatives discarded.
|
|
16
|
+
|
|
17
|
+
## Tasks
|
|
18
|
+
- [ ] Small, verifiable (status kept here — any session resumes without getting lost)
|
|
19
|
+
|
|
20
|
+
## How to validate
|
|
21
|
+
Commands/flows that prove the acceptance criteria (build, tests, e2e, real manual flow).
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# Spec — <name>
|
|
2
|
+
|
|
3
|
+
**Status:** draft — awaiting validation (<who>) · **Demand:** <link/id>
|
|
4
|
+
|
|
5
|
+
## Goal & context
|
|
6
|
+
The business problem and what changes in the world (2–5 lines, in the client's language).
|
|
7
|
+
(Relevant work already passed the value gate — its success metric becomes an acceptance criterion here.)
|
|
8
|
+
|
|
9
|
+
## Acceptance criteria
|
|
10
|
+
- [ ] Simple ones in free form
|
|
11
|
+
- [ ] Critical ones (money / data / integration / security) in EARS:
|
|
12
|
+
WHEN <trigger>, THE SYSTEM SHALL <behavior>
|
|
13
|
+
|
|
14
|
+
## Data (AI features only)
|
|
15
|
+
Source, owner, access, quality/bias, corpus refresh plan.
|
|
16
|
+
|
|
17
|
+
## Risks (critical or AI demands only)
|
|
18
|
+
Risk → response. For AI: corpus drift, provider API change, cost, regulation.
|
|
19
|
+
|
|
20
|
+
## Out of scope
|
|
21
|
+
What this delivery does NOT cover (controlled expectations).
|
|
22
|
+
|
|
23
|
+
## Impact on stable specs
|
|
24
|
+
Which sections of the system/domain specs will be updated on delivery (the absorption).
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# Value gate — <demand name>
|
|
2
|
+
|
|
3
|
+
Fill this in *before* writing a spec, for anything relevant (a new feature, module, project).
|
|
4
|
+
Trivial work and routine fixes skip this.
|
|
5
|
+
|
|
6
|
+
**Problem (measurable):** what hurts today, in numbers when possible.
|
|
7
|
+
**Why this solution:** AI vs a rule vs a process vs doing nothing — why this path.
|
|
8
|
+
**Success metric (business):** the number that will prove value — not "it works", but "reduced X", "freed Y hours", "raised Z".
|
|
9
|
+
**Data readiness:** 🟢 data exists, accessible, reliable · 🟡 exists with caveats (which?) · 🔴 doesn't exist → resolve *before* specifying.
|
|
10
|
+
**Verdict:** GO / NO-GO / defer (why).
|
|
11
|
+
|
|
12
|
+
<!-- At close, come back and record: did the metric materialize? -->
|