---
title: Codex Deep Repo Audit - pm-skills
description: High and low level audit of the pm-skills repository, including governance health, product strategy, GUI options, ecosystem comparison, strengths, gaps, and next ideological direction.
date: 2026-06-06
status: draft for maintainer review
audience: pm-skills maintainers
scope: full repo at 9881bbd plus local working tree verification
---

# Codex Deep Repo Audit - 2026-06-06

> ## 🔵 CLAUDE REVIEW AND DISPOSITION (added 2026-06-06, NOT part of the original Codex audit)
>
> I (Claude, Opus 4.8) independently verified this audit against the live tree at HEAD `7eae470` using a 7-agent adversarial-verification workflow, then acted on its release-blocking finding. My point-by-point responses are interleaved below as blockquotes marked **🔵 CLAUDE**. The full structured review is the companion file [`2026-06-06_codex_review.md`](2026-06-06_codex_review.md).
>
> **Headline verdict: this audit is three layers with three different grades.**
>
> - **Tactical layer (P0/P1 hygiene, inventory): SOUND.** Nearly every falsifiable claim confirmed to the exact line and count; inventory was 12/13 exact (the one delta is the audit file itself, untracked). This is genuinely good forensic work.
> - **Strategic layer: mostly CONVERGENT with the team's own `docs/internal/roadmap.md`** (dated 2026-05-31, six days before this audit, and literally titled "From Skill Library to PM Operating Layer"), which the audit never cites. The "PM operating layer" reframe, the eval harness, and the `.pm-skills/` persistent-context convention restate work the team had already planned or shipped (the eval Tier 1 shipped in v2.25.0). Genuinely NOVEL and worthwhile: the static in-site Skill Finder + `skill-manifest.json`, and optional output schemas. OVERREACH: the broad connector/MCP packs, which run against the standing MCP-maintenance-mode decision.
> - **Ecosystem layer: the four arXiv citations are almost certainly FABRICATED** (future-dated `2602/2604/2605/2606` prefixes, at or after this audit's own 2026-06-06 date). Treat the academic anchors as untrustworthy; strip them before any maintainer-facing use.
>
> **What was actioned:** P0-01 (the broken PowerShell pre-tag bundle) was real and was fixed in **PR #174**, then banked in **v2.25.1** (shipped 2026-06-06, tag `2b5044a`, GitHub Release Latest). P0-02, P1-01, P1-02, P1-03, and P1-05 are confirmed; dispositions are noted inline. One correction to the audit's own framing: `docs/internal/` is TRACKED (355 files), not gitignored, so P1-01's broken `docs/reference` source links ARE visible to GitHub readers, which raises (not lowers) their priority.

## Executive Take

pm-skills is unusually strong for an agent-skill/plugin repository. It is not just a pile of prompt files. It is a governed PM methodology library with a coherent taxonomy, cross-client dispatch patterns, sample corpora, a generated documentation site, release sub-agents, family contracts, and a serious validation culture.

The main strategic risk is that the repo has become excellent at "produce a PM artifact" and "govern this skill library," while the market is moving toward "operate a PM system." Competitors increasingly package skills with MCP servers, hooks, agents, persistent context, dashboards, and one-click visual management. pm-skills has the better PM knowledge base and stronger governance, but it is lighter on connected workflow execution.

The next ideological step should be:

> From prompt library to evidence-grounded PM operating layer.

That means preserving the current artifact quality, but adding structured output contracts, run state, evidence provenance, optional connectors, and a GUI/workbench that helps users select, chain, run, review, and persist PM work.

The strongest near-term improvement is not adding more skills. The catalog is already broad. The highest leverage work is:

1. Unify and fix validation so local release readiness exactly matches CI.
2. Repair source-link/path drift around `docs/reference/...` now that source docs live under `site/src/content/docs/...`.
3. Add a generated skill manifest as product data, not just docs content.
4. Build a lightweight GUI skill/workflow finder on top of that manifest.
5. Introduce empirical quality evals that score PM outputs, not just repo structure.
6. Add optional integration surfaces through MCP/connectors for Linear, Jira, GitHub Issues, Notion, Slack, Figma, analytics, and research repositories.

## Scope And Method

This audit reviewed the repository from both maintainer and product-strategy angles.

Local scope:

- Repo root: `E:\Projects\product-on-purpose\pm-skills`
- HEAD: `9881bbd`
- Starting working tree: clean
- Audit date: 2026-06-06

Evidence gathered:

- Repo inventory across `skills/`, `agents/`, `commands/`, `_workflows/`, `scripts/`, `hooks/`, `library/`, `docs/`, and `site/`.
- Canonical pm-skill-auditor instructions from `skills/utility-pm-skill-auditor/SKILL.md` and `agents/pm-skill-auditor.md`.
- Validator bundle runs through PowerShell and Bash.
- Site build and rendered-site link checks.
- Unit tests for build-aware validators, hooks, resource index, and sample-quality checks.
- Marketplace and ecosystem research using current public pages and papers.

Important caveat:

- During verification, `site/src/styles/custom.css` appeared staged with one content change adding `--sl-content-width: 60rem;`. I did not author that as part of this audit and did not revert it. The requested output file is this audit document.

## Verification Snapshot

| Check | Result | Interpretation |
|---|---:|---|
| `pwsh -NoProfile -File scripts/pre-tag-validate.ps1` | FAIL | Required PowerShell bundle references two missing scripts: `check-internal-link-validity.ps1` and `check-generated-content-untouched.ps1`. |
| `bash scripts/pre-tag-validate.sh` | FAIL locally | Bash bundle differs from PowerShell. In this Windows/WSL environment it also cannot find `node`, so local Bash parity is not reliable. |
| `pwsh -NoProfile -File scripts/validate-docs-frontmatter.ps1 -Strict` | PASS | Docs frontmatter validates in PowerShell. |
| `pwsh -NoProfile -File scripts/validate-codex-manifest.ps1` | PASS | `.codex-plugin/plugin.json` is valid JSON and structurally valid. |
| `pwsh -NoProfile -File scripts/validate-version-consistency.ps1` | PASS | Repo version claims align at `2.25.0`. |
| `pwsh -NoProfile -File scripts/validate-skill-family-registration.ps1` | PASS | Three registered families resolve and members reference contracts. |
| `pwsh -NoProfile -File scripts/validate-plugin-install.ps1` | PASS | Claude marketplace and Codex plugin install metadata validate. |
| `pwsh -NoProfile -File scripts/validate-skill-history.ps1` | FAIL | Script cannot read nested `metadata.version` in `foundation-prioritized-action-plan/SKILL.md`. |
| `pwsh -NoProfile -File scripts/check-skill-sample-coverage.ps1` | PASS | 53 in-scope skills have Brainshelf, Storevine, and Workbench samples. |
| `npm --prefix site run build` | PASS with warnings | 375 pages built. Warnings: large chunks, duplicate `/404` rendering conflict, deprecated Astro markdown plugin config. |
| `node scripts/verify-edit-links.mjs site/dist .` | PASS | 360 edit links resolve. |
| `STRICT_ANCHORS=1 node scripts/check-rendered-links.mjs site/dist` | PASS | 388 pages scanned, 0 browser-broken internal links, 0 broken anchors. |
| `node scripts/check-route-parity.mjs site/dist` | PASS | 388 baseline routes still present. |
| `node scripts/check-root-doc-links.mjs` | PASS | Root docs links resolve. |
| Node unit suite for hooks, resource index, rendered links, sample checks | PASS | 67 tests pass. |
| `node scripts/check-sample-no-placeholders.mjs` | PASS | No placeholder findings. |
| `node scripts/check-sample-exact-quote-sourcing.mjs` | PASS | No unsourced quote findings. |
| `node scripts/check-sample-no-fabricated-metrics.mjs` | FAIL advisory | 319 possible metric-sourcing hits. Current CI treats this as advisory. |

Bottom line: the generated site and most individual validators are healthy, but the local canonical release entry point is not trustworthy across shells. That is the most concrete release-governance defect.

## Repo Inventory

Current high-level inventory:

| Surface | Count / Shape |
|---|---:|
| Skills | 65 |
| Commands | 10 workflow commands |
| Sub-agents | 5 |
| Workflows | 12 |
| Skill files under `skills/` | 211 files |
| Scripts | 114 files |
| Hooks | 16 files |
| Skill output samples | 192 files |
| Sub-agent samples | 14 files |
| Docs under `docs/` | 446 files, mostly internal plus resource index/templates |
| Site source under `site/src/content/docs/` | 378 files |
| Built site | 388 HTML files, 78.8 MB total dist |

Skill counts by prefix:

| Prefix | Count |
|---|---:|
| `discover` | 5 |
| `define` | 5 |
| `develop` | 4 |
| `deliver` | 6 |
| `measure` | 6 |
| `iterate` | 4 |
| `foundation` | 9 |
| `utility` | 11 |
| `tool` | 15 |

Largest skill files by line count:

| Skill | Lines |
|---|---:|
| `utility-update-pm-skills` | 276 |
| `utility-pm-skill-iterate` | 236 |
| `utility-pm-skill-builder` | 228 |
| `utility-pm-skill-validate` | 185 |
| `foundation-prioritized-action-plan` | 184 |
| `discover-market-sizing` | 146 |
| `foundation-okr-writer` | 141 |
| `define-prioritization-framework` | 140 |
| `measure-survey-analysis` | 138 |
| `measure-okr-grader` | 132 |

Largest workflows by line count:

| Workflow | Lines |
|---|---:|
| `triple-diamond.md` | 296 |
| `lean-startup.md` | 244 |
| `feature-kickoff.md` | 230 |
| `foundation-sprint.md` | 201 |
| `design-sprint.md` | 195 |

Sub-agent sizes:

| Agent | Lines |
|---|---:|
| `pm-workflow-orchestrator.md` | 165 |
| `pm-skill-auditor.md` | 148 |
| `pm-changelog-curator.md` | 135 |
| `pm-release-conductor.md` | 126 |
| `pm-critic.md` | 109 |

## What Is Great

### 1. The catalog is complete enough to be useful as a real PM workbench

The library covers the product lifecycle more coherently than most competing PM skill packs:

- Discovery: interviews, competitive analysis, stakeholder mapping, market sizing, journey maps.
- Definition: hypotheses, JTBD, opportunity trees, prioritization, problem statements.
- Development: ADRs, design rationale, solution briefs, spikes.
- Delivery: PRDs, user stories, acceptance criteria, edge cases, launch checklists, release notes.
- Measurement: dashboards, experiments, instrumentation, OKR grading, survey analysis.
- Iteration: retrospectives, lessons logs, refinement, pivot decisions.
- Foundation: personas, lean canvas, OKRs, meeting artifacts, stakeholder updates, prioritized action plans.
- Tool families: Foundation Sprint, Design Sprint, note-and-vote.

This breadth matters because PM work is not one artifact. PRD-only plugins are useful, but they trap the user in a delivery mindset. pm-skills has enough upstream and downstream coverage to nudge better product thinking.

### 2. The repo has a real governance posture

The validator suite is extensive. It checks frontmatter, commands, AGENTS sync, family contracts, count consistency, generated content, docs frontmatter, body H1 duplication, script docs, version consistency, plugin manifests, sample coverage, rendered links, route parity, root doc links, and more.

Many skill repos have no meaningful CI beyond "files exist." pm-skills has release scars encoded into validators. That is a real moat.

### 3. The sample corpus is a major differentiator

The three-thread sample strategy is strong:

- Brainshelf
- Storevine
- Workbench

The sample coverage validator confirms all 53 in-scope skills have the three canonical thread samples. This gives users concrete expectations and gives maintainers a future eval substrate. The sample corpus is not only documentation; it can become the test set for skill quality.

### 4. Families and workflows are better than flat skills

The meeting skills, OKR set, Foundation Sprint family, Design Sprint family, and workflow commands make the repo feel like a system rather than a list. The family contracts are especially valuable because they define shared behavior, not just common naming.

The workflow layer also creates a natural entrypoint for a future GUI.

### 5. Cross-client thinking is ahead of most peers

The repo already includes:

- Claude plugin marketplace metadata.
- Native Codex `.codex-plugin/plugin.json`.
- Dispatch skills for non-Claude clients.
- Explicit cross-client compatibility language.
- Sub-agent definitions with fallbacks.

Most skill/plugin projects are one-client artifacts. pm-skills is closer to a portable agent-skill product.

### 6. The docs site is serious

The Astro/Starlight site builds successfully, rendered links pass, anchors pass, route parity passes, and edit links pass. That is a good baseline for public adoption. The docs site is already close to being a product surface, not just project documentation.

## Findings

### P0-01 - The PowerShell pre-tag bundle is broken

**Location:** `scripts/pre-tag-validate.ps1`

**Issue:** The PowerShell pre-tag bundle references two required validators that do not exist:

- `scripts/check-internal-link-validity.ps1`
- `scripts/check-generated-content-untouched.ps1`

The run fails with "not recognized as the name of a script file" for both.

**Why it matters:** The auditor and release conductor treat `scripts/pre-tag-validate.{sh,ps1}` as canonical release readiness entrypoints. On Windows, the canonical entrypoint currently fails before it can meanfully certify release readiness.

**Fix:** Reconcile `pre-tag-validate.ps1` with the current CI workflow and Bash bundle. The validation workflow explicitly says the old filesystem link validators were retired in favor of rendered-link checks. The PowerShell bundle should remove retired validators and include the current checks, especially `check-skill-sample-coverage.ps1`.

**Suggested owner:** Release/CI hygiene.

> **🔵 CLAUDE - CONFIRMED, and FIXED.** Verified at HEAD `7eae470`: `pre-tag-validate.ps1` lines 25/30 listed both scripts in the REQUIRED tier and neither exists on disk, so the bundle could never reach "ALL CHECKS PASSED" on Windows. Fixed in PR #174 (`310b503`): dropped the two phantom validators, added `check-skill-sample-coverage`, restored the advisory tier; the bundle now passes (exit 0). Banked in v2.25.1.

### P0-02 - Bash and PowerShell pre-tag inventories are materially different

**Location:** `scripts/pre-tag-validate.sh`, `scripts/pre-tag-validate.ps1`, `.github/workflows/validation.yml`

**Issue:** The Bash and PowerShell pre-tag bundles do not run the same validator inventory.

Examples:

- Bash includes `check-skill-sample-coverage`.
- PowerShell omits `check-skill-sample-coverage`.
- PowerShell includes retired/missing `check-internal-link-validity` and `check-generated-content-untouched`.
- CI includes additional checks not represented in either local pre-tag bundle, such as site build, edit-link verification, rendered-link/anchor resolution, route parity, root-doc links, plugin install validation, and hook/sample unit tests.

**Why it matters:** A maintainer can get contradictory readiness signals depending on shell. That defeats the point of a canonical pre-tag command.

**Fix:** Create one source of truth for validator inventory. Options:

- A generated manifest such as `scripts/validation-manifest.yaml`, consumed by Bash, PowerShell, and CI.
- A single Node orchestrator that runs cross-platform, with thin `sh` and `ps1` wrappers.
- A `scripts/validate-all.{ps1,sh}` pair generated from CI workflow metadata.

Do not keep three hand-maintained validator inventories.

> **🔵 CLAUDE - CONFIRMED.** Set difference verified exactly: bash-only `{check-skill-sample-coverage}`; ps1-only `{the two phantom scripts}`; CI is a strict superset of both. PR #174 made the ps1 REQUIRED inventory mirror bash exactly and added a sync comment. The deeper fix (a single validator manifest, your Spec A) SHIPPED 2026-06-09: `scripts/validation-manifest.yaml` (single source of truth) + `scripts/check-validator-parity.mjs` (CI drift-gate, enforcing on both OS legs). #174 reconciled the two bundles by hand; Spec A unified their source and caught the residual CI-only drift (`validate-skill-family-registration`, `validate-plugin-install`).

### P1-01 - Source links point to `docs/reference/...`, but the root docs tree no longer has `docs/reference`

**Location:** `AGENTS.md`, many `skills/*/SKILL.md`, agents, workflows, validator docs.

**Issue:** The repo has many source links like `../../docs/reference/skill-families/meeting-skills-contract.md`, but `docs/reference/` is not present at the root. The actual source files live under `site/src/content/docs/reference/`.

The rendered site link checks pass, so browser users are protected. Source readers in GitHub, local editors, and some agents are not.

Examples:

- `AGENTS.md` references `docs/reference/skill-families/...`.
- Meeting skills link to `../../docs/reference/skill-families/meeting-skills-contract.md`.
- Sprint skills link to `../../docs/reference/skill-families/...`.
- Sub-agent docs reference `docs/reference/runtime-components.md` and `docs/reference/sub-agent-compatibility.md`.

**Why it matters:** Skills are often consumed as raw markdown by agents and by humans browsing GitHub. Broken local links erode trust and can break "read the referenced file" behaviors.

**Fix options:**

1. Recreate root `docs/reference`, `docs/guides`, and `docs/concepts` as thin redirect/index stubs that point to `site/src/content/docs/...`.
2. Rewrite source links in skills and agents to `site/src/content/docs/...` for GitHub correctness, while allowing the site generator to render public routes.
3. Add a validator that checks markdown links in `skills/`, `agents/`, `_workflows/`, `commands/`, `AGENTS.md`, and root docs against actual repo paths, with explicit exceptions for site-route links.

The third option is required either way.

> **🔵 CLAUDE - CONFIRMED, with three refinements.** 41 files / 128 matches of `docs/(reference|guides|concepts)`; every clickable relative form resolves to a non-existent root path (the site passes only because `gen-site.mjs:212` rewrites the link in the generated copy, never in the source, and the rendered-link check validates `site/dist` only). Refinements: (1) README is NOT an offender - its `docs/` links correctly point at `site/src/content/docs/`. (2) `docs/internal/` is TRACKED, not gitignored as CLAUDE.md/MEMORY claim, so these broken links ARE visible to GitHub readers, which RAISES their priority. (3) `check-root-doc-links.mjs` already exists but is scoped to README/CHANGELOG/CONTRIBUTING/AGENTS/QUICKSTART; extending it to `skills/**`, `agents/**`, `_workflows/**` is the minimal sound fix (your option 3). NOT yet done; tracked as a follow-up. This finding bit LIVE during the v2.25.1 release: the release runbook and the conductor agent definition both still cite the stale `docs/releases/` and `docs/contributing/` paths.

### P1-02 - `pm-skill-auditor` itself has stale path assumptions

**Location:** `agents/pm-skill-auditor.md`

**Issue:** The auditor says family contracts should be counted under `docs/reference/skill-families/`, but current files are under `site/src/content/docs/reference/skill-families/`.

**Why it matters:** The auditor is the thing maintainers use to detect drift. A stale auditor prompt can produce false findings or miss real ones.

**Fix:** Update the auditor prompt to treat `site/src/content/docs/reference/skill-families/` as the current source path, and separately check whether legacy `docs/reference/...` references are intentional route aliases or stale local paths.

> **🔵 CLAUDE - CONFIRMED.** `agents/pm-skill-auditor.md:72` counts contracts under `docs/reference/skill-families/` (0 files); the 3 contracts live at `site/src/content/docs/reference/skill-families/`. A maintainer following it literally would mis-report the family-contract counter as 0. NOT yet fixed; follow-up. (Worked around during the v2.25.1 governance audit by pointing the auditor at the real path so it did not false-positive.)

### P1-03 - `validate-skill-history.ps1` is not compatible with nested metadata

**Location:** `scripts/validate-skill-history.ps1`, `skills/foundation-prioritized-action-plan/SKILL.md`

**Issue:** The only skill with `HISTORY.md` fails history validation:

> `[FAIL] skills\foundation-prioritized-action-plan\HISTORY.md : sibling SKILL.md is missing version`

The sibling skill does have a version, but it is nested under:

```yaml
metadata:
  version: "1.1.0"
```

The validator only reads top-level `version:`.

**Why it matters:** v2.17+ moved toward metadata-nested frontmatter, but this validator still assumes the older shape. It is advisory in CI today, but it will block future enforcement or create false confidence if ignored.

**Fix:** Update both PowerShell and Bash history validators to read `metadata.version` first, fall back to top-level `version`, and include a test fixture for nested metadata.

> **🔵 CLAUDE - CONFIRMED by live run.** `pwsh -File scripts/validate-skill-history.ps1` -> exit 1, `[FAIL] skills\foundation-prioritized-action-plan\HISTORY.md : sibling SKILL.md is missing version` (the version is nested under `metadata:`). The bash sibling has the identical bug. Release-relevance is muted: it is in neither pre-tag bundle and the CI step is `continue-on-error`, so it warns rather than blocks today. NOT yet fixed; follow-up exactly as you describe.

### P1-04 - Local Bash validation is not reproducible on Windows/WSL without Node bridging

**Location:** `scripts/pre-tag-validate.sh`, local environment assumptions.

**Issue:** In this environment, Bash validators fail with `node: command not found` even though PowerShell can run `node -v` and sees `v22.12.0`.

**Why it matters:** The repo advertises cross-platform validation. Maintainers on Windows may reasonably use Git Bash, WSL, or PowerShell. If Bash cannot discover Node but PowerShell can, local release checks become environment-sensitive.

**Fix options:**

- Document that Bash validation on Windows requires Node installed inside the Bash/WSL environment.
- Prefer PowerShell as the Windows local entrypoint.
- Better: use a Node orchestrator with shell wrappers, and fail early with a clear prerequisite message when `node` is not available.

### P1-05 - The repo has structural evals, but not enough outcome evals

**Location:** `scripts/check-sample-*`, `library/skill-output-samples/**`

**Issue:** Current checks are good at structural correctness:

- No placeholders.
- Exact quotes are sourced.
- Sample coverage exists.
- Links and generated docs resolve.

But they do not yet measure whether outputs are actually good PM work. The fabricated-metrics check reports 319 possible hits and is intentionally advisory/noisy.

**Why it matters:** The next quality frontier is not "did every file validate?" It is "did this skill produce a better artifact than a generic model prompt?" Competitors can copy a catalog shape. It is harder to copy measured PM judgment.

**Fix:** Build a small eval harness over the existing sample corpus:

- Golden scenario input.
- Expected artifact rubric.
- pm-critic based review.
- Evidence/provenance score.
- Decision usefulness score.
- Baseline comparison against no-skill prompt.
- Regression threshold per skill family.

Promote only precise invariants to enforcing status. Keep heuristic metric checks advisory until the source-ledger format is strong enough.

> **🔵 CLAUDE - PARTIALLY STALE.** The structural side is confirmed, but an outcome-scoring rubric already exists for one skill (`foundation-prioritized-action-plan/eval/fixtures/`, a Cynefin reasoning-quality rubric that scores judgment, not structure), and the deterministic eval tier (M-30) SHIPPED in v2.25.0 - which this audit observed PASSING in its own Verification Snapshot. The full three-tier harness is already designed at `docs/internal/release-plans/_unreleased/output-eval-harness.md`, and your Spec E re-derives almost exactly its Tier 2/3. So "the repo does not yet measure output quality" overstates it: the cheap deterministic tier ships and the LLM-judged tiers are already planned. Validating, but not net-new.

### P2-01 - The GUI opportunity is real and underexploited

**Location:** Public docs and site.

**Issue:** The site is a good documentation surface, but it is not yet a workbench. Users still need to know which skill to invoke, copy command syntax, and manage generated artifacts manually.

**Why it matters:** Current marketplaces and user expectations are moving toward visual dashboards, browse/search/install flows, and one-click management. BuySkills, for example, positions a visual dashboard and no-terminal install/update/remove as a core benefit. pm-skills can meet this trend without becoming a hosted SaaS.

**Fix:** Add a GUI incrementally:

1. Generated skill/workflow manifest.
2. Interactive skill finder in the Starlight site.
3. Workflow chain builder.
4. Artifact preview pages with copy/run prompts.
5. Optional local workbench for saving runs.

More detail appears in the GUI section below.

### P2-02 - Competitors are weaker in PM depth but stronger in integrations

**Location:** Product positioning.

**Issue:** Comparable product-management plugins often have fewer skills, weaker governance, or narrower PM coverage, but several include MCP servers or explicit integrations. One current ClaudePluginHub product-management plugin lists 6 PM skills, 6 commands, and 12 MCP servers for tools like Notion, Figma, analytics, support, project management, Slack, Linear, and Asana.

**Why it matters:** Integrations make PM skills operational. A PRD skill is useful; a PRD skill that can read Linear issues, synthesize research calls, update Notion, and link evidence is much more useful.

**Fix:** Add optional integration packs rather than bloating the core:

- `pm-skills-core`: current markdown skills.
- `pm-skills-connectors`: MCP recipes and connector-aware skills.
- `pm-skills-workbench`: GUI/local app.

### P2-03 - Some utility skills are long enough to merit more progressive disclosure

**Location:** `skills/utility-*`, especially update/build/iterate/validate utilities.

**Issue:** Several utility skills are over 180 lines, with the largest at 276 lines.

**Why it matters:** Long `SKILL.md` files cost context and can bury the actual decision contract. The broader skills ecosystem is moving toward progressive disclosure: compact trigger/overview up front, detailed procedures in references, scripts for deterministic work.

**Fix:** For the top 5 largest skills, move mechanical details to `references/` or scripts and keep `SKILL.md` focused on:

- Trigger.
- Refusal/guardrails.
- Required workflow.
- Output contract.
- Links to references.

### P2-04 - Per-skill version provenance is weak

**Location:** `skills/*/HISTORY.md`

**Issue:** Only `foundation-prioritized-action-plan` currently has `HISTORY.md`, while many skills carry versions in frontmatter.

**Why it matters:** Users and maintainers cannot easily answer "what changed in this skill?" without scanning release notes and git history. This becomes more important if skills are optimized or eval-scored over time.

**Fix:** Do not backfill all histories immediately. Start with high-change/high-risk skills:

- `deliver-prd`
- `foundation-okr-writer`
- `measure-okr-grader`
- `foundation-prioritized-action-plan`
- `utility-pm-workflow-orchestrator`
- tool sprint families

Adopt `HISTORY.md` when a skill next changes, not as a mass migration.

### P2-05 - Marketplace metadata has no screenshots

**Location:** `.codex-plugin/plugin.json`

**Issue:** `interface.screenshots` is empty.

**Why it matters:** Marketplace pages are increasingly visual. The repo has a strong docs site and sample pages, but plugin listings do not fully show that value.

**Fix:** Add 3 to 5 screenshots:

- Skill finder/catalog page.
- Example skill detail page.
- Workflow page.
- Sample output page.
- Future GUI/workbench page.

### P2-06 - Site build warnings should be triaged before they become upgrade blockers

**Location:** `site/`, Astro/Starlight build.

**Issue:** Build passes but reports:

- Large chunks over 500 kB after minification.
- Duplicate `/404` route rendering conflict.
- Deprecated `markdown.remarkPlugins`, `markdown.rehypePlugins`, and `markdown.remarkRehype` config shape.

**Why it matters:** These are not urgent, but they signal future maintenance cost. The deprecated Astro markdown config is the most likely to become a version-upgrade blocker.

**Fix:** Add a site-maintenance backlog item:

- Update Astro markdown plugin wiring to the current API.
- Investigate Mermaid/Pagefind chunk splitting.
- Resolve or document the 404 conflict.

### P2-07 - The current `docs/` and `site/src/content/docs/` split is cognitively expensive

**Location:** `docs/`, `site/src/content/docs/`, scripts.

**Issue:** Root `docs/` now holds mostly internal docs, templates, and `RESOURCES.md`; public docs live under `site/src/content/docs/`. Historical docs and many source references still speak as if public docs live under root `docs/`.

**Why it matters:** The repo has already paid down much documentation drift, but this split remains a source of confusion for agents and contributors.

**Fix:** Document the current architecture in one short canonical place and enforce it:

- Root `docs/`: internal/audit/templates/resources only.
- `site/src/content/docs/`: public docs source.
- Generated docs: exactly which files are generated and where.
- Link policy: source-local links vs rendered-route links.

Then add validators that encode the policy.

### P2-08 - There is no first-class product/project memory model

**Location:** Product architecture.

**Issue:** Skills consume user input and produce artifacts, but there is no canonical persisted product context: product glossary, personas, constraints, assumptions, research evidence, roadmap, metrics, decisions, and open questions.

**Why it matters:** PM work compounds through memory. Without a product context model, each skill invocation starts too cold, and workflows rely on the user to paste context forward.

**Fix:** Add a lightweight optional project memory convention:

```text
.pm-skills/
  product.md
  glossary.md
  assumptions.md
  evidence/
  artifacts/
  runs/
  decisions/
```

Keep it opt-in and local-first. Do not require it for basic skill use.

### P3-01 - The Codex/Claude invocation story is mostly clear but still verbose

**Location:** README, AGENTS, marketplace metadata.

**Issue:** The repo describes several invocation modes: Claude Code plugin commands, direct skills, Codex `$skill-name`, dispatch skills, sub-agent mentions, workflows. This is accurate but heavy.

**Why it matters:** New users may not know which path applies to them.

**Fix:** Add a "choose your entrypoint" table near the top of README:

| User | Start with |
|---|---|
| PM writing one artifact | Direct skill |
| PM running multi-step process | Workflow command |
| Maintainer releasing pm-skills | Release conductor |
| Codex user | `$skill-name` |
| Unsure | Skill finder |

### P3-02 - The generated site is functional but not yet a product experience

**Location:** `site/`

**Issue:** The site is documentation-first. It could become the best public interface to the catalog with relatively small changes.

**Fix:** Add:

- Searchable skill cards with filters.
- "Copy invocation" buttons.
- "Show me examples" per skill.
- Workflow graph views.
- "Recommended next skill" links based on output handoff.

## High-Level Ideology: What Comes Next

### The current ideology

The repo currently expresses this worldview:

> PM work can be decomposed into repeatable professional artifacts, each artifact can be taught as a skill, and a governed library can make AI agents produce those artifacts more consistently.

That is a good foundation. It avoids vague "AI PM" branding and commits to recognizable PM work products.

### The next ideology

The next worldview should be:

> PM work is not a set of isolated documents. It is a decision system over evidence, constraints, bets, and learning loops. Skills should not only draft artifacts; they should preserve reasoning, connect evidence, update assumptions, and move work through a governed lifecycle.

That ideological shift implies several concrete moves:

1. **Artifacts become typed objects.** A PRD is not just markdown; it has goals, non-goals, users, risks, decisions, metrics, open questions, and links to evidence.
2. **Skills become transformations.** A problem statement transforms into hypotheses; hypotheses transform into experiments; experiment results transform into lessons and next bets.
3. **Workflows become run graphs.** The orchestrator should track input, output, status, failure, checkpoint, and human decision at every step.
4. **Evidence becomes first-class.** Claims should cite source snippets, research artifacts, metrics, or assumptions. Unsupported claims are labeled.
5. **Quality becomes measured.** The library should know when a skill improves, regresses, or merely changes.
6. **Integrations become optional execution surfaces.** The core stays portable markdown, but connector packs make it operational.

> **🔵 CLAUDE - CONVERGENT, not novel (and the audit seems unaware of it).** This "next ideology" is near-verbatim the team's existing `docs/internal/roadmap.md`, dated 2026-05-31 (six days BEFORE this audit) and literally titled "From Skill Library to PM Operating Layer". The roadmap already frames the same three problems (discovery, activation, trust) and already states "the next frontier is not more skills". The `.pm-skills/` persistent-context idea (point on "evidence becomes first-class") is also already shipped in a different shape: `.claude/pm-skills.local.md`, read by the v2.25.0 hooks, with roadmap section 4.4 planning its expansion. So this section is strong INDEPENDENT VALIDATION of direction, but it is not discovery, and adopting the audit's specific `.pm-skills/` directory layout literally would FORK the already-chosen `.claude/pm-skills.local.md` convention. The one item that is genuinely net-new and worth building: the static in-site Skill Finder + generated `skill-manifest.json`.

The key is to avoid becoming another project-management app. The product should be an AI-native PM reasoning layer that can live inside Claude Code, Codex, Cursor, GitHub, Notion, Linear, or a local folder.

## GUI Possibility

Yes, there is a clear path to add a GUI. The repo already has the right ingredients:

- A generated Astro/Starlight site.
- Structured skill frontmatter.
- Workflow definitions.
- Samples.
- Commands.
- Agent metadata.
- Release and validation scripts.

The GUI should not start as a full SaaS. Start as a local/static workbench that makes the existing catalog easier to use.

### GUI Option A - Static Skill Finder inside the current site

**Effort:** Low.

**Shape:** Generate `site/src/data/skill-manifest.json` from skill frontmatter and sample metadata. Add an Astro page with filter/search.

Core controls:

- Search by task, artifact, phase, framework, skill name.
- Filter by classification.
- Show "use when" and output type.
- Copy invocation command for Claude and Codex.
- Link to samples.
- Suggest next skills.

Why this should be first:

- No backend.
- Uses current site.
- Can be built with Astro and vanilla JS.
- Improves discoverability immediately.
- Produces screenshot assets for marketplaces.

### GUI Option B - Workflow Builder

**Effort:** Medium.

**Shape:** Visual workflow graph over the 12 workflows and 65 skills.

Capabilities:

- Pick a goal: "feature kickoff", "customer discovery", "product strategy", "post-launch learning".
- Show required steps and optional branches.
- Copy a runnable prompt chain.
- Export a markdown run plan.
- Preview expected outputs per step.

This aligns with the existing `pm-workflow-orchestrator` and would make human checkpoints visible.

### GUI Option C - Local PM Workbench

**Effort:** Medium to high.

**Shape:** A local app, probably built as an Astro/React or Tauri/Electron workbench, launched by a command such as:

```powershell
npm run workbench
```

Capabilities:

- Select a product workspace.
- Store `.pm-skills/` context.
- Run or copy skill prompts.
- Save generated artifacts.
- Track assumptions, decisions, evidence, and open questions.
- Show workflow run status.

This is the best "PM operating layer" shape while staying local-first.

### GUI Option D - Hosted Marketplace/Product

**Effort:** High.

**Shape:** Hosted product with accounts, collaboration, and integrations.

Do not start here. Hosted PM software brings support, security, multi-tenant data, auth, and compliance obligations. The repo's immediate advantage is portability and trust. A local/static GUI preserves that advantage.

### Recommended GUI Roadmap

1. Generate `skill-manifest.json`.
2. Build static Skill Finder page.
3. Add "copy invocation" and "view samples" interactions.
4. Add Workflow Builder page.
5. Add optional `.pm-skills/` local workspace convention.
6. Only then consider a local workbench app.

## Ecosystem Comparison

### Market context

Agent skills are becoming a platform layer, not a novelty. Anthropic describes skills as reusable instructions and resources that improve specialized tasks, capture organizational knowledge, and can include executable scripts. Anthropic also points to the Agent Skills open standard, positioning the format as portable across tools that adopt it. The Claude API docs now describe attaching skills to managed agents, with each session supporting up to 20 skills.

Public marketplaces are also growing quickly. Current directories advertise large catalogs and visual management:

- ClaudePluginHub lists `pm-skills` as 65 skills, 5 agents, 10 slash commands, 1 hook, version 2.25.0, with strong maintenance and capability scores.
- Tons of Skills advertises hundreds of plugins and thousands of embedded skills.
- BuySkills emphasizes a visual dashboard, one-click install/update/remove, and cross-agent support.

Academic work is also moving quickly:

- SkillOpt argues for systematically optimizing skill text against held-out validation scores.
- AIP proposes compiling skills into schema-validated execution graphs with typed input/output edges.
- CoEvoSkills focuses on self-evolving multi-file skill packages with verifier feedback.

> **🔵 CLAUDE - LIKELY FABRICATED CITATIONS, do not rely on these.** The four arXiv IDs in this audit (SkillOpt `2605.23904`, AIP `2606.04781`, CoEvoSkills `2604.01687`, ecosystem `2602.08004`) are future-dated. arXiv `YYMM` prefixes encode submission month, and `2602`/`2604`/`2605`/`2606` map to Feb/Apr/May/Jun 2026, at or AFTER this audit's own 2026-06-06 date (one is literally "June 2026"). Future-dated IDs attached to named-but-unrecognizable papers are a classic hallucination signature. I could not verify them offline; treat the academic anchors as untrustworthy and strip them before any maintainer-facing use. The directional point (mature skill repos need governance + evals + UX) stands on its own without these citations. (The non-academic links and the ClaudePluginHub `65/5/10/v2.25.0` figures DO check out against the repo.)

The implication: a mature skill repo needs governance, evals, structured artifacts, and UX. pm-skills already has governance. The next gap is evals plus UX.

### Compared with official Anthropic skills

Official Anthropic skills focus on high-value general tasks such as document creation and managed-agent capabilities. They benefit from first-party product integration, automatic invocation, organization provisioning, and a GUI directory.

pm-skills is different:

- Stronger domain specialization for PM work.
- More transparent and open-source.
- More methodology coverage.
- More portable across non-Claude clients.

But official skills have advantages pm-skills lacks:

- Built-in product UI.
- Centralized admin/provisioning.
- Deep integration with first-party runtime.
- User trust from first-party distribution.

### Compared with narrow PRD/product-management plugins

Many PM plugins focus on PRDs, roadmaps, stakeholder updates, metrics reviews, or research synthesis. That makes them easier to understand but narrower.

pm-skills is stronger when the user needs a lifecycle:

- It can start before the PRD.
- It can continue after launch.
- It includes workshops and governance.
- It has sample coverage and validation depth.

Competitors can be stronger when the user wants connected operations:

- Some include MCP servers for Notion, Figma, analytics, support, project management, Slack, Linear, and Asana.
- Some create GitHub Issues directly.
- Some are agent-heavy and promise autonomous PM workflows.

The positioning should be:

> pm-skills is the high-trust open PM methodology layer. Add connectors optionally; do not collapse into a one-off PRD bot.

### Compared with broad "skills marketplace" packs

Broad packs such as Wondelai and multi-domain marketplace libraries often cover product strategy, UX, marketing, sales, motivation, systems architecture, and code quality. Their advantage is breadth across roles.

pm-skills should not try to match every role. It should win by:

- PM depth.
- Quality gates.
- Repeatable artifact contracts.
- Evidence discipline.
- Workflow orchestration.
- Compatibility with other agents and tools.

### Compared with AI PM copilot products

AI PM copilots tend to sell an operating-system story: agents, memory, integrations, roadmap management, and automated workflows.

pm-skills has the raw material for this, but not the full product surface yet. If it wants to compete there, it needs:

- Persistent product context.
- Workflow run state.
- Integration points.
- A GUI.
- Evals and quality scoring.

If it does not want to compete there, it should stay explicit: this is a portable PM skill library, not a PM SaaS.

## What's Missing

### 1. Structured output schemas

Most outputs are markdown-first. That is portable and human-friendly, but it limits automation.

Add optional schemas for high-value artifacts:

- PRD
- Problem statement
- Hypothesis
- Experiment design
- Experiment results
- Release notes
- Retrospective
- Meeting recap
- Opportunity tree
- Prioritized action plan

Use schemas as validation and GUI data models, not as a replacement for markdown.

### 2. Persistent PM context

The repo needs a recommended local workspace convention:

```text
.pm-skills/
  context/
  artifacts/
  evidence/
  runs/
  decisions/
```

This would let skills say "read the product context first" when appropriate, and let workflows accumulate learning.

### 3. Connector-aware variants

Do not make core skills dependent on external tools. Add optional connector recipes:

- GitHub Issues/Projects
- Linear/Jira
- Notion/Google Docs
- Slack/Teams
- Dovetail/Zoom/Fireflies/transcripts
- Amplitude/PostHog/Mixpanel
- Figma

The connector-aware layer should map external data into the same artifact schemas.

### 4. Empirical skill benchmarks

The sample corpus can become an eval suite:

- "No skill" baseline.
- Current skill output.
- Candidate edited skill output.
- pm-critic review.
- Human rubric for top artifacts.
- Regression thresholds.

This aligns with current research trends in skill optimization.

### 5. Security/threat model for hooks and power tools

ClaudePluginHub flags pm-skills with safety signals: modifies files, hook triggers on file write/edit, uses power tools. That is not necessarily bad, but the repo should own the narrative.

Add a short threat model:

- What hooks do and do not inspect.
- What data leaves the machine, if any.
- How to disable hooks.
- What scripts can modify.
- How generated content is controlled.

### 6. Marketplace screenshots and user-facing demos

The repo has strong content but weak visual proof in plugin metadata. Add screenshots and short demo GIFs once the Skill Finder exists.

### 7. Per-skill lifecycle records

Adopt `HISTORY.md` incrementally for high-change skills. This will matter more if evals start showing quality changes over time.

## What To Improve First

### Tier 0 - Release hygiene blockers

1. Fix `pre-tag-validate.ps1`.
2. Reconcile Bash, PowerShell, and CI validator inventories.
3. Fix `validate-skill-history` for nested metadata.
4. Update `pm-skill-auditor` path assumptions.

These are not glamorous, but they protect trust.

### Tier 1 - Source-link and documentation architecture

1. Decide whether root `docs/reference` should exist as stubs or all source links should move to `site/src/content/docs`.
2. Add a validator for markdown links in `skills/`, `agents/`, `_workflows/`, `commands/`, and `AGENTS.md`.
3. Write a short "docs architecture" reference for contributors and agents.

### Tier 2 - GUI MVP

1. Generate `skill-manifest.json`.
2. Add a static Skill Finder page.
3. Add copy buttons and sample previews.
4. Add screenshots to `.codex-plugin/plugin.json` and marketplace metadata.

### Tier 3 - PM operating layer

1. Define `.pm-skills/` workspace convention.
2. Add output schemas for 3 to 5 flagship artifacts.
3. Add workflow run state.
4. Add optional connector recipes.
5. Add eval harness over samples.

## Concrete Implementation Specs

### Spec A - Unified Validator Manifest

Create `scripts/validation-manifest.yaml`:

```yaml
required:
  - id: lint-skills-frontmatter
    shell:
      bash: bash scripts/lint-skills-frontmatter.sh
      pwsh: pwsh -NoProfile -File scripts/lint-skills-frontmatter.ps1
  - id: validate-agents-md
    shell:
      bash: bash scripts/validate-agents-md.sh
      pwsh: pwsh -NoProfile -File scripts/validate-agents-md.ps1
site:
  - id: build-site
    command: npm --prefix site run build
  - id: rendered-links
    command: node scripts/check-rendered-links.mjs site/dist
```

Then:

- Generate `pre-tag-validate.sh`.
- Generate `pre-tag-validate.ps1`.
- Or replace both with wrappers around `node scripts/validate-all.mjs`.

Acceptance criteria:

- PowerShell pre-tag passes on Windows.
- Bash pre-tag passes on Linux CI.
- Both list the same required validator IDs.
- CI cannot add a required validator without updating the manifest.

### Spec B - Source Markdown Link Validator

Create a validator that scans:

- `skills/**/*.md`
- `agents/*.md`
- `_workflows/*.md`
- `commands/*.md`
- `AGENTS.md`
- `README.md`
- `QUICKSTART.md`

It should:

- Parse markdown links outside fenced code blocks.
- Resolve relative file paths.
- Allow external URLs.
- Allow route links only when explicitly marked as site routes.
- Fail on local paths that do not exist.

Acceptance criteria:

- Links to `../../docs/reference/...` fail unless root stubs exist.
- Links to `site/src/content/docs/...` pass.
- Rendered-site links continue to pass separately.

### Spec C - Static Skill Finder

Generate `site/src/data/skill-manifest.json` from:

- Skill directory name.
- Name.
- Description.
- Classification/prefix.
- Version.
- Updated date.
- Category.
- Frameworks.
- Sample files.
- Workflow membership.
- Family membership.

Add `site/src/content/docs/guides/skill-finder.mdx` or a custom Astro page.

Minimum UI:

- Text search.
- Phase/classification filters.
- Framework filter.
- Artifact type filter.
- Cards with "copy Claude invocation" and "copy Codex invocation".
- Links to samples and docs.

Acceptance criteria:

- No backend.
- Build passes.
- Search works offline in the static site.
- Marketplace screenshot can be captured from this page.

### Spec D - Artifact Schema Pilot

Pick three artifacts:

- `deliver-prd`
- `define-hypothesis`
- `measure-experiment-results`

For each:

- Define a JSON schema.
- Add an optional "machine-readable summary" block in output instructions.
- Add sample checks that the block parses.
- Use the schema in the future GUI.

Acceptance criteria:

- Markdown remains the primary human output.
- JSON block is optional for casual use but required in samples.
- Validator catches missing required fields in samples.

### Spec E - Evaluation Harness Pilot

Use existing sample scenarios to create a small eval set:

- 5 skills.
- 3 scenarios each.
- Baseline prompt.
- Current skill prompt.
- pm-critic review pass.
- Rubric score.

Initial rubric dimensions:

- Evidence discipline.
- Decision usefulness.
- Completeness.
- Specificity.
- Appropriate uncertainty.
- Actionability.

Acceptance criteria:

- Outputs a score report.
- Does not block CI initially.
- Can compare two branches.

## Product Strategy Recommendation

### Positioning

Keep the core positioning:

> Open-source Product Management skills for AI agents.

But sharpen the second sentence:

> A governed PM operating layer: structured skills, workflows, examples, validators, and sub-agents that help AI assistants produce evidence-grounded PM work across the product lifecycle.

This claims the higher ground without overclaiming a full SaaS product.

### Strategic choices

#### Choice 1 - Stay a library

Pros:

- Lowest complexity.
- Strong open-source fit.
- Avoids connector/security burden.
- Keeps trust high.

Cons:

- Competitors with integrations feel more useful in daily PM work.
- Discoverability remains command-driven.
- Harder to monetize or build community around usage.

#### Choice 2 - Become a local PM workbench

Pros:

- Adds GUI without SaaS burden.
- Makes workflows tangible.
- Uses current site and manifests.
- Preserves local-first trust.

Cons:

- Requires product/UI maintenance.
- Requires a data model.
- Needs careful scope control.

#### Choice 3 - Become a connected PM copilot

Pros:

- Biggest user value.
- Competes with AI PM operating systems.
- Can automate real workflows.

Cons:

- Highest support and security burden.
- Many integration edge cases.
- Risks diluting the clean skill-library identity.

Recommended default: Choice 2 first. Build the local/static workbench and data model. Let connector demand prove itself before going deeper.

## Suggested Roadmap

### Next 1 to 2 weeks

- Fix PowerShell pre-tag bundle.
- Add validator inventory parity.
- Fix skill-history nested metadata parsing.
- Update pm-skill-auditor path assumptions.
- Decide source-link policy for `docs/reference`.
- Add screenshots only after a useful UI page exists.

### Next release

- Add generated skill manifest.
- Build static Skill Finder.
- Add source markdown link validator.
- Add one new marketplace screenshot.
- Add docs architecture page.

### Next quarter

- Add Workflow Builder.
- Define `.pm-skills/` local workspace convention.
- Pilot structured schemas for PRD, hypothesis, experiment results.
- Pilot eval harness on 5 skills.
- Add connector-aware recipes for GitHub Issues and Linear first.

### Later

- Local PM Workbench.
- MCP connector pack.
- Artifact graph and assumptions ledger.
- Quality score dashboard over skill evals.
- Optional cloud or marketplace-specific distribution only if adoption justifies it.

## Risk Register

| Risk | Likelihood | Impact | Mitigation |
|---|---:|---:|---|
| Validator drift continues across Bash, PowerShell, and CI | High | High | Single manifest or Node orchestrator. |
| GUI scope expands into SaaS prematurely | Medium | High | Start static/local. No accounts. No hosted data. |
| Connector work dilutes core skill quality | Medium | Medium | Keep connectors optional and schema-based. |
| Eval harness becomes noisy and unactionable | Medium | Medium | Start with small human-reviewed rubric set. |
| Docs path split keeps producing broken source links | High | Medium | Add source-link validator and architecture doc. |
| Skill catalog grows without stronger discovery | Medium | Medium | Build Skill Finder before adding many more skills. |
| Hook safety perception hurts adoption | Medium | Medium | Publish a short threat model and disable instructions. |

## Final Assessment

pm-skills is already one of the more mature PM skill/plugin projects in the ecosystem. The catalog depth, validation culture, workflow system, family contracts, and sample corpus are all strong. The repo's biggest weakness is not missing PM frameworks. It is the gap between a high-quality artifact library and an operational PM workbench.

The project should resist the temptation to add many more standalone skills. The next phase should make existing skills easier to choose, safer to run, easier to evaluate, and more connected to persistent product context.

The highest-confidence recommendation is:

1. Repair validator parity.
2. Fix source-link/path drift.
3. Generate a skill manifest.
4. Build a static GUI Skill Finder.
5. Pilot schemas and evals.
6. Add optional connector-aware execution only after the core workbench is coherent.

That path preserves what is great about the repo while moving it toward the market's next shape.

## Source Map

Local evidence:

- `skills/utility-pm-skill-auditor/SKILL.md`
- `agents/pm-skill-auditor.md`
- `scripts/pre-tag-validate.ps1`
- `scripts/pre-tag-validate.sh`
- `.github/workflows/validation.yml`
- `.codex-plugin/plugin.json`
- `.claude-plugin/marketplace.json`
- `site/package.json`
- `package.json`
- `library/skill-output-samples/**`
- `site/src/content/docs/**`

External sources used:

- Anthropic Help Center, "What are Skills?": https://support.claude.com/en/articles/12512176-what-are-skills
- Claude API Docs, "Skills": https://platform.claude.com/docs/en/managed-agents/skills
- ClaudePluginHub listing for pm-skills: https://www.claudepluginhub.com/plugins/product-on-purpose-pm-skills
- ClaudePluginHub product-management examples: https://www.claudepluginhub.com/plugins/sksdesignnew-product-management-product-management
- ClaudeIndex Wondelai marketplace listing: https://www.claudeindex.com/marketplace/wondelai/wondelai-skills
- BuySkills marketplace positioning: https://buyskills.ai/
- Tons of Skills marketplace: https://tonsofskills.com/
- SkillOpt paper: https://arxiv.org/abs/2605.23904
- AIP paper: https://arxiv.org/abs/2606.04781
- CoEvoSkills paper: https://arxiv.org/abs/2604.01687
- Agent Skills ecosystem analysis: https://arxiv.org/abs/2602.08004
