oh-my-copilot 4.13.2 → 4.13.21

package/skills/release/SKILL.md

@@ -1,87 +1,198 @@
 ---
 name: release
-description: Automated release workflow for oh-my-copilot
+description: Generic release assistant — analyzes repo release rules, caches them in .omcp/RELEASE_RULE.md, then guides the release
+level: 3
 ---
 
 # Release Skill
 
-Automate the release process for oh-my-copilot.
+A thin, repo-aware release assistant. On first run it inspects the project and CI to derive release rules, stores them in `.omcp/RELEASE_RULE.md` for future use, then walks you through a release using those rules.
 
 ## Usage
 
 ```
-/oh-my-copilot:release <version>
+/oh-my-copilot:release [version]
 ```
 
-Example: `/oh-my-copilot:release 2.4.0` or `/oh-my-copilot:release patch` or `/oh-my-copilot:release minor`
+- `version` is optional. If omitted the skill will ask. Accepts `patch`, `minor`, `major`, or an explicit semver like `2.4.0`.
+- Add `--refresh` to force re-analysis of the repo even when a cached rule file exists.
 
-## Release Checklist
+## Execution Flow
 
-Execute these steps in order:
+### Step 0 — Load or Build Release Rules
 
-### 1. Version Bump
-Update version in all locations:
-- `package.json`
-- `src/installer/index.ts` (VERSION constant)
-- `src/__tests__/installer.test.ts` (expected version)
-- `.copilot-plugin/plugin.json`
-- `.copilot-plugin/marketplace.json` (both `plugins[0].version` and root `version`)
-- `docs/copilot-instructions.md` (`<!-- OMC:VERSION:X.Y.Z -->` marker)
-- `README.md` (version badge and title)
+Check whether `.omcp/RELEASE_RULE.md` exists.
 
-### 2. Run Tests
-```bash
-npm run test:run
-```
-All 231+ tests must pass before proceeding.
+**If it does NOT exist (or `--refresh` was passed):** Run the full repo analysis below and write the file.
 
-### 3. Commit Version Bump
-```bash
-git add -A
-git commit -m "chore: Bump version to <version>"
-```
+**If it DOES exist:** Read the file. Then do a quick delta check — scan `.github/workflows/` (or equivalent CI dirs: `.circleci/`, `.travis.yml`, `Jenkinsfile`, `bitbucket-pipelines.yml`, `gitlab-ci.yml`) for any modifications newer than the `last-analyzed` timestamp in the rule file. If relevant workflow files changed, re-run the analysis for those sections and update the file. Report what changed.
 
-### 4. Create & Push Tag
-```bash
-git tag v<version>
-git push origin main
-git push origin v<version>
-```
+---
+
+### Step 1 — Repo Analysis (first run or --refresh)
+
+Inspect the repo and answer the following. Write answers into `.omcp/RELEASE_RULE.md`.
+
+#### 1a. Version Sources
+
+- Locate all files that contain a version string matching the current version in `package.json` / `pyproject.toml` / `Cargo.toml` / `build.gradle` / `VERSION` file / etc.
+- List each file and the field or regex pattern used to find the version.
+- Detect whether there is a release automation script (e.g. `scripts/release.*`, `Makefile release` target, `bump2version`, `release-it`, `semantic-release`, `changesets`, `goreleaser`).
+
+#### 1b. Registry / Distribution
+
+- npm (`package.json` with `publishConfig` or `npm publish` in CI), PyPI (`pyproject.toml` + `twine`/`flit`), Cargo (`Cargo.toml`), Docker (`Dockerfile` + push step), GitHub Packages, other.
+- Is there a CI step that publishes automatically on tag push? Which workflow file and job?
+
+#### 1c. Release Trigger
+
+- Identify what starts the release: tag push (`v*`), manual dispatch (`workflow_dispatch`), merge to main/master, a release branch merge, a commit message pattern.
+
+#### 1d. Test Gate
+
+- Identify the test command and where it runs in CI.
+- Are tests required to pass before publish? Note any bypass flags.
+
+#### 1e. Release Notes / Changelog
+
+- Does a `CHANGELOG.md` or `CHANGELOG.rst` exist?
+- What convention is used: Keep a Changelog, Conventional Commits, GitHub auto-generated, none?
+- Is there a release body file (e.g. `.github/release-body.md`) committed pre-tag?
 
