/plan-feature

/security-audit

docs/decisions/

[!IMPORTANT] This skill does NOT replace the

/security-audit

gate. Security audit is a separate gate item that runs after the GTM review. This skill delegates security concerns to that skill rather than duplicating its work.

• GTM issue number (e.g.,

  #132

  ) — primary input
• Phase identifier (e.g.,

  M1

  ) — alternative input

gh issue view <number> --json title,body,labels,milestone

gh issue list --state open --label "gtm-review" --json number,title,milestone

1. List all issues in the milestone — shipped (closed), in-progress, open:
   bash

   gh issue list --milestone "<milestone-title>" --state all --json number,title,state,labels --limit 100

2. Categorize features:
   • Shipped (closed issues): features that are complete and available
   • In-progress (issues with

     in-progress

     label): features being built in tandem
   • Planned (open issues without

     in-progress

     ): features not yet started
3. Build a capabilities matrix: For each shipped feature, summarize what the product can now do. For each in-progress feature, note what it will add. This matrix is the ground truth for the content audit — every marketing claim will be validated against it.
4. Identify gaps: Features described in the GTM issue's Phase Summary that are NOT yet shipped.

pnpm lint
pnpm format:check
pnpm type-check
pnpm test --coverage
pnpm build

• Lint: pass/fail, number of warnings
• Format: pass/fail, files needing formatting
• Type-check: pass/fail, error count
• Tests: pass/fail, total tests, coverage percentage by package
• Build: pass/fail, bundle sizes from build output

.claude/agents/performance-analyst.md

## Model

• application-performance

  for application profiling and optimization patterns

• performance-testing-review

  for performance testing methodology and coverage analysis

• Bundle size analysis: Total bundle size, largest chunks, opportunities for code splitting
• Lazy loading: Are route-level components lazy loaded? Are heavy libraries deferred?
• Image optimization: Are images served in modern formats (WebP, AVIF)? Are they properly sized?
• Render performance: Are there render-blocking resources? Large initial payloads?
• Core Web Vitals risk assessment (from code patterns):
  • LCP: Large hero images without preloading? Blocking fonts? Slow server response patterns?
  • INP: Heavy JavaScript on the main thread? Missing

    React.memo

    or

    useMemo

    for expensive renders?
  • CLS: Dynamic content insertion without reserved space? Font swap without fallback sizing?

• API endpoint patterns: Are there endpoints that fetch excessive data? Missing pagination?
• N+1 queries: Review Prisma queries for

  .include()

  patterns that could cause N+1
• Database index coverage: Do frequently queried fields have indexes?
• Connection pooling: Is the database connection pool configured?
• Caching: Is there a caching strategy for frequently accessed data?

• accessibility-compliance:wcag-audit-patterns

  for comprehensive WCAG 2.1 AA compliance audit

• accessibility-compliance:screen-reader-testing

  for assistive technology compatibility

• ui-design:accessibility-audit

  for component-level accessibility checks

• Color contrast: Do all text/background combinations meet WCAG AA ratios (4.5:1 normal, 3:1 large)?
• Keyboard navigation: Can all interactive elements be reached and activated via keyboard?
• ARIA attributes: Are ARIA roles, labels, and live regions used correctly?
• Focus management: Is focus trapped in modals? Does focus move logically between steps?
• Semantic HTML: Are headings hierarchical? Are form labels associated? Are landmarks present?
• Touch targets: Are interactive elements at least 44x44px on mobile?
• Responsive design: Does the layout work across common breakpoints?
• Motion/animation: Is

  prefers-reduced-motion

  respected?

.claude/agents/content-reviewer.md

## Model

• seo-technical-optimization

  for meta tags, structured data, schema markup audit

• seo-content-creation

  for content quality and E-E-A-T assessment

1. Read the actual component file to see the exact copy users will see
2. Compare each claim against the capabilities matrix from Step 1
3. Flag any discrepancies: features mentioned but not shipped, inflated descriptions, misleading comparisons

• Landing page vs. in-app copy (onboarding, dashboard, profiles)
• Landing page vs. email templates (invite, welcome)
• Pricing claims vs. actual billing implementation
• "How it works" flow vs. actual user experience

