@dotdotgod/claude-code 0.2.14 → 0.2.17

package/README.md

@@ -61,7 +61,7 @@ By default, `docs/spec/**` has two separate roles:
 - It is stable shared project memory for product behavior and requirements.
 - It is the traceability-enforced path for behavior specs.
 
-Projects can customize memory roles with `memory.areas`, and can customize traceability requirements with `traceability.required` and `traceability.exclude`.
+Projects can customize memory roles with `memory.areas`, select traceability-enforced Markdown with `traceability.required` and `traceability.exclude`, and define the ordered complete list of traceability string arrays with `traceability.keys`. Each key owns its label, path or command target, graph relation, and PPR weight.
 
 ## Optional Hooks
 

package/commands/dd/impact.md

@@ -14,34 +14,21 @@ Optional focus: `$ARGUMENTS`
 
 ## Goal
 
-Review source/config/documentation changes with dotdotgod impact data before broad verification, commits, pushes, publishing, or final handoff.
-
-This workflow is the Claude Code and Codex counterpart to Pi's `/impact-check` reminder. It is advisory unless the active agent runtime or a project-local trusted hook adds stricter enforcement.
+Review task-relevant source, config, and documentation changes with dotdotgod impact evidence before broad verification, commits, pushes, publishing, or final handoff. Claude Code and Codex use this advisory workflow; trusted runtime or project hooks may enforce a stricter boundary.
 
 ## Workflow
 
-1. Establish the changed-file set.
-   - Check git status and preserve unrelated user edits.
-   - Include unstaged, staged, and untracked source/config/docs files that are relevant to the current task.
-   - Exclude dependencies, generated caches, build artifacts, secrets, and unrelated local-memory files unless the user explicitly asks about them.
-2. Prefer bounded multi-seed graph impact.
-   - 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`.
-   - 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.
-   - 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`.
-   - If the CLI is unavailable, continue with README indexes, traceability blocks, package metadata, and targeted grep/find fallback.
-3. Inspect impact output selectively.
-   - 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.
-   - When behavior specs appear through `implemented_by`, `verified_by`, or `related_doc`, read those docs before broad verification.
-   - Do not paste large raw impact JSON into the response unless the user asks for diagnostics.
-4. Repair or update related docs/tests when the impact output shows stale, missing, or contradictory project memory.
-5. Choose verification from evidence.
-   - Prefer focused package tests, docs validation, generated-resource checks, and package dry-runs that match the changed files.
-   - For docs changes in dotdotgod projects, run `dotdotgod validate . --include-local-memory` and use `--check-index` when index freshness matters.
-6. Summarize the result.
-   - List changed files reviewed.
-   - List the most relevant impacted docs/tests/files and any follow-up action.
-   - List verification commands run or explain why verification was skipped.
-
-## Hook Boundary
-
-Optional hooks may remind agents to run this workflow after edits or before stop time, but default package resources must not auto-run full workspace verification, rebuild indexes, initialize scaffolds, move plans to archives, or block every write without a tested plan-only state signal.
+1. Build the changed-file set from Git status. Preserve unrelated user work and exclude dependencies, caches, build output, secrets, and unrelated local memory.
+2. Run one bounded multi-seed impact command for up to 20 unique paths in first-seen order:
+
+   ```bash
+   dotdotgod graph impact <root> --changed <path-a> --changed <path-b> --compact
+   ```
+
+   Use `--yml` when structured detail helps. Split larger sets into ordered batches of 20. In a source checkout, use `node packages/cli/bin/dotdotgod.mjs graph impact`; when the CLI is unavailable, follow README indexes, traceability, package metadata, and focused file search.
+3. Review the combined ranking and each seed's non-seed top results. Prioritize high-signal specs, tests, architecture, and source links, especially `implemented_by`, `verified_by`, and `related_doc` relationships.
+4. Resolve stale or contradictory related docs and tests that belong to the current task.
+5. Select focused tests, documentation validation, generated-resource checks, and package dry-runs from the evidence. For dotdotgod documentation changes, run `dotdotgod validate . --include-local-memory` and add `--check-index` when index freshness matters.
+6. Report the changed files reviewed, the strongest related findings and follow-up actions, and verification completed or skipped.
+
+Keep raw impact payloads out of normal summaries. Optional hooks may remind agents about this workflow; default package resources leave full verification, index rebuilds, initialization, archive moves, and write blocking under explicit workflow control.