-### 5. Publish to npm
-```bash
-npm publish --access public
+#### 1f. First-Time User Check
+
+- Does a release workflow exist in `.github/workflows/` (or equivalent)? If not, flag this and offer to scaffold one.
+- Is there a `.gitignore` entry preventing build artifacts from being committed? If not, flag it.
+- Are git tags being used? Run `git tag --list` to check. If no tags exist, flag and explain best practice.
+
+---
+
+### Step 2 — Write `.omcp/RELEASE_RULE.md`
+
+Create or overwrite the file with this structure:
+
+```markdown
+# Release Rules
+<!-- last-analyzed: YYYY-MM-DDTHH:MM:SSZ -->
+
+## Version Sources
+<!-- list of files + patterns -->
+
+## Release Trigger
+<!-- what kicks off the release -->
+
+## Test Gate
+<!-- command + CI job name -->
+
+## Registry / Distribution
+<!-- npm, PyPI, Docker, etc. + CI job that publishes -->
+
+## Release Notes Strategy
+<!-- convention + files -->
+
+## CI Workflow Files
+<!-- paths to relevant workflow files -->
+
+## First-Time Setup Gaps
+<!-- any missing pieces found during analysis, or "none" -->
 ```
 
-### 6. Create GitHub Release
-```bash
-gh release create v<version> --title "v<version> - <title>" --notes "<release notes>"
+---
+
+### Step 3 — Determine Version
+
+If the user provided a version argument, use it. Otherwise:
+
+1. Show the current version (from the primary version file).
+2. Show what `patch`, `minor`, and `major` would produce.
+3. Ask the user which to use.
+
+Validate the chosen version is a valid semver string.
+
+---
+
+### Step 4 — Pre-Release Checklist
+
+Present a checklist derived from the release rules. At minimum:
+
+- [ ] All changes intended for this release are committed and pushed
+- [ ] CI is green on the target branch
+- [ ] Tests pass locally (run the test gate command)
+- [ ] Version bump applied to all version source files
+- [ ] Release notes / changelog prepared (see Step 5)
+
+Ask the user to confirm before proceeding, or run each step if they say "go ahead".
+
+---
+
+### Step 5 — Release Notes Guidance
+
+Help the user write good release notes. Apply whichever convention the repo uses. Default guidance when no convention is detected:
+
+**What makes a good release note:**
+- Lead with **what changed for users**, not internal implementation details.
+- Group by type: `New Features`, `Bug Fixes`, `Breaking Changes`, `Deprecations`, `Internal / Chores`.
+- For each item: one sentence, link to the PR or issue, credit the author if external.
+- **Breaking changes** go first and must include a migration path.
+- Omit changes users never see (refactors, CI tweaks, test-only changes) unless they affect build reproducibility.
+
+**Example entry format:**
+```
+### Bug Fixes
+- Fix session drop on token expiry (#123) — @contributor
 ```
 
-### 7. Verify
-- [ ] npm: https://www.npmjs.com/package/oh-my-copilot
-- [ ] GitHub: https://github.com/RobinNorberg/oh-my-copilot/releases
+If the repo uses Conventional Commits, generate a draft changelog from `git log <prev-tag>..HEAD --no-merges --format="%s"` grouped by commit type. Show it to the user and let them edit.
 
