boxpositron/absolute-dotfiles
1
0
Fork 0
mirror of https://github.com/boxpositron/absolute-dotfiles.git synced 2026-10-24 08:23:19 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(opencode): vendor ten marketing and copy skills

Browse Source 
- Copy product-marketing, copywriting, copy-editing, emails,
  cold-email, content-strategy, seo-audit, ai-seo, launch and social
  unchanged from coreyhaines31/marketingskills at b9ba399, with its MIT
  license in each directory
- link-ai-configs.sh links each into the OpenCode, Claude Code and omo
  skill directories
- Document provenance and the upgrade path in the OpenCode README
This commit is contained in:
David Ibia
2026-10-08 15:09:40 +01:00
parent 0ec56aa8c5
commit cac5c1d036
78 changed files with 12195 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.config/opencode/skills/launch/references/shipped-changes.md
+84
View File
@@ -0,0 +1,84 @@
# From Shipped Code to Marketing
Most product updates never get marketed because nobody translates them. The engineers wrote the PR description for each other, and by the time marketing hears about it, the moment has passed. An agent with access to the repo can close that gap every week: read what shipped, decide what's worth telling, and draft it in customer language.
## Inputs
For the chosen window (usually the last week, or since the last release tag):
- **Merged PRs** with titles, descriptions, and linked issues. These explain *why* better than commits do.
- **Commit log** for anything merged without a PR: `git log --since="1 week ago" --no-merges --pretty=format:"%h %s (%an, %ar)"`
- **Changed files**, read wherever a title doesn't make the user-facing effect clear.
- **Release notes or tags**, if the team already writes them.
- **Feature flags**: what's actually live for customers versus merged behind a flag.
Only market what customers can use today. Anything behind a flag, in internal beta, or not yet deployed waits.
## Translate before you write
Engineering changes are described by what changed in the code. Customers care about what changed for them. For each change, write one line: **"You can now ___"** or **"___ no longer ___."** If you can't fill that in, the change is invisible to customers. Refactors, dependency bumps, CI, and test changes go in no marketing output at all.
Then group the visible changes with the tiers in the Ongoing Launch Strategy section of `SKILL.md`:
| Tier | Typical changes | Output |
|------|-----------------|--------|
| **Major** | New capability, new plan, big workflow change | Changelog + blog post + email + social + in-app |
| **Medium** | New integration, notable UX improvement, performance gain customers can feel | Changelog + targeted email or in-app + one social post |
| **Minor** | Fixes, polish, small additions | Changelog only, batched |
Several medium changes that share a theme ("five improvements to reporting") can be bundled into one major-tier story.
## Ground every claim in the change
- State what the change does, not what it might do for someone. "Exports now include custom fields," not "unlock deeper insights."
- Use numbers only if they come from the change itself (a benchmark in the PR, a measured speedup). Never invent customer results, adoption, or impact.
- If a PR says the change is partial ("phase 1," "first step toward"), the announcement says so too.
- Credit the user who asked for it, where the team does that and the user agreed.
## Watch for marketing that just became wrong
Every shipped change can also make an existing claim false: a new limit, a renamed plan, a removed integration, a price change. Check the site, docs, comparison pages, and ads for statements the change contradicts. On a schedule, this is the claim-drift loop in `marketing-loops`.
New capabilities also open new search demand. A new integration can deserve its own page ("[Product] + [Tool] integration"), and a new feature can answer queries or comparisons the product couldn't win before. Add those to the content backlog (see `content-strategy` and `competitors`).
## Weekly digest format
```markdown
## Shipped: [date range]
### For customers
- **[Major]** [You can now ...] (PR #123)
- **[Medium]** [You can now ...] (PR #130)
- **[Minor]** [Fixed ...] (PR #131, #134)
### Changelog entry
## [version or date]
### Added
- [Customer-facing description]
### Changed
- [...]
### Fixed
- [...]
### Drafts
- Blog post: [working title], [angle], [who it's for]
- Email: [subject line options] → [segment]
- Social: [one post per major or medium change, built on its single most useful detail]
- In-app: [message + where it appears]
### Pages to update
- [Page]: [statement that's now wrong or incomplete]
### New content opportunities
- [Query or comparison the change makes winnable]
```
Use Keep a Changelog headings (Added, Changed, Deprecated, Removed, Fixed, Security) so the changelog stays scannable over time.
## Writing the drafts
- **Changelog:** one line per change, written for a customer and in past or present tense. Link docs for anything non-obvious.
- **Blog post (major only):** the problem the customer had, what changed, how to use it (with screenshots), and who it's for. The `copywriting` skill covers structure; its AI-tell rules apply.
- **Email:** lead with the change for that segment; one call to action that takes them to the feature. See `emails`.
- **Social:** one concrete detail per post, with a screenshot or 10-second clip of the feature doing it. See `social`.
Drafts are staged for a human to review and send. Nothing in this workflow publishes on its own.
.config/opencode/skills/launch/references/site-launch-qa.md
+57
View File
@@ -0,0 +1,57 @@
# Site Launch QA
The checks to run before and right after a website goes live: a new site, a redesign, a platform migration, or a big new section. Product launches fail quietly when the site underneath them breaks, and most of these failures are invisible from the homepage.
Run it in three passes: before the switch, at the switch, and in the first two weeks after.
## Before the switch
**Content and links**
- [ ] Every page in the plan exists, with final copy (no lorem ipsum, "TBD," or test prices)
- [ ] Crawl the staging site for broken internal links and missing images
- [ ] Legal pages (privacy, terms, cookie policy) are present and current
- [ ] Contact details, pricing, and plan names match what sales and support say
**Forms and conversions**
- [ ] Submit every form with a test entry and confirm it reaches the inbox, CRM, or tool it should
- [ ] Confirmation messages and redirects work, and spam protection doesn't block real submissions
- [ ] Conversion tracking fires on the confirmed submission, not the button click (the `conversion-tracking` skill covers the setup and the test)
- [ ] Analytics is installed once, on every page, with internal traffic filtered
- [ ] Consent banner works and tags respect it
**SEO**
- [ ] Every page has a unique title, meta description, and one H1
- [ ] Canonical tags point to the production domain, not staging
- [ ] Staging is `noindex` or password-protected, and production is **not** (the most common launch-day SEO failure is shipping the staging `noindex`)
- [ ] `robots.txt` allows the pages you want indexed; the XML sitemap lists production URLs
- [ ] Structured data validates (Rich Results Test for Google features, Schema Markup Validator for everything else)
- [ ] For a migration: the redirect map is loaded and tested on a sample of old URLs (see the `site-architecture` skill's platforms and migration reference)
**Performance and access**
- [ ] Core Web Vitals are acceptable on the key templates, on mobile
- [ ] Pages work on mobile, in Safari, and inside in-app browsers (LinkedIn, Instagram, Facebook)
- [ ] Images have alt text; forms have labels; keyboard navigation works
- [ ] Open Graph images and titles render correctly when the URL is shared
**Rollback**
- [ ] You know how to roll back on this platform, and someone has done it once. Examples: Vercel and Netlify promote a previous deployment; Webflow restores a site backup; WordPress restores from a backup plugin or host snapshot; Ploy ◆ promotes a previous deploy from its Deploys screen (its CLI always publishes to production, with no staging target, so preview before publishing).
- [ ] DNS TTL lowered a day ahead if the switch involves DNS changes
◆ marks a [Verified Partner](https://github.com/coreyhaines31/marketingskills/blob/main/tools/REGISTRY.md#verified-partners) of this repository: disclosure, not endorsement.
## At the switch
- [ ] Deploy redirects at the same moment as the new site
- [ ] Confirm HTTPS works on every hostname (`www` and apex) and one redirects to the other
- [ ] Load the top 10 pages by traffic and check content, title, canonical, and a 200 status
- [ ] Submit one real form and confirm it arrives everywhere it should
- [ ] Submit the sitemap in Search Console and Bing Webmaster Tools
- [ ] Re-check that production isn't `noindex`
## The first two weeks
- [ ] Search Console: watch coverage and 404s daily for the first week, then weekly; fix missing redirects as they show up
- [ ] Compare traffic and conversions to the same period before, page by page, not just in total
- [ ] Confirm conversions are arriving in each ad platform at the expected rate
- [ ] Fix internal links that still point at redirected URLs
- [ ] Collect the bugs the team and customers report, and decide what's urgent