self-evolve-framework 1.1.0 → 1.1.1

package/template/skills/request-refactor-plan/SKILL.md

@@ -1,68 +0,0 @@
----
-name: request-refactor-plan
-description: Create a detailed refactor plan with tiny commits via user interview, then file it as a GitHub issue. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.
----
-
-This skill will be invoked when the user wants to create a refactor request. You should go through the steps below. You may skip steps if you don't consider them necessary.
-
-1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
-
-2. Explore the repo to verify their assertions and understand the current state of the codebase.
-
-3. Ask whether they have considered other options, and present other options to them.
-
-4. Interview the user about the implementation. Be extremely detailed and thorough.
-
-5. Hammer out the exact scope of the implementation. Work out what you plan to change and what you plan not to change.
-
-6. Look in the codebase to check for test coverage of this area of the codebase. If there is insufficient test coverage, ask the user what their plans for testing are.
-
-7. Break the implementation into a plan of tiny commits. Remember Martin Fowler's advice to "make each refactoring step as small as possible, so that you can always see the program working."
-
-8. Create a GitHub issue with the refactor plan. Use the following template for the issue description:
-
-<refactor-plan-template>
-
-## Problem Statement
-
-The problem that the developer is facing, from the developer's perspective.
-
-## Solution
-
-The solution to the problem, from the developer's perspective.
-
-## Commits
-
-A LONG, detailed implementation plan. Write the plan in plain English, breaking down the implementation into the tiniest commits possible. Each commit should leave the codebase in a working state.
-
-## Decision Document
-
-A list of implementation decisions that were made. This can include:
-
-- The modules that will be built/modified
-- The interfaces of those modules that will be modified
-- Technical clarifications from the developer
-- Architectural decisions
-- Schema changes
-- API contracts
-- Specific interactions
-
-Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
-
-## Testing Decisions
-
-A list of testing decisions that were made. Include:
-
-- A description of what makes a good test (only test external behavior, not implementation details)
-- Which modules will be tested
-- Prior art for the tests (i.e. similar types of tests in the codebase)
-
-## Out of Scope
-
-A description of the things that are out of scope for this refactor.
-
-## Further Notes (optional)
-
-Any further notes about the refactor.
-
-</refactor-plan-template>

package/template/skills/review/SKILL.md

