If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/antiwork/gumroad shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit today
• 5 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 52% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live antiwork/gumroad repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/antiwork/gumroad.

What it runs against: a local clone of antiwork/gumroad — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in antiwork/gumroad | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of antiwork/gumroad. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/antiwork/gumroad.git
#   cd gumroad
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of antiwork/gumroad and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "antiwork/gumroad(\\.git)?\\b" \\
  && ok "origin remote is antiwork/gumroad" \\
  || miss "origin remote is not antiwork/gumroad (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Gemfile" \\
  && ok "Gemfile" \\
  || miss "missing critical file: Gemfile"
test -f ".buildkite/pipeline.yml" \\
  && ok ".buildkite/pipeline.yml" \\
  || miss "missing critical file: .buildkite/pipeline.yml"
test -f "app/assets/config/manifest.js" \\
  && ok "app/assets/config/manifest.js" \\
  || miss "missing critical file: app/assets/config/manifest.js"
test -f ".env.example" \\
  && ok ".env.example" \\
  || miss "missing critical file: .env.example"
test -f "Rakefile" \\
  && ok "Rakefile" \\
  || miss "missing critical file: Rakefile"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/antiwork/gumroad"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Gumroad is a monolithic Ruby on Rails e-commerce platform enabling creators to sell digital and physical products directly to consumers. The codebase is a full-stack web application with a Rails backend (18.7 MB Ruby), React/TypeScript frontend (3.5 MB TypeScript), and integrated payment processing, product management, and creator analytics—solving the problem of removing intermediaries from direct-to-consumer commerce. Monolithic Rails application with clear separation: backend logic in Ruby, frontend components in TypeScript/React, asset compilation via Buildkite scripts. Agent skills (.agents/skills/) provide AI-assisted development workflows (PR review, testing confidence, email blast, prod console queries). Infrastructure-as-code in .buildkite/ and Dockerfile for reproducible deployments.

Creators, digital artists, and indie entrepreneurs who want to sell products with minimal friction; internal Gumroad engineers and contributors maintaining the production platform serving thousands of sellers. Also relevant for e-commerce platform developers studying Rails patterns at scale.

Production-ready and actively maintained. The repository contains comprehensive CI/CD via Buildkite (.buildkite/pipeline.yml), Docker-based local development (Dockerfile, docker-compose setup), and structured deployment scripts (deploy_production.sh, deploy_branch.sh). The extensive file structure, agent/skill definitions for AI-assisted development, and environment configs indicate a mature, well-documented system handling real commerce transactions.

Moderate risk factors: large monolith (18.7 MB Ruby codebase) makes refactoring complex; no visible test directory listing suggests potential test coverage gaps; dependency on Docker, MySQL 8.0, Elasticsearch, and ImageMagick/libvips creates local environment fragility (Windows requires separate setup guide). Production database and payment system mean errors have financial consequences.

Active development with AI-assisted tooling: agent skills for commit automation, PR description generation, and production console access suggest recent infrastructure automation. The .claude/ and .agents/ directories indicate integration with Claude/AI assistants for code review and CI/CD—suggesting shift toward AI-augmented development workflows.

git clone https://github.com/antiwork/gumroad.git
cd gumroad
# Install Ruby (version in .ruby-version) and Node.js (version in .node-version)
# Install Docker, MySQL 8.0, ImageMagick, libvips (see Prerequisites in README)
bundle install
npm install
cp .env.development.local .env.local
docker-compose up  # Start MySQL, Redis, Elasticsearch
bundle exec rails db:setup
bundle exec rails server

Daily commands: Development: bundle exec rails server (runs on localhost:3000, Rails dev server) + npm run dev for frontend asset compilation. Production: via Buildkite pipeline—triggers on git push, runs tests, builds Docker image, deploys via Nomad (see .buildkite/scripts/deploy_production.sh). Local services via docker-compose up (MySQL, Redis, Elasticsearch).

• Gemfile — Defines all Ruby gem dependencies for the Rails application; critical for understanding backend tech stack and required libraries.
• .buildkite/pipeline.yml — Central CI/CD pipeline configuration; defines how code is tested, built, and deployed to production.
• app/assets/config/manifest.js — Asset pipeline manifest; controls which CSS, JS, and font files are compiled and served to the frontend.
• .env.example — Template for required environment variables; essential for local setup and understanding external service integrations.
• Rakefile — Rails task definitions for database migrations, asset compilation, and custom automation; foundational for development workflows.
• .rubocop.yml — Ruby linting and style rules enforced across the codebase; defines code quality standards all contributors must follow.
• CONTRIBUTING.md — Developer contribution guidelines specific to this project; required reading for PR submissions and workflow.