-## Version Files Reference
+---
+
+### Step 6 — Execute Release
+
+Using the rules discovered, walk through:
+
+1. **Bump version** — apply to each version source file.
+2. **Run tests** — execute the test gate command.
+3. **Commit** — `git add <version files> CHANGELOG.md` and commit with `chore(release): bump version to vX.Y.Z`.
+4. **Tag** — `git tag -a vX.Y.Z -m "vX.Y.Z"` (annotated tags are preferred over lightweight).
+5. **Push** — `git push origin <branch> && git push origin vX.Y.Z`.
+6. **CI takes over** — if the release trigger is a tag push, remind the user that CI will handle the rest (publish, GitHub release creation). Show the expected CI workflow file.
+7. **Manual publish** — if no CI automation exists, list the manual publish command (e.g. `npm publish --access public`, `twine upload dist/*`).
+
+---
+
+### Step 7 — First-Time Setup Suggestions
+
+If gaps were found in Step 1f, offer concrete help:
 
-| File | Field/Line |
-|------|------------|
-| `package.json` | `"version": "X.Y.Z"` |
-| `src/installer/index.ts` | `export const VERSION = 'X.Y.Z'` |
-| `src/__tests__/installer.test.ts` | `expect(VERSION).toBe('X.Y.Z')` |
-| `.copilot-plugin/plugin.json` | `"version": "X.Y.Z"` |
-| `.copilot-plugin/marketplace.json` | `plugins[0].version` + root `version` |
-| `docs/copilot-instructions.md` | `<!-- OMC:VERSION:X.Y.Z -->` |
-| `README.md` | Title + version badge |
+**No release workflow:**
+> Your repo doesn't have a release CI workflow. A GitHub Actions workflow triggered on `v*` tag push is the most common best practice. It can:
+> - Run tests
+> - Publish to npm/PyPI/etc.
+> - Create a GitHub Release with your release notes
+>
+> Want me to scaffold a `.github/workflows/release.yml` for your stack?
 
-## Semantic Versioning
+**No git tags:**
+> This appears to be the first release. Git tags let GitHub, npm, and other tools understand your version history. We'll create your first tag in Step 6.
 
-- **patch** (X.Y.Z+1): Bug fixes, minor improvements
-- **minor** (X.Y+1.0): New features, backward compatible
-- **major** (X+1.0.0): Breaking changes
+**Build artifacts not gitignored:**
+> Build artifacts are present in git history or not gitignored. This inflates repo size and creates merge conflicts. Want me to add them to `.gitignore`?
+
+---
+
+### Step 8 — Verify
+
+After the push:
+- Check CI status: `gh run list --workflow=<release workflow> --limit=3` (if `gh` is available).
+- Check the registry (npm, PyPI) for the new version after a few minutes.
+- Confirm a GitHub Release was created: `gh release view vX.Y.Z`.
+
+Report success or flag any failures.
+
+---
 
 ## Notes
 
-- Always run tests before publishing
-- Create release notes summarizing changes
-- Plugin marketplace syncs automatically from GitHub releases
+- This skill does **not** hardcode any project-specific version files or commands. Everything is derived from repo inspection.
+- `.omcp/RELEASE_RULE.md` is a local cache. Commit it to your repo if you want to share the derived rules with your team, or add it to `.gitignore` if you prefer it stays local.
+- For complex monorepos or multi-package workspaces, the skill will detect workspace patterns (npm workspaces, pnpm workspaces, Cargo workspace) and adapt accordingly.

package/skills/remember/SKILL.md

@@ -14,7 +14,7 @@ Promote durable, reusable knowledge into the right memory surface instead of lea
 - **Project memory** — durable team/project knowledge
 - **Notepad priority** — short high-signal context for the next turns
 - **Notepad working** — temporary active-session notes
-- **Docs / AGENTS / COPILOT files** — durable instructions and conventions when they truly belong there
+- **Docs / AGENTS / CLAUDE files** — durable instructions and conventions when they truly belong there
 
 ## Workflow
 1. Gather the relevant session findings.
