@dotdotgod/claude-code 0.2.6 → 0.2.8

package/README.md

@@ -23,7 +23,6 @@ Then use the bundled `/dd:*` commands in your repository:
 /dd:init
 /dd:load
 /dd:plan Update the API migration plan.
-/dd:plan-goal Add the new export API to the auth module.
 /dd:impact
 ```
 
@@ -40,12 +39,9 @@ claude --plugin-dir /path/to/dotdotgod/packages/claude-code
 | `/dd:init` | Start a repository with dotdotgod conventions. | Creates or normalizes shared agent files, docs indexes, local-memory areas, and the complete default project config. |
 | `/dd:load` | Load project memory without changing maintained project files. | Renders the shared Markdown tree and uses `dotdotgod query` when focus text is provided; query may refresh ignored caches. |
 | `/dd:plan` | Plan before implementation. | Writes or updates durable task intent in `docs/plan/<task-slug>/README.md`. |
-| `/dd:plan-goal` | Run 5-stage structured planning before implementation. | Produces durable checkpoint files in `docs/plan/<task>/.dotdotgod-plan/` and a plan README. |
 | `/dd:impact` | Review changed files before verification or handoff. | Uses `dotdotgod graph impact` to identify likely related docs, tests, commands, and source files. |
 | `document-clarify` | Improve docs wording without changing behavior contracts. | Clarifies README/spec/test/arch/plan/archive docs using memory-area roles. |
 
-The package also includes matching skills for init, load, planning, plan-goal, and impact-review workflows.
-
 ## Shared Project-Memory Contract
 
 - `AGENTS.md` remains canonical.

package/commands/dd/init.md

@@ -12,56 +12,13 @@ Initialize or normalize a repository with dotdotgod project memory and the compl
 
 Arguments: `$ARGUMENTS`
 
-## Overview
+## Goal
 
-Create a conservative dotdotgod project baseline shared by AI coding agents:
-
-- `AGENTS.md` is the canonical project instruction file.
-- `CLAUDE.md` and `CODEX.md` are thin agent-specific entrypoints.
-- `docs/` contains concise indexes for specs, tests, architecture, active plans, and archives.
-- `dotdotgod.config.json` materializes the complete editable default project policy.
-- `.gitignore` keeps `docs/plan`, `docs/archive`, and `.dotdotgod` local by default.
-
-Under `docs/`, directories use kebab-case and markdown file names use UPPER_SNAKE_CASE, including `README.md`.
-
-## CLI and Fallback
-
-Prefer the CLI initializer:
-
-```bash
-dotdotgod init <project-root>
-```
-
-Use the bundled fallback when the CLI is unavailable:
-
-```bash
-sh "${CLAUDE_PLUGIN_ROOT}/skills/project-initializer/scripts/init_project.sh" <project-root>
-```
-
-Both paths create the same baseline file set and canonical config while preserving existing files. Use `--dry-run` for unfamiliar repositories and `--dotdot-setting` for the optional documentation and code-convention guidance.
+Create a non-destructive dotdotgod baseline with canonical agent instructions, thin agent entrypoints, documentation indexes, project config, and local-memory ignore rules.
 
 ## Workflow
 
-1. Inspect the project root.
-   - Check `AGENTS.md`, `AGENT.md`, `CLAUDE.md`, `CODEX.md`, `README.md`, `.gitignore`, `docs/`, and `dotdotgod.config.json`.
-   - Preserve project-specific instructions and unrelated user work.
-   - Keep `AGENTS.md` canonical when both `AGENT.md` and `AGENTS.md` exist.
-2. Run the initializer.
-   - Use the CLI when available; otherwise use the bundled fallback.
-   - Existing files are always preserved and skipped.
-3. Review and validate.
-   - Fill project-specific placeholders in `AGENTS.md` when the required context is known.
-   - Keep `CLAUDE.md` and `CODEX.md` thin.
-   - Preserve the generated complete memory-area set; do not replace it with a partial hand-written list.
-   - Run `dotdotgod validate <project-root>` after creating or changing config when the CLI is available.
-   - Inspect `dotdotgod config <project-root> --json` when validation fails or resolved policy needs review.
-4. Report the result.
-   - List created, updated, and skipped files, plus validation failures.
-   - Report when CLI validation was unavailable.
-   - Identify existing instructions that still require manual consolidation.
-
-## Bundled Resources
-
-- `scripts/init_project.sh`: POSIX fallback initializer.
-- `templates/dotdotgod.config.json`: generated canonical config template used by the fallback.
-- `references/agent-docs.md`: shared agent-document naming and content model.
+1. Inspect existing agent instructions, documentation, config, and ignore rules; preserve existing files and unrelated user work.
+2. Run `dotdotgod init <project-root>` when available; otherwise run `sh "${CLAUDE_PLUGIN_ROOT}/skills/project-initializer/scripts/init_project.sh" <project-root>`. Existing files must be skipped, not replaced.
+3. Validate the initialized project with `dotdotgod validate <project-root>` when available.
+4. Report created and skipped files, validation failures, and unresolved instruction conflicts.

package/commands/dd/load.md

@@ -14,46 +14,16 @@ User focus, if provided: `$ARGUMENTS`
 
 ## Goal
 
-Load the current repository's dotdotgod project memory without modifying source, documentation, or project config. A focused query may refresh ignored `.dotdotgod/vectors/` data and the runtime's user-level model cache. Use a full load for an explicit project overview and a compact load to refresh an already-loaded session. Treat free-form arguments as query text, not as mode switches.
+Load the repository's dotdotgod project memory without modifying maintained files. Treat free-form arguments as query text, not mode switches.
 
 ## Workflow
 
-1. Identify the repository root and current state.
-   - Check the current directory and, when Git is available, the repository root, branch, and dirty worktree status.
-   - Mention user changes and avoid reverting or cleaning them.
-2. Read baseline memory only when it is not already clear from loaded context.
-   - Start with `AGENTS.md`, the current adapter entrypoint when present, `README.md`, and `docs/README.md`.
-   - Do not run scaffold, config-writing, or source-modifying commands during a load.
-3. Build the shared documentation map.
-   - Discover Markdown files under `docs/` after applying `load.documentationSummary.exclude`, which excludes `docs/plan` and `docs/archive` by default.
-   - Render repository-relative paths as a prefix-compressed tree. Count `docs/` as directory depth 1.
-   - Without arguments, expand through directory depth 5. At the boundary, summarize deeper descendants with exact directory and Markdown-file counts.
-4. Use query routing only when arguments are present.
-   - Run `dotdotgod query <root> "<arguments>" --limit 30 --json` when the command is available.
-   - Show the best-ranked chunk from each of at most 30 distinct Markdown files and render the documentation tree through directory depth 3.
-   - If query is unavailable, continue from the tree, README indexes, and targeted reads.
-5. Read document bodies selectively.
-   - Follow README indexes as maintained tables of contents.
-   - Prefer query results, explicit paths, and the current request before broader search.
-   - Use `grep` or `find` only when targeted reads do not provide enough evidence.
-6. Read local memory only when relevant.
-   - For active plans, list `docs/plan` entries first and read only relevant plan files.
-   - Use `docs/archive/README.md` as the history map. Do not scan archive bodies by default.
-7. Avoid broad reads of generated outputs, dependencies, databases, caches, secrets, and `.env*` contents.
-
-## Output Shape
-
-For a full load, respond concisely with:
-
-- Project narrative and purpose
-- Key working rules
-- Relevant documentation and verification routes
-- Relevant active plans or archive history only when needed
-- Questions surfaced by loaded material
-
-For a compact load, respond with:
-
-- Compact project-memory status
-- Relevant documentation routes
-- Relevant active plan hints only when needed
-- A short bounded list of next reads, or a note that none are needed
+1. Identify the repository root.
+2. When baseline context is missing, read `AGENTS.md`, the adapter entrypoint, `README.md`, and `docs/README.md` when present.
+3. Build a prefix-compressed tree of `docs/**/*.md` after `load.documentationSummary.exclude`. Count `docs/` as depth 1; without arguments, expand through depth 5 and summarize deeper descendants with exact directory and Markdown-file counts.
+4. With arguments, run `dotdotgod query <root> "<arguments>" --limit 30 --json` when available, return at most 30 distinct Markdown files, and render the tree through depth 3. Fall back to the tree and README indexes when query is unavailable.
+5. Read bodies selectively from query results, explicit paths, and README indexes. Read relevant active plans only when needed, use `docs/archive/README.md` as the history map, and avoid broad generated, dependency, cache, or secret reads.
+
+## Output
+
+Report the project purpose, key rules, relevant documentation routes, and only the active-plan or next-read hints needed for the request. Keep compact loads to a brief refresh.

package/commands/dd/plan.md

@@ -14,74 +14,23 @@ Task request: `$ARGUMENTS`
 
 ## Goal
 
-Create implementation plans from the repository's documented design sources before changing source/config files when the work needs durable coordination. Treat substantial planning as a managed artifact under `docs/plan`.
+Create an implementation plan from maintained repository documentation before substantial source or configuration changes.
 
-Do not start substantial implementation until the plan has a clear evidence trail and the user has asked to execute it. Treat the written plan file as the durable review artifact for large, risky, multi-file, behavior-changing, architecture-changing, CLI/API-affecting, source/config-heavy, or resumable work. For obvious bounded work, a short in-chat checklist is enough unless the user asks for a saved plan.
-
-## Source Order
-
-Prefer live repository docs in this order:
-
-1. `AGENTS.md`, `CLAUDE.md`, `CODEX.md`, `README.md`, and `docs/README.md` for working rules and project map.
-2. `docs/spec/` for behavior, domain rules, API contracts, and acceptance criteria.
-3. `docs/test/` for verification strategy, regression cases, fixtures, and manual checks.
-4. `docs/arch/` for architecture decisions, module boundaries, integration constraints, and runtime assumptions.
-5. `docs/plan/README.md` and matching active plans under `docs/plan/`.
-6. Relevant completed plans under `docs/archive/plan/` or reports under `docs/archive/report/` only when directly useful.
+Use `docs/plan/<task-slug>/README.md` for substantial, risky, or resumable work; otherwise use a short in-chat checklist unless the user requests a saved plan.
 
 ## Workflow
 
-1. Establish current state.
-   - Check git status.
-   - Locate relevant docs and active plans.
-   - Preserve user edits and unrelated dirty worktree changes.
-   - If the session is long or noisy, suggest a user-initiated planning-focused compaction before writing or revising the plan; do not compact automatically because compaction is lossy.
-2. Gather evidence before planning.
-   - When the request contains explicit project-memory refs such as `[[PLAN_MODE]]`, run `dotdotgod expand <root> "<request>" --json` before broad `grep` or `find` scans, then read the resolved candidates selectively.
-   - When the request uses high-signal natural refs such as `PLAN_MODE`, `docs/spec/PLAN_MODE.md`, or quoted doc names, run `dotdotgod expand <root> "<request>" --fuzzy --json`; skip fuzzy expansion for generic low-signal words alone and respect configured fuzzy low-signal add/remove terms.
-   - Search docs by domain terms from the user request.
-   - Read nearest README indexes and relevant focused docs.
-   - 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.
-   - 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.
-   - 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.
-   - During planning, treat these dotdotgod commands as bounded context/status helpers: `status`, `query`, `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.
-   - Use `grep` or `find` after reference expansion, impact, and targeted reads when the task needs fallback discovery or raw source text search.
-   - Read code only after docs identify likely module boundaries, impact output points to relevant files, or docs are missing/stale.
-3. Create or update an active plan at this path when durable planning is needed:
-
-   ```text
-   docs/plan/<task-slug>/README.md
-   ```
-
-   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.
-4. For durable active plans that will be executed, keep the user-facing plan in `docs/plan/<task-slug>/README.md`. If `/plan-goal` 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.
-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`.
-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-goal` state, not a general Plan Mode requirement.
-7. When a durable plan is created, include:
-   - scope and current status
-   - target files and rationale
-   - impact-derived related files/checks when available
-   - implementation steps
-   - risks and edge cases when useful
-   - verification method
-   - current resume state when useful
-   - final housekeeping step to move completed work to `docs/archive/plan/<task-slug>/`
-   - 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
-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-goal` and manual/non-Plan-Mode workflows may still use the CLI plan-validation contract when appropriate.
-9. Update `docs/plan/README.md` if the repository keeps active plan entries there.
-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.
-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.
-12. Stop after presenting the plan unless the user explicitly asks for execution.
-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.
-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.
+1. Check for a matching active plan.
+2. Reuse loaded memory and the documentation map, then use focused query and README indexes to select maintained docs and verify conclusions in them.
+3. Inspect the source needed to confirm targets and constraints.
+4. Run impact review on likely changed files and refine targets, risks, and verification.
+5. For durable work, write and present the task README with scope, targets, executable steps, verification, and required completion gates.
+6. Resolve blocking decisions and stop until the user asks to execute the plan.
 
 ## Quality Rules
 
 - Prefer documented facts over inference; label inference explicitly.
-- Keep plans concise and maintainable.
-- Use local repository terminology and existing module names.
-- Validation steps must be executable commands or concrete review checks.
-- Avoid turning explanatory numbered lists into executable implementation plans. Use concrete action-oriented `Plan:` steps only when a real active plan artifact is being created or updated.
+- Keep plans concise, executable, and maintainable.
 
 ## Execution Rule
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dotdotgod/claude-code",
-  "version": "0.2.6",
+  "version": "0.2.8",
   "description": "Claude Code adapter for dotdotgod project memory workflows.",
   "type": "module",
   "license": "Elastic-2.0",
@@ -38,7 +38,7 @@
     "url": "https://github.com/dotdotgod/dotdotgod-kit/issues"
   },
   "scripts": {
-    "verify": "node -e \"const fs=require('fs'); const req=['.claude-plugin/plugin.json','commands/dd/load.md','commands/dd/plan.md','commands/dd/plan-goal.md','commands/dd/init.md','commands/dd/impact.md','skills/project-load/SKILL.md','skills/doc-first-planning/SKILL.md','skills/plan-goal/SKILL.md','skills/plan-goal/agents/openai.yaml','skills/project-initializer/SKILL.md','skills/impact-review/SKILL.md','skills/document-clarify/SKILL.md','skills/document-clarify/agents/openai.yaml','skills/project-initializer/scripts/init_project.sh','skills/project-initializer/templates/dotdotgod.config.json','hooks/README.md']; JSON.parse(fs.readFileSync('.claude-plugin/plugin.json','utf8')); for (const f of req) { if (!fs.existsSync(f)) throw new Error('missing '+f); } console.log('claude-code adapter ok')\"",
+    "verify": "node -e \"const fs=require('fs'); const req=['.claude-plugin/plugin.json','commands/dd/load.md','commands/dd/plan.md','commands/dd/init.md','commands/dd/impact.md','skills/project-load/SKILL.md','skills/doc-first-planning/SKILL.md','skills/project-initializer/SKILL.md','skills/impact-review/SKILL.md','skills/document-clarify/SKILL.md','skills/document-clarify/agents/openai.yaml','skills/project-initializer/scripts/init_project.sh','skills/project-initializer/templates/dotdotgod.config.json','hooks/README.md']; JSON.parse(fs.readFileSync('.claude-plugin/plugin.json','utf8')); for (const f of req) { if (!fs.existsSync(f)) throw new Error('missing '+f); } console.log('claude-code adapter ok')\"",
     "pack:dry-run": "pnpm pack --dry-run --json"
   }
 }

package/skills/doc-first-planning/SKILL.md

@@ -10,71 +10,20 @@ version: 1.0.0
 
 ## Goal
 
-Create implementation plans from the repository's documented design sources before changing source/config files when the work needs durable coordination. Treat substantial planning as a managed artifact under `docs/plan`.
+Create an implementation plan from maintained repository documentation before substantial source or configuration changes.
 
-Do not start substantial implementation until the plan has a clear evidence trail and the user has asked to execute it. Treat the written plan file as the durable review artifact for large, risky, multi-file, behavior-changing, architecture-changing, CLI/API-affecting, source/config-heavy, or resumable work. For obvious bounded work, a short in-chat checklist is enough unless the user asks for a saved plan.
-
-## Source Order
-
-Prefer live repository docs in this order:
-
-1. `AGENTS.md`, `CLAUDE.md`, `CODEX.md`, `README.md`, and `docs/README.md` for working rules and project map.
-2. `docs/spec/` for behavior, domain rules, API contracts, and acceptance criteria.
-3. `docs/test/` for verification strategy, regression cases, fixtures, and manual checks.
-4. `docs/arch/` for architecture decisions, module boundaries, integration constraints, and runtime assumptions.
-5. `docs/plan/README.md` and matching active plans under `docs/plan/`.
-6. Relevant completed plans under `docs/archive/plan/` or reports under `docs/archive/report/` only when directly useful.
+Use `docs/plan/<task-slug>/README.md` for substantial, risky, or resumable work; otherwise use a short in-chat checklist unless the user requests a saved plan.
 
 ## Workflow
 
-1. Establish current state.
-   - Check git status.
-   - Locate relevant docs and active plans.
-   - Preserve user edits and unrelated dirty worktree changes.
-   - If the session is long or noisy, suggest a user-initiated planning-focused compaction before writing or revising the plan; do not compact automatically because compaction is lossy.
-2. Gather evidence before planning.
-   - When the request contains explicit project-memory refs such as `[[PLAN_MODE]]`, run `dotdotgod expand <root> "<request>" --json` before broad `grep` or `find` scans, then read the resolved candidates selectively.
-   - When the request uses high-signal natural refs such as `PLAN_MODE`, `docs/spec/PLAN_MODE.md`, or quoted doc names, run `dotdotgod expand <root> "<request>" --fuzzy --json`; skip fuzzy expansion for generic low-signal words alone and respect configured fuzzy low-signal add/remove terms.
-   - Search docs by domain terms from the user request.
-   - Read nearest README indexes and relevant focused docs.
-   - 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.
-   - 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.
-   - 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.
-   - During planning, treat these dotdotgod commands as bounded context/status helpers: `status`, `query`, `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.
-   - Use `grep` or `find` after reference expansion, impact, and targeted reads when the task needs fallback discovery or raw source text search.
-   - Read code only after docs identify likely module boundaries, impact output points to relevant files, or docs are missing/stale.
-3. Create or update an active plan at this path when durable planning is needed:
-
-   ```text
-   docs/plan/<task-slug>/README.md
-   ```
-
-   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.
-4. For durable active plans that will be executed, keep the user-facing plan in `docs/plan/<task-slug>/README.md`. If `/plan-goal` 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.
-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`.
-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-goal` state, not a general Plan Mode requirement.
-7. When a durable plan is created, include:
-   - scope and current status
-   - target files and rationale
-   - impact-derived related files/checks when available
-   - implementation steps
-   - risks and edge cases when useful
-   - verification method
-   - current resume state when useful
-   - final housekeeping step to move completed work to `docs/archive/plan/<task-slug>/`
-   - 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
-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-goal` and manual/non-Plan-Mode workflows may still use the CLI plan-validation contract when appropriate.
-9. Update `docs/plan/README.md` if the repository keeps active plan entries there.
-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.
-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.
-12. Stop after presenting the plan unless the user explicitly asks for execution.
-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.
-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.
+1. Check for a matching active plan.
+2. Reuse loaded memory and the documentation map, then use focused query and README indexes to select maintained docs and verify conclusions in them.
+3. Inspect the source needed to confirm targets and constraints.
+4. Run impact review on likely changed files and refine targets, risks, and verification.
+5. For durable work, write and present the task README with scope, targets, executable steps, verification, and required completion gates.
+6. Resolve blocking decisions and stop until the user asks to execute the plan.
 
 ## Quality Rules
 
 - Prefer documented facts over inference; label inference explicitly.
-- Keep plans concise and maintainable.
-- Use local repository terminology and existing module names.
-- Validation steps must be executable commands or concrete review checks.
-- Avoid turning explanatory numbered lists into executable implementation plans. Use concrete action-oriented `Plan:` steps only when a real active plan artifact is being created or updated.
+- Keep plans concise, executable, and maintainable.

package/skills/project-initializer/SKILL.md

@@ -8,56 +8,13 @@ version: 1.0.0
 
 # Project Initializer
 
-## Overview
+## Goal
 
-Create a conservative dotdotgod project baseline shared by AI coding agents:
-
-- `AGENTS.md` is the canonical project instruction file.
-- `CLAUDE.md` and `CODEX.md` are thin agent-specific entrypoints.
-- `docs/` contains concise indexes for specs, tests, architecture, active plans, and archives.
-- `dotdotgod.config.json` materializes the complete editable default project policy.
-- `.gitignore` keeps `docs/plan`, `docs/archive`, and `.dotdotgod` local by default.
-
-Under `docs/`, directories use kebab-case and markdown file names use UPPER_SNAKE_CASE, including `README.md`.
-
-## CLI and Fallback
-
-Prefer the CLI initializer:
-
-```bash
-dotdotgod init <project-root>
-```
-
-Use the bundled fallback when the CLI is unavailable:
-
-```bash
-sh "${CLAUDE_PLUGIN_ROOT}/skills/project-initializer/scripts/init_project.sh" <project-root>
-```
-
-Both paths create the same baseline file set and canonical config while preserving existing files. Use `--dry-run` for unfamiliar repositories and `--dotdot-setting` for the optional documentation and code-convention guidance.
+Create a non-destructive dotdotgod baseline with canonical agent instructions, thin agent entrypoints, documentation indexes, project config, and local-memory ignore rules.
 
 ## Workflow
 
-1. Inspect the project root.
-   - Check `AGENTS.md`, `AGENT.md`, `CLAUDE.md`, `CODEX.md`, `README.md`, `.gitignore`, `docs/`, and `dotdotgod.config.json`.
-   - Preserve project-specific instructions and unrelated user work.
-   - Keep `AGENTS.md` canonical when both `AGENT.md` and `AGENTS.md` exist.
-2. Run the initializer.
-   - Use the CLI when available; otherwise use the bundled fallback.
-   - Existing files are always preserved and skipped.
-3. Review and validate.
-   - Fill project-specific placeholders in `AGENTS.md` when the required context is known.
-   - Keep `CLAUDE.md` and `CODEX.md` thin.
-   - Preserve the generated complete memory-area set; do not replace it with a partial hand-written list.
-   - Run `dotdotgod validate <project-root>` after creating or changing config when the CLI is available.
-   - Inspect `dotdotgod config <project-root> --json` when validation fails or resolved policy needs review.
-4. Report the result.
-   - List created, updated, and skipped files, plus validation failures.
-   - Report when CLI validation was unavailable.
-   - Identify existing instructions that still require manual consolidation.
-
-## Bundled Resources
-
-- `scripts/init_project.sh`: POSIX fallback initializer.
-- `templates/dotdotgod.config.json`: generated canonical config template used by the fallback.
-- `references/agent-docs.md`: shared agent-document naming and content model.
+1. Inspect existing agent instructions, documentation, config, and ignore rules; preserve existing files and unrelated user work.
+2. Run `dotdotgod init <project-root>` when available; otherwise run `sh "${CLAUDE_PLUGIN_ROOT}/skills/project-initializer/scripts/init_project.sh" <project-root>`. Existing files must be skipped, not replaced.
+3. Validate the initialized project with `dotdotgod validate <project-root>` when available.
+4. Report created and skipped files, validation failures, and unresolved instruction conflicts.

package/skills/project-load/SKILL.md

@@ -10,46 +10,16 @@ version: 1.0.0
 
 ## Goal
 
-Load the current repository's dotdotgod project memory without modifying source, documentation, or project config. A focused query may refresh ignored `.dotdotgod/vectors/` data and the runtime's user-level model cache. Use a full load for an explicit project overview and a compact load to refresh an already-loaded session. Treat free-form arguments as query text, not as mode switches.
+Load the repository's dotdotgod project memory without modifying maintained files. Treat free-form arguments as query text, not mode switches.
 
 ## Workflow
 
-1. Identify the repository root and current state.
-   - Check the current directory and, when Git is available, the repository root, branch, and dirty worktree status.
-   - Mention user changes and avoid reverting or cleaning them.
-2. Read baseline memory only when it is not already clear from loaded context.
-   - Start with `AGENTS.md`, the current adapter entrypoint when present, `README.md`, and `docs/README.md`.
-   - Do not run scaffold, config-writing, or source-modifying commands during a load.
-3. Build the shared documentation map.
-   - Discover Markdown files under `docs/` after applying `load.documentationSummary.exclude`, which excludes `docs/plan` and `docs/archive` by default.
-   - Render repository-relative paths as a prefix-compressed tree. Count `docs/` as directory depth 1.
-   - Without arguments, expand through directory depth 5. At the boundary, summarize deeper descendants with exact directory and Markdown-file counts.
-4. Use query routing only when arguments are present.
-   - Run `dotdotgod query <root> "<arguments>" --limit 30 --json` when the command is available.
-   - Show the best-ranked chunk from each of at most 30 distinct Markdown files and render the documentation tree through directory depth 3.
-   - If query is unavailable, continue from the tree, README indexes, and targeted reads.
-5. Read document bodies selectively.
-   - Follow README indexes as maintained tables of contents.
-   - Prefer query results, explicit paths, and the current request before broader search.
-   - Use `grep` or `find` only when targeted reads do not provide enough evidence.
-6. Read local memory only when relevant.
-   - For active plans, list `docs/plan` entries first and read only relevant plan files.
-   - Use `docs/archive/README.md` as the history map. Do not scan archive bodies by default.
-7. Avoid broad reads of generated outputs, dependencies, databases, caches, secrets, and `.env*` contents.
-
-## Output Shape
-
-For a full load, respond concisely with:
-
-- Project narrative and purpose
-- Key working rules
-- Relevant documentation and verification routes
-- Relevant active plans or archive history only when needed
-- Questions surfaced by loaded material
-
-For a compact load, respond with:
-
-- Compact project-memory status
-- Relevant documentation routes
-- Relevant active plan hints only when needed
-- A short bounded list of next reads, or a note that none are needed
+1. Identify the repository root.
+2. When baseline context is missing, read `AGENTS.md`, the adapter entrypoint, `README.md`, and `docs/README.md` when present.
+3. Build a prefix-compressed tree of `docs/**/*.md` after `load.documentationSummary.exclude`. Count `docs/` as depth 1; without arguments, expand through depth 5 and summarize deeper descendants with exact directory and Markdown-file counts.
+4. With arguments, run `dotdotgod query <root> "<arguments>" --limit 30 --json` when available, return at most 30 distinct Markdown files, and render the tree through depth 3. Fall back to the tree and README indexes when query is unavailable.
+5. Read bodies selectively from query results, explicit paths, and README indexes. Read relevant active plans only when needed, use `docs/archive/README.md` as the history map, and avoid broad generated, dependency, cache, or secret reads.
+
+## Output
+
+Report the project purpose, key rules, relevant documentation routes, and only the active-plan or next-read hints needed for the request. Keep compact loads to a brief refresh.

package/commands/dd/plan-goal.md

@@ -1,173 +0,0 @@
----
-description: Create a durable staged plan using dotdotgod 5-stage pipeline
-argument-hint: <task or change request>
-allowed-tools: [Read, Glob, Grep, Bash, Write, Edit]
----
-
-<!-- Generated from packages/shared resources by scripts/generate-adapters.mjs. Do not edit this file directly; edit the shared source and run `pnpm run generate`. -->
-
-# /dd:plan-goal - Staged Planning
-
-Run the dotdotgod 5-stage planning pipeline.
-
-Task request: `$ARGUMENTS`
-
-## Goal
-
-Create a durable staged plan using the dotdotgod 5-stage pipeline before changing source or config files. Each stage produces a checkpoint file under `.dotdotgod-plan/` and updates the durable plan artifact at `docs/plan/<task>/README.md`.
-
-Tip: set `/goal "docs/plan/<task>/.dotdotgod-plan/05_WORKSTREAM_HANDOFF.md Status: completed"` before running this command to let Claude track completion automatically across turns. Omit `/goal` when you want to review and approve each stage manually.
-
-## Pipeline Overview
-
-| Stage | ID | Checkpoint | Required Sections |
-|-------|----|------------|------------------|
-| Intake | `01-intake` | `01_INTAKE.md` | Request Summary, Goal, Scope, Non-goals, Constraints, Assumptions |
-| Context Load | `02-context-load` | `02_CONTEXT_LOAD.md` | Memory Reads, Impact Candidates, Related Files |
-| Discovery | `03-discovery` | `03_DISCOVERY.md` | Findings, Risks, Open Questions |
-| Plan | `04-plan` | `04_PLAN.md` | Implementation Design, Code Touchpoints, Data/State Flow, Edge Cases, Atomic Tasks, Test Design, Validation Plan, Resume Point |
-| Workstream Handoff | `05-workstream-handoff` | `05_WORKSTREAM_HANDOFF.md` | Workstream Handoff, Workstream Map, Shared Context, Workstreams, Integration Sequence, Todo Contract |
-
-## Checkpoint Format
-
-Write each checkpoint to `docs/plan/<task>/.dotdotgod-plan/NN_STAGE_NAME.md`:
-
-```
-Stage: <stage-id>
-Status: completed
-Updated: <ISO timestamp>
-
-## <Required Section 1>
-[content]
-
-## Stage 0N Construction Checklist
-- [x] Category: evidence
-- [x] Category: evidence description
-```
-
-Use `Status: blocked` when a user decision blocks the stage. Use only canonical checklist rows: `- [x] Category: evidence`. Do not use tables, `completed - [x]`, or `Category: completed - [x]` shorthand.
-
-## Resume Logic
-
-When the argument is a task path such as `docs/plan/<task>/README.md` or a task slug:
-
-1. Resolve the README path from the argument.
-2. Scan `.dotdotgod-plan/` for existing checkpoint files.
-3. Reverse-scan to find the last checkpoint where `Status:` is not `completed`.
-4. Resume from that stage. If all checkpoints show `Status: completed`, report the plan as already complete and stop.
-5. If no checkpoints exist, start from Stage 01.
-6. Load the found checkpoint content as stage context before generating the next stage message.
-
-## Stage Instructions
-
-### Stage 01: Intake
-
-Create the initial planning context for the durable plan request.
-
-Include in the durable plan and checkpoint:
-- **Request Summary** — restate the user's request in your own words.
-- **Goal** — the intended durable plan goal.
-- **Scope** — what is in scope.
-- **Non-goals** — what is explicitly out of scope.
-- **Constraints** — known constraints and guardrails.
-- **Assumptions** — assumptions made where information is incomplete.
-
-Construction checklist categories: Requirements, Constraints, Failure paths, Data shape, Verification, Integration impact.
-
-Do not edit source code. Do not advance beyond Stage 01.
-
-### Stage 02: Context Load
-
-Use the Stage 01 context, then update the durable plan artifact and checkpoint.
-
-Include in the durable plan and checkpoint:
-- **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.
-- **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.
-- **Related Files** — source, config, and doc files identified as relevant.
-
-Construction checklist categories: Memory reads, Impact candidates, Related files, Boundary risk.
-
-Do not edit source code. Do not advance beyond Stage 02.
-
-### Stage 03: Discovery
-
-Use the Stage 02 context, then update the durable plan artifact and checkpoint with actual findings from inspected code and docs — not just a list of files to inspect.
-
-Include in the durable plan and checkpoint:
-- **Findings** — concrete observations from reading source, config, and docs.
-- **Risks** — identified risks and failure paths.
-- **Open Questions** — research gaps the agent can resolve by reading project context. Do not silently carry unresolved user decisions forward. If a missing choice requires the user to decide scope, behavior, product policy, risk acceptance, or implementation direction, stop and ask the user a concrete question with options. Record machine-readable blockers with `DecisionOwner: user` and `DecisionState: unresolved`, or `BlockerType: user-decision` and `Status: blocked`. Do not use prose keywords such as "TBD" or "undecided" as machine-readable state.
-
-Construction checklist categories: Findings, Risks, Open questions, Extension points.
-
-Do not edit source code. Do not advance beyond Stage 03.
-
-### Stage 04: Plan
-
-Use the Stage 03 context, then update the durable plan artifact and checkpoint with an implementation design — not a generic project plan.
-
-Include in the durable plan and checkpoint:
-- **Implementation Design** — design overview.
-- **Code Touchpoints** — exact files, functions, types, classes, and commands to change.
-- **Data/State Flow** — how data and state change through the implementation.
-- **Edge Cases** — failure paths, empty/missing data, invalid input, interrupted/resumed state, idempotency, retry behavior, and integration boundaries.
-- **Atomic Tasks** — each task must name concrete code touchpoints; no vague verbs such as "update logic" without a named target. A different agent must be able to implement the task without this chat history.
-- **Test Design** — unit, integration, or E2E tests for each atomic task.
-- **Validation Plan** — verification commands and review checks.
-- **Resume Point** — current resume state for long-running tasks.
-
-When the implementation design has multiple independent parts, split the durable plan into task-local support markdown files under `docs/plan/<task>/`. Keep `README.md` as the overview/index, and link each support file with a one-line purpose. Use support files for implementation-part detail such as CLI changes, extension or runtime changes, tests, docs, migration, or rollout. Do not put final user-facing plan content only in `.dotdotgod-plan/`.
-
-Apply `dotdotgod graph impact` evidence from Stage 02 to strengthen Code Touchpoints, Edge Cases, and Validation Plan. For Claude Code and Codex plans, include a concrete `dd:impact` or `impact-review` step before broad verification or final handoff when source, config, or docs files will change.
-
-Do not silently carry unresolved user decisions forward. Stop and ask if scope, behavior, risk acceptance, or implementation direction is missing.
-
-Construction checklist categories: Implementation design, Code touchpoints, Data/State flow, Edge cases, Atomic tasks, Test design, Validation plan, Resume point.
-
-Do not edit source code. Do not advance beyond Stage 04.
-
-### Stage 05: Workstream Handoff
-
-Use the Stage 04 context, then update the durable plan artifact and checkpoint with a phase-based, subagent-ready Workstream Handoff Contract.
-
-Include in the durable plan and checkpoint:
-- **Workstream Handoff** — state `Split decision: yes` or `Split decision: no`. When no split is needed, include `No-split rationale:` and a concrete Todo Contract as the implementation handoff contract.
-- **Workstream Map** — when split is needed: at least two `Workstream ID:` entries, each with owner or role, exact primary handoff file, target files and functions, dependencies, and whether it can run in parallel. Include an execution phase map with phase names, dependency gates, sequencing constraints, and parallelization notes.
-- **Shared Context** — everything every downstream agent needs to work without this chat history.
-- **Workstreams** — per-workstream contracts with structured fields: `Workstream ID:`, `Purpose:`, `Required context:`, `Allowed edits:`, `Forbidden edits:`, `Tasks:`, `Validation:`, `Handoff output:`, `Dependencies:`. Each split-workstream subagent must receive exactly one primary handoff file and be able to work from that file alone. Each primary handoff file must include role, phase, dependency gates, summarized context, exact target files and functions, allowed edits, forbidden edits, tasks, validation, expected handoff output, dependencies, and integration notes. Use UPPER_SNAKE_CASE markdown files under the task directory and README index links for large split contracts.
-- **Integration Sequence** — how to combine workstream outputs after phase gates pass: `Step:`, `Validation:`, `Handoff:`.
-- **Todo Contract** — aggregated implementation todos across workstreams and phases.
-
-The `.dotdotgod-plan/05_WORKSTREAM_HANDOFF.md` file is internal stage state context and validation evidence. Write final user-facing handoff instructions to `README.md` or task-local support files outside `.dotdotgod-plan/`.
-
-Construction checklist categories: Handoffs, Do-not rules, Focused verification, Chat-independent context.
-
-Do not edit source code. Do not advance beyond Stage 05.
-
-## Stage Evaluation
-
-After writing each stage output, self-evaluate before advancing:
-
-- **pass** — the durable plan artifact has enough human-readable content and the matching checkpoint has all required sections, a completed construction checklist, and no unresolved user decisions. Advance to the next stage.
-- **retry** — the output is repairable without user input. Rewrite the stage (maximum 5 retries). Repair the durable plan artifact as well as the checkpoint.
-- **blocked** — a user decision about scope, behavior, risk acceptance, or implementation direction is required. Stop, surface the concrete question with options, and wait for user input before proceeding. Do not pass a stage that records unresolved choices as "TBD" or "undecided".
-
-## Completion: Document Clarify
-
-After Stage 05 passes, run a final `document-clarify` pass before implementation:
-
-- Use the `document-clarify` skill.
-- Clarify `docs/plan/<task>/README.md` and any task-local support or workstream handoff markdown files referenced by that README.
-- Preserve scope, user decisions, validation requirements, workstream dependencies, Todo Contract, and handoff contracts.
-- Do not execute implementation work. Do not edit source or config files.
-- Treat `docs/plan/<task>/.dotdotgod-plan/*.md` files as internal checkpoint state and validation evidence, not user-facing documentation to polish.
-- Do not weaken acceptance criteria, verification commands, do-not rules, or blocker descriptions.
-- Stop after reporting the clarified plan path and any remaining blockers.
-
-## Quality Rules
-
-- Prefer documented facts over inference; label inference explicitly.
-- Checkpoint files are internal validation evidence; final plan content belongs in `README.md` or task-local support files.
-- Validation steps must be executable commands or concrete review checks.
-- Do not silently carry unresolved user decisions across stages.
-- Do not begin source or config implementation until the user explicitly asks to execute the plan.

package/skills/plan-goal/SKILL.md

@@ -1,169 +0,0 @@
----
-name: plan-goal
-description: Use this skill when the user asks Claude Code to run a staged planning pipeline, create a durable plan with checkpoint files, or use dotdotgod plan-goal stages (intake, context-load, discovery, plan, workstream-handoff); when dd:plan-goal or staged planning is mentioned.
-version: 1.0.0
----
-
-<!-- Generated from packages/shared resources by scripts/generate-adapters.mjs. Do not edit this file directly; edit the shared source and run `pnpm run generate`. -->
-
-# Staged Planning
-
-## Goal
-
-Create a durable staged plan using the dotdotgod 5-stage pipeline before changing source or config files. Each stage produces a checkpoint file under `.dotdotgod-plan/` and updates the durable plan artifact at `docs/plan/<task>/README.md`.
-
-Tip: set `/goal "docs/plan/<task>/.dotdotgod-plan/05_WORKSTREAM_HANDOFF.md Status: completed"` before running this command to let Claude track completion automatically across turns. Omit `/goal` when you want to review and approve each stage manually.
-
-## Pipeline Overview
-
-| Stage | ID | Checkpoint | Required Sections |
-|-------|----|------------|------------------|
-| Intake | `01-intake` | `01_INTAKE.md` | Request Summary, Goal, Scope, Non-goals, Constraints, Assumptions |
-| Context Load | `02-context-load` | `02_CONTEXT_LOAD.md` | Memory Reads, Impact Candidates, Related Files |
-| Discovery | `03-discovery` | `03_DISCOVERY.md` | Findings, Risks, Open Questions |
-| Plan | `04-plan` | `04_PLAN.md` | Implementation Design, Code Touchpoints, Data/State Flow, Edge Cases, Atomic Tasks, Test Design, Validation Plan, Resume Point |
-| Workstream Handoff | `05-workstream-handoff` | `05_WORKSTREAM_HANDOFF.md` | Workstream Handoff, Workstream Map, Shared Context, Workstreams, Integration Sequence, Todo Contract |
-
-## Checkpoint Format
-
-Write each checkpoint to `docs/plan/<task>/.dotdotgod-plan/NN_STAGE_NAME.md`:
-
-```
-Stage: <stage-id>
-Status: completed
-Updated: <ISO timestamp>
-
-## <Required Section 1>
-[content]
-
-## Stage 0N Construction Checklist
-- [x] Category: evidence
-- [x] Category: evidence description
-```
-
-Use `Status: blocked` when a user decision blocks the stage. Use only canonical checklist rows: `- [x] Category: evidence`. Do not use tables, `completed - [x]`, or `Category: completed - [x]` shorthand.
-
-## Resume Logic
-
-When the argument is a task path such as `docs/plan/<task>/README.md` or a task slug:
-
-1. Resolve the README path from the argument.
-2. Scan `.dotdotgod-plan/` for existing checkpoint files.
-3. Reverse-scan to find the last checkpoint where `Status:` is not `completed`.
-4. Resume from that stage. If all checkpoints show `Status: completed`, report the plan as already complete and stop.
-5. If no checkpoints exist, start from Stage 01.
-6. Load the found checkpoint content as stage context before generating the next stage message.
-
-## Stage Instructions
-
-### Stage 01: Intake
-
-Create the initial planning context for the durable plan request.
-
-Include in the durable plan and checkpoint:
-- **Request Summary** — restate the user's request in your own words.
-- **Goal** — the intended durable plan goal.
-- **Scope** — what is in scope.
-- **Non-goals** — what is explicitly out of scope.
-- **Constraints** — known constraints and guardrails.
-- **Assumptions** — assumptions made where information is incomplete.
-
-Construction checklist categories: Requirements, Constraints, Failure paths, Data shape, Verification, Integration impact.
-
-Do not edit source code. Do not advance beyond Stage 01.
-
-### Stage 02: Context Load
-
-Use the Stage 01 context, then update the durable plan artifact and checkpoint.
-
-Include in the durable plan and checkpoint:
-- **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.
-- **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.
-- **Related Files** — source, config, and doc files identified as relevant.
-
-Construction checklist categories: Memory reads, Impact candidates, Related files, Boundary risk.
-
-Do not edit source code. Do not advance beyond Stage 02.
-
-### Stage 03: Discovery
-
-Use the Stage 02 context, then update the durable plan artifact and checkpoint with actual findings from inspected code and docs — not just a list of files to inspect.
-
-Include in the durable plan and checkpoint:
-- **Findings** — concrete observations from reading source, config, and docs.
-- **Risks** — identified risks and failure paths.
-- **Open Questions** — research gaps the agent can resolve by reading project context. Do not silently carry unresolved user decisions forward. If a missing choice requires the user to decide scope, behavior, product policy, risk acceptance, or implementation direction, stop and ask the user a concrete question with options. Record machine-readable blockers with `DecisionOwner: user` and `DecisionState: unresolved`, or `BlockerType: user-decision` and `Status: blocked`. Do not use prose keywords such as "TBD" or "undecided" as machine-readable state.
-
-Construction checklist categories: Findings, Risks, Open questions, Extension points.
-
-Do not edit source code. Do not advance beyond Stage 03.
-
-### Stage 04: Plan
-
-Use the Stage 03 context, then update the durable plan artifact and checkpoint with an implementation design — not a generic project plan.
-
-Include in the durable plan and checkpoint:
-- **Implementation Design** — design overview.
-- **Code Touchpoints** — exact files, functions, types, classes, and commands to change.
-- **Data/State Flow** — how data and state change through the implementation.
-- **Edge Cases** — failure paths, empty/missing data, invalid input, interrupted/resumed state, idempotency, retry behavior, and integration boundaries.
-- **Atomic Tasks** — each task must name concrete code touchpoints; no vague verbs such as "update logic" without a named target. A different agent must be able to implement the task without this chat history.
-- **Test Design** — unit, integration, or E2E tests for each atomic task.
-- **Validation Plan** — verification commands and review checks.
-- **Resume Point** — current resume state for long-running tasks.
-
-When the implementation design has multiple independent parts, split the durable plan into task-local support markdown files under `docs/plan/<task>/`. Keep `README.md` as the overview/index, and link each support file with a one-line purpose. Use support files for implementation-part detail such as CLI changes, extension or runtime changes, tests, docs, migration, or rollout. Do not put final user-facing plan content only in `.dotdotgod-plan/`.
-
-Apply `dotdotgod graph impact` evidence from Stage 02 to strengthen Code Touchpoints, Edge Cases, and Validation Plan. For Claude Code and Codex plans, include a concrete `dd:impact` or `impact-review` step before broad verification or final handoff when source, config, or docs files will change.
-
-Do not silently carry unresolved user decisions forward. Stop and ask if scope, behavior, risk acceptance, or implementation direction is missing.
-
-Construction checklist categories: Implementation design, Code touchpoints, Data/State flow, Edge cases, Atomic tasks, Test design, Validation plan, Resume point.
-
-Do not edit source code. Do not advance beyond Stage 04.
-
-### Stage 05: Workstream Handoff
-
-Use the Stage 04 context, then update the durable plan artifact and checkpoint with a phase-based, subagent-ready Workstream Handoff Contract.
-
-Include in the durable plan and checkpoint:
-- **Workstream Handoff** — state `Split decision: yes` or `Split decision: no`. When no split is needed, include `No-split rationale:` and a concrete Todo Contract as the implementation handoff contract.
-- **Workstream Map** — when split is needed: at least two `Workstream ID:` entries, each with owner or role, exact primary handoff file, target files and functions, dependencies, and whether it can run in parallel. Include an execution phase map with phase names, dependency gates, sequencing constraints, and parallelization notes.
-- **Shared Context** — everything every downstream agent needs to work without this chat history.
-- **Workstreams** — per-workstream contracts with structured fields: `Workstream ID:`, `Purpose:`, `Required context:`, `Allowed edits:`, `Forbidden edits:`, `Tasks:`, `Validation:`, `Handoff output:`, `Dependencies:`. Each split-workstream subagent must receive exactly one primary handoff file and be able to work from that file alone. Each primary handoff file must include role, phase, dependency gates, summarized context, exact target files and functions, allowed edits, forbidden edits, tasks, validation, expected handoff output, dependencies, and integration notes. Use UPPER_SNAKE_CASE markdown files under the task directory and README index links for large split contracts.
-- **Integration Sequence** — how to combine workstream outputs after phase gates pass: `Step:`, `Validation:`, `Handoff:`.
-- **Todo Contract** — aggregated implementation todos across workstreams and phases.
-
-The `.dotdotgod-plan/05_WORKSTREAM_HANDOFF.md` file is internal stage state context and validation evidence. Write final user-facing handoff instructions to `README.md` or task-local support files outside `.dotdotgod-plan/`.
-
-Construction checklist categories: Handoffs, Do-not rules, Focused verification, Chat-independent context.
-
-Do not edit source code. Do not advance beyond Stage 05.
-
-## Stage Evaluation
-
-After writing each stage output, self-evaluate before advancing:
-
-- **pass** — the durable plan artifact has enough human-readable content and the matching checkpoint has all required sections, a completed construction checklist, and no unresolved user decisions. Advance to the next stage.
-- **retry** — the output is repairable without user input. Rewrite the stage (maximum 5 retries). Repair the durable plan artifact as well as the checkpoint.
-- **blocked** — a user decision about scope, behavior, risk acceptance, or implementation direction is required. Stop, surface the concrete question with options, and wait for user input before proceeding. Do not pass a stage that records unresolved choices as "TBD" or "undecided".
-
-## Completion: Document Clarify
-
-After Stage 05 passes, run a final `document-clarify` pass before implementation:
-
-- Use the `document-clarify` skill.
-- Clarify `docs/plan/<task>/README.md` and any task-local support or workstream handoff markdown files referenced by that README.
-- Preserve scope, user decisions, validation requirements, workstream dependencies, Todo Contract, and handoff contracts.
-- Do not execute implementation work. Do not edit source or config files.
-- Treat `docs/plan/<task>/.dotdotgod-plan/*.md` files as internal checkpoint state and validation evidence, not user-facing documentation to polish.
-- Do not weaken acceptance criteria, verification commands, do-not rules, or blocker descriptions.
-- Stop after reporting the clarified plan path and any remaining blockers.
-
-## Quality Rules
-
-- Prefer documented facts over inference; label inference explicitly.
-- Checkpoint files are internal validation evidence; final plan content belongs in `README.md` or task-local support files.
-- Validation steps must be executable commands or concrete review checks.
-- Do not silently carry unresolved user decisions across stages.
-- Do not begin source or config implementation until the user explicitly asks to execute the plan.

package/skills/plan-goal/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Staged Planning"
-  short_description: "Run dotdotgod 5-stage planning pipeline."
-  default_prompt: "Run plan-goal staged planning: intake, context-load, discovery, plan, workstream-handoff."