feat(skills): add P2 lifecycle completion skills

Add 18 new skills completing the full product development lifecycle including sprint planning, backlog grooming, stakeholder updates, analytics setup, A/B testing, feature flagging, and deprecation management.

Author: breadoncee

skills/analyze-competitors/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: analyze-competitors
+description: Build a competitive positioning matrix and strategy canvas when the user asks to analyze competitors, compare products, or assess competitive landscape
+owner: chalk
+version: "1.0.0"
+metadata-version: "1"
+allowed-tools: Read, Glob, Grep, Write
+argument-hint: "[competitor names and/or dimensions to compare]"
+---
+
+# Analyze Competitors
+
+## Overview
+
+Generate a competitive positioning matrix and Blue Ocean Strategy canvas that compares your product against named competitors across key dimensions: features, pricing, target market, UX, strengths, and weaknesses. Surfaces differentiation opportunities and strategic white space.
+
+## Workflow
+
+1. **Read product context** -- Scan `.chalk/docs/product/` for the product profile (`0_product_profile.md`), JTBD docs, and any existing competitive analyses. If no product context exists, ask the user to describe their product before proceeding.
+
+2. **Parse competitors and dimensions** -- Extract from `$ARGUMENTS` the competitor names and any specific dimensions the user wants compared. If no competitors are named, ask the user to list 2-5 direct competitors. If no dimensions are specified, use the defaults: core features, pricing model, target market, UX quality, integration ecosystem, go-to-market approach.
+
+3. **Determine the next file number** -- Read filenames in `.chalk/docs/product/` to find the highest numbered file. The next number is `highest + 1`.
+
+4. **Build the competitive matrix** -- For each competitor, analyze across every dimension. Use a consistent rating or description per cell. Be specific -- "freemium with $29/mo pro tier" not "has free plan."
+
+5. **Create the strategy canvas** -- Describe a Blue Ocean Strategy canvas: list the competing factors on the X-axis and value level (low to high) on the Y-axis. Plot your product and each competitor. Identify factors where you can eliminate, reduce, raise, or create to find uncontested market space.
+
+6. **Identify positioning insights** -- Summarize: where you are differentiated, where you are at parity, where competitors have an advantage, and where white space exists.
+
+7. **Write the file** -- Save to `.chalk/docs/product/<n>_competitive_analysis.md`.
+
+8. **Confirm** -- Share the file path and highlight the top 2-3 differentiation opportunities or competitive risks.
+
+## Output
+
+- **File**: `.chalk/docs/product/<n>_competitive_analysis.md`
+- **Format**: Plain markdown with comparison table, strategy canvas description, and positioning insights
+- **First line**: `# Competitive Analysis: <Your Product> vs. <Competitors>`
+
+## Anti-patterns
+
+- **Feature checklist without context** -- A grid of checkmarks tells you nothing about competitive dynamics. Every cell should describe the *quality* and *approach*, not just presence/absence.
+- **Ignoring indirect competitors** -- Products in adjacent categories that solve the same job often matter more than direct feature competitors.
+- **Stale data presented as current** -- If you do not have current information about a competitor, say so. Do not fabricate pricing or feature details.
+- **Missing "so what"** -- A comparison table without positioning insights is just data. Always conclude with what the analysis means for product strategy.
+- **Only comparing features** -- Pricing, distribution, brand, and go-to-market are often more decisive than feature parity. Compare across all strategic dimensions.