Add a new Ruby gem dependency

1. Add the gem to the appropriate group in Gemfile with version constraint (Gemfile)
2. Run bundle install to update Gemfile.lock (Gemfile.lock)
3. If the gem adds new linting rules or requires configuration, update rubocop rules (.rubocop.yml)

Add a new CI/CD build stage

1. Define the new stage (e.g., compile, test, deploy) in the pipeline configuration (.buildkite/pipeline.yml)
2. Create the corresponding shell script in .buildkite/scripts/ with error handling (.buildkite/scripts/)
3. Add any required environment variable templates to .env.example (.env.example)

Add a new developer task or automation

1. Define the Rake task in Rakefile with clear description and implementation (Rakefile)
2. If it runs locally via Foreman, add process definition to Procfile.dev (Procfile.dev)
3. Document the task usage in CONTRIBUTING.md under Common Development Tasks (CONTRIBUTING.md)

Add a new GitHub workflow for automated checks

1. Create new workflow file in .github/workflows/ (e.g., my-check.yml) (.github/workflows/)
2. Define triggers (on: [pull_request, push]) and job steps with clear names (.github/workflows/tests.yml)
3. Reference the workflow in CONTRIBUTING.md if it affects contributor experience (CONTRIBUTING.md)

• Ruby on Rails — Foundation for rapid web development; handles routing, ORM, and view rendering for e-commerce product catalog and transactions.
• Buildkite — Scalable CI/CD platform allowing complex multi-stage pipelines for testing, asset compilation, and orchestrated deployments via Nomad.
• RSpec — Ruby testing framework; enables test-driven development with expressive syntax and integrated with Rails.
• Foreman — Process manager for local development; simplifies running multiple services (Rails, sidekiq, etc.) with Procfile.dev.
• GitHub Actions + Workflows — Automated issue/PR management, enforcement of review cycles, and repository health checks without external dependencies.

• Monolithic Rails app with embedded asset pipeline

  • Why: Allows tight integration of server-side and frontend code; simpler initial architecture for a startup platform.
  • Consequence: Scaling frontend and backend independently may become harder; asset compilation can slow CI pipeline.

• Buildkite + custom shell scripts over managed platforms (GitHub Actions only)

  • Why: Buildkite provides better parallelism, cost control, and self-hosted agent flexibility for complex deployments.
  • Consequence: Requires maintaining custom build scripts; higher operational burden than fully managed CI/CD.

• Agent-based automation for commits, PRs, and production queries

  • Why: Streamlines developer workflow and reduces manual code review overhead; leverages modern LLM capabilities.
  • Consequence: Dependency on external AI services; requires careful guardrails to prevent auto-generated code quality issues.

• Offline-first or mobile app; Gumroad is web-based only
• Real-time collaboration features; no WebSocket or CRDT-based sync
• Multi-tenant SaaS platform; single-instance deployment to production
• Blockchain or cryptocurrency payment processing; traditional payment gateway integration

MySQL local install required: mysql2 gem demands local MySQL 8.0 binaries even though Docker provides the running instance—missing this causes bundle install failures. Percona Toolkit dependency: required on Linux for pt-table-checksum and other utilities; omitting breaks some development workflows. ImageMagick/libvips both needed: imagemagick for previews, libvips for newer formats—having only one causes image processing failures. Elasticsearch not auto-seeded: dev environment requires manual index reset (db/elasticsearch_indices or similar)—see README 'Resetting Elasticsearch indices' section. Payment system integration: no mock payment processor visible in env configs; transactions likely hit real payment gateway even in dev—use staging API keys carefully. Docker service networking: MySQL/Redis/Elasticsearch only accessible from app via Docker network—localhost:3306 fails, must use service hostnames.