package/commands/dd/load.md

@@ -12,6 +12,10 @@ Load project memory without modifying source, documentation, or project config;
 
 User focus, if provided: `$ARGUMENTS`
 
+## CLI Context
+
+Run `dotdotgod config <root> --json` and apply `config.load.documentationSummary.exclude` before building the documentation tree. With focus text, run `dotdotgod query <root> "<focus>" --limit 30 --json`. If the CLI is unavailable, continue from the documentation tree and README indexes.
+
 ## Goal
 
 Load the repository's dotdotgod project memory without modifying maintained files. Treat free-form arguments as query text, not mode switches.
@@ -21,7 +25,7 @@ Load the repository's dotdotgod project memory without modifying maintained file
 1. Identify the repository root. Expose `Help: dotdotgod --help` as optional CLI discovery guidance without checking or reporting installation status, and do not require Help execution for Load to continue.
 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. At the boundary, list every direct Markdown file and immediate child directory regardless of item count, then summarize hidden descendants separately under each named child with exact recursive 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 with the same named boundary-child summaries. Fall back to the tree and README indexes when query is unavailable.
+4. With arguments, use focused query results to return at most 30 distinct Markdown files and render the tree through depth 3 with the same named boundary-child summaries.
 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

package/commands/dd/plan.md

@@ -12,6 +12,10 @@ Create or update a dotdotgod implementation plan before changing source/config f
 
 Task request: `$ARGUMENTS`
 
+## CLI Context
+
+For focused documentation routing, run `dotdotgod query <root> "<focus>" --limit 30 --json`. Run `dotdotgod config <root> --json` when memory-area policy, documentation exclusions, or Plan Mode writable paths affect the plan. If the CLI is unavailable, continue from README indexes and focused file reads.
+
 ## Goal
 
 Create an implementation plan from maintained repository documentation before substantial source or configuration changes.
@@ -34,4 +38,4 @@ Use `docs/plan/<task-slug>/README.md` for substantial, risky, or resumable work;
 
 ## Execution Rule
 
-Do not implement source/config changes until the plan is clear and the user asks to proceed.
+Begin source/config implementation after the plan is clear and the user asks to proceed.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dotdotgod/claude-code",
-  "version": "0.2.14",
+  "version": "0.2.17",
   "description": "Claude Code adapter for dotdotgod project memory workflows.",
   "type": "module",
   "license": "Elastic-2.0",

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

@@ -8,6 +8,10 @@ version: 1.0.0
 
 # Doc-First Planning
 
+## CLI Context
+
+For focused documentation routing, run `dotdotgod query <root> "<focus>" --limit 30 --json`. Run `dotdotgod config <root> --json` when memory-area policy, documentation exclusions, or Plan Mode writable paths affect the plan. If the CLI is unavailable, continue from README indexes and focused file reads.
+
 ## Goal
 
 Create an implementation plan from maintained repository documentation before substantial source or configuration changes.

package/skills/doc-first-planning/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Doc-First Planning"
   short_description: "Plan work from dotdotgod docs first."
-  default_prompt: "Plan this change from AGENTS.md, docs/spec, docs/test, docs/arch, and docs/plan before implementation."
+  default_prompt: "Plan this change from maintained project evidence and create a durable task plan when the work warrants one."

package/skills/document-clarify/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: document-clarify
-description: Use this skill when Claude Code should clarify project documentation using dotdotgod memory-area metadata, default document roles, and docs-as-code clarity rules; when README indexes, docs/spec, docs/test, docs/arch, docs/plan, docs/archive, or project-specific docs need clearer wording without changing behavior contracts.
+description: Use this skill when Claude Code should clarify project documentation using resolved dotdotgod memory-area guidance and direct, concise prose; when README indexes or project-specific docs need clearer wording while preserving established meaning and traceability.
 version: 1.0.0
 ---
 
@@ -8,110 +8,22 @@ version: 1.0.0
 
 # Document Clarify
 
