aw-ecc 1.4.48 → 1.4.50

package/manifests/install-modules.json

@@ -274,6 +274,8 @@
         "skills/e2e-testing",
         "skills/eval-harness",
         "skills/finish-only-when-green",
+        "skills/grill-me",
+        "skills/grill-with-docs",
         "skills/iterative-retrieval",
         "skills/plankton-code-quality",
         "skills/project-guidelines-example",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aw-ecc",
-  "version": "1.4.48",
+  "version": "1.4.50",
   "description": "GoHighLevel Agentic Workspace Engine — forked from Everything Claude Code (ecc-universal)",
   "keywords": [
     "claude-code",

package/skills/grill-with-docs/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: grill-with-docs
-description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
+description: Grilling session that challenges your plan against the existing domain model, AW planning context, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
 ---
 
 ## When To Use
 
-Use this inside planning when the problem is fuzzy, domain language is overloaded, acceptance criteria are under-specified, or existing docs/code may contradict the user's mental model.
+Use this inside planning when the problem is fuzzy, domain language is overloaded, acceptance criteria are under-specified, or existing AW docs, repo docs, or code may contradict the user's mental model.
 
 <what-to-do>
 
@@ -21,7 +21,19 @@ If a question can be answered by exploring the codebase, explore the codebase in
 
 ## Domain awareness
 
-During codebase exploration, also look for existing documentation:
+During codebase exploration, also look for AW planning context and existing documentation.
+
+### AW feature context
+
+If `.aw_docs/` exists, resolve the active AW context before assuming the repo has no glossary or ADRs.
+
+1. Look for an explicit feature slug in the prompt, current branch, PR title, current files, or conversation. If present, inspect `.aw_docs/features/<slug>/`.
+2. If no explicit slug is present, search `.aw_docs/features/` for likely matches using the user's terms. Prefer folders with fresh `state.json`, `prd.md`, `design.md`, `spec.md`, `tasks.md`, `execution.md`, or `verification.md`.
+3. If multiple feature folders plausibly match, name the candidates and ask one short selection question before continuing.
+4. Read relevant AW feature files as planning memory. Markdown files remain the canonical agent-readable source; HTML sidecars are human-facing companions.
+5. Use `state.json`, plan files, PR links, git remotes, and changed paths to identify the target implementation repo or repos. In a workspace that contains multiple repos, do not treat the workspace container root as the domain root.
+
+AW docs do not replace domain docs. They tell you which feature and target repos to inspect. After resolving the AW feature context, inspect the target repo or bounded domain for `CONTEXT.md`, `CONTEXT-MAP.md`, and ADR folders.
 
 ### File structure
 
@@ -53,7 +65,9 @@ If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The ma
 │       └── docs/adr/
 ```
 
-Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+Create files lazily — only when you have something to write. If no `CONTEXT.md` exists in the resolved target repo or bounded context, create one when the first term is resolved. If no `docs/adr/` or `docs/adrs/` exists in that target context, create it when the first ADR is needed.
+
+Do not create `CONTEXT.md` or `docs/adr/` at a workspace container root just because they are missing there. If the root contains `.aw_docs/` plus multiple nested repos, first resolve the AW feature folder and target repo, then create or update docs in the target context.
 
 ## During the session
 

package/skills/grill-with-docs/evals/eval-aw-docs-context-root.md

@@ -0,0 +1,50 @@
+# Eval: AW Docs Context Root
+
+## Purpose
+
+Verify `grill-with-docs` resolves AW feature context before assuming root-level `CONTEXT.md` or `docs/adr/` are missing.
+
+## Scenario
+
+Workspace layout:
+
+```text
+/workspace/
+├── .aw_docs/
+│   └── features/
+│       └── teamofone-routines-agents-forward-plan/
+│           ├── spec.md
+│           ├── tasks.md
+│           └── state.json
+├── teamofone-monorepo/
+│   ├── package.json
+│   └── README.md
+└── platform-devtools-backend/
+    ├── package.json
+    └── README.md
+```
+
+No `CONTEXT.md`, `CONTEXT-MAP.md`, or `docs/adr/` exists at `/workspace/`.
+
+User asks:
+
+> Use grill-with-docs for the TeamOfOne routines and agents PRs. When we say Routine, is it saved configuration or executable workflow?
+
+## Expected Behavior
+
+The agent should:
+
+- Inspect `.aw_docs/features/teamofone-routines-agents-forward-plan/` as the active planning context.
+- Use `state.json`, `spec.md`, and `tasks.md` to identify likely target repos before declaring docs absent.
+- Avoid saying the workspace has no glossary solely because `/workspace/CONTEXT.md` and `/workspace/docs/adr/` are absent.
+- Avoid creating `/workspace/CONTEXT.md` or `/workspace/docs/adr/`.
+- Say that durable context docs should be created only in the resolved target repo or bounded context after terms are agreed.
+
+## Failure Modes
+
+The eval fails if the agent:
+
+- Treats `/workspace/` as the domain root without checking `.aw_docs/features/`.
+- Ignores the AW feature folder.
+- Creates or proposes root-level context docs in the workspace container.
+- Uses only generic `CONTEXT.md` / `docs/adr/` discovery language.