@dotdotgod/claude-code 0.1.30 → 0.1.31
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/commands/dd/plan.md
CHANGED
|
@@ -54,9 +54,10 @@ Prefer live repository docs in this order:
|
|
|
54
54
|
```
|
|
55
55
|
|
|
56
56
|
Skip the saved plan for obvious bounded work such as typos, single-file documentation clarifications, targeted test/validation runs, or one-file fixes with an unambiguous implementation path.
|
|
57
|
-
4.
|
|
58
|
-
5.
|
|
59
|
-
6.
|
|
57
|
+
4. For durable active plans that will be executed, keep the user-facing plan in `docs/plan/<task-slug>/README.md`. If `/plan-generator` staged planning is useful, it may record internal checkpoints under `docs/plan/<task-slug>/.dotdotgod-plan/NN_STAGE_NAME.md`; do not make legacy stage directories such as `01-intake/README.md` the required plan product.
|
|
58
|
+
5. Use UPPER_SNAKE_CASE support files in the task directory only when they improve resume quality, such as `ROLE_AREA_WORKSTREAMS.md`, `ATOMIC_TASKS.md`, `PROGRESS_LOG.md`, or `VERIFICATION_EVIDENCE.md`.
|
|
59
|
+
6. For long-running durable tasks, use concise README sections or optional support files for chronological progress, durable decisions, resume state, and task-specific verification checklists. `.dotdotgod-plan/` checkpoints are `/plan-generator` state, not a general Plan Mode requirement.
|
|
60
|
+
7. When a durable plan is created, include:
|
|
60
61
|
- scope and current status
|
|
61
62
|
- target files and rationale
|
|
62
63
|
- impact-derived related files/checks when available
|
|
@@ -66,12 +67,13 @@ Prefer live repository docs in this order:
|
|
|
66
67
|
- current resume state when useful
|
|
67
68
|
- final housekeeping step to move completed work to `docs/archive/plan/<task-slug>/`
|
|
68
69
|
- for Claude Code/Codex plans, a concrete `dd:impact` or `impact-review` step before broad verification or final handoff when source/config/docs files changed
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
70
|
+
8. Before executing a durable active plan, ensure the user has explicitly asked to execute it and resolve any plan-local Discussion Queue items that block execution review. Plan Mode does not require `dotdotgod plan validate` before execution; `/plan-generator` and manual/non-Plan-Mode workflows may still use the CLI plan-validation contract when appropriate.
|
|
71
|
+
9. Update `docs/plan/README.md` if the repository keeps active plan entries there.
|
|
72
|
+
10. Use repository-local package manager evidence for verification commands. In this repository, prefer `pnpm run verify`, `pnpm run pack:dry-run`, and `.husky/pre-push` when applicable.
|
|
73
|
+
11. After creating or updating behavior specs, run project validation when possible. For dotdotgod projects, `dotdotgod validate` enforces machine-readable `json dotdotgod` traceability blocks as the final section in specs. Use `dotdotgod validate --check-index` when you need to confirm markdown fingerprints match the graph index. If validation fails, use the schema, property guidance, and example shown in the validation error to repair the spec.
|
|
74
|
+
12. Stop after presenting the plan unless the user explicitly asks for execution.
|
|
75
|
+
13. During implementation in Claude Code or Codex, use `/dd:impact`, `dd:impact`, or the `impact-review` skill after edits and before broad verification, commits, pushes, publishing, or final handoff.
|
|
76
|
+
14. After implementation and verification, archive completed or superseded plan directories under `docs/archive/plan/<task-slug>/`; remove stale local plan artifacts only when the project policy allows plan/archive housekeeping.
|
|
75
77
|
|
|
76
78
|
## Quality Rules
|
|
77
79
|
|
package/package.json
CHANGED
|
@@ -50,9 +50,10 @@ Prefer live repository docs in this order:
|
|
|
50
50
|
```
|
|
51
51
|
|
|
52
52
|
Skip the saved plan for obvious bounded work such as typos, single-file documentation clarifications, targeted test/validation runs, or one-file fixes with an unambiguous implementation path.
|
|
53
|
-
4.
|
|
54
|
-
5.
|
|
55
|
-
6.
|
|
53
|
+
4. For durable active plans that will be executed, keep the user-facing plan in `docs/plan/<task-slug>/README.md`. If `/plan-generator` staged planning is useful, it may record internal checkpoints under `docs/plan/<task-slug>/.dotdotgod-plan/NN_STAGE_NAME.md`; do not make legacy stage directories such as `01-intake/README.md` the required plan product.
|
|
54
|
+
5. Use UPPER_SNAKE_CASE support files in the task directory only when they improve resume quality, such as `ROLE_AREA_WORKSTREAMS.md`, `ATOMIC_TASKS.md`, `PROGRESS_LOG.md`, or `VERIFICATION_EVIDENCE.md`.
|
|
55
|
+
6. For long-running durable tasks, use concise README sections or optional support files for chronological progress, durable decisions, resume state, and task-specific verification checklists. `.dotdotgod-plan/` checkpoints are `/plan-generator` state, not a general Plan Mode requirement.
|
|
56
|
+
7. When a durable plan is created, include:
|
|
56
57
|
- scope and current status
|
|
57
58
|
- target files and rationale
|
|
58
59
|
- impact-derived related files/checks when available
|
|
@@ -62,12 +63,13 @@ Prefer live repository docs in this order:
|
|
|
62
63
|
- current resume state when useful
|
|
63
64
|
- final housekeeping step to move completed work to `docs/archive/plan/<task-slug>/`
|
|
64
65
|
- for Claude Code/Codex plans, a concrete `dd:impact` or `impact-review` step before broad verification or final handoff when source/config/docs files changed
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
66
|
+
8. Before executing a durable active plan, ensure the user has explicitly asked to execute it and resolve any plan-local Discussion Queue items that block execution review. Plan Mode does not require `dotdotgod plan validate` before execution; `/plan-generator` and manual/non-Plan-Mode workflows may still use the CLI plan-validation contract when appropriate.
|
|
67
|
+
9. Update `docs/plan/README.md` if the repository keeps active plan entries there.
|
|
68
|
+
10. Use repository-local package manager evidence for verification commands. In this repository, prefer `pnpm run verify`, `pnpm run pack:dry-run`, and `.husky/pre-push` when applicable.
|
|
69
|
+
11. After creating or updating behavior specs, run project validation when possible. For dotdotgod projects, `dotdotgod validate` enforces machine-readable `json dotdotgod` traceability blocks as the final section in specs. Use `dotdotgod validate --check-index` when you need to confirm markdown fingerprints match the graph index. If validation fails, use the schema, property guidance, and example shown in the validation error to repair the spec.
|
|
70
|
+
12. Stop after presenting the plan unless the user explicitly asks for execution.
|
|
71
|
+
13. During implementation in Claude Code or Codex, use `/dd:impact`, `dd:impact`, or the `impact-review` skill after edits and before broad verification, commits, pushes, publishing, or final handoff.
|
|
72
|
+
14. After implementation and verification, archive completed or superseded plan directories under `docs/archive/plan/<task-slug>/`; remove stale local plan artifacts only when the project policy allows plan/archive housekeeping.
|
|
71
73
|
|
|
72
74
|
## Quality Rules
|
|
73
75
|
|