@mthanhlm/autodev 0.4.2 → 0.4.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.
package/README.md
CHANGED
|
@@ -8,8 +8,9 @@
|
|
|
8
8
|
- Keeps project state in `.autodev/`
|
|
9
9
|
- Uses `/autodev` as the main command
|
|
10
10
|
- Organizes work as `project -> track -> phase -> tasks`
|
|
11
|
+
- Starts new projects and new tracks with a short discovery pass so requirements are based on the user's actual goal
|
|
11
12
|
- Resolves `.autodev/` state from the repo root even when Claude is started in a nested subdirectory
|
|
12
|
-
- Maps brownfield repos with
|
|
13
|
+
- Maps brownfield repos in the main session, with optional specialized helpers when the environment supports them
|
|
13
14
|
- Runs a multi-lens review pass, using foreground review agents when the environment supports them
|
|
14
15
|
- Can auto-format edited code after Claude writes files when a local formatter is available
|
|
15
16
|
- Ships manual commands when you want direct control:
|
|
@@ -106,6 +107,7 @@ project -> track -> phase -> tasks
|
|
|
106
107
|
### Execution Model
|
|
107
108
|
|
|
108
109
|
- `/autodev` remains the single entrypoint
|
|
110
|
+
- Project and track setup should clarify what the user wants to build, for whom, and what done looks like before writing state files
|
|
109
111
|
- A phase is planned into one phase overview plus multiple task files
|
|
110
112
|
- `/autodev` stops after planning so the user can review the phase before any execution starts
|
|
111
113
|
- The phase keeps one user-facing orchestration session
|
|
@@ -3,8 +3,15 @@
|
|
|
3
3
|
Type: [feature|bugfix|refactor|research|polish]
|
|
4
4
|
Status: active
|
|
5
5
|
|
|
6
|
+
## Why This Track
|
|
7
|
+
[Why this work matters right now.]
|
|
8
|
+
|
|
6
9
|
## Outcome
|
|
7
|
-
[What this track is
|
|
10
|
+
[What changes for the user or operator when this track is done.]
|
|
11
|
+
|
|
12
|
+
## Success Signals
|
|
13
|
+
- [Observable user or operator outcome]
|
|
14
|
+
- [Verification or quality bar]
|
|
8
15
|
|
|
9
16
|
## Scope Boundaries
|
|
10
17
|
- [What is in scope]
|
|
@@ -37,13 +37,22 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" status
|
|
|
37
37
|
|
|
38
38
|
6. If the route is `track_select` or `track_setup`, handle it directly:
|
|
39
39
|
- If tracks exist, ask whether to continue one of them or create a new track.
|
|
40
|
-
-
|
|
40
|
+
- When creating or repairing a track, do a short track-discovery pass before writing files.
|
|
41
|
+
- Ask for:
|
|
42
|
+
- the initiative name
|
|
43
|
+
- what the user wants to ship or change in this track
|
|
44
|
+
- what done looks like
|
|
45
|
+
- scope boundaries and explicit non-goals
|
|
46
|
+
- dependencies or constraints only if they affect planning
|
|
47
|
+
- If the request is vague, summarize the understanding in a few bullets and resolve ambiguity before writing.
|
|
48
|
+
- If no tracks exist, do not jump straight to phase types before the track goal is clear.
|
|
41
49
|
- Create or repair:
|
|
42
50
|
- `.autodev/ACTIVE_TRACK`
|
|
43
51
|
- `.autodev/tracks/<slug>/TRACK.md`
|
|
44
52
|
- `.autodev/tracks/<slug>/REQUIREMENTS.md`
|
|
45
53
|
- `.autodev/tracks/<slug>/ROADMAP.md`
|
|
46
54
|
- `.autodev/tracks/<slug>/STATE.md`
|
|
55
|
+
- Fill the track and requirements docs from the clarified intent, not generic placeholders.
|
|
47
56
|
- Use a lowercase hyphenated slug.
|
|
48
57
|
- Use roadmap headings in this format:
|
|
49
58
|
|
|
@@ -3,8 +3,11 @@ Map a brownfield repository quickly and produce a usable codebase brief without
|
|
|
3
3
|
</purpose>
|
|
4
4
|
|
|
5
5
|
<rules>
|
|
6
|
-
-
|
|
6
|
+
- The main `/autodev` session owns this workflow and the final synthesis.
|
|
7
|
+
- Specialized codebase agents are optional implementation helpers, not a separate user-facing mode.
|
|
8
|
+
- Prefer a small set of foreground codebase agents, run one at a time, only when agent delegation is clearly available.
|
|
7
9
|
- Give each agent a disjoint write target.
|
|
10
|
+
- If agent delegation is unavailable or unclear, continue inline without surfacing platform confusion.
|
|
8
11
|
- Use read-only investigation only. No git writes.
|
|
9
12
|
- Focus on information that will improve planning and execution for the active track.
|
|
10
13
|
</rules>
|
|
@@ -26,34 +29,36 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init explore-codebase
|
|
|
26
29
|
- the active track docs if they exist
|
|
27
30
|
- representative repo files needed to orient the exploration
|
|
28
31
|
|
|
29
|
-
4.
|
|
32
|
+
4. Do a small amount of direct repo reading first so the current session understands the workspace before deciding whether helper agents are useful.
|
|
33
|
+
|
|
34
|
+
5. If agent delegation is clearly available, explicitly call the `Agent` tool for these subagents, one at a time in the foreground, with owned outputs:
|
|
30
35
|
- `autodev-codebase-structure` for standalone installs, or `autodev:autodev-codebase-structure` in direct plugin runs, owns `.autodev/codebase/structure.md`
|
|
31
36
|
- `autodev-codebase-domain` for standalone installs, or `autodev:autodev-codebase-domain` in direct plugin runs, owns `.autodev/codebase/domain.md`
|
|
32
37
|
- `autodev-codebase-runtime` for standalone installs, or `autodev:autodev-codebase-runtime` in direct plugin runs, owns `.autodev/codebase/runtime.md`
|
|
33
38
|
- `autodev-codebase-quality` for standalone installs, or `autodev:autodev-codebase-quality` in direct plugin runs, owns `.autodev/codebase/quality.md`
|
|
34
39
|
|
|
35
|
-
|
|
40
|
+
6. Tell each agent:
|
|
36
41
|
- it is not alone in the codebase
|
|
37
42
|
- it must not overwrite another agent's file
|
|
38
43
|
- it should stay read-only except for its owned output file
|
|
39
44
|
- it should prefer concise, decision-useful findings over exhaustive listing
|
|
40
45
|
|
|
41
|
-
|
|
46
|
+
7. If agent delegation is unavailable, do not stop on the raw platform message.
|
|
42
47
|
Treat messages like `specialized agents aren't available` as an environment limitation, tell the user exploration will continue in the current session, and write the four owned output files directly.
|
|
43
48
|
|
|
44
|
-
|
|
49
|
+
8. After the four agent outputs are written, or after the current-session fallback writes them, review them and synthesize `.autodev/codebase/summary.md` with:
|
|
45
50
|
- architectural overview
|
|
46
51
|
- major constraints
|
|
47
52
|
- current track implications
|
|
48
53
|
- hotspots and likely safe change points
|
|
49
54
|
- the next planning risks to watch
|
|
50
55
|
|
|
51
|
-
|
|
56
|
+
9. Update `.autodev/STATE.md` and the active track `STATE.md` so they reflect:
|
|
52
57
|
- `Current Step: planning`
|
|
53
58
|
- `Next Command: /autodev`
|
|
54
59
|
- refreshed ISO timestamp
|
|
55
60
|
|
|
56
|
-
|
|
61
|
+
10. End with:
|
|
57
62
|
- the biggest structural insight
|
|
58
63
|
- the biggest risk
|
|
59
64
|
- `/autodev` as the next command
|
|
@@ -5,7 +5,8 @@ Initialize `.autodev/` with useful project-level context, then create the first
|
|
|
5
5
|
<rules>
|
|
6
6
|
- Do not run `git init`, `git add`, `git commit`, `git checkout`, `git switch`, `git merge`, `git rebase`, `git worktree`, `git push`, `git pull`, `git stash`, `git reset`, `git fetch`, or `git clone`.
|
|
7
7
|
- Git is read-only only.
|
|
8
|
-
- Use concise questioning
|
|
8
|
+
- Use concise questioning, but do a short discovery pass before writing project state.
|
|
9
|
+
- Ask only for details that materially change requirements or roadmap.
|
|
9
10
|
- Treat the repository as a `project`, then put the current initiative in a `track`.
|
|
10
11
|
</rules>
|
|
11
12
|
|
|
@@ -19,11 +20,15 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init new-project
|
|
|
19
20
|
|
|
20
21
|
2. If `.autodev/PROJECT.md` already exists, stop and tell the user to use `/autodev`.
|
|
21
22
|
|
|
22
|
-
3.
|
|
23
|
-
- the
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
23
|
+
3. Do a short discovery pass before writing project or track files.
|
|
24
|
+
- If the current prompt is thin, ask for:
|
|
25
|
+
- what the user wants to build or change right now
|
|
26
|
+
- who it is for or what pain it solves
|
|
27
|
+
- what done looks like for the first track
|
|
28
|
+
- scope boundaries, constraints, and explicit non-goals that materially affect planning
|
|
29
|
+
- whether this is greenfield or brownfield if ambiguous
|
|
30
|
+
- Prefer one compact batch of questions over a long drip of follow-ups.
|
|
31
|
+
- Reflect the understanding back in 2-5 bullets before writing files when the original request was vague.
|
|
27
32
|
|
|
28
33
|
4. Read the templates from the execution context.
|
|
29
34
|
|
|
@@ -38,6 +43,7 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init new-project
|
|
|
38
43
|
- one-line summary
|
|
39
44
|
- project type
|
|
40
45
|
- repo or product problem
|
|
46
|
+
- current user goal or job to be done
|
|
41
47
|
- users or operators
|
|
42
48
|
- success criteria
|
|
43
49
|
- constraints
|
|
@@ -58,12 +64,14 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init new-project
|
|
|
58
64
|
9. Create `.autodev/tracks/<slug>/TRACK.md` with:
|
|
59
65
|
- track name
|
|
60
66
|
- type or workstream shape
|
|
61
|
-
-
|
|
62
|
-
-
|
|
67
|
+
- why this track exists now
|
|
68
|
+
- desired outcome and what done looks like
|
|
69
|
+
- scope boundaries and explicit non-goals
|
|
63
70
|
- known dependencies
|
|
64
71
|
- brownfield notes if this is an existing repo
|
|
65
72
|
|
|
66
73
|
10. Write `.autodev/tracks/<slug>/REQUIREMENTS.md` with clear must-have requirements and acceptance bullets for the track only.
|
|
74
|
+
Tie the acceptance bullets to the discovered outcome instead of placeholder implementation tasks.
|
|
67
75
|
|
|
68
76
|
11. Write `.autodev/tracks/<slug>/ROADMAP.md` with 2-8 phases using this exact heading format:
|
|
69
77
|
|
|
@@ -89,5 +97,5 @@ Each phase must include:
|
|
|
89
97
|
|
|
90
98
|
13. If the project is brownfield, do not fake a codebase map. Continue into codebase exploration inside `/autodev` by default. Mention `/autodev-explore-codebase` only as a manual shortcut. Otherwise, the next step is planning phase 1 through `/autodev`.
|
|
91
99
|
|
|
92
|
-
14. End with a short summary and direct the user to `/autodev`. Mention the manual shortcut only if useful.
|
|
100
|
+
14. End with a short summary of what the user wants to build or change and direct the user to `/autodev`. Mention the manual shortcut only if useful.
|
|
93
101
|
</process>
|
package/package.json
CHANGED