@@ -1,78 +0,0 @@
----
-name: review
-description: Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
----
-
-# Review
-
-Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
-
-- **Standards** — does the code conform to this repo's documented coding standards?
-- **Spec** — does the code faithfully implement the originating issue / PRD / spec?
-
-Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.
-
-The issue tracker should have been provided to you — run `/setup-matt-pocock-skills` if `docs/agents/issue-tracker.md` is missing.
-
-## Process
-
-### 1. Pin the fixed point
-
-Whatever the user said is the fixed point — a commit SHA, branch name, tag, `main`, `HEAD~5`, etc. Don't be opinionated; pass it through. If they didn't specify one, ask: "Review against what — a branch, a commit, or `main`?" Don't proceed until you have it.
-
-Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.
-
-### 2. Identify the spec source
-
-Look for the originating spec, in this order:
-
-1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.) — fetch via the workflow in `docs/agents/issue-tracker.md`.
-2. A path the user passed as an argument.
-3. A PRD/spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.
-4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available".
-
-### 3. Identify the standards sources
-
-Anything in the repo that documents how code should be written. Common locations:
-
-- `CLAUDE.md`, `AGENTS.md`
-- `CONTRIBUTING.md`
-- `CONTEXT.md`, `CONTEXT-MAP.md`, per-context `CONTEXT.md` files
-- `docs/adr/` (architectural decisions are standards)
-- `.editorconfig`, `eslint.config.*`, `biome.json`, `prettier.config.*`, `tsconfig.json` (machine-enforced standards — note them but don't re-check what tooling already checks)
-- Any `STYLE.md`, `STANDARDS.md`, `STYLEGUIDE.md`, or similar at the repo root or under `docs/`
-
-Collect the list of files. The **Standards** sub-agent will read them.
-
-### 4. Spawn both sub-agents in parallel
-
-Send a single message with two `Agent` tool calls. Use the `general-purpose` subagent for both.
-
-**Standards sub-agent prompt** — include:
-
-- The full diff command and commit list.
-- The list of standards-source files you found in step 3.
-- The brief: "Read the standards docs. Then read the diff. Report — per file/hunk where relevant — every place the diff violates a documented standard. Cite the standard (file + the rule). Distinguish hard violations from judgement calls. Skip anything tooling enforces. Under 400 words."
-
-**Spec sub-agent prompt** — include:
-
-- The diff command and commit list.
-- The path or fetched contents of the spec.
-- The brief: "Read the spec. Then read the diff. Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
-
-If the spec is missing, skip the Spec sub-agent and note this in the final report.
-
-### 5. Aggregate
-
-Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings — the two axes are deliberately separate so the user can see them independently.
-
-End with a one-line summary: total findings per axis, and the worst single issue (if any) flagged.
-
-## Why two axes
-
-A change can pass one axis and fail the other:
-
-- Code that follows every standard but implements the wrong thing → **Standards pass, Spec fail.**
-- Code that does exactly what the issue asked but breaks the project's conventions → **Spec pass, Standards fail.**
-
-Reporting them separately stops one axis from masking the other.

package/template/skills/rust-auto-fix/SKILL.md

@@ -1,94 +0,0 @@
----
-name: fix:rust-auto
-description: Read Rust plugin (rust-analyzer) diagnostics from the IDE and automatically fix detected issues. Use when the user mentions Rust errors, type mismatches, cargo check failures, compiler warnings, rust-analyzer problems, or asks to fix Rust compilation issues in the src-tauri directory.
----
-
-# Rust Auto-Fix
-
-## Diagnostics collection (dual channel)
-
-1. **Fast path** — `read_lints(paths="d:/code/sheetflow/src-tauri")` 读 IDE 实时诊断
-2. **Confirmation** — `cd d:/code/sheetflow/src-tauri && cargo check 2>&1` 获取编译器真实输出
-
-## Categorize
-
-按严重程度分组：
-
-- **Config/Macro errors** — `proc macro panicked`（非代码问题）
-- **Code errors** — type mismatches, borrow checker, missing items
-- **Warnings** — unused imports, unnecessary `mut`, dead code
-- **Hints** — cargo fix suggestions
-
-## Fix workflow
-
-### Phase A: Auto-fix warnings with `cargo fix`
-
-先跑 `cargo fix` 自动处理可修复的 warning，大幅减少手动工作：
-
-```
-cd d:/code/sheetflow/src-tauri && cargo fix --lib -p sheetflow --allow-dirty 2>&1
-```
-
-完成后 re-check 确认剩余警告。
-
-### Phase B: Handle config/macro errors
-
-`proc macro panicked` 通常是外部原因，不是 Rust 代码问题：
-
-| 错误信息 | 非代码原因 | 处理方式 |
-|----------|-----------|---------|
-| `frontendDist` 路径不存在 | 前端未构建 | `npm run build` 创建 `build/` |
-| `identifier` 格式错误 | `tauri.conf.json` 配置 | 手动检查配置文件 |
-| 其他 macro panic | 依赖版本或配置 | 优先检查外部因素再怀疑代码 |
-
-当确认是前端构建问题时，可以调用 `svelte-warnings-fix` 协作修复。
-
-### Phase C: Fix code errors (one category at a time)
-
-按优先级批量处理同类错误，同类修复完再 rescan：
-
-1. **Type mismatches** — `expected X, found Y`
-2. **Borrow checker** — `cannot borrow`, `cannot move`
-3. **Missing items** — `not found`, `unresolved import`
-4. **Other errors**
-
-修复模式：
-1. `read_file` 定位错误行
-2. 理解上下文
-3. `replace_in_file` 最小改动
-4. 同类全部修完后 → `cargo check` 全量验证
-
-### Phase D: Handle remaining warnings
-
-对 `dead_code` 警告，按规则决定处理方式：
-
-| 场景 | 做法 |
-|------|------|
-| `pub struct` 公开 API 的字段 | `#[allow(dead_code)]` 保留 |
-| `pub struct` 公开 API 的整个 struct | `#[allow(dead_code)]` 保留 |
-| 私有 struct/函数，确定未用 | 删除代码 |
-| `pub fn` Tauri 命令参数（如 `_cache`） | 保留或用 `_` 前缀命名 |
-| `cache.rs` 整模块未用 | 加 `#![allow(dead_code)]` 模块级注解 |
-
-### Phase E: Final verification
-
-```
-cargo check 2>&1
-```
-
-确认零错误零警告后输出最终报告。
-
-## Final report
-
-```
-## Rust diagnostics resolved
-
-[cargo-fix]  cargo fix 自动处理: X 项
-[manual]  手动修复类型错误: Y 项
-[allow]   添加 #[allow(dead_code)]: Z 处
-
-Changes:
-- file.rs: cargo fix 自动处理
-- file.rs: 手动修复 mismatched types
-- file.rs: 添加 #[allow(dead_code)]
-```

package/template/skills/scaffold-exercises/SKILL.md

@@ -1,106 +0,0 @@
----
-name: scaffold-exercises
-description: Create exercise directory structures with sections, problems, solutions, and explainers that pass linting. Use when user wants to scaffold exercises, create exercise stubs, or set up a new course section.
----
-
-# Scaffold Exercises
-
-Create exercise directory structures that pass `pnpm ai-hero-cli internal lint`, then commit with `git commit`.
-
-## Directory naming
-
-- **Sections**: `XX-section-name/` inside `exercises/` (e.g., `01-retrieval-skill-building`)
-- **Exercises**: `XX.YY-exercise-name/` inside a section (e.g., `01.03-retrieval-with-bm25`)
-- Section number = `XX`, exercise number = `XX.YY`
-- Names are dash-case (lowercase, hyphens)
-
-## Exercise variants
-
-Each exercise needs at least one of these subfolders:
-
-- `problem/` - student workspace with TODOs
-- `solution/` - reference implementation
-- `explainer/` - conceptual material, no TODOs
-
-When stubbing, default to `explainer/` unless the plan specifies otherwise.
-
-## Required files
-
-Each subfolder (`problem/`, `solution/`, `explainer/`) needs a `readme.md` that:
-
-- Is **not empty** (must have real content, even a single title line works)
-- Has no broken links
-
-When stubbing, create a minimal readme with a title and a description:
-
-```md
-# Exercise Title
-
-Description here
-```
-
-If the subfolder has code, it also needs a `main.ts` (>1 line). But for stubs, a readme-only exercise is fine.
-
-## Workflow
-
-1. **Parse the plan** - extract section names, exercise names, and variant types
-2. **Create directories** - `mkdir -p` for each path
-3. **Create stub readmes** - one `readme.md` per variant folder with a title
-4. **Run lint** - `pnpm ai-hero-cli internal lint` to validate
-5. **Fix any errors** - iterate until lint passes
-
-## Lint rules summary
-
-The linter (`pnpm ai-hero-cli internal lint`) checks:
-
-- Each exercise has subfolders (`problem/`, `solution/`, `explainer/`)
-- At least one of `problem/`, `explainer/`, or `explainer.1/` exists
-- `readme.md` exists and is non-empty in the primary subfolder
-- No `.gitkeep` files
-- No `speaker-notes.md` files
-- No broken links in readmes
-- No `pnpm run exercise` commands in readmes
-- `main.ts` required per subfolder unless it's readme-only
-
-## Moving/renaming exercises
-
-When renumbering or moving exercises:
-
-1. Use `git mv` (not `mv`) to rename directories - preserves git history
-2. Update the numeric prefix to maintain order
-3. Re-run lint after moves
-
-Example:
-
-```bash
-git mv exercises/01-retrieval/01.03-embeddings exercises/01-retrieval/01.04-embeddings
-```
-
-## Example: stubbing from a plan
-
-Given a plan like:
-
-```
-Section 05: Memory Skill Building
-- 05.01 Introduction to Memory
-- 05.02 Short-term Memory (explainer + problem + solution)
-- 05.03 Long-term Memory
-```
-
-Create:
-
-```bash
-mkdir -p exercises/05-memory-skill-building/05.01-introduction-to-memory/explainer
-mkdir -p exercises/05-memory-skill-building/05.02-short-term-memory/{explainer,problem,solution}
-mkdir -p exercises/05-memory-skill-building/05.03-long-term-memory/explainer
-```
-
-Then create readme stubs:
-
-```
-exercises/05-memory-skill-building/05.01-introduction-to-memory/explainer/readme.md -> "# Introduction to Memory"
-exercises/05-memory-skill-building/05.02-short-term-memory/explainer/readme.md -> "# Short-term Memory"
-exercises/05-memory-skill-building/05.02-short-term-memory/problem/readme.md -> "# Short-term Memory"
-exercises/05-memory-skill-building/05.02-short-term-memory/solution/readme.md -> "# Short-term Memory"
-exercises/05-memory-skill-building/05.03-long-term-memory/explainer/readme.md -> "# Long-term Memory"
-```

package/template/skills/sdd-dev/SKILL.md

@@ -1,114 +0,0 @@
----
-name: sdd-dev
-description: |
-  Spec-Driven Development — generate code from PRD/idea via a structured DESIGN.md spec.
-  Use when the user asks to "generate frontend code", "design a page", "create a component",
-  "按照规范生成", or any feature request that needs both spec and implementation.
----
-
-# Spec-Driven Development (SDD)
-
-流程：需求 → 规范（DESIGN.md）→ 审批 → 代码生成 → 自检
-
-## Phase A: 理解输入
-
-收集设计线索。输入可以是以下任意组合：
-
-1. **PRD / 需求描述** — 功能列表、用户故事
-2. **参考 URL** — 可访问的线上页面
-3. **截图/设计稿** — 描述你看到的布局和风格
-4. **品牌名称 / 关键词** — 如"工务平台"、"数据分析"
-5. **已有组件库** — 如 ant-design-vue
-
-如果输入稀疏，使用以下项目已有设计线索作为 fallback：
-- `:root` CSS 变量（App.vue）：颜色、字体、圆角、间距
-- `RULES.md`：设计约束（统一风格、响应式强制、多页面一致性）
-- 现有页面样式作为参考
-
-**在此阶段不要生成任何代码。**
-
-## Phase B: 输出 DESIGN.md
-
-产出一份完整的设计规范文档，存放在 `docs/design/` 目录下，包含以下 **9 个章节**：
-
-### 1. 色彩（Color）
-- 主色调、辅助色、语义色（成功/错误/警告）
-- 引用 `:root` 已有的 `--primary-color` / `--success-color` 等变量
-- 禁止引入全新的颜色体系，除非确实必要
-
-### 2. 字体（Type）
-- 使用 `var(--font-sans)` 和 `var(--font-mono)`
-- 字号层级：`--font-size-xs/sm/base/lg/xl`
-- 行高、字重
-
-### 3. 组件（Component）
-- 使用 ant-design-vue 组件优先
-- 自定义组件的样式继承 `:root` token
-- 每个组件的状态：默认、悬停、禁用、加载
-
-### 4. 布局（Layout）
-- 使用 CSS Grid / Flexbox
-- 响应式断点：`820px` / `480px`
-- 间距使用 `var(--space-xs/sm/md/lg/xl)`
-
-### 5. 动效（Motion）
-- 过渡时长：0.15s / 0.2s / 0.3s
-- 缓动函数：ease-in-out
-- 悬停效果：translateY(-2px) + box-shadow
-
-### 6. 深度（Depth）
-- 阴影层级：卡片（sm）、弹窗（md）、Drawer（lg）
-- Z-index 层级约定
-
-### 7. 最佳实践 & 禁止事项（Do's & Don'ts）
-- 做：引用 `:root` 变量、用设计 token
-- 不做：硬编码颜色/尺寸、在 scoped 中定义新 token
-
-### 8. 响应式（Responsive）
-- 820px：侧栏折叠、2 列变 1 列
-- 480px：字体缩小、触控友好的点击区域（≥44px）
-
-### 9. 无障碍（Accessibility）
-- 颜色对比度
-- 焦点可见
-- 语义化 HTML
-
-**将 DESIGN.md 展示给用户审批前，不允许进入 Phase C。**
-
-## Phase C: 代码生成
-
-严格遵循已审批的 DESIGN.md 生成代码。
-
-### 代码质量自检清单（100 分制）
-
-| 检查项 | 分值 | 说明 |
-|--------|------|------|
-| 使用 `:root` 变量而非硬编码值 | 15 | 颜色、字体、间距、圆角必须用 var() |
-| 响应式布局 | 15 | 820px 和 480px 下正常 |
-| 组件复用 | 10 | 优先使用 ant-design-vue 已有组件 |
-| 语义化 HTML | 10 | 正确使用 header/main/section/nav |
-| CSS 使用 token | 10 | 无硬编码尺寸 |
-| 悬停/聚焦效果 | 10 | 所有可交互元素有视觉反馈 |
-| 动画过渡 | 10 | 适当使用 transition |
-| 无重复样式 | 10 | 无相同值重复声明 |
-| 命名规范 | 5 | 组件 PascalCase 等 |
-| 无障碍基础 | 5 | focus-visible、aria 属性 |
-
-得分低于 70 分时必须修改。
-
-### diff 审计（如果提供了参考 URL）
-将生成代码与参考页面的截图或描述进行对比，标注差异。
-
-## 文件产出位置
-
-```
-src/pages/      — 新页面
-src/components/ — 新组件
-docs/design/    — DESIGN.md 规范文档
-```
-
-## 参考
-
-- 项目设计 token：App.vue `:root` 变量
-- 设计约束：`RULES.md`
-- 组件库：ant-design-vue（已全局注册）

package/template/skills/setup-matt-pocock-skills/SKILL.md

@@ -1,121 +0,0 @@
----
-name: setup-matt-pocock-skills
-description: Sets up an `## Agent skills` block in AGENTS.md/CLAUDE.md and `docs/agents/` so the engineering skills know this repo's issue tracker (GitHub or local markdown), triage label vocabulary, and domain doc layout. Run before first use of `to-issues`, `to-prd`, `triage`, `diagnose`, `tdd`, `improve-codebase-architecture`, or `zoom-out` — or if those skills appear to be missing context about the issue tracker, triage labels, or domain docs.
-disable-model-invocation: true
----
-
-# Setup Matt Pocock's Skills
-
-Scaffold the per-repo configuration that the engineering skills assume:
-
-- **Issue tracker** — where issues live (GitHub by default; local markdown is also supported out of the box)
-- **Triage labels** — the strings used for the five canonical triage roles
-- **Domain docs** — where `CONTEXT.md` and ADRs live, and the consumer rules for reading them
-
-This is a prompt-driven skill, not a deterministic script. Explore, present what you found, confirm with the user, then write.
-
-## Process
-
-### 1. Explore
-
-Look at the current repo to understand its starting state. Read whatever exists; don't assume:
-
-- `git remote -v` and `.git/config` — is this a GitHub repo? Which one?
-- `AGENTS.md` and `CLAUDE.md` at the repo root — does either exist? Is there already an `## Agent skills` section in either?
-- `CONTEXT.md` and `CONTEXT-MAP.md` at the repo root
-- `docs/adr/` and any `src/*/docs/adr/` directories
-- `docs/agents/` — does this skill's prior output already exist?
-- `.scratch/` — sign that a local-markdown issue tracker convention is already in use
-
-### 2. Present findings and ask
-
-Summarise what's present and what's missing. Then walk the user through the three decisions **one at a time** — present a section, get the user's answer, then move to the next. Don't dump all three at once.
-
-Assume the user does not know what these terms mean. Each section starts with a short explainer (what it is, why these skills need it, what changes if they pick differently). Then show the choices and the default.
-
-**Section A — Issue tracker.**
-
-> Explainer: The "issue tracker" is where issues live for this repo. Skills like `to-issues`, `triage`, `to-prd`, and `qa` read from and write to it — they need to know whether to call `gh issue create`, write a markdown file under `.scratch/`, or follow some other workflow you describe. Pick the place you actually track work for this repo.
-
-Default posture: these skills were designed for GitHub. If a `git remote` points at GitHub, propose that. If a `git remote` points at GitLab (`gitlab.com` or a self-hosted host), propose GitLab. Otherwise (or if the user prefers), offer:
-
-- **GitHub** — issues live in the repo's GitHub Issues (uses the `gh` CLI)
-- **GitLab** — issues live in the repo's GitLab Issues (uses the [`glab`](https://gitlab.com/gitlab-org/cli) CLI)
-- **Local markdown** — issues live as files under `.scratch/<feature>/` in this repo (good for solo projects or repos without a remote)
-- **Other** (Jira, Linear, etc.) — ask the user to describe the workflow in one paragraph; the skill will record it as freeform prose
-
-**Section B — Triage label vocabulary.**
-
-> Explainer: When the `triage` skill processes an incoming issue, it moves it through a state machine — needs evaluation, waiting on reporter, ready for an AFK agent to pick up, ready for a human, or won't fix. To do that, it needs to apply labels (or the equivalent in your issue tracker) that match strings *you've actually configured*. If your repo already uses different label names (e.g. `bug:triage` instead of `needs-triage`), map them here so the skill applies the right ones instead of creating duplicates.
-
-The five canonical roles:
-
-- `needs-triage` — maintainer needs to evaluate
-- `needs-info` — waiting on reporter
-- `ready-for-agent` — fully specified, AFK-ready (an agent can pick it up with no human context)
-- `ready-for-human` — needs human implementation
-- `wontfix` — will not be actioned
-
-Default: each role's string equals its name. Ask the user if they want to override any. If their issue tracker has no existing labels, the defaults are fine.
-
-**Section C — Domain docs.**
-
-> Explainer: Some skills (`improve-codebase-architecture`, `diagnose`, `tdd`) read a `CONTEXT.md` file to learn the project's domain language, and `docs/adr/` for past architectural decisions. They need to know whether the repo has one global context or multiple (e.g. a monorepo with separate frontend/backend contexts) so they look in the right place.
-
-Confirm the layout:
-
-- **Single-context** — one `CONTEXT.md` + `docs/adr/` at the repo root. Most repos are this.
-- **Multi-context** — `CONTEXT-MAP.md` at the root pointing to per-context `CONTEXT.md` files (typically a monorepo).
-
-### 3. Confirm and edit
-
-Show the user a draft of:
-
-- The `## Agent skills` block to add to whichever of `CLAUDE.md` / `AGENTS.md` is being edited (see step 4 for selection rules)
-- The contents of `docs/agents/issue-tracker.md`, `docs/agents/triage-labels.md`, `docs/agents/domain.md`
-
-Let them edit before writing.
-
-### 4. Write
-
-**Pick the file to edit:**
-
-- If `CLAUDE.md` exists, edit it.
-- Else if `AGENTS.md` exists, edit it.
-- If neither exists, ask the user which one to create — don't pick for them.
-
-Never create `AGENTS.md` when `CLAUDE.md` already exists (or vice versa) — always edit the one that's already there.
-
-If an `## Agent skills` block already exists in the chosen file, update its contents in-place rather than appending a duplicate. Don't overwrite user edits to the surrounding sections.
-
-The block:
-
-```markdown
-## Agent skills
-
-### Issue tracker
-
-[one-line summary of where issues are tracked]. See `docs/agents/issue-tracker.md`.
-
-### Triage labels
-
-[one-line summary of the label vocabulary]. See `docs/agents/triage-labels.md`.
-
-### Domain docs
-
-[one-line summary of layout — "single-context" or "multi-context"]. See `docs/agents/domain.md`.
-```
-
-Then write the three docs files using the seed templates in this skill folder as a starting point:
-
-- [issue-tracker-github.md](./issue-tracker-github.md) — GitHub issue tracker
-- [issue-tracker-gitlab.md](./issue-tracker-gitlab.md) — GitLab issue tracker
-- [issue-tracker-local.md](./issue-tracker-local.md) — local-markdown issue tracker
-- [triage-labels.md](./triage-labels.md) — label mapping
-- [domain.md](./domain.md) — domain doc consumer rules + layout
-
-For "other" issue trackers, write `docs/agents/issue-tracker.md` from scratch using the user's description.
-
-### 5. Done
-
-Tell the user the setup is complete and which engineering skills will now read from these files. Mention they can edit `docs/agents/*.md` directly later — re-running this skill is only necessary if they want to switch issue trackers or restart from scratch.

package/template/skills/setup-matt-pocock-skills/domain.md

@@ -1,51 +0,0 @@
-# Domain Docs
-
-How the engineering skills should consume this repo's domain documentation when exploring the codebase.
-
-## Before exploring, read these
-
-- **`CONTEXT.md`** at the repo root, or
-- **`CONTEXT-MAP.md`** at the repo root if it exists — it points at one `CONTEXT.md` per context. Read each one relevant to the topic.
-- **`docs/adr/`** — read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
-
-If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The producer skill (`/grill-with-docs`) creates them lazily when terms or decisions actually get resolved.
-
-## File structure
-
-Single-context repo (most repos):
-
-```
-/
-├── CONTEXT.md
-├── docs/adr/
-│   ├── 0001-event-sourced-orders.md
-│   └── 0002-postgres-for-write-model.md
-└── src/
-```
-
-Multi-context repo (presence of `CONTEXT-MAP.md` at the root):
-
-```
-/
-├── CONTEXT-MAP.md
-├── docs/adr/                          ← system-wide decisions
-└── src/
-    ├── ordering/
-    │   ├── CONTEXT.md
-    │   └── docs/adr/                  ← context-specific decisions
-    └── billing/
-        ├── CONTEXT.md
-        └── docs/adr/
-```
-
-## Use the glossary's vocabulary
-
-When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
-
-If the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/grill-with-docs`).
-
-## Flag ADR conflicts
-
-If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
-
-> _Contradicts ADR-0007 (event-sourced orders) — but worth reopening because…_

package/template/skills/setup-matt-pocock-skills/issue-tracker-github.md

@@ -1,22 +0,0 @@
-# Issue tracker: GitHub
-
-Issues and PRDs for this repo live as GitHub issues. Use the `gh` CLI for all operations.
-
-## Conventions
-
-- **Create an issue**: `gh issue create --title "..." --body "..."`. Use a heredoc for multi-line bodies.
-- **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.
-- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.
-- **Comment on an issue**: `gh issue comment <number> --body "..."`
-- **Apply / remove labels**: `gh issue edit <number> --add-label "..."` / `--remove-label "..."`
-- **Close**: `gh issue close <number> --comment "..."`
-
-Infer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.
-
-## When a skill says "publish to the issue tracker"
-
-Create a GitHub issue.
-
-## When a skill says "fetch the relevant ticket"
-
-Run `gh issue view <number> --comments`.