[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79FMDTG3JB2KCXP6EPZ14MS":3,"skill-same:01M79FMDTG3JB2KCXP6EPZ14MS":48},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":6,"updatedAt":33,"install":34,"resources":47},"01M79FMDTG3JB2KCXP6EPZ14MS","dream",null,"Curate the in-repo project memory store (.claude\u002Fmemory\u002F) — merge duplicates, drop stale entries, surface new patterns from recent sessions, and promote durable project-wide themes into docs\u002F and skill text. Applies all changes on a branch and opens a PR. Memory is version-controlled, so git is the review\u002Fbackup\u002Frollback mechanism — there is no staging dir or file backup.","penca-io\u002Fpenca","penca-io","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F294652540?v=4","01M79FKD3WVDHQXKBT43KMQFPR","Penca","01M79FKD4JJK7894AKV1R7RHTR",8,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpenca-io\u002Fpenca\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdream\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: dream\ndescription: Curate the in-repo project memory store (.claude\u002Fmemory\u002F) — merge duplicates, drop stale entries, surface new patterns from recent sessions, and promote durable project-wide themes into docs\u002F and skill text. Applies all changes on a branch and opens a PR. Memory is version-controlled, so git is the review\u002Fbackup\u002Frollback mechanism — there is no staging dir or file backup.\nallowed-tools: Bash Read Write Edit Glob Grep\n---\n\n# Dream: curate the project memory store\n\nRead the project's memory store and recent session transcripts, then **apply** a curated memory store plus any theme promotions directly to the repo on a branch and open a PR. Memory lives in the git-tracked `.claude\u002Fmemory\u002F` directory, so every change is version-controlled — the PR is the review gate, and `git` is the backup and rollback path. There is no staging directory, no file backup, and no swap\u002Fprune dance.\n\nModeled on Anthropic's Managed Agents Dreams API (`platform.claude.com\u002Fdocs\u002Fen\u002Fmanaged-agents\u002Fdreams`). The API version operates on managed `memory_store` and `session` resources; this skill operates on the in-repo memory store and local session transcripts.\n\n## Inputs\n\n- **Memory store (in repo, version-controlled):** `$(git rev-parse --show-toplevel)\u002F.claude\u002Fmemory\u002F*.md`, index in `MEMORY.md`. This is the source of truth and the thing you edit — **not** the runtime `~\u002F.claude\u002Fprojects\u002F\u003Cslug>\u002Fmemory\u002F` path (that's a symlink into here; editing it directly is the bug this skill was rewritten to avoid).\n- **Sessions (optional, up to ~100):** recent JSONL transcripts under `~\u002F.claude\u002Fprojects\u002F$(pwd | tr '\u002F' '-')\u002F*.jsonl`. These are *not* in the repo. Mine them for patterns to fold into the store.\n- **Instructions (optional):** the user can scope the curation, e.g. \"focus on coding-style preferences; ignore one-off debugging notes.\"\n\nInvoking `\u002Fdream` is the authorization to curate, commit, push, and open a PR. The PR — not a mid-run prompt — is where the user reviews and approves. Never merge the PR (that is the user's, always).\n\n## Procedure\n\n### 1. Branch\n\nVM-per-ticket default — plain branch from the repo root:\n\n```bash\ngit checkout -b \u003Cuser>\u002Fdream-curate-memory-\u003CYYYY-MM-DD>\n```\n\n(Laptop-fallback worktree mechanics, if applicable, follow the repo's normal branching convention.)\n\n### 2. Inventory the current store\n\n```bash\nMEM=\"$(git rev-parse --show-toplevel)\u002F.claude\u002Fmemory\"\nls \"$MEM\"\u002F*.md | grep -v MEMORY.md | wc -l\nwc -c \"$MEM\u002FMEMORY.md\"\nSESS=~\u002F.claude\u002Fprojects\u002F$(pwd | tr '\u002F' '-')\nls \"$SESS\"\u002F*.jsonl 2>\u002Fdev\u002Fnull | wc -l\n```\n\nRead `MEMORY.md` and each entry body. Understand the store before changing it.\n\n### 3. Identify candidates\n\nFour dispositions:\n\n- **Merge** — entries that say the same thing in different words, or cover the same rule from different angles (e.g. several proto-feedback entries → one; several naming-preference entries → one per coherent rule).\n- **Drop** — entries that are superseded by newer state, contradicted by current code, about files\u002Fsymbols\u002Fflags that no longer exist, already captured in committed code (an ADR, `docs\u002Fstyle-guide.md`, a service doc, a skill `SKILL.md`), or narrow \u002F non-recurring (a one-off gotcha that won't recur often enough to earn its context cost).\n- **Promote** — durable, project-wide rules that *aren't* already in committed code and should be. **Memory is not the home for durable conventions.** If a rule is load-bearing, promote it to docs\u002F or a skill **and drop it from memory in the same PR** (see step 5). Typical homes:\n  - Coding conventions → `docs\u002Fstyle-guide.md`\n  - Algorithm \u002F design rationale → `docs\u002Falgorithms.md`, `docs\u002Fdesign-decisions.md`, or a new ADR under `docs\u002Fdecisions\u002F`\n  - Service-specific design → `docs\u002Fservices\u002F\u003Cservice>.md`\n  - Recurring review pushbacks → `.claude\u002Fskills\u002Freview-pr\u002FSKILL.md` (\"What NOT to flag\" or the relevant step)\n  - Recurring planning rules → `.claude\u002Fskills\u002Fdo-issue\u002FSKILL.md`\n  - **Corrections to a skill's own cheat-sheet\u002Finstructions** → fix that skill directly. An entry that only exists because a skill's text is wrong retires the moment the skill is fixed — this is the highest-value promotion.\n- **Add** — patterns visible in recent sessions not yet in memory: repeated corrections, enthusiastically-accepted preferences, project-state facts (incidents, deadlines) future sessions need.\n\nMemory should be tight. Default each candidate to the strictest disposition that fits — **promote** beats **keep** for any project-wide convention; **drop** beats **promote** for narrow gotchas.\n\n### 4. Verify before changing\n\nCode state is authoritative; do not drop or rewrite based on assumption.\n- A memory cites a file path → confirm it exists (or doesn't).\n- A memory cites a symbol → grep for it.\n- A memory cites a deadline \u002F \"verified \u003Cdate>\" → check it against today.\n- A memory claims a skill says X → read that skill and confirm before \"fixing\" it (the skill may already have changed).\n\nIf a rule is still valid but a cited symbol drifted, refresh the reference rather than dropping the rule.\n\n### 5. Apply the changes in `.claude\u002Fmemory\u002F` (and promotion targets)\n\nEdit the in-repo store directly:\n- **Merge:** write the new combined entry, delete the merged-away files (`git rm` or `rm`), update any `[[links]]` in surviving entries that pointed at removed slugs, and update `MEMORY.md`.\n- **Drop:** delete the files, update `MEMORY.md`.\n- **Add:** write new entries (same frontmatter contract — `name`, `description`, `metadata.type`), add their index lines to `MEMORY.md`.\n- **Promote:** apply the rule to its named target file (match the surrounding section style; never paste memory frontmatter into committed docs), **and delete the now-redundant memory entry in the same PR**, removing its `MEMORY.md` line. Because the docs change and the memory drop land atomically in one PR, there is no \"retire later\" deferral — that two-phase dance only existed when the store wasn't version-controlled. (Until the PR merges, `main` still carries the entry, so nothing is lost if the PR is revised.)\n\nKeep `MEMORY.md` in sync with the actual file set — every index link must resolve, and every entry file must be indexed. Verify before committing:\n\n```bash\nMEM=\"$(git rev-parse --show-toplevel)\u002F.claude\u002Fmemory\"\n# index links that don't resolve to a file:\ngrep -oE '\\(([a-z0-9_]+\\.md)\\)' \"$MEM\u002FMEMORY.md\" | tr -d '()' | sort -u | \\\n  while read f; do [ -f \"$MEM\u002F$f\" ] || echo \"MISSING: $f\"; done\n# files vs index (empty = perfect match):\ncomm -3 \u003C(grep -oE '\\(([a-z0-9_]+\\.md)\\)' \"$MEM\u002FMEMORY.md\" | tr -d '()' | sort -u) \\\n        \u003C(ls \"$MEM\"\u002F*.md | xargs -n1 basename | grep -v MEMORY.md | sort)\n# no dangling [[links]] to removed slugs:\ngrep -rn '\\[\\[' \"$MEM\"\u002F*.md\n```\n\nDo **not** write a `CHANGELOG.md` into `.claude\u002Fmemory\u002F` — the change log is the PR body (step 7), not a committed memory file.\n\n### 6. Commit\n\nFollow the repo's commit conventions (conventional commits; scope from `linear\u002Flabels.toml` — memory\u002Fskill changes use `docs(agent)`; omit scope when a change spans areas). Separate commits read best:\n- one `docs(agent)` commit for the memory curation (merges \u002F drops \u002F adds \u002F link fixes),\n- one commit per promotion target group (e.g. `docs:` for `docs\u002Fstyle-guide.md`, `docs(agent):` for skill-text fixes), each dropping the corresponding memory entries.\n\nRun any commit-msg\u002Fpre-commit hooks; fix subject-length \u002F type \u002F scope rejections rather than bypassing them.\n\n### 7. Open the PR\n\nPush the branch and open a PR (`gh pr create`; if `gh pr edit` is broken in this env, use `gh api -X PATCH` for later body edits). Stop after opening it — **never merge** (the user merges). The PR body is the change log:\n\n```markdown\n## Summary\n\u003Cone-line: dream curation + promotions for \u003CYYYY-MM-DD>>\n\n## Merged (N → M)\n- `old_a` + `old_b` → `new`: \u003Crationale>\n\n## Dropped — already captured \u002F stale \u002F narrow\n- `old_c`: \u003Cwhich doc\u002FADR\u002Fskill covers it, or why it's stale (with the verification)>\n\n## Promoted (rule moved to committed code; memory entry removed here)\n- `old_d` → `docs\u002Fstyle-guide.md` (\u003Csection>): \u003Crationale>\n- `old_e` → `.claude\u002Fskills\u002Freview-pr\u002FSKILL.md` (\"What NOT to flag\"): \u003Crationale>\n\n## Added\n- `new_f`: \u003Cpattern + which sessions surfaced it>\n\n## Net\nBefore: \u003CN> entries, index \u003CK> KB. After: \u003CM> entries, index \u003CK'> KB.\n```\n\n### 8. Report\n\nGive the user the PR URL, the before\u002Fafter numbers, and the top 3–5 changes worth their attention (highest-impact merges, riskiest drops, notable promotions). Note that review\u002Frollback is via the PR and git — there is no separate file backup to manage.\n\n## Notes\n\n- **Git is the safety net.** Rollback is `git checkout main` \u002F closing the PR; history is the backup. Don't reintroduce file backups, staging dirs, or `mv`\u002F`rm -rf` swaps — they were a workaround for a non-versioned store and broke under the `.claude\u002Fmemory\u002F` symlink.\n- A curated store changes prefix bytes → the next session pays one cold `cache_create` on the new index; subsequent sessions warm-hit the smaller prefix.\n- Frequency: monthly is plenty for routine curation; run on demand when memory volume crosses a discomfort threshold, or right after a stretch of sessions that generated many new entries.\n\n## Future: out-of-session API equivalent\n\nA v2 could call the Anthropic API from a separate process (using `ANTHROPIC_API_KEY`) so the curation doesn't burn the current session's plan tokens. The contract — memory + sessions in, curated memory + promotions out as a PR — stays the same.\n","# Dream: curate the project memory store\n\nRead the project's memory store and recent session transcripts, then **apply** a curated memory store plus any theme promotions directly to the repo on a branch and open a PR. Memory lives in the git-tracked `.claude\u002Fmemory\u002F` directory, so every change is version-controlled — the PR is the review gate, and `git` is the backup and rollback path. There is no staging directory, no file backup, and no swap\u002Fprune dance.\n\nModeled on Anthropic's Managed Agents Dreams API (`platform.claude.com\u002Fdocs\u002Fen\u002Fmanaged-agents\u002Fdreams`). The API version operates on managed `memory_store` and `session` resources; this skill operates on the in-repo memory store and local session transcripts.\n\n## Inputs\n\n- **Memory store (in repo, version-controlled):** `$(git rev-parse --show-toplevel)\u002F.claude\u002Fmemory\u002F*.md`, index in `MEMORY.md`. This is the source of truth and the thing you edit — **not** the runtime `~\u002F.claude\u002Fprojects\u002F\u003Cslug>\u002Fmemory\u002F` path (that's a symlink into here; editing it directly is the bug this skill was rewritten to avoid).\n- **Sessions (optional, up to ~100):** recent JSONL transcripts under `~\u002F.claude\u002Fprojects\u002F$(pwd | tr '\u002F' '-')\u002F*.jsonl`. These are *not* in the repo. Mine them for patterns to fold into the store.\n- **Instructions (optional):** the user can scope the curation, e.g. \"focus on coding-style preferences; ignore one-off debugging notes.\"\n\nInvoking `\u002Fdream` is the authorization to curate, commit, push, and open a PR. The PR — not a mid-run prompt — is where the user reviews and approves. Never merge the PR (that is the user's, always).\n\n## Procedure\n\n### 1. Branch\n\nVM-per-ticket default — plain branch from the repo root:\n\n```bash\ngit checkout -b \u003Cuser>\u002Fdream-curate-memory-\u003CYYYY-MM-DD>\n```\n\n(Laptop-fallback worktree mechanics, if applicable, follow the repo's normal branching convention.)\n\n### 2. Inventory the current store\n\n```bash\nMEM=\"$(git rev-parse --show-toplevel)\u002F.claude\u002Fmemory\"\nls \"$MEM\"\u002F*.md | grep -v MEMORY.md | wc -l\nwc -c \"$MEM\u002FMEMORY.md\"\nSESS=~\u002F.claude\u002Fprojects\u002F$(pwd | tr '\u002F' '-')\nls \"$SESS\"\u002F*.jsonl 2>\u002Fdev\u002Fnull | wc -l\n```\n\nRead `MEMORY.md` and each entry body. Understand the store before changing it.\n\n### 3. Identify candidates\n\nFour dispositions:\n\n- **Merge** — entries that say the same thing in different words, or cover the same rule from different angles (e.g. several proto-feedback entries → one; several naming-preference entries → one per coherent rule).\n- **Drop** — entries that are superseded by newer state, contradicted by current code, about files\u002Fsymbols\u002Fflags that no longer exist, already captured in committed code (an ADR, `docs\u002Fstyle-guide.md`, a service doc, a skill `SKILL.md`), or narrow \u002F non-recurring (a one-off gotcha that won't recur often enough to earn its context cost).\n- **Promote** — durable, project-wide rules that *aren't* already in committed code and should be. **Memory is not the home for durable conventions.** If a rule is load-bearing, promote it to docs\u002F or a skill **and drop it from memory in the same PR** (see step 5). Typical homes:\n  - Coding conventions → `docs\u002Fstyle-guide.md`\n  - Algorithm \u002F design rationale → `docs\u002Falgorithms.md`, `docs\u002Fdesign-decisions.md`, or a new ADR under `docs\u002Fdecisions\u002F`\n  - Service-specific design → `docs\u002Fservices\u002F\u003Cservice>.md`\n  - Recurring review pushbacks → `.claude\u002Fskills\u002Freview-pr\u002FSKILL.md` (\"What NOT to flag\" or the relevant step)\n  - Recurring planning rules → `.claude\u002Fskills\u002Fdo-issue\u002FSKILL.md`\n  - **Corrections to a skill's own cheat-sheet\u002Finstructions** → fix that skill directly. An entry that only exists because a skill's text is wrong retires the moment the skill is fixed — this is the highest-value promotion.\n- **Add** — patterns visible in recent sessions not yet in memory: repeated corrections, enthusiastically-accepted preferences, project-state facts (incidents, deadlines) future sessions need.\n\nMemory should be tight. Default each candidate to the strictest disposition that fits — **promote** beats **keep** for any project-wide convention; **drop** beats **promote** for narrow gotchas.\n\n### 4. Verify before changing\n\nCode state is authoritative; do not drop or rewrite based on assumption.\n- A memory cites a file path → confirm it exists (or doesn't).\n- A memory cites a symbol → grep for it.\n- A memory cites a deadline \u002F \"verified \u003Cdate>\" → check it against today.\n- A memory claims a skill says X → read that skill and confirm before \"fixing\" it (the skill may already have changed).\n\nIf a rule is still valid but a cited symbol drifted, refresh the reference rather than dropping the rule.\n\n### 5. Apply the changes in `.claude\u002Fmemory\u002F` (and promotion targets)\n\nEdit the in-repo store directly:\n- **Merge:** write the new combined entry, delete the merged-away files (`git rm` or `rm`), update any `[[links]]` in surviving entries that pointed at removed slugs, and update `MEMORY.md`.\n- **Drop:** delete the files, update `MEMORY.md`.\n- **Add:** write new entries (same frontmatter contract — `name`, `description`, `metadata.type`), add their index lines to `MEMORY.md`.\n- **Promote:** apply the rule to its named target file (match the surrounding section style; never paste memory frontmatter into committed docs), **and delete the now-redundant memory entry in the same PR**, removing its `MEMORY.md` line. Because the docs change and the memory drop land atomically in one PR, there is no \"retire later\" deferral — that two-phase dance only existed when the store wasn't version-controlled. (Until the PR merges, `main` still carries the entry, so nothing is lost if the PR is revised.)\n\nKeep `MEMORY.md` in sync with the actual file set — every index link must resolve, and every entry file must be indexed. Verify before committing:\n\n```bash\nMEM=\"$(git rev-parse --show-toplevel)\u002F.claude\u002Fmemory\"\n# index links that don't resolve to a file:\ngrep -oE '\\(([a-z0-9_]+\\.md)\\)' \"$MEM\u002FMEMORY.md\" | tr -d '()' | sort -u | \\\n  while read f; do [ -f \"$MEM\u002F$f\" ] || echo \"MISSING: $f\"; done\n# files vs index (empty = perfect match):\ncomm -3 \u003C(grep -oE '\\(([a-z0-9_]+\\.md)\\)' \"$MEM\u002FMEMORY.md\" | tr -d '()' | sort -u) \\\n        \u003C(ls \"$MEM\"\u002F*.md | xargs -n1 basename | grep -v MEMORY.md | sort)\n# no dangling [[links]] to removed slugs:\ngrep -rn '\\[\\[' \"$MEM\"\u002F*.md\n```\n\nDo **not** write a `CHANGELOG.md` into `.claude\u002Fmemory\u002F` — the change log is the PR body (step 7), not a committed memory file.\n\n### 6. Commit\n\nFollow the repo's commit conventions (conventional commits; scope from `linear\u002Flabels.toml` — memory\u002Fskill changes use `docs(agent)`; omit scope when a change spans areas). Separate commits read best:\n- one `docs(agent)` commit for the memory curation (merges \u002F drops \u002F adds \u002F link fixes),\n- one commit per promotion target group (e.g. `docs:` for `docs\u002Fstyle-guide.md`, `docs(agent):` for skill-text fixes), each dropping the corresponding memory entries.\n\nRun any commit-msg\u002Fpre-commit hooks; fix subject-length \u002F type \u002F scope rejections rather than bypassing them.\n\n### 7. Open the PR\n\nPush the branch and open a PR (`gh pr create`; if `gh pr edit` is broken in this env, use `gh api -X PATCH` for later body edits). Stop after opening it — **never merge** (the user merges). The PR body is the change log:\n\n```markdown\n## Summary\n\u003Cone-line: dream curation + promotions for \u003CYYYY-MM-DD>>\n\n## Merged (N → M)\n- `old_a` + `old_b` → `new`: \u003Crationale>\n\n## Dropped — already captured \u002F stale \u002F narrow\n- `old_c`: \u003Cwhich doc\u002FADR\u002Fskill covers it, or why it's stale (with the verification)>\n\n## Promoted (rule moved to committed code; memory entry removed here)\n- `old_d` → `docs\u002Fstyle-guide.md` (\u003Csection>): \u003Crationale>\n- `old_e` → `.claude\u002Fskills\u002Freview-pr\u002FSKILL.md` (\"What NOT to flag\"): \u003Crationale>\n\n## Added\n- `new_f`: \u003Cpattern + which sessions surfaced it>\n\n## Net\nBefore: \u003CN> entries, index \u003CK> KB. After: \u003CM> entries, index \u003CK'> KB.\n```\n\n### 8. Report\n\nGive the user the PR URL, the before\u002Fafter numbers, and the top 3–5 changes worth their attention (highest-impact merges, riskiest drops, notable promotions). Note that review\u002Frollback is via the PR and git — there is no separate file backup to manage.\n\n## Notes\n\n- **Git is the safety net.** Rollback is `git checkout main` \u002F closing the PR; history is the backup. Don't reintroduce file backups, staging dirs, or `mv`\u002F`rm -rf` swaps — they were a workaround for a non-versioned store and broke under the `.claude\u002Fmemory\u002F` symlink.\n- A curated store changes prefix bytes → the next session pays one cold `cache_create` on the new index; subsequent sessions warm-hit the smaller prefix.\n- Frequency: monthly is plenty for routine curation; run on demand when memory volume crosses a discomfort threshold, or right after a stretch of sessions that generated many new entries.\n\n## Future: out-of-session API equivalent\n\nA v2 could call the Anthropic API from a separate process (using `ANTHROPIC_API_KEY`) so the curation doesn't burn the current session's plan tokens. The contract — memory + sessions in, curated memory + promotions out as a PR — stays the same.\n",{"name":5,"description":7,"allowed-tools":24},"Bash Read Write Edit Glob Grep","main","5857ef2d015e3d9011c5e73b01660da6043e0f0e",".claude\u002Fskills\u002Fdream",0,"https:\u002F\u002Fgithub.com\u002Fpenca-io\u002Fpenca","https:\u002F\u002Fpenca.io\u002F","https:\u002F\u002Fgithub.com\u002Fpenca-io","https:\u002F\u002Fpenca.io","2026-08-01 08:29:37",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add penca-io\u002Fpenca --skill dream",{"tool":40,"command":41},"bunx","bunx skills add penca-io\u002Fpenca --skill dream",{"tool":43,"command":44},"pnpm","pnpm dlx skills add penca-io\u002Fpenca --skill dream","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpenca-io\u002Fpenca\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdream\u002FSKILL.md",true,[],[49,56,63,70,77,84],{"skillNo":50,"name":51,"nameZh":6,"description":52,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":53,"categories":54,"keywords":55,"publishedAt":19},"01M79FNA3MSFZJJEY8K32KJ7VG","tracing-instrument","Add structured `tracing`-crate instrumentation (spans + events + fields) to Penca Rust code — one combined plan emitted as kata tasks under `cha-NNN plan-draft` and gated once by `\u002Fplan-reviewer`, then one branch carrying every site as its own commit drained from the approved kata queue, gated once by `just check` at PR open. Scope is the `tracing` crate only (logs-as-events + spans); metrics and OpenTelemetry are out of scope. Use for observability tickets, ad-hoc instrumentation passes on a crate, or as the `\u002Fdo-issue` `orch:run-cleanup` cleanup-context pass.","https:\u002F\u002Fgithub.com\u002Fpenca-io\u002Fpenca\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftracing-instrument\u002FSKILL.md",[],[],{"skillNo":57,"name":58,"nameZh":6,"description":59,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":19},"01M79FN8FWKKYX3PG3MPHFBMSP","test","Run the test suite with pytest","https:\u002F\u002Fgithub.com\u002Fpenca-io\u002Fpenca\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftest\u002FSKILL.md",[],[],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":19},"01M79FN4G6C2KG7D737QDQCJFM","software-architect","High-level architecture analysis for Penca design questions — bounded contexts, microservice boundaries, cross-service interfaces, storage tier separations (hot vs cold), CQRS-shaped splits, design-stamina trade-offs, and incremental-replacement strategies. Use when a Linear ticket needs design framing, when an existing plan has a structural concern, or when a proposed change crosses bounded-context boundaries. Advisory — does not edit code.","https:\u002F\u002Fgithub.com\u002Fpenca-io\u002Fpenca\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsoftware-architect\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M79FN1Y86PSSG0A6A4QZSVKW","save-memory","Save or update a memory entry. Always targets the **current repo root's** `.claude\u002Fmemory\u002F`, resolved via `git rev-parse --show-toplevel`; never the runtime `~\u002F.claude\u002Fprojects\u002F\u003Cslug>\u002Fmemory\u002F` path.","https:\u002F\u002Fgithub.com\u002Fpenca-io\u002Fpenca\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsave-memory\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":19},"01M79FMXG15K3SFKP8FVYASF8Q","review-pr","Review a Penca PR against project conventions and architecture","https:\u002F\u002Fgithub.com\u002Fpenca-io\u002Fpenca\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freview-pr\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M79FMQVW8TEK002D5SY7N22Z","plan-reviewer","Audit a Penca `\u002Fdo-issue` plan — a set of kata tasks under `cha-NNN plan-draft` — for the mechanism-bound rule + dependency-graph sanity. Use after `\u002Fdo-issue` Step 2 emits the task set and before the user flips `plan-draft` → `approved`. Checks that every task names symbols\u002Ffiles to change AND symbols the new code path must invoke, has mechanism non-goals where relevant, avoids parallel-path workarounds, and that every implementation task is `--blocked-by` at least one red-test task with no cycles in the graph.","https:\u002F\u002Fgithub.com\u002Fpenca-io\u002Fpenca\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplan-reviewer\u002FSKILL.md",[],[]]