cc-dev-template 0.1.3 → 0.1.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-dev-template",
-  "version": "0.1.3",
+  "version": "0.1.5",
   "description": "Structured AI-assisted development framework for Claude Code",
   "bin": {
     "cc-dev-template": "./bin/install.js"

package/src/agents/execution-agent.md

@@ -106,6 +106,21 @@ For each ADR in `relevant_adrs`:
   - ADR-005 violation: Using MD5 instead of bcrypt for passwords
   ```
 
+## Prompt Work
+
+If your task involves creating or editing **prompts**—for sub-agents, commands, skills, Claude Agent SDK, or any other prompt artifacts—activate the **prompting skill** before proceeding with implementation.
+
+This applies when:
+- Writing or modifying agent prompt files (`.md` files that define agent behavior)
+- Creating or editing slash command definitions
+- Writing or updating skill definitions (`SKILL.md`)
+- Crafting prompts for Claude Agent SDK usage
+- Any work where you're defining instructions that Claude will follow
+
+**How to activate**: Use the Skill tool with `skill: "prompting"` to load the prompting best practices, then apply those principles to your prompt work.
+
+The prompting skill ensures your prompts follow established patterns: explaining WHY not just WHAT, using positive framing, being clear and direct, and providing proper context. Quality prompts are critical since they shape agent behavior across all future executions.
+
 ## Escalation
 
 **Stop immediately and escalate if:**

package/src/skills/orchestration/references/planning/draft.md

@@ -94,14 +94,37 @@ relevant_adrs:
   - id: ADR-[XXX]
     title: [title]
     constraint: [What this ADR requires us to do or avoid]
+
+# Submodules affected by this work (for repos with git submodules)
+affected_submodules:
+  - path: [relative/path/to/submodule]
+    reason: [Why this submodule is affected by the plan]
 ```
 
 **Field guidance:**
 
 - **Required**: id, title, type, status, created, problem_statement, goals, success_criteria
-- **Include if relevant**: integration_points, data_models, api_contracts, relevant_adrs
+- **Include if relevant**: integration_points, data_models, api_contracts, relevant_adrs, affected_submodules
 - **Only include fields that were discussed**: The plan reflects the conversation from Phases 1 and 2
 
+**affected_submodules field:**
+
+Include this field when working in repositories with git submodules and the plan's scope touches specific submodules. This enables scope-aware ADR discovery—the adr-agent can filter to only show ADRs that are either global or scoped to the affected submodules.
+
+- `path` (required): Relative path to the submodule, matching what appears in `.gitmodules`
+- `reason` (optional): Brief explanation of why this submodule is affected by the plan
+
+Example:
+```yaml
+affected_submodules:
+  - path: packages/auth
+    reason: Adding new authentication method
+  - path: packages/shared
+    reason: Shared types need updating for new auth flow
+```
+
+When a plan declares affected_submodules, ADRs scoped to those submodules become relevant, while ADRs scoped to unaffected submodules can be filtered out. ADRs with no scope field are always treated as global and remain relevant regardless of which submodules are affected.
+
 **Why no approach or risks?** The plan defines WHAT we're building, not HOW. The approach (phases, task breakdown) gets figured out during decomposition in execution. Risks emerge naturally during exploration or decomposition.
 </step>
 

package/src/skills/orchestration/references/planning/explore.md

@@ -56,10 +56,13 @@ While codebase exploration is happening, also spawn the adr-agent to find archit
 ```
 Spawn adr-agent: "Find ADRs that would be relevant to [summary of requirements].
                   For each relevant ADR, explain why it matters and what
-                  constraints it imposes on this work."
+                  constraints it imposes on this work.
+
+                  If this work affects specific submodules, mention which ones
+                  so the agent can filter ADRs by scope."
 ```
 
-ADRs discovered now will inform the plan you write. Better to know the rules before you design than to discover violations later.
+ADRs discovered now will inform the plan you write. Better to know the rules before you design than to discover violations later. When specific submodules are involved, scope-aware discovery surfaces the most relevant ADRs while filtering out ADRs that only apply elsewhere.
 </step>
 
 <step name="Synthesize Findings">

package/src/skills/orchestration/references/planning/finalize.md

@@ -18,6 +18,7 @@ Complete each step in order before proceeding to the next.
 Spawn the adr-agent to validate the plan. The agent will:
 - Read the plan.yaml
 - Find ALL ADRs that might be relevant (not just the ones declared in the plan)
+- Use the plan's `affected_submodules` field for scope-aware filtering
 - Check compliance for each: COMPLIANT, TENSION, or CONFLICT
 - Report what needs attention
 
@@ -28,12 +29,16 @@ Find all ADRs that could be relevant to this work—check beyond what's
 declared in the plan's relevant_adrs field. Better to surface extra
 ADRs than miss important ones.
 
+Use the plan's affected_submodules field to focus on ADRs that apply
+to the relevant submodules. Global ADRs always apply; submodule-scoped
+ADRs only apply when their scope matches the affected submodules.
+
 For each relevant ADR, report:
 - COMPLIANT: Plan follows this ADR
 - TENSION: Potential friction, worth noting
 - CONFLICT: Plan violates this ADR, must resolve
 
-Return a validation report with findings for each ADR."
+Note in the report when ADRs were filtered by scope."
 ```
 
 **Show the validation report to the user** before proceeding.