@wipcomputer/wip-repo-init 1.9.25 → 1.9.27
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/init.mjs +1 -1
- package/package.json +1 -1
- package/templates/_sort/README.md +15 -0
- package/templates/dev-updates/README.md +50 -0
- package/templates/product/notes/README.md +26 -0
- package/templates/product/plans-prds/roadmap.md +77 -0
- package/templates/product/plans-prds/todos/README 2.md +63 -0
- package/templates/product/plans-prds/todos/README.md +63 -0
- package/templates/product/product-ideas/README.md +24 -0
- package/templates/product/readme-first-product.md +128 -0
- package/templates/read-me-first.md +80 -0
package/init.mjs
CHANGED
|
@@ -15,7 +15,7 @@ import { fileURLToPath } from 'node:url';
|
|
|
15
15
|
import { createInterface } from 'node:readline';
|
|
16
16
|
|
|
17
17
|
const __dirname = dirname(fileURLToPath(import.meta.url));
|
|
18
|
-
const TEMPLATE = join(__dirname, '
|
|
18
|
+
const TEMPLATE = join(__dirname, 'templates');
|
|
19
19
|
|
|
20
20
|
const targetRepo = resolve(process.argv[2] || process.cwd());
|
|
21
21
|
const aiDir = join(targetRepo, 'ai');
|
package/package.json
CHANGED
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# _sort/
|
|
2
|
+
|
|
3
|
+
The holding pen. Files that need to be looked at and filed somewhere.
|
|
4
|
+
|
|
5
|
+
## What Goes Here
|
|
6
|
+
|
|
7
|
+
- iCloud duplicates or randomly placed files that need sorting
|
|
8
|
+
- Files you're not sure where to put yet
|
|
9
|
+
- Anything that needs a human to look at it and decide where it belongs
|
|
10
|
+
|
|
11
|
+
## Rules
|
|
12
|
+
|
|
13
|
+
- **Not trash.** `_sort/` is for files you want to review. `_trash/` is for files you're done with.
|
|
14
|
+
- **Don't let it pile up.** Check this folder periodically. File things or trash them.
|
|
15
|
+
- **Agents:** If you don't know where a file goes, put it in `_sort/`. A human will sort it later.
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
# dev-updates/
|
|
2
|
+
|
|
3
|
+
One file per significant change. Written as you work, auto-detected by `wip-release`.
|
|
4
|
+
|
|
5
|
+
## What This Folder Is
|
|
6
|
+
|
|
7
|
+
Dev updates are the engineering changelog. Every time you do significant work (ship a feature, fix a bug, change architecture), write a dev update. `wip-release` picks up today's dev updates and uses them as release notes.
|
|
8
|
+
|
|
9
|
+
This is not a place for plans or ideas. It's a record of what was built and why.
|
|
10
|
+
|
|
11
|
+
## Naming Convention
|
|
12
|
+
|
|
13
|
+
```
|
|
14
|
+
YYYY-MM-DD--HH-MM--agent--description.md
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
Examples:
|
|
18
|
+
- `2026-03-11--09-30--cc-mini--fix-hook-duplicates.md`
|
|
19
|
+
- `2026-03-10--14-00--lesa-mini--add-voice-call-support.md`
|
|
20
|
+
|
|
21
|
+
## File Format
|
|
22
|
+
|
|
23
|
+
```markdown
|
|
24
|
+
# Short title of what changed
|
|
25
|
+
|
|
26
|
+
**Date:** YYYY-MM-DD HH:MM TZ
|
|
27
|
+
**Author:** Agent Name (agent-id)
|
|
28
|
+
|
|
29
|
+
## Problem
|
|
30
|
+
|
|
31
|
+
What was broken or missing.
|
|
32
|
+
|
|
33
|
+
## Fix / What Changed
|
|
34
|
+
|
|
35
|
+
What you did and why.
|
|
36
|
+
|
|
37
|
+
## Files changed
|
|
38
|
+
|
|
39
|
+
- `path/to/file.js` ... what changed in it
|
|
40
|
+
|
|
41
|
+
Closes #issue-number (if applicable)
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
## Rules
|
|
45
|
+
|
|
46
|
+
- **Write them as you work.** Don't batch them at the end. Each significant change gets its own file.
|
|
47
|
+
- **One file per change.** Not one file per day. If you fix two unrelated bugs, write two files.
|
|
48
|
+
- **Include the "why."** "Fixed X" is a commit message. A dev update explains why it was broken and why the fix works.
|
|
49
|
+
- **Reference issues.** If there's a GitHub issue, add `Closes #N` at the bottom.
|
|
50
|
+
- **Consumed files go to `_trash/`.** `wip-release` doesn't move them automatically, but the release notes files it generates do get trashed after release.
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
# notes/
|
|
2
|
+
|
|
3
|
+
Freeform notes, research, and observations. Anything that's useful context but isn't a plan, idea, or dev update.
|
|
4
|
+
|
|
5
|
+
## What Goes Here
|
|
6
|
+
|
|
7
|
+
- Research notes ("I looked into X and found...")
|
|
8
|
+
- Meeting notes or conversation summaries
|
|
9
|
+
- Technical investigations
|
|
10
|
+
- Context that multiple plans reference
|
|
11
|
+
- Anything that doesn't fit in `plans-prds/` or `product-ideas/`
|
|
12
|
+
|
|
13
|
+
## Naming
|
|
14
|
+
|
|
15
|
+
No strict convention. Use descriptive names:
|
|
16
|
+
|
|
17
|
+
```
|
|
18
|
+
YYYY-MM-DD--agent--topic.md
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
Example: `2026-03-10--cc-mini--readme-standard-and-universal-installer-vision.md`
|
|
22
|
+
|
|
23
|
+
## Rules
|
|
24
|
+
|
|
25
|
+
- **Not a plan?** Put it here, not in `plans-prds/`.
|
|
26
|
+
- **Done with it?** Move to `_trash/`. Don't delete.
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
# [Product Name] ... Roadmap
|
|
2
|
+
|
|
3
|
+
**Last updated:** YYYY-MM-DD
|
|
4
|
+
**Current version:** vX.Y.Z
|
|
5
|
+
|
|
6
|
+
Items are either **Upcoming**, **Done**, or **Deprecated**. Never delete. Always move.
|
|
7
|
+
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
## What This File Is
|
|
11
|
+
|
|
12
|
+
The prioritized roadmap for this product. Three sections:
|
|
13
|
+
|
|
14
|
+
- **Upcoming** ... work that's planned, ordered by priority. Top = most important.
|
|
15
|
+
- **Done** ... shipped work. Moved here with a date when it's released.
|
|
16
|
+
- **Deprecated** ... planned work that's no longer needed. Strikethrough, add the reason and date. Not the same as Done. Done means it shipped. Deprecated means the plan changed.
|
|
17
|
+
|
|
18
|
+
**Keep it honest.** If something isn't going to happen, deprecate it. Don't leave dead items in Upcoming.
|
|
19
|
+
|
|
20
|
+
**Keep it prioritized.** Upcoming items have priority numbers. When priorities shift, renumber them. The order is the strategy.
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## Vision
|
|
25
|
+
|
|
26
|
+
_One paragraph. Where is this product going? Not the feature list. The north star._
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## Upcoming
|
|
31
|
+
|
|
32
|
+
### Priority 1 ... [Feature/Epic Name]
|
|
33
|
+
|
|
34
|
+
_What it is and why it matters in 1-2 sentences._
|
|
35
|
+
|
|
36
|
+
- [ ] Task one
|
|
37
|
+
- [ ] Task two
|
|
38
|
+
- [ ] Task three
|
|
39
|
+
|
|
40
|
+
### Priority 2 ... [Feature/Epic Name]
|
|
41
|
+
|
|
42
|
+
_What it is and why it matters._
|
|
43
|
+
|
|
44
|
+
- [ ] Task one
|
|
45
|
+
- [ ] Task two
|
|
46
|
+
|
|
47
|
+
_Add more priorities as needed. Number them. The number is the priority._
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
51
|
+
## Done
|
|
52
|
+
|
|
53
|
+
### [Feature Name] (YYYY-MM-DD)
|
|
54
|
+
|
|
55
|
+
- [x] What shipped
|
|
56
|
+
- [x] What shipped
|
|
57
|
+
|
|
58
|
+
_Move items here when they're released. Include the date. Keep the checkbox format so it's clear what was planned vs what actually shipped._
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
## Deprecated
|
|
63
|
+
|
|
64
|
+
- ~~[Feature that was planned]~~ ... reason it was dropped. (YYYY-MM-DD)
|
|
65
|
+
|
|
66
|
+
_Deprecated is not a graveyard. It's a record of decisions. When someone asks "why didn't we build X?" the answer is here._
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
## How to Update This File
|
|
71
|
+
|
|
72
|
+
- **Shipped a feature?** Move it from Upcoming to Done. Add the date. Check the boxes.
|
|
73
|
+
- **Dropped a plan?** Move it to Deprecated. Strikethrough, add the reason and date.
|
|
74
|
+
- **New idea that's ready to plan?** Add to Upcoming with a priority number. Renumber if needed.
|
|
75
|
+
- **Idea that's NOT ready to plan?** Put it in `../product-ideas/` instead. The roadmap is for committed work.
|
|
76
|
+
- **Priorities shifted?** Renumber the Upcoming section. The order matters.
|
|
77
|
+
- **Always update** "Last updated" and "Current version" at the top.
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
# todos/
|
|
2
|
+
|
|
3
|
+
One todo file per person or agent. Three sections per file: To Do, Done, Deprecated.
|
|
4
|
+
|
|
5
|
+
## What This Folder Is
|
|
6
|
+
|
|
7
|
+
Todos that are specific to this repo. Each person or agent who works on this repo gets one file. The file tracks what they need to do, what they've done, and what got dropped.
|
|
8
|
+
|
|
9
|
+
For cross-repo work or bigger items, use GitHub Issues. Todos here are for repo-scoped tasks that don't need the overhead of an issue.
|
|
10
|
+
|
|
11
|
+
## Files
|
|
12
|
+
|
|
13
|
+
One file per person/agent. Name it `[Name]-todo.md`.
|
|
14
|
+
|
|
15
|
+
Example:
|
|
16
|
+
|
|
17
|
+
| File | Who |
|
|
18
|
+
|------|-----|
|
|
19
|
+
| `Parker-todo.md` | Parker (human tasks: reviews, credentials, approvals) |
|
|
20
|
+
| `CC-Mini-todo.md` | Claude Code on Mac Mini (code, builds, deploys) |
|
|
21
|
+
|
|
22
|
+
Create the file when that person/agent first has work to do. No empty placeholder files.
|
|
23
|
+
|
|
24
|
+
## File Format
|
|
25
|
+
|
|
26
|
+
```markdown
|
|
27
|
+
# [Name] Todos
|
|
28
|
+
|
|
29
|
+
**Last updated:** YYYY-MM-DD
|
|
30
|
+
|
|
31
|
+
## To Do
|
|
32
|
+
|
|
33
|
+
- [ ] Task description
|
|
34
|
+
- [ ] Task description (blocked by: reason)
|
|
35
|
+
|
|
36
|
+
## Done
|
|
37
|
+
|
|
38
|
+
- [x] Task description (YYYY-MM-DD)
|
|
39
|
+
- [x] Task description (YYYY-MM-DD)
|
|
40
|
+
|
|
41
|
+
## Deprecated
|
|
42
|
+
|
|
43
|
+
- ~~Task description~~ ... reason. (YYYY-MM-DD)
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
## Rules
|
|
47
|
+
|
|
48
|
+
- **Never delete anything.** Items move between sections, never off the page.
|
|
49
|
+
- **To Do** ... work that needs to happen.
|
|
50
|
+
- **Done** ... completed work. Check the box, add the date.
|
|
51
|
+
- **Deprecated** ... planned but no longer needed. Strikethrough, add the reason and date. Not the same as Done. Done means it shipped. Deprecated means the requirement changed.
|
|
52
|
+
- **Update the date** at the top of the file every time you edit it.
|
|
53
|
+
- **One file per person/agent.** No dated files, no subfolders, no inboxes.
|
|
54
|
+
- **Blocked items** stay in To Do with a `(blocked by: reason)` note. Don't move them to a separate section.
|
|
55
|
+
|
|
56
|
+
## When to Use Todos vs GitHub Issues
|
|
57
|
+
|
|
58
|
+
| Use | When |
|
|
59
|
+
|-----|------|
|
|
60
|
+
| **Todo file** | Quick tasks, repo-scoped work, things you'll do this session or this week |
|
|
61
|
+
| **GitHub Issue** | Bugs, feature requests, cross-repo work, things that need tracking or discussion |
|
|
62
|
+
|
|
63
|
+
Both is fine. File an issue AND add a todo that references it. The todo is your personal checklist. The issue is the team's record.
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
# todos/
|
|
2
|
+
|
|
3
|
+
One todo file per person or agent. Three sections per file: To Do, Done, Deprecated.
|
|
4
|
+
|
|
5
|
+
## What This Folder Is
|
|
6
|
+
|
|
7
|
+
Todos that are specific to this repo. Each person or agent who works on this repo gets one file. The file tracks what they need to do, what they've done, and what got dropped.
|
|
8
|
+
|
|
9
|
+
For cross-repo work or bigger items, use GitHub Issues. Todos here are for repo-scoped tasks that don't need the overhead of an issue.
|
|
10
|
+
|
|
11
|
+
## Files
|
|
12
|
+
|
|
13
|
+
One file per person/agent. Name it `[Name]-todo.md`.
|
|
14
|
+
|
|
15
|
+
Example:
|
|
16
|
+
|
|
17
|
+
| File | Who |
|
|
18
|
+
|------|-----|
|
|
19
|
+
| `Parker-todo.md` | Parker (human tasks: reviews, credentials, approvals) |
|
|
20
|
+
| `CC-Mini-todo.md` | Claude Code on Mac Mini (code, builds, deploys) |
|
|
21
|
+
|
|
22
|
+
Create the file when that person/agent first has work to do. No empty placeholder files.
|
|
23
|
+
|
|
24
|
+
## File Format
|
|
25
|
+
|
|
26
|
+
```markdown
|
|
27
|
+
# [Name] Todos
|
|
28
|
+
|
|
29
|
+
**Last updated:** YYYY-MM-DD
|
|
30
|
+
|
|
31
|
+
## To Do
|
|
32
|
+
|
|
33
|
+
- [ ] Task description
|
|
34
|
+
- [ ] Task description (blocked by: reason)
|
|
35
|
+
|
|
36
|
+
## Done
|
|
37
|
+
|
|
38
|
+
- [x] Task description (YYYY-MM-DD)
|
|
39
|
+
- [x] Task description (YYYY-MM-DD)
|
|
40
|
+
|
|
41
|
+
## Deprecated
|
|
42
|
+
|
|
43
|
+
- ~~Task description~~ ... reason. (YYYY-MM-DD)
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
## Rules
|
|
47
|
+
|
|
48
|
+
- **Never delete anything.** Items move between sections, never off the page.
|
|
49
|
+
- **To Do** ... work that needs to happen.
|
|
50
|
+
- **Done** ... completed work. Check the box, add the date.
|
|
51
|
+
- **Deprecated** ... planned but no longer needed. Strikethrough, add the reason and date. Not the same as Done. Done means it shipped. Deprecated means the requirement changed.
|
|
52
|
+
- **Update the date** at the top of the file every time you edit it.
|
|
53
|
+
- **One file per person/agent.** No dated files, no subfolders, no inboxes.
|
|
54
|
+
- **Blocked items** stay in To Do with a `(blocked by: reason)` note. Don't move them to a separate section.
|
|
55
|
+
|
|
56
|
+
## When to Use Todos vs GitHub Issues
|
|
57
|
+
|
|
58
|
+
| Use | When |
|
|
59
|
+
|-----|------|
|
|
60
|
+
| **Todo file** | Quick tasks, repo-scoped work, things you'll do this session or this week |
|
|
61
|
+
| **GitHub Issue** | Bugs, feature requests, cross-repo work, things that need tracking or discussion |
|
|
62
|
+
|
|
63
|
+
Both is fine. File an issue AND add a todo that references it. The todo is your personal checklist. The issue is the team's record.
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# product-ideas/
|
|
2
|
+
|
|
3
|
+
Ideas that aren't plans yet. The incubator.
|
|
4
|
+
|
|
5
|
+
## What Goes Here
|
|
6
|
+
|
|
7
|
+
An idea is something you want to build but haven't committed to. It doesn't have tasks, timelines, or priorities. It's a "what if" or "we should."
|
|
8
|
+
|
|
9
|
+
When an idea is ready to become a plan, move it to `../plans-prds/upcoming/` and flesh it out with tasks and priorities.
|
|
10
|
+
|
|
11
|
+
## Format
|
|
12
|
+
|
|
13
|
+
No strict format. But a good idea file usually has:
|
|
14
|
+
|
|
15
|
+
- **What it is** (one paragraph)
|
|
16
|
+
- **Why it matters** (what problem it solves)
|
|
17
|
+
- **Open questions** (what you'd need to figure out)
|
|
18
|
+
- **External references** (links, reviews, research)
|
|
19
|
+
|
|
20
|
+
## Rules
|
|
21
|
+
|
|
22
|
+
- **Not ready to plan?** It stays here.
|
|
23
|
+
- **Ready to plan?** Move to `../plans-prds/upcoming/`.
|
|
24
|
+
- **Killed?** Move to `_trash/` with a note about why.
|
|
@@ -0,0 +1,128 @@
|
|
|
1
|
+
# [Product Name] ... Read Me First
|
|
2
|
+
|
|
3
|
+
**Last updated:** YYYY-MM-DD
|
|
4
|
+
**Status:** Living document. Read this before any plan, build, or PR.
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## What This File Is
|
|
9
|
+
|
|
10
|
+
This is the product bible for this repo. It answers: what is this thing, why does it exist, how does it work, and what's the current state. Every person and agent working on this repo reads this first.
|
|
11
|
+
|
|
12
|
+
**Keep it current.** Update it when the architecture changes, when major features ship, when the mental model shifts. If this file is stale, the team is working from bad context.
|
|
13
|
+
|
|
14
|
+
**Keep it honest.** Don't describe the aspirational version. Describe what's built and what's missing. Plans go in `plans-prds/`. This file is ground truth.
|
|
15
|
+
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
## This Folder
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
product/
|
|
22
|
+
readme-first-product.md <- you're here (the product bible)
|
|
23
|
+
_trash/
|
|
24
|
+
notes/ <- freeform notes, research, observations
|
|
25
|
+
plans-prds/ <- plans with lifecycle stages
|
|
26
|
+
roadmap.md <- the prioritized roadmap
|
|
27
|
+
current/ <- plans being built right now
|
|
28
|
+
upcoming/ <- plans that are next
|
|
29
|
+
archive-complete/ <- plans that shipped
|
|
30
|
+
todos/ <- per-agent task lists
|
|
31
|
+
_sort/ <- plans that need categorizing
|
|
32
|
+
_trash/
|
|
33
|
+
product-ideas/ <- ideas that aren't plans yet
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
**Navigate:**
|
|
37
|
+
- **Want to know what's planned?** Read `plans-prds/roadmap.md`.
|
|
38
|
+
- **Want to know what's being built right now?** Look in `plans-prds/current/`.
|
|
39
|
+
- **Have an idea?** Write it up in `product-ideas/`.
|
|
40
|
+
- **Ready to turn an idea into a plan?** Move it from `product-ideas/` to `plans-prds/upcoming/` (or `current/` if starting now).
|
|
41
|
+
|
|
42
|
+
**Plan lifecycle:**
|
|
43
|
+
```
|
|
44
|
+
product-ideas/ -> upcoming/ -> current/ -> archive-complete/
|
|
45
|
+
(idea) (planned) (building) (shipped)
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## What [Product Name] Is
|
|
51
|
+
|
|
52
|
+
_One paragraph. What it does in human words. Not what it is technically. What problem it solves and for whom._
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## Core Concepts
|
|
57
|
+
|
|
58
|
+
_The 3-5 mental models someone needs to understand this product. Not implementation details. The "aha" moments that make everything else make sense._
|
|
59
|
+
|
|
60
|
+
_Example: "Raw files are ground truth. Databases are indexes. If anything breaks, rebuild from raw files."_
|
|
61
|
+
|
|
62
|
+
_Example: "One agent per harness per machine. That's the identity unit."_
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
## How It Works
|
|
67
|
+
|
|
68
|
+
_The architecture at a level a new contributor can follow. Diagrams are fine. ASCII art is fine. The goal is: someone reads this section and can navigate the codebase without asking questions._
|
|
69
|
+
|
|
70
|
+
_Include:_
|
|
71
|
+
- _High-level data flow_
|
|
72
|
+
- _Key components and what they do_
|
|
73
|
+
- _Where state lives (databases, config files, etc.)_
|
|
74
|
+
- _What talks to what_
|
|
75
|
+
|
|
76
|
+
---
|
|
77
|
+
|
|
78
|
+
## Key Source Files
|
|
79
|
+
|
|
80
|
+
_Table of the important files and what they do. Not every file. The ones a new contributor needs to find their way._
|
|
81
|
+
|
|
82
|
+
| File | What It Does |
|
|
83
|
+
|------|-------------|
|
|
84
|
+
| `src/core.ts` | _description_ |
|
|
85
|
+
| `src/cli.ts` | _description_ |
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## What's Built (as of vX.Y.Z)
|
|
90
|
+
|
|
91
|
+
_Bullet list of what actually works right now. Update the version and date when this section changes._
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
## What's Missing
|
|
96
|
+
|
|
97
|
+
_Bullet list of known gaps, limitations, and unfinished work. This is not the roadmap (that's in `plans-prds/roadmap.md`). This is the honest answer to "what doesn't work yet?"_
|
|
98
|
+
|
|
99
|
+
---
|
|
100
|
+
|
|
101
|
+
## Key Documents
|
|
102
|
+
|
|
103
|
+
_Links to the important plans, PRDs, and references. Relative paths within `ai/product/`._
|
|
104
|
+
|
|
105
|
+
| Document | Location |
|
|
106
|
+
|----------|----------|
|
|
107
|
+
| **This file** | `readme-first-product.md` |
|
|
108
|
+
| **Roadmap** | `plans-prds/roadmap.md` |
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
## Principles
|
|
113
|
+
|
|
114
|
+
_The non-negotiable rules for this product. The things that override convenience. 5-10 max._
|
|
115
|
+
|
|
116
|
+
1. _Principle one._
|
|
117
|
+
2. _Principle two._
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
## How to Update This File
|
|
122
|
+
|
|
123
|
+
- **New major feature shipped?** Update "What's Built" and "What's Missing."
|
|
124
|
+
- **Architecture changed?** Update "How It Works" and "Key Source Files."
|
|
125
|
+
- **New mental model?** Update "Core Concepts."
|
|
126
|
+
- **New principle?** Add to "Principles."
|
|
127
|
+
- **Always update** the "Last updated" date at the top.
|
|
128
|
+
- **Never delete sections.** If a section is empty, leave the heading. It reminds the team to fill it in.
|
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
# ai/ ... Read Me First
|
|
2
|
+
|
|
3
|
+
This is the working folder for the team. Plans, notes, ideas, dev updates, todos. Everything that isn't code lives here.
|
|
4
|
+
|
|
5
|
+
This folder only exists in `-private` repos. It never ships to public.
|
|
6
|
+
|
|
7
|
+
## Structure
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
ai/
|
|
11
|
+
read-me-first.md <- you're here
|
|
12
|
+
_sort/ <- stuff that hasn't been filed yet
|
|
13
|
+
_trash/ <- stuff that's done or replaced (never delete, move here)
|
|
14
|
+
dev-updates/ <- one file per significant change, auto-detected by wip-release
|
|
15
|
+
_trash/
|
|
16
|
+
product/
|
|
17
|
+
readme-first-product.md <- the product bible (read this before anything else)
|
|
18
|
+
_trash/
|
|
19
|
+
notes/ <- freeform notes, research, observations
|
|
20
|
+
_trash/
|
|
21
|
+
plans-prds/ <- plans and PRDs with lifecycle stages
|
|
22
|
+
roadmap.md <- prioritized roadmap (Upcoming / Done / Deprecated)
|
|
23
|
+
_sort/ <- plans that haven't been categorized yet
|
|
24
|
+
_trash/
|
|
25
|
+
upcoming/ <- planned work (next up after current)
|
|
26
|
+
current/ <- active plans being implemented right now
|
|
27
|
+
archive-complete/ <- finished plans (moved here when done)
|
|
28
|
+
todos/ <- per-agent todo files
|
|
29
|
+
product-ideas/ <- ideas that aren't plans yet
|
|
30
|
+
_trash/
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
## What's In Each Section
|
|
34
|
+
|
|
35
|
+
| Location | What It Is | Read More |
|
|
36
|
+
|----------|-----------|-----------|
|
|
37
|
+
| [_sort/](_sort/README.md) | Holding pen. Files that need to be looked at and filed somewhere. iCloud duplicates, randomly placed files, things you're not sure about. | [_sort/README.md](_sort/README.md) |
|
|
38
|
+
| [_trash/](_trash/README.md) | The archive. Files that are done, replaced, or consumed. Never delete anything, move it here. | [_trash/README.md](_trash/README.md) |
|
|
39
|
+
| [dev-updates/](dev-updates/README.md) | Engineering changelog. One file per significant change. Auto-detected by `wip-release` for release notes. | [dev-updates/README.md](dev-updates/README.md) |
|
|
40
|
+
| [product/readme-first-product.md](product/readme-first-product.md) | The product bible. What this product is, how it works, what's built, what's missing. Read before any plan, build, or PR. | [product/readme-first-product.md](product/readme-first-product.md) |
|
|
41
|
+
| [product/notes/](product/notes/README.md) | Freeform notes, research, observations. Anything useful that isn't a plan or idea. | [product/notes/README.md](product/notes/README.md) |
|
|
42
|
+
| [product/plans-prds/roadmap.md](product/plans-prds/roadmap.md) | Prioritized roadmap. Upcoming (ordered by priority), Done (with dates), Deprecated (with reasons). | [product/plans-prds/roadmap.md](product/plans-prds/roadmap.md) |
|
|
43
|
+
| [product/plans-prds/todos/](product/plans-prds/todos/README.md) | Per-agent todo files. One file per person/agent. Three sections: To Do, Done, Deprecated. | [product/plans-prds/todos/README.md](product/plans-prds/todos/README.md) |
|
|
44
|
+
| [product/product-ideas/](product/product-ideas/README.md) | Ideas that aren't plans yet. The incubator. Move to `plans-prds/upcoming/` when ready to commit. | [product/product-ideas/README.md](product/product-ideas/README.md) |
|
|
45
|
+
|
|
46
|
+
## Rules
|
|
47
|
+
|
|
48
|
+
**Never delete anything.** Move to `_trash/` in the nearest parent folder. Files in `_trash/` stay in git history and can always be recovered.
|
|
49
|
+
|
|
50
|
+
**`_sort/` is the holding pen.** When something doesn't have an obvious home yet, or iCloud duplicated something, put it in `_sort/`. File it properly when you know where it goes.
|
|
51
|
+
|
|
52
|
+
**`_trash/` is not garbage.** It's the archive. Completed plans go to `archive-complete/`. But notes, drafts, and superseded files go to `_trash/`. The difference: `archive-complete/` is work that shipped. `_trash/` is work that was replaced, abandoned, or consumed.
|
|
53
|
+
|
|
54
|
+
## How to Use This
|
|
55
|
+
|
|
56
|
+
**Starting a new feature?**
|
|
57
|
+
1. Write a plan in [product/plans-prds/current/](product/plans-prds/current/)
|
|
58
|
+
2. Write dev updates as you work in [dev-updates/](dev-updates/)
|
|
59
|
+
3. When the plan ships, move it to [archive-complete/](product/plans-prds/archive-complete/)
|
|
60
|
+
|
|
61
|
+
**Got an idea but not ready to plan?**
|
|
62
|
+
Put it in [product/product-ideas/](product/product-ideas/)
|
|
63
|
+
|
|
64
|
+
**Found something interesting but don't know where it goes?**
|
|
65
|
+
Put it in [_sort/](_sort/) or [product/notes/](product/notes/)
|
|
66
|
+
|
|
67
|
+
**Tracking work across agents?**
|
|
68
|
+
Use [product/plans-prds/todos/](product/plans-prds/todos/) (one file per person/agent) or GitHub Issues
|
|
69
|
+
|
|
70
|
+
## Dev Updates
|
|
71
|
+
|
|
72
|
+
Dev updates go in [dev-updates/](dev-updates/) with the naming convention:
|
|
73
|
+
|
|
74
|
+
```
|
|
75
|
+
YYYY-MM-DD--HH-MM--agent--description.md
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
Example: `2026-03-11--09-30--cc-mini--fix-hook-duplicates.md`
|
|
79
|
+
|
|
80
|
+
`wip-release` auto-detects today's dev updates and uses them as release notes. Write them as you work. They're the changelog that writes itself.
|