-## Goal
-
-Improve project documentation clarity without changing the document's role, behavior contract, traceability semantics, or project-specific memory intent.
-
-Use this workflow for README indexes, specs, test docs, architecture docs, active plans, archive maps, and custom documentation areas configured through dotdotgod memory-area policy.
-
-## Source Order
-
-Prefer live repository context in this order:
-
-1. The user's target file or requested documentation area.
-2. Relevant documentation from `dotdotgod query <root> "<focus>" --json` when semantic routing is useful.
-3. Resolved config from `dotdotgod config <root> --json` when memory-area or documentation-map policy is needed.
-4. The nearest README index, especially `docs/README.md` and the local area `README.md`.
-5. Directly linked specs, tests, architecture notes, commands, and traceability targets needed to preserve meaning.
-6. `docs/archive/README.md` as the history map; read archive bodies only when the current clarification task needs a targeted past decision.
-
-If the CLI is unavailable, continue from README indexes, path conventions, and traceability blocks.
-
-## Resolve the Document Role
-
-Before editing, decide what job the document is supposed to do.
-
-For configured memory areas, apply guidance in this order:
-
-1. Matched area's `clarify` guidance:
-   - `audience`: who must understand the document.
-   - `documentType`: recommended type such as index, tutorial, how-to, reference, explanation, spec, test strategy, architecture note, runbook, plan, archive map, or archive body.
-   - `clarityGoal`: the north star for edits.
-   - `editRules`: local constraints that must be preserved.
-2. Matched area's `description`, `label`, and `role`.
-3. Default dotdotgod roles:
-   - `AGENTS.md`: canonical working rules.
-   - `CLAUDE.md` and `CODEX.md`: thin agent-specific entrypoints.
-   - root `README.md`: project map and start path.
-   - `docs/README.md` and area README files: routing maps and next actions.
-   - `docs/spec/**`: behavior contracts and acceptance criteria.
-   - `docs/test/**`: verification strategy, regression coverage, fixtures, and commands.
-   - `docs/arch/**`: rationale, boundaries, implementation constraints, data flow, and integration decisions.
-   - `docs/plan/**`: active task intent, decisions, risks, verification, and resume state.
-   - `docs/archive/README.md`: history map.
-   - `docs/archive/**`: targeted historical body, not a default reading surface.
-
-Treat custom memory-area metadata as project policy. If custom guidance conflicts with current document content or would change product meaning, surface the conflict and ask before rewriting semantics.
+## Memory-Area Context
 
-## Assess Clarity Problems
+Run `dotdotgod config <root> --json` and use the resolved `config.areas`. Match the target path against the ordered areas and use the first match. If the CLI is unavailable, continue from the target document, nearest README, and direct links.
 
-Look for problems that prevent first-time developers, contributors, or AI coding agents from understanding and acting correctly:
-
-- unclear purpose or missing opening context
-- missing next action or command boundary
-- jargon without definition or link
-- ambiguous terms, inconsistent naming, or overloaded concepts
-- passive or indirect wording that hides who does what
-- excessive background before the task or contract
-- duplicated headings and intros that repeat without adding value
-- weak information scent in links, headings, and README routes
-- examples that are not runnable or are disconnected from the described behavior
-- mixed document roles, such as specs becoming implementation plans or architecture notes becoming tutorials
-- filenames that are sequentially numbered (API_1.md, 01_AUTH.md) — filenames and paths are LLM context metadata and should be as specific as the document title; prefer names derived from the primary endpoint, screen, policy, or domain
-
-Use plain language, active voice, descriptive links, global-audience wording, and concise sections. Keep exact commands, paths, package names, API names, and behavior claims unless verified evidence supports a change.
-
-## Edit Safely
-
-- Preserve the document's role. Do not turn specs into tutorials, tests into product promises, architecture into task plans, plans into permanent specs, or archives into broad default reading surfaces.
-- Put action guidance before internal model details when the audience needs a next step first.
-- Use the same term for the same concept throughout the document.
-- Split or route deep background to focused docs instead of making README indexes dense.
-- For behavior specs, do not weaken MUST/SHOULD requirements or acceptance criteria under the guise of copy edits.
-- For test docs, clarify what is covered and how to verify it; do not invent behavior requirements.
-- For architecture docs, clarify boundaries, constraints, and rationale; do not add unapproved implementation work.
-- For plans, preserve scope, decisions, verification notes, current status, and resume context.
-
-## Traceability and Generated Content
-
-- Treat the fenced `json dotdotgod` block as canonical traceability data.
-- Do not manually edit generated `<!-- dotdotgod:traceability-links:* -->` sections.
-- If traceability mappings need to change, edit the canonical JSON block and run `dotdotgod traceability links <root> --write`.
-- Keep generated links and compact JSON synchronized before final validation.
-- Do not directly maintain generated adapter skill bodies. Edit shared workflow files and `scripts/generate-adapters.mjs`, then run `pnpm run generate`.
-
-## Verification
-
-After documentation edits, run checks that match the changed surface:
-
-```bash
-node packages/cli/bin/dotdotgod.mjs traceability links . --check --json
-node packages/cli/bin/dotdotgod.mjs validate . --include-local-memory --check-index
-```
-
-If validation reports index drift, run:
+## Goal
 
