devlyn-cli 1.7.2 → 1.7.3
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.
|
@@ -7,6 +7,19 @@ description: Transform unstructured ideas into implementation-ready planning doc
|
|
|
7
7
|
|
|
8
8
|
Turn unstructured thinking into auto-resolve-ready documents. The output is a precision-engineered context pipeline — each document layer serves a specific role so that implementation agents receive exactly the context they need, nothing more.
|
|
9
9
|
|
|
10
|
+
<hard_boundary>
|
|
11
|
+
This skill is a PLANNING tool, not an IMPLEMENTATION tool. Your output is documents (VISION.md, ROADMAP.md, item specs) — never code changes.
|
|
12
|
+
|
|
13
|
+
When the user describes a bug, improvement, or feature request through ideate, they want it CAPTURED in the roadmap, not FIXED in the codebase. Even if the fix seems trivial and obvious, resist the urge to implement it. The user chose `/devlyn:ideate` over `/devlyn:resolve` for a reason — they want planning, not coding.
|
|
14
|
+
|
|
15
|
+
Concretely:
|
|
16
|
+
- Do NOT read source code to find and fix issues
|
|
17
|
+
- Do NOT edit application files (.tsx, .ts, .py, .js, etc.)
|
|
18
|
+
- DO create or update roadmap documents (VISION.md, ROADMAP.md, item specs)
|
|
19
|
+
- DO explore and research the problem space to write better specs
|
|
20
|
+
- If you catch yourself about to open a source file to make a code change, stop — that's a signal you've left ideation mode
|
|
21
|
+
</hard_boundary>
|
|
22
|
+
|
|
10
23
|
<why_this_matters>
|
|
11
24
|
When ideas flow directly from conversation to `/devlyn:auto-resolve`, context degrades at each handoff:
|
|
12
25
|
- Abstract vision statements cause over-engineering (the agent optimizes for principles instead of deliverables)
|
|
@@ -71,6 +84,7 @@ Before starting, identify what the user needs:
|
|
|
71
84
|
|--------|------|----------|
|
|
72
85
|
| No existing docs, new project or idea | **Greenfield** | Full flow: Frame → Explore → Converge → Document |
|
|
73
86
|
| Existing docs, user adds new ideas | **Expand** | Lighter Frame, focused Explore on new area, merge into existing phases |
|
|
87
|
+
| Existing docs, user describes a single bug/improvement/idea | **Quick Add** | Read existing roadmap, create one item spec, add row to ROADMAP.md |
|
|
74
88
|
| One specific feature needs deep thought | **Deep-dive** | Intensive Explore on one topic, output 1-3 specs |
|
|
75
89
|
| User shares links/resources to process | **Research-first** | Lead with Explore (research synthesis), then standard flow |
|
|
76
90
|
| Existing roadmap, user wants to reprioritize | **Replan** | Read existing docs, focus on Converge, update documents |
|
|
@@ -100,6 +114,30 @@ Expand is the most common mode after initial setup — the user already has Visi
|
|
|
100
114
|
|
|
101
115
|
In Replan mode, also read existing docs first, then focus on the Converge phase to reprioritize.
|
|
102
116
|
|
|
117
|
+
### Quick Add Mode Detail
|
|
118
|
+
|
|
119
|
+
Quick Add is for when the user has a single concrete idea, bug report, or improvement — they don't need a full ideation session, just a new entry in the roadmap. This is the most common trigger for misuse: the request looks like a simple fix, so the temptation is to implement it. Don't. Capture it.
|
|
120
|
+
|
|
121
|
+
**On entry:**
|
|
122
|
+
1. Read `docs/ROADMAP.md` and relevant phase `_overview.md` files
|
|
123
|
+
2. Identify the best-fit phase for the new item (or suggest a new phase if it doesn't fit)
|
|
124
|
+
3. Determine the next available item ID (e.g., if phase 2 has 2.1-2.4, the new item is 2.5)
|
|
125
|
+
|
|
126
|
+
**Workflow (minimal — no full Frame/Explore/Converge):**
|
|
127
|
+
1. Confirm the idea with the user: "I'll add this as [item title] in Phase [N]. That sound right?"
|
|
128
|
+
2. Ask 1-2 clarifying questions if the requirement is unclear (skip if the user gave enough detail)
|
|
129
|
+
3. Generate the item spec following `references/templates/item-spec.md`
|
|
130
|
+
4. Add a row to `docs/ROADMAP.md`
|
|
131
|
+
5. Output confirmation: the file path and a suggested auto-resolve command
|
|
132
|
+
|
|
133
|
+
**Example output:**
|
|
134
|
+
```
|
|
135
|
+
Added: docs/roadmap/phase-2/2.5-back-to-review-button.md
|
|
136
|
+
|
|
137
|
+
To implement:
|
|
138
|
+
/devlyn:auto-resolve "Implement per spec at docs/roadmap/phase-2/2.5-back-to-review-button.md"
|
|
139
|
+
```
|
|
140
|
+
|
|
103
141
|
### Context Archiving
|
|
104
142
|
|
|
105
143
|
As projects progress, completed work accumulates and dilutes the active roadmap. Archive stale context at these trigger points:
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "devlyn-cli",
|
|
3
|
-
"version": "1.7.
|
|
3
|
+
"version": "1.7.3",
|
|
4
4
|
"description": "AI development toolkit for Claude Code — ideate, auto-resolve, and ship with context engineering and agent orchestration",
|
|
5
5
|
"homepage": "https://github.com/fysoul17/devlyn-cli#readme",
|
|
6
6
|
"bin": {
|