skills/analyze-metrics/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: analyze-metrics
+description: Analyze product metrics and identify trends when the user asks to review metrics, analyze KPIs, or assess product health
+owner: chalk
+version: "1.0.0"
+metadata-version: "1"
+allowed-tools: Read, Glob, Grep, Write
+argument-hint: "[metric name, period, or metrics file]"
+---
+
+# Analyze Metrics
+
+## Overview
+
+Review product metrics against targets, identify trends across cohorts, distinguish leading from lagging indicators, and generate hypotheses for unexpected changes. Turns raw numbers into actionable insight.
+
+## Workflow
+
+1. **Read metrics context** — Scan `.chalk/docs/product/` for any metrics framework, KPI definitions, or previous metrics reviews. Identify which metrics have defined targets and baselines.
+
+2. **Gather metrics data** — Parse `$ARGUMENTS` for the specific metrics or period to analyze. If the user provides data inline or references a file, read it. If no data is provided, ask the user to supply current metric values.
+
+3. **Classify each metric** — For each metric, determine:
+   - Type: leading (predictive) vs. lagging (outcome)
+   - Category: acquisition, activation, engagement, retention, revenue, referral
+   - Comparison basis: target value, previous period, cohort benchmark
+
+4. **Assess current vs. target** — Compare each metric's current value against its target. Classify as: on-track (within 10%), at-risk (10-25% off), or off-track (>25% off). If no target exists, note the gap.
+
+5. **Identify trends** — For each metric with historical data, classify the trend: improving, stable, or declining. Note acceleration or deceleration (is improvement slowing down?). Flag inflection points.
+
+6. **Cohort comparison** — Where cohort data is available, compare across user segments (new vs. returning, plan tiers, acquisition channels). Identify cohorts that outperform or underperform the average.
+
+7. **Generate hypotheses** — For any metric that is off-track or shows unexpected changes, propose 2-3 hypotheses for the cause. Each hypothesis should be testable. Connect to recent product changes, market events, or seasonal patterns.
+
+8. **Identify metric relationships** — Flag leading indicators that predict lagging indicator changes. Note correlations and potential causal chains.
+
+9. **Determine the next file number** — Read filenames in `.chalk/docs/product/` to find the highest numbered file. Use `highest + 1`.
+
+10. **Write the review** — Save to `.chalk/docs/product/<n>_metrics_review_<period>.md`.
+
+## Output
+
+- **File**: `.chalk/docs/product/<n>_metrics_review_<period>.md`
+- **Format**: Markdown with a health dashboard table and detailed metric sections
+- **Key sections**: Health Summary Table (metric / current / target / status / trend), Detailed Analysis per metric, Cohort Insights, Hypotheses for Off-Track Metrics, Recommended Actions
+
+## Anti-patterns
+
+- **Vanity metrics without context** — Reporting "10K signups" without conversion rate, activation rate, or retention is misleading. Always pair volume metrics with quality metrics.
+- **Confusing correlation with causation** — "We launched feature X and signups went up" is a correlation, not a causal claim. Always note confounders and suggest experiments to validate.
+- **Ignoring leading indicators** — Only reviewing lagging indicators (revenue, churn) means you are looking in the rearview mirror. Prioritize leading indicators that let you act before outcomes materialize.
+- **Reporting without hypotheses** — Stating "retention dropped 5%" without proposing why is not analysis. Every unexpected change needs at least one testable hypothesis.
+- **Missing cohort breakdowns** — Aggregate metrics hide important variation. A stable overall retention rate can mask declining retention in new cohorts offset by strong retention in old cohorts.

skills/audit-accessibility/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: audit-accessibility
+description: Audit a feature for WCAG 2.1 AA compliance using POUR principles when the user asks to check accessibility, audit a11y, or verify WCAG compliance
+owner: chalk
+version: "1.0.0"
+metadata-version: "1"
+allowed-tools: Read, Glob, Grep, Write
+argument-hint: "[feature or component to audit for accessibility]"
+---
+
+# Audit Accessibility
+
+## Overview
+
+Generate a WCAG 2.1 AA compliance audit for a specific feature or component, organized by the POUR principles (Perceivable, Operable, Understandable, Robust). Produces a concrete checklist with testing instructions, keyboard navigation paths, screen reader expectations, and color contrast requirements.
+
+## Workflow
+
+1. **Read feature context** -- Scan `.chalk/docs/product/` for the PRD describing the feature. Check `.chalk/docs/engineering/` for component architecture and any existing a11y guidelines. Read the source code for the feature's UI components to understand the actual implementation.
+
+2. **Parse the audit target** -- Extract from `$ARGUMENTS` the feature, page, or component to audit. If unspecified, ask the user to name a specific feature -- auditing the entire application at once produces shallow results.
+
+3. **Determine the next file number** -- Read filenames in `.chalk/docs/engineering/` to find the highest numbered file. The next number is `highest + 1`.
+
+4. **Audit Perceivable** -- Check:
+   - All images have meaningful alt text (decorative images use `alt=""`)
+   - Color is not the only means of conveying information
+   - Text meets contrast ratios (4.5:1 for normal text, 3:1 for large text)
+   - Content is readable at 200% zoom
+   - Media has captions or transcripts
+
+5. **Audit Operable** -- Check:
+   - All interactive elements are reachable via keyboard (Tab, Shift+Tab, Enter, Space, Escape, Arrow keys)
+   - Document the expected keyboard navigation path through the feature
+   - Focus order matches visual order
+   - No keyboard traps
+   - Focus indicators are visible
+   - Touch targets are at least 44x44 CSS pixels
+
+6. **Audit Understandable** -- Check:
+   - Form inputs have visible labels (not just placeholders)
+   - Error messages identify the field and describe how to fix the error
+   - Consistent navigation and naming patterns
+   - Language is set on the page element
+
+7. **Audit Robust** -- Check:
+   - Semantic HTML elements used appropriately (buttons, links, headings, landmarks)
+   - ARIA roles, states, and properties are correct and necessary
+   - Components work with major screen readers (VoiceOver, NVDA, JAWS)
+   - No ARIA is better than bad ARIA
+
+8. **Write the file** -- Save to `.chalk/docs/engineering/<n>_a11y_audit_<feature-slug>.md`.
+
+9. **Confirm** -- Share the file path and highlight the highest-severity issues that block users from completing tasks.
+
+## Output
+
+- **File**: `.chalk/docs/engineering/<n>_a11y_audit_<feature-slug>.md`
+- **Format**: Plain markdown with POUR-organized checklist, each item marked pass/fail/needs-review with specific testing instructions
+- **First line**: `# Accessibility Audit: <Feature Name>`
+
+## Anti-patterns
+
+- **Checklist without testing instructions** -- "Check color contrast" is not actionable. Specify which elements, what the current ratio is, and what the target ratio should be.
+- **ARIA overuse** -- Adding `role="button"` to a `<button>` is redundant. Adding ARIA to fix semantic HTML problems is treating symptoms. Prefer native HTML elements.
+- **Keyboard testing only with Tab** -- Many components require Arrow keys (tabs, menus, radio groups), Escape (modals, dropdowns), Space (checkboxes), and Enter (buttons, links). Document the full expected keyboard interaction model.
+- **Ignoring screen reader output** -- An element can be technically accessible but produce nonsensical screen reader output. Specify what the screen reader should announce for each interactive element.
+- **Treating a11y as a one-time audit** -- Note which checks should be automated in CI and which require manual testing on each release.

