wehub-resource-sync
169 lines
7.0 KiB
Markdown
169 lines
7.0 KiB
Markdown
# 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.
|