• Meta tags: Are title, description, and keywords accurate for current product state?
• Structured data (JSON-LD): Does it match the actual product (type, price, features)?
• Open Graph tags: Are og:title, og:description, og:image correct?
• Aggregate ratings: Are they real or fabricated?

• Do

  /privacy

  ,

  /terms

  ,

  /contact

  (or equivalent) links resolve to actual pages?
• Are legal pages complete and accurate?

AGENTS.md

• No em dashes (

  —

  or

  —

  )
• No AI-slop vocabulary: delve, tapestry, landscape, leverage, seamless, cutting-edge, groundbreaking, etc.
• No hollow transitions: moreover, furthermore, additionally
• No promotional inflation: stunning, breathtaking, world-class, game-changer
• No rule-of-three defaults
• No superficial -ing closers

• Are testimonials real or placeholder?
• Is scale language appropriate? (e.g., "Join thousands" for an invite-only beta is misleading)
• Are star ratings backed by actual data?

1. Quality Checks (Step 2): pass/fail status, coverage numbers, bundle sizes
2. Performance (Step 3): key findings, risk areas
3. Accessibility (Step 4): WCAG compliance status, issues found
4. Content Accuracy (Step 5): line-item accuracy report, SEO audit results, style violations

code-review-ai:architect-review

Model Selection: See the Model Selection section in README.md for mapping agent model specs to Task tool parameters.

.claude/councils/review-council.md

• Review codebase security posture (this is a high-level review, not the full

  /security-audit

  )
• Validate authentication and authorization patterns
• Check OWASP Top 10 at a surface level
• Flag any critical issues that should block launch
• Vote: Approve / Concern / Block
• Assessment: [Findings and recommendations]

• Assess test coverage against >80% target for phase code
• Identify gaps in critical user paths (auth, onboarding, core features)
• Evaluate test quality (are tests meaningful or just hitting line counts?)
• Vote: Approve / Concern / Block
• Assessment: [Findings and recommendations]

• Is README.md accurate for a fresh developer setup?
• Does

  docs/DEVELOPMENT.md

  match current setup steps?
• Is

  docs/INDEX.md

  up to date with all docs files?
• Are API endpoints documented?
• Vote: Approve / Concern / Block
• Assessment: [Findings and recommendations]

• Domain-specific code quality and patterns consistency
• Architecture adherence (folder structure, module organization)
• Component reuse and DRY principles
• Vote: Approve / Concern / Block
• Assessment: [Findings and recommendations]

• deployment-validation

  for pre-deployment configuration checks

• observability-monitoring

  for monitoring and observability readiness

.claude/agents/platform-engineer.md

• Docker: Does

  docker compose up

  produce a working environment for a fresh clone?
• CI/CD: Are all checks passing on the main branch?
• Environment variables: Is

  .env.example

  complete and accurate? Are all required vars documented?
• Database: Are all Prisma migrations applied cleanly? Is the seed script current?
• Monitoring: Is error tracking or logging in place?
• Health checks: Does the API have a health endpoint that validates dependencies?

.claude/agents/devx-engineer.md

• Is README.md accurate for a fresh developer clone-to-running experience?
• Is

  docs/DEVELOPMENT.md

  current with all prerequisites and setup steps?
• Is

  docs/INDEX.md

  up to date with all documentation files?
• Are all new docs files from this phase indexed?

• business-analytics

  for KPI framework, metrics guidance, and financial analysis patterns

• content-marketing

  for content strategy and competitive research

Model Selection: See the Model Selection section in README.md for mapping agent model specs to Task tool parameters.

.claude/councils/gtm-council.md

• Market positioning accuracy for this phase's capabilities
• Messaging effectiveness and clarity
• Launch tactics: channels, timing, sequencing
• Competitive differentiation given current feature set
• Vote: Approve / Concern / Block
• Rationale: [Explanation]