skills/audit-performance/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: audit-performance
+description: Audit performance against Core Web Vitals and performance budgets when the user asks to check performance, audit speed, or analyze web vitals
+owner: chalk
+version: "1.0.0"
+metadata-version: "1"
+allowed-tools: Read, Glob, Grep, Write
+argument-hint: "[page, feature, or endpoint to audit for performance]"
+---
+
+# Audit Performance
+
+## Overview
+
+Generate a performance budget audit against Core Web Vitals (LCP, INP, CLS), bundle size, and API latency. Defines thresholds, identifies violations, and provides actionable recommendations for image optimization, code splitting, lazy loading, and caching improvements.
+
+## Workflow
+
+1. **Read engineering context** -- Scan `.chalk/docs/engineering/` for architecture docs, existing performance budgets, and infrastructure configuration. Check the codebase for build configuration (webpack, vite, next.config) and existing performance tooling.
+
+2. **Parse the audit target** -- Extract from `$ARGUMENTS` the page, feature, or endpoint to audit. If unspecified, audit the most critical user-facing page (typically the landing page or main dashboard).
+
+3. **Determine the next file number** -- Read filenames in `.chalk/docs/engineering/` to find the highest numbered file. The next number is `highest + 1`.
+
+4. **Define performance budgets** -- Set thresholds (use existing budgets from docs if available, otherwise use industry standards):
+
+   | Metric | Good | Needs Improvement | Poor |
+   |--------|------|-------------------|------|
+   | LCP | < 2.5s | 2.5-4.0s | > 4.0s |
+   | INP | < 200ms | 200-500ms | > 500ms |
+   | CLS | < 0.1 | 0.1-0.25 | > 0.25 |
+   | Bundle size (JS) | < 200KB gzipped | 200-350KB | > 350KB |
+   | API latency (p95) | < 300ms | 300-1000ms | > 1000ms |
+
+5. **Analyze the codebase for performance issues** -- Review:
+   - Bundle: large dependencies, tree-shaking gaps, missing code splitting
+   - Images: unoptimized formats, missing lazy loading, no responsive sizes
+   - Rendering: layout shifts from dynamic content, render-blocking resources
+   - Data fetching: waterfall requests, missing caching, over-fetching
+   - API: slow queries, missing indexes, N+1 problems
+
+6. **Report violations** -- For each budget exceeded or at risk, document: current value (if measurable from code analysis), threshold, root cause, and recommended fix.
+
+7. **Prioritize recommendations** -- Rank fixes by impact (how much improvement) and effort (how hard to implement). Quick wins first.
+
+8. **Write the file** -- Save to `.chalk/docs/engineering/<n>_performance_audit.md`.
+
+9. **Confirm** -- Share the file path and highlight the top 3 highest-impact fixes.
+
+## Output
+
+- **File**: `.chalk/docs/engineering/<n>_performance_audit.md`
+- **Format**: Plain markdown with budget table, violations list, and prioritized recommendations
+- **First line**: `# Performance Audit: <Target>`
+
+## Anti-patterns
+
+- **Auditing without budgets** -- "The page is slow" is not actionable. Define thresholds first, then measure against them. Without budgets, there is no pass/fail.
+- **Only measuring lab data** -- Lab metrics (Lighthouse) and field metrics (CrUX) can differ significantly. Note which measurements are lab-based and recommend field monitoring.
+- **Recommendations without priority** -- A list of 20 optimizations without ranking overwhelms teams. Prioritize by impact-to-effort ratio and present quick wins first.
+- **Ignoring bundle composition** -- "Bundle is too large" without identifying which dependencies contribute most is not helpful. Break down the bundle and identify the largest contributors.
+- **Missing API latency** -- Frontend performance audits that ignore API response times miss half the picture. Include backend latency in the audit scope.

