Skip to content

MAPPING.md

Latest commit

 

History

History
168 lines (120 loc) · 7.03 KB

MAPPING.md

File metadata and controls

168 lines (120 loc) · 7.03 KB

Mapping: Existing Skills → Public v1

This document records the historical porting decisions for the initial public skill set (v1). It exists so contributors can see why a skill looks the way it does.

Note: This is a historical document covering the initial v1 port. The current catalog has expanded substantially (see README.md for the current count and full list). The mapping below covers only the original v1 ports and net-new writes.

Summary

The starting position: 5 user-scoped skills. The public v1: 11 skills. Five of the public skills are generic ports of existing ones. Six were net-new and written from scratch. Subsequent versions added many more skills covering the full lifecycle.

Existing skill Maps to Action
design-framework design-standards Port + genericize
pm-framework pm-spec-writing Port + genericize
seo-review seo-foundations Port + lighten
dev-code-review code-review-web Port + abstract
qa-testing qa-testing Port + lighten
New skill Source Action
brand-discovery New Write from scratch
creative-brief New Write from scratch (prototype done)
information-architecture New Write from scratch
content-and-copy New Write from scratch
launch-runbook New Write from scratch
after-action-report New Write from scratch

Port decisions, skill by skill

design-framework → design-standards

Keep:

  • WCAG AA contrast ratios and the contrast checker JS
  • The pre-ship checklist (mostly)
  • Section pattern philosophy (hero, card grid, data row, CTA banner)

Genericize or remove:

  • Tailwind class libraries → reference patterns conceptually, give one Tailwind example as a reference file, give equivalent vanilla CSS
  • #E47200 not #FF9900 Amazon orange rule → genericize as "verify brand color contrast against actual backgrounds"
  • The specific hex tokens (#1A1D23, etc.) → replace with role-based tokens that the user fills in
  • Affiliate-specific markup (rel="nofollow sponsored") → keep but make optional

Add:

  • Stack-agnostic component patterns (React + vanilla HTML side by side in a reference file)
  • Type scale guidance independent of Tailwind classes
  • Spacing system explanation (8px grid as the default reference)

Risk: stripping the Tailwind classes makes it less immediately useful for your own projects. Mitigation: ship a references/tailwind-patterns.md reference file that contains the existing Tailwind library, so you don't lose anything.

pm-framework → pm-spec-writing

Keep:

  • The IDEA → SPEC → BRIEF → SHIP loop
  • The dev brief structure (CONTEXT / TASK / CONSTRAINTS / VERIFY)
  • Impact vs effort quadrant
  • Feature planning templates (new page, content entry, bug report)
  • Decision log structure

Genericize or remove:

  • Multi-agent orchestration section → split out. This is a power-user pattern that doesn't belong in a generic public skill. Consider a separate ai-agent-orchestration skill later.
  • Sprint rhythm → keep but loosen the SEO-revenue-affiliate framing
  • Launch checklist → move to the new launch-runbook skill (this is its proper home)

Add:

  • User story format (As a / I want / So that) for teams that prefer it
  • Acceptance criteria patterns
  • A worked example from idea to ticket

Risk: removing the launch checklist creates churn. Mitigation: it lives in launch-runbook now, where it belongs, and pm-spec-writing references it.

seo-review → seo-foundations

Keep:

  • Technical SEO checklist (canonical, sitemap, robots.txt, schema)
  • On-page patterns
  • E-E-A-T signals
  • AEO and GEO sections
  • Schema markup patterns

Genericize or remove:

  • Any references to specific affiliate networks
  • Project-specific examples from your own portfolio
  • Stack-specific implementation (Next.js metadata API, etc.) → move to a references/stack-implementations.md file

Add:

  • Pre-launch SEO checklist as a separate quick-reference file
  • llms.txt guidance (since this is becoming standard)

dev-code-review → code-review-web

Keep:

  • Bug-finding mindset
  • Security review patterns
  • Performance review patterns

Genericize or remove:

  • Next.js/Supabase-specific failure modes → move to a references/stack-quirks.md file with Next.js, WordPress, and vanilla sections
  • TypeScript-specific patterns → keep but mark as optional
  • ISR-specific guidance → reference file

Add:

  • A general code review checklist that works for any web stack
  • Accessibility review section (was implicit, make explicit)

Risk: loses some of its punch when stripped of stack opinions. Mitigation: the reference files preserve the depth, and the trigger description still hooks the same review intent.

qa-testing → qa-testing (same name)

Keep:

  • Functional QA flow
  • Accessibility checks
  • Performance checks
  • Cross-browser checks

Genericize or remove:

  • Any Vercel/Supabase-specific deploy verification → reference file
  • WordPress-specific patterns (you have a section on these) → reference file

Add:

  • A QA report template (markdown) so the output is consistent
  • Pre-launch vs post-deploy QA distinction (different scopes)

What does NOT get ported

A few patterns from your existing skills are intentionally not in the public set:

  • Multi-agent orchestration - too specific to your workflow. Could be a separate skill later.
  • /go/[slug] affiliate redirects - too specific to your monetization model. Mention briefly in seo-foundations as one valid pattern, not as the standard.
  • llms.txt on all sites - keep as a recommendation in seo-foundations but not a non-negotiable.
  • Personal style preferences (em dash prohibition, hashtag-in-comments, specific monetization patterns). These live in your private skills, not the public set.

v1 ship plan

Suggested order to write the remaining skills:

  1. Done: creative-brief (prototype, sets the pattern)
  2. Port next (lowest risk, you already have the content): design-standards, pm-spec-writing, qa-testing
  3. Port after that: seo-foundations, code-review-web
  4. Write new: brand-discovery (precedes creative-brief, so write next)
  5. Write new: information-architecture, content-and-copy
  6. Write new last: launch-runbook, after-action-report

This order means the most-used skills land first, so you can dogfood them on a real project before the rest are written.

Open questions to revisit

  • Do brand-discovery and creative-brief stay separate or merge? Default: separate. Different triggers, different outputs.
  • Should code-review-web split into code-review-frontend and code-review-backend? Default: no for v1. Revisit if the skill gets too long.
  • Should there be a accessibility skill, or does it stay distributed across design-standards, qa-testing, and code-review-web? Default: distributed. Accessibility is a quality dimension, not a phase.
  • License: MIT. Confirm this is what you want before publishing.