@@ -38,3 +38,4 @@ Promote durable, reusable knowledge into the right memory surface instead of lea
 - What was stored
 - Where it was stored
 - Any duplicates/conflicts found
+

package/skills/sciomc/SKILL.md

@@ -2,6 +2,7 @@
 name: sciomc
 description: Orchestrate parallel scientist agents for comprehensive analysis with AUTO mode
 argument-hint: <research goal>
+level: 4
 ---
 
 # Research Skill
@@ -63,13 +64,13 @@ Fire independent stages in parallel via Task tool:
 
 ```
 // Stage 1 - Simple data gathering
-Task(subagent_type="oh-my-copilot:scientist", model="haiku", name="scientist-1", prompt="[RESEARCH_STAGE:1] Investigate...")
+Task(subagent_type="oh-my-copilot:scientist", model="haiku", prompt="[RESEARCH_STAGE:1] Investigate...")
 
 // Stage 2 - Standard analysis
-Task(subagent_type="oh-my-copilot:scientist", model="sonnet", name="scientist-2", prompt="[RESEARCH_STAGE:2] Analyze...")
+Task(subagent_type="oh-my-copilot:scientist", model="sonnet", prompt="[RESEARCH_STAGE:2] Analyze...")
 
 // Stage 3 - Complex reasoning
-Task(subagent_type="oh-my-copilot:scientist", model="opus", name="scientist-3", prompt="[RESEARCH_STAGE:3] Deep analysis of...")
+Task(subagent_type="oh-my-copilot:scientist", model="opus", prompt="[RESEARCH_STAGE:3] Deep analysis of...")
 ```
 
 ### Smart Model Routing
@@ -99,7 +100,7 @@ After parallel execution completes, verify findings:
 
 ```
 // Cross-validation stage
-Task(subagent_type="oh-my-copilot:scientist", model="sonnet", name="scientist-1", prompt="
+Task(subagent_type="oh-my-copilot:scientist", model="sonnet", prompt="
 [RESEARCH_VERIFICATION]
 Cross-validate these findings for consistency:
 
@@ -180,9 +181,9 @@ When stages analyze different data sources:
 
 ```
 // All fire simultaneously
-Task(subagent_type="oh-my-copilot:scientist", model="haiku", name="scientist-1", prompt="[STAGE:1] Analyze src/api/...")
-Task(subagent_type="oh-my-copilot:scientist", model="haiku", name="scientist-2", prompt="[STAGE:2] Analyze src/utils/...")
-Task(subagent_type="oh-my-copilot:scientist", model="haiku", name="scientist-3", prompt="[STAGE:3] Analyze src/components/...")
+Task(subagent_type="oh-my-copilot:scientist", model="haiku", prompt="[STAGE:1] Analyze src/api/...")
+Task(subagent_type="oh-my-copilot:scientist", model="haiku", prompt="[STAGE:2] Analyze src/utils/...")
+Task(subagent_type="oh-my-copilot:scientist", model="haiku", prompt="[STAGE:3] Analyze src/components/...")
 ```
 
 ### Hypothesis Battery (Parallel)
@@ -191,9 +192,9 @@ When testing multiple hypotheses:
 
 ```
 // Test hypotheses simultaneously