skills/create-decision-log/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: create-decision-log
+description: Record a product or engineering decision with full context when the user asks to log a decision, record a choice, or document why something was decided
+owner: chalk
+version: "1.0.0"
+metadata-version: "1"
+allowed-tools: Read, Glob, Grep, Write
+argument-hint: "[decision topic or question]"
+---
+
+# Create Decision Log
+
+## Overview
+
+Create a structured decision journal entry that separates decision quality from outcome quality, inspired by Annie Duke's "Thinking in Bets." Captures the context, options, rationale, and expected outcomes at the time of decision, enabling future review and learning.
+
+## Workflow
+
+1. **Read existing context** — Scan `.chalk/docs/product/` and `.chalk/docs/engineering/` for related decisions, PRDs, ADRs, or other docs that provide context for this decision. Check for previous decision logs that address similar topics.
+
+2. **Capture the decision** — Parse `$ARGUMENTS` to identify the decision topic. If the topic is vague, ask the user to clarify the specific choice being made. Every decision log answers: "What did we decide, and why?"
+
+3. **Document the context** — Record the circumstances at the time of decision: what information was available, what constraints existed, what pressures were present (time, resources, competitive), and what the stakes were. This section is critical for future retrospection.
+
+4. **Enumerate options considered** — List all options that were seriously evaluated, including the option of doing nothing. For each option, note the key pros, cons, and the estimated probability of success or risk.
+
+5. **Record the decision and rationale** — State the chosen option and the reasoning. Distinguish between: (a) evidence-based reasons (data, research), (b) principled reasons (values, strategy alignment), and (c) pragmatic reasons (time pressure, resource constraints). Be honest about which type dominates.
+
+6. **Define expected outcomes** — What does the decision-maker expect to happen? Include both the hoped-for outcome and the realistic range. State the confidence level (high / medium / low) and the timeframe for evaluation.
+
+7. **Set revisit triggers** — Define conditions that should trigger a re-evaluation of this decision: specific metrics thresholds, dates, or events. This prevents both premature reversal and zombie decisions that persist past their relevance.
+
+8. **Determine the next file number** — Read filenames in `.chalk/docs/product/` to find the highest numbered file. Use `highest + 1`.
+
+9. **Write the decision log** — Save to `.chalk/docs/product/<n>_decision_<topic>.md`.
+
+## Output
+
+- **File**: `.chalk/docs/product/<n>_decision_<topic>.md`
+- **Format**: Markdown with structured sections
+- **Key sections**: Date, Decision Statement, Context, Options Considered (with pros/cons), Decision, Rationale (evidence / principled / pragmatic), Expected Outcome (with confidence and timeframe), Actual Outcome (blank — filled later), Revisit Triggers
+
+## Anti-patterns
+
+- **Outcome bias** — Judging a decision by its outcome rather than the quality of reasoning at the time. A good decision can have a bad outcome and vice versa. This log captures decision quality independently.
+- **Hindsight editing** — Rewriting the context or rationale after the outcome is known. The context section must reflect what was known at decision time, not what was learned later.
+- **Missing the "do nothing" option** — Every decision should include the status quo as an explicit option with its own pros and cons. Sometimes the best decision is to not decide yet.
+- **Vague rationale** — "It felt right" is not a rationale. Even intuition-based decisions should articulate the underlying pattern recognition or experience driving the intuition.
+- **No revisit triggers** — A decision without revisit conditions becomes permanent by inertia. Every decision log must define when and under what conditions the decision should be reconsidered.
+- **Logging only big decisions** — Small, frequent decisions compound. Log decisions that are reversible but consequential, not just the "big bets."