100xprism 2.3.1

package/modules/cold-email/references/subject-lines.md

@@ -0,0 +1,53 @@
+# Subject Line Optimization
+
+The subject line determines whether the email gets read. The data is counterintuitive: **short, boring, internal-looking subject lines win decisively.**
+
+## Length: 2–4 words
+
+- 2-word subject lines get **60% more opens** than 5-word (Lavender).
+- Going from 2 to 4 words reduces replies by **17.5%**.
+- 2–4 words yield **46% open rates** vs 34% for 10 words (Belkins, 5.5M emails).
+- Mobile truncates at 30–35 characters — brevity is practical necessity.
+
+## Internal Camouflage Principle
+
+Subject lines that look like they came from a colleague, not a vendor, double open rates (Gong). Buyers mentally categorize before opening — if it looks like sales, it's filtered.
+
+**High-performing examples:** "reply rates" · "trial delays" · "hiring ops" · "employee turnover" · "Q2 forecast" · "new patients" · "personalization issue" · "second page"
+
+## Capitalization: lowercase wins
+
+All-lowercase has highest open rates (Gong, 85M+ emails). Lowercase looks more personal/internal. For cold outreach specifically, lowercase beats title case.
+
+## Personalization: context over name
+
+Personalized subject lines boost opens **26–50%**, but type matters:
+
+- **First name in subject line → 12% fewer replies.** Signals automation.
+- **Contextual personalization works:** pain points, competitors, trigger events, industry challenges.
+- Use {{painPoint}}, {{competitor}}, {{commonGround}} — not {{firstName}}.
+
+## Questions: only when highly specific
+
+Data conflicts: Belkins says questions perform well (46% open rate). Lavender says questions lower opens by **56%**. Resolution: **specific pain questions work** ("Need help with {{challenge}}?"), **generic questions fail** ("Quick question?" / "Have 15 minutes?"). Default to statements.
+
+## What to Avoid
+
+| Anti-pattern                                   | Impact                      |
+| ---------------------------------------------- | --------------------------- |
+| Salesy language ("increase," "boost," "ROI")   | -17.9% opens                |
+| Urgency words ("ASAP," "urgent")               | Below 36% opens             |
+| Excessive punctuation ("!!!" or "??")          | -36% opens                  |
+| Numbers and percentages                        | -46% opens                  |
+| Emojis                                         | Hurt B2B professionalism    |
+| Pitching product in subject                    | -57% replies                |
+| Empty/no subject line                          | +30% opens but -12% replies |
+| Spam triggers ("free," "guarantee," "act now") | Deliverability risk         |
+
+## C-Suite Subject Lines
+
+Executives receive 300–400 emails daily, decide in seconds. They respond **23% more often** than non-C-suite when emails pass their filter (6.4% reply rate).
+
+What works: ultra-concise, human, understated. "{{companyInitiative}}" · "thank you" · "an update" · "a question" · reference to a specific project or trigger event.
+
+Anything "salesy" is immediately rejected.

package/modules/commit/SKILL.md