-Task(subagent_type="oh-my-copilot:scientist", model="sonnet", name="scientist-1", prompt="[HYPOTHESIS:A] Test if caching improves...")
-Task(subagent_type="oh-my-copilot:scientist", model="sonnet", name="scientist-2", prompt="[HYPOTHESIS:B] Test if batching reduces...")
-Task(subagent_type="oh-my-copilot:scientist", model="sonnet", name="scientist-3", prompt="[HYPOTHESIS:C] Test if lazy loading helps...")
+Task(subagent_type="oh-my-copilot:scientist", model="sonnet", prompt="[HYPOTHESIS:A] Test if caching improves...")
+Task(subagent_type="oh-my-copilot:scientist", model="sonnet", prompt="[HYPOTHESIS:B] Test if batching reduces...")
+Task(subagent_type="oh-my-copilot:scientist", model="sonnet", prompt="[HYPOTHESIS:C] Test if lazy loading helps...")
 ```
 
 ### Cross-Validation (Sequential)
@@ -205,7 +206,7 @@ When verification depends on all findings:
 [stages complete]
 
 // Then sequential verification
-Task(subagent_type="oh-my-copilot:scientist", model="opus", name="scientist-1", prompt="
+Task(subagent_type="oh-my-copilot:scientist", model="opus", prompt="
 [CROSS_VALIDATION]
 Validate consistency across all findings:
 - Finding 1: ...

package/skills/self-improve/SKILL.md

@@ -30,9 +30,9 @@ You are the **loop controller** for the self-improvement system. You manage the
 
 Self-improve artifacts live under a resolved root returned by `scripts/resolve-paths.mjs`.
 
-- New runs default to `.omc/self-improve/topics/default/`.
-- When the user provides a topic or slug, use `.omc/self-improve/topics/{topic_slug}/`.
-- Legacy single-track state at `.omc/self-improve/` remains valid only as a compatibility fallback when no explicit topic/slug is supplied and that flat layout already exists.
+- New runs default to `.omcp/self-improve/topics/default/`.
+- When the user provides a topic or slug, use `.omcp/self-improve/topics/{topic_slug}/`.
+- Legacy single-track state at `.omcp/self-improve/` remains valid only as a compatibility fallback when no explicit topic/slug is supplied and that flat layout already exists.
 
 Treat `<self-improve-root>/` below as that resolved root:
 
@@ -115,7 +115,7 @@ Read these files at startup and at the beginning of each iteration:
 6. If goal not set → read `si-goal-clarifier.md` from this skill directory and run the 4-dimension Socratic interview directly in this context (Objective, Metric, Target, Scope). Write result to `<self-improve-root>/config/goal.md`.
 6. If benchmark not set → read `si-benchmark-builder.md` from this skill directory, spawn a custom Agent(model=opus) with its content as prompt. The agent surveys the repo, creates or wraps a benchmark, validates 3x, and records baseline.
    After benchmark is set, confirm the benchmark command with user:
-   `"Benchmark command: {benchmark_command}. This will be run repeatedly during the loop. Confirm? [yes/no]"`
+      `"Benchmark command: {benchmark_command}. This will be run repeatedly during the loop. Confirm? [yes/no]"`
    If user declines: abort setup and exit.
 7. If harness not set → confirm default harness rules (H001/H002/H003) with user or customize.
 8. **Gate**: All of `si_setting_goal`, `si_setting_benchmark`, `si_setting_harness`, `trust_confirmed` must be true.

package/skills/setup/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: setup
 description: Use first for install/update routing — sends setup, doctor, or MCP requests to the correct OMC setup flow
+level: 2
 ---
 
 # Setup

package/skills/skill/SKILL.md

@@ -2,6 +2,7 @@
 name: skill
 description: Manage local skills - list, add, remove, search, edit, setup wizard
 argument-hint: "<command> [args]"
+level: 2
 ---
 
 # Skill Management CLI
@@ -28,7 +29,7 @@ BUILT-IN SKILLS (bundled with oh-my-copilot):
 | visual-verdict    | Structured visual QA verdicts  | built-in |
 | ralph             | Persistence loop               | built-in |
 
-USER SKILLS (~/.copilot/skills/omc-learned/):
+USER SKILLS (~/.claude/skills/omc-learned/):
 | Name              | Triggers           | Quality | Usage | Scope |
 |-------------------|--------------------|---------|-------|-------|
 | error-handler     | fix, error         | 95%     | 42    | user  |
@@ -114,7 +115,7 @@ Triggers (comma-separated): log, logger, logging
 Argument hint (optional): <level> [message]
 Scope (user/project): user
 
-✓ Created skill at ~/.copilot/skills/omc-learned/custom-logger/SKILL.md
+✓ Created skill at ~/.claude/skills/omc-learned/custom-logger/SKILL.md
 → Edit with: /skill edit custom-logger
 ```
 