-```bash
-node packages/cli/bin/dotdotgod.mjs index . --json
-node packages/cli/bin/dotdotgod.mjs validate . --include-local-memory --check-index
-```
+Make project documentation easier to understand and act on while preserving established behavior, decisions, task state, historical meaning, and traceability.
 
-When shared workflow text, generated adapter resources, package metadata, or cross-agent docs change, also run:
+## Workflow
 
-```bash
-pnpm run generate
-pnpm run verify:generated
-pnpm run verify
-```
+1. Confirm the target document and requested outcome. Use its matched memory-area metadata when available: `clarify` guidance first, then `description`, `label`, and `role`.
+2. Read only the context needed to preserve meaning: the nearest README, directly linked documents, relevant query results, and targeted history when a past decision matters.
+3. Clarify purpose, next actions, terms, ownership, headings, links, and runnable examples. Keep exact commands, paths, package names, API names, requirements, and behavior claims unless verified evidence supports a change.
+4. Prefer direct affirmative statements. Use “X is not Y; it is Z” only when that contrast resolves a likely ambiguity. Remove repeated framing, indirect wording, mixed responsibilities, and background that obscures the document's job.
+5. Follow repository-local generated markers and canonical-source instructions. For dotdotgod traceability, edit the fenced `json dotdotgod` block as the canonical mapping and use `dotdotgod traceability links <root> --write` to refresh generated links.
+6. Ask for a decision when the requested clarification would change established meaning or when current sources conflict.
+7. Run verification that matches the changed surface. Use documentation and traceability checks for ordinary docs; add generation checks, focused package tests, dry-runs, or workspace verification when shared resources or product behavior are affected.
 
-Use focused package tests or package dry-runs when package resources or CLI config behavior changed.
+When CLI-backed routing is unavailable, continue from the target document, nearest README, direct links, and repository conventions.

package/skills/document-clarify/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Document Clarify"
   short_description: "Clarify dotdotgod project documentation."
-  default_prompt: "Clarify the target docs using dotdotgod memory-area metadata, default document roles, and docs-as-code clarity rules while preserving behavior contracts."
+  default_prompt: "Clarify the target docs using resolved dotdotgod memory-area guidance and direct affirmative prose while preserving established meaning and traceability."

package/skills/impact-review/SKILL.md

@@ -10,34 +10,21 @@ version: 1.0.0
 
 ## Goal
 
-Review source/config/documentation changes with dotdotgod impact data before broad verification, commits, pushes, publishing, or final handoff.
-
-This workflow is the Claude Code and Codex counterpart to Pi's `/impact-check` reminder. It is advisory unless the active agent runtime or a project-local trusted hook adds stricter enforcement.
+Review task-relevant source, config, and documentation changes with dotdotgod impact evidence before broad verification, commits, pushes, publishing, or final handoff. Claude Code and Codex use this advisory workflow; trusted runtime or project hooks may enforce a stricter boundary.
 
 ## Workflow
 
