@dotdotgod/claude-code 0.2.3 → 0.2.4
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/impact.md
CHANGED
|
@@ -24,12 +24,13 @@ This workflow is the Claude Code and Codex counterpart to Pi's `/impact-check` r
|
|
|
24
24
|
- Check git status and preserve unrelated user edits.
|
|
25
25
|
- Include unstaged, staged, and untracked source/config/docs files that are relevant to the current task.
|
|
26
26
|
- Exclude dependencies, generated caches, build artifacts, secrets, and unrelated local-memory files unless the user explicitly asks about them.
|
|
27
|
-
2. Prefer bounded graph impact.
|
|
28
|
-
-
|
|
29
|
-
- If
|
|
27
|
+
2. Prefer bounded multi-seed graph impact.
|
|
28
|
+
- Collect the complete relevant changed-file set, preserve first-seen order, and run one command with repeated `--changed <path>` options for up to 20 unique paths: `dotdotgod graph impact <root> --changed <path-a> --changed <path-b> --compact` or `--yml`.
|
|
29
|
+
- If more than 20 unique paths remain, split them into ordered batches of at most 20. Do not run one command per file unless only one relevant path exists.
|
|
30
|
+
- If the local repository uses the source checkout CLI, use `node packages/cli/bin/dotdotgod.mjs graph impact <root> --changed <path-a> --changed <path-b> --compact` or `--yml`.
|
|
30
31
|
- If the CLI is unavailable, continue with README indexes, traceability blocks, package metadata, and targeted grep/find fallback.
|
|
31
32
|
3. Inspect impact output selectively.
|
|
32
|
-
- Review related specs, tests, architecture docs, and source files with the highest scores and clearest reasons.
|
|
33
|
+
- Review the deduplicated combined ranking and each seed's non-seed top-five results, prioritizing related specs, tests, architecture docs, and source files with the highest scores and clearest reasons.
|
|
33
34
|
- When behavior specs appear through `implemented_by`, `verified_by`, or `related_doc`, read those docs before broad verification.
|
|
34
35
|
- Do not paste large raw impact JSON into the response unless the user asks for diagnostics.
|
|
35
36
|
4. Repair or update related docs/tests when the impact output shows stale, missing, or contradictory project memory.
|
package/commands/dd/plan-goal.md
CHANGED
|
@@ -82,7 +82,7 @@ Use the Stage 01 context, then update the durable plan artifact and checkpoint.
|
|
|
82
82
|
|
|
83
83
|
Include in the durable plan and checkpoint:
|
|
84
84
|
- **Memory Reads** — agent docs, README indexes, specs, architecture notes, test docs, and active plans consulted. Use `dotdotgod expand <root> "<request>" --json` when the request contains `[[...]]` refs; use `--fuzzy` for high-signal doc names before broad grep/find.
|
|
85
|
-
- **Impact Candidates** —
|
|
85
|
+
- **Impact Candidates** — collect the likely target files and run one bounded multi-seed `dotdotgod graph impact <root> --changed <path-a> --changed <path-b> --compact` command for up to 20 unique paths, splitting only larger sets into ordered batches. Record the combined ranking and each seed's non-seed top-five specs, tests, scores, and reasons. Fall back to README indexes and traceability blocks when the CLI is unavailable.
|
|
86
86
|
- **Related Files** — source, config, and doc files identified as relevant.
|
|
87
87
|
|
|
88
88
|
Construction checklist categories: Memory reads, Impact candidates, Related files, Boundary risk.
|
package/commands/dd/plan.md
CHANGED
|
@@ -42,7 +42,7 @@ Prefer live repository docs in this order:
|
|
|
42
42
|
- Search docs by domain terms from the user request.
|
|
43
43
|
- Read nearest README indexes and relevant focused docs.
|
|
44
44
|
- For behavior changes, prefer specs with CLI-enforced fenced `json dotdotgod` traceability blocks in the final section; use their source, test, related-doc, and verification-command mappings before editing code.
|
|
45
|
-
- When the dotdotgod CLI is available and likely target files are known, run `dotdotgod graph impact <root> --changed <path> --yml` for
|
|
45
|
+
- When the dotdotgod CLI is available and likely target files are known, run one bounded multi-seed `dotdotgod graph impact <root> --changed <path-a> --changed <path-b> --yml` command for up to 20 unique files, splitting only larger sets into ordered batches. Use the combined ranking and per-seed top-five related specs, tests, docs, commands, scores, and reasons to strengthen target files, risks, and verification steps. If impact lookup fails or the CLI is unavailable, continue with README-index and traceability fallback evidence.
|
|
46
46
|
- For Claude Code and Codex, add an explicit post-edit impact-review step to the plan when the task will change source/config files, because those adapters do not have Pi's automatic pending-impact reminder or `/impact-check` enforcement.
|
|
47
47
|
- During planning, treat these dotdotgod commands as bounded context/status helpers: `status`, `load-snapshot`, `resolve`, `expand`, `graph impact`, `graph communities`, read-only `config`, and `index`. Do not run mutating scaffold/config commands such as `init` or `config init` unless the user explicitly asks for initialization or config creation.
|
|
48
48
|
- Use `grep` or `find` after reference expansion, impact, and targeted reads when the task needs fallback discovery or raw source text search.
|
package/hooks/README.md
CHANGED
|
@@ -114,7 +114,7 @@ Use this only when you want stop-time docs validation. It may be noisier than ad
|
|
|
114
114
|
|
|
115
115
|
A `UserPromptSubmit` hook can add a reminder for implementation-like prompts. Keep the command fast and non-mutating. Prefer reminders over automatic planning because `/dd:plan` and the planning skill are the explicit durable workflow.
|
|
116
116
|
|
|
117
|
-
`UserPromptSubmit` does not support matchers in Claude Code settings, so filter on the submitted `prompt` field inside the hook command. For planning-like prompts, use an advisory reminder that asks Claude to resolve explicit `[[...]]` project-memory refs with `dotdotgod expand`, identify the complete target file list, and run graph impact
|
|
117
|
+
`UserPromptSubmit` does not support matchers in Claude Code settings, so filter on the submitted `prompt` field inside the hook command. For planning-like prompts, use an advisory reminder that asks Claude to resolve explicit `[[...]]` project-memory refs with `dotdotgod expand`, identify the complete target file list, and run one bounded multi-seed graph impact command with repeated `--changed` options for up to 20 unique paths before finalizing the plan. Split only larger sets into ordered batches:
|
|
118
118
|
|
|
119
119
|
```json
|
|
120
120
|
{
|
|
@@ -124,7 +124,7 @@ A `UserPromptSubmit` hook can add a reminder for implementation-like prompts. Ke
|
|
|
124
124
|
"hooks": [
|
|
125
125
|
{
|
|
126
126
|
"type": "command",
|
|
127
|
-
"command": "python3 -c \"import json,re,sys; p=json.load(sys.stdin).get('prompt',''); msg='dotdotgod: advisory reminder only. If the prompt contains [[...]] refs, run dotdotgod expand . \\\"<prompt>\\\" --json before broad grep/find. For planning work, identify the complete target file list, run dotdotgod graph impact . --changed <path> --compact for
|
|
127
|
+
"command": "python3 -c \"import json,re,sys; p=json.load(sys.stdin).get('prompt',''); msg='dotdotgod: advisory reminder only. If the prompt contains [[...]] refs, run dotdotgod expand . \\\"<prompt>\\\" --json before broad grep/find. For planning work, identify the complete target file list, run one bounded dotdotgod graph impact . --changed <path-a> --changed <path-b> --compact command for up to 20 unique paths, split only larger sets into ordered batches, and use combined and per-seed impact output to strengthen related docs, risks, and verification steps. After edits, use /dd:impact before broad verification or handoff. If docs change, run dotdotgod validate . --include-local-memory --check-index.'; print(msg) if re.search(r'plan|planning|플랜|계획|\\[\\[', p, re.I) else None\"",
|
|
128
128
|
"timeout": 10
|
|
129
129
|
}
|
|
130
130
|
]
|
package/package.json
CHANGED
|
@@ -38,7 +38,7 @@ Prefer live repository docs in this order:
|
|
|
38
38
|
- Search docs by domain terms from the user request.
|
|
39
39
|
- Read nearest README indexes and relevant focused docs.
|
|
40
40
|
- For behavior changes, prefer specs with CLI-enforced fenced `json dotdotgod` traceability blocks in the final section; use their source, test, related-doc, and verification-command mappings before editing code.
|
|
41
|
-
- When the dotdotgod CLI is available and likely target files are known, run `dotdotgod graph impact <root> --changed <path> --yml` for
|
|
41
|
+
- When the dotdotgod CLI is available and likely target files are known, run one bounded multi-seed `dotdotgod graph impact <root> --changed <path-a> --changed <path-b> --yml` command for up to 20 unique files, splitting only larger sets into ordered batches. Use the combined ranking and per-seed top-five related specs, tests, docs, commands, scores, and reasons to strengthen target files, risks, and verification steps. If impact lookup fails or the CLI is unavailable, continue with README-index and traceability fallback evidence.
|
|
42
42
|
- For Claude Code and Codex, add an explicit post-edit impact-review step to the plan when the task will change source/config files, because those adapters do not have Pi's automatic pending-impact reminder or `/impact-check` enforcement.
|
|
43
43
|
- During planning, treat these dotdotgod commands as bounded context/status helpers: `status`, `load-snapshot`, `resolve`, `expand`, `graph impact`, `graph communities`, read-only `config`, and `index`. Do not run mutating scaffold/config commands such as `init` or `config init` unless the user explicitly asks for initialization or config creation.
|
|
44
44
|
- Use `grep` or `find` after reference expansion, impact, and targeted reads when the task needs fallback discovery or raw source text search.
|
|
@@ -20,12 +20,13 @@ This workflow is the Claude Code and Codex counterpart to Pi's `/impact-check` r
|
|
|
20
20
|
- Check git status and preserve unrelated user edits.
|
|
21
21
|
- Include unstaged, staged, and untracked source/config/docs files that are relevant to the current task.
|
|
22
22
|
- Exclude dependencies, generated caches, build artifacts, secrets, and unrelated local-memory files unless the user explicitly asks about them.
|
|
23
|
-
2. Prefer bounded graph impact.
|
|
24
|
-
-
|
|
25
|
-
- If
|
|
23
|
+
2. Prefer bounded multi-seed graph impact.
|
|
24
|
+
- Collect the complete relevant changed-file set, preserve first-seen order, and run one command with repeated `--changed <path>` options for up to 20 unique paths: `dotdotgod graph impact <root> --changed <path-a> --changed <path-b> --compact` or `--yml`.
|
|
25
|
+
- If more than 20 unique paths remain, split them into ordered batches of at most 20. Do not run one command per file unless only one relevant path exists.
|
|
26
|
+
- If the local repository uses the source checkout CLI, use `node packages/cli/bin/dotdotgod.mjs graph impact <root> --changed <path-a> --changed <path-b> --compact` or `--yml`.
|
|
26
27
|
- If the CLI is unavailable, continue with README indexes, traceability blocks, package metadata, and targeted grep/find fallback.
|
|
27
28
|
3. Inspect impact output selectively.
|
|
28
|
-
- Review related specs, tests, architecture docs, and source files with the highest scores and clearest reasons.
|
|
29
|
+
- Review the deduplicated combined ranking and each seed's non-seed top-five results, prioritizing related specs, tests, architecture docs, and source files with the highest scores and clearest reasons.
|
|
29
30
|
- When behavior specs appear through `implemented_by`, `verified_by`, or `related_doc`, read those docs before broad verification.
|
|
30
31
|
- Do not paste large raw impact JSON into the response unless the user asks for diagnostics.
|
|
31
32
|
4. Repair or update related docs/tests when the impact output shows stale, missing, or contradictory project memory.
|
|
@@ -78,7 +78,7 @@ Use the Stage 01 context, then update the durable plan artifact and checkpoint.
|
|
|
78
78
|
|
|
79
79
|
Include in the durable plan and checkpoint:
|
|
80
80
|
- **Memory Reads** — agent docs, README indexes, specs, architecture notes, test docs, and active plans consulted. Use `dotdotgod expand <root> "<request>" --json` when the request contains `[[...]]` refs; use `--fuzzy` for high-signal doc names before broad grep/find.
|
|
81
|
-
- **Impact Candidates** —
|
|
81
|
+
- **Impact Candidates** — collect the likely target files and run one bounded multi-seed `dotdotgod graph impact <root> --changed <path-a> --changed <path-b> --compact` command for up to 20 unique paths, splitting only larger sets into ordered batches. Record the combined ranking and each seed's non-seed top-five specs, tests, scores, and reasons. Fall back to README indexes and traceability blocks when the CLI is unavailable.
|
|
82
82
|
- **Related Files** — source, config, and doc files identified as relevant.
|
|
83
83
|
|
|
84
84
|
Construction checklist categories: Memory reads, Impact candidates, Related files, Boundary risk.
|