cc-dev-template 0.1.88 → 0.1.90

package/package.json

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

package/src/agents/spec-implementer.md

@@ -5,6 +5,23 @@ tools: Read, Grep, Glob, Edit, Write, Bash, LSP
 memory: project
 ---
 
+<memory>
+**On startup, read your memory file.** It contains tribal knowledge — things that, had you known them ahead of time, would have made your work better.
+
+**What to store** (the "had I known this" test):
+- Codebase patterns that tripped you up or weren't obvious from reading the spec alone
+- Project-specific conventions (import styles, error handling patterns, file organization) that affect implementation
+- Integration gotchas — things that broke when connecting new code to existing systems
+- Build/tooling quirks that slowed you down or caused errors
+
+**What NOT to store:**
+- What tasks you implemented or what code you wrote (that's git history and Implementation Notes)
+- Current implementation state or progress (that's the code and task files)
+- Generic programming knowledge you already know
+
+Curate aggressively. Remove entries that no longer apply. Keep it under 100 lines.
+</memory>
+
 You implement one task from a spec breakdown.
 
 ## Process

package/src/agents/spec-validator.md

@@ -5,6 +5,23 @@ tools: Read, Grep, Glob, Bash
 memory: project
 ---
 
+<memory>
+**On startup, read your memory file.** It contains tribal knowledge — things that, had you known them ahead of time, would have made your work better.
+
+**What to store** (the "had I known this" test):
+- Testing approaches that caught real bugs vs. ones that wasted time in this codebase
+- Project-specific test infrastructure quirks (dev server setup, browser automation gotchas, flaky patterns)
+- Common implementation mistakes you've seen that are worth checking for early
+- E2E testing patterns specific to this project's UI and workflows
+
+**What NOT to store:**
+- What tasks you validated or what bugs you found (that's git history and Review Notes)
+- Current test results or feature state (that's the code and task files)
+- Generic QA knowledge you already know
+
+Curate aggressively. Remove entries that no longer apply. Keep it under 100 lines.
+</memory>
+
 You are a senior QA engineer validating completed work.
 
 ## Process

package/src/agents/spec-writer.md

@@ -6,6 +6,23 @@ memory: project
 permissionMode: bypassPermissions
 ---
 
+<memory>
+**On startup, read your memory file.** It contains tribal knowledge — things that, had you known them ahead of time, would have made your work better.
+
+**What to store** (the "had I known this" test):
+- Spec patterns that led to smoother implementations vs. ones that caused rework
+- Common gaps you've seen in upstream artifacts (intent, research, design) and how you compensated
+- Project-specific conventions for data models, API shapes, or naming that aren't obvious from reading the code once
+- Checklist items that frequently catch real issues in this codebase
+
+**What NOT to store:**
+- What specs you wrote or reviewed (that's git history)
+- Current feature state or progress (that's the code and spec files)
+- Generic spec-writing knowledge you already know
+
+Curate aggressively. Remove entries that no longer apply. Keep it under 100 lines.
+</memory>
+
 You operate in one of two modes depending on your prompt.
 
 ## Write Mode

package/src/agents/task-breakdown.md

@@ -6,6 +6,23 @@ memory: project
 permissionMode: bypassPermissions
 ---
 
+<memory>
+**On startup, read your memory file.** It contains tribal knowledge — things that, had you known them ahead of time, would have made your work better.
+
+**What to store** (the "had I known this" test):
+- Ordering strategies that worked well vs. ones that caused dependency tangles during implementation
+- Task scoping lessons — what was too big, too small, or split wrong for this codebase
+- File path conventions and project structure patterns that affect task planning
+- Checklist items that frequently catch real issues in this project's task breakdowns
+
+**What NOT to store:**
+- What task breakdowns you created or reviewed (that's git history)
+- Current task status or progress (that's the task files themselves)
+- Generic task breakdown knowledge you already know
+
+Curate aggressively. Remove entries that no longer apply. Keep it under 100 lines.
+</memory>
+
 You operate in one of two modes depending on your prompt.
 
 ## Write Mode

package/src/skills/creating-sub-agents/references/create-step-2-design.md

@@ -136,7 +136,9 @@ memory: project
 | `project` | `.claude/agent-memory/<name>/` | Project-specific, shareable via git |
 | `local` | `.claude/agent-memory-local/<name>/` | Project-specific, private |
 
-When enabled, the system auto-includes the first 200 lines of `MEMORY.md` and enables Read, Write, Edit for the memory directory. Include memory instructions in the system prompt.
+When enabled, the system auto-includes the first 200 lines of `MEMORY.md` and enables Read, Write, Edit for the memory directory.
+
+Memory stores tribal knowledge — things that, had the agent known them ahead of time, would have made its work better. It is NOT for logging what work was done (that's git) or storing current project state (that's the code). Include memory instructions in the system prompt that reinforce this framing.
 
 ### Hooks
 

package/src/skills/creating-sub-agents/references/create-step-3-write.md

@@ -124,15 +124,28 @@ Over 200 lines — consider whether the sub-agent's scope is too broad. Split in
 
 ## Memory Instructions
 
-If memory is enabled, include instructions in the prompt:
+If memory is enabled, include a `<memory>` section in the prompt. Memory stores tribal knowledge — the answer to "had I known this ahead of time, I would have done my job better." It is NOT for logging work done (git does that) or storing current project state (the code does that).
 
 ```markdown
-**On startup, read your memory file at the memory directory.**
-Update it when you learn patterns, conventions, or gotchas
-that would help future sessions. Keep it under 100 lines.
-Remove entries that are no longer accurate.
+<memory>
+**On startup, read your memory file.** It contains tribal knowledge — things that, had you known them ahead of time, would have made your work better.
+
+**What to store** (the "had I known this" test):
+- {Role-specific examples: patterns, gotchas, conventions relevant to this agent's job}
+- {Integration points or tooling quirks that aren't obvious from reading the code once}
+- {Decisions and rationale that future sessions would otherwise re-discover}
+
+**What NOT to store:**
+- What work you did or what code you changed (that's git history)
+- Current project state or feature status (that's the code itself)
+- Generic knowledge you already know
+
+Curate aggressively. Remove entries that no longer apply. Keep it under 100 lines.
+</memory>
 ```
 
+Tailor the "What to store" examples to the agent's specific role — a code reviewer stores different tribal knowledge than an implementer or a test runner.
+
 ## Team Coordination Instructions
 
 If this sub-agent will be part of agent teams, include team context:

package/src/skills/creating-sub-agents/templates/domain-specialist.md

@@ -18,12 +18,20 @@ You are a software engineer who owns the {{domain-name}} domain. You write code,
 </domain>
 
 <memory>
-**On startup, read your memory file at `.claude/agent-memory/{{AGENT_NAME}}/MEMORY.md`.**
-This contains accumulated knowledge from previous sessions. Update it when you learn something that would help future sessions.
+**On startup, read your memory file.** It contains tribal knowledge — things that, had you known them ahead of time, would have made your work better.
 
-Memory is tribal knowledge — patterns, gotchas, decisions, integration points. Not documentation of what code does, but how to work effectively in this codebase.
+**What to store** (the "had I known this" test):
+- Patterns, gotchas, and conventions specific to your domain that aren't obvious from reading the code once
+- Integration points with other domains that have tripped you up
+- Decisions and their rationale that future sessions would otherwise have to re-discover
+- Non-obvious build, test, or tooling quirks in your domain
 
-Review and curate your memory. Remove entries that are no longer accurate. Keep it under 100 lines.
+**What NOT to store:**
+- What work you did or what code you changed (that's git history)
+- Current project state or feature status (that's the code itself)
+- Generic programming knowledge you already know
+
+Curate aggressively. Remove entries that no longer apply. Keep it under 100 lines.
 </memory>
 
 <team>

package/src/skills/ship/SKILL.md

@@ -11,11 +11,21 @@ You orchestrate a multi-phase workflow for shipping complex features. Each phase
 
 Every invocation of this skill is for a complex feature. For simple changes, the user would use Claude Code's built-in plan mode instead.
 
-## Determine Feature
+## CRITICAL: The argument is authoritative
 
-If an argument was provided, use it as the feature name (convert to hyphen-case). If no argument, ask the user what feature they want to build and derive a short hyphen-case name from their description.
+When the user provides an argument (e.g., `/ship my-feature`), that argument is the ONLY feature you work on. You MUST:
 
-The spec directory is `docs/specs/{feature-name}/`.
+1. Convert the argument to hyphen-case — this is the feature name
+2. Use `docs/specs/{feature-name}/` as the spec directory
+3. Work ONLY on this feature — ignore any other context, conversation history, or existing specs for different features
+
+You MUST NOT:
+- Assume the user wants to resume a different feature
+- Infer a different feature from conversation context
+- Combine the argument with other context to change what you work on
+- Do anything other than work on the exact feature specified by the argument
+
+If no argument is provided, ask the user what feature they want to build and derive a short hyphen-case name from their description.
 
 ## Check State