@@ -126,7 +127,7 @@ Remove a skill by name.
 
 **Behavior:**
 1. **Search for skill** in both scopes:
-   - `~/.copilot/skills/omc-learned/<name>/SKILL.md`
+   - `${COPILOT_CONFIG_DIR:-~/.copilot}/skills/omc-learned/<name>/SKILL.md`
    - `.omcp/skills/<name>/SKILL.md`
 2. **If found:**
    - Display skill info (name, description, scope)
@@ -144,7 +145,7 @@ Remove a skill by name.
 User: /skill remove old-logger
 Assistant: Found skill 'old-logger' in user scope:
   Description: Legacy logging utility
-  Scope: user (~/.copilot/skills/omc-learned/)
+  Scope: user (~/.claude/skills/omc-learned/)
 
 Delete 'old-logger' skill? (yes/no)
 
@@ -260,13 +261,13 @@ Show detailed information about a skill.
 
 ```
 Skill: custom-logger
-Scope: user (~/.copilot/skills/omc-learned/custom-logger/)
+Scope: user (~/.claude/skills/omc-learned/custom-logger/)
 Description: Enhanced logging with structured output
 Triggers: log, logger, logging
 Argument Hint: <level> [message]
 Quality: 95% (if available)
 Usage Count: 42 times (if available)
-File Path: /home/user/.copilot/skills/omc-learned/custom-logger/SKILL.md
+File Path: /home/user/.claude/skills/omc-learned/custom-logger/SKILL.md
 
 --- FULL CONTENT ---
 [entire markdown content]
@@ -281,7 +282,7 @@ Assistant: Skill: custom-logger
 Scope: user
 Description: Enhanced logging with structured output
 Triggers: log, logger, logging
-File: ~/.copilot/skills/omc-learned/custom-logger/SKILL.md
+File: ~/.claude/skills/omc-learned/custom-logger/SKILL.md
 
 --- CONTENT ---
 # Custom Logger Skill
@@ -369,7 +370,7 @@ First, check if skill directories exist and create them if needed:
 
 ```bash
 # Check and create user-level skills directory
-USER_SKILLS_DIR="${COPILOT_CONFIG_DIR:-${COPILOT_CONFIG_DIR:-$HOME/.copilot}}/skills/omc-learned"
+USER_SKILLS_DIR="${COPILOT_CONFIG_DIR:-$HOME/.copilot}/skills/omc-learned"
 if [ -d "$USER_SKILLS_DIR" ]; then
   echo "User skills directory exists: $USER_SKILLS_DIR"
 else