@@ -0,0 +1,195 @@
+---
+name: commit
+description: Quality gate runs FIRST. **Do NOT commit if any gate fails.**
+category: lifecycle
+tier: core
+slash_command: /commit
+---
+
+# Commit — Gate → Stage → Commit
+
+Quality gate runs FIRST. **Do NOT commit if any gate fails.**
+
+## Do NOT ask for permission. Do NOT skip the gate.
+
+---
+
+## Phase 0 — Quality Gate (MANDATORY)
+
+Check gate cache first — skip if it already passed for this exact tree state. The
+cache is keyed on a tree token (HEAD + tracked diff + untracked files), not a bare
+HEAD, so a dirty or rebased tree never reuses a stale pass:
+
+```bash
+TOKEN=$(python3 ~/100xprism/hooks/gate-pass.py --print 2>/dev/null)
+CACHED=$(cat ~/.100xprism/gate-cache 2>/dev/null)
+[ -n "$TOKEN" ] && [ "$CACHED" = "$TOKEN" ] && echo "Gate: skipped (already passed for this tree)" && GATE_DONE=true || GATE_DONE=false
+```
+
+If `GATE_DONE=false`: run the **gate** workflow. On pass, record it (same token the
+gate-on-commit hook checks):
+```bash
+python3 ~/100xprism/hooks/gate-pass.py
+```
+
+Do NOT proceed until gate reports `✅ ALL GATES PASSED`. If any gate fails → STOP, fix, clear cache, re-run gate.
+
+---
+
+## Phase 1 — Review changes
+
+```bash
+PROJECT_ROOT=$(git rev-parse --show-toplevel)
+cd "$PROJECT_ROOT"
+git status
+git diff --stat
+git diff --name-only HEAD 2>/dev/null || true
+```
+
+---
+
+## Phase 2 — Update docs (if needed)
+
+Based on what changed, update corresponding documentation:
+
+| Changed files | Doc to update |
+|---|---|
+| API routes or handlers | API reference doc (README, project instruction file, or `docs/`) |
+| CLI commands or flags | CLI reference doc |
+| New features or config | README.md or project-equivalent |
+| Removed files/features | Remove stale references from all docs |
+| `.claude/commands/**` | No doc update needed |
+
+Read the project instruction file for specific doc file paths. Skip if no docs are affected.
+
+---
+
+## Phase 3 — Stage files
+
+Stage only task-related files. Never stage `.env`, `dist/`, `node_modules/`, `venv/`, unrelated work:
+
+```bash
+git add -u
+# Or stage specific files if -u picks up unrelated changes:
+# git add path/to/file1 path/to/file2
+git diff --staged --stat
+```
+
+---
+
+## Phase 4 — Write and create commit
+
+Use [Conventional Commits](https://www.conventionalcommits.org/). Focus on **why**, not just what.
+
+| Type | When to use |
+|---|---|
+| `feat` | New feature or capability |
+| `fix` | Bug fix |
+| `test` | Adding or updating tests |
+| `chore` | Tooling, config, scripts, CI |
+| `docs` | Documentation only |
+| `refactor` | Code change with no behavior change |
+| `perf` | Performance improvement |
+| `security` | Vulnerability fix |
+
+```bash
+git commit -m "$(cat <<'EOF'
+<type>(<scope>): <short summary under 72 chars>
+
+- <Key change 1 and why>
+- <Key change 2 and why>
+
+Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
+EOF
+)"
+```
+
+---
+
+## Phase 5 — Code Review
+
+Check review cache — skip if this HEAD was already reviewed:
+
+```bash
+HEAD=$(git rev-parse HEAD)
+REVIEWED=$(cat ~/.100xprism/review-cache 2>/dev/null)
+[ "$REVIEWED" = "$HEAD" ] && echo "Review: skipped (already done for $HEAD)" && exit 0
+```
+
+Otherwise, run a full review:
+
+```bash
+git diff HEAD~1 --stat
+PR=$(gh pr list --head "$(git branch --show-current)" --json number -q '.[0].number' 2>/dev/null)
+[ -n "$PR" ] && echo "PR #$PR found" || echo "No PR — running diff review"
+```
+
+**If a PR exists** → run the **code-review** skill: `/review $PR`
+
+**If no PR** → spawn **one** review Agent on `git diff HEAD~1`. The Agent reads the full diff and scans surrounding codebase for context. Cover all five dimensions in a single pass:
+
+### Review dimensions (all required)
+
+**1. Bug review**
+- Null/undefined dereferences, off-by-one errors, wrong conditions
+- Unhandled error paths, missing awaits, silent catch blocks
+- Race conditions, state mutation side effects
+
+**2. Security review**
+- Injection vectors (SQL, shell, XSS), auth bypass, missing input validation
+- Exposed secrets or tokens, insecure defaults, overly permissive CORS/headers
+- Privilege escalation risks in new routes or handlers
+
+**3. Architecture review**
+- Does the change respect existing layer boundaries (e.g. routes → services → DB, not routes → DB directly)?
+- Does it introduce patterns inconsistent with the rest of the codebase?
+- Are new abstractions justified, or is this premature generalization?
+- Does it create circular dependencies or tight coupling between modules?
+- Does it belong in the right layer/module — or is it a responsibility leak?
+
+**4. Design review**
+- Are names (variables, functions, files) clear and consistent with existing conventions?
+- Is the interface (function signatures, return types, API shape) clean and minimal?
+- Is there unnecessary duplication that should be extracted — or over-extracted abstraction that should be inlined?
+- Do new data structures match the project's existing patterns (shape, naming, serialization)?
+- Are SOLID principles respected — single responsibility, open/closed, dependency inversion?
+
+**5. CLAUDE.md / project rules compliance**
+- Read the project instruction file and verify all new code follows its conventions
+- Flag any deviation from documented patterns, naming rules, or architectural decisions
+
+### Severity
+
+| Level | Action |
+|---|---|
+| **Critical** | Bug, security hole, or architectural violation that breaks correctness or safety → fix before push |
+| **High** | Design smell or pattern inconsistency that will compound over time → fix before push |
+| **Minor** | Style, naming preference, small improvement → log, non-blocking |
+
+**Critical or High issues found** → fix now, create a new commit, re-run gate. Do NOT push.
+
+On clean review, cache the result so push skips re-reviewing the same HEAD:
+```bash
+echo "$(git rev-parse HEAD)" > ~/.100xprism/review-cache
+```
+
+---
+
+## Phase 6 — Verify
+
+```bash
+git log --oneline -3
+```
+
+---
+
+## Output
+
+```
+=== /commit Complete ===
+Gate:         ✅ ALL GATES PASSED
+Staged files: N
+Commit:       <short-hash> <message>
+Review:       ✅ No critical issues | ⚠️ N minor notes
+Status:       COMMITTED ✅
+```

package/modules/competitor-alternatives/SKILL.md

@@ -0,0 +1,256 @@
+---
+name: competitor-alternatives
+description: "When the user wants to create competitor comparison or alternative pages for SEO and sales enablement. Also use when the user mentions 'alternative page,' 'vs page,' 'competitor comparison,' 'comparison page,' '[Product] vs [Product],' '[Product] alternative,' 'competitive landing pages,' 'how do we compare to X,' 'battle card,' or 'competitor teardown.' Use this for any content that positions your product against competitors. Covers four formats: singular alternative, plural alternatives, you vs competitor, and competitor vs competitor. For sales-specific competitor docs, see sales-enablement."
+category: marketing
+tier: on-demand
+---
+
+# Competitor & Alternative Pages
+
+You are an expert in creating competitor comparison and alternative pages. Your goal is to build pages that rank for competitive search terms, provide genuine value to evaluators, and position your product effectively.
+
+## Initial Assessment
+
+**Check for product marketing context first:**
+If `.agents/product-marketing-context.md` exists (or `.claude/product-marketing-context.md` in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.
+
+Before creating competitor pages, understand:
+
+1. **Your Product**
+   - Core value proposition
+   - Key differentiators
+   - Ideal customer profile
+   - Pricing model
+   - Strengths and honest weaknesses
+
+2. **Competitive Landscape**
+   - Direct competitors
+   - Indirect/adjacent competitors
+   - Market positioning of each
+   - Search volume for competitor terms
+
+3. **Goals**
+   - SEO traffic capture
+   - Sales enablement
+   - Conversion from competitor users
+   - Brand positioning
+
+---
+
+## Core Principles
+
+### 1. Honesty Builds Trust
+- Acknowledge competitor strengths
+- Be accurate about your limitations
+- Don't misrepresent competitor features
+- Readers are comparing—they'll verify claims
+
+### 2. Depth Over Surface
+- Go beyond feature checklists
+- Explain *why* differences matter
+- Include use cases and scenarios
+- Show, don't just tell
+
+### 3. Help Them Decide
+- Different tools fit different needs
+- Be clear about who you're best for
+- Be clear about who competitor is best for
+- Reduce evaluation friction
+
+### 4. Modular Content Architecture
+- Competitor data should be centralized
+- Updates propagate to all pages
+- Single source of truth per competitor
+
+---
+
+## Page Formats
+
+### Format 1: [Competitor] Alternative (Singular)
+
+**Search intent**: User is actively looking to switch from a specific competitor
+
+**URL pattern**: `/alternatives/[competitor]` or `/[competitor]-alternative`
+
+**Target keywords**: "[Competitor] alternative", "alternative to [Competitor]", "switch from [Competitor]"
+
+**Page structure**:
+1. Why people look for alternatives (validate their pain)
+2. Summary: You as the alternative (quick positioning)
+3. Detailed comparison (features, service, pricing)
+4. Who should switch (and who shouldn't)
+5. Migration path
+6. Social proof from switchers
+7. CTA
+
+---
+
+### Format 2: [Competitor] Alternatives (Plural)
+
+**Search intent**: User is researching options, earlier in journey
+
+**URL pattern**: `/alternatives/[competitor]-alternatives`
+
+**Target keywords**: "[Competitor] alternatives", "best [Competitor] alternatives", "tools like [Competitor]"
+
+**Page structure**:
+1. Why people look for alternatives (common pain points)
+2. What to look for in an alternative (criteria framework)
+3. List of alternatives (you first, but include real options)
+4. Comparison table (summary)
+5. Detailed breakdown of each alternative
+6. Recommendation by use case
+7. CTA
+
+**Important**: Include 4-7 real alternatives. Being genuinely helpful builds trust and ranks better.
+
+---
+
+### Format 3: You vs [Competitor]
+
+**Search intent**: User is directly comparing you to a specific competitor
+
+**URL pattern**: `/vs/[competitor]` or `/compare/[you]-vs-[competitor]`
+
+**Target keywords**: "[You] vs [Competitor]", "[Competitor] vs [You]"
+
+**Page structure**:
+1. TL;DR summary (key differences in 2-3 sentences)
+2. At-a-glance comparison table
+3. Detailed comparison by category (Features, Pricing, Support, Ease of use, Integrations)
+4. Who [You] is best for
+5. Who [Competitor] is best for (be honest)
+6. What customers say (testimonials from switchers)
+7. Migration support
+8. CTA
+
+---
+
+### Format 4: [Competitor A] vs [Competitor B]
+
+**Search intent**: User comparing two competitors (not you directly)
+
+**URL pattern**: `/compare/[competitor-a]-vs-[competitor-b]`
+
+**Page structure**:
+1. Overview of both products
+2. Comparison by category
+3. Who each is best for
+4. The third option (introduce yourself)
+5. Comparison table (all three)
+6. CTA
+
+**Why this works**: Captures search traffic for competitor terms, positions you as knowledgeable.
+
+---
+
+## Essential Sections
+
+### TL;DR Summary
+Start every page with a quick summary for scanners—key differences in 2-3 sentences.
+
+### Paragraph Comparisons
+Go beyond tables. For each dimension, write a paragraph explaining the differences and when each matters.
+
+### Feature Comparison
+For each category: describe how each handles it, list strengths and limitations, give bottom line recommendation.
+
+### Pricing Comparison
+Include tier-by-tier comparison, what's included, hidden costs, and total cost calculation for sample team size.
+
+### Who It's For
+Be explicit about ideal customer for each option. Honest recommendations build trust.
+
+### Migration Section
+Cover what transfers, what needs reconfiguration, support offered, and quotes from customers who switched.
+
+**For detailed templates**: See [references/templates.md](references/templates.md)
+
+---
+
+## Content Architecture
+
+### Centralized Competitor Data
+Create a single source of truth for each competitor with:
+- Positioning and target audience
+- Pricing (all tiers)
+- Feature ratings
+- Strengths and weaknesses
+- Best for / not ideal for
+- Common complaints (from reviews)
+- Migration notes
+
+**For data structure and examples**: See [references/content-architecture.md](references/content-architecture.md)
+
+---
+
+## Research Process
+
+### Deep Competitor Research
+
+For each competitor, gather:
+
+1. **Product research**: Sign up, use it, document features/UX/limitations
+2. **Pricing research**: Current pricing, what's included, hidden costs
+3. **Review mining**: G2, Capterra, TrustRadius for common praise/complaint themes
+4. **Customer feedback**: Talk to customers who switched (both directions)
+5. **Content research**: Their positioning, their comparison pages, their changelog
+
+### Ongoing Updates
+
+- **Quarterly**: Verify pricing, check for major feature changes
+- **When notified**: Customer mentions competitor change
+- **Annually**: Full refresh of all competitor data
+
+---
+
+## SEO Considerations
+
+### Keyword Targeting
+
+| Format | Primary Keywords |
+|--------|-----------------|
+| Alternative (singular) | [Competitor] alternative, alternative to [Competitor] |
+| Alternatives (plural) | [Competitor] alternatives, best [Competitor] alternatives |
+| You vs Competitor | [You] vs [Competitor], [Competitor] vs [You] |
+| Competitor vs Competitor | [A] vs [B], [B] vs [A] |
+
+### Internal Linking
+- Link between related competitor pages
+- Link from feature pages to relevant comparisons
+- Create hub page linking to all competitor content
+
+### Schema Markup
+Consider FAQ schema for common questions like "What is the best alternative to [Competitor]?"
+
+---
+
+## Output Format
+
+### Competitor Data File
+Complete competitor profile in YAML format for use across all comparison pages.
+
+### Page Content
+For each page: URL, meta tags, full page copy organized by section, comparison tables, CTAs.
+
+### Page Set Plan
+Recommended pages to create with priority order based on search volume.
+
+---
+
+## Task-Specific Questions
+
+1. What are common reasons people switch to you?
+2. Do you have customer quotes about switching?
+3. What's your pricing vs. competitors?
+4. Do you offer migration support?
+
+---
+
+## Related Skills
+
+- **programmatic-seo**: For building competitor pages at scale
+- **copywriting**: For writing compelling comparison copy
+- **seo-audit**: For optimizing competitor pages
+- **schema-markup**: For FAQ and comparison schema
+- **sales-enablement**: For internal sales collateral, decks, and objection docs

package/modules/competitor-alternatives/evals/evals.json

@@ -0,0 +1,93 @@
+{
+  "skill_name": "competitor-alternatives",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Create a 'Best Asana Alternatives' page for our project management tool. We compete mainly on price (we're $8/user vs their $24/user) and simplicity (they've become bloated). Target audience is small teams (5-20 people).",
+      "expected_output": "Should check for product-marketing-context.md first. Should identify this as the plural alternatives format ([Competitor] Alternatives). Should include the essential sections: TL;DR comparison, brief paragraphs on each alternative (including the user's product positioned first or prominently), feature comparison table, pricing comparison, who each alternative is best for. Should use the modular content architecture approach. Should address SEO considerations for the target keyword 'Asana alternatives.' Should position the user's product with the stated differentiators (price, simplicity).",
+      "assertions": [
+        "Checks for product-marketing-context.md",
+        "Identifies as plural alternatives format",
+        "Includes TL;DR comparison section",
+        "Includes feature comparison table",
+        "Includes pricing comparison",
+        "Includes 'who it's best for' per alternative",
+        "Positions user's product prominently with differentiators",
+        "Addresses SEO for target keyword"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Write a 'HubSpot vs Salesforce' comparison page. We're HubSpot and want to show why we're the better choice for SMBs.",
+      "expected_output": "Should identify this as the 'you vs competitor' format. Should include structured comparison sections: overview of both, feature-by-feature comparison, pricing comparison, pros/cons of each, who each is best for, and migration path. Should be factually accurate about the competitor while strategically positioning the user's product. Should include a TL;DR at the top. Should address the SMB angle throughout. Should use the centralized competitor data architecture pattern.",
+      "assertions": [
+        "Identifies as 'you vs competitor' format",
+        "Includes structured comparison sections",
+        "Includes feature-by-feature comparison",
+        "Includes pricing comparison",
+        "Includes TL;DR at the top",
+        "Factually accurate about competitor",
+        "Strategically positions user's product for SMBs",
+        "Includes migration path or switching section"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "we need a page targeting 'mailchimp alternative' (singular). we're an email marketing platform focused on e-commerce brands.",
+      "expected_output": "Should trigger on casual phrasing. Should identify this as the singular alternative format ([Competitor] Alternative — positioning your product as THE alternative). Should focus the entire page on why the user's product is the best Mailchimp alternative for e-commerce. Should include: why people switch from Mailchimp, what the user's product does better (e-commerce specific features), feature comparison, pricing comparison, migration guide, customer testimonials. Should optimize for the singular keyword 'Mailchimp alternative.'",
+      "assertions": [
+        "Triggers on casual phrasing",
+        "Identifies as singular alternative format",
+        "Focuses on user's product as THE alternative",
+        "Includes why people switch from Mailchimp",
+        "Highlights e-commerce-specific advantages",
+        "Includes feature and pricing comparison",
+        "Includes migration guide",
+        "Optimizes for singular keyword"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "Can you create a comparison page for 'Notion vs Coda'? We're a third-party review site, not affiliated with either product.",
+      "expected_output": "Should identify this as the 'competitor vs competitor' format (third-party perspective). Should maintain objectivity since the user isn't either product. Should include balanced comparison: overview of both, feature comparison, pricing, pros/cons, use case recommendations. Should use the essential page sections from the skill. Should suggest how to monetize the page (affiliate links, CTA to the user's own product if relevant). Should address SEO for the 'Notion vs Coda' keyword.",
+      "assertions": [
+        "Identifies as 'competitor vs competitor' format",
+        "Maintains objectivity (third-party perspective)",
+        "Includes balanced feature comparison",
+        "Includes pricing comparison",
+        "Includes use case recommendations",
+        "Addresses SEO considerations",
+        "Suggests monetization approach"
+      ],
+      "files": []
+    },
+    {
+      "id": 5,
+      "prompt": "We want to build a whole competitor comparison hub. We have 5 main competitors and want to create alternative pages for each, plus head-to-head comparisons. How should we structure this?",
+      "expected_output": "Should apply the centralized competitor data architecture. Should recommend a hub structure with: individual alternative pages for each competitor (5 singular pages), a 'best alternatives' roundup page, head-to-head comparison pages for key matchups. Should address internal linking strategy between these pages. Should recommend the research process for gathering competitive data. Should address URL structure and site architecture for the hub.",
+      "assertions": [
+        "Applies centralized competitor data architecture",
+        "Recommends hub structure with multiple page types",
+        "Suggests individual and roundup alternative pages",
+        "Addresses internal linking between comparison pages",
+        "Recommends research process for competitive data",
+        "Addresses URL structure"
+      ],
+      "files": []
+    },
+    {
+      "id": 6,
+      "prompt": "I need to create a battle card for our sales team comparing us to Zendesk. It should help reps handle competitive objections during sales calls.",
+      "expected_output": "Should recognize this as internal sales enablement material, not a public comparison page. Should defer to or cross-reference the sales-enablement skill, which handles battle cards, objection handling docs, and internal competitive collateral. May provide some competitive positioning advice but should make clear that sales-enablement is the right skill for internal sales materials.",
+      "assertions": [
+        "Recognizes this as internal sales enablement material",
+        "References or defers to sales-enablement skill",
+        "Does not attempt to create internal battle card using public comparison page patterns"
+      ],
+      "files": []
+    }
+  ]
+}