-1. Establish the changed-file set.
-   - Check git status and preserve unrelated user edits.
-   - Include unstaged, staged, and untracked source/config/docs files that are relevant to the current task.
-   - Exclude dependencies, generated caches, build artifacts, secrets, and unrelated local-memory files unless the user explicitly asks about them.
-2. Prefer bounded multi-seed graph impact.
-   - 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`.
-   - 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.
-   - 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`.
-   - If the CLI is unavailable, continue with README indexes, traceability blocks, package metadata, and targeted grep/find fallback.
-3. Inspect impact output selectively.
-   - 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.
-   - When behavior specs appear through `implemented_by`, `verified_by`, or `related_doc`, read those docs before broad verification.
-   - Do not paste large raw impact JSON into the response unless the user asks for diagnostics.
-4. Repair or update related docs/tests when the impact output shows stale, missing, or contradictory project memory.
-5. Choose verification from evidence.
-   - Prefer focused package tests, docs validation, generated-resource checks, and package dry-runs that match the changed files.
-   - For docs changes in dotdotgod projects, run `dotdotgod validate . --include-local-memory` and use `--check-index` when index freshness matters.
-6. Summarize the result.
-   - List changed files reviewed.
-   - List the most relevant impacted docs/tests/files and any follow-up action.
-   - List verification commands run or explain why verification was skipped.
-
-## Hook Boundary
-
-Optional hooks may remind agents to run this workflow after edits or before stop time, but default package resources must not auto-run full workspace verification, rebuild indexes, initialize scaffolds, move plans to archives, or block every write without a tested plan-only state signal.
+1. Build the changed-file set from Git status. Preserve unrelated user work and exclude dependencies, caches, build output, secrets, and unrelated local memory.
+2. Run one bounded multi-seed impact command for up to 20 unique paths in first-seen order:
+
+   ```bash
+   dotdotgod graph impact <root> --changed <path-a> --changed <path-b> --compact
+   ```
+
+   Use `--yml` when structured detail helps. Split larger sets into ordered batches of 20. In a source checkout, use `node packages/cli/bin/dotdotgod.mjs graph impact`; when the CLI is unavailable, follow README indexes, traceability, package metadata, and focused file search.
+3. Review the combined ranking and each seed's non-seed top results. Prioritize high-signal specs, tests, architecture, and source links, especially `implemented_by`, `verified_by`, and `related_doc` relationships.
+4. Resolve stale or contradictory related docs and tests that belong to the current task.
+5. Select focused tests, documentation validation, generated-resource checks, and package dry-runs from the evidence. For dotdotgod documentation changes, run `dotdotgod validate . --include-local-memory` and add `--check-index` when index freshness matters.
+6. Report the changed files reviewed, the strongest related findings and follow-up actions, and verification completed or skipped.
+
+Keep raw impact payloads out of normal summaries. Optional hooks may remind agents about this workflow; default package resources leave full verification, index rebuilds, initialization, archive moves, and write blocking under explicit workflow control.

package/skills/impact-review/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Impact Review"
   short_description: "Review changed files with dotdotgod graph impact."
-  default_prompt: "Review current changed source, config, and docs files with dotdotgod graph impact before broad verification or handoff."
+  default_prompt: "Review task-relevant changed files with dotdotgod graph impact and use the evidence to select verification and related updates."

package/skills/project-initializer/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Project Initializer"
   short_description: "Initialize project memory and config."
-  default_prompt: "Initialize shared project memory and the complete default config with dotdotgod init or the bundled fallback, preserving existing files."
+  default_prompt: "Initialize shared project memory and the complete default config with dotdotgod init or the bundled fallback while preserving existing files."

package/skills/project-initializer/templates/dotdotgod.config.json