• Pricing validation: is the price justified by the current feature set?
• Revenue impact: what conversion path exists?
• Competitive positioning: how does pricing compare?
• Risk assessment: what could go wrong at launch?
• Vote: Approve / Concern / Block
• Rationale: [Explanation]

• Final content accuracy verdict based on Step 5 findings
• SEO readiness score
• Style compliance summary
• Are there any claims that could erode user trust?
• Vote: Approve / Concern / Block
• Rationale: [Explanation]

• Brand consistency across all surfaces (marketing, app, emails)
• Visual polish: is the UI production-ready?
• UX coherence: does the product experience match marketing promises?
• Vote: Approve / Concern / Block
• Rationale: [Explanation]

• MVP completeness: are all planned features for this phase shipped?
• Feature flags: are unfinished features properly gated?
• Shipped vs. promised: gap analysis between marketing and reality
• Launch timeline: is the timing realistic?
• Vote: Approve / Concern / Block
• Rationale: [Explanation]

.claude/councils/gtm-council.md

• Approved: All members vote Approve or Concern (no Blocks)
• Needs Changes: One or more Concern votes on blocking items, implement recommendations
• Blocked: One or more Block votes, fundamental issues must be resolved before launch

1. Each member's vote and rationale
2. The consolidated verdict (Approved / Needs Changes / Blocked)
3. Blocking issues list
4. Non-blocking recommendations

.claude/skills/gtm-review/GTM-REPORT-TEMPLATE.md

docs/decisions/

1. Determine the next decision number: Read

   docs/decisions/INDEX.md

   and find the highest existing decision number. Increment by 1, zero-padded to 3 digits.
2. File name:

   docs/decisions/NNN-<phase>-gtm-review.md

   (e.g.,

   021-m1-gtm-review.md

   )
3. Fill in all template sections with real data from Steps 2-8. Replace all placeholder text. Remove sections that are not applicable to this phase, but keep the overall structure intact.
4. Frontmatter: Update the

   description

   field to summarize the phase and verdict:
   yaml

   ---
   type: reference
   description: GTM launch readiness report for M1 -- [Approved/Needs Changes/Blocked]. Covers marketing, code quality, performance, accessibility, infrastructure, and business positioning.
   ---

• Executive Summary — Phase overview and council vote tallies
• Phase Inventory — Capabilities matrix and gap analysis from Step 1
• Blocking / High / Medium / Low Priority Issues — Categorized findings from all steps
• Automated Quality Checks — Results from Step 2
• Performance Readiness — Frontend and backend findings from Step 3
• Accessibility Compliance — WCAG audit results from Step 4
• Content & Marketing Audit — Content accuracy, SEO, style compliance from Step 5
• Code Quality Summary — Review Council votes from Step 6
• Infrastructure Readiness — Platform and docs findings from Step 7
• GTM Council Votes — Each member's vote, rationale, and strategic recommendations from Step 8
• Success Metrics — Validation of GTM issue metrics
• Action Items and Next Steps — Consolidated from all findings

gh issue comment <issue-number> --body "<report>"

[!TIP] Use a HEREDOC for the report body to preserve formatting:

bash

gh issue comment <number> --body "$(cat <<'EOF'
## GTM Review Results
...report content...
EOF
)"

• Check items that pass:

  - [x] Item

• Add notes to items that need work:

  - [ ] Item -- [GTM Review: needs attention because...]

gh issue edit

1. CHECKPOINT: Ask the user whether to close the GTM issue now that the review is complete. Present the issue number and title for confirmation.
2. If approved, close the issue:
   bash

   gh issue close <number> --reason completed

[!IMPORTANT] This skill does NOT replace the

/security-audit

gate item. The security audit is the final gate in every milestone and must be run separately after the GTM review.

• GTM Issue: Link to the updated issue
• Report File: Path to the decision record (e.g.,

  docs/decisions/021-m1-gtm-review.md

  )
• Verdict: The consolidated readiness verdict
• Blocking Issues Count: How many must-fix items remain
• Next Steps:
  • If blocking issues remain: "Fix blocking issues, then re-run

    /gtm-review

    "
  • If ready: "Run

    /security-audit

    to complete the final gate item for this phase"