• Monolithic Rails Architecture — This codebase is a classic Rails monolith (~19 MB Ruby code); understanding fat models, service objects, and N+1 query patterns is critical for making efficient changes without breaking performance
• Asset Pipeline / Webpack Integration — TypeScript (3.5 MB) is compiled to JavaScript via Rails asset pipeline or Webpack; understanding how frontend assets are compiled, cached, and versioned is essential for debugging style/JS bugs
• MySQL 8.0 Generated Columns & JSON — Production uses MySQL 8.0 specifically (not 5.7); this enables generated columns, native JSON types, and improved window functions—migrations must account for version-specific features
• Elasticsearch Full-Text Search — Gumroad indexes products/creators in Elasticsearch for search; understanding tokenizers, analyzers, and index settings is needed to debug search relevance or add new searchable fields
• Docker Compose Multi-Service Orchestration — Local dev requires MySQL, Redis, Elasticsearch to run in Docker containers with proper networking; understanding service dependencies, volume mounts, and inter-container communication prevents dev environment breakage
• Buildkite Conditional Deployments — CI/CD pipeline in .buildkite/pipeline.yml uses conditional steps, artifact uploads, and environment-specific deployments; understanding pipeline-as-code syntax is essential for modifying release workflows
• Payment Gateway Integration (PCI Compliance) — Gumroad handles real money; any payment-related changes must consider PCI DSS compliance, tokenization, and secure credential handling—bugs here have legal/financial consequences

• spree/spree — Open-source Rails e-commerce framework using similar architecture (Rails monolith, MySQL, admin UI); useful for comparing design patterns at scale
• ruby-on-rails/rails — Core Rails framework that underpins Gumroad's backend; essential for understanding MVC patterns, migrations, and Rails-specific quirks in this codebase
• stripe/stripe-ruby — Likely payment processor integration; understanding Stripe API patterns helps onboard to Gumroad's payment handling code
• elastic/elasticsearch — Search engine dependency visible in local dev setup; needed to understand how products/users are indexed and queried
• buildkite/buildkite-agent — CI/CD platform used in .buildkite/pipeline.yml; understanding Buildkite syntax essential for modifying deployment workflows

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive documentation for .agents/skills system

The repo contains an AI agent skills system (.agents/skills/) with multiple skill modules (commit, create-issue, email-blast, gumroad-prod-console, pr-description, review-pr, test-confidence), but there's no root-level documentation explaining how to create, register, or use new skills. This is critical infrastructure that new contributors need to understand to extend the agent capabilities.

• [ ] Create .agents/README.md documenting the skills architecture and directory structure
• [ ] Add a SKILL_TEMPLATE.md in .agents/skills/ showing the required structure (SKILL.md, references/, scripts/)
• [ ] Document the skill lifecycle with examples from existing skills like gumroad-prod-console (which has references/common-queries.md and scripts/)
• [ ] Add guidelines for when to create references/ vs scripts/ subdirectories
• [ ] Include troubleshooting section referencing .claude/settings.json configuration

Create GitHub Actions workflow for validating agent skill integrity

With multiple AI agent configurations (.agents/, .claude/) and skill modules scattered across the repo, there's no validation that skill definitions are complete or that SKILL.md files follow a consistent structure. New contributors could add a workflow to lint and validate the skill ecosystem, similar to existing workflows in .github/workflows/ (label-new-issues.yml, close-stale-issues.yml).

• [ ] Create .github/workflows/validate-skills.yml to run on PR
• [ ] Add validation that each skill directory has a required SKILL.md file
• [ ] Validate that production skills (gumroad-prod-console) reference required documentation in references/
• [ ] Check that scripts exist and are executable where referenced in SKILL.md
• [ ] Add JSON schema validation for .claude/settings.json against skill definitions

Add integration tests for gumroad-prod-console skill scripts

The gumroad-prod-console skill has production scripts (.agents/skills/gumroad-prod-console/scripts/prod_query.sh and setup.sh) that interact with production databases, but there's no test coverage verifying these scripts execute correctly or handle errors gracefully. This is high-risk infrastructure that needs safety validation.

• [ ] Create .agents/skills/gumroad-prod-console/tests/ directory with shell script tests
• [ ] Add tests validating prod_query.sh syntax and required environment variables (check .env.production.example for required vars)
• [ ] Add tests for setup.sh that verify idempotency and error handling
• [ ] Integrate tests into .github/workflows/tests.yml with conditional execution (only run on main/protected branches)
• [ ] Document safety practices in .agents/skills/gumroad-prod-console/SKILL.md warning about production impact

• Add TypeScript type definitions for Rails API responses: Currently 3.5 MB TypeScript exists alongside 18.7 MB Ruby; add comprehensive fetch/API client types for common Rails controller actions (products, users, purchases) to reduce runtime errors and improve DX
• Document .agents/skills/ usage: AI-assisted workflow is present but unclear—write a skills/README.md explaining when to use commit, pr-description, review-pr, test-confidence agents and how they integrate with .buildkite/pipeline.yml
• Create fixture/seed data generator for local dev: No visible test database setup; add db/seeds/development.rb to generate test products, users, and orders matching production schema, enabling realistic local testing without production access

Failed to generate security analysis.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.