codebyplan 1.13.29 → 1.13.30

package/templates/skills/cbp-build-cc-memory/examples/project-memory.md

@@ -1,11 +0,0 @@
----
-name: Auth middleware rewrite is compliance-driven
-description: Compliance context for the auth rewrite — affects scope decisions
-type: project
----
-
-Auth middleware rewrite is driven by legal/compliance requirements around session token storage, not tech-debt cleanup.
-
-**Why:** Legal flagged the current middleware in 2026-Q1 because session tokens are stored in a way that doesn't meet the new compliance requirements. Deadline: 2026-05-15.
-
-**How to apply:** When making scope decisions on this rewrite, favour compliance over ergonomics. Don't add unrelated refactors. Don't defer compliance work for "cleaner" architecture. If asked to trade off — compliance wins.

package/templates/skills/cbp-build-cc-memory/examples/reference-memory.md

@@ -1,13 +0,0 @@
----
-name: Pipeline bugs tracked in Linear INGEST
-description: External system pointer for pipeline-related tickets and dashboards
-type: reference
----
-
-Pipeline bugs are tracked in Linear project **INGEST** (https://linear.app/acme/team/INGEST).
-
-Related dashboards:
-- `grafana.internal/d/api-latency` — oncall latency dashboard; check when editing request-path code
-- `https://status.acme.com/pipeline` — customer-facing pipeline status
-
-When the user mentions a pipeline bug by ID (e.g. INGEST-4123), look there first.

package/templates/skills/cbp-build-cc-memory/examples/user-memory.md

@@ -1,14 +0,0 @@
----
-name: User role and frontend experience
-description: User's technical background — use to calibrate explanation depth
-type: user
----
-
-User has deep Go backend experience (10+ years) and is newly touching the React side of this repo.
-
-Frame frontend explanations in terms of backend analogues:
-- Components ≈ structs + methods
-- Hooks ≈ middleware-like composition
-- React state ≈ mutex-guarded field on a struct
-
-Skip JS fundamentals (closures, async). Go deeper on React-specific patterns (render cycles, effect semantics, ref semantics).

package/templates/skills/cbp-build-cc-memory/reference/memory-types.md

@@ -1,59 +0,0 @@
-# Memory Types Reference
-
-Four discrete types of auto-memory entries. Pick by content, not by user phrasing.
-
-## `user`
-
-**Contains:** role, goals, responsibilities, existing knowledge.
-
-**Save when:** you learn details about who the user is or how they collaborate. Tailors future behaviour.
-
-**Skip when:** the info would be a negative judgement, or it's not relevant to work.
-
-**Example trigger:** "I'm a data scientist investigating logging."
-
-## `feedback`
-
-**Contains:** guidance the user has given about how to approach work — corrections AND confirmations.
-
-**Save when:**
-- User corrects you ("no not that", "don't", "stop")
-- User confirms a non-obvious approach worked ("yes exactly", "that was the right call")
-
-**Structure:** rule → **Why:** (reason) → **How to apply:** (when).
-
-**Example trigger:** "stop summarizing at the end of every response."
-
-Record successes too — otherwise you drift toward cautious defaults and away from validated approaches.
-
-## `project`
-
-**Contains:** ongoing work context — goals, deadlines, incidents, stakeholders, WHY behind initiatives.
-
-**Save when:** you learn who is doing what, why, or by when — things not derivable from code or git history.
-
-**Convert dates to absolute** when saving (never "Thursday" — always `2026-04-23`).
-
-**Structure:** fact → **Why:** → **How to apply:**.
-
-**Example trigger:** "we're freezing after Thursday for the mobile cut."
-
-Project memories decay fast. The **Why** helps future-you judge whether the memory is still load-bearing.
-
-## `reference`
-
-**Contains:** pointers to external systems (Linear, Slack, Grafana, Notion, Confluence).
-
-**Save when:** user mentions a resource by name. Memory just says *where to look*.
-
-**Example trigger:** "the Grafana dashboard at grafana.internal/d/api-latency is what oncall watches."
-
-## What NOT to save (any type)
-
-- Code patterns, file paths, project structure (re-derivable from code)
-- Git history, who-changed-what (`git log`, `git blame` are authoritative)
-- Debugging fixes (already in the commit; PR body has the why)
-- CLAUDE.md content (that's a different mechanism)
-- Ephemeral task state (in-progress work, current conversation)
-
-Applies **even when the user asks you to save**. If they ask to save a PR list, ask what was *surprising* — that's the part worth keeping.

package/templates/skills/cbp-build-cc-memory/reference/when-to-save.md

@@ -1,62 +0,0 @@
-# When to Save vs Skip
-
-Decision tree for auto-memory entries.
-
-## Save immediately
-
-| Signal | Type |
-|--------|------|
-| User corrects you ("no", "don't", "stop") | feedback |
-| User confirms a non-obvious choice worked | feedback |
-| User shares their role, experience, preferences | user |
-| User explains **why** something is the way it is | project |
-| User names an external system (ticket tracker, dashboard, channel) | reference |
-| User says "remember this" / "save this" | pick by content |
-
-## Skip
-
-- "What's the status of X?" — derivable from code/DB, don't save
-- "Here's the PR list" — derivable from `gh pr list`, don't save unless something was surprising
-- Fix you just made — the commit has the why, don't duplicate
-- Architecture you just read — re-read when needed
-
-## Update an existing entry instead of creating
-
-Before writing a new file:
-
-```bash
-ls ~/.claude/projects/<project>/memory/ | grep -i {topic}
-```
-
-If anything matches:
-- Fact has changed → edit the existing file, update description if needed
-- New angle on same topic → merge into existing, keep one file per topic
-
-## Remove stale entries
-
-When a memory turns out wrong:
-
-1. Delete the file
-2. Remove the index line from MEMORY.md
-
-When a memory references something that no longer exists (file renamed/removed):
-
-1. Grep the codebase for the referenced symbol/path
-2. If truly gone, delete the memory
-3. If renamed, update the memory
-
-## Verify before acting
-
-A memory naming a specific function, file, or flag is a claim that it existed *when written*. Before recommending it:
-
-- Memory names a file path → check the file exists
-- Memory names a function or flag → grep for it
-- User is about to act on your recommendation → always verify first
-
-"Memory says X exists" is not the same as "X exists now."
-
-## Session gates
-
-- `/clear` wipes conversation context but NOT memory — memory reloads on next session
-- When the user says "ignore memory" or "don't use memory" — do not cite or act on memory content for this session; do not say "memory says X"
-- When memory conflicts with current code — trust the code, update or remove the stale memory

package/templates/skills/cbp-build-cc-memory/templates/MEMORY-index.md

@@ -1,4 +0,0 @@
-# Memory
-
-- [Entry title](filename.md) — one-line hook under ~150 chars
-- [Another entry](another.md) — one-line hook

package/templates/skills/cbp-build-cc-memory/templates/memory-entry.md

@@ -1,15 +0,0 @@
----
-name: Entry title
-description: One-line relevance hint — future sessions read this to decide if the memory matters
-type: user | feedback | project | reference
----
-
-[Memory content]
-
-# For feedback and project types, structure as:
-
-The rule or fact itself in one sentence.
-
-**Why:** The reason the user gave — often a past incident or strong preference.
-
-**How to apply:** When/where this guidance kicks in, so future-you can judge edge cases.