@@ -393,15 +394,15 @@ Scan both directories and show a comprehensive inventory:
 
 ```bash
 # Scan user-level skills
-echo "=== USER-LEVEL SKILLS (~/.copilot/skills/omc-learned/) ==="
+echo "=== USER-LEVEL SKILLS (~/.claude/skills/omc-learned/) ==="
 if [ -d "${COPILOT_CONFIG_DIR:-$HOME/.copilot}/skills/omc-learned" ]; then
-  USER_COUNT=$(find "${COPILOT_CONFIG_DIR:-${COPILOT_CONFIG_DIR:-$HOME/.copilot}}/skills/omc-learned" -name "*.md" 2>/dev/null | wc -l)
+  USER_COUNT=$(find "${COPILOT_CONFIG_DIR:-$HOME/.copilot}/skills/omc-learned" -name "*.md" 2>/dev/null | wc -l)
   echo "Total skills: $USER_COUNT"
 
   if [ $USER_COUNT -gt 0 ]; then
     echo ""
     echo "Skills found:"
-    find "${COPILOT_CONFIG_DIR:-${COPILOT_CONFIG_DIR:-$HOME/.copilot}}/skills/omc-learned" -name "*.md" -type f -exec sh -c '
+    find "${COPILOT_CONFIG_DIR:-$HOME/.copilot}/skills/omc-learned" -name "*.md" -type f -exec sh -c '
       FILE="$1"
       NAME=$(grep -m1 "^name:" "$FILE" 2>/dev/null | sed "s/name: //")
       DESC=$(grep -m1 "^description:" "$FILE" 2>/dev/null | sed "s/description: //")
@@ -467,7 +468,7 @@ Analyze the current conversation context to identify potential skill-worthy patt
 - Codebase-specific workarounds discovered
 - Error patterns that took time to resolve
 
-Report findings and ask if user wants to extract any as skills (invoke `/learner` if yes).
+Report findings and ask if user wants to extract any as skills (invoke `/skillify`; `/learner` is deprecated compatibility).
 
 **Option 4: Import Skill**
 
@@ -476,7 +477,7 @@ Ask user to provide either:
 - **Paste content**: Paste skill markdown content directly
 
 Then ask for scope:
-- **User-level** (~/.copilot/skills/omc-learned/) - Available across all projects
+- **User-level** (~/.claude/skills/omc-learned/) - Available across all projects
 - **Project-level** (.omcp/skills/) - Only for this project
 
 Validate the skill format and save to the chosen location.
@@ -711,7 +712,7 @@ How to work with this integration correctly:
 When invoked with an argument, skip the interactive wizard:
 
 - `/oh-my-copilot:skill list` - Show detailed skill inventory
-- `/oh-my-copilot:skill add` - Start skill creation (invoke learner)
+- `/oh-my-copilot:skill add` - Start skill creation (invoke skillify)
 - `/oh-my-copilot:skill scan` - Scan both skill directories
 
 ### Interactive Mode
@@ -722,13 +723,13 @@ When invoked without arguments, run the full guided wizard.
 
 ## Benefits of Local Skills
 
-**Automatic Application**: Copilot detects triggers and applies skills automatically - no need to remember or search for solutions.
+**Automatic Application**: Claude detects triggers and applies skills automatically - no need to remember or search for solutions.
 
 **Version Control**: Project-level skills (`.omcp/skills/`) are intended to be committed with your code so the whole team benefits. In linked worktrees, uncommitted skills remain local to that worktree and disappear if it is removed.
 
 **Evolving Knowledge**: Skills improve over time as you discover better approaches and refine triggers.
 
-**Reduced Token Usage**: Instead of re-solving the same problems, Copilot applies known patterns efficiently.
+**Reduced Token Usage**: Instead of re-solving the same problems, Claude applies known patterns efficiently.
 
 **Codebase Memory**: Preserves institutional knowledge that would otherwise be lost in conversation history.
 
@@ -758,7 +759,7 @@ Good skills are:
 
 ## Related Skills
 
-- `/oh-my-copilot:learner` - Extract a skill from current conversation
+- `/oh-my-copilot:skillify` - Extract a skill from current conversation (`/oh-my-copilot:learner` is a deprecated alias)
 - `/oh-my-copilot:note` - Save quick notes (less formal than skills)
 - `/oh-my-copilot:deepinit` - Generate AGENTS.md codebase hierarchy
 
@@ -770,7 +771,7 @@ Good skills are:
 > /oh-my-copilot:skill list
 
 Checking skill directories...
-✓ User skills directory exists: ~/.copilot/skills/omc-learned/
+✓ User skills directory exists: ~/.claude/skills/omc-learned/
 ✓ Project skills directory exists: .omcp/skills/
 
 Scanning for skills...
@@ -811,7 +812,7 @@ What would you like to do?
 ## Tips for Users
 
 - Run `/oh-my-copilot:skill list` periodically to review your skill library
-- After solving a tricky bug, immediately run learner to capture it
+- After solving a tricky bug, immediately run skillify to capture it
 - Use project-level skills for codebase-specific knowledge
 - Use user-level skills for general patterns that apply everywhere
 - Review and refine triggers over time to improve matching accuracy
@@ -831,7 +832,7 @@ What would you like to do?
 
 ## Related Skills
 
-- `/oh-my-copilot:learner` - Extract a skill from current conversation
+- `/oh-my-copilot:skillify` - Extract a skill from current conversation (`/oh-my-copilot:learner` is a deprecated alias)
 - `/oh-my-copilot:note` - Save quick notes (less formal than skills)
 - `/oh-my-copilot:deepinit` - Generate AGENTS.md codebase hierarchy
 

package/skills/skillify/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: skillify
+aliases: [learner]
 description: Turn a repeatable workflow from the current session into a reusable OMC skill draft
 ---
 
@@ -7,9 +8,19 @@ description: Turn a repeatable workflow from the current session into a reusable
 
 Use this skill when the current session uncovered a repeatable workflow that should become a reusable OMC skill.
 
+> Compatibility: `/oh-my-copilot:learner` is a deprecated alias for this skill. Prefer `/oh-my-copilot:skillify` in docs, prompts, and new workflows. Internal implementation modules may still use the learner name.
+
 ## Goal
 Capture a successful multi-step workflow as a concrete skill draft instead of rediscovering it later.
 
+## Quality Gate
+Before extracting a skill, all three should be true:
+- "Could someone Google this in 5 minutes?" → No.
+- "Is this specific to this codebase, project, or workflow?" → Yes.
+- "Did this take real debugging, design, or operational effort to discover?" → Yes.
+
+Prefer skills that encode decision-making heuristics, constraints, pitfalls, and verification steps. Avoid generic snippets, boilerplate, or library usage examples that belong in normal documentation.
+
 ## Workflow
 1. Identify the repeatable task the session accomplished.
 2. Extract:
@@ -17,22 +28,42 @@ Capture a successful multi-step workflow as a concrete skill draft instead of re
    - ordered steps
    - success criteria
    - constraints / pitfalls
+   - verification evidence
    - best target location for the skill
 3. Decide whether the workflow belongs as:
    - a repo built-in skill
    - a user/project learned skill
    - documentation only
-4. Draft the SKILL.md content with clear triggers, steps, and success criteria.
-5. Point out anything still too fuzzy to encode safely.
+4. When drafting a learned skill file, output a complete skill file that starts with YAML frontmatter.
+   - Never emit plain markdown-only skill files.
+   - Do **not** write plain markdown without frontmatter.
+   - Minimum frontmatter:
+     ```yaml
+     ---
+     name: <skill-name>
+     description: <one-line description>
+     triggers:
+       - <trigger-1>
+       - <trigger-2>
+     ---
+     ```
+   - Write learned/user/project skills to flat file-backed paths:
+     - `${COPILOT_CONFIG_DIR:-~/.copilot}/skills/omc-learned/<skill-name>.md`
+     - `.omcp/skills/<skill-name>.md`
+   - Remember that uncommitted skills are still worktree-local until committed or copied to a user-level directory.
+5. Draft the rest of the skill file with clear triggers, steps, success criteria, and pitfalls.
+6. Point out anything still too fuzzy to encode safely.
 
 ## Rules
 - Only capture workflows that are actually repeatable.
 - Keep the skill practical and scoped.
 - Prefer explicit success criteria over vague prose.
 - If the workflow still has unresolved branching decisions, note them before drafting.
+- Keep `omc-learned` as the storage directory name for compatibility; do not present it as the public invocation name.
 
 ## Output
 - Proposed skill name
 - Target location
-- Draft workflow structure
+- Draft workflow structure or complete skill file
+- Verification or quality-gate notes
 - Open questions, if any