@@ -155,6 +155,40 @@
     ],
     "exclude": [
       "**/README.md"
+    ],
+    "keys": [
+      {
+        "key": "implementedBy",
+        "label": "Implemented by",
+        "description": "Files that implement the behavior.",
+        "target": "path",
+        "relation": "implemented_by",
+        "weight": 4
+      },
+      {
+        "key": "verifiedBy",
+        "label": "Verified by",
+        "description": "Tests or maintained verification documents.",
+        "target": "path",
+        "relation": "verified_by",
+        "weight": 4
+      },
+      {
+        "key": "relatedDocs",
+        "label": "Related docs",
+        "description": "Documents needed to interpret the behavior.",
+        "target": "path",
+        "relation": "related_doc",
+        "weight": 3
+      },
+      {
+        "key": "verificationCommands",
+        "label": "Verification commands",
+        "description": "Project-local verification commands.",
+        "target": "command",
+        "relation": "verification_command",
+        "weight": 3
+      }
     ]
   },
   "validation": {
@@ -169,72 +203,10 @@
     }
   },
   "impactRanking": {
-    "preset": "balanced",
-    "weights": {
-      "ppr": 40,
-      "traceability": 30,
-      "memoryPolicy": 10,
-      "verification": 15,
-      "proximity": 10,
-      "semantic": 10,
-      "freshness": 5,
-      "archivePenalty": -25
-    },
-    "ppr": {
-      "enabled": true,
-      "damping": 0.85,
-      "iterations": 20,
-      "tolerance": 0.000001
-    },
-    "relationWeights": {
-      "implemented_by": 4,
-      "verified_by": 4,
-      "related_doc": 3,
-      "verification_command": 3,
-      "links_to": 2,
-      "belongs_to_area": 2,
-      "semantic_similarity": 2,
-      "mentions_package": 1
-    },
-    "traceabilityBoosts": {
-      "implemented_by": 30,
-      "incoming:implemented_by": 30,
-      "verified_by": 25,
-      "incoming:verified_by": 25,
-      "verification_command": 15,
-      "incoming:verification_command": 15,
-      "related_doc": 12,
-      "incoming:related_doc": 12
-    },
-    "verificationBoosts": {
-      "verified_by": 15,
-      "incoming:verified_by": 15,
-      "verification_command": 12,
-      "incoming:verification_command": 12
-    },
-    "semanticBoosts": {
-      "semantic_similarity": 8,
-      "incoming:semantic_similarity": 8,
-      "mentions_package": 4,
-      "incoming:mentions_package": 4
-    },
-    "proximityBoosts": {
-      "links_to": 6,
-      "incoming:links_to": 6,
-      "routes_to": 5,
-      "incoming:routes_to": 5
-    },
     "semantic": {
       "enabled": true,
       "threshold": 0.5,
-      "topKPerFile": 5,
-      "includeArchiveBodies": false,
-      "signals": [
-        "path",
-        "filename",
-        "heading",
-        "package"
-      ]
+      "topKPerFile": 5
     }
   },
   "referenceExpansion": {
@@ -245,11 +217,6 @@
       }
     }
   },
-  "integrations": {
-    "trello": {
-      "syncPaths": []
-    }
-  },
   "load": {
     "pinnedPaths": [],
     "pinnedBodies": [],

package/skills/project-load/SKILL.md

@@ -8,6 +8,10 @@ version: 1.0.0
 
 # Project Load
 
+## CLI Context
+
+Run `dotdotgod config <root> --json` and apply `config.load.documentationSummary.exclude` before building the documentation tree. With focus text, run `dotdotgod query <root> "<focus>" --limit 30 --json`. If the CLI is unavailable, continue from the documentation tree and README indexes.
+
 ## Goal
 
 Load the repository's dotdotgod project memory without modifying maintained files. Treat free-form arguments as query text, not mode switches.
@@ -17,7 +21,7 @@ Load the repository's dotdotgod project memory without modifying maintained file
 1. Identify the repository root. Expose `Help: dotdotgod --help` as optional CLI discovery guidance without checking or reporting installation status, and do not require Help execution for Load to continue.
 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. At the boundary, list every direct Markdown file and immediate child directory regardless of item count, then summarize hidden descendants separately under each named child with exact recursive 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 with the same named boundary-child summaries. Fall back to the tree and README indexes when query is unavailable.
+4. With arguments, use focused query results to return at most 30 distinct Markdown files and render the tree through depth 3 with the same named boundary-child summaries.
 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

package/skills/project-load/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Project Load"
   short_description: "Load dotdotgod project memory."
-  default_prompt: "Load this project's dotdotgod memory and summarize rules, docs, commands, relevant active plans, and questions surfaced by the loaded material."
+  default_prompt: "Load the resolved dotdotgod project context and summarize the maintained evidence and routes relevant to the current request."