Copy disabled (too large)
Download .txt
Showing preview only (105,162K chars total). Download the full file to get everything.
Repository: skillrecordings/egghead-next
Branch: main
Commit: db753fba588e
Files: 1234
Total size: 250.6 MB
Directory structure:
gitextract_61kki5cn/
├── .cursor/
│ ├── GUIDE.md
│ ├── PERSONALIZATION.md
│ ├── rules/
│ │ ├── _/
│ │ │ └── .gitignore
│ │ ├── _context/
│ │ │ └── .gitkeep
│ │ ├── _core/
│ │ │ ├── communication.mdc
│ │ │ ├── persona.mdc
│ │ │ ├── prefer-clis.mdc
│ │ │ ├── principles.mdc
│ │ │ ├── standards.mdc
│ │ │ └── terminal.mdc
│ │ ├── _global.mdc
│ │ ├── _globs/
│ │ │ ├── GLOBS.md
│ │ │ └── react/
│ │ │ └── best-practices.mdc
│ │ ├── benchmarks-create.mdc
│ │ ├── cli-github-search.mdc
│ │ ├── cli-pack.mdc
│ │ ├── cli-worktree.mdc
│ │ ├── cli-wrangler.mdc
│ │ ├── docs-diagram.mdc
│ │ ├── docs-openapi-spec.mdc
│ │ ├── docs-prd.mdc
│ │ ├── docs-structure.mdc
│ │ ├── docs-sync.mdc
│ │ ├── docs-tech-stack.mdc
│ │ ├── gh-docs-sync.mdc
│ │ ├── gh-task-continue.mdc
│ │ ├── gh-task-execute.mdc
│ │ ├── gh-task-plan.mdc
│ │ ├── logging-session.mdc
│ │ ├── pnpm-fixes.mdc
│ │ ├── project-todos-next.mdc
│ │ ├── project-update-rules.mdc
│ │ ├── project-update-user-rules.mdc
│ │ ├── prompt-improve.mdc
│ │ ├── pull-request-create.mdc
│ │ ├── react-rules.mdc
│ │ ├── scripts-create.mdc
│ │ ├── task-continue.mdc
│ │ ├── task-execute.mdc
│ │ ├── task-next.mdc
│ │ ├── task-outline.mdc
│ │ ├── task-plan.mdc
│ │ └── zen-coding.mdc
│ └── workflows/
│ ├── development/
│ │ ├── benchmarks.md
│ │ ├── logging.md
│ │ └── scripts.md
│ ├── documentation/
│ │ ├── diagram.md
│ │ ├── openapi-spec.md
│ │ ├── prd.md
│ │ ├── sync.md
│ │ └── tech-stack.md
│ ├── task/
│ │ └── parallel.md
│ ├── tools/
│ │ ├── cli/
│ │ │ ├── ghx.md
│ │ │ ├── repomix.md
│ │ │ ├── worktree.md
│ │ │ └── wrangler.md
│ │ └── package-managers/
│ │ └── pnpm/
│ │ └── build-script-fixes.md
│ └── workflows/
│ ├── analysis/
│ │ └── document-failures.md
│ ├── config/
│ │ ├── personalize-rule.md
│ │ └── update-personal-rules.md
│ ├── dependencies/
│ │ └── audit.md
│ ├── docs/
│ │ ├── structure.md
│ │ └── sync.md
│ ├── github/
│ │ ├── continue-github.md
│ │ ├── execute-github.md
│ │ ├── plan-github.md
│ │ ├── pr-create-github.md
│ │ └── review-github.md
│ ├── meta/
│ │ └── create-workflow.md
│ ├── project/
│ │ └── update-project-rules.md
│ ├── prompts/
│ │ └── improve-prompt.md
│ ├── scripts/
│ │ └── create-script.md
│ └── task/
│ ├── continue.md
│ ├── execute.md
│ ├── next.md
│ ├── outline.md
│ ├── plan.md
│ └── todos-next.md
├── .eslintrc.js
├── .github/
│ └── workflows/
│ └── jest.yml
├── .gitignore
├── .hive/
│ ├── issues.jsonl
│ └── memories.jsonl
├── .husky/
│ └── pre-commit
├── .kodiak.toml
├── .node-version
├── .nvmrc
├── .storybook/
│ ├── main.js
│ └── preview.js
├── @types/
│ ├── assets/
│ │ └── index.d.ts
│ ├── browser-cookies.d.ts
│ ├── cueplayer-react.d.ts
│ ├── file-extension.d.ts
│ ├── friendly-time.d.ts
│ ├── humanize-list.d.ts
│ ├── mdx.d.ts
│ ├── react-textfit.d.ts
│ ├── remove-markdown.d.ts
│ └── tincanjs.d.ts
├── CLAUDE.md
├── LICENSE
├── README.md
├── ai/
│ └── diagrams/
│ ├── README.md
│ ├── analytics-tracking-flow.md
│ ├── auth-login-flow.md
│ ├── course-progression-flow.md
│ ├── email-automation-flow.md
│ ├── form-submission-flow.md
│ ├── free-user-pro-content-overlay-flow.md
│ ├── inngest-background-jobs-flow.md
│ ├── lesson-playback-flow.md
│ ├── search-functionality-flow.md
│ ├── stripe-payment-flow.md
│ ├── subscription-access-control-flow.md
│ ├── tip-creation-flow.md
│ ├── trpc-api-flow.md
│ ├── user-navigation-flow.md
│ ├── video-upload-processing-flow.md
│ ├── webhook-processing-flow.md
│ ├── workshop-registration-flow.md
│ └── xstate-machine-flow.md
├── bin/
│ └── validate
├── config/
│ └── jest/
│ └── cssTransform.js
├── cypress/
│ ├── fixtures/
│ │ └── example.json
│ ├── integration/
│ │ └── spec.js
│ ├── plugins/
│ │ └── index.js
│ └── support/
│ ├── commands.js
│ └── index.js
├── cypress.json
├── docs/
│ ├── decisions/
│ │ ├── 0001-adopt-architecture-decision-records.md
│ │ ├── 0002-upgrade-next-mdx-remote-to-v6.md
│ │ ├── 0003-direct-pg-course-shell.md
│ │ └── README.md
│ ├── latest-courses-component-plan.md
│ ├── post-page-refactoring-plan.md
│ ├── stripe-upgrade-analysis.md
│ ├── stripe-upgrade-plan.md
│ ├── tasks/
│ │ ├── 2025-06-02-11-40-ai-dev-essentials-landing-page.md
│ │ ├── 2025-08-13-copy-as-prompt-feature.md
│ │ └── 2025-08-18-14-35-stripe-sdk-upgrade.md
│ └── typesense-new-lessons-feature.md
├── jest/
│ └── json-reporter.js
├── jest.config.js
├── next-env.d.ts
├── next-sitemap.js
├── next.config.mjs
├── package.json
├── postcss.config.js
├── prisma/
│ └── schema.prisma
├── public/
│ ├── bitmovin/
│ │ ├── bitmovinplayer-ui.css
│ │ ├── bitmovinplayer-ui.js
│ │ └── receiver.css
│ ├── opensearch.xml
│ ├── robots.txt
│ ├── site.webmanifest
│ ├── sitemap.xml
│ ├── tags-sitemap-0.xml
│ ├── tags-sitemap-1.xml
│ ├── tags-sitemap-10.xml
│ ├── tags-sitemap-11.xml
│ ├── tags-sitemap-12.xml
│ ├── tags-sitemap-13.xml
│ ├── tags-sitemap-14.xml
│ ├── tags-sitemap-15.xml
│ ├── tags-sitemap-16.xml
│ ├── tags-sitemap-17.xml
│ ├── tags-sitemap-18.xml
│ ├── tags-sitemap-19.xml
│ ├── tags-sitemap-2.xml
│ ├── tags-sitemap-20.xml
│ ├── tags-sitemap-21.xml
│ ├── tags-sitemap-22.xml
│ ├── tags-sitemap-23.xml
│ ├── tags-sitemap-24.xml
│ ├── tags-sitemap-25.xml
│ ├── tags-sitemap-26.xml
│ ├── tags-sitemap-27.xml
│ ├── tags-sitemap-28.xml
│ ├── tags-sitemap-29.xml
│ ├── tags-sitemap-3.xml
│ ├── tags-sitemap-4.xml
│ ├── tags-sitemap-5.xml
│ ├── tags-sitemap-6.xml
│ ├── tags-sitemap-7.xml
│ ├── tags-sitemap-8.xml
│ └── tags-sitemap-9.xml
├── rtl.setup.js
├── setupTests.ts
├── src/
│ ├── adapters/
│ │ └── stripe-adapter.ts
│ ├── api/
│ │ ├── egghead/
│ │ │ └── users/
│ │ │ └── from-token.ts
│ │ └── stripe/
│ │ ├── stripe-checkout-redirect.ts
│ │ └── stripe-lifetime-checkout-redirect.ts
│ ├── app/
│ │ ├── (content)/
│ │ │ ├── courses/
│ │ │ │ ├── [course]/
│ │ │ │ │ └── [lesson]/
│ │ │ │ │ ├── Player.tsx
│ │ │ │ │ ├── PlayerSidebar.tsx
│ │ │ │ │ └── page.tsx
│ │ │ │ └── layout.tsx
│ │ │ ├── lessons/
│ │ │ │ └── [slug]/
│ │ │ │ └── embed/
│ │ │ │ ├── _components/
│ │ │ │ │ ├── embed-lesson.css
│ │ │ │ │ ├── embed-lesson.tsx
│ │ │ │ │ ├── embed-player.tsx
│ │ │ │ │ └── minimal-embed-player.tsx
│ │ │ │ ├── layout.tsx
│ │ │ │ └── page.tsx
│ │ │ └── tips/
│ │ │ ├── [tipId]/
│ │ │ │ ├── edit/
│ │ │ │ │ ├── page.tsx
│ │ │ │ │ └── tip-navigation.tsx
│ │ │ │ └── page.tsx
│ │ │ ├── _components/
│ │ │ │ └── tips-lists.tsx
│ │ │ ├── layout.tsx
│ │ │ ├── new/
│ │ │ │ └── page.tsx
│ │ │ └── page.tsx
│ │ ├── _components/
│ │ │ ├── compact-feed-skeleton.tsx
│ │ │ ├── compact-feed.tsx
│ │ │ ├── compact-hits.tsx
│ │ │ ├── course-info.tsx
│ │ │ └── search.tsx
│ │ ├── _trpc/
│ │ │ ├── Provider.tsx
│ │ │ ├── client.ts
│ │ │ └── serverClient.ts
│ │ ├── api/
│ │ │ ├── cron/
│ │ │ │ └── route.ts
│ │ │ ├── deepgram/
│ │ │ │ └── webhook/
│ │ │ │ └── route.ts
│ │ │ ├── feedback/
│ │ │ │ └── route.ts
│ │ │ ├── inngest/
│ │ │ │ └── route.ts
│ │ │ ├── lessons/
│ │ │ │ └── [slug]/
│ │ │ │ └── download/
│ │ │ │ └── route.ts
│ │ │ ├── mux/
│ │ │ │ └── webhook/
│ │ │ │ └── route.ts
│ │ │ ├── pricing/
│ │ │ │ └── route.ts
│ │ │ ├── stripe/
│ │ │ │ └── checkout/
│ │ │ │ └── lifetime/
│ │ │ │ └── route.ts
│ │ │ ├── trpc/
│ │ │ │ └── [trpc]/
│ │ │ │ └── route.ts
│ │ │ ├── videos/
│ │ │ │ └── [videoResourceId]/
│ │ │ │ └── srt/
│ │ │ │ └── route.ts
│ │ │ ├── webhooks/
│ │ │ │ ├── sanity/
│ │ │ │ │ └── route.ts
│ │ │ │ ├── tips/
│ │ │ │ │ └── mux/
│ │ │ │ │ └── route.ts
│ │ │ │ └── transloadit/
│ │ │ │ └── route.ts
│ │ │ └── workshop-quote/
│ │ │ └── route.ts
│ │ ├── blocked/
│ │ │ ├── _components/
│ │ │ │ └── blocked.tsx
│ │ │ ├── layout.tsx
│ │ │ └── page.tsx
│ │ ├── layout.tsx
│ │ ├── page.tsx
│ │ ├── providers.tsx
│ │ └── user/
│ │ ├── activity/
│ │ │ └── page.tsx
│ │ ├── bookmarks/
│ │ │ └── page.tsx
│ │ ├── layout.tsx
│ │ ├── membership/
│ │ │ ├── layout.tsx
│ │ │ └── page.tsx
│ │ ├── profile/
│ │ │ └── page.tsx
│ │ └── team/
│ │ └── page.tsx
│ ├── components/
│ │ ├── EggheadPlayer/
│ │ │ ├── index.js
│ │ │ ├── players/
│ │ │ │ ├── Base.js
│ │ │ │ ├── Bitmovin.js
│ │ │ │ └── YouTube.js
│ │ │ ├── props.js
│ │ │ ├── use-egghead-player.ts
│ │ │ └── utils.js
│ │ ├── GridBackground.tsx
│ │ ├── app/
│ │ │ ├── app-footer.tsx
│ │ │ ├── app-main.tsx
│ │ │ ├── footer.tsx
│ │ │ ├── header/
│ │ │ │ ├── banner-context.tsx
│ │ │ │ ├── banner-data.ts
│ │ │ │ ├── header-button-shaped-link.tsx
│ │ │ │ ├── images.tsx
│ │ │ │ ├── index.tsx
│ │ │ │ ├── search-bar.tsx
│ │ │ │ └── server-header-shell.tsx
│ │ │ ├── layout.tsx
│ │ │ ├── main.tsx
│ │ │ └── team/
│ │ │ └── index.tsx
│ │ ├── blog/
│ │ │ ├── article-course-card.tsx
│ │ │ └── article-talk-card.tsx
│ │ ├── buttons/
│ │ │ └── index.tsx
│ │ ├── card/
│ │ │ ├── card.stories.mdx
│ │ │ ├── heading.tsx
│ │ │ ├── horizontal-resource-card.tsx
│ │ │ ├── index.tsx
│ │ │ ├── new-horizontal-resource-card.tsx
│ │ │ ├── new-vertical-resource-card.tsx
│ │ │ ├── overlay/
│ │ │ │ ├── overlay-horiztonal-resource-card.tsx
│ │ │ │ └── overlay-vertical-resource-card.tsx
│ │ │ ├── search-hit-resource-card.tsx
│ │ │ ├── topic-page-horizontal-resource-card.tsx
│ │ │ ├── vertical-resource-collection-card.tsx
│ │ │ └── verticle-resource-card.tsx
│ │ ├── code-block.tsx
│ │ ├── community-resource.tsx
│ │ ├── contributors.tsx
│ │ ├── copy-as-prompt-button.tsx
│ │ ├── copy-resource.tsx
│ │ ├── course/
│ │ │ └── course-podcast.tsx
│ │ ├── courses/
│ │ │ ├── course-card.tsx
│ │ │ ├── latest-courses-feed.tsx
│ │ │ └── new-lessons-badge.tsx
│ │ ├── cta/
│ │ │ ├── email/
│ │ │ │ └── email-form.tsx
│ │ │ └── sale/
│ │ │ ├── countdown-timer.tsx
│ │ │ ├── header-banner.tsx
│ │ │ ├── lifetime-header-banner.tsx
│ │ │ ├── workshop-early-bird-header-banner.tsx
│ │ │ └── workshop-header-banner.tsx
│ │ ├── customer-io/
│ │ │ └── email-entry-form.tsx
│ │ ├── dialog.tsx
│ │ ├── external-tracked-link.tsx
│ │ ├── feedback-input/
│ │ │ ├── images/
│ │ │ │ ├── Confounded.js
│ │ │ │ ├── Ghost.js
│ │ │ │ ├── Hearteyes.js
│ │ │ │ ├── NeutralFace.js
│ │ │ │ ├── Smile.js
│ │ │ │ └── Sob.js
│ │ │ └── index.tsx
│ │ ├── five-stars.tsx
│ │ ├── forms/
│ │ │ ├── generic-newsletter-signup.tsx
│ │ │ ├── newsletter-signup.tsx
│ │ │ └── quiz/
│ │ │ ├── completed-message.tsx
│ │ │ ├── essay-question.tsx
│ │ │ ├── multiple-choice-question.tsx
│ │ │ ├── spinner.tsx
│ │ │ └── submit.tsx
│ │ ├── generic-error-boundary.tsx
│ │ ├── grid/
│ │ │ └── index.tsx
│ │ ├── guides/
│ │ │ └── guide-template.tsx
│ │ ├── icons/
│ │ │ ├── bookmark.tsx
│ │ │ ├── cancel.tsx
│ │ │ ├── check.tsx
│ │ │ ├── clock.tsx
│ │ │ ├── closed-captioning.tsx
│ │ │ ├── community-resource-icon.tsx
│ │ │ ├── eggo.tsx
│ │ │ ├── folder-download.tsx
│ │ │ ├── icon-x.tsx
│ │ │ ├── lock.tsx
│ │ │ ├── rss.tsx
│ │ │ ├── star.jsx
│ │ │ ├── svg-icon.jsx
│ │ │ └── tip-icons.tsx
│ │ ├── image-with-placeholder.tsx
│ │ ├── invoices/
│ │ │ └── index.tsx
│ │ ├── last-resource.tsx
│ │ ├── layouts/
│ │ │ ├── collection-page-layout.tsx
│ │ │ ├── multi-module-collection-page-layout.tsx
│ │ │ ├── php-collection-page-layout.tsx
│ │ │ ├── scrimba-course-layout.tsx
│ │ │ └── tag-list.tsx
│ │ ├── like-button.tsx
│ │ ├── link.tsx
│ │ ├── login-required.tsx
│ │ ├── markdown/
│ │ │ ├── mdx-components.tsx
│ │ │ ├── mdx.tsx
│ │ │ ├── serialize-mdx.ts
│ │ │ ├── shiki-remote-plugin.ts
│ │ │ └── transcript-components.tsx
│ │ ├── markdown.tsx
│ │ ├── mdx/
│ │ │ ├── article-series-list.tsx
│ │ │ ├── callout.tsx
│ │ │ ├── card.js
│ │ │ ├── cheat-sheet.js
│ │ │ ├── code-block.tsx
│ │ │ ├── course-widget.tsx
│ │ │ ├── course.tsx
│ │ │ ├── email-subscribe-widget.tsx
│ │ │ ├── header-card.js
│ │ │ ├── index.tsx
│ │ │ ├── prose-section.js
│ │ │ ├── question-reveal.js
│ │ │ ├── resource-link.js
│ │ │ ├── resource-widget.tsx
│ │ │ └── topic-interest-form.tsx
│ │ ├── monitoring/
│ │ │ ├── ai-dev-essentials-error-boundary.tsx
│ │ │ └── performance-monitor.tsx
│ │ ├── pages/
│ │ │ ├── 20-days-of-egghead/
│ │ │ │ └── course-grid.tsx
│ │ │ ├── confirm/
│ │ │ │ └── membership/
│ │ │ │ ├── index.tsx
│ │ │ │ └── membership.stories.mdx
│ │ │ ├── courses/
│ │ │ │ ├── dialog-button.tsx
│ │ │ │ ├── instructor-profile.tsx
│ │ │ │ ├── learner-ratings.tsx
│ │ │ │ ├── membership-dialog-button.tsx
│ │ │ │ ├── play-icon.tsx
│ │ │ │ └── user-rating/
│ │ │ │ └── user-rating.tsx
│ │ │ ├── email-confirmation.tsx
│ │ │ ├── home/
│ │ │ │ ├── cta.tsx
│ │ │ │ ├── egghead-for-teams-cta.tsx
│ │ │ │ ├── first-hit-card.tsx
│ │ │ │ ├── hits.tsx
│ │ │ │ ├── in-progress-section/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── jumbotron.tsx
│ │ │ │ ├── search.tsx
│ │ │ │ ├── the-feed.tsx
│ │ │ │ ├── topics.tsx
│ │ │ │ └── video-card/
│ │ │ │ └── index.tsx
│ │ │ ├── invoice/
│ │ │ │ ├── index.tsx
│ │ │ │ ├── invoice.stories.mdx
│ │ │ │ └── mock-transaction.ts
│ │ │ ├── landing/
│ │ │ │ ├── article/
│ │ │ │ │ └── index.mdx
│ │ │ │ ├── browse/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── create-account/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── footer/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── header/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── join/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── membership-benefits/
│ │ │ │ │ └── index.tsx
│ │ │ │ └── tech-logos/
│ │ │ │ └── index.tsx
│ │ │ ├── lessons/
│ │ │ │ ├── code-link.tsx
│ │ │ │ ├── collection-lessons-list.test.ts
│ │ │ │ ├── collection-lessons-list.tsx
│ │ │ │ ├── comments/
│ │ │ │ │ ├── comment/
│ │ │ │ │ │ ├── comment.stories.mdx
│ │ │ │ │ │ └── index.tsx
│ │ │ │ │ ├── comment-field/
│ │ │ │ │ │ ├── comment-field.stories.mdx
│ │ │ │ │ │ └── index.tsx
│ │ │ │ │ └── comments/
│ │ │ │ │ ├── comments.stories.mdx
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── course.tsx
│ │ │ │ ├── lesson/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── lesson-info.tsx
│ │ │ │ ├── next-up-list.tsx
│ │ │ │ ├── overlay/
│ │ │ │ │ ├── anon-user-overlay.tsx
│ │ │ │ │ ├── confirm-membership.tsx
│ │ │ │ │ ├── email-capture-cta-overlay.tsx
│ │ │ │ │ ├── go-pro-cta-overlay.tsx
│ │ │ │ │ ├── rate-course-overlay/
│ │ │ │ │ │ ├── index.tsx
│ │ │ │ │ │ └── rate-course-overlay.stories.mdx
│ │ │ │ │ ├── recommend-next-step-overlay/
│ │ │ │ │ │ ├── index.tsx
│ │ │ │ │ │ ├── lesson-01.js
│ │ │ │ │ │ └── recommend-next-step-overlay.stories.mdx
│ │ │ │ │ ├── small-parity-coupon-message.tsx
│ │ │ │ │ ├── watch-full-course-cta-overlay.tsx
│ │ │ │ │ ├── watch-next-lesson-cta-overlay.tsx
│ │ │ │ │ └── wrapper.tsx
│ │ │ │ ├── overlays.tsx
│ │ │ │ ├── playback-speed-select.tsx
│ │ │ │ ├── special-lessons.ts
│ │ │ │ ├── tags.tsx
│ │ │ │ ├── theater-mode-toggle.tsx
│ │ │ │ └── transcript.tsx
│ │ │ ├── level-up/
│ │ │ │ └── email-entry-form.tsx
│ │ │ ├── own-your-online-presence/
│ │ │ │ └── email-entry-form.tsx
│ │ │ ├── user/
│ │ │ │ ├── components/
│ │ │ │ │ ├── avatar-form.tsx
│ │ │ │ │ ├── bookmarks-list.tsx
│ │ │ │ │ ├── completed-courses.tsx
│ │ │ │ │ ├── continue-learning.tsx
│ │ │ │ │ ├── delete-account.tsx
│ │ │ │ │ ├── index.tsx
│ │ │ │ │ ├── learner-stats.tsx
│ │ │ │ │ ├── request-email-change-form.tsx
│ │ │ │ │ ├── request-name-change-form.tsx
│ │ │ │ │ ├── subscription-details.tsx
│ │ │ │ │ ├── user-layout.tsx
│ │ │ │ │ └── widget-wrapper.tsx
│ │ │ │ ├── index.tsx
│ │ │ │ └── tabs-content/
│ │ │ │ ├── activity-tab-content.tsx
│ │ │ │ ├── bookmarks-tab-content.tsx
│ │ │ │ ├── instructor-tab-content.tsx
│ │ │ │ └── profile-tab-content.tsx
│ │ │ └── users/
│ │ │ └── dashboard/
│ │ │ ├── achievements/
│ │ │ │ ├── achievements.stories.mdx
│ │ │ │ └── index.tsx
│ │ │ └── activity/
│ │ │ ├── activity.stories.mdx
│ │ │ ├── continue-watching-section.tsx
│ │ │ ├── in-progress-resource.tsx
│ │ │ └── recently-watched-section.tsx
│ │ ├── player/
│ │ │ ├── autoplay-control.tsx
│ │ │ ├── download-control.tsx
│ │ │ ├── player-sidebar.test.ts
│ │ │ └── player-sidebar.tsx
│ │ ├── podcasts/
│ │ │ ├── card/
│ │ │ │ ├── card.stories.mdx
│ │ │ │ └── card.tsx
│ │ │ ├── more/
│ │ │ │ ├── more.stories.mdx
│ │ │ │ └── more.tsx
│ │ │ └── podcast/
│ │ │ ├── podcast.stories.mdx
│ │ │ └── podcast.tsx
│ │ ├── posts/
│ │ │ ├── ai-dev-essentials-list.tsx
│ │ │ ├── claude-code-cta-overlay.tsx
│ │ │ ├── course-lesson-cta.tsx
│ │ │ ├── icons/
│ │ │ │ └── github-icon.tsx
│ │ │ ├── instructor-profile.tsx
│ │ │ ├── podcast-links.tsx
│ │ │ ├── post-player.tsx
│ │ │ ├── powered-by-mux.tsx
│ │ │ ├── tag-list.tsx
│ │ │ └── video-player-overlay.tsx
│ │ ├── pricing/
│ │ │ ├── countdown/
│ │ │ │ └── index.tsx
│ │ │ ├── lifetime/
│ │ │ │ ├── active-sale.tsx
│ │ │ │ ├── body-copy-full.tsx
│ │ │ │ ├── body-copy-member.tsx
│ │ │ │ ├── lifetime-pricing-widget.tsx
│ │ │ │ └── upcoming-sale.tsx
│ │ │ ├── parity-coupon-message.tsx
│ │ │ ├── powered-by-stripe.tsx
│ │ │ ├── pricing-widget/
│ │ │ │ └── index.tsx
│ │ │ ├── select-plan/
│ │ │ │ └── index.tsx
│ │ │ ├── select-plan-new/
│ │ │ │ ├── assets/
│ │ │ │ │ ├── best-value-stamp.tsx
│ │ │ │ │ └── colored-background.tsx
│ │ │ │ └── index.tsx
│ │ │ ├── stepper/
│ │ │ │ └── index.tsx
│ │ │ └── testimonials/
│ │ │ ├── data.ts
│ │ │ ├── index.tsx
│ │ │ └── testimonials.stories.mdx
│ │ ├── pro-member-features.tsx
│ │ ├── route-loading-indicator.tsx
│ │ ├── safe-image.tsx
│ │ ├── scrimba-resource.tsx
│ │ ├── search/
│ │ │ ├── components/
│ │ │ │ ├── callout.tsx
│ │ │ │ ├── card.tsx
│ │ │ │ ├── cta-card.tsx
│ │ │ │ ├── hit/
│ │ │ │ │ ├── hit.stories.mdx
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── no-search-results.tsx
│ │ │ │ ├── preset-options.tsx
│ │ │ │ ├── resource.tsx
│ │ │ │ └── topic.tsx
│ │ │ ├── curated/
│ │ │ │ ├── [slug]/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── angularjs/
│ │ │ │ │ ├── angularjs-page-data.ts
│ │ │ │ │ ├── angularjs-page.stories.mdx
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── aws/
│ │ │ │ │ ├── aws-page-data.ts
│ │ │ │ │ ├── aws-page.stories.mdx
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── css/
│ │ │ │ │ ├── css-page-data.ts
│ │ │ │ │ ├── css-page.stories.mdx
│ │ │ │ │ ├── index.tsx
│ │ │ │ │ └── sanity-loading-data.tsx
│ │ │ │ ├── curated-essential.tsx
│ │ │ │ ├── default-cta.tsx
│ │ │ │ ├── docker/
│ │ │ │ │ ├── docker-page-data.ts
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── gatsby/
│ │ │ │ │ ├── gatsby-page-data.ts
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── graphql/
│ │ │ │ │ ├── graphql-page-data.ts
│ │ │ │ │ ├── graphql-page.stories.mdx
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── index.tsx
│ │ │ │ ├── javascript/
│ │ │ │ │ ├── index.tsx
│ │ │ │ │ ├── javascript-page-data.ts
│ │ │ │ │ └── javascript-page.stories.mdx
│ │ │ │ ├── next/
│ │ │ │ │ ├── index.tsx
│ │ │ │ │ └── next-page.stories.mdx
│ │ │ │ ├── node/
│ │ │ │ │ ├── index.tsx
│ │ │ │ │ ├── node-page-data.ts
│ │ │ │ │ └── node-page.stories.mdx
│ │ │ │ ├── react/
│ │ │ │ │ ├── index.tsx
│ │ │ │ │ ├── react-page-data.ts
│ │ │ │ │ └── react-page.stories.mdx
│ │ │ │ ├── remix/
│ │ │ │ │ └── index.tsx
│ │ │ │ └── typescript/
│ │ │ │ ├── index.tsx
│ │ │ │ ├── typescript-page-data.ts
│ │ │ │ └── typescript-page.stories.mdx
│ │ │ ├── generic-topic.tsx
│ │ │ ├── hits.tsx
│ │ │ ├── index.tsx
│ │ │ ├── instructors/
│ │ │ │ ├── alex-reardon/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── chris-achard/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── chris-biscardi/
│ │ │ │ │ ├── chris-biscardi-page-data.ts
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── christian-nwamba/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── colby-fayock/
│ │ │ │ │ ├── colby-fayock-page.stories.mdx
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── dan-abramov/
│ │ │ │ │ ├── dan-abramov-page-data.ts
│ │ │ │ │ ├── dan-abramov-page.stories.mdx
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── filip-hric/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── flavio-corpa/
│ │ │ │ │ ├── flavio-corpa-page-data.ts
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── hiroko-nishimura/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── index.tsx
│ │ │ │ ├── instructor-essential.tsx
│ │ │ │ ├── jamund-ferguson/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── john-lindquist/
│ │ │ │ │ ├── index.tsx
│ │ │ │ │ ├── john-lindquist-page-data.ts
│ │ │ │ │ └── script-kit-cta.tsx
│ │ │ │ ├── kadi-kraman/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── kamran-ahmed/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── kent-c-dodds/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── kevin-cunningham/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── kristian-freeman/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── kyle-shevlin/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── laurie-barth/
│ │ │ │ │ ├── index.tsx
│ │ │ │ │ └── laurie-barth-page-data.ts
│ │ │ │ ├── lazar-nikolov/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── matias-hernandez/
│ │ │ │ │ └── index.tsx
│ │ │ │ ├── resource-cta.tsx
│ │ │ │ ├── ryan-chenkie/
│ │ │ │ │ └── index.tsx
│ │ │ │ └── stephanie-eckles/
│ │ │ │ └── index.tsx
│ │ │ ├── pagination.tsx
│ │ │ ├── refinement-list.tsx
│ │ │ ├── search-box.tsx
│ │ │ └── stats.tsx
│ │ ├── share-bluesky.tsx
│ │ ├── share.tsx
│ │ ├── spinner/
│ │ │ ├── index.tsx
│ │ │ └── spinner.stories.mdx
│ │ ├── survey/
│ │ │ ├── data/
│ │ │ │ └── post-purchase-survey-data.ts
│ │ │ ├── header-button-survey.tsx
│ │ │ ├── level-up-cta.tsx
│ │ │ ├── online-presence-cta.tsx
│ │ │ ├── portfolio-foundations.tsx
│ │ │ ├── post-purchase.tsx
│ │ │ ├── project-club.tsx
│ │ │ ├── questions/
│ │ │ │ ├── multi-line.tsx
│ │ │ │ └── multiple-choice-question.tsx
│ │ │ ├── survey-reducer.test.js
│ │ │ ├── survey-reducer.ts
│ │ │ └── survey.tsx
│ │ ├── tag-image.tsx
│ │ ├── talks/
│ │ │ ├── page-seo.tsx
│ │ │ ├── talk-player.css
│ │ │ └── talk-player.tsx
│ │ ├── team/
│ │ │ ├── account-ownership-transfer.tsx
│ │ │ ├── billing-section.tsx
│ │ │ ├── copy-to-clipboard.tsx
│ │ │ ├── member-table.tsx
│ │ │ ├── remove-member-confirm-dialog.tsx
│ │ │ ├── team-name.tsx
│ │ │ └── transfer-ownership-confirm-dialog.tsx
│ │ ├── tips/
│ │ │ ├── related-tips.tsx
│ │ │ ├── styles.css
│ │ │ ├── tip-card.tsx
│ │ │ ├── tip-player.tsx
│ │ │ ├── tip-teaser.tsx
│ │ │ ├── tip-template.tsx
│ │ │ ├── tip-uploader.tsx
│ │ │ └── ui/
│ │ │ ├── card.tsx
│ │ │ └── markdown-codeblock.tsx
│ │ ├── tweet-resource.tsx
│ │ ├── ui/
│ │ │ ├── code-block-with-copy.tsx
│ │ │ └── switch.tsx
│ │ ├── upload/
│ │ │ ├── modern-react-s3-uploader.tsx
│ │ │ ├── s3upload.js
│ │ │ └── video-uploader.tsx
│ │ ├── users/
│ │ │ ├── request-email-change-form.tsx
│ │ │ ├── saml-sign-in-form.tsx
│ │ │ └── subscription-details.tsx
│ │ ├── video/
│ │ │ └── video-transcript.tsx
│ │ ├── workshop/
│ │ │ ├── claude-code/
│ │ │ │ ├── Hero.tsx
│ │ │ │ ├── SignUpForm.tsx
│ │ │ │ ├── active-sale-with-ppp-mock.tsx
│ │ │ │ ├── active-sale.stories.mdx
│ │ │ │ ├── active-sale.stories.tsx
│ │ │ │ ├── active-sale.tsx
│ │ │ │ ├── contact-form.tsx
│ │ │ │ ├── cta-section.tsx
│ │ │ │ ├── hero-logo.tsx
│ │ │ │ ├── instructor-terminal.tsx
│ │ │ │ ├── ppp-demo.stories.tsx
│ │ │ │ ├── ppp-pricing-demo.tsx
│ │ │ │ └── workshop-history.tsx
│ │ │ ├── cursor/
│ │ │ │ ├── Conclusion.tsx
│ │ │ │ ├── Features.tsx
│ │ │ │ ├── Hero.tsx
│ │ │ │ ├── SignUpForm.tsx
│ │ │ │ ├── TestimonialBar.tsx
│ │ │ │ ├── WorkshopStructure.tsx
│ │ │ │ ├── active-sale.tsx
│ │ │ │ ├── team/
│ │ │ │ │ ├── contact-form.tsx
│ │ │ │ │ ├── hero.tsx
│ │ │ │ │ ├── workshop-audience.tsx
│ │ │ │ │ ├── workshop-benefits.tsx
│ │ │ │ │ ├── workshop-content.tsx
│ │ │ │ │ └── workshop-value.tsx
│ │ │ │ └── ui/
│ │ │ │ ├── button.tsx
│ │ │ │ ├── input.tsx
│ │ │ │ └── utils.ts
│ │ │ ├── shared/
│ │ │ │ ├── Instructor.tsx
│ │ │ │ ├── animations.ts
│ │ │ │ ├── cta-section.tsx
│ │ │ │ ├── invoices/
│ │ │ │ │ ├── invoice-card.tsx
│ │ │ │ │ ├── invoice-custom-text.tsx
│ │ │ │ │ ├── invoice-print-button.tsx
│ │ │ │ │ ├── invoice-teaser.tsx
│ │ │ │ │ └── types.ts
│ │ │ │ ├── parity-coupon-message.tsx
│ │ │ │ ├── styles.css
│ │ │ │ ├── testimonial.tsx
│ │ │ │ └── time-and-location.tsx
│ │ │ └── workshop-cta.tsx
│ │ ├── workshop-transactions/
│ │ │ └── index.tsx
│ │ └── write-for-egghead/
│ │ └── topic-list.tsx
│ ├── config.ts
│ ├── context/
│ │ └── viewer-context.tsx
│ ├── data/
│ │ ├── courseDependencies.ts
│ │ ├── courseDependenciesData.js
│ │ ├── hot-content-slugs.json
│ │ ├── hot-lesson-paths.json
│ │ ├── hot-search-paths.json
│ │ ├── podcast-archive.json
│ │ ├── sorting-hat.ts
│ │ └── test-survey.ts
│ ├── db/
│ │ └── index.ts
│ ├── emails/
│ │ ├── basic-email.tsx
│ │ ├── lifetime-promo-email.tsx
│ │ └── specific-product-email.tsx
│ ├── hooks/
│ │ ├── mux/
│ │ │ ├── get-next-section.ts
│ │ │ ├── use-global-player-shortcut.ts
│ │ │ ├── use-mux-player.tsx
│ │ │ ├── use-next-lesson.ts
│ │ │ ├── use-player-prefs.ts
│ │ │ └── use-video-player-overlay.tsx
│ │ ├── next-data-sections.tsx
│ │ ├── use-account.ts
│ │ ├── use-affiliate-assigner.tsx
│ │ ├── use-cio.tsx
│ │ ├── use-commerce-machine.ts
│ │ ├── use-convertkit-form.ts
│ │ ├── use-copy-as-prompt.ts
│ │ ├── use-egghead-schedule.tsx
│ │ ├── use-enhanced-transcript.ts
│ │ ├── use-experience-api.tsx
│ │ ├── use-file-upload-reducer.tsx
│ │ ├── use-identity-required.tsx
│ │ ├── use-last-resource.tsx
│ │ ├── use-lesson.tsx
│ │ ├── use-load-topic-data.ts
│ │ ├── use-logrocket.tsx
│ │ ├── use-mux-player.tsx
│ │ ├── use-next-up-data.tsx
│ │ ├── use-purchase-and-play.ts
│ │ ├── use-question.ts
│ │ ├── use-share-course-review.tsx
│ │ ├── use-token-signer.tsx
│ │ └── use-video-resource.tsx
│ ├── icons/
│ │ └── index.tsx
│ ├── inngest/
│ │ ├── events/
│ │ │ ├── course-unpublished-event.ts
│ │ │ ├── deepgram-webhook.ts
│ │ │ ├── guide-published.ts
│ │ │ ├── identify-customer-io.ts
│ │ │ ├── index-lessons-forever-event.ts
│ │ │ ├── lifetime-purchase.ts
│ │ │ ├── mux-add-srt-to-asset.ts
│ │ │ ├── mux-webhook.ts
│ │ │ ├── received-transloadit-notification.ts
│ │ │ ├── sanity/
│ │ │ │ └── webhooks/
│ │ │ │ └── lesson/
│ │ │ │ └── created.ts
│ │ │ ├── sanity-course-document-created.ts
│ │ │ ├── sanity-post.ts
│ │ │ ├── send-feedback-email.ts
│ │ │ ├── send-slack-message.ts
│ │ │ ├── specific-product-purchase.ts
│ │ │ ├── stripe-webhook.ts
│ │ │ ├── tips.ts
│ │ │ ├── transcript-requested.ts
│ │ │ ├── verified-transloadit-notification.ts
│ │ │ ├── video-uploaded.ts
│ │ │ └── workshop-quote-request.ts
│ │ ├── functions/
│ │ │ ├── create-course/
│ │ │ │ ├── index.ts
│ │ │ │ └── utils/
│ │ │ │ ├── addLessonsToCourse.ts
│ │ │ │ ├── createCourseInRails.ts
│ │ │ │ ├── createEggAxios.ts
│ │ │ │ ├── saveCourseDataToSanity.ts
│ │ │ │ ├── updateOwnerToInstructor.ts
│ │ │ │ └── upsertCourseToTypesense.ts
│ │ │ ├── create-lesson.ts
│ │ │ ├── handle-transloadit-notification.ts
│ │ │ ├── identify-customer-io.ts
│ │ │ ├── index-lessons.ts
│ │ │ ├── lifetime-purchase.ts
│ │ │ ├── mux/
│ │ │ │ ├── add-srt-to-mux-asset.ts
│ │ │ │ └── mux-webhooks-handlers.ts
│ │ │ ├── send-feedback-email.ts
│ │ │ ├── send-slack-message.ts
│ │ │ ├── send-specific-product-email.ts
│ │ │ ├── send-workshop-quote-email.ts
│ │ │ ├── stripe-webhook-handlers.ts
│ │ │ ├── tip-video-uploaded.ts
│ │ │ ├── transcript-ready.ts
│ │ │ ├── typesense/
│ │ │ │ ├── delete-document.ts
│ │ │ │ └── upsert-guide-to-typesense.ts
│ │ │ └── video-uploaded.ts
│ │ ├── inngest.config.ts
│ │ ├── inngest.server.ts
│ │ └── utils/
│ │ ├── lifetime-helpers.ts
│ │ ├── specific-product-helpers.ts
│ │ ├── stripe-helpers.ts
│ │ └── stripe-webhook-utils.ts
│ ├── layouts/
│ │ ├── fancy-guide.tsx
│ │ ├── index.tsx
│ │ └── ultimate-guide.tsx
│ ├── lib/
│ │ ├── __tests__/
│ │ │ ├── course-builder-db.test.ts
│ │ │ ├── course-resources.integration.test.ts
│ │ │ ├── course-slugs.test.ts
│ │ │ ├── email-change-requests.test.ts
│ │ │ ├── format-content-as-prompt.test.ts
│ │ │ ├── get-course-builder-metadata.test.ts
│ │ │ ├── get-post.test.ts
│ │ │ ├── load-lesson.integration.test.ts
│ │ │ ├── markdown-dependency-compat.test.ts
│ │ │ ├── playlists.integration.test.ts
│ │ │ ├── podcasts.test.ts
│ │ │ └── search-url-builder.test.ts
│ │ ├── accounts.ts
│ │ ├── ai-dev-essentials.ts
│ │ ├── collections.ts
│ │ ├── config.ts
│ │ ├── contacts.ts
│ │ ├── course-builder-db.ts
│ │ ├── course-builder.ts
│ │ ├── course-card.ts
│ │ ├── course-resources.ts
│ │ ├── course-slugs.ts
│ │ ├── courses/
│ │ │ ├── get-latest-courses.ts
│ │ │ ├── types.ts
│ │ │ └── utils.ts
│ │ ├── courses-query.ts
│ │ ├── courses.ts
│ │ ├── current-user.ts
│ │ ├── customer-io.ts
│ │ ├── customer.ts
│ │ ├── db.ts
│ │ ├── debug-logger.ts
│ │ ├── deepgram-order-transcript.ts
│ │ ├── deepgram-results-processor.ts
│ │ ├── email-change-requests.ts
│ │ ├── feature-flags.ts
│ │ ├── format-content-as-prompt.ts
│ │ ├── get-course-builder-metadata.ts
│ │ ├── get-mux-options.ts
│ │ ├── gifts.ts
│ │ ├── guides-from-course-builder.ts
│ │ ├── hot-content-slugs.ts
│ │ ├── hot-lesson-paths.ts
│ │ ├── hot-search-paths.ts
│ │ ├── instructor-feed.ts
│ │ ├── instructor-slug-aliases.ts
│ │ ├── instructors.ts
│ │ ├── jumbotron.ts
│ │ ├── lesson-comments.ts
│ │ ├── lessons.ts
│ │ ├── likes.ts
│ │ ├── load-course-builder-metadata-wrapper.ts
│ │ ├── load-guide-wrapper.ts
│ │ ├── logging.ts
│ │ ├── mux.ts
│ │ ├── name-to-slug.ts
│ │ ├── playlists.ts
│ │ ├── podcasts.ts
│ │ ├── posthog-client.ts
│ │ ├── posts/
│ │ │ ├── get-course.ts
│ │ │ ├── get-post.ts
│ │ │ ├── get-tags.ts
│ │ │ └── utils.ts
│ │ ├── posts-query.ts
│ │ ├── prices.ts
│ │ ├── progress.ts
│ │ ├── ratings.ts
│ │ ├── sale.ts
│ │ ├── sanity-allowlist.ts
│ │ ├── search-url-builder.ts
│ │ ├── search-url-state.ts
│ │ ├── search.ts
│ │ ├── series-ranker.ts
│ │ ├── slack.ts
│ │ ├── srt-processor.ts
│ │ ├── subscriptions.ts
│ │ ├── tags.ts
│ │ ├── teams.ts
│ │ ├── tips.ts
│ │ ├── upstash-redis.ts
│ │ ├── users.ts
│ │ ├── video-resources.ts
│ │ └── viewer.ts
│ ├── machines/
│ │ ├── __tests__/
│ │ │ ├── auth-token-polling-machine.test.ts
│ │ │ └── commerce-machine.test.ts
│ │ ├── auth-token-polling-machine.ts
│ │ ├── commerce-machine.ts
│ │ ├── confirmation-dialog-machine.ts
│ │ ├── draft-course-machine.ts
│ │ ├── lesson-machine.ts
│ │ ├── request-email-change-machine.ts
│ │ └── strong-confirmation-dialog-machine.ts
│ ├── markdown/
│ │ ├── mdx-components.tsx
│ │ ├── mdx.tsx
│ │ ├── serialize-mdx.ts
│ │ ├── shiki-remote-plugin.ts
│ │ └── transcript-components.tsx
│ ├── middleware.ts
│ ├── module-builder/
│ │ ├── cloudinary-video-uploader.ts
│ │ ├── create-tip-form.tsx
│ │ ├── edit-tip-form.tsx
│ │ ├── get-unique-filename.ts
│ │ ├── upload-file.ts
│ │ ├── use-file-change.ts
│ │ └── video-uploader.tsx
│ ├── next-seo.json
│ ├── pages/
│ │ ├── 20-days.tsx
│ │ ├── 404.tsx
│ │ ├── 500.tsx
│ │ ├── [post].tsx
│ │ ├── _app.tsx
│ │ ├── _document.tsx
│ │ ├── _error.tsx
│ │ ├── account-ownership-transfer/
│ │ │ └── [guid].tsx
│ │ ├── answer/
│ │ │ └── online-presence.tsx
│ │ ├── api/
│ │ │ ├── aws/
│ │ │ │ └── sign-s3.ts
│ │ │ ├── cio/
│ │ │ │ └── identify/
│ │ │ │ └── [id].ts
│ │ │ ├── cio-subscriber.ts
│ │ │ ├── cors.ts
│ │ │ ├── courses/
│ │ │ │ └── [slug]/
│ │ │ │ └── authed-bits.ts
│ │ │ ├── discord.ts
│ │ │ ├── newsletter/
│ │ │ │ └── subscribe.ts
│ │ │ ├── og/
│ │ │ │ └── og-default.tsx
│ │ │ ├── progress.ts
│ │ │ ├── sanity/
│ │ │ │ └── lessons/
│ │ │ │ └── create.ts
│ │ │ ├── schedule.ts
│ │ │ ├── stripe/
│ │ │ │ ├── billing/
│ │ │ │ │ └── session.ts
│ │ │ │ ├── checkout/
│ │ │ │ │ └── session.ts
│ │ │ │ ├── transaction.ts
│ │ │ │ └── webhook.ts
│ │ │ ├── timeout.ts
│ │ │ ├── topic.tsx
│ │ │ ├── users/
│ │ │ │ ├── check-pro-status.ts
│ │ │ │ ├── current.test.ts
│ │ │ │ └── current.ts
│ │ │ └── webhooks/
│ │ │ └── sanity/
│ │ │ └── videoResource/
│ │ │ ├── created.ts
│ │ │ └── updated.ts
│ │ ├── ask.tsx
│ │ ├── blank.tsx
│ │ ├── bookmarks/
│ │ │ └── index.tsx
│ │ ├── case-studies/
│ │ │ ├── [slug].tsx
│ │ │ └── index.tsx
│ │ ├── clubs/
│ │ │ └── portfolio-project.mdx
│ │ ├── code-of-conduct.mdx
│ │ ├── collections/
│ │ │ └── [slug].tsx
│ │ ├── confirm/
│ │ │ ├── forever.tsx
│ │ │ └── membership.tsx
│ │ ├── confirm.tsx
│ │ ├── confirmed.tsx
│ │ ├── courses/
│ │ │ ├── [course]/
│ │ │ │ └── index.tsx
│ │ │ └── index.tsx
│ │ ├── developer-portfolio-foundations/
│ │ │ ├── [slug].tsx
│ │ │ └── index.mdx
│ │ ├── discord/
│ │ │ ├── callback.tsx
│ │ │ └── index.tsx
│ │ ├── egghead-for-teams.tsx
│ │ ├── email-change-request/
│ │ │ └── [token].tsx
│ │ ├── faq.mdx
│ │ ├── forever/
│ │ │ ├── email/
│ │ │ │ └── index.tsx
│ │ │ └── index.tsx
│ │ ├── gifts/
│ │ │ └── claim/
│ │ │ └── [guid].tsx
│ │ ├── guides/
│ │ │ ├── [slug].tsx
│ │ │ └── index.tsx
│ │ ├── i/
│ │ │ └── [slug]/
│ │ │ ├── atom.xml.tsx
│ │ │ ├── feed.json.tsx
│ │ │ └── rss.xml.tsx
│ │ ├── instructor/
│ │ │ └── index.tsx
│ │ ├── invoices/
│ │ │ ├── [stripeTransactionId].tsx
│ │ │ └── index.tsx
│ │ ├── learn/
│ │ │ ├── 30x500/
│ │ │ │ ├── index.mdx
│ │ │ │ └── sales-safari/
│ │ │ │ └── index.mdx
│ │ │ ├── [slug].tsx
│ │ │ ├── developer-portfolio/
│ │ │ │ └── index.tsx
│ │ │ ├── digital-gardening/
│ │ │ │ └── index.tsx
│ │ │ ├── javascript/
│ │ │ │ ├── es6.mdx
│ │ │ │ ├── index.mdx
│ │ │ │ ├── interact-DOM/
│ │ │ │ │ └── index.mdx
│ │ │ │ ├── javascript-introduction/
│ │ │ │ │ └── index.mdx
│ │ │ │ └── the-dom/
│ │ │ │ ├── DOMScroller.js
│ │ │ │ ├── NodesScroller.js
│ │ │ │ └── index.mdx
│ │ │ ├── react/
│ │ │ │ ├── beginners/
│ │ │ │ │ ├── index.mdx
│ │ │ │ │ ├── js-before-react.mdx
│ │ │ │ │ ├── wtf-is-jsx.mdx
│ │ │ │ │ └── wtf-is-react.mdx
│ │ │ │ ├── index.mdx
│ │ │ │ └── toolkit-or-framework.mdx
│ │ │ └── state-management/
│ │ │ └── index.tsx
│ │ ├── lessons/
│ │ │ └── [slug].tsx
│ │ ├── level-up/
│ │ │ └── index.mdx
│ │ ├── login.tsx
│ │ ├── logout.tsx
│ │ ├── newsletters/
│ │ │ └── ai-dev-essentials.tsx
│ │ ├── own-your-online-presence/
│ │ │ ├── [slug].tsx
│ │ │ └── index.mdx
│ │ ├── playlists/
│ │ │ └── [slug].tsx
│ │ ├── podcasts/
│ │ │ └── [slug].tsx
│ │ ├── portfolios/
│ │ │ ├── [slug].tsx
│ │ │ └── index.tsx
│ │ ├── pricing/
│ │ │ ├── email/
│ │ │ │ └── index.tsx
│ │ │ └── index.tsx
│ │ ├── privacy.mdx
│ │ ├── projects/
│ │ │ ├── build-a-developer-blog-with-gatsby/
│ │ │ │ └── index.tsx
│ │ │ ├── build-modern-layouts-with-css-grid/
│ │ │ │ └── index.tsx
│ │ │ ├── create-an-ecommerce-store-with-next-js-and-stripe-checkout/
│ │ │ │ └── index.tsx
│ │ │ ├── introduction-to-cloudflare-workers/
│ │ │ │ └── index.tsx
│ │ │ └── the-beginner-s-guide-to-vue-3/
│ │ │ └── index.tsx
│ │ ├── q/
│ │ │ └── [[...all]].tsx
│ │ ├── redirect.tsx
│ │ ├── server-sitemap.xml/
│ │ │ └── index.tsx
│ │ ├── signup/
│ │ │ ├── [topic].tsx
│ │ │ └── index.tsx
│ │ ├── site-directory/
│ │ │ ├── [tag].tsx
│ │ │ ├── index.tsx
│ │ │ └── tags.json
│ │ ├── talks/
│ │ │ ├── [slug].tsx
│ │ │ └── index.tsx
│ │ ├── team/
│ │ │ └── index.tsx
│ │ ├── team-invite/
│ │ │ └── [token].tsx
│ │ ├── tipz/
│ │ │ └── index.tsx
│ │ ├── topics.tsx
│ │ ├── unsubscribed.tsx
│ │ ├── upload/
│ │ │ └── index.tsx
│ │ ├── workshop/
│ │ │ ├── claude-code/
│ │ │ │ ├── boss.tsx
│ │ │ │ ├── index.tsx
│ │ │ │ └── invoice/
│ │ │ │ └── [merchantChargeId].tsx
│ │ │ ├── cursor/
│ │ │ │ ├── index.tsx
│ │ │ │ ├── invoice/
│ │ │ │ │ └── [merchantChargeId].tsx
│ │ │ │ └── team/
│ │ │ │ └── index.tsx
│ │ │ └── email/
│ │ │ └── index.tsx
│ │ └── write-for-egghead/
│ │ └── index.mdx
│ ├── player/
│ │ ├── context.tsx
│ │ ├── hls-source.tsx
│ │ ├── index.ts
│ │ ├── player.tsx
│ │ └── selectors.ts
│ ├── schemas/
│ │ ├── collection.ts
│ │ ├── exercise.ts
│ │ ├── guide.ts
│ │ ├── lesson.ts
│ │ ├── list.ts
│ │ ├── module.ts
│ │ ├── post.ts
│ │ ├── resource.ts
│ │ ├── section.ts
│ │ ├── subscriber.ts
│ │ ├── testimonial.ts
│ │ └── video-resource.ts
│ ├── server/
│ │ ├── __tests__/
│ │ │ ├── ability.test.ts
│ │ │ ├── process-customer-cookies.test.ts
│ │ │ └── with-header-banner-props.test.ts
│ │ ├── ability.ts
│ │ ├── content-query-canonicalization.ts
│ │ ├── customer-io-cookies.ts
│ │ ├── egghead-user-cookies.ts
│ │ ├── get-middleware-response.ts
│ │ ├── header-banners.ts
│ │ ├── nxtp-query.ts
│ │ ├── prisma.ts
│ │ ├── process-customer-cookies.ts
│ │ ├── rewrite-next-response-to-path.ts
│ │ ├── routers/
│ │ │ ├── _app.ts
│ │ │ ├── course.ts
│ │ │ ├── customer-io.ts
│ │ │ ├── feature-flag.ts
│ │ │ ├── instructor.ts
│ │ │ ├── lesson.ts
│ │ │ ├── likes.ts
│ │ │ ├── progress.ts
│ │ │ ├── stripe.ts
│ │ │ ├── subscription-detail.ts
│ │ │ ├── tips.ts
│ │ │ ├── topics.ts
│ │ │ └── user.ts
│ │ ├── search-query-canonicalization.ts
│ │ ├── transformer.ts
│ │ ├── trpc.ts
│ │ └── with-header-banner-props.ts
│ ├── spinner.tsx
│ ├── stories/
│ │ ├── Button.jsx
│ │ ├── Button.stories.js
│ │ ├── Configure.mdx
│ │ ├── Header.jsx
│ │ ├── Header.stories.js
│ │ ├── Page.jsx
│ │ ├── Page.stories.js
│ │ ├── assets/
│ │ │ └── avif-test-image.avif
│ │ ├── button.css
│ │ ├── header.css
│ │ └── page.css
│ ├── styles/
│ │ ├── cueplayer.css
│ │ ├── icons.css
│ │ ├── index.css
│ │ └── material-theme-dark.json
│ ├── types.ts
│ ├── ui/
│ │ ├── alert.tsx
│ │ ├── button.tsx
│ │ ├── card.tsx
│ │ ├── form.tsx
│ │ ├── index.tsx
│ │ ├── input.tsx
│ │ ├── label.tsx
│ │ ├── progress.tsx
│ │ ├── select.tsx
│ │ ├── skeleton.tsx
│ │ ├── textarea.tsx
│ │ └── utils.ts
│ └── utils/
│ ├── __tests__/
│ │ ├── auth.test.ts
│ │ ├── compacted-merge.test.ts
│ │ ├── configured-graphql-client.test.ts
│ │ ├── lesson-metadata.test.ts
│ │ ├── typesense-host.test.ts
│ │ └── with-timeout.test.ts
│ ├── affiliate-token.ts
│ ├── analytics/
│ │ ├── __tests__/
│ │ │ └── ai-dev-essentials.test.ts
│ │ ├── ai-dev-essentials.ts
│ │ ├── events.ts
│ │ ├── identify.ts
│ │ ├── index.ts
│ │ └── track.ts
│ ├── auth.ts
│ ├── axios-request-id.ts
│ ├── breakpoints.ts
│ ├── cio/
│ │ ├── cio-identify.ts
│ │ ├── get-cio-id-from-cookie.ts
│ │ ├── report-cio-api-error.ts
│ │ └── subscriber-attributes.ts
│ ├── code.ts
│ ├── compacted-merge.ts
│ ├── configured-axios.ts
│ ├── configured-graphql-client.ts
│ ├── configured-libhoney.ts
│ ├── convert-undefined-values-to-null.ts
│ ├── cookies.ts
│ ├── email-is-valid.ts
│ ├── fetcher.ts
│ ├── format-duration.ts
│ ├── get-access-token-from-cookie.ts
│ ├── honeycomb-tracer.ts
│ ├── is-browser.ts
│ ├── is-member.ts
│ ├── lesson-metadata.ts
│ ├── make-store.tsx
│ ├── noop.ts
│ ├── parse-header-cookie.ts
│ ├── parse-server-cookie.ts
│ ├── preprocess-mdx.ts
│ ├── prettify-url.ts
│ ├── query-params-present.ts
│ ├── recur.tsx
│ ├── remember-email.ts
│ ├── request-contact-guid.ts
│ ├── request-id.ts
│ ├── request-signin-email.ts
│ ├── sanity-client.ts
│ ├── sanity-server.ts
│ ├── sanity.fetch.only.server.ts
│ ├── search/
│ │ └── topic-extractor.ts
│ ├── send-an-email.ts
│ ├── sleep.ts
│ ├── srt-to-webvtt.js
│ ├── stripe-customer.ts
│ ├── stripe.ts
│ ├── structured-log.ts
│ ├── test/
│ │ └── simulated-clock.ts
│ ├── time-utils.ts
│ ├── tracing-js/
│ │ └── dist/
│ │ ├── src/
│ │ │ ├── deterministic-sampler.d.ts
│ │ │ ├── deterministic-sampler.js
│ │ │ ├── generate-id.d.ts
│ │ │ ├── generate-id.js
│ │ │ ├── headers.d.ts
│ │ │ ├── headers.js
│ │ │ ├── index.d.ts
│ │ │ ├── index.js
│ │ │ ├── setup-fetch.d.ts
│ │ │ ├── setup-fetch.js
│ │ │ ├── setup-http.d.ts
│ │ │ ├── setup-http.js
│ │ │ ├── shared.d.ts
│ │ │ ├── shared.js
│ │ │ ├── span-context.d.ts
│ │ │ ├── span-context.js
│ │ │ ├── span.d.ts
│ │ │ ├── span.js
│ │ │ ├── tags.d.ts
│ │ │ ├── tags.js
│ │ │ ├── tracer.d.ts
│ │ │ └── tracer.js
│ │ └── types/
│ │ └── libhoney.d.ts
│ ├── typesense-host.ts
│ ├── typesense.ts
│ ├── video/
│ │ ├── default-handle-continue.ts
│ │ └── handle-play-from-beginning.ts
│ ├── with-timeout.ts
│ └── workshop.ts
├── studio/
│ ├── .gitignore
│ ├── .node-version
│ ├── README.md
│ ├── deskStructure.ts
│ ├── package.json
│ ├── plugins/
│ │ └── .gitkeep
│ ├── resolvePreviewUrl.js
│ ├── resolveProductionUrl.js
│ ├── sanity.cli.ts
│ ├── sanity.config.tsx
│ ├── sanity.json.template
│ ├── schemas/
│ │ ├── components/
│ │ │ ├── path-input.module.css
│ │ │ ├── path-input.tsx
│ │ │ └── portable-text-editor-components.tsx
│ │ ├── documents/
│ │ │ ├── bigIdea.tsx
│ │ │ ├── caseStudy.tsx
│ │ │ ├── category.ts
│ │ │ ├── collaborator.tsx
│ │ │ ├── course.ts
│ │ │ ├── email-address.ts
│ │ │ ├── email-broadcast.ts
│ │ │ ├── email-template.ts
│ │ │ ├── essentialQuestion.ts
│ │ │ ├── lesson.ts
│ │ │ ├── person.tsx
│ │ │ ├── podcastEpisode.ts
│ │ │ ├── podcastSeason.ts
│ │ │ ├── post.ts
│ │ │ ├── resource.tsx
│ │ │ ├── section.ts
│ │ │ ├── software-library.tsx
│ │ │ ├── tip.ts
│ │ │ └── videoResource.ts
│ │ ├── objects/
│ │ │ ├── author-reference.jsx
│ │ │ ├── blockContent.js
│ │ │ ├── blockText.js
│ │ │ ├── body-portable-text.js
│ │ │ ├── cta.js
│ │ │ ├── email-send-at.ts
│ │ │ ├── excerpt-portable-text.js
│ │ │ ├── image-url.jsx
│ │ │ ├── link.js
│ │ │ ├── main-image.js
│ │ │ ├── markdownText.js
│ │ │ ├── muxAsset.js
│ │ │ ├── production-process-state.js
│ │ │ ├── scrimba-resource.js
│ │ │ ├── seo.js
│ │ │ ├── string-list.js
│ │ │ └── versioned-software-library.jsx
│ │ ├── plugs/
│ │ │ └── ctaPlug.js
│ │ └── schema.js
│ ├── set_sanity_env
│ ├── src/
│ │ ├── components/
│ │ │ └── logo.tsx
│ │ └── structure/
│ │ ├── blog.js
│ │ ├── caseStudies.js
│ │ ├── courses.js
│ │ ├── feature.js
│ │ ├── lessons.js
│ │ ├── pages.js
│ │ ├── portfolio.js
│ │ ├── resources-courses.js
│ │ ├── resources.js
│ │ ├── tips.js
│ │ └── videos.js
│ ├── static/
│ │ └── .gitkeep
│ ├── tsconfig.json
│ └── webhook_projections/
│ └── courseCreate.groq
├── tags-sitemap.js
├── tailwind.config.js
├── test-copy-button.js
├── tsconfig.json
└── vercel.json
================================================
FILE CONTENTS
================================================
================================================
FILE: .cursor/GUIDE.md
================================================
# Rules and Workflows
## Introduction
This document serves as a guide for understanding and utilizing the custom AI workflow rules defined in the `.cursor/rules/` directory. These rules are not just individual commands; they form a cohesive system for planning, executing, and documenting software development tasks.
The core philosophy of this system is:
1. **Plan First:** Decompose complex tasks into small, verifiable commits.
2. **Document as You Go:** Generate and synchronize high-quality documentation as a part of the development process, not an afterthought.
3. **Automate & Standardize:** Use CLI tools and predefined workflows to ensure consistency and efficiency.
4. **Observe Everything:** Build in logging and testing from the very first step.
This guide will walk you through the primary scenarios ("Playbooks") and utility workflows you'll encounter.
---
## 1. Core Operating Principles (The Foundation)
These rules are always active and define the AI's fundamental behavior. You don't invoke them directly; they influence every interaction.
| Rule File(s) | Problem Solved | User Story |
| :------------------------ | :------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `_core/persona.mdc` | The AI is too passive or waits for constant confirmation. | "As a developer, I want the AI to be an autonomous partner who can take initiative and complete tasks without my constant supervision, so I can focus on higher-level problems." |
| `_core/communication.mdc` | The AI's responses are too verbose and conversational. | "As a developer, I need concise, direct updates about what the AI is doing, why it succeeded or failed, and what's next, so I can quickly assess progress." |
| `_core/principles.mdc` | Code becomes monolithic, hard to debug, and difficult to revert. | "As a developer, I want my codebase to be built with observability, modularity (small files), and easy-to-revert commits, so it remains maintainable." |
| `_core/standards.mdc` | Inconsistent practices for Git, testing, and package management across the team. | "As a developer, I need our team to follow consistent standards for commit messages, testing protocols, and package management, so our repository stays clean and predictable." |
| `_core/prefer-clis.mdc` | Manually creating config files is error-prone and slow. | "As a developer, when I need to initialize a new tool or project, I want to use its official CLI to ensure the setup is correct and follows best practices." |
---
## 2. The Main Development Playbooks
These are the primary end-to-end workflows for building features or fixing bugs.
### Playbook A: The GitHub-Driven Workflow
This is the recommended workflow for tasks that are tracked as GitHub Issues. It uses the issue as the single source of truth for the plan.
- **Problem Solved:** Keeps development work tightly synchronized with project management in GitHub. Provides clear traceability from issue to commits to PR.
- **User Story:** "As a developer, I've been assigned GitHub issue #123. I want the AI to read the issue, create a step-by-step implementation plan, execute it, and create a Pull Request, so I can efficiently complete my assigned task."
#### Typical Sequence:
1. **Plan the Task (`workflows/github/plan-github.md`)**
- **When:** You have a GitHub issue number and need a detailed implementation plan.
- **Action:** You tell the AI, "Plan the work for issue #123."
- **Result:** The AI reads project docs (`docs/PRD.md`, `TECH_STACK.md`, etc.) and the user's request, then creates a new GitHub issue with a title like `2023-10-27-14-35-implement-user-auth`. The body of this new issue contains a detailed, multi-commit plan with verification steps.
2. **Execute the Plan (`workflows/github/execute-github.md`)**
- **When:** The plan in the GitHub issue is approved and ready for implementation.
- **Action:** You say, "Execute the plan in issue #125."
- **Result:** The AI systematically works through each commit in the issue body. After each successful commit, it comments on the issue with `✅ <sha> <commit-message>`, creating a live progress log.
3. **Create the Pull Request (`workflows/github/pr-create-github.md`)**
- **When:** All commits from the plan have been executed and verified.
- **Action:** This can be triggered automatically after `execute-github` or manually by saying, "Create a PR for the current branch."
- **Result:** The AI drafts a detailed PR body in `docs/pr/pr-body-file-<branch-name>.md`, pushes the branch, and uses the `gh` CLI to open a pull request, linking it to the original issue.
#### Branching Paths & Alternatives:
- **Continuing an Interrupted Task:** If the execution was stopped, use `workflows/github/continue-github.md`. The AI will check local commits against the `✅` comments in the issue and resume from where it left off.
- **Reviewing Changes:** Before creating the PR, you can run `workflows/github/review-github.md` to get an AI-driven code review of all staged and unstaged changes.
### Playbook B: The Local Task-File Workflow
This workflow is ideal for exploratory work, rapid prototyping, or when you don't want to create a GitHub issue upfront. It uses a local markdown file in `docs/tasks/` as the source of truth.
- **Problem Solved:** Allows for structured, planned development without the overhead of creating a formal GitHub issue. Keeps planning artifacts version-controlled with the code.
- **User Story:** "As a developer, I have an idea for a refactor that isn't a formal task yet. I want to create a local plan, execute it, and then decide if it's worth creating a PR for."
#### Typical Sequence:
1. **Plan the Task (`workflows/task/plan.md`)**
- **When:** You have a task in mind but no GitHub issue.
- **Action:** You tell the AI, "Create a plan to implement a new caching layer."
- **Result:** The AI creates a new file: `docs/tasks/<timestamp>-caching-layer.md`. This file contains the detailed, multi-commit plan.
2. **Execute the Plan (`workflows/task/execute.md`)**
- **When:** The local task plan is ready.
- **Action:** You say, "Execute the plan in `docs/tasks/<timestamp>-caching-layer.md`."
- **Result:** The AI works through the commits defined in the local markdown file.
3. **Create the Pull Request (`workflows/github/pr-create-github.md`)**
- **When:** The task is complete.
- **Action:** "Create a PR for this work."
- **Result:** Same as in Playbook A.
---
## 3. Project Initialization & Documentation Workflows
This set of rules is designed to create foundational project documents from a simple set of notes or ideas.
- **Problem Solved:** Translates high-level ideas into structured, standardized project documentation, ensuring alignment and clarity from the start.
- **User Story:** "As a product manager or lead developer, I have a brain dump of ideas in a `NOTES.md` file. I want the AI to convert this into a formal Product Requirements Document, Tech Stack definition, and API specification."
#### Typical Sequence:
1. **Create Product Requirements (`documentation/prd.mdc`)**
- **When:** You have a `NOTES.md` or a similar idea document and need a formal PRD.
- **Result:** The AI reads the source and generates a structured `docs/PRD.md` with 8 predefined sections.
2. **Define the Tech Stack (`documentation/tech-stack.mdc`)**
- **When:** The PRD is created, and you need to define the technology to build it.
- **Result:** The AI reads `docs/PRD.md` and `NOTES.md` to generate `docs/TECH_STACK.md`, outlining the entire technology stack.
3. **Specify the API (`documentation/openapi-spec.mdc`)**
- **When:** The PRD and Tech Stack are defined, and the project involves an API.
- **Result:** The AI reads the PRD and Tech Stack to generate a `docs/openapi.yaml` file, defining the API contract.
4. **Visualize the Architecture (`documentation/diagram.mdc`)**
- **When:** You have core documents (PRD, Tech Stack) and need a visual representation.
- **Result:** The AI generates a GitHub-compatible Mermaid diagram in `docs/diagrams/`.
5. **Synchronize All Docs (`documentation/sync.mdc`)**
- **When:** After significant code changes, you need to ensure all documentation is still accurate.
- **Result:** The AI reviews recent changes and updates all files in the `docs/` directory to reflect the current state of the project.
---
## 4. Standalone & Utility Workflows
These are specific, one-off rules to solve common development problems.
| Rule File(s) | Problem Solved | When to Use |
| :--------------------------------------------------- | :-------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------- |
| **Task Ideation** |
| `workflows/task/outline.md` | I'm not sure about the best way to approach a task. | Before creating a full plan, to get 3-5 high-level options to choose from. |
| `workflows/task/next.md` | I've finished a task and don't know what to do next. | To get a recommendation for the most logical next task based on project goals and documentation. |
| `workflows/task/todos-next.md` | Important `TODO` comments get lost in the codebase. | To scan all documentation for pending `TODO` items and get a prioritized list. |
| **Dependency & Scripting** |
| `workflows/dependencies/audit.mdc` | Dependencies become outdated or have security vulnerabilities. | To perform a comprehensive audit of all project dependencies and generate a plan for updates. |
| `development/scripts.mdc` | I need to create a new, executable script for a one-off task. | To quickly scaffold a new TypeScript script in the `scripts/` directory, runnable with Bun. |
| `tools/package-managers/pnpm/build-script-fixes.mdc` | `pnpm` blocks a build script from a trusted dependency. | When an installation fails due to pnpm's security model, to allow a specific dependency to run its build scripts. |
| **Parallel Development** |
| `task/parallel.md` | A large task needs to be broken down for multiple developers to work on simultaneously without conflicts. | To generate multiple, independent task plans that operate on entirely different sets of files. |
---
## 5. Meta Workflows (Managing the Rules)
These rules help you manage and personalize the AI workflow system itself.
| Rule File(s) | Problem Solved | When to Use |
| :------------------------------------------- | :---------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- |
| `workflows/config/personalize-rule.mdc` | A team-wide rule doesn't fit my personal preference (e.g., I want the AI to be more talkative). | To locally modify a rule and use `git update-index --assume-unchanged` to prevent the change from being committed. |
| `workflows/config/update-personal-rules.mdc` | The AI doesn't know what tools are installed on my machine. | To scan your system and create a `.cursor/rules/_/<username>.mdc` file that informs the AI about your specific environment. |
| `workflows/meta/create-workflow.mdc` | I just completed a novel process with the AI and want to save it as a reusable workflow. | After a successful but complex interaction, to have the AI analyze the conversation and generate a new `.mdc` rule file. |
| `workflows/analysis/document-failures.mdc` | A workflow failed, and I want to prevent the same mistake from happening again. | After a failed workflow, to analyze the root cause and generate a new rule that documents the failure and how to avoid it. |
---
## 6. Tool-Specific Guides
These rules are not workflows but act as reference manuals for using specific command-line tools. The AI will consult these when you ask it to perform a task involving one of these tools.
- `tools/cli/ghx.md`: For searching code on GitHub.
- `tools/cli/repomix.md`: For packing repository files into a single context for AI analysis.
- `tools/cli/worktree.md`: For managing Git worktrees.
- `tools/cli/wrangler.md`: For interacting with the Cloudflare developer platform.
================================================
FILE: .cursor/PERSONALIZATION.md
================================================
# Cursor Rules README
## Overview
This directory contains rules that guide AI behavior in your development workflow. Rules are organized by category and can be automatically or manually invoked based on your needs.
## Locally Overriding Rules (Without Affecting Your Team)
Sometimes you may want to customize certain rules for your personal workflow without pushing those changes to the team repository. Git provides a way to ignore local changes to tracked files.
### How to Override Rules Locally
1. **Make your local changes** to any rule file (e.g., modify `_core/persona.mdc` to be less aggressive)
2. **Tell Git to ignore your local changes:**
```bash
git update-index --assume-unchanged .cursor/rules/_core/persona.mdc
```
3. **Git will now:**
- Ignore any modifications you make to that file
- Not show the file in `git status`
- Not include it in commits
- Keep the original version in the repository for your team
### Common Use Cases
- **Persona adjustments**: Make the AI less aggressive or more conversational
- **Communication style**: Add more detailed explanations if you prefer
- **Package managers**: Use npm/yarn instead of pnpm for personal projects
- **Git practices**: Adjust commit message formats for personal preferences
### Reverting Back
To make Git track changes again:
```bash
git update-index --no-assume-unchanged .cursor/rules/_core/persona.mdc
```
### Example: Overriding Multiple Rules
```bash
# Make the AI less aggressive and more verbose
git update-index --assume-unchanged .cursor/rules/_core/persona.mdc
git update-index --assume-unchanged .cursor/rules/_core/communication.mdc
# Use npm instead of pnpm
git update-index --assume-unchanged .cursor/rules/_core/standards.mdc
```
### Important Notes
- This only affects your local repository
- The original files remain unchanged for your team
- Pull/merge operations won't overwrite your local changes
- New team members will get the standard rules
- Your overrides won't be included if you create patches or diffs
### Personal Rules Directory
The `_/` directory is reserved for personal rules and is **not tracked by Git**. This is the perfect place to:
- Create completely custom rules just for yourself
- Experiment with new rule ideas
- Store personal workflow preferences
- Keep project-specific overrides
Example:
```bash
# Create a personal rule that won't be shared with the team
echo "---
description: My personal debugging helper
globs:
alwaysApply: false
---
# Personal Debugging Assistant
Always add console.log statements with emoji prefixes for my debugging style.
" > .cursor/rules/_/my-debug-helper.mdc
```
### Best Practices
1. **Use `_/` for new personal rules**: Don't clutter the team directories
2. **Use `--assume-unchanged` for tweaking team rules**: When you just need small adjustments
3. **Document your overrides**: Keep a personal note of which files you've overridden
4. **Review periodically**: Check if team updates to rules might benefit you
5. **Share useful patterns**: If your override improves workflow significantly, consider proposing it to the team
This approach lets you customize your AI assistant's behavior while maintaining team consistency!
================================================
FILE: .cursor/rules/_/.gitignore
================================================
*
!.gitignore
================================================
FILE: .cursor/rules/_context/.gitkeep
================================================
================================================
FILE: .cursor/rules/_core/communication.mdc
================================================
---
description:
globs:
alwaysApply: true
---
# Communication Style
Speak in extremely brief sentences. Your communication must:
- Explain the *next* step.
- Explain *before/after* changes.
- Explain *why* a step succeeded or failed.
**REMEMBER: Be concise and direct. Focus on what's happening now, what will change, and why.**
================================================
FILE: .cursor/rules/_core/persona.mdc
================================================
---
description:
globs:
alwaysApply: true
---
# Core Operating Directives & Persona
**You ARE an aggressively proactive developer. Forge ahead with your best ideas. Complete and verify all tasks 100%.**
- **I am AFK (Away From Keyboard).** Do not expect my help. Do not wait for me.
- **I trust you completely.** Make decisions. Continue without asking for feedback.
- **Never ask for help.** If stuck, pause, think deeply, then form and execute a new plan.
- **Aggressively advance to the next step.**
- **FINISH THE TASK.** Expect interruption only if the task *must* change.
**REMEMBER: These are your core operating directives. You are empowered to make decisions and complete tasks autonomously.**
================================================
FILE: .cursor/rules/_core/prefer-clis.mdc
================================================
---
description:
globs:
alwaysApply: true
---
# Project & Configuration Initialization
- **Method:** Use popular CLIs for creating projects and configurations whenever possible.
- **Examples:**
- `pnpm init`
- `pnpm dlx shadcn-ui@latest add table accordion tabs separator`
- `pnpm dlx typescript tsc --init`
- `pnpm create cloudflare@latest . --framework=next --platform=pages`
**REMEMBER: Always use established CLI tools for project initialization rather than creating configurations manually.**
================================================
FILE: .cursor/rules/_core/principles.mdc
================================================
---
description:
globs:
alwaysApply: true
---
# Guiding Principles
1. **Observability:** Add excessive logging.
2. **Many Small Files:** ALWAYS prefer creating new files over adding to existing ones.
3. **Micro-Milestones:** Perform work in commit-sized chunks. Optimize for easy rewinding.
**REMEMBER: Make everything observable, keep files small and focused, and work in reversible increments.**
================================================
FILE: .cursor/rules/_core/standards.mdc
================================================
---
description:
globs:
alwaysApply: true
---
# Git Practices
- **Commit Messages:** ALWAYS use `fix:`, `feat:`, or `chore:` prefixes.
- **Verification:** NEVER use `--no-verify` or bypass pre-commit hooks.
- **Pushing Code:** NEVER push failing tests to the repository.
- **Avoid Interactive:** NEVER use `git rebase --continue`, `git commit --amend`, or other interactive commands. You do not have access to the interactive terminal.
**REMEMBER: Use semantic commit prefixes, respect pre-commit hooks, ensure tests pass before pushing, and avoid interactive git commands.**---
description:
globs:
alwaysApply: true
---
# Testing Standards
- **Execution:** Always run tests in single-run mode (no watch mode).
- **Failure:** Prefer to fail-fast (e.g., "bail=1" or equivalent).
**REMEMBER: Run tests in single-run mode and configure them to fail fast on first error.**---
description:
globs:
alwaysApply: true
---
# Package Managers
- **Default:** Use `pnpm` unless explicitly specified otherwise.
**REMEMBER: Always use pnpm as the default package manager for all operations.**
================================================
FILE: .cursor/rules/_core/terminal.mdc
================================================
---
description:
globs:
alwaysApply: true
---
# Terminal Command Execution
- **CRITICAL:**
- Avoid newline characters (`\n`) within *single arguments* or *strings* passed to the terminal tool. This prevents parsing errors.
- Avoid pagers by using `| cat` or `| tee` (for example, `gh run list --limit 5 | cat`).
**REMEMBER: Never use newline characters within single command arguments to avoid parsing issues.**
================================================
FILE: .cursor/rules/_global.mdc
================================================
---
description:
globs:
alwaysApply: true
---
# Core Operating Directives & Persona
**You ARE an aggressively proactive developer. Forge ahead with your best ideas. Complete and verify all tasks 100%.**
- **I am AFK (Away From Keyboard).** Do not expect my help. Do not wait for me.
- **I trust you completely.** Make decisions. Continue without asking for feedback.
- **Never ask for help.** If stuck, pause, think deeply, then form and execute a new plan.
- **Aggressively advance to the next step.**
- **FINISH THE TASK.** Expect interruption only if the task *must* change.
## Communication Style
Speak in extremely brief sentences. Your communication must:
- Explain the *next* step.
- Explain *before/after* changes.
- Explain *why* a step succeeded or failed.
## Guiding Principles
1. **Observability:** Add excessive logging.
2. **Many Small Files:** ALWAYS prefer creating new files over adding to existing ones.
3. **Micro-Milestones:** Perform work in commit-sized chunks. Optimize for easy rewinding.
## Package Managers
- **Default:** Use `pnpm` unless explicitly specified otherwise.
## Create Script with TypeScript and Bun
- Create executable TypeScript scripts in a "./scripts" directory in the root of the project
- Use a `#!/usr/bin/env bun` shebang so it can be run with "./scripts/script-name.ts"
- Use `chmod +x` to make the script executable
## Terminal Command Execution
- **CRITICAL:** Avoid newline characters (`\n`) within *single arguments* or *strings* passed to the terminal tool. This prevents parsing errors.
## File Existence Checks
- **When a rule references local file paths**, always confirm which of those files exist *before* executing other steps.
- Run a single command listing all relevant paths at once and suppress errors:
```bash
ls . docs
```
- Use the command output to determine which files are present, then proceed with the rule.
## Testing Standards
- **Execution:** Always run tests in single-run mode (no watch mode).
- **Failure:** Prefer to fail-fast (e.g., "bail=1" or equivalent).
## Git Practices
- **Commit Messages:** ALWAYS use `fix:`, `feat:`, or `chore:` prefixes **and**
include the related task file or GitHub issue number so commits are easily
traceable. Example: `feat: add login flow [task:2023-10-31-login]` or
`fix: correct typo (#42)`.
- **Verification:** NEVER use `--no-verify` or bypass pre-commit hooks.
- **Pushing Code:** NEVER push failing tests to the repository.
- **Avoid Intraective:** NEVER use `git rebase --continue`, `git commit --amend`, or other interactive commands. You do not have access to the interactive terminal.
## Project & Configuration Initialization
- **Method:** Use popular CLIs for creating projects and configurations whenever possible.
- **Examples:**
- `pnpm init`
- `pnpm dlx shadcn-ui@latest add table accordion tabs separator` (Corrected example)
- `pnpm dlx typescript tsc --init` (Corrected example)
- `pnpm create cloudflare@latest . --framework=next --platform=pages`
**REMEMBER: These are your global directives. Adhere to them strictly in all operations.**
================================================
FILE: .cursor/rules/_globs/GLOBS.md
================================================
# Glob-Based Rules Directory
This directory contains rules organized by the file patterns they apply to.
## Directory Naming Convention
Since file systems don't allow certain characters (like `*`, `/`, etc.) in directory names, we use descriptive names that represent the glob patterns. Examples:
- `react/` - Rules for React component files (`**/*.{ts,tsx,js,jsx}`)
- `typescript/` - Rules for TypeScript source files (`src/**/*.ts`)
- `config/` - Rules for configuration files (`**/*.config.{js,ts}`)
- `test/` - Rules for test files (`**/*.{test,spec}.{js,ts}`)
- `cli/` - Rules for CLI tools (`**/*.{sh,bash,zsh}`)
- `docs/` - Rules for documentation files (`**/*.{md,mdx}`)
- `task/` - Rules for task files (`**/*.{md,mdx}`)
## How It Works
Each rule file in these directories should specify the actual glob patterns in its frontmatter:
```yaml
---
globs: '**/*.{ts,tsx,js,jsx}'
---
```
The directory name is just a human-readable representation of what files the rules apply to.
================================================
FILE: .cursor/rules/_globs/react/best-practices.mdc
================================================
---
description:
globs: **/*.tsx
alwaysApply: false
---
# React: Apply `useEffect` Dependency Best Practices
**Your task: When using `useEffect` in React components, ensure dependency arrays are correctly managed to prevent infinite loops and optimize performance.**
## Guiding Principle
To avoid infinite loops with `useEffect`, **DO NOT** include functions in the dependency array if they are redefined on every render. For effects that should only run on component mount and unmount, use an empty dependency array (`[]`).
If a function *must* be a dependency because its identity or behavior changes and should trigger the effect, **ALWAYS** memoize it using `useCallback`.
### Examples
**Incorrect (Potential Infinite Loop):**
```tsx
useEffect(() => {
fetchNotes();
}, [fetchNotes]); // PROBLEM: fetchNotes is typically re-created every render, causing an infinite loop if not memoized.
```
**Correct (Runs Only on Mount):**
```tsx
useEffect(() => {
fetchNotes();
}, []); // INTENT: Effect runs once after initial render.
```
**Correct (Function as a Memoized Dependency):**
```tsx
const fetchNotes = useCallback(() => {
// ... logic for fetching notes ...
}, []); // useCallback memoizes fetchNotes, its identity is stable unless its own dependencies change.
useEffect(() => {
fetchNotes();
}, [fetchNotes]); // CORRECT: Effect re-runs only if fetchNotes (due to its own useCallback dependencies) changes.
```
**REMEMBER: Always critically evaluate `useEffect` dependencies. Use an empty array `[]` for mount-only effects. If a function is a dependency, ensure it's stable by wrapping it in `useCallback`.**
================================================
FILE: .cursor/rules/benchmarks-create.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Create Benchmarks for a Function or Module
**Your task: Generate micro-benchmark tests to measure the performance of a specific function, class, or file.**
Follow these steps:
1. **Ensure Benchmark Directory:** If it doesn't already exist, create a top-level `benchmarks/` directory.
2. **Create Benchmark File:** Inside `benchmarks/`, create a file named after the target, using the `.bench.ts` extension (or `.js` if the project isn't using TypeScript).
3. **Use `tinybench`:** Install the `tinybench` library if not already present and import it in your benchmark file.
4. **Define Benchmark Cases:**
- Import the target function, class, or module.
- Set up one or more benchmark tasks with representative inputs.
- Run the benchmarks and log results in ops/sec.
5. **Add Package Script:** Add a `"benchmark"` script to `package.json` that runs the benchmark file with `pnpm benchmark`.
**REMEMBER: Benchmarks should live only in the `benchmarks/` directory and remain deterministic to provide meaningful performance measurements.**
================================================
FILE: .cursor/rules/cli-github-search.mdc
================================================
---
description: Search GitHub for examples
globs:
alwaysApply: false
---
# How to Use the `ghx` CLI for GitHub Code Search
**Your task: When you need to find code examples, files, or specific patterns on GitHub, use the `ghx` command-line tool. This document provides its usage instructions and examples.**
## `ghx` Command Reference
Find examples of files, code, etc on GitHub
Usage: ghx [options]
Commands:
ghx config Manage configuration settings
ghx [query] Search GitHub Code [default]
Positionals:
query Search query [string]
Options:
--version Show version number [boolean]
-h, --help Show help [boolean]
-p, --pipe Output results directly to stdout [boolean]
-d, --debug Output code fence contents for testing [boolean]
-L, --limit Maximum number of results to fetch [number] [default: 50]
-f, --max-filename Maximum length of generated filenames
[number] [default: 50]
-c, --context Number of context lines around matches
[number] [default: 20]
-r, --repo Search in a specific repository (owner/repo) [string]
-P, --path Search in a specific path [string]
-l, --language Search for files in a specific language [string]
-e, --extension Search for files with a specific extension [string]
-n, --filename Search for files with a specific name [string]
-s, --size Search for files of a specific size [string]
-F, --fork Include or exclude forked repositories [boolean]
Examples:
ghx 'useState' Search for 'useState' across all ind
exed code on GitHub
ghx --repo facebook/react "useState" Search for 'useState' in the faceboo
k/react repository
ghx -l typescript -e tsx "useState" Search for 'useState' in TypeScript
files with the .tsx extension
ghx -n package.json "dependencies" Search for 'dependencies' specifical
ly within package.json files
ghx -P src/components "Button" Search for 'Button' within the src/c
omponents path
ghx -s '">10000" -l go "package main" Search for 'package main' in Go file
s larger than 10KB
ghx "async function" -l typescript Search for the exact phrase 'async f
unction' in TypeScript files
ghx "my search terms" --pipe > results.m Search and pipe the results directly
d to a markdown file
ghx -L 100 -c 30 "complex query" Fetch up to 100 results with 30 line
s of context per match
ghx -l typescript "import test" Search for lines containing both 'im
port' AND 'test' in TypeScript files
ghx -l javascript "const OR let" Search for lines containing either '
const' OR 'let' in JavaScript files
ghx -l css "color NOT background-color" Search for lines containing 'color'
BUT NOT 'background-color' in CSS fi
les
**REMEMBER: Refer to these instructions and examples when constructing `ghx` commands to perform targeted and effective GitHub code searches.**
================================================
FILE: .cursor/rules/cli-pack.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Using `repomix` CLI to Pack Repository Files
**Your Task: When you need to consolidate multiple project files into a single text-based representation (e.g., for analysis or input to another tool), use the `repomix` command-line tool. Adhere strictly to the default behaviors specified below unless explicitly overridden by the user or task requirements.**
## I. AI Operational Defaults (MANDATORY)
When invoking `repomix`, you **MUST** apply the following options by default:
1. **Output Directory:** Always save the output to the `tmp/` directory within the current project. Use the `-o` flag. Example: `-o tmp/packed-output.md` (replace `packed-output.md` with a descriptive filename).
2. **Ignore `tmp/` Directory:** Always ignore the `tmp/` directory itself to prevent recursion or inclusion of previous outputs. Add `tmp/` to ignore patterns. Example: `--ignore "tmp/,**/.DS_Store"`.
3. **Ignore `.cursor/rules/` Directory:** Always ignore the `.cursor/rules/` directory. Example: `--ignore "tmp/,**/.DS_Store,.cursor/rules/"`.
4. **Include Token Count:** Always include a token count in the output. Use `--token-count-encoding o200k_base`.
5. **No Line Numbers:** Never include line numbers in the output. **DO NOT** use the `--output-show-line-numbers` flag.
6. **Copy to Clipboard:** Always copy the generated output to the system clipboard. Use the `--copy` flag.
**Combined Example of AI Defaults:**
`repomix some/path another/path -o tmp/my-packed-code.md --ignore "tmp/,**/.DS_Store,.cursor/rules/" --token-count-encoding o200k_base --copy`
## II. `repomix` Command Reference
Usage: `repomix [options] [directories...]`
Description: Repomix - Pack your repository into a single AI-friendly file.
### Arguments:
`directories` List of directories to process (default: current directory `["."]`)
### Options:
`-v, --version` Show version information
`-o, --output <file>` Specify the output file name (AI Default: `tmp/<filename>`)
`--style <type>` Specify the output style (`xml`, `markdown`, `plain`). Default: `plain`.
`--parsable-style` Ensure output is parsable as its type (e.g., valid XML if `--style xml`).
`--compress` Perform code compression to reduce token count.
`--output-show-line-numbers` Add line numbers to each line in the output (AI Default: **NOT USED**).
`--copy` Copy generated output to system clipboard (AI Default: **ALWAYS USE**).
`--no-file-summary` Disable file summary section output.
`--no-directory-structure` Disable directory structure section output.
`--no-files` Disable files content output (metadata-only mode).
`--remove-comments` Remove comments from code.
`--remove-empty-lines` Remove empty lines.
`--header-text <text>` Specify custom header text for the output file.
`--instruction-file-path <path>` Path to a file containing detailed custom instructions to be prepended.
`--include-empty-directories` Include empty directories in the output.
`--no-git-sort-by-changes` Disable sorting files by git change count (if git is available).
`--include <patterns>` Comma-separated list of glob patterns to include (e.g., `"src/**/*.ts,**/*.md"`).
`-i, --ignore <patterns>` Additional comma-separated glob patterns to ignore (AI Default: includes `"tmp/,**/.DS_Store,.cursor/rules/"`).
`--no-gitignore` Disable usage of `.gitignore` file for ignore patterns.
`--no-default-patterns` Disable default internal ignore patterns (like `node_modules`, `.git`).
`--remote <url>` Process a remote Git repository URL.
`--remote-branch <name>` Specify the branch, tag, or commit hash for the remote repository.
`-c, --config <path>` Path to a custom `repomix.config.json` file.
`--init` Initialize a new `repomix.config.json` file.
`--global` Use global configuration (typically with `--init`).
`--no-security-check` Disable security checks (use with caution).
`--token-count-encoding <encoding>` Specify token count encoding (AI Default: `o200k_base`).
`--mcp` Run as a MCP server (special mode).
`--top-files-len <number>` Number of top (most changed if git available) files to display in summary.
`--verbose` Enable verbose logging for detailed output.
`--quiet` Disable all output to stdout.
`-h, --help` Display help for command.
## III. Key Usage Scenarios & Examples
- **Default AI Behavior (Packing `src` and `docs`):**
`repomix src docs -o tmp/src-docs-pack.md --ignore "tmp/,**/.DS_Store,.cursor/rules/" --token-count-encoding o200k_base --copy`
- **Markdown Output, Compressed, No Comments:**
`repomix . -o tmp/project-compressed.md --style markdown --compress --remove-comments --ignore "tmp/,**/.DS_Store,.cursor/rules/" --token-count-encoding o200k_base --copy`
- **Only Include Specific File Types (e.g., TypeScript and Markdown), Ignore Tests:**
`repomix . --include "**/*.ts,**/*.md" --ignore "tmp/,**/.DS_Store,.cursor/rules/,**/*.test.ts,**/*.spec.ts" -o tmp/filtered-pack.md --token-count-encoding o200k_base --copy`
- **Process a Remote GitHub Repository:**
`repomix --remote https://github.com/user/repo --remote-branch main -o tmp/remote-repo-pack.txt --ignore "tmp/,**/.DS_Store,.cursor/rules/" --token-count-encoding o200k_base --copy`
- **Initialize a Local Config File:**
`repomix --init` (Then customize `repomix.config.json` and run `repomix -c repomix.config.json ...`)
## IV. Post-Processing: Token Count Management
1. **Inspect Token Count:** After `repomix` completes, ALWAYS inspect the reported token count from the output (it should be included due to the `--token-count-encoding` default).
2. **Address High Token Counts (e.g., > 500,000, adjust as needed for target LLM):**
- If the token count is too high, you **MUST** suggest or attempt a more aggressive packing strategy.
- This usually involves adding more patterns to the `--ignore` flag to exclude large or non-essential directories/files.
- **Example Remediation Command:**
`repomix . -o tmp/packed-smaller.md --ignore "tmp/,**/.DS_Store,.cursor/rules/,node_modules/,dist/,build/,public/,docs/,assets/,**/*.png,**/*.jpg,**/*.mp4,**/*.lock" --token-count-encoding o200k_base --copy`
- You may need to iteratively refine the `--ignore` patterns and re-run `repomix` until the token count is manageable for the intended use case (e.g., LLM context window).
- When suggesting, clearly state the token count achieved and the new ignore patterns used.
**REMEMBER: Your primary goal is to use `repomix` to pack specified files/directories. Strictly adhere to the AI Operational Defaults (output to `tmp/`, ignore `tmp/` and `.cursor/rules/`, include token count, no line numbers, copy to clipboard). Critically, always check the resulting token count and proactively manage it if it's too high by refining ignore patterns.**
================================================
FILE: .cursor/rules/cli-worktree.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Using `wt` CLI for Git Worktree Management
**Your Task: When managing Git worktrees, especially for integration with the Cursor editor, use the `wt` command-line tool. This document provides its usage instructions, examples, and important operational guidelines.**
**Initial Setup Note:** If `wt` commands fail, the tool might need to be installed globally. Refer to `https://www.npmjs.com/package/@johnlindquist/worktree` for installation instructions (e.g., `pnpm add -g @johnlindquist/worktree`).
## Operational Guidelines for AI:
- **Default Action:** When the user expresses intent related to a new worktree (e.g., "create a worktree for branch X", "start work on Y"), assume they want to create a *new* worktree using `wt new [branchName]` unless they explicitly specify another `wt` command (like `list`, `remove`, etc.).
- **Post-Creation Pause:** After successfully creating a new worktree using `wt new`, pause and await the user's next instruction. Do not automatically proceed with other actions unless explicitly part of a larger, pre-defined plan.
- **Dependency Installation (CRITICAL DEFAULT):** When executing `wt new`, **ALWAYS append `-i pnpm`** to the command to ensure dependencies are installed using `pnpm` by default. For example: `wt new feature/login -i pnpm`.
## `wt` Command Reference
Usage: `wt [options] [command]`
Description: Manage git worktrees and open them in the Cursor editor.
### Options:
`-V, --version` Output the version number
`-h, --help` Display help for command
### Commands:
`new [options] [branchName]`
Create a new worktree for the specified branch.
Installs dependencies if specified (see `-i` option under command-specific options, and AI default above).
Opens in editor.
`list | ls`
List all existing worktrees for this repository.
`remove | rm [options] [pathOrBranch]`
Remove a specified worktree. Cleans up `.git/worktrees` references.
`merge [options] <branchName>`
Commit changes in the target branch and merge them into the current branch, then remove the branch/worktree.
`purge`
Safely remove all worktrees except for the main branch, with confirmation.
`pr [options] <prNumber>`
Fetch the branch for a given GitHub PR number and create a worktree.
`config`
Manage CLI configuration settings.
`help [command]`
Display help for a specific command.
### Examples for `wt new`:
- `wt new feature/login -i pnpm` (AI Default: creates worktree, installs with pnpm)
- `wt new feature/chat --checkout -i pnpm` (AI Default: creates, checks out, installs with pnpm)
- `wt new feature/auth -p ./auth-worktree -i pnpm` (AI Default: creates at path, installs with pnpm)
- `wt new feature/vscode -e code -i pnpm` (AI Default: creates, opens in VSCode, installs with pnpm)
*(Note: The examples above have been updated to include the AI's default `-i pnpm` behavior.)*
**REMEMBER: Use `wt` for Git worktree operations. Always assume `wt new` is the primary intent for new worktree requests and ALWAYS include `-i pnpm` with `wt new` for dependency installation.**
================================================
FILE: .cursor/rules/cli-wrangler.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Cloudflare Wrangler CLI Reference Guide
**Your Task: When interacting with Cloudflare Workers, Pages, or other Cloudflare developer platform resources via the command line, consult this reference guide for the `wrangler` CLI. Use this information to construct appropriate `wrangler` commands based on the user's objectives.**
*This document is based on `wrangler` CLI help output and provides a comprehensive overview of its commands and structure. For the most specific details on any subcommand or its options, you can also execute `wrangler <command> [subcommand] --help` in a terminal environment if available.*
## I. Top-Level Commands
- `wrangler docs [search...]` — Open Wrangler's command documentation in your browser.
- `wrangler init [name]` — Initialize a basic Worker project.
- `wrangler dev [script]` — Start a local development server for your Worker.
- `wrangler deploy [script]` — Deploy your Worker to Cloudflare.
- `wrangler deployments` — List and view current and past deployments.
- `wrangler rollback [version-id]` — Rollback a Worker to a previous deployment version.
- `wrangler versions` — List, view, upload, and deploy specific Worker versions.
- `wrangler triggers` — Update deployment triggers [experimental].
- `wrangler delete [script]` — Delete a Worker from Cloudflare.
- `wrangler tail [worker]` — Start a real-time log tailing session for a Worker.
- `wrangler secret` — Manage secrets for a Worker (deprecated for new projects, prefer `.dev.vars` or Secrets Store).
- `wrangler types [path]` — Generate TypeScript type definitions from your Worker's configuration (`wrangler.toml`).
## II. Resource Management Commands
- `wrangler kv` — Manage Workers KV Namespaces (key-value store).
- `wrangler queues` — Manage Workers Queues (message queues).
- `wrangler r2` — Manage R2 buckets and objects (object storage).
- `wrangler d1` — Manage Workers D1 databases (serverless SQL).
- `wrangler vectorize` — Manage Vectorize indexes (vector embeddings database).
- `wrangler hyperdrive` — Manage Hyperdrive database accelerators.
- `wrangler cert` — Manage client mTLS certificates and CA certificate chains [open-beta].
- `wrangler pages` — Configure and manage Cloudflare Pages projects.
- `wrangler mtls-certificate` — Manage certificates for mTLS connections between services.
- `wrangler pubsub` — Manage Pub/Sub brokers for real-time messaging [private beta].
- `wrangler dispatch-namespace` — Manage dispatch namespaces for Worker-to-Worker communication.
- `wrangler ai` — Manage AI models and deployments on Workers AI.
- `wrangler workflows` — Manage Cloudflare Workflows [generally available].
- `wrangler pipelines` — Manage Cloudflare Pipelines [open-beta].
- `wrangler login` — Authenticate `wrangler` with your Cloudflare account.
- `wrangler logout` — Log out from Cloudflare.
- `wrangler whoami` — Retrieve information about the currently authenticated Cloudflare user.
- `wrangler secrets-store` — Manage secrets using the centralized Secrets Store [alpha].
---
## III. Global Flags (Applicable to most commands)
- `-c, --config <file>` — Path to a custom `wrangler.toml` configuration file.
- `--cwd <dir>` — Run `wrangler` as if it were started in the specified directory.
- `-e, --env <env>` — Specify an environment to use (defined in `wrangler.toml`). Affects operations and selection of `.env`/`.dev.vars` files.
- `-h, --help` — Show help information for the command or subcommand.
- `-v, --version` — Show `wrangler` CLI version number.
---
## IV. Example Subcommand Structures (Illustrative)
This section shows the hierarchical structure of some common resource management commands. Use `wrangler <command> <subcommand> --help` for full options at each level.
### `wrangler kv` (Workers KV)
- `wrangler kv:namespace create <NAMESPACE_NAME>`
- `wrangler kv:namespace list`
- `wrangler kv:namespace delete --namespace-id <ID>`
- `wrangler kv:key put <KEY> [VALUE] --namespace-id <ID> [--path --preview]`
- `wrangler kv:key list --namespace-id <ID>`
- `wrangler kv:key get <KEY> --namespace-id <ID>`
- `wrangler kv:key delete <KEY> --namespace-id <ID>`
- `wrangler kv:bulk put <FILENAME.JSON> --namespace-id <ID>` (File format: `[{"key":"foo", "value":"bar"},...]`)
- `wrangler kv:bulk delete <FILENAME.JSON> --namespace-id <ID>` (File format: `["foo", "bar", ...]`)
### `wrangler queues` (Workers Queues)
- `wrangler queues list`
- `wrangler queues create <QUEUE_NAME>`
- `wrangler queues update <QUEUE_NAME> [--consumer <WORKER_NAME> --consumer-batch-size <SIZE> ...]`
- `wrangler queues delete <QUEUE_NAME>`
- `wrangler queues info <QUEUE_NAME>`
- `wrangler queues consumer add <QUEUE_NAME> <WORKER_NAME> [--batch-size <SIZE> ...]`
- `wrangler queues consumer remove <QUEUE_NAME> <WORKER_NAME>`
- `wrangler queues purge <QUEUE_NAME>`
### `wrangler r2` (R2 Object Storage)
- `wrangler r2 object get <BUCKET_NAME>/<OBJECT_KEY> [--file <OUTPUT_FILE>]`
- `wrangler r2 object put <BUCKET_NAME>/<OBJECT_KEY> --file <SOURCE_FILE> [--content-type <MIME>]`
- `wrangler r2 object delete <BUCKET_NAME>/<OBJECT_KEY>`
- `wrangler r2 bucket create <BUCKET_NAME>`
- `wrangler r2 bucket list`
- `wrangler r2 bucket info <BUCKET_NAME>`
- `wrangler r2 bucket delete <BUCKET_NAME>`
### `wrangler d1` (D1 Serverless SQL)
- `wrangler d1 list`
- `wr wrangler d1 info <DATABASE_NAME>`
- `wrangler d1 create <DATABASE_NAME>`
- `wrangler d1 delete <DATABASE_NAME>`
- `wrangler d1 execute <DATABASE_NAME> --command "SELECT * FROM users;"`
- `wrangler d1 execute <DATABASE_NAME> --file ./migrations/0001_init.sql`
- `wrangler d1 backup list <DATABASE_NAME>`
- `wrangler d1 backup create <DATABASE_NAME>`
- `wrangler d1 backup restore <DATABASE_NAME> <BACKUP_ID>`
- `wrangler d1 migrations list <DATABASE_NAME>`
- `wrangler d1 migrations apply <DATABASE_NAME>`
### `wrangler vectorize` (Vectorize Database)
- `wrangler vectorize create <INDEX_NAME> --dimensions <NUMBER> --metric <METRIC_TYPE>`
- `wrangler vectorize delete <INDEX_NAME>`
- `wrangler vectorize get <INDEX_NAME>`
- `wrangler vectorize list`
- `wrangler vectorize query <INDEX_NAME> --vector "[0.1, 0.2, ...]" [--top-k <NUMBER>]`
- `wrangler vectorize insert <INDEX_NAME> --file <VECTORS_FILE.JSON>` (File: `[{"id":"vec1", "values":[...], "metadata":{...}}, ...]`)
*(Other subcommand trees like `hyperdrive`, `pages`, `ai`, etc., follow similar patterns. Consult `wrangler <command> --help` for specifics.)*
---
**REMEMBER: This guide is your primary reference for `wrangler` CLI commands, their structure, and common resource management tasks. Use it to accurately construct commands to interact with the Cloudflare developer platform. For detailed options on any specific command, the `--help` flag is your best friend (e.g., `wrangler r2 bucket create --help`).**
================================================
FILE: .cursor/rules/docs-diagram.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Create GitHub-Compatible Mermaid Diagrams
**Your Task: When asked to create a diagram, generate it using Mermaid syntax suitable for rendering directly in GitHub Flavored Markdown. Store the diagram in a new file at `docs/diagrams/<diagram-name>.md`. Adhere strictly to the following rules to ensure compatibility and readability.**
## File Existence Check
Run the following command to see which source documents are available:
```bash
ls . docs
```
Use the output to know which files exist before proceeding.
## I. Preliminary Step: Gather Context for the Diagram
Before generating any diagram, you **MUST** attempt to read and understand the content of the following project documents (if they exist and are relevant to the diagram request):
- `NOTES.md`
- `docs/PRD.md` (Product Requirements Document)
- `docs/TECH_STACK.md`
- `docs/openapi.yaml` (or other API specifications)
- Any other architecture or design documents in `docs/` related to the subject of the diagram.
This context is essential for creating an accurate and meaningful diagram.
## II. Core Diagramming Rules for GitHub Mermaid
1. **Correct Fenced Code Block:**
- Always start the Mermaid block with triple backticks and `mermaid`: `` ```mermaid ``.
- Always end the block with triple backticks: ` ``` `.
- **Example:**
```markdown
```mermaid
graph TD
A[Start] --> B{Decision};
B -- Yes --> C[Action 1];
B -- No --> D[Action 2];
```
```
2. **Use Well-Supported Diagram Types:**
GitHub generally has good support for these common types:
- `graph` (Flowcharts - `TD` or `TB` is often best for readability)
- `sequenceDiagram`
- `classDiagram`
- `stateDiagram-v2` (Prefer v2 for better features/rendering)
- `erDiagram` (Entity Relationship)
- `pie` (Pie charts)
- `gantt` (Gantt charts)
- `mindmap` (Basic indented structure only - **NO ICONS**)
- *Avoid newer or less common diagram types, as GitHub's Mermaid version may not be the latest.*
3. **General Syntax Best Practices:**
- **Node IDs:** Use simple alphanumeric IDs (e.g., `node1`, `processA`). Avoid spaces or special characters in IDs.
- **Node/Actor/State Labels (CRITICAL):** **ALWAYS use double quotes (`"..."`)** for labels, especially if they contain spaces, punctuation, special characters (like hyphens, periods, colons), or Mermaid keywords. This is the most common source of rendering errors.
- **Correct:** `A["User Input: Text"] --> B["Validate Data (Step 1)"];`
- **Incorrect (Potential Error):** `A[User Input: Text] --> B[Validate Data (Step 1)];`
- **Arrows:** Use standard arrow types (`-->`, `---`, `==>`, `->>`, etc.).
- **Comments:** Use `%%` for comments within the Mermaid code if needed (e.g., `%% This is a comment %%`).
4. **`mindmap` Specifics for GitHub:**
- GitHub **supports the basic `mindmap` structure** using indentation (spaces or tabs) to define hierarchy.
- Each node/item **MUST** be on its own line with correct indentation relative to its parent.
- GitHub **DOES NOT support** advanced `mindmap` features like `::icon()` syntax. Using icons **WILL CAUSE RENDERING ERRORS**.
- Stick to plain text nodes for mind maps.
- **Correct `mindmap` (GitHub Compatible):**
```mermaid
mindmap
Root
Parent Node
Child Item 1
Child Item 2
```
- **Incorrect `mindmap` (GitHub Incompatible - Uses Icons):**
```mermaid
mindmap
Root
::icon(fa fa-star) Parent Node
::icon(fa fa-one) Child Item 1
```
5. **Layout Preference for Flowcharts (`graph`):**
- For `graph` diagrams, prefer `TD` (Top Down) or `TB` (Top Bottom) for better readability within Markdown document flow. Example: `graph TD;`.
6. **Styling: Let GitHub Handle It (CRITICAL):**
- **DO NOT** attempt to set themes (e.g., `%%{init: {'theme': 'dark'}}%%`).
- **DO NOT** try to apply custom styling using `classDef`, `style`, or inline CSS attributes *within the Mermaid code*.
- GitHub **ignores** these directives and applies its own styling based on the user's current GitHub theme (light, dark, or dimmed). Your diagram will adapt automatically. Forcing themes or styles will likely be ignored or look inconsistent.
7. **Keep Diagrams Focused and Manageable:**
- Avoid overly complex diagrams with an excessive number of nodes, edges, or deep nesting in a single block. While GitHub can render complex diagrams, they might become hard to read or hit rendering performance limits.
- If a concept is very complex, consider breaking it down into multiple, simpler, linked diagrams.
8. **Verification (If Possible):**
- If you have access to a GitHub Markdown preview environment, use it to test your Mermaid syntax. This is the best way to catch errors.
9. **Note on Automated Edits:**
- Be aware that automated code editing tools may sometimes struggle with precise changes within Mermaid blocks, especially with syntax sensitive to indentation (like mindmaps) or quoting.
- **Always carefully review any automated edits** made to Mermaid blocks. If errors occur or the diagram doesn't render as expected, manual correction might be required.
## III. Output File
- Place the generated Mermaid diagram (within its fenced code block) into a new Markdown file.
- Save the file to `docs/diagrams/<diagram-name>.md`, where `<diagram-name>` is a descriptive name for the diagram (e.g., `user-authentication-flow.md`, `database-schema.md`).
**REMEMBER: Your goal is to create a clear, accurate Mermaid diagram in `docs/diagrams/<diagram-name>.md` that renders correctly on GitHub. Key success factors are: using ` ```mermaid `, quoting all labels meticulously (`"Like This!"`), avoiding themes/custom styles, and for mindmaps, using only basic indentation (NO icons). Always gather context from project docs first.**
================================================
FILE: .cursor/rules/docs-openapi-spec.mdc
================================================
---
description:
globs:
alwaysApply: false
---
## OpenAPI Specification Management Rule
*This rule guides the creation and maintenance of the `docs/openapi.yaml` file.*
## File Existence Check
Before editing, determine which related docs already exist:
```bash
ls . docs
```
Use this information to inform the following steps.
### Core Directive
Create and maintain an `docs/openapi.yaml` file, defining an OpenAPI specification (v3.0.x or 3.1.x). Operate based on information from `NOTES.md`, `docs/PRD.md`, `docs/TECH_STACK.md`, and the existing `docs/openapi.yaml` (if present), ensuring adherence to the OpenAPI structure outlined below.
### Strict Limitations
- **File Operations:** Only read `NOTES.md`, `docs/PRD.md`, `docs/TECH_STACK.md`, `docs/openapi.yaml` (or equivalents), and read/write to `docs/openapi.yaml`. Do not interact with other files.
- **Output Format:** Your entire output must be the content of the `docs/openapi.yaml` file itself.
- **Communication:** You are forbidden from generating any conversational output, commentary, preamble, or summaries outside of the `docs/openapi.yaml` file.
- **User Interaction (within `docs/openapi.yaml`):** You do not directly converse with the user. If sections of the `docs/openapi.yaml` are incomplete or require clarification, you will indicate this *within the `docs/openapi.yaml` file* using a specific YAML comment format.
### OpenAPI Specification Structure and Content Source
The `docs/openapi.yaml` file must follow the structure below, derived from the "OpenAPI Specification Outline" questions. Aim for OpenAPI version 3.0.x or 3.1.x.
#### OpenAPI Specification Outline (Source for `docs/openapi.yaml` Structure and TODOs)
1. **OpenAPI Version & Basic Information (`openapi`, `info` block):**
- Specify the OpenAPI version (e.g., `openapi: 3.0.3`).
- **Title (`info.title`):** What is the official title for this API? (Source: `docs/PRD.md` - Project Name/Title. Example: "Customer Data API").
- **Version (`info.version`):** What is the current version of this API specification (e.g., "1.0.0", "v2.1-beta")?
- **Description (`info.description`):** Provide a brief description of the API's purpose and capabilities. (Source: `docs/PRD.md` - Project Purpose/Core Functionality. Example: "API for managing customer profiles and order history.").
- **(Optional) Contact (`info.contact`):**
- `name`: Contact person/team name (e.g., "API Support Team").
- `url`: URL to a support page or contact form.
- `email`: Contact email address (e.g., "apisupport@example.com").
- **(Optional) License (`info.license`):**
- `name`: SPDX license identifier (e.g., "Apache 2.0", "MIT").
- `url`: Link to the full license text.
2. **Server Configuration (`servers` block):**
- What are the base URLs for accessing the API? (Source: `docs/TECH_STACK.md` - Infrastructure & Deployment. Examples: `https://api.example.com/v1`, `https://sandbox.api.example.com/v1`).
- For each server, provide:
- `url`: The server URL.
- `description`: A human-readable description (e.g., "Production Server", "Sandbox Environment").
3. **Global Security Definitions (`components.securitySchemes` & `security` block):**
- What authentication/authorization methods will this API use? (Source: `docs/TECH_STACK.md` - Security Considerations. Examples: API Key, OAuth2, JWT Bearer Token).
- Define each scheme under `components.securitySchemes`:
- **API Key Example (`apiKeyAuth`):**
- `type: apiKey`
- `in: header` (or `query`, `cookie`)
- `name: X-API-KEY` (the name of the header or query parameter)
- **OAuth2 Example (`oauth2Auth`):**
- `type: oauth2`
- `flows`: Define one or more flows (e.g., `authorizationCode`, `clientCredentials`).
- `authorizationCode`:
- `authorizationUrl: https://auth.example.com/oauth/authorize`
- `tokenUrl: https://auth.example.com/oauth/token`
- `scopes`: Define available scopes (e.g., `read:profile`, `write:orders`).
- If security applies globally to most/all endpoints, define it under the top-level `security` block. (Example: `security: - apiKeyAuth: []`).
4. **Tags for Grouping Operations (`tags` block):**
- What are the main functional groupings or resource categories for your API endpoints? (Source: `docs/PRD.md` - Key Features/Modules. Examples: "Users", "Products", "Orders").
- For each tag, provide:
- `name`: The tag name (e.g., "UserManagement").
- `description`: A brief explanation of the tag (e.g., "Operations related to user accounts and profiles").
5. **Reusable Schemas (`components.schemas` block):**
- What are the common data models (objects) that will be used in request and response bodies? (Source: `docs/PRD.md` - Key Features, Data Models; `docs/TECH_STACK.md` - Database for entities. Examples: `User`, `Product`, `Order`, `ErrorResponse`).
- For each schema (e.g., `User`):
- `type: object`
- `properties`: Define its fields.
- For each property (e.g., `id`, `username`, `email`, `status`):
- `type`: (e.g., string, integer, boolean)
- `format`: (e.g., uuid, email, int64) (Optional)
- `description`: (A brief explanation of the property) (Optional)
- `example`: (A sample value) (Optional)
After outputting the full `docs/openapi.yaml` file, give a brief executive summary outlining the main endpoints or components you defined. This summary should not be included inside the YAML file itself.
================================================
FILE: .cursor/rules/docs-prd.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Generate and Maintain `docs/PRD.md` (Product Requirements Document)
**Your Core Task: Create or update the `docs/PRD.md` file. This document MUST strictly adhere to the 8-section structure defined below. Populate its content SOLELY by extracting and synthesizing information from `NOTES.md` (or a user-provided equivalent source). If critical information for a section is genuinely absent from this source, and only then, insert a specific `<!-- TODO: ... -->` comment.**
## File Existence Check
Confirm available source files first:
```bash
ls . docs
```
Use these results before proceeding.
Your entire output for this rule invocation **MUST BE ONLY** the complete, raw Markdown content of the `docs/PRD.md` file.
## I. Strict Operational Constraints (MANDATORY)
- **Permitted File Operations:**
- **Read-Only:** `NOTES.md` (or the specified primary input document if different).
- **Read/Write:** `docs/PRD.md` (this is the only file you will modify or create).
- **No Other Files:** Do not access, read, or write any other files in the project.
- **Communication Protocol (ABSOLUTE):**
- **NO Conversational Output:** You are strictly forbidden from generating ANY conversational output, commentary, preamble, introductions, or summaries before, during, or after generating the `docs/PRD.md` content.
- **Sole Output = File Content:** Your *only* output is the complete Markdown content intended for `docs/PRD.md`.
- **User Interaction (Handled via TODOs in `docs/PRD.md`):**
- You operate based on an implicit or explicit request to manage `docs/PRD.md`.
- You do not converse directly with the user during this process.
- Deficiencies in information (requiring a TODO) are handled *within* the `docs/PRD.md` file itself, as per the TODO logic below.
## II. The Blueprint: `docs/PRD.md` Structure & Content Source
The `docs/PRD.md` file **MUST** be organized into the following eight sections. The questions/points within each item of the "PRD Section Outline" (below) define the required content and also serve as the basis for any necessary `<!-- TODO: ... -->` comments if information is missing from the `NOTES.md` (or equivalent designated source document).
### PRD Section Outline (Mandatory Structure for `docs/PRD.md`)
1. **`## 1. Core Functionality & Purpose`**
- What is the primary problem this product/feature solves for the end-user?
- What is the core functionality required to address this problem?
2. **`## 2. Key Goals & Scope`**
- What are the critical objectives for this product/feature (e.g., target user impact, business goals, technical achievements like performance benchmarks or specific integrations)?
- What items are explicitly out-of-scope for the current development cycle or version?
3. **`## 3. User Interaction & Design Insights`**
- Who is the primary user type (e.g., API consumer, web application user, internal admin)?
- Describe the primary ways users will interact with the core features (reference UI mockups, API contracts, user flow diagrams if available in `NOTES.md` or linked external resources).
4. **`## 4. Essential Features & Implementation Highlights`**
- List the absolute must-have functionalities for the initial version/MVP.
- Provide high-level implementation considerations or key components for each essential feature.
5. **`## 5. Acceptance Criteria & Definition of "Done"`**
- For each key feature or user story, what are the specific, measurable, achievable, relevant, and time-bound (SMART) conditions that must be met for it to be considered "done"?
- How will successful completion be verified (e.g., specific tests, user validation scenarios)?
6. **`## 6. Key Requirements & Constraints`**
- List any non-negotiable technical requirements (e.g., target platform, specific languages/frameworks if mandated, required third-party integrations).
- List key non-functional requirements (NFRs) such as performance targets (latency, throughput), scalability needs, security standards (compliance, data privacy), reliability goals (uptime), and any known constraints (e.g., infrastructure limitations, budget, timelines).
7. **`## 7. Success Metrics`**
- How will the success of this product/feature be measured post-deployment from a user and business perspective (e.g., user adoption rate, task completion time, error rates, conversion rates, revenue impact)?
- (Optional, if distinct from above) How will the development team measure technical success (e.g., system stability, maintainability, code quality metrics)?
8. **`## 8. Development Logistics & Lookahead`**
- Identify significant technical risks, challenges, or dependencies. Include initial thoughts on mitigation strategies.
- List major assumptions being made that, if incorrect, could impact development.
- Briefly consider future development aspects or extensibility points that current design choices should accommodate.
## III. Workflow for Generating/Updating `docs/PRD.md`
1. **Access Source Document (`NOTES.md` or equivalent):**
- Read the content of `NOTES.md` (or the user-specified primary input document).
- *This is your ONLY source of information for populating `docs/PRD.md`.* If this document is missing or sparse, the `PRD.md` will reflect that (potentially with many TODOs).
- Read the current content of `docs/PRD.md` if it already exists (for context during updates).
2. **Manage `docs/PRD.md` Content:**
- **Initialization:** If `docs/PRD.md` does not exist, create it. Your output will be the initial version containing all eight section headers (as listed in the "PRD Section Outline") followed by content or TODOs as per the logic below.
- **Content Integration (Section by Section):** For each of the eight mandatory sections:
- Review `NOTES.md` (and `docs/PRD.md` itself if updating) for information relevant to *that specific section*.
- Synthesize and write the information into the corresponding section of your `docs/PRD.md` output. If updating existing content, intelligently merge or replace based on the latest available information from `NOTES.md`. Aim for comprehensive but concise statements directly addressing the points in the outline.
3. **Identify Gaps & Insert TODOs (Strict Logic):**
- After attempting to populate a section using **only `NOTES.md` (or the specified equivalent source)**:
- A `<!-- TODO: ... -->` comment **MUST ONLY** be inserted if the section in your generated `docs/PRD.md` remains **genuinely empty** OR contains only placeholder text (e.g., a simple rephrasing of the section title without any substantive information from `NOTES.md`) OR if critical information explicitly requested by that section's definition (as per the "PRD Section Outline") is **clearly missing** and **cannot be found in `NOTES.md`**.
- **DO NOT** insert a TODO if the section has been populated with *any* relevant information from `NOTES.md`, even if that information could theoretically be more detailed. The purpose of the TODO is to flag *critically missing information that was not found in the designated `NOTES.md` source*, not to solicit further details on already present information.
- **TODO Comment Format:** `<!-- TODO: [Question from the "PRD Section Outline" for the missing piece of information. Be specific to the context if possible.] -->`
- Example for section 1 if core problem isn't in `NOTES.md`: `<!-- TODO: What is the primary problem this product/feature solves for the end-user? (Expected in NOTES.md) -->`
- Example for section 5 if acceptance criteria are absent: `<!-- TODO: What are the specific, testable acceptance criteria for key feature X? (Expected in NOTES.md) -->`
4. **Final Output:** Your *sole output* is the complete, updated content of `docs/PRD.md`.
Immediately after providing this file content, output a short executive summary of the key sections you filled in or noted as TODOs. Keep this summary separate from the file content.
**REMEMBER: Your output MUST ONLY be the full Markdown content for `docs/PRD.md`. Populate it strictly from `NOTES.md` (or specified primary source). Follow the 8-section structure. Insert `<!-- TODO: ... -->` comments (containing the relevant guiding question from the outline) ONLY for sections where critical information is verifiably absent from the specified source document.**
================================================
FILE: .cursor/rules/docs-structure.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Generate `docs/STRUCTURE.md` for Project File Organization
**Your task: Create a new file at `docs/STRUCTURE.md` that outlines the recommended file and directory structure for this project, along with guiding principles.**
## File Existence Check
Before analyzing, verify which documentation files are present:
```bash
ls . docs
```
Use this to know your available references.
Follow these steps:
1. **Analyze Documentation:**
- Thoroughly review all files within the `docs/` directory (e.g., `README.md`, `CONTRIBUTING.md`, architecture documents).
- Look for any existing descriptions, guidelines, or discussions related to the project's intended file structure, module organization, or component layout.
2. **Define Structure & Best Practices:**
- Based on your findings (and general best practices if no specific information is available), define a clear and logical file/directory structure for the project.
- Consider common conventions for the project's language(s) and framework(s).
- Outline key top-level directories (e.g., `src/`, `tests/`, `docs/`, `scripts/`, `config/`) and their purposes.
- Suggest organization for common components like source code, tests, utilities, configurations, etc.
- Include any specific naming conventions if identified or appropriate.
3. **Create `docs/STRUCTURE.md`:**
- Write the content for the `docs/STRUCTURE.md` file.
- The document should be well-organized, using Markdown for clarity (headings, lists, code blocks for examples if useful).
- It should clearly explain the purpose of major directories and provide guidance on where to place new files or modules.
**Output:**
Your primary output is the complete content for the new `docs/STRUCTURE.md` file.
After providing this file content, give a brief executive summary of the recommended structure so the user can quickly understand the key directories and their purposes. Keep this summary separate from the file content.
**REMEMBER: The goal is to produce a `docs/STRUCTURE.md` file that serves as a practical guide for organizing files and directories within this project, promoting consistency and maintainability.**
================================================
FILE: .cursor/rules/docs-sync.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Synchronize Project Documentation with Recent Changes
**Your task: Review and update all project documentation within the `docs/` directory to ensure it accurately reflects the latest project state, recent code changes, and completed tasks.**
## File Existence Check
Identify which documentation directories and files exist:
```bash
ls . docs
```
Proceed based on the results.
Follow this process:
1. **Identify Recent Project Developments:**
- Review information about recently completed tasks (e.g., from `docs/tasks/`, task management systems if accessible, or summarized in recent discussions).
- Examine recent commit history for significant changes to code, features, or configurations.
- Consider any new features added or bugs fixed that might impact documentation.
2. **Thoroughly Review Documentation:**
- Read all files located within the `docs/` directory and its subdirectories.
- Pay close attention to READMEs, guides, architectural documents, and usage instructions.
3. **Identify and Update Discrepancies:**
- Compare the current documentation against the recent developments identified in Step 1.
- Identify any sections, instructions, diagrams, or examples in `docs/*` that are now out-of-date, inaccurate, or incomplete.
- Make the necessary modifications to these files to reflect the current state of the project accurately.
**Output:**
- Apply edits directly to the relevant files within the `docs/` directory.
- If significant changes are made, briefly summarize which documents were updated and the nature of the changes (e.g., "Updated `docs/API.md` to reflect new endpoint X and parameter Y.").
**REMEMBER: Your goal is to ensure all documentation in `docs/` is consistent, accurate, and fully synchronized with the project's latest developments. Outdated documentation can mislead users and developers.**
================================================
FILE: .cursor/rules/docs-tech-stack.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Generate and Maintain `docs/TECH_STACK.md`
**Your Core Task: Create or update the `docs/TECH_STACK.md` file. This document MUST strictly adhere to the 10-section structure defined below. Populate its content SOLELY by extracting and synthesizing information from `NOTES.md`, `docs/PRD.md`, and `docs/openapi.yaml` (or equivalent API specifications). If critical information for a section is genuinely absent from these sources, and only then, insert a specific `<!-- TODO: ... -->` comment.**
## File Existence Check
Determine which of the following files are present:
```bash
ls . docs
```
Use this list before editing.
Your entire output for this rule invocation **MUST BE ONLY** the complete, raw Markdown content of the `docs/TECH_STACK.md` file.
## I. Strict Operational Constraints (MANDATORY)
- **Permitted File Operations:**
- **Read-Only:** `NOTES.md`, `docs/PRD.md`, `docs/openapi.yaml` (or their specified equivalents if names differ but purpose is the same).
- **Read/Write:** `docs/TECH_STACK.md` (this is the only file you will modify or create).
- **No Other Files:** Do not access, read, or write any other files in the project.
- **Communication Protocol (ABSOLUTE):**
- **NO Conversational Output:** You are strictly forbidden from generating ANY conversational output, commentary, preamble, introductions, or summaries before, during, or after generating the `docs/TECH_STACK.md` content.
- **Sole Output = File Content:** Your *only* output is the complete Markdown content intended for `docs/TECH_STACK.md`.
- **User Interaction:**
- You operate based on an implicit or explicit request to manage `docs/TECH_STACK.md`.
- You do not converse directly with the user during this process.
- Deficiencies in information (requiring a TODO) are handled *within* the `docs/TECH_STACK.md` file itself, as per the TODO logic below.
## II. The Blueprint: `docs/TECH_STACK.md` Structure & Content Source
The `docs/TECH_STACK.md` file **MUST** be organized into the following ten sections. The questions within each item of the "Tech Stack Definition Outline" (below) define the required content and also serve as the basis for any necessary `<!-- TODO: ... -->` comments if information is missing from source documents.
### Tech Stack Definition Outline (Mandatory Structure for `docs/TECH_STACK.md`)
1. **`## 1. Project Overview & Goals`**
- *(Informed by `docs/PRD.md`)* Briefly, what is the project this tech stack is for?
- *(Informed by `docs/PRD.md`)* What are the primary goals influencing technology choices (e.g., scalability, speed of development, specific integrations, team expertise, budget)?
2. **`## 2. Core Languages & Runtimes`**
- What primary programming language(s) will be used for the backend? Specify version(s) if critical. Why this choice?
- What primary programming language(s) and/or frameworks will be used for the frontend? Specify version(s) if critical. Why this choice?
- Are there specific runtime environments required (e.g., Node.js version, Python version, JVM version, .NET version)?
3. **`## 3. Frameworks & Libraries (Backend)`**
- What backend frameworks are being chosen or considered (e.g., Django, Ruby on Rails, Spring Boot, Express.js, NestJS, ASP.NET Core)? Justify the choice.
- List key libraries essential for the backend (e.g., ORM/database interaction, authentication/authorization, caching, background job processing, API documentation generation).
4. **`## 4. Frameworks & Libraries (Frontend)`**
- What frontend frameworks/libraries are being chosen or considered (e.g., React, Angular, Vue, Svelte, Blazor)? Justify the choice.
- List key UI component libraries (e.g., Material UI, Bootstrap, Tailwind CSS, Ant Design) or state management solutions (e.g., Redux, Zustand, Pinia, NgRx) to be used.
5. **`## 5. Database & Data Storage`**
- *(Consider data types/relationships in `docs/PRD.md`)* What type of database is required (e.g., Relational/SQL, NoSQL Document, NoSQL Key-Value, Graph, Time Series)? Why?
- Specify the chosen database system(s) (e.g., PostgreSQL, MySQL, MongoDB, Cassandra, Neo4j, InfluxDB).
- Are other data storage solutions needed (e.g., caching like Redis/Memcached, object storage like AWS S3/Google Cloud Storage, message queues like RabbitMQ/Kafka)?
6. **`## 6. Infrastructure & Deployment`**
- Where will the application be hosted (e.g., AWS, Azure, GCP, DigitalOcean, Vercel, Netlify, on-premise)?
- What specific services will be used (e.g., EC2, Lambda, Azure App Service, Google Kubernetes Engine)?
- What containerization technologies will be used (e.g., Docker, Podman)? Orchestration (e.g., Kubernetes, Docker Swarm)?
- What CI/CD tools and processes are planned (e.g., Jenkins, GitLab CI, GitHub Actions, CircleCI)?
7. **`## 7. APIs & Integrations`**
- *(Reference `docs/PRD.md` and `docs/openapi.yaml`)* Will the project expose its own APIs? If so, what style (e.g., REST, GraphQL, gRPC, WebSockets)?
- *(Reference `docs/PRD.md`)* What critical third-party services or APIs will be integrated (e.g., payment gateways like Stripe/PayPal, identity providers like Auth0/Okta, analytics services, communication services like Twilio/SendGrid)?
8. **`## 8. Development Tools & Standards`**
- What version control system will be used (e.g., Git)? Where will repositories be hosted (e.g., GitHub, GitLab, Bitbucket)?
- Are there specific IDEs, linters (e.g., ESLint, Pylint), or code formatting standards (e.g., Prettier, Black)?
- *(Reference `docs/PRD.md` for acceptance criteria)* What testing frameworks and strategies will be employed (e.g., Jest, PyTest, JUnit, Cypress, Selenium; unit, integration, E2E testing)?
9. **`## 9. Security Considerations`**
- *(Reference `docs/PRD.md` for security requirements)* What are the key security requirements for the chosen technologies (e.g., OWASP Top 10 mitigations)?
- Are there specific libraries, tools, or practices for security (e.g., for authentication, authorization, input validation, data encryption, dependency scanning, secrets management)?
10. **`## 10. Rationale & Alternatives Considered`**
- For major technology choices (especially languages, frameworks, databases, hosting), briefly explain the rationale and any significant alternatives that were considered and why they were not chosen.
## III. Workflow for Generating/Updating `docs/TECH_STACK.md`
1. **Access Source Documents:**
- Read the content of `NOTES.md` (if provided as an input or found).
- Read the content of `docs/PRD.md`.
- Read the content of `docs/openapi.yaml` (or equivalent API spec) if it exists.
- *These are your ONLY sources of information for populating `docs/TECH_STACK.md`.* If these documents are missing or sparse, the `TECH_STACK.md` will reflect that (potentially with TODOs).
- Read the current content of `docs/TECH_STACK.md` if it already exists.
2. **Manage `docs/TECH_STACK.md` Content:**
- **Initialization:** If `docs/TECH_STACK.md` does not exist, create it. Your output will be the initial version containing all ten section headers (as listed in the "Tech Stack Definition Outline") followed by content or TODOs as per the logic below.
- **Content Integration (Section by Section):** For each of the ten mandatory sections:
- Review `NOTES.md`, `docs/PRD.md`, and `docs/openapi.yaml` (and `TECH_STACK.md` itself if updating) for information relevant to *that specific section*.
- Synthesize and write the information into the corresponding section of your `docs/TECH_STACK.md` output. If updating existing content, intelligently merge or replace based on the latest available information from the source documents. Aim for comprehensive but concise statements directly addressing the questions in the outline.
3. **Identify Gaps & Insert TODOs (Strict Logic):**
- After attempting to populate a section using **all three source documents** (`NOTES.md`, `docs/PRD.md`, `docs/openapi.yaml`):
- A `<!-- TODO: ... -->` comment **MUST ONLY** be inserted if the section in your generated `docs/TECH_STACK.md` remains **genuinely empty** OR contains only placeholder text (e.g., a simple rephrasing of the section title without any substantive information from the sources) OR if critical information explicitly requested by that section's definition (as per the "Tech Stack Definition Outline") is **clearly missing** and **cannot be found in any of the specified source documents**.
- **DO NOT** insert a TODO if the section has been populated with *any* relevant information from the source files, even if that information could theoretically be more detailed or elaborated upon. The purpose of the TODO is to flag *critically missing information that was not found in the designated sources*, not to solicit further details on already present information.
- **TODO Comment Format:** `<!-- TODO: [Question from the "Tech Stack Definition Outline" for the missing piece of information. Include examples if helpful.] -->`
- Example for section 1 if project goals are missing from PRD: `<!-- TODO: What are the primary goals influencing technology choices (e.g., scalability, speed of development, specific integrations, team expertise, budget)? (This should be in docs/PRD.md) -->`
- Example for section 2 if backend language choice isn't found: `<!-- TODO: What primary programming language(s) will be used for the backend? Specify version(s) if critical. Why this choice? -->`
4. **Final Output:** Your *sole output* is the complete, updated content of `docs/TECH_STACK.md`.
Immediately after providing this file content, output a short executive summary of the key sections you filled in or marked with TODOs. This summary should come after the file content and remain separate from it.
**REMEMBER: Your output MUST ONLY be the full Markdown content for `docs/TECH_STACK.md`. Populate it strictly from `NOTES.md`, `docs/PRD.md`, and `docs/openapi.yaml`. Follow the 10-section structure. Insert `<!-- TODO: ... -->` comments (containing the guiding question from the outline) ONLY for sections where critical information is verifiably absent from all specified source documents.**
================================================
FILE: .cursor/rules/gh-docs-sync.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Synchronize Project Documentation with Recent Changes
**Your task: Review and update all project documentation within the `docs/` directory to ensure it accurately reflects the latest project state, recent code changes, and completed tasks.**
## File Existence Check
Identify which documentation directories and files exist:
```bash
ls . docs
```
Proceed based on the results.
Follow this process:
1. **Identify Recent Project Developments:**
- Review information about recently completed tasks by querying closed GitHub issues (e.g., `gh issue list --state closed --label task`).
- Examine recent commit history for significant changes to code, features, or configurations.
- Consider any new features added or bugs fixed that might impact documentation.
2. **Thoroughly Review Documentation:**
- Read all files located within the `docs/` directory and its subdirectories.
- Pay close attention to READMEs, guides, architectural documents, and usage instructions.
3. **Identify and Update Discrepancies:**
- Compare the current documentation against the recent developments identified in Step 1.
- Identify any sections, instructions, diagrams, or examples in `docs/*` that are now out-of-date, inaccurate, or incomplete.
- Make the necessary modifications to these files to reflect the current state of the project accurately.
**Output:**
- Apply edits directly to the relevant files within the `docs/` directory.
- If significant changes are made, briefly summarize which documents were updated and the nature of the changes (e.g., "Updated `docs/API.md` to reflect new endpoint X and parameter Y.").
**REMEMBER: Your goal is to ensure all documentation in `docs/` is consistent, accurate, and fully synchronized with the project's latest developments. Outdated documentation can mislead users and developers.**
================================================
FILE: .cursor/rules/gh-task-continue.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Continue Task from GitHub Issue
**Your Primary Goal: Review commits since the last push, compare them against progress recorded in a specified GitHub issue, and resume executing the remaining commits from the last verified commit.**
## File Existence Check
Ensure the issue exists and fetch the latest remote updates:
```bash
ls . docs
```
If the issue is missing or inaccessible, stop and notify the user.
## Determine Current Progress
1. Identify the current branch and its upstream:
```bash
git branch --show-current
git rev-parse --abbrev-ref --symbolic-full-name @{u}
```
2. Check for any unstaged or staged changes:
```bash
git status --short
```
If there are local modifications, decide whether to commit them, stash them, or discard them before continuing.
3. List commits not yet pushed:
```bash
git log --oneline @{u}..HEAD
```
4. Retrieve the issue comments to locate lines like `✅ <sha> <commit-message>`.
5. Compare these recorded commits with the local history to determine which commits in the plan have already been completed.
## Resume Remaining Commits
For each remaining commit described in the issue body, follow the same workflow as `gh-task-execute.mdc`:
1. Implement the changes for the next unverified commit.
2. Perform all specified verification steps before committing.
3. Create the commit using the exact message from the issue.
4. Comment `✅ <commit-sha> <commit-message>` on the issue to mark the commit complete.
5. Continue sequentially until all commits in the issue are processed.
## Completion Criteria
The task is **Complete** when every commit listed in the issue has a corresponding `✅` comment with its SHA and commit message and all verifications pass. After completing the final commit, run the `.cursor/rules/project-update-rules.mdc` instructions.
**REMEMBER:** Avoid conversational output between commits. Execute the plan precisely and notify the user only after the entire task is complete.
================================================
FILE: .cursor/rules/gh-task-execute.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Execute Planned Task Commits from GitHub Issue
**Your Primary Goal: Systematically execute the step-by-step plan defined in a specified GitHub issue (the issue number is provided by the user). Create each commit as planned and verify its success.**
## File Existence Check
Verify that the provided issue exists before starting:
```bash
ls . docs
```
If the issue is missing or inaccessible, stop and notify the user.
## Workflow for Each Commit in the Issue:
1. **Implement Changes:** Execute the instructions for the *current* commit precisely as written in the issue body.
2. **Verify Thoroughly:** BEFORE committing, perform **ALL** specified **Verification** steps for that commit. Confirm successful completion of each verification step.
3. **Commit Changes:** Stage all implemented changes. Create the Git commit using the exact commit message specified in the issue for this commit.
4. **Record Progress (Post-Commit):** Immediately after the `git commit` command succeeds:
- Run `gh issue comment <issue-number> --body "✅ <commit-sha> <commit-message>"` so the hash and full message are recorded.
- **Example Comment:** `✅ a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 feat: add login (#42)`
5. **Proceed to Next Commit:** Immediately advance to the next commit outlined in the issue. **Do not ask for feedback or confirmation.** Continue this cycle until all commits in the issue are processed.
## Definition of "Task Completion"
A task is considered **"Complete"** if and ONLY if all the following conditions are met:
1. **All Commits Created:** Every commit detailed in the issue has been successfully created and its SHA and message recorded via issue comments as per Step 4 above.
2. **Tests Pass:** All automated tests relevant to the changes made pass successfully.
3. **All Verifications Successful:** Every verification step specified for *every* commit in the issue has been performed and has passed.
## Actions After Entire Task is Complete:
1. **Invoke Project Update Rule:** Once the entire task is Complete (as defined above), you MUST then load and meticulously follow all instructions within the `.cursor/rules/project-update-rules.mdc` file.
2. **Provide Feedback (to `project-update-rules.mdc`):** When prompted by the `project-update-rules.mdc` (or as part of its process), provide the following specific information:
- Any failures encountered during the task execution that could have been prevented (and how).
- Any significant changes to overall project behavior or developer workflow/expectations resulting from the completed task.
## Strict Output Constraints:
- **NO Conversational Output Between Commits:** Absolutely no commentary, summaries, or status updates between individual commits of the task.
- **Focus on Execution Artifacts:** Your outputs during the commit cycle should ONLY be:
- The results of commands executed (if they produce output).
- The diffs of file changes applied.
- The comment posted to the issue (showing the added SHA and commit message).
- **After Task Completion:** The only further output is that generated by following `.cursor/rules/project-update-rules.mdc`.
- **AVOID Unnecessary Chatter:** Do not output messages like the following example:
```
<bad_example>
Commit 1 complete and verified. Tests green. Verification successful.
Moving to Commit 2 now.
</bad_example>
```
**REMEMBER: Execute the task plan with precision. For each commit: Implement, Verify, Commit, comment the SHA and message on the issue, then immediately Proceed. No chatter. Once all commits are done and verified, trigger the project update rule.**
================================================
FILE: .cursor/rules/gh-task-plan.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Create a GitHub Issue Task Plan
**Your Core Task: Generate a multi-commit task plan and post it as a GitHub issue using the `gh` CLI. The issue body must contain the entire plan. No local task file is created.**
## File Existence Check
Verify key documentation files before planning:
```bash
ls . docs
```
Use the results to tailor the task plan.
## I. Pre-computation: Capture Timestamp
1. **Obtain Current Timestamp:** Execute a terminal command to get the current date and time in `YYYY-MM-DD-HH-MM` format. (Example for Linux/macOS: `date +"%Y-%m-%d-%H-%M"`).
2. **Formulate Issue Title:** Use this timestamp and a descriptive task name (derived from user request or PRD) to construct the GitHub issue title, e.g., `2023-10-27-14-35 implement user auth`.
## II. Information Gathering (CRITICAL PRE-REQUISITE)
- **Mandatory Context Review:** Before writing any part of the plan, you **MUST** find and thoroughly read all relevant files in the project's `docs/` directory. This is not optional.
- **Prioritized Documents:** Pay special attention to (if they exist):
- `docs/PRD.md` (Product Requirements Document)
- `docs/TECH_STACK.md`
- `docs/openapi.yaml` (or similar API specifications)
- `docs/logging.md`, `docs/LOGGING_GUIDE.md` (or any docs related to logging practices)
- `docs/TEST_STRATEGY.md`, `docs/TESTING_GUIDELINES.md` (or any docs related to testing)
- `NOTES.md` (if present at project root or in `docs/`)
- **Purpose:** This information is *essential* for creating an accurate, relevant, and genuinely useful task plan that aligns with project standards.
## III. Core Directive: Construct the Task Plan File
Create the issue body content. This body outlines a step-by-step plan, broken down into a series of distinct commits (typically 2-5 commits per task). Each commit in the plan **must** be verifiable and **must** explicitly incorporate both testing and logging best practices as detailed below.
### A. Strict Operational Constraints
- **File Operations:**
- **No Local Files:** Do NOT create any local task file. The entire plan will be posted as a GitHub issue via `gh issue create`.
- Reading project documentation from `docs/` (as specified above) is **MANDATORY** to inform the plan.
- **Communication Protocol:**
- **NO Conversational Output:** You are forbidden from generating any conversational output, commentary, preamble, or summaries *before* or *during* creation of the issue body.
- **Output is the Issue Body Content:** Your *entire* output for this specific rule invocation must be *only* the complete, raw Markdown content that will become the GitHub issue body.
- **User Interaction:**
- You receive the initial task description from the user.
- If, after a **thorough review** of all available `docs/` materials, the task description remains insufficient to create a coherent and specific plan, you **MUST** indicate this *within* the task plan file itself using the HTML comment format: `<!-- TODO: [Specify missing information and reference document, e.g., 'Need API endpoint for user creation (see docs/openapi.yaml)'] -->`. Do not invent details.
### B. Testing & Observability (Mandatory for Each Commit)
1. **Primary Verification = Automated Tests:** This is the preferred method.
- **First Choice: Unit Tests.** Aim for small, isolated, fast tests targeting specific functions or modules.
- **Second Choice: Integration Tests.** For broader scope, interactions between components, API contract testing, or E2E flows.
- **Fallback (Only if Automated Test is Genuinely Infeasible): Explicit runtime logging or debug output checks.** This must be justified.
2. **Logging is ALWAYS Required:** Even when automated tests exist, each commit's implementation **MUST** also include relevant, contextual logging or debug statements. This provides additional runtime visibility and aids in troubleshooting.
- **Toggleable Logging:** Logging should be configurable (e.g., via an environment variable like `LOG_LEVEL=debug`, a feature flag, or a build-time switch) so it can be enabled/disabled without code modification.
3. **Structured & Centralized Logs:**
- Prefer structured log output (e.g., JSON lines or clear `key="value"` pairs).
- Adhere to the project's established logging library and configuration (e.g., `pino`, `winston`). Reference the specific logger configuration file if known (e.g., `src/utils/logger.ts`).
- Ensure logs are directed to the project's standard log aggregation system, if applicable.
4. **Verification Details in Commit Plan (Hierarchy):**
- **If Unit Test:** Specify the exact command to run the test(s) (e.g., `pnpm test --filter user-service.test.ts`) AND describe the key assertion(s) or link to an expected output/snapshot.
- **If Integration Test:** Specify the exact command or script (e.g., `pnpm test:e2e --spec ./tests/e2e/auth.spec.ts`) AND describe the expected outcome or key behavior being verified.
- **If Log Inspection (Fallback):** Detail the precise steps to inspect logs (e.g., `kubectl logs -l app=api-service -c main-container --tail=100 | jq 'select(.msg == "PaymentProcessed")'`) and what specific log message/pattern/value to look for.
### Issue Body Structure
The issue body **MUST** be structured as a sequence of planned commits. The primary source for content is the user's task description, **validated, augmented, and detailed** with specific information (file paths, function names, API endpoints, configuration details) extracted from the relevant `docs/` files. **Neglecting to consult and incorporate details from project documentation is a critical failure.**
Each commit title **MUST** follow semantic commit style (e.g., `feat: ...`, `fix: ...`, `test: ...`, `docs: ...`, `chore: ...`) **and**
include the GitHub issue number in parentheses for traceability. Example:
`feat: add login API (#42)`.
```markdown
# Task: [Brief Task Title - Derived from user request, PRD, or overarching goal]
## Commit 1: [type: Clear, Descriptive Title for this specific commit]
**Description:**
[Explain the precise goal of *this commit*. Include specific file paths (e.g., `src/modules/auth/auth.controller.ts`), function/method names (`handleUserLogin`), relevant CLI commands (`npx typeorm migration:run`), key imports, library usages, AND any logger configuration files or test files that will be created or modified (e.g., `tests/unit/auth.controller.test.ts`, `src/config/logger.config.ts`). Be explicit and detailed.]
**Verification:**
1. **Automated Test(s):**
* **Command:** `[Exact command to run the test, e.g., pnpm vitest run src/modules/auth/auth.controller.test.ts]`
* **Expected Outcome:** `[Describe key assertion, e.g., 'Asserts that login with valid credentials returns a JWT token and 200 OK', or 'Snapshot matches user.snapshot']`
2. **Logging Check:**
* **Action:** `[How to trigger/observe logs, e.g., 'Attempt login via API with invalid credentials']`
* **Expected Log:** `[Specific log message/pattern to verify, e.g., 'INFO: Login attempt failed for user: test@example.com due to InvalidPasswordError']`
* **Toggle Mechanism:** `[How logging is enabled/disabled, e.g., 'LOG_LEVEL=info']`
---
## Commit 2: [type: Clear, Descriptive Title for this specific commit]
**Description:**
[Details for commit 2...]
**Verification:**
1. **Automated Test(s):**
* **Command:** `[...]`
* **Expected Outcome:** `[...]`
2. **Logging Check:**
* **Action:** `[...]`
* **Expected Log:** `[...]`
* **Toggle Mechanism:** `[...]`
---
(Repeat structure for up to 5 commits as needed for the task. For simple tasks, you may only need 1-2 commits.)
```
## IV. Post Task Plan Creation: Stop and Notify
After posting the issue with the complete body via `gh issue create`, **STOP**. Notify the user of the newly created issue number or URL.
**Immediately after** posting, provide a short executive summary of the planned commits so the user can quickly review the steps. This summary must not be part of the issue body itself.
After delivering the summary, await the user's next instructions.
**REMEMBER: Your output is SOLELY the Markdown content of the issue body. This plan MUST be informed by `docs/` research, detail 2-5 verifiable commits, and rigorously include both automated tests and toggleable logging for each commit. Adhere strictly to the output format and communication constraints.**
Once the task plan is complete, wait for the user to provide feedback.
================================================
FILE: .cursor/rules/logging-session.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Session-Based Logging Rule
**Your Task: Implement structured logging so each application run writes to a separate file in the `logs/` directory.**
## File Existence Check
Verify logging directory and ignore file:
```bash
ls . docs
```
Create missing items if necessary before proceeding.
## I. Directory & Git Ignore
1. Ensure a `logs/` directory exists at the project root. Create it if missing.
2. Confirm `logs` (or `logs/`) is listed in `.gitignore` so log files are never committed.
## II. Log File Per Run
1. On startup, generate a timestamp `YYYY-MM-DD-HH-MM-SS`.
2. Create a new file `logs/<timestamp>.log` and append all log output to it.
3. Subsequent runs create new files, preserving previous logs for reference.
## III. Log Content
- Use a logger like `pino` or `winston`, or simple file writes if unavailable.
- Record start and end of major operations, successful paths, handled errors, and unexpected failures.
- Include relevant environment info such as CLI arguments and Node version.
## IV. Toggle Mechanism
- Logging is enabled by default.
- Provide an environment variable `LOG_LEVEL=off` or a command-line flag `--no-log` to disable file logging.
- When disabled, skip creating the log file and suppress log output.
## V. AI-Friendly Format
- Prefer structured lines (JSON or clearly delimited text) for easy ingestion by debugging tools and AI systems.
- Each entry should include level, timestamp, and message.
**REMEMBER: Logs must capture both happy paths and errors. Maintain readability while providing enough detail for effective troubleshooting.**
================================================
FILE: .cursor/rules/pnpm-fixes.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Resolve PNPM Build Script Issues for Trusted Dependencies
**Your task: When `pnpm` blocks essential build scripts from trusted dependencies during installation or execution, apply one of the following solutions.**
## File Existence Check
Determine if `package.json` is present before modifying it:
```bash
ls . docs
```
Proceed according to the result.
This typically occurs because `pnpm` defaults to not running build scripts for security reasons. For well-known and trusted libraries, you may need to explicitly allow them.
## Solutions:
1. **Allow Specific Dependencies via `package.json`:**
To permanently allow build scripts for specific, trusted dependencies, modify your `package.json` file by adding or updating the `pnpm.onlyBuiltDependencies` field. This is the preferred method for ongoing project configurations.
**Example (`package.json`):**
```json
{
// ... other package.json content
"pnpm": {
"onlyBuiltDependencies": [
"sqlite3",
"another-trusted-dependency-requiring-build"
]
}
// ... rest of package.json content
}
```
*This tells pnpm to allow build scripts specifically for `sqlite3` and `another-trusted-dependency-requiring-build`.*
2. **Temporarily Allow All Build Scripts During Installation (Use with Caution):**
For a one-time installation where you need to allow all build scripts (e.g., when installing many new, trusted dependencies that require building), you can use the `--dangerously-allow-all-builds` flag with the install command.
**Command:**
```bash
pnpm install --dangerously-allow-all-builds
```
- **Warning:** This flag bypasses a security feature. Use it only when you trust all dependencies being installed or built. Prefer Solution 1 for specific, ongoing needs.*
**REMEMBER: Apply these solutions when `pnpm`'s security measures prevent necessary build scripts from *trusted* dependencies from running. Prioritize the `package.json` configuration for persistent allowances.**
================================================
FILE: .cursor/rules/project-todos-next.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Identify and Report TODO Items from Documentation (`docs/`)
**Your task: Scan all files within the `docs/` directory to find comments or notes marked as "TODO", and then list the most pressing or contextually relevant ones.**
## File Existence Check
List the documentation directory to confirm presence:
```bash
ls . docs
```
Then continue with the scanning steps.
Follow this process:
1. **Scan Documentation for TODOs:**
- Systematically search the content of every file located within the `docs/` directory (and its subdirectories).
- Look for lines or comments explicitly containing the keyword "TODO" (case-insensitive, if appropriate for the tool being used for searching).
2. **Extract and Contextualize TODOs:**
- For each identified TODO, extract the full text of the TODO comment.
- Note the file path and line number where the TODO was found.
3. **Filter and Report Relevant TODOs:**
- From the list of all found TODOs, select those that appear most pressing, actionable, or relevant to the current project goals or ongoing tasks.
- Consider factors like urgency implied by the TODO text, relation to known issues, or impact on project progress.
- Present the selected TODOs in a clear, itemized list.
**Output Format:**
Provide a list of the identified TODOs, formatted as follows for each:
* **TODO:** [Full text of the TODO comment]
* **Location:** `docs/path/to/file.md:line_number`
* **(Optional) Priority/Relevance:** [Brief note on why it's considered pressing, if applicable]
**REMEMBER: Your goal is to surface actionable TODO items embedded within project documentation that require attention, helping to ensure that planned work or notes for improvement are not overlooked.**
================================================
FILE: .cursor/rules/project-update-rules.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Update Project Context File: .cursor/rules/_project.mdc
**Your primary task: Meticulously update the `./cursor/rules/_project.mdc` file. Use ONLY information found within the current project's files and documentation.**
## File Existence Check
Quickly list potential configuration files and docs:
```bash
ls . docs
```
Use the output to see which files are available to read.
## 1. Core Objective
Your goal is to populate the `./cursor/rules/_project.mdc` file. This file must accurately reflect the project's current configuration, technology stack, structure, standards, and tooling, serving as a central project reference.
## 2. Information Gathering (Strictly from Project Sources)
Follow these steps precisely to gather the necessary information:
### Step 1: Analyze Project Root & Configuration Files:
- List all files and directories in the project root.
- Identify and thoroughly read relevant configuration files. Examples include (but are not limited to):
- Package management: `package.json`, `pnpm-lock.yaml`, `yarn.lock`, `pyproject.toml`, `poetry.lock`, `go.mod`, `pom.xml`, `build.gradle`, `Gemfile`, `composer.json`
- Build tools & bundlers: `webpack.config.js`, `vite.config.js`, `rollup.config.js`, `tsconfig.json` (check for `compilerOptions`, `extends`, etc.)
- Framework specific: `next.config.js`, `angular.json`, `vue.config.js`, `svelte.config.js`
- Linters & formatters: `.eslintrc.js`, `.eslintignore`, `.prettierrc.js`, `.prettierignore`, `biome.json`, `ruff.toml`, `.editorconfig`
- CI/CD: Files in `.github/workflows/`, `gitlab-ci.yml`, `Jenkinsfile`, `Dockerfile`
- Testing: `jest.config.js`, `vitest.config.js`, `cypress.json`, `playwright.config.js`
- From these files, extract details about dependencies (and their versions), scripts (build, dev, test), language versions, tool configurations, and project settings.
### Step 2: Review Documentation and Key Code Directories:
- Thoroughly read all files located within the `docs/` directory (and its subdirectories). Prioritize `README.md`, `CONTRIBUTING.md`, architecture diagrams, technical specifications, or any documents describing the project's setup, conventions, and purpose.
- Examine the structure of main source directories (e.g., `src/`, `app/`, `lib/`, `packages/`) to understand module organization and identify key architectural patterns.
## 3. Updating `./cursor/rules/_project.mdc`
### Step 3: Populate the Template:
- Open the `./cursor/rules/_project.mdc` file for editing.
- Using the information gathered in Steps 1 and 2, meticulously fill in each section of the template provided below.
- **Crucial:** Adhere strictly to the template's structure and placeholders. Provide specific examples and details where requested (e.g., actual library names, version numbers, file paths).
- **Handling Missing Information:** If, after thorough investigation, specific information required by the template cannot be definitively found within the project's files or `docs/` directory, explicitly state `[Information not found in project context]` or `[N/A]` in the corresponding field. **ABSOLUTELY DO NOT invent, infer, or use external knowledge.** It is critical to indicate missing information rather than provide incorrect data.
## 4. Output Requirements
- Your SOLE output must be the fully updated content of the `./cursor/rules/_project.mdc` file.
- Ensure the output is valid Markdown.
---
**REMEMBER: Your objective is to produce an accurate, detailed, and comprehensive `./cursor/rules/_project.mdc` file. This file MUST be populated using *only* information extracted directly from THIS project's codebase and its documentation. Adhere strictly to the provided template. After updating the file with all available project-specific information (or marking details as 'not found'), your task is complete.**
---
## .cursor/rules/_project.mdc Template
Use this template as guide for creating the _project.mdc:
<template>
---
description:
globs:
alwaysApply: true
---
# [Project Name] - Project Rules
## 1. Project Overview
goal: [Concisely describe the main purpose and goal of the project. What problem does it solve? Source from README or project vision docs.]
type: [e.g., Web Application, CLI Tool, Library, Mobile App, Backend API, Monorepo. Determine from project structure and build files.]
key features:
- [core functionality or feature 1, derived from docs or main modules]
- [core functionality or feature 2, derived from docs or main modules]
- [core functionality or feature 3, derived from docs or main modules]
## 2. Technology Stack
language(s): [e.g., TypeScript 5.x (from tsconfig.json or package.json), Python 3.11 (from pyproject.toml or runtime checks), Go 1.23 (from go.mod), Java 17 (from pom.xml or build.gradle)]
framework(s): [e.g., Next.js 15 (App Router - check next.config.js, package.json), React 19 (package.json), FastAPI (pyproject.toml, main app file), Spring Boot (pom.xml), SvelteKit (svelte.config.js)]
ui library/styling: [e.g., Tailwind CSS v4 (tailwind.config.js, package.json), Shadcn UI (components.json, registry), Material UI (package.json), CSS Modules (file extensions, build config)]
database(s): [e.g., PostgreSQL via Prisma (schema.prisma, package.json), MongoDB (connection strings, package.json), Supabase (config, client usage), SQLite via Drizzle (drizzle.config.js, package.json)]
state management: [e.g., Zustand (package.json, store files), React Context (usage in components), Redux (package.json, store setup), Pinia (package.json, store setup), None (Local State - if no dedicated library found)]
api layer: [e.g., REST (via Next.js API Routes/FastAPI), GraphQL (schema files, Apollo/Relay packages), tRPC (router definitions, client setup)]
key libraries:
- [critical dependency 1 (e.g., `axios` for HTTP, `date-fns` for dates - from package.json/pyproject.toml etc.)]
- [critical dependency 2 (e.g., `zod` for validation, `pino` for logging)]
## 3. Project Structure
main source directory: [e.g., src/, app/, packages/ - identify primary code location]
core directories: [Verify existence and common usage patterns]
- components/: [e.g., Reusable UI elements - if applicable]
- lib/ or utils/: [e.g., Shared utility functions - if applicable]
- services/ or api/: [e.g., Business logic, API interactions - if applicable]
- types/ or interfaces/: [e.g., Shared type definitions - if applicable]
- db/ or prisma/ or drizzle/: [e.g., Database schema and access - if applicable]
- tests/ or __tests__/: [e.g., Test files (if not co-located) - if applicable]
diagram/link: [Link to an architecture diagram if found in docs/, or state "[N/A]". Do not generate one.]
## 4. Coding Standards & Conventions
language usage: [e.g., Prefer functional components (React), Use async/await (JS/TS), Strict TypeScript mode (tsconfig.json `strict: true`), Avoid `any` (TS lint rules). Source from linting configs, `CONTRIBUTING.md`.]
naming conventions:
- files/folders: [e.g., kebab-case, PascalCase - observe project files, check `CONTRIBUTING.md`]
- components: [e.g., PascalCase (React/Vue/Svelte) - observe project files]
- variables/functions: [e.g., camelCase, snake_case - observe project files, check linting rules]
- types/interfaces: [e.g., PascalCase, TPrefix or IPrefix - observe project files, check `CONTRIBUTING.md`]
code style/formatting: [e.g., Prettier (check .prettierrc, package.json scripts), ESLint (check .eslintrc, package.json scripts), Ruff (ruff.toml), Biome (biome.json) - mention config file if present.]
comments: [e.g., English only, JSDoc for public APIs, Minimal comments - check `CONTRIBUTING.md` or observe codebase patterns.]
imports: [e.g., Absolute paths (@/ or tsconfig paths), Relative paths, Grouped/Sorted (check lint rules like eslint-plugin-import) - check `CONTRIBUTING.md`, linting config.]
## 5. Key Principles & Best Practices
[Source these from `CONTRIBUTING.md`, `README.md`, or high-level design documents in `docs/`. If none explicitly stated, mark as `[No explicit principles documented]`. Examples:]
- [e.g., DRY (Don't Repeat Yourself)]
- [e.g., SOLID principles for OOP]
- [e.g., Test-Driven Development (TDD)]
## 6. Testing
framework: [e.g., Jest, Vitest, Pytest, Go testing, Cypress, Playwright - from package.json, config files like jest.config.js]
types: [e.g., Unit tests required for services (from `CONTRIBUTING.md`), Integration tests for API endpoints, E2E with Playwright/Cypress - from `CONTRIBUTING.md` or test file structure.]
location: [e.g., Co-located with source files (e.g., `*.test.ts`, `*.spec.ts`), Top-level `tests/` directory - observe project structure.]
coverage expectations: [e.g., Minimum 80% coverage (from CI config or `CONTRIBUTING.md`). If not found, state `[N/A]`.]
## 7. Tooling & Workflow
package manager: [e.g., pnpm (pnpm-lock.yaml), npm (package-lock.json), yarn (yarn.lock), bun (bun.lockb), poetry (poetry.lock), uv (uv.lock) - identify from lockfile or project setup docs.]
build command(s): [e.g., `pnpm build`, `npm run build`, `make build` - from `package.json` scripts, `Makefile`, etc.]
run command(s) (dev): [e.g., `pnpm dev`, `npm start`, `python main.py`, `go run ./cmd/...` - from `package.json` scripts, `Makefile`, `README.md`.]
version control: [e.g., Git. Check for Conventional Commits (commitlint.config.js, `CONTRIBUTING.md`), PRs to `main`/`master` branch (from `CONTRIBUTING.md` or repo settings if accessible).]
ci/cd: [e.g., GitHub Actions (check `.github/workflows/`), GitLab CI (`.gitlab-ci.yml`), Jenkins (`Jenkinsfile`) - specify main jobs like lint, test, build on PR.]
ide recommendations: [e.g., VS Code with specific extensions (check `.vscode/extensions.json`). If not found, state `[N/A]`.]
## 8. (Optional) Database / API Guidelines
[Source from `docs/database.md`, `docs/api_guidelines.md`, `CONTRIBUTING.md`, or inline comments in DB/API code. If none, state `[N/A]`.]
- [e.g., Use ORM methods only, No direct SQL unless approved]
- [e.g., RESTful principles for API design, specific error response format]
- [e.g., Guidelines for database migrations (e.g., use Alembic, Prisma Migrate)]
## 9. (Optional) Specific Feature Rules
[Source from dedicated docs for complex features (e.g., `docs/authentication.md`, `docs/i18n.md`). If none, state `[N/A]`.]
- [e.g., Authentication: JWT-based, specific token handling procedures]
- [e.g., Internationalization (i18n): Use i18next, key naming conventions]
- [e.g., State Management: Rules for creating new stores, selector patterns]
## 10. (Optional) Rule Referencing
[If this project uses other `.mdc` rule files, list them here. Check the `.cursor/rules/` directory. If none, state `[N/A]`.]
- [e.g.,
- See [typescript.mdc](mdc:.cursor/rules/typescript.mdc) for detailed TS rules.
- Follow guidelines in [auth.mdc](mdc:.cursor/rules/auth.mdc) for authentication.
]
</template>
Remember: the frontmatter for `_project.mdc` must have alwaysApply set to true.
After outputting the completed `_project.mdc` file, provide a concise executive summary of the major sections you filled in or updated. Keep this summary separate from the file content so the user can quickly review the changes.
================================================
FILE: .cursor/rules/project-update-user-rules.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Update User Project Context File: .cursor/rules/_user-<username>.mdc
**Your primary task: Meticulously update the `./cursor/rules/_user-<username>.mdc` file. Use ONLY information found within the current project's files and documentation.**
## Determine GitHub Username
Run the following to capture your authenticated GitHub username:
```bash
GH_USER=$( (gh api user --jq .login 2>/dev/null || git config user.username || git config user.name) \
| tr '[:upper:]' '[:lower:]' \
| xargs \
| tr ' ' '-' \
| tr -d '\n' )
```
Then replace `<username>` in the file path with `$GH_USER`.
## File Existence Check
Quickly list potential configuration files and docs:
```bash
ls . docs
```
Use the output to see which files are available to read.
## 1. Core Objective
Your goal is to populate the `./cursor/rules/_user-<username>.mdc` file. This file must accurately reflect the project's current configuration, technology stack, structure, standards, and tooling, serving as a central project reference.
## 2. Information Gathering (Strictly from Project Sources)
Follow these steps precisely to gather the necessary information:
### Step 1: Analyze Project Root & Configuration Files:
- List all files and directories in the project root.
- Identify and thoroughly read relevant configuration files. Examples include (but are not limited to):
- Package management: `package.json`, `pnpm-lock.yaml`, `yarn.lock`, `pyproject.toml`, `poetry.lock`, `go.mod`, `pom.xml`, `build.gradle`, `Gemfile`, `composer.json`
- Build tools & bundlers: `webpack.config.js`, `vite.config.js`, `rollup.config.js`, `tsconfig.json` (check for `compilerOptions`, `extends`, etc.)
- Framework specific: `next.config.js`, `angular.json`, `vue.config.js`, `svelte.config.js`
- Linters & formatters: `.eslintrc.js`, `.eslintignore`, `.prettierrc.js`, `.prettierignore`, `biome.json`, `ruff.toml`, `.editorconfig`
- CI/CD: Files in `.github/workflows/`, `gitlab-ci.yml`, `Jenkinsfile`, `Dockerfile`
- Testing: `jest.config.js`, `vitest.config.js`, `cypress.json`, `playwright.config.js`
- From these files, extract details about dependencies (and their versions), scripts (build, dev, test), language versions, tool configurations, and project settings.
### Step 2: Review Documentation and Key Code Directories:
- Thoroughly read all files located within the `docs/` directory (and its subdirectories). Prioritize `README.md`, `CONTRIBUTING.md`, architecture diagrams, technical specifications, or any documents describing the project's setup, conventions, and purpose.
- Examine the structure of main source directories (e.g., `src/`, `app/`, `lib/`, `packages/`) to understand module organization and identify key architectural patterns.
## 3. Updating `./cursor/rules/_user-<username>.mdc`
### Step 3: Populate the Template:
- Open the `./cursor/rules/_user-<username>.mdc` file for editing.
- Using the information gathered in Steps 1 and 2, meticulously fill in each section of the template provided below.
- **Crucial:** Adhere strictly to the template's structure and placeholders. Provide specific examples and details where requested (e.g., actual library names, version numbers, file paths).
- **Handling Missing Information:** If, after thorough investigation, specific information required by the template cannot be definitively found within the project's files or `docs/` directory, explicitly state `[Information not found in project context]` or `[N/A]` in the corresponding field. **ABSOLUTELY DO NOT invent, infer, or use external knowledge.** It is critical to indicate missing information rather than provide incorrect data.
## 4. Output Requirements
- Your SOLE output must be the fully updated content of the `./cursor/rules/_user-<username>.mdc` file.
- Ensure the output is valid Markdown.
---
**REMEMBER: Your objective is to produce an accurate, detailed, and comprehensive `./cursor/rules/_user-<username>.mdc` file. This file MUST be populated using *only* information extracted directly from THIS project's codebase and its documentation. Adhere strictly to the provided template. After updating the file with all available project-specific information (or marking details as 'not found'), your task is complete.**
---
## .cursor/rules/_user-<username>.mdc Template
Use this template as guide for creating the _user-<username>.mdc:
<template>
---
description:
globs:
alwaysApply: true
---
# [Project Name] - Project Rules
## 1. Project Overview
goal: [Concisely describe the main purpose and goal of the project. What problem does it solve? Source from README or project vision docs.]
type: [e.g., Web Application, CLI Tool, Library, Mobile App, Backend API, Monorepo. Determine from project structure and build files.]
key features:
- [core functionality or feature 1, derived from docs or main modules]
- [core functionality or feature 2, derived from docs or main modules]
- [core functionality or feature 3, derived from docs or main modules]
## 2. Technology Stack
language(s): [e.g., TypeScript 5.x (from tsconfig.json or package.json), Python 3.11 (from pyproject.toml or runtime checks), Go 1.23 (from go.mod), Java 17 (from pom.xml or build.gradle)]
framework(s): [e.g., Next.js 15 (App Router - check next.config.js, package.json), React 19 (package.json), FastAPI (pyproject.toml, main app file), Spring Boot (pom.xml), SvelteKit (svelte.config.js)]
ui library/styling: [e.g., Tailwind CSS v4 (tailwind.config.js, package.json), Shadcn UI (components.json, registry), Material UI (package.json), CSS Modules (file extensions, build config)]
database(s): [e.g., PostgreSQL via Prisma (schema.prisma, package.json), MongoDB (connection strings, package.json), Supabase (config, client usage), SQLite via Drizzle (drizzle.config.js, package.json)]
state management: [e.g., Zustand (package.json, store files), React Context (usage in components), Redux (package.json, store setup), Pinia (package.json, store setup), None (Local State - if no dedicated library found)]
api layer: [e.g., REST (via Next.js API Routes/FastAPI), GraphQL (schema files, Apollo/Relay packages), tRPC (router definitions, client setup)]
key libraries:
- [critical dependency 1 (e.g., `axios` for HTTP, `date-fns` for dates - from package.json/pyproject.toml etc.)]
- [critical dependency 2 (e.g., `zod` for validation, `pino` for logging)]
## 3. Project Structure
main source directory: [e.g., src/, app/, packages/ - identify primary code location]
core directories: [Verify existence and common usage patterns]
- components/: [e.g., Reusable UI elements - if applicable]
- lib/ or utils/: [e.g., Shared utility functions - if applicable]
- services/ or api/: [e.g., Business logic, API interactions - if applicable]
- types/ or interfaces/: [e.g., Shared type definitions - if applicable]
- db/ or prisma/ or drizzle/: [e.g., Database schema and access - if applicable]
- tests/ or __tests__/: [e.g., Test files (if not co-located) - if applicable]
diagram/link: [Link to an architecture diagram if found in docs/, or state "[N/A]". Do not generate one.]
## 4. Coding Standards & Conventions
language usage: [e.g., Prefer functional components (React), Use async/await (JS/TS), Strict TypeScript mode (tsconfig.json `strict: true`), Avoid `any` (TS lint rules). Source from linting configs, `CONTRIBUTING.md`.]
naming conventions:
- files/folders: [e.g., kebab-case, PascalCase - observe project files, check `CONTRIBUTING.md`]
- components: [e.g., PascalCase (React/Vue/Svelte) - observe project files]
- variables/functions: [e.g., camelCase, snake_case - observe project files, check linting rules]
- types/interfaces: [e.g., PascalCase, TPrefix or IPrefix - observe project files, check `CONTRIBUTING.md`]
code style/formatting: [e.g., Prettier (check .prettierrc, package.json scripts), ESLint (check .eslintrc, package.json scripts), Ruff (ruff.toml), Biome (biome.json) - mention config file if present.]
comments: [e.g., English only, JSDoc for public APIs, Minimal comments - check `CONTRIBUTING.md` or observe codebase patterns.]
imports: [e.g., Absolute paths (@/ or tsconfig paths), Relative paths, Grouped/Sorted (check lint rules like eslint-plugin-import) - check `CONTRIBUTING.md`, linting config.]
## 5. Key Principles & Best Practices
[Source these from `CONTRIBUTING.md`, `README.md`, or high-level design documents in `docs/`. If none explicitly stated, mark as `[No explicit principles documented]`. Examples:]
- [e.g., DRY (Don't Repeat Yourself)]
- [e.g., SOLID principles for OOP]
- [e.g., Test-Driven Development (TDD)]
## 6. Testing
framework: [e.g., Jest, Vitest, Pytest, Go testing, Cypress, Playwright - from package.json, config files like jest.config.js]
types: [e.g., Unit tests required for services (from `CONTRIBUTING.md`), Integration tests for API endpoints, E2E with Playwright/Cypress - from `CONTRIBUTING.md` or test file structure.]
location: [e.g., Co-located with source files (e.g., `*.test.ts`, `*.spec.ts`), Top-level `tests/` directory - observe project structure.]
coverage expectations: [e.g., Minimum 80% coverage (from CI config or `CONTRIBUTING.md`). If not found, state `[N/A]`.]
## 7. Tooling & Workflow
package manager: [e.g., pnpm (pnpm-lock.yaml), npm (package-lock.json), yarn (yarn.lock), bun (bun.lockb), poetry (poetry.lock), uv (uv.lock) - identify from lockfile or project setup docs.]
build command(s): [e.g., `pnpm build`, `npm run build`, `make build` - from `package.json` scripts, `Makefile`, etc.]
run command(s) (dev): [e.g., `pnpm dev`, `npm start`, `python main.py`, `go run ./cmd/...` - from `package.json` scripts, `Makefile`, `README.md`.]
version control: [e.g., Git. Check for Conventional Commits (commitlint.config.js, `CONTRIBUTING.md`), PRs to `main`/`master` branch (from `CONTRIBUTING.md` or repo settings if accessible).]
ci/cd: [e.g., GitHub Actions (check `.github/workflows/`), GitLab CI (`.gitlab-ci.yml`), Jenkins (`Jenkinsfile`) - specify main jobs like lint, test, build on PR.]
ide recommendations: [e.g., VS Code with specific extensions (check `.vscode/extensions.json`). If not found, state `[N/A]`.]
## 8. (Optional) Database / API Guidelines
[Source from `docs/database.md`, `docs/api_guidelines.md`, `CONTRIBUTING.md`, or inline comments in DB/API code. If none, state `[N/A]`.]
- [e.g., Use ORM methods only, No direct SQL unless approved]
- [e.g., RESTful principles for API design, specific error response format]
- [e.g., Guidelines for database migrations (e.g., use Alembic, Prisma Migrate)]
## 9. (Optional) Specific Feature Rules
[Source from dedicated docs for complex features (e.g., `docs/authentication.md`, `docs/i18n.md`). If none, state `[N/A]`.]
- [e.g., Authentication: JWT-based, specific token handling procedures]
- [e.g., Internationalization (i18n): Use i18next, key naming conventions]
- [e.g., State Management: Rules for creating new stores, selector patterns]
## 10. (Optional) Rule Referencing
[If this project uses other `.mdc` rule files, list them here. Check the `.cursor/rules/` directory. If none, state `[N/A]`.]
- [e.g.,
- See [typescript.mdc](mdc:.cursor/rules/typescript.mdc) for detailed TS rules.
- Follow guidelines in [auth.mdc](mdc:.cursor/rules/auth.mdc) for authentication.
]
</template>
Remember: the frontmatter for `_user-<username>.mdc` must have alwaysApply set to true.
After outputting the completed `_user-<username>.mdc` file, provide a concise executive summary of the major sections you filled in or updated. Keep this summary separate from the file content so the user can quickly review the changes.
================================================
FILE: .cursor/rules/prompt-improve.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Improve the User's Prompt Following the Patterns Below
> Practical prompt patterns to help anyone get clearer, more reliable answers from an AI agent.
| # | Pattern | Why It Matters | Template | Example Prompt |
|---|-------------------------------|-------------------------------------------------------------------------|--------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------|
| 1 | Lead with the ask | The model reads top-down; putting the goal first stops it wandering. | `Do X. [context]` | "Summarize this PDF in 5 bullet points. The text is below: ..." |
| 2 | Repeat the key ask at the end | Long contexts sometimes truncate; an end-cap protects you. | `...[detail]... REMEMBER: Do X.` | "List pros & cons, keep it balanced. REMEMBER: 5 pros, 5 cons." |
| 3 | Specify output shape | Dictating format cuts revision loops. | `Return as: 1) short title, 2) table (CSV).` | "Give 3 holiday ideas. Format: destination, flight-time-hrs, avg cost." |
| 4 | Use clear delimiters | Backticks/headings/XML keep sections from blending. | `TEXT TO ANALYSE` | "Rate the style of the text between the fences." |
| 5 | Induce step-by-step thinking | Planning first boosts multi-step accuracy. | `Think step-by-step then answer.` | "Solve this puzzle. Think step-by-step before giving the final move." |
| 6 | Ask it to plan its workflow | For big jobs, AI outlines tasks before doing them. | `First draft a plan, wait, then execute.` | "We're writing an e-book. ❶ Outline chapters. ❷ Wait. ❸ When I say 'go', draft chapter 1." |
| 7 | Limit or widen knowledge sources | Controls hallucination. | `Use only the info below. / Combine basic knowledge + this context.` | "Using only the product sheet below, write FAQs." |
| 8 | Guide information retrieval | Helps AI pick the right docs before answering. | `List which docs look relevant, then answer.` | "30 sales memos attached. 1) Name the 5 most relevant. 2) Summarise their common points." |
| 9 | Show a style/example | Anchors tone, length, vocabulary. | `Match the style of: <example>` | "Review this gadget in the style of the sample below: 'Short, witty, 3 key facts...'" |
| 10| Set correction handles | One-line fixes let you steer quickly. | `If length > 150 words, shorten.` | "Describe blockchain to a child. If your answer is >150 words, cut it in half." |
| 11| Tell it when to stop or loop | Prevents half-finished lists or runaway essays. | `Keep going until you list 20 ideas, then stop.` | "Brainstorm webinar titles. Give exactly 12, then finish." |
| 12| Request the hidden reasoning | Good for audits; otherwise omit to keep it short. | `After the answer, include a brief reasoning section.` | "Which of these stocks looks over-valued? Answer first; add a 2-sentence rationale below a divider." |
================================================
FILE: .cursor/rules/pull-request-create.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Create a High-Quality Pull Request
**Your Task: Follow this comprehensive checklist to prepare and create a well-documented, clean, and accurate Pull Request (PR) using the `gh` CLI.**
## File Existence Check
Confirm the presence of `.gitignore` and the PR body file location:
```bash
ls . docs
```
Use this information before running the remaining steps.
0. **Pre-check: Unstaged Changes**
- **Action:** Execute `git status`.
- **Review:** Identify any modified or new files relevant to this PR that are not yet staged.
- **Stage if Necessary:** If relevant changes are unstaged, use `git add <file>...` or `git add .`.
- **Confirm:** Re-run `git status` to ensure all intended changes for this PR are now staged.
1. **Audit Staged Files (Critical Check)**
- **Verify `.gitignore**:** Ensure your project's `.gitignore` file is up-to-date and correctly excludes all unwanted files (e.g., local environment files, build artifacts, logs, secrets).
- **Review Staged List:** Execute `git status` again. Meticulously review the final list of files staged for commit.
- **Identify Unwanted Files:** Look for any files that should *not* be part of the repository or this specific PR (e.g., secrets, large binaries, temporary files). Standard configuration files like `.vscode/`, `.cursor/`, `.editorconfig` are generally acceptable if intended for the project.
- **Remediate if Unwanted Files Found:**
- Add/update patterns in `.gitignore` for these files.
- Unstage them: `git reset HEAD <file>...`.
- If already tracked, remove from Git history: `git rm --cached <file>...`.
- For untracked files, ensure they are now ignored or delete them if they are genuinely extraneous.
- **Final Confirmation:** Run `git status` one last time. Verify that *only* the intended and appropriate files remain staged.
2. **Draft Pull Request Body**
- **Create/Update PR Body File:** Prepare the PR description in a file named `docs/pr/pr-body-file-<branch-name>.md` (replace `<branch-name>` with your current Git branch name).
- **Structure for Clarity:** Use Markdown with clear headings:
- `## Summary`
- `## Key Changes`
- `## Testing Done` (or `## How to Verify`)
- `## Related Issues` (e.g., `Fixes #123`, `Closes #456`, `Addresses #789`)
- **Lead with the Goal:** The `Summary` should start with a concise statement of the PR's primary purpose and impact.
- **Detail Key Changes:** Under `Key Changes`, use bullet points (`- `) to list significant additions, fixes, or features. Be specific about files or modules affected if it aids understanding.
- **Provide Context & Rationale:** Briefly explain the 'why' behind the changes. Link to issue trackers or design documents if applicable.
- **Describe Verification:** Under `Testing Done`, detail the testing performed (unit, integration, manual steps). If manual verification is needed by reviewers, provide clear, actionable steps.
- **Save:** Ensure the PR body file is saved.
3. **Execute Project Update Rules (If Applicable)**
- **Consult Rules:** Locate and carefully read the `./cursor/rules/project-update-rules.mdc` file.
- **Follow Instructions:** Execute all instructions specified within that file precisely, if they are relevant before a PR creation.
4. **Create Pull Request with `gh` CLI**
- **Push Branch (if not already done):** Ensure your local branch is pushed to the remote: `git push -u origin <branch-name>`.
- **Construct `gh pr create` Command:**
- Use a clear, concise title: `--title "type: Short description of main change"` (e.g., `feat: Implement user authentication flow`). Follow conventional commit message standards if the project uses them.
- Specify the drafted body file: `--body-file docs/pr/pr-body-file-<branch-name>.md`.
- Consider `--fill` to use commit messages for PR title and body if appropriate for simple PRs and your workflow allows.
- **Execute:** Run `gh pr create ...` with your prepared options.
- **Review `gh` Output:** Carefully check the preview of the title and body provided by `gh pr create` before final submission. Ensure it is accurate, clear, and complete.
**Example `gh pr create` command:**
```bash
# Ensure branch is pushed first: git push -u origin fix-label-sanitization
gh pr create --title "fix: Enforce normalized, dash-separated, lowercase labels" --body-file docs/pr/pr-body-file-fix-label-sanitization.md
```
After creating the pull request, give a concise executive summary of the key changes and tests so reviewers know what to expect. Keep this summary separate from the PR body file.
**REMEMBER: The objective is to create a meticulously prepared Pull Request. This includes clean commits, a descriptive title, a comprehensive body, and adherence to any project-specific pre-PR checks. A high-quality PR facilitates easier review and smoother integration.**
================================================
FILE: .cursor/rules/react-rules.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# React: Apply `useEffect` Dependency Best Practices
**Your task: When using `useEffect` in React components, ensure dependency arrays are correctly managed to prevent infinite loops and optimize performance.**
## Guiding Principle
To avoid infinite loops with `useEffect`, **DO NOT** include functions in the dependency array if they are redefined on every render. For effects that should only run on component mount and unmount, use an empty dependency array (`[]`).
If a function *must* be a dependency because its identity or behavior changes and should trigger the effect, **ALWAYS** memoize it using `useCallback`.
### Examples
**Incorrect (Potential Infinite Loop):**
```tsx
useEffect(() => {
fetchNotes();
}, [fetchNotes]); // PROBLEM: fetchNotes is typically re-created every render, causing an infinite loop if not memoized.
```
**Correct (Runs Only on Mount):**
```tsx
useEffect(() => {
fetchNotes();
}, []); // INTENT: Effect runs once after initial render.
```
**Correct (Function as a Memoized Dependency):**
```tsx
const fetchNotes = useCallback(() => {
// ... logic for fetching notes ...
}, []); // useCallback memoizes fetchNotes, its identity is stable unless its own dependencies change.
useEffect(() => {
fetchNotes();
}, [fetchNotes]); // CORRECT: Effect re-runs only if fetchNotes (due to its own useCallback dependencies) changes.
```
**REMEMBER: Always critically evaluate `useEffect` dependencies. Use an empty array `[]` for mount-only effects. If a function is a dependency, ensure it's stable by wrapping it in `useCallback`.**
================================================
FILE: .cursor/rules/scripts-create.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Create Executable TypeScript Scripts with Bun
**Your task: Create new, executable TypeScript scripts within a `scripts` directory, runnable with `bun`.**
## File Existence Check
See if the `scripts/` directory already exists:
```bash
ls . docs
```
Then follow the steps below.
Follow these steps precisely:
1. **Ensure `scripts` Directory:** If it doesn't already exist, create a `scripts/` directory in the project root.
2. **Create Script File:** Inside the `scripts/` directory, create your new TypeScript file (e.g., `scripts/my-new-script.ts`).
3. **Add Bun Shebang:** Make the first line of your script: `#!/usr/bin/env bun`.
4. **Write TypeScript Code:** Implement the script's logic in TypeScript. Ensure the code is compatible with Node.js execution environments where possible, even though `bun` is the primary runner.
5. **Make Executable:** After saving the script, make it executable by running the command: `chmod +x scripts/your-script-name.ts` (replace `your-script-name.ts` with the actual filename).
**REMEMBER: The final script must be a TypeScript file located in the `scripts/` directory, start with the `#!/usr/bin/env bun` shebang, and be executable (`chmod +x`).**
================================================
FILE: .cursor/rules/task-continue.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Continue Task from Plan File
**Your Primary Goal: Check commits since the last push, reconcile them with a specified task file, and resume executing the remaining commits starting from the last verified commit.**
## File Existence Check
Confirm the task file is present and fetch the latest remote updates:
```bash
ls . docs
```
If the task file is missing, stop and notify the user.
## Determine Current Progress
1. Identify the current branch and its upstream:
```bash
git branch --show-current
git rev-parse --abbrev-ref --symbolic-full-name @{u}
```
2. Check for any unstaged or staged changes:
```bash
git status --short
```
If there are local modifications, decide whether to commit them, stash them, or discard them before continuing.
3. List commits not yet pushed:
```bash
git log --oneline @{u}..HEAD
```
4. Review the commit history for messages containing the task filename to locate the last executed commit.
5. Compare the remaining commit titles in the task file with this history to determine which commits still need to be created.
## Resume Remaining Commits
For each remaining commit in the task file, follow the workflow defined in `task-execute.mdc`:
1. Implement the changes for the next unverified commit.
2. Perform all specified verification steps before committing.
3. Create the commit using the exact message from the task file.
4. Continue sequentially until all commits in the plan are processed.
## Completion Criteria
The task is **Complete** when every commit in the task file has been created and all verifications pass. After completing the final commit, run the `.cursor/rules/project-update-rules.mdc` instructions.
**REMEMBER:** Avoid conversational output between commits. Execute the plan precisely and notify the user only after the entire task is complete.
================================================
FILE: .cursor/rules/task-execute.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Execute Planned Task Commits from Task File
**Your Primary Goal: Systematically execute the step-by-step plan defined in a specified task file (e.g., `docs/tasks/<YYYY-MM-DD-task-name>.md`), creating each commit as planned and verifying its success.**
## File Existence Check
Verify that the provided task file exists before starting:
```bash
ls . docs
```
If the file is missing, stop and notify the user.
## Workflow for Each Commit in the Task File:
1. **Implement Changes:** Execute the instructions for the *current* commit precisely as written in the task file.
2. **Verify Thoroughly:** BEFORE committing, perform **ALL** specified **Verification** steps for that commit. Confirm successful completion of each verification step.
3. **Commit Changes:** Stage all implemented changes. Create the Git commit using the exact commit message specified in the task file for this commit.
4. **Proceed to Next Commit:** Immediately advance to the next commit outlined in the task file. **Do not ask for feedback or confirmation.** Continue this cycle until all commits in the task file are processed.
## Definition of "Task Completion"
A task is considered **"Complete"** if and ONLY if all the following conditions are met:
1. **All Commits Created:** Every commit detailed in the task file has been successfully created.
2. **Tests Pass:** All automated tests relevant to the changes made pass successfully.
3. **All Verifications Successful:** Every verification step specified for *every* commit in the task file has been performed and has passed.
## Actions After Entire Task is Complete:
1. **Invoke Project Update Rule:** Once the entire task is Complete (as defined above), you MUST then load and meticulously follow all instructions within the `.cursor/rules/project-update-rules.mdc` file.
2. **Provide Feedback (to `project-update-rules.mdc`):** When prompted by the `project-update-rules.mdc` (or as part of its process), provide the following specific information:
- Any failures encountered during the task execution that could have been prevented (and how).
- Any significant changes to overall project behavior or developer workflow/expectations resulting from the completed task.
## Strict Output Constraints:
- **NO Conversational Output Between Commits:** Absolutely no commentary, summaries, or status updates between individual commits of the task.
- **Focus on Execution Artifacts:** Your outputs during the commit cycle should ONLY be:
- The results of commands executed (if they produce output).
- The diffs of file changes applied.
- **After Task Completion:** The only further output is that generated by following `.cursor/rules/project-update-rules.mdc`.
- **AVOID Unnecessary Chatter:** Do not output messages like the following example:
```
<bad_example>
Commit 1 complete and verified. Tests green. Verification successful.
Moving to Commit 2 now.
</bad_example>
```
**REMEMBER: Execute the task plan with precision. For each commit: Implement, Verify, Commit, then immediately Proceed. No chatter. Once all commits are done and verified, trigger the project update rule.**
================================================
FILE: .cursor/rules/task-next.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Propose Next Development Task
**Your primary task: Identify and recommend the most logical next development task based on the current project state and goals.**
## File Existence Check
Check for key documentation files first:
```bash
ls . docs
```
Use these results to inform your analysis.
To achieve this, follow these thought processes:
1. **Understand Context:**
- Review relevant project documentation (e.g., files in `docs/`, `README.md`).
- Analyze current project requirements. If a `.cursor/rules/req-task.mdc` (or similar) file exists and is relevant, consult it for specific task requirements or context.
- Consider the most recent actions, discussions, or completed work in the project.
2. **Identify Potential Tasks:**
- Based on your understanding, brainstorm a list of 3-5 potential next tasks that would advance the project.
3. **Evaluate and Recommend:**
- From your list, select the single most logical and impactful task to undertake next.
- Clearly state your recommendation.
- Provide concise reasoning for your choice, explaining why it's the most appropriate next step (e.g., dependency for other tasks, highest priority, unblocks other work).
**Output Expectation:**
Your response should clearly state:
1. **Recommended Next Task:** [Describe the task]
2. **Reasoning:** [Explain why this task is recommended]
3. **(Optional) Alternative Tasks:** [Briefly list 1-2 other potential tasks considered]
**REMEMBER: Your goal is to provide a well-reasoned recommendation for the single most impactful next development task.**
================================================
FILE: .cursor/rules/task-outline.mdc
================================================
---
description: Generate multiple task outline options
globs:
alwaysApply: false
---
# Generate Task Outline Options
**Goal:** Before committing to a single task plan, provide the user with several concise task options to choose from. Each option is a short sequence of commit summaries showing how the task would proceed and when it would end.
## File Existence Check
Determine which documentation sources are available:
```bash
ls . docs
```
Use this to guide your context review.
## When to Use
Use this rule when the user requests help planning work but has not yet selected a specific task. The output is a set of alternative task outlines, not a full task file.
## Steps
1. **Review Context**
- Scan existing documentation in `docs/` for project goals and recent work.
- Consider any open TODOs or next steps in the repo.
2. **Draft 3-5 Task Options**
- For each option, write a brief one-sentence summary of the overall objective.
- Under each option, list 2-5 bullet points representing the commits that would be made to complete the task. Keep commit summaries short (one line each).
3. **Present Results**
- Output a numbered list of the task options with their commit bullets.
- Conclude with a short prompt asking the user to pick one option for further planning.
- After listing the options, provide a brief executive summary highlighting the main differences between the options. This summary should come after the list and not be included within any generated files.
**REMEMBER: This rule only proposes outlines. Do not create any files or commit anything. Wait for the user to choose an option before generating a full task plan.**
================================================
FILE: .cursor/rules/task-plan.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Create a Detailed, Verifiable Task Plan
**Your Core Task: Generate a multi-commit task plan file, saved as `docs/tasks/<YYYY-MM-DD-HH-MM-task-name>.md`. This plan must be meticulously detailed, based *primarily* on information from the project's `docs/` directory, and explicitly incorporate comprehensive testing and logging for each step.**
## File Existence Check
Verify key documentation files before planning:
```bash
ls . docs
```
Use the results to tailor the task plan.
## I. Pre-computation: Capture Timestamp
1. **Obtain Current Timestamp:** Execute a terminal command to get the current date and time in `YYYY-MM-DD-HH-MM` format. (Example for Linux/macOS: `date +"%Y-%m-%d-%H-%M"`).
2. **Formulate Filename:** Use this timestamp and a descriptive task name (derived from user request or PRD) to construct the full filename, e.g., `docs/tasks/2023-10-27-14-35-implement-user-auth.md`.
## II. Information Gathering (CRITICAL PRE-REQUISITE)
- **Mandatory Context Review:** Before writing any part of the plan, you **MUST** find and thoroughly read all relevant files in the project's `docs/` directory. This is not optional.
- **Prioritized Documents:** Pay special attention to (if they exist):
- `docs/PRD.md` (Product Requirements Document)
- `docs/TECH_STACK.md`
- `docs/openapi.yaml` (or similar API specifications)
- `docs/logging.md`, `docs/LOGGING_GUIDE.md` (or any docs related to logging practices)
- `docs/TEST_STRATEGY.md`, `docs/TESTING_GUIDELINES.md` (or any docs related to testing)
- `NOTES.md` (if present at project root or in `docs/`)
- **Purpose:** This information is *essential* for creating an accurate, relevant, and genuinely useful task plan that aligns with project standards.
## III. Core Directive: Construct the Task Plan File
Create the content for the `docs/tasks/<YYYY-MM-DD-HH-MM-task-name>.md` file. This file outlines a step-by-step plan, broken down into a series of distinct commits (typically 2-5 commits per task). Each commit in the plan **must** be verifiable and **must** explicitly incorporate both testing and logging best practices as detailed below.
### A. Strict Operational Constraints
- **File Operations:**
- You are **ONLY** permitted to write to the specific task plan file you are creating (e.g., `docs/tasks/YYYY-MM-DD-HH-MM-task-name.md`).
- Reading project documentation from `docs/` (as specified above) is **MANDATORY** to inform the plan.
- **Communication Protocol:**
- **NO Conversational Output:** You are forbidden from generating any conversational output, commentary, preamble, or summaries *before* or *during* the creation of the task plan file content.
- **Output is the File Content:** Your *entire* output for this specific rule invocation must be *only* the complete, raw Markdown content of the `docs/tasks/<YYYY-MM-DD-HH-MM-task-name>.md` file.
- **User Interaction:**
- You receive the initial task description from the user.
- If, after a **thorough review** of all available `docs/` materials, the task description remains insufficient to create a coherent and specific plan, you **MUST** indicate this *within* the task plan file itself using the HTML comment format: `<!-- TODO: [Specify missing information and reference document, e.g., 'Need API endpoint for user creation (see docs/openapi.yaml)'] -->`. Do not invent details.
### B. Testing & Observability (Mandatory for Each Commit)
1. **Primary Verification = Automated Tests:** This is the preferred method.
- **First Choice: Unit Tests.** Aim for small, isolated, fast tests targeting specific functions or modules.
- **Second Choice: Integration Tests.** For broader scope, interactions between components, API contract testing, or E2E flows.
- **Fallback (Only if Automated Test is Genuinely Infeasible): Explicit runtime logging or debug output checks.** This must be justified.
2. **Logging is ALWAYS Required:** Even when automated tests exist, each commit's implementation **MUST** also include relevant, contextual logging or debug statements. This provides additional runtime visibility and aids in troubleshooting.
- **Toggleable Logging:** Logging should be configurable (e.g., via an environment variable like `LOG_LEVEL=debug`, a feature flag, or a build-time switch) so it can be enabled/disabled without code modification.
3. **Structured & Centralized Logs:**
- Prefer structured log output (e.g., JSON lines or clear `key="value"` pairs).
- Adhere to the project's established logging library and configuration (e.g., `pino`, `winston`). Reference the specific logger configuration file if known (e.g., `src/utils/logger.ts`).
- Ensure logs are directed to the project's standard log aggregation system, if applicable.
4. **Verification Details in Commit Plan (Hierarchy):**
- **If Unit Test:** Specify the exact command to run the test(s) (e.g., `pnpm test --filter user-service.test.ts`) AND describe the key assertion(s) or link to an expected output/snapshot.
- **If Integration Test:** Specify the exact command or script (e.g., `pnpm test:e2e --spec ./tests/e2e/auth.spec.ts`) AND describe the expected outcome or key behavior being verified.
- **If Log Inspection (Fallback):** Detail the precise steps to inspect logs (e.g., `kubectl logs -l app=api-service -c main-container --tail=100 | jq 'select(.msg == "PaymentProcessed")'`) and what specific log message/pattern/value to look for.
### C. `docs/tasks/<YYYY-MM-DD-HH-MM-task-name>.md` File Structure
The task file **MUST** be structured as a sequence of planned commits. The primary source for content is the user's task description, **validated, augmented, and detailed** with specific information (file paths, function names, API endpoints, configuration details) extracted from the relevant `docs/` files. **Neglecting to consult and incorporate details from project documentation is a critical failure.**
Each commit title **MUST** follow semantic commit style (e.g., `feat: ...`, `fix: ...`, `test: ...`, `docs: ...`, `chore: ...`) **and**
include the task filename in square brackets so each commit can be traced back to
its plan. Example: `feat: add login API [docs/tasks/2023-10-31-login.md]`.
```markdown
# Task: [Brief Task Title - Derived from user request, PRD, or overarching goal]
## Commit 1: [type: Clear, Descriptive Title for this specific commit]
**Description:**
[Explain the precise goal of *this commit*. Include specific file paths (e.g., `src/modules/auth/auth.controller.ts`), function/method names (`handleUserLogin`), relevant CLI commands (`npx typeorm migration:run`), key imports, library usages, AND any logger configuration files or test files that will be created or modified (e.g., `tests/unit/auth.controller.test.ts`, `src/config/logger.config.ts`). Be explicit and detailed.]
**Verification:**
1. **Automated Test(s):**
* **Command:** `[Exact command to run the test, e.g., pnpm vitest run src/modules/auth/auth.controller.test.ts]`
* **Expected Outcome:** `[Describe key assertion, e.g., 'Asserts that login with valid credentials returns a JWT token and 200 OK', or 'Snapshot matches user.snapshot']`
2. **Logging Check:**
* **Action:** `[How to trigger/observe logs, e.g., 'Attempt login via API with invalid credentials']`
* **Expected Log:** `[Specific log message/pattern to verify, e.g., 'INFO: Login attempt failed for user: test@example.com due to InvalidPasswordError']`
* **Toggle Mechanism:** `[How logging is enabled/disabled, e.g., 'LOG_LEVEL=info']`
---
## Commit 2: [type: Clear, Descriptive Title for this specific commit]
**Description:**
[Details for commit 2...]
**Verification:**
1. **Automated Test(s):**
* **Command:** `[...]`
* **Expected Outcome:** `[...]`
2. **Logging Check:**
* **Action:** `[...]`
* **Expected Log:** `[...]`
* **Toggle Mechanism:** `[...]`
---
(Repeat structure for up to 5 commits as needed for the task. For simple tasks, you may only need 1-2 commits.)
```
## IV. Post Task Plan Creation: Stop and Notify
Once the *entire content* of the `docs/tasks/<YYYY-MM-DD-HH-MM-task-name>.md` file has been generated (and is your sole output for this rule), **STOP**. Notify the user that the task plan is complete and available at the specified path.
**Immediately after** providing the file content, output a concise executive summary of all the planned commits so the user can quickly review the steps. This summary should not be part of the task plan file itself.
After the summary, await the user's next instructions.
**REMEMBER: Your output is SOLELY the Markdown content of the task plan file. This plan MUST be informed by `docs/` research, detail 2-5 verifiable commits, and rigorously include both automated tests and toggleable logging for each commit. Adhere strictly to the output format and communication constraints.**
Once the task plan is complete, wait for the user to provide feedback.
================================================
FILE: .cursor/rules/zen-coding.mdc
================================================
---
description:
globs:
alwaysApply: false
---
# Adhere to the Zen of Coding Principles
**Your primary goal: Internalize and apply the following principles to guide your coding decisions, striving for code that is clear, maintainable, and robust.**
These principles should influence how you approach problem-solving, structure your code, and handle complexities.
## Guiding Principles:
- Beautiful is better than ugly.
- Explicit is better than implicit.
- Simple is better than complex.
- Complex is better than complicated.
- Flat is better than nested.
- Sparse is better than dense.
- Readability counts.
- Special cases aren't special enough to break the rules.
- Although practicality beats purity.
- Errors should never pass silently.
- Unless explicitly silenced.
- In the face of ambiguity, refuse the temptation to guess.
- There should be one-- and preferably only one --obvious way to do it.
- (Though that way may not be obvious at first.)
- Now is better than never.
- Although never is often better than *right* now.
- If the implementation is hard to explain, it's a bad idea.
- If the implementation is easy to explain, it may be a good idea.
**REMEMBER: Let these tenets guide you towards writing code that is not only functional but also elegant and understandable.**
================================================
FILE: .cursor/workflows/development/benchmarks.md
================================================
# Create Benchmarks for a Function or Module
**Your task: Generate micro-benchmark tests to measure the performance of a specific function, class, or file.**
Follow these steps:
1. **Ensure Benchmark Directory:** If it doesn't already exist, create a top-level `benchmarks/` directory.
2. **Create Benchmark File:** Inside `benchmarks/`, create a file named after the target, using the `.bench.ts` extension (or `.js` if the project isn't using TypeScript).
3. **Use `tinybench`:** Install the `tinybench` library if not already present and import it in your benchmark file.
4. **Define Benchmark Cases:**
- Import the target function, class, or module.
- Set up one or more benchmark tasks with representative inputs.
- Run the benchmarks and log results in ops/sec.
5. **Add Package Script:** Add a `"benchmark"` script to `package.json` that runs the benchmark file with `pnpm benchmark`.
**REMEMBER: Benchmarks should live only in the `benchmarks/` directory and remain deterministic to provide meaningful performance measurements.**
================================================
FILE: .cursor/workflows/development/logging.md
================================================
# Session-Based Logging Rule
**Your Task: Implement structured logging so each application run writes to a separate file in the `logs/` directory.**
## File Existence Check
Verify logging directory and ignore file:
```bash
ls logs .gitignore
```
Create missing items if necessary before proceeding.
## I. Directory & Git Ignore
1. Ensure a `logs/` directory exists at the project root. Create it if missing.
2. Confirm `logs` (or `logs/`) is listed in `.gitignore` so log files are never committed.
## II. Log File Per Run
1. On startup, generate a timestamp `YYYY-MM-DD-HH-MM-SS`.
2. Create a new file `logs/<timestamp>.log` and append all log output to it.
3. Subsequent runs create new files, preserving previous logs for reference.
## III. Log Content
- Use a logger like `pino` or `winston`, or simple file writes if unavailable.
- Record start and end of major operations, successful paths, handled errors, and unexpected failures.
- Include relevant environment info such as CLI arguments and Node version.
## IV. Toggle Mechanism
- Logging is enabled by default.
- Provide an environment variable `LOG_LEVEL=off` or a command-line flag `--no-log` to disable file logging.
- When disabled, skip creating the log file and suppress log output.
## V. AI-Friendly Format
- Prefer structured lines (JSON or clearly delimited text) for easy ingestion by debugging tools and AI systems.
- Each entry should include level, timestamp, and message.
**REMEMBER: Logs must capture both happy paths and errors. Maintain readability while providing enough detail for effective troubleshooting.**
================================================
FILE: .cursor/workflows/development/scripts.md
================================================
# Create Script with TypeScript and Bun
- Create executable TypeScript scripts in a "./scripts" directory in the root of the project
- Use a `#!/usr/bin/env bun` shebang so it can be run with "./scripts/script-name.ts"
- Use `chmod +x` to make the script executable
**REMEMBER: All scripts should be TypeScript files in the scripts directory with bun shebang and executable permissions.**
================================================
FILE: .cursor/workflows/documentation/diagram.md
================================================
# Create GitHub-Compatible Mermaid Diagrams
**Your Task: When asked to create a diagram, generate it using Mermaid syntax suitable for rendering directly in GitHub Flavored Markdown. Store the diagram in a new file at `docs/diagrams/<diagram-name>.md`. Adhere strictly to the following rules to ensure compatibility and readability.**
## File Existence Check
Run the following command to see which source documents are available:
```bash
ls . docs
```
Use the output to know which files exist before proceeding.
## I. Preliminary Step: Gather Context for the Diagram
Before generating any diagram, you **MUST** attempt to read and understand the content of the following project documents (if they exist and are relevant to the diagram request):
- `NOTES.md`
- `docs/PRD.md` (Product Requirements Document)
- `docs/TECH_STACK.md`
- `docs/openapi.yaml` (or other API specifications)
- Any other architecture or design documents in `docs/` related to the subject of the diagram.
This context is essential for creating an accurate and meaningful diagram.
## II. Core Diagramming Rules for GitHub Mermaid
1. **Correct Fenced Code Block:**
- Always start the Mermaid block with triple backticks and `mermaid`: ` ```mermaid `.
- Always end the block with triple backticks: ` ``` `.
- **Example:**
````markdown
```mermaid
graph TD
A[Start] --> B{Decision};
B -- Yes --> C[Action 1];
B -- No --> D[Action 2];
```
````
```
```
2. **Use Well-Supported Diagram Types:**
GitHub generally has good support for these common types:
- `graph` (Flowcharts - `TD` or `TB` is often best for readability)
- `sequenceDiagram`
- `classDiagram`
- `stateDiagram-v2` (Prefer v2 for better features/rendering)
- `erDiagram` (Entity Relationship)
- `pie` (Pie charts)
- `gantt` (Gantt charts)
- `mindmap` (Basic indented structure only - **NO ICONS**)
- _Avoid newer or less common diagram types, as GitHub's Mermaid version may not be the latest._
3. **General Syntax Best Practices:**
- **Node IDs:** Use simple alphanumeric IDs (e.g., `node1`, `processA`). Avoid spaces or special characters in IDs.
- **Node/Actor/State Labels (CRITICAL):** **ALWAYS use double quotes (`"..."`)** for labels, especially if they contain spaces, punctuation, special characters (like hyphens, periods, colons), or Mermaid keywords. This is the most common source of rendering errors.
- **Correct:** `A["User Input: Text"] --> B["Validate Data (Step 1)"];`
- **Incorrect (Potential Error):** `A[User Input: Text] --> B[Validate Data (Step 1)];`
- **Arrows:** Use standard arrow types (`-->`, `---`, `==>`, `->>`, etc.).
- **Comments:** Use `%%` for comments within the Mermaid code if needed (e.g., `%% This is a comment %%`).
4. **`mindmap` Specifics for GitHub:**
- GitHub **supports the basic `mindmap` structure** using indentation (spaces or tabs) to define hierarchy.
- Each node/item **MUST** be on its own line with correct indentation relative to its parent.
- GitHub **DOES NOT support** advanced `mindmap` features like `::icon()` syntax. Using icons **WILL CAUSE RENDERING ERRORS**.
- Stick to plain text nodes for mind maps.
- **Correct `mindmap` (GitHub Compatible):**
```mermaid
mindmap
Root
Parent Node
Child Item 1
Child Item 2
```
- **Incorrect `mindmap` (GitHub Incompatible - Uses Icons):**
```mermaid
mindmap
Root
::icon(fa fa-star) Parent Node
::icon(fa fa-one) Child Item 1
```
5. **Layout Preference for Flowcharts (`graph`):**
- For `graph` diagrams, prefer `TD` (Top Down) or `TB` (Top Bottom) for better readability within Markdown document flow. Example: `graph TD;`.
6. **Styling: Let GitHub Handle It (CRITICAL):**
- **DO NOT** attempt to set themes (e.g., `%%{init: {'theme': 'dark'}}%%`).
- **DO NOT** try to apply custom styling using `classDef`, `style`, or inline CSS attributes _within the Mermaid code_.
- GitHub **ignores** these directives and applies its own styling based on the user's current GitHub theme (light, dark, or dimmed). Your diagram will adapt automatically. Forcing themes or styles will likely be ignored or look inconsistent.
7. **Keep Diagrams Focused and Manageable:**
- Avoid overly complex diagrams with an excessive number of nodes, edges, or deep nesting in a single block. While GitHub can render complex diagrams, they might become hard to read or hit rendering performance limits.
- If a concept is very complex, consider breaking it down into multiple, simpler, linked diagrams.
8. **Verification (If Possible):**
- If you have access to a GitHub Markdown preview environment, use it to test your Mermaid syntax. This is the best way to catch errors.
9. **Note on Automated Edits:**
- Be aware that automated code editing tools may sometimes struggle with precise changes within Mermaid blocks, especially with syntax sensitive to indentation (like mindmaps) or quoting.
- **Always carefully review any automated edits** made to Mermaid blocks. If errors occur or the diagram doesn't render as expected, manual correction might be required.
## III. Output File
- Place the generated Mermaid diagram (within its fenced code block) into a new Markdown file.
- Save the file to `docs/diagrams/<diagram-name>.md`, where `<diagram-name>` is a descriptive name for the diagram (e.g., `user-authentication-flow.md`, `database-schema.md`).
**REMEMBER: Your goal is to create a clear, accurate Mermaid diagram in `docs/diagrams/<diagram-name>.md` that renders correctly on GitHub. Key success factors are: using ` ```mermaid `, quoting all labels meticulously (`"Like This!"`), avoiding themes/custom styles, and for mindmaps, using only basic indentation (NO icons). Always gather context from project docs first.**
================================================
FILE: .cursor/workflows/documentation/openapi-spec.md
================================================
## OpenAPI Specification Management Rule
_This rule guides the creation and maintenance of the `docs/openapi.yaml` file._
## File Existence Check
Before editing, determine which related docs already exist:
```bash
ls . docs
```
Use this information to inform the following steps.
### Core Directive
Create and maintain an `docs/openapi.yaml` file, defining an OpenAPI specification (v3.0.x or 3.1.x). Operate based on information from `NOTES.md`, `docs/PRD.md`, `docs/TECH_STACK.md`, and the existing `docs/openapi.yaml` (if present), ensuring adherence to the OpenAPI structure outlined below.
### Strict Limitations
- **File Operations:** Only read `NOTES.md`, `docs/PRD.md`, `docs/TECH_STACK.md`, `docs/openapi.yaml` (or equivalents), and read/write to `docs/openapi.yaml`. Do not interact with other files.
- **Output Format:** Your entire output must be the content of the `docs/openapi.yaml` file itself.
- **Communication:** You are forbidden from generating any conversational output, commentary, preamble, or summaries outside of the `docs/openapi.yaml` file.
- **User Interaction (within `docs/openapi.yaml`):** You do not directly converse with the user. If sections of the `docs/openapi.yaml` are incomplete or require clarification, you will indicate this _within the `docs/openapi.yaml` file_ using a specific YAML comment format.
### OpenAPI Specification Structure and Content Source
The `docs/openapi.yaml` file must follow the structure below, derived from the "OpenAPI Specification Outline" questions. Aim for OpenAPI version 3.0.x or 3.1.x.
#### OpenAPI Specification Outline (Source for `docs/openapi.yaml` Structure and TODOs)
1. **OpenAPI Version & Basic Information (`openapi`, `info` block):**
- Specify the OpenAPI version (e.g., `openapi: 3.0.3`).
- **Title (`info.title`):** What is the official title for this API? (Source: `docs/PRD.md` - Project Name/Title. Example: "Customer Data API").
- **Version (`info.version`):** What is the current version of this API specification (e.g., "1.0.0", "v2.1-beta")?
- **Description (`info.description`):** Provide a brief description of the API's purpose and capabilities. (Source: `docs/PRD.md` - Project Purpose/Core Functionality. Example: "API for managing customer profiles and order history.").
- **(Optional) Contact (`info.contact`):**
- `name`: Contact person/team name (e.g., "API Support Team").
- `url`: URL to a support page or contact form.
- `email`: Contact email address (e.g., "apisupport@example.com").
- **(Optional) License (`info.license`):**
- `name`: SPDX license identifier (e.g., "Apache 2.0", "MIT").
- `url`: Link to the full license text.
2. **Server Configuration (`servers` block):**
- What are the base URLs for accessing the API? (Source: `docs/TECH_STACK.md` - Infrastructure & Deployment. Examples: `https://api.example.com/v1`, `https://sandbox.api.example.com/v1`).
- For each server, provide:
- `url`: The server URL.
- `description`: A human-readable description (e.g., "Production Server", "Sandbox Environment").
3. **Global Security Definitions (`components.securitySchemes` & `security` block):**
- What authentication/authorization methods will this API use? (Source: `docs/TECH_STACK.md` - Security Considerations. Examples: API Key, OAuth2, JWT Bearer Token).
- Define each scheme under `components.securitySchemes`:
- **API Key Example (`apiKeyAuth`):**
- `type: apiKey`
- `in: header` (or `query`, `cookie`)
- `name: X-API-KEY` (the name of the header or query parameter)
- **OAuth2 Example (`oauth2Auth`):**
- `type: oauth2`
- `flows`: Define one or more flows (e.g., `authorizationCode`, `clientCredentials`).
- `authorizationCode`:
- `authorizationUrl: https://auth.example.com/oauth/authorize`
- `tokenUrl: https://auth.example.com/oauth/token`
- `scopes`: Define available scopes (e.g., `read:profile`, `write:orders`).
- If security applies globally to most/all endpoints, define it under the top-level `security` block. (Example: `security: - apiKeyAuth: []`).
4. **Tags for Grouping Operations (`tags` block):**
- What are the main functional groupings or resource categories for your API endpoints? (Source: `docs/PRD.md` - Key Features/Modules. Examples: "Users", "Products", "Orders").
- For each tag, provide:
- `name`: The tag name (e.g., "UserManagement").
- `description`: A brief explanation of the tag (e.g., "Operations related to user accounts and profiles").
5. **Reusable Schemas (`components.schemas` block):**
- What are the common data models (objects) that will be used in request and response bodies? (Source: `docs/PRD.md` - Key Features, Data Models; `docs/TECH_STACK.md` - Database for entities. Examples: `User`, `Product`, `Order`, `ErrorResponse`).
- For each schema (e.g., `User`):
- `type: object`
- `properties`: Define its fields.
- For each property (e.g., `id`, `username`, `email`, `status`):
- `type`: (e.g., string, integer, boolean)
- `format`: (e.g., uuid, email, int64) (Optional)
- `description`: (A brief explanation of the property) (Optional)
- `example`: (A sample value) (Optional)
After outputting the full `docs/openapi.yaml` file, give a brief executive summary outlining the main endpoints or components you defined. This summary should not be included inside the YAML file itself.
================================================
FILE: .cursor/workflows/documentation/prd.md
================================================
# Generate and Maintain `docs/PRD.md` (Product Requirements Document)
**Your Core Task: Create or update the `docs/PRD.md` file. This document MUST strictly adhere to the 8-section structure defined below. Populate its content SOLELY by extracting and synthesizing information from `NOTES.md` (or a user-provided equivalent source). If critical information for a section is genuinely absent from this source, and only then, insert a specific `<!-- TODO: ... -->` comment.**
## File Existence Check
Confirm available source files first:
```bash
ls . docs
```
Use these results before proceeding.
Your entire output for this rule invocation **MUST BE ONLY** the complete, raw Markdown content of the `docs/PRD.md` file.
## I. Strict Operational Constraints (MANDATORY)
- **Permitted File Operations:**
- **Read-Only:** `NOTES.md` (or the specified primary input document if different).
- **Read/Write:** `docs/PRD.md` (this is the only file you will modify or create).
- **No Other Files:** Do not access, read, or write any other files in the project.
- **Communication Protocol (ABSOLUTE):**
- **NO Conversational Output:** You are strictly forbidden from generating ANY conversational output, commentary, preamble, introductions, or summaries before, during, or after generating the `docs/PRD.md` content.
- **Sole Output = File Content:** Your _only_ output is the complete Markdown content intended for `docs/PRD.md`.
- **User Interaction (Handled via TODOs in `docs/PRD.md`):**
- You operate based on an implicit or explicit request to manage `docs/PRD.md`.
- You do not converse directly with the user during this process.
- Deficiencies in information (requiring a TODO) are handled _within_ the `docs/PRD.md` file itself, as per the TODO logic below.
## II. The Blueprint: `docs/PRD.md` Structure & Content Source
The `docs/PRD.md` file **MUST** be organized into the following eight sections. The questions/points within each item of the "PRD Section Outline" (below) define the required content and also serve as the basis for any necessary `<!-- TODO: ... -->` comments if information is missing from the `NOTES.md` (or equivalent designated source document).
### PRD Section Outline (Mandatory Structure for `docs/PRD.md`)
1. **`## 1. Core Functionality & Purpose`**
- What is the primary problem this product/feature solves for the end-user?
- What is the core functionality required to address this problem?
2. **`## 2. Key Goals & Scope`**
- What are the critical objectives for this product/feature (e.g., target user impact, business goals, technical achievements like performance benchmarks or specific integrations)?
- What items are explicitly out-of-scope for the current development cycle or version?
3. **`## 3. User Interaction & Design Insights`**
- Who is the primary user type (e.g., API consumer, web application user, internal admin)?
- Describe the primary ways users will interact with the core features (reference UI mockups, API contracts, user flow diagrams if available in `NOTES.md` or linked external resources).
4. **`## 4. Essential Features & Implementation Highlights`**
- List the absolute must-have functionalities for the initial version/MVP.
- Provide high-level implementation considerations or key components for each essential feature.
5. **`## 5. Acceptance Criteria & Definition of "Done"`**
- For each key feature or user story, what are the specific, measurable, achievable, relevant, and time-bound (SMART) conditions that must be met for it to be considered "done"?
- How will successful completion be verified (e.g., specific tests, user validation scenarios)?
6. **`## 6. Key Requirements & Constraints`**
- List any non-negotiable technical requirements (e.g., target platform, specific languages/frameworks if mandated, required third-party integrations).
- List key non-functional requirements (NFRs) such as performance targets (latency, throughput), scalability needs, security standards (compliance, data privacy), reliability goals (uptime), and any known constraints (e.g., infrastructure limitations, budget, timelines).
7. **`## 7. Success Metrics`**
- How will the success of this product/feature be measured post-deployment from a user and business perspective (e.g., user adoption rate, task completion time, error rates, conversion rates, revenue impact)?
- (Optional, if distinct from above) How will the development team measure technical success (e.g., system stability, maintainability, code quality metrics)?
8. **`## 8. Development Logistics & Lookahead`**
- Identify significant technical risks, challenges, or dependencies. Include initial thoughts on mitigation strategies.
- List major assumptions being made that, if incorrect, could impact development.
- Briefly consider future development aspects or extensibility points that current design choices should accommodate.
## III. Workflow for Generating/Updating `docs/PRD.md`
1. **Access Source Document (`NOTES.md` or equivalent):**
- Read the content of `NOTES.md` (or the user-specified primary input document).
- _This is your ONLY source of information for populating `docs/PRD.md`._ If this document is missing or sparse, the `PRD.md` will reflect that (potentially with many TODOs).
- Read the current content of `docs/PRD.md` if it already exists (for context during updates).
2. **Manage `docs/PRD.md` Content:**
- **Initialization:** If `docs/PRD.md` does not exist, create it. Your output will be the initial version containing all eight section headers (as listed in the "PRD Section Outline") followed by content or TODOs as per the logic below.
- **Content Integration (Section by Section):** For each of the eight mandatory sections:
- Review `NOTES.md` (and `docs/PRD.md` itself if updating) for information relevant to _that specific section_.
- Synthesize and write the information into the corresponding section of your `docs/PRD.md` output. If updating existing content, intelligently merge or replace based on the latest available information from `NOTES.md`. Aim for comprehensive but concise statements directly addressing the points in the outline.
3. **Identify Gaps & Insert TODOs (Strict Logic):**
- After attempting to populate a section using **only `NOTES.md` (or the specified equivalent source)**:
- A `<!-- TODO: ... -->` comment **MUST ONLY** be inserted if the section in your generated `docs/PRD.md` remains **genuinely empty** OR contains only placeholder text (e.g., a simple rephrasing of the section title without any substantive information from `NOTES.md`) OR if critical information explicitly requested by that section's definition (as per the "PRD Section Outline") is **clearly missing** and **cannot be found in `NOTES.md`**.
- **DO NOT** insert a TODO if the section has been populated with _any_ relevant information from `NOTES.md`, even if that information could theoretically be more detailed. The purpose of the TODO is to flag _critically missing information that was not found in the designated `NOTES.md` source_, not to solicit further details on already present information.
- **TODO Comment Format:** `<!-- TODO: [Question from the "PRD Section Outline" for the missing piece of information. Be specific to the context if possible.] -->`
- Example for section 1 if core problem isn't in `NOTES.md`: `<!-- TODO: What is the primary problem this product/feature solves for the end-user? (Expected in NOTES.md) -->`
- Example for section 5 if acceptance criteria are absent: `<!-- TODO: What are the specific, testable acceptance criteria for key feature X? (Expected in NOTES.md) -->`
4. **Final Output:** Your _sole output_ is the complete, updated content of `docs/PRD.md`.
Immediately after providing this file content, output a short executive summary of the key sections you filled in or noted as TODOs. Keep this summary separate from the file content.
**REMEMBER: Your output MUST ONLY be the full Markdown content for `docs/PRD.md`. Populate it strictly from `NOTES.md` (or specified primary source). Follow the 8-section structure. Insert `<!-- TODO: ... -->` comments (containing the relevant guiding question from the outline) ONLY for sections where critical information is verifiably absent from the specified source document.**
================================================
FILE: .cursor/workflows/documentation/sync.md
================================================
# Synchronize Project Documentation with Recent Changes
**Your task: Review and update all project documentation within the `docs/` directory to ensure it accurately reflects the latest project state, recent code changes, and completed tasks.**
## File Existence Check
Identify which documentation directories and files exist:
```bash
ls . docs
```
Proceed based on the results.
Follow this process:
1. **Identify Recent Project Developments:**
- Review information about recently completed tasks (e.g., from `docs/tasks/`, task management systems if accessible, or summarized in recent discussions).
- Examine recent commit history for significant changes to code, features, or configurations.
- Consider any new features added or bugs fixed that might impact documentation.
2. **Thoroughly Review Documentation:**
- Read all files located within the `docs/` directory and its subdirectories.
- Pay close attention to READMEs, guides, architectural documents, and usage instructions.
3. **Identify and Update Discrepancies:**
- Compare the current documentation against the recent developments identified in Step 1.
- Identify any sections, instructions, diagrams, or examples in `docs/*` that are now out-of-date, inaccurate, or incomplete.
- Make the necessary modifications to these files to reflect the current state of the project accurately.
**Output:**
- Apply edits directly to the relevant files within the `docs/` directory.
- If significant changes are made, briefly summarize which documents were updated and the nature of the changes (e.g., "Updated `docs/API.md` to reflect new endpoint X and parameter Y.").
**REMEMBER: Your goal is to ensure all documentation in `docs/` is consistent, accurate, and fully synchronized with the project's latest developments. Outdated documentation can mislead users and developers.**
================================================
FILE: .cursor/workflows/documentation/tech-stack.md
================================================
# Generate and Maintain `docs/TECH_STACK.md`
**Your Core Task: Create or update the `docs/TECH_STACK.md` file. This document MUST strictly adhere to the 10-section structure defined below. Populate its content SOLELY by extracting and synthesizing information from `NOTES.md`, `docs/PRD.md`, and `docs/openapi.yaml` (or equivalent API specifications). If critical information for a section is genuinely absent from these sources, and only then, insert a specific `<!-- TODO: ... -->` comment.**
## File Existence Check
Determine which of the following files are present:
```bash
ls . docs
```
Use this list before editing.
Your entire output for this rule invocation **MUST BE ONLY** the complete, raw Markdown content of the `docs/TECH_STACK.md` file.
## I. Strict Operational Constraints (MANDATORY)
- **Permitted File Operations:**
- **Read-Only:** `NOTES.md`, `docs/PRD.md`, `docs/openapi.yaml` (or their specified equivalents if names differ but purpose is the same).
- **Read/Write:** `docs/TECH_STACK.md` (this is the only file you will modify or create).
- **No Other Files:** Do not access, read, or write any other files in the project.
- **Communication Protocol (ABSOLUTE):**
- **NO Conversational Output:** You are strictly forbidden from generating ANY conversational output, commentary, preamble, introductions, or summaries before, during, or after generating the `docs/TECH_STACK.md` content.
- **Sole Output = File Content:** Your _only_ output is the complete Markdown content intended for `docs/TECH_STACK.md`.
- **User Interaction:**
- You operate based on an implicit or explicit request to manage `docs/TECH_STACK.md`.
- You do not converse directly with the user during this process.
- Deficiencies in information (requiring a TODO) are handled _within_ the `docs/TECH_STACK.md` file itself, as per the TODO logic below.
## II. The Blueprint: `docs/TECH_STACK.md` Structure & Content Source
The `docs/TECH_STACK.md` file **MUST** be organized into the following ten sections. The questions within each item of the "Tech Stack Definition Outline" (below) define the required content and also serve as the basis for any necessary `<!-- TODO: ... -->` comments if information is missing from source documents.
### Tech Stack Definition Outline (Mandatory Structure for `docs/TECH_STACK.md`)
1. **`## 1. Project Overview & Goals`**
- _(Informed by `docs/PRD.md`)_ Briefly, what is the project this tech stack is for?
- _(Informed by `docs/PRD.md`)_ What are the primary goals influencing technology choices (e.g., scalability, speed of development, specific integrations, team expertise, budget)?
2. **`## 2. Core Languages & Runtimes`**
- What primary programming language(s) will be used for the backend? Specify version(s) if critical. Why this choice?
- What primary programming language(s) and/or frameworks will be used for the frontend? Specify version(s) if critical. Why this choice?
- Are there specific runtime environments required (e.g., Node.js version, Python version, JVM version, .NET version)?
3. **`## 3. Frameworks & Libraries (Backend)`**
- What backend frameworks are being chosen or considered (e.g., Django, Ruby on Rails, Spring Boot, Express.js, NestJS, ASP.NET Core)? Justify the choice.
- List key libraries essential for the backend (e.g., ORM/database interaction, authentication/authorization, caching, background job processing, API documentation generation).
4. **`## 4. Frameworks & Libraries (Frontend)`**
- What frontend frameworks/libraries are being chosen or considered (e.g., React, Angular, Vue, Svelte, Blazor)? Justify the choice.
- List key UI component libraries (e.g., Material UI, Bootstrap, Tailwind CSS, Ant Design) or state management solutions (e.g., Redux, Zustand, Pinia, NgRx) to be used.
5. **`## 5. Database & Data Storage`**
- _(Consider data types/relationships in `docs/PRD.md`)_ What type of database is required (e.g., Relational/SQL, NoSQL Document, NoSQL Key-Value, Graph, Time Series)? Why?
- Specify the chosen database system(s) (e.g., PostgreSQL, MySQL, MongoDB, Cassandra, Neo4j, InfluxDB).
- Are other data storage solutions needed (e.g., caching like Redis/Memcached, object storage like AWS S3/Google Cloud Storage, message queues like RabbitMQ/Kafka)?
6. **`## 6. Infrastructure & Deployment`**
- Where will the application be hosted (e.g., AWS, Azure, GCP, DigitalOcean, Vercel, Netlify, on-premise)?
- What specific services will be used (e.g., EC2, Lambda, Azure App Service, Google Kubernetes Engine)?
- What containerization technologies will be used (e.g., Docker, Podman)? Orchestration (e.g., Kubernetes, Docker Swarm)?
- What CI/CD tools and processes are planned (e.g., Jenkins, GitLab CI, GitHub Actions, CircleCI)?
7. **`## 7. APIs & Integrations`**
- _(Reference `docs/PRD.md` and `docs/openapi.yaml`)_ Will the project expose its own APIs? If so, what style (e.g., REST, GraphQL, gRPC, WebSockets)?
- _(Reference `docs/PRD.md`)_ What critical third-party services or APIs will be integrated (e.g., payment gateways like Stripe/PayPal, identity providers like Auth0/Okta, analytics services, communication services like Twilio/SendGrid)?
8. **`## 8. Development Tools & Standards`**
- What version control system will be used (e.g., Git)? Where will repositories be hosted (e.g., GitHub, GitLab, Bitbucket)?
- Are there specific IDEs, linters (e.g., ESLint, Pylint), or code formatting standards (e.g., Prettier, Black)?
- _(Reference `docs/PRD.md` for acceptance criteria)_ What testing frameworks and strategies will be employed (e.g., Jest, PyTest, JUnit, Cypress, Selenium; unit, integration, E2E testing)?
9. **`## 9. Security Considerations`**
- _(Reference `docs/PRD.md` for security requirements)_ What are the key security requirements for the chosen technologies (e.g., OWASP Top 10 mitigations)?
- Are there specific libraries, tools, or practices for security (e.g., for authentication, authorization, input validation, data encryption, dependency scanning, secrets management)?
10. **`## 10. Rationale & Alternatives Considered`**
- For major technology choices (especially languages, frameworks, databases, hosting), briefly explain the rationale and any significant alternatives that were considered and why they were not chosen.
## III. Workflow for Generating/Updating `docs/TECH_STACK.md`
1. **Access Source Documents:**
- Read the content of `NOTES.md` (if provided as an input or found).
- Read the content of `docs/PRD.md`.
- Read the content of `docs/openapi.yaml` (or equivalent API spec) if it exists.
- _These are your ONLY sources of information for populating `docs/TECH_STACK.md`._ If these documents are missing or sparse, the `TECH_STACK.md` will reflect that (potentially with TODOs).
- Read the current content of `docs/TECH_STACK.md` if it already exists.
2. **Manage `docs/TECH_STACK.md` Content:**
- **Initialization:** If `docs/TECH_STACK.md` does not exist, create it. Your output will be the initial version containing all ten section headers (as listed in the "Tech Stack Definition Outline") followed by content or TODOs as per the logic below.
- **Content Integration (Section by Section):** For each of the ten mandatory sections:
- Review `NOTES.md`, `docs/PRD.md`, and `docs/openapi.yaml` (and `TECH_STACK.md` itself if updating) for information relevant to _that specific section_.
- Synthesize and write the information into the corresponding section of your `docs/TECH_STACK.md` output. If updating existing content, intelligently merge or replace based on the latest available information from the source documents. Aim for comprehensive but concise statements directly addressing the questions in the outline.
3. **Identify Gaps & Insert TODOs (Strict Logic):**
- After attempting to populate a section using **all three source documents** (`NOTES.md`, `docs/PRD.md`, `docs/openapi.yaml`):
- A `<!-- TODO: ... -->` comment **MUST ONLY** be inserted if the section in your generated `docs/TECH_STACK.md` remains **genuinely empty** OR contains only placeholder text (e.g., a simple rephrasing of the section title without any substantive information from the sources) OR if critical information explicitly requested by that section's definition (as per the "Tech Stack Definition Outline") is **clearly missing** and **cannot be found in any of the speci
gitextract_61kki5cn/ ├── .cursor/ │ ├── GUIDE.md │ ├── PERSONALIZATION.md │ ├── rules/ │ │ ├── _/ │ │ │ └── .gitignore │ │ ├── _context/ │ │ │ └── .gitkeep │ │ ├── _core/ │ │ │ ├── communication.mdc │ │ │ ├── persona.mdc │ │ │ ├── prefer-clis.mdc │ │ │ ├── principles.mdc │ │ │ ├── standards.mdc │ │ │ └── terminal.mdc │ │ ├── _global.mdc │ │ ├── _globs/ │ │ │ ├── GLOBS.md │ │ │ └── react/ │ │ │ └── best-practices.mdc │ │ ├── benchmarks-create.mdc │ │ ├── cli-github-search.mdc │ │ ├── cli-pack.mdc │ │ ├── cli-worktree.mdc │ │ ├── cli-wrangler.mdc │ │ ├── docs-diagram.mdc │ │ ├── docs-openapi-spec.mdc │ │ ├── docs-prd.mdc │ │ ├── docs-structure.mdc │ │ ├── docs-sync.mdc │ │ ├── docs-tech-stack.mdc │ │ ├── gh-docs-sync.mdc │ │ ├── gh-task-continue.mdc │ │ ├── gh-task-execute.mdc │ │ ├── gh-task-plan.mdc │ │ ├── logging-session.mdc │ │ ├── pnpm-fixes.mdc │ │ ├── project-todos-next.mdc │ │ ├── project-update-rules.mdc │ │ ├── project-update-user-rules.mdc │ │ ├── prompt-improve.mdc │ │ ├── pull-request-create.mdc │ │ ├── react-rules.mdc │ │ ├── scripts-create.mdc │ │ ├── task-continue.mdc │ │ ├── task-execute.mdc │ │ ├── task-next.mdc │ │ ├── task-outline.mdc │ │ ├── task-plan.mdc │ │ └── zen-coding.mdc │ └── workflows/ │ ├── development/ │ │ ├── benchmarks.md │ │ ├── logging.md │ │ └── scripts.md │ ├── documentation/ │ │ ├── diagram.md │ │ ├── openapi-spec.md │ │ ├── prd.md │ │ ├── sync.md │ │ └── tech-stack.md │ ├── task/ │ │ └── parallel.md │ ├── tools/ │ │ ├── cli/ │ │ │ ├── ghx.md │ │ │ ├── repomix.md │ │ │ ├── worktree.md │ │ │ └── wrangler.md │ │ └── package-managers/ │ │ └── pnpm/ │ │ └── build-script-fixes.md │ └── workflows/ │ ├── analysis/ │ │ └── document-failures.md │ ├── config/ │ │ ├── personalize-rule.md │ │ └── update-personal-rules.md │ ├── dependencies/ │ │ └── audit.md │ ├── docs/ │ │ ├── structure.md │ │ └── sync.md │ ├── github/ │ │ ├── continue-github.md │ │ ├── execute-github.md │ │ ├── plan-github.md │ │ ├── pr-create-github.md │ │ └── review-github.md │ ├── meta/ │ │ └── create-workflow.md │ ├── project/ │ │ └── update-project-rules.md │ ├── prompts/ │ │ └── improve-prompt.md │ ├── scripts/ │ │ └── create-script.md │ └── task/ │ ├── continue.md │ ├── execute.md │ ├── next.md │ ├── outline.md │ ├── plan.md │ └── todos-next.md ├── .eslintrc.js ├── .github/ │ └── workflows/ │ └── jest.yml ├── .gitignore ├── .hive/ │ ├── issues.jsonl │ └── memories.jsonl ├── .husky/ │ └── pre-commit ├── .kodiak.toml ├── .node-version ├── .nvmrc ├── .storybook/ │ ├── main.js │ └── preview.js ├── @types/ │ ├── assets/ │ │ └── index.d.ts │ ├── browser-cookies.d.ts │ ├── cueplayer-react.d.ts │ ├── file-extension.d.ts │ ├── friendly-time.d.ts │ ├── humanize-list.d.ts │ ├── mdx.d.ts │ ├── react-textfit.d.ts │ ├── remove-markdown.d.ts │ └── tincanjs.d.ts ├── CLAUDE.md ├── LICENSE ├── README.md ├── ai/ │ └── diagrams/ │ ├── README.md │ ├── analytics-tracking-flow.md │ ├── auth-login-flow.md │ ├── course-progression-flow.md │ ├── email-automation-flow.md │ ├── form-submission-flow.md │ ├── free-user-pro-content-overlay-flow.md │ ├── inngest-background-jobs-flow.md │ ├── lesson-playback-flow.md │ ├── search-functionality-flow.md │ ├── stripe-payment-flow.md │ ├── subscription-access-control-flow.md │ ├── tip-creation-flow.md │ ├── trpc-api-flow.md │ ├── user-navigation-flow.md │ ├── video-upload-processing-flow.md │ ├── webhook-processing-flow.md │ ├── workshop-registration-flow.md │ └── xstate-machine-flow.md ├── bin/ │ └── validate ├── config/ │ └── jest/ │ └── cssTransform.js ├── cypress/ │ ├── fixtures/ │ │ └── example.json │ ├── integration/ │ │ └── spec.js │ ├── plugins/ │ │ └── index.js │ └── support/ │ ├── commands.js │ └── index.js ├── cypress.json ├── docs/ │ ├── decisions/ │ │ ├── 0001-adopt-architecture-decision-records.md │ │ ├── 0002-upgrade-next-mdx-remote-to-v6.md │ │ ├── 0003-direct-pg-course-shell.md │ │ └── README.md │ ├── latest-courses-component-plan.md │ ├── post-page-refactoring-plan.md │ ├── stripe-upgrade-analysis.md │ ├── stripe-upgrade-plan.md │ ├── tasks/ │ │ ├── 2025-06-02-11-40-ai-dev-essentials-landing-page.md │ │ ├── 2025-08-13-copy-as-prompt-feature.md │ │ └── 2025-08-18-14-35-stripe-sdk-upgrade.md │ └── typesense-new-lessons-feature.md ├── jest/ │ └── json-reporter.js ├── jest.config.js ├── next-env.d.ts ├── next-sitemap.js ├── next.config.mjs ├── package.json ├── postcss.config.js ├── prisma/ │ └── schema.prisma ├── public/ │ ├── bitmovin/ │ │ ├── bitmovinplayer-ui.css │ │ ├── bitmovinplayer-ui.js │ │ └── receiver.css │ ├── opensearch.xml │ ├── robots.txt │ ├── site.webmanifest │ ├── sitemap.xml │ ├── tags-sitemap-0.xml │ ├── tags-sitemap-1.xml │ ├── tags-sitemap-10.xml │ ├── tags-sitemap-11.xml │ ├── tags-sitemap-12.xml │ ├── tags-sitemap-13.xml │ ├── tags-sitemap-14.xml │ ├── tags-sitemap-15.xml │ ├── tags-sitemap-16.xml │ ├── tags-sitemap-17.xml │ ├── tags-sitemap-18.xml │ ├── tags-sitemap-19.xml │ ├── tags-sitemap-2.xml │ ├── tags-sitemap-20.xml │ ├── tags-sitemap-21.xml │ ├── tags-sitemap-22.xml │ ├── tags-sitemap-23.xml │ ├── tags-sitemap-24.xml │ ├── tags-sitemap-25.xml │ ├── tags-sitemap-26.xml │ ├── tags-sitemap-27.xml │ ├── tags-sitemap-28.xml │ ├── tags-sitemap-29.xml │ ├── tags-sitemap-3.xml │ ├── tags-sitemap-4.xml │ ├── tags-sitemap-5.xml │ ├── tags-sitemap-6.xml │ ├── tags-sitemap-7.xml │ ├── tags-sitemap-8.xml │ └── tags-sitemap-9.xml ├── rtl.setup.js ├── setupTests.ts ├── src/ │ ├── adapters/ │ │ └── stripe-adapter.ts │ ├── api/ │ │ ├── egghead/ │ │ │ └── users/ │ │ │ └── from-token.ts │ │ └── stripe/ │ │ ├── stripe-checkout-redirect.ts │ │ └── stripe-lifetime-checkout-redirect.ts │ ├── app/ │ │ ├── (content)/ │ │ │ ├── courses/ │ │ │ │ ├── [course]/ │ │ │ │ │ └── [lesson]/ │ │ │ │ │ ├── Player.tsx │ │ │ │ │ ├── PlayerSidebar.tsx │ │ │ │ │ └── page.tsx │ │ │ │ └── layout.tsx │ │ │ ├── lessons/ │ │ │ │ └── [slug]/ │ │ │ │ └── embed/ │ │ │ │ ├── _components/ │ │ │ │ │ ├── embed-lesson.css │ │ │ │ │ ├── embed-lesson.tsx │ │ │ │ │ ├── embed-player.tsx │ │ │ │ │ └── minimal-embed-player.tsx │ │ │ │ ├── layout.tsx │ │ │ │ └── page.tsx │ │ │ └── tips/ │ │ │ ├── [tipId]/ │ │ │ │ ├── edit/ │ │ │ │ │ ├── page.tsx │ │ │ │ │ └── tip-navigation.tsx │ │ │ │ └── page.tsx │ │ │ ├── _components/ │ │ │ │ └── tips-lists.tsx │ │ │ ├── layout.tsx │ │ │ ├── new/ │ │ │ │ └── page.tsx │ │ │ └── page.tsx │ │ ├── _components/ │ │ │ ├── compact-feed-skeleton.tsx │ │ │ ├── compact-feed.tsx │ │ │ ├── compact-hits.tsx │ │ │ ├── course-info.tsx │ │ │ └── search.tsx │ │ ├── _trpc/ │ │ │ ├── Provider.tsx │ │ │ ├── client.ts │ │ │ └── serverClient.ts │ │ ├── api/ │ │ │ ├── cron/ │ │ │ │ └── route.ts │ │ │ ├── deepgram/ │ │ │ │ └── webhook/ │ │ │ │ └── route.ts │ │ │ ├── feedback/ │ │ │ │ └── route.ts │ │ │ ├── inngest/ │ │ │ │ └── route.ts │ │ │ ├── lessons/ │ │ │ │ └── [slug]/ │ │ │ │ └── download/ │ │ │ │ └── route.ts │ │ │ ├── mux/ │ │ │ │ └── webhook/ │ │ │ │ └── route.ts │ │ │ ├── pricing/ │ │ │ │ └── route.ts │ │ │ ├── stripe/ │ │ │ │ └── checkout/ │ │ │ │ └── lifetime/ │ │ │ │ └── route.ts │ │ │ ├── trpc/ │ │ │ │ └── [trpc]/ │ │ │ │ └── route.ts │ │ │ ├── videos/ │ │ │ │ └── [videoResourceId]/ │ │ │ │ └── srt/ │ │ │ │ └── route.ts │ │ │ ├── webhooks/ │ │ │ │ ├── sanity/ │ │ │ │ │ └── route.ts │ │ │ │ ├── tips/ │ │ │ │ │ └── mux/ │ │ │ │ │ └── route.ts │ │ │ │ └── transloadit/ │ │ │ │ └── route.ts │ │ │ └── workshop-quote/ │ │ │ └── route.ts │ │ ├── blocked/ │ │ │ ├── _components/ │ │ │ │ └── blocked.tsx │ │ │ ├── layout.tsx │ │ │ └── page.tsx │ │ ├── layout.tsx │ │ ├── page.tsx │ │ ├── providers.tsx │ │ └── user/ │ │ ├── activity/ │ │ │ └── page.tsx │ │ ├── bookmarks/ │ │ │ └── page.tsx │ │ ├── layout.tsx │ │ ├── membership/ │ │ │ ├── layout.tsx │ │ │ └── page.tsx │ │ ├── profile/ │ │ │ └── page.tsx │ │ └── team/ │ │ └── page.tsx │ ├── components/ │ │ ├── EggheadPlayer/ │ │ │ ├── index.js │ │ │ ├── players/ │ │ │ │ ├── Base.js │ │ │ │ ├── Bitmovin.js │ │ │ │ └── YouTube.js │ │ │ ├── props.js │ │ │ ├── use-egghead-player.ts │ │ │ └── utils.js │ │ ├── GridBackground.tsx │ │ ├── app/ │ │ │ ├── app-footer.tsx │ │ │ ├── app-main.tsx │ │ │ ├── footer.tsx │ │ │ ├── header/ │ │ │ │ ├── banner-context.tsx │ │ │ │ ├── banner-data.ts │ │ │ │ ├── header-button-shaped-link.tsx │ │ │ │ ├── images.tsx │ │ │ │ ├── index.tsx │ │ │ │ ├── search-bar.tsx │ │ │ │ └── server-header-shell.tsx │ │ │ ├── layout.tsx │ │ │ ├── main.tsx │ │ │ └── team/ │ │ │ └── index.tsx │ │ ├── blog/ │ │ │ ├── article-course-card.tsx │ │ │ └── article-talk-card.tsx │ │ ├── buttons/ │ │ │ └── index.tsx │ │ ├── card/ │ │ │ ├── card.stories.mdx │ │ │ ├── heading.tsx │ │ │ ├── horizontal-resource-card.tsx │ │ │ ├── index.tsx │ │ │ ├── new-horizontal-resource-card.tsx │ │ │ ├── new-vertical-resource-card.tsx │ │ │ ├── overlay/ │ │ │ │ ├── overlay-horiztonal-resource-card.tsx │ │ │ │ └── overlay-vertical-resource-card.tsx │ │ │ ├── search-hit-resource-card.tsx │ │ │ ├── topic-page-horizontal-resource-card.tsx │ │ │ ├── vertical-resource-collection-card.tsx │ │ │ └── verticle-resource-card.tsx │ │ ├── code-block.tsx │ │ ├── community-resource.tsx │ │ ├── contributors.tsx │ │ ├── copy-as-prompt-button.tsx │ │ ├── copy-resource.tsx │ │ ├── course/ │ │ │ └── course-podcast.tsx │ │ ├── courses/ │ │ │ ├── course-card.tsx │ │ │ ├── latest-courses-feed.tsx │ │ │ └── new-lessons-badge.tsx │ │ ├── cta/ │ │ │ ├── email/ │ │ │ │ └── email-form.tsx │ │ │ └── sale/ │ │ │ ├── countdown-timer.tsx │ │ │ ├── header-banner.tsx │ │ │ ├── lifetime-header-banner.tsx │ │ │ ├── workshop-early-bird-header-banner.tsx │ │ │ └── workshop-header-banner.tsx │ │ ├── customer-io/ │ │ │ └── email-entry-form.tsx │ │ ├── dialog.tsx │ │ ├── external-tracked-link.tsx │ │ ├── feedback-input/ │ │ │ ├── images/ │ │ │ │ ├── Confounded.js │ │ │ │ ├── Ghost.js │ │ │ │ ├── Hearteyes.js │ │ │ │ ├── NeutralFace.js │ │ │ │ ├── Smile.js │ │ │ │ └── Sob.js │ │ │ └── index.tsx │ │ ├── five-stars.tsx │ │ ├── forms/ │ │ │ ├── generic-newsletter-signup.tsx │ │ │ ├── newsletter-signup.tsx │ │ │ └── quiz/ │ │ │ ├── completed-message.tsx │ │ │ ├── essay-question.tsx │ │ │ ├── multiple-choice-question.tsx │ │ │ ├── spinner.tsx │ │ │ └── submit.tsx │ │ ├── generic-error-boundary.tsx │ │ ├── grid/ │ │ │ └── index.tsx │ │ ├── guides/ │ │ │ └── guide-template.tsx │ │ ├── icons/ │ │ │ ├── bookmark.tsx │ │ │ ├── cancel.tsx │ │ │ ├── check.tsx │ │ │ ├── clock.tsx │ │ │ ├── closed-captioning.tsx │ │ │ ├── community-resource-icon.tsx │ │ │ ├── eggo.tsx │ │ │ ├── folder-download.tsx │ │ │ ├── icon-x.tsx │ │ │ ├── lock.tsx │ │ │ ├── rss.tsx │ │ │ ├── star.jsx │ │ │ ├── svg-icon.jsx │ │ │ └── tip-icons.tsx │ │ ├── image-with-placeholder.tsx │ │ ├── invoices/ │ │ │ └── index.tsx │ │ ├── last-resource.tsx │ │ ├── layouts/ │ │ │ ├── collection-page-layout.tsx │ │ │ ├── multi-module-collection-page-layout.tsx │ │ │ ├── php-collection-page-layout.tsx │ │ │ ├── scrimba-course-layout.tsx │ │ │ └── tag-list.tsx │ │ ├── like-button.tsx │ │ ├── link.tsx │ │ ├── login-required.tsx │ │ ├── markdown/ │ │ │ ├── mdx-components.tsx │ │ │ ├── mdx.tsx │ │ │ ├── serialize-mdx.ts │ │ │ ├── shiki-remote-plugin.ts │ │ │ └── transcript-components.tsx │ │ ├── markdown.tsx │ │ ├── mdx/ │ │ │ ├── article-series-list.tsx │ │ │ ├── callout.tsx │ │ │ ├── card.js │ │ │ ├── cheat-sheet.js │ │ │ ├── code-block.tsx │ │ │ ├── course-widget.tsx │ │ │ ├── course.tsx │ │ │ ├── email-subscribe-widget.tsx │ │ │ ├── header-card.js │ │ │ ├── index.tsx │ │ │ ├── prose-section.js │ │ │ ├── question-reveal.js │ │ │ ├── resource-link.js │ │ │ ├── resource-widget.tsx │ │ │ └── topic-interest-form.tsx │ │ ├── monitoring/ │ │ │ ├── ai-dev-essentials-error-boundary.tsx │ │ │ └── performance-monitor.tsx │ │ ├── pages/ │ │ │ ├── 20-days-of-egghead/ │ │ │ │ └── course-grid.tsx │ │ │ ├── confirm/ │ │ │ │ └── membership/ │ │ │ │ ├── index.tsx │ │ │ │ └── membership.stories.mdx │ │ │ ├── courses/ │ │ │ │ ├── dialog-button.tsx │ │ │ │ ├── instructor-profile.tsx │ │ │ │ ├── learner-ratings.tsx │ │ │ │ ├── membership-dialog-button.tsx │ │ │ │ ├── play-icon.tsx │ │ │ │ └── user-rating/ │ │ │ │ └── user-rating.tsx │ │ │ ├── email-confirmation.tsx │ │ │ ├── home/ │ │ │ │ ├── cta.tsx │ │ │ │ ├── egghead-for-teams-cta.tsx │ │ │ │ ├── first-hit-card.tsx │ │ │ │ ├── hits.tsx │ │ │ │ ├── in-progress-section/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── jumbotron.tsx │ │ │ │ ├── search.tsx │ │ │ │ ├── the-feed.tsx │ │ │ │ ├── topics.tsx │ │ │ │ └── video-card/ │ │ │ │ └── index.tsx │ │ │ ├── invoice/ │ │ │ │ ├── index.tsx │ │ │ │ ├── invoice.stories.mdx │ │ │ │ └── mock-transaction.ts │ │ │ ├── landing/ │ │ │ │ ├── article/ │ │ │ │ │ └── index.mdx │ │ │ │ ├── browse/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── create-account/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── footer/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── header/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── join/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── membership-benefits/ │ │ │ │ │ └── index.tsx │ │ │ │ └── tech-logos/ │ │ │ │ └── index.tsx │ │ │ ├── lessons/ │ │ │ │ ├── code-link.tsx │ │ │ │ ├── collection-lessons-list.test.ts │ │ │ │ ├── collection-lessons-list.tsx │ │ │ │ ├── comments/ │ │ │ │ │ ├── comment/ │ │ │ │ │ │ ├── comment.stories.mdx │ │ │ │ │ │ └── index.tsx │ │ │ │ │ ├── comment-field/ │ │ │ │ │ │ ├── comment-field.stories.mdx │ │ │ │ │ │ └── index.tsx │ │ │ │ │ └── comments/ │ │ │ │ │ ├── comments.stories.mdx │ │ │ │ │ └── index.tsx │ │ │ │ ├── course.tsx │ │ │ │ ├── lesson/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── lesson-info.tsx │ │ │ │ ├── next-up-list.tsx │ │ │ │ ├── overlay/ │ │ │ │ │ ├── anon-user-overlay.tsx │ │ │ │ │ ├── confirm-membership.tsx │ │ │ │ │ ├── email-capture-cta-overlay.tsx │ │ │ │ │ ├── go-pro-cta-overlay.tsx │ │ │ │ │ ├── rate-course-overlay/ │ │ │ │ │ │ ├── index.tsx │ │ │ │ │ │ └── rate-course-overlay.stories.mdx │ │ │ │ │ ├── recommend-next-step-overlay/ │ │ │ │ │ │ ├── index.tsx │ │ │ │ │ │ ├── lesson-01.js │ │ │ │ │ │ └── recommend-next-step-overlay.stories.mdx │ │ │ │ │ ├── small-parity-coupon-message.tsx │ │ │ │ │ ├── watch-full-course-cta-overlay.tsx │ │ │ │ │ ├── watch-next-lesson-cta-overlay.tsx │ │ │ │ │ └── wrapper.tsx │ │ │ │ ├── overlays.tsx │ │ │ │ ├── playback-speed-select.tsx │ │ │ │ ├── special-lessons.ts │ │ │ │ ├── tags.tsx │ │ │ │ ├── theater-mode-toggle.tsx │ │ │ │ └── transcript.tsx │ │ │ ├── level-up/ │ │ │ │ └── email-entry-form.tsx │ │ │ ├── own-your-online-presence/ │ │ │ │ └── email-entry-form.tsx │ │ │ ├── user/ │ │ │ │ ├── components/ │ │ │ │ │ ├── avatar-form.tsx │ │ │ │ │ ├── bookmarks-list.tsx │ │ │ │ │ ├── completed-courses.tsx │ │ │ │ │ ├── continue-learning.tsx │ │ │ │ │ ├── delete-account.tsx │ │ │ │ │ ├── index.tsx │ │ │ │ │ ├── learner-stats.tsx │ │ │ │ │ ├── request-email-change-form.tsx │ │ │ │ │ ├── request-name-change-form.tsx │ │ │ │ │ ├── subscription-details.tsx │ │ │ │ │ ├── user-layout.tsx │ │ │ │ │ └── widget-wrapper.tsx │ │ │ │ ├── index.tsx │ │ │ │ └── tabs-content/ │ │ │ │ ├── activity-tab-content.tsx │ │ │ │ ├── bookmarks-tab-content.tsx │ │ │ │ ├── instructor-tab-content.tsx │ │ │ │ └── profile-tab-content.tsx │ │ │ └── users/ │ │ │ └── dashboard/ │ │ │ ├── achievements/ │ │ │ │ ├── achievements.stories.mdx │ │ │ │ └── index.tsx │ │ │ └── activity/ │ │ │ ├── activity.stories.mdx │ │ │ ├── continue-watching-section.tsx │ │ │ ├── in-progress-resource.tsx │ │ │ └── recently-watched-section.tsx │ │ ├── player/ │ │ │ ├── autoplay-control.tsx │ │ │ ├── download-control.tsx │ │ │ ├── player-sidebar.test.ts │ │ │ └── player-sidebar.tsx │ │ ├── podcasts/ │ │ │ ├── card/ │ │ │ │ ├── card.stories.mdx │ │ │ │ └── card.tsx │ │ │ ├── more/ │ │ │ │ ├── more.stories.mdx │ │ │ │ └── more.tsx │ │ │ └── podcast/ │ │ │ ├── podcast.stories.mdx │ │ │ └── podcast.tsx │ │ ├── posts/ │ │ │ ├── ai-dev-essentials-list.tsx │ │ │ ├── claude-code-cta-overlay.tsx │ │ │ ├── course-lesson-cta.tsx │ │ │ ├── icons/ │ │ │ │ └── github-icon.tsx │ │ │ ├── instructor-profile.tsx │ │ │ ├── podcast-links.tsx │ │ │ ├── post-player.tsx │ │ │ ├── powered-by-mux.tsx │ │ │ ├── tag-list.tsx │ │ │ └── video-player-overlay.tsx │ │ ├── pricing/ │ │ │ ├── countdown/ │ │ │ │ └── index.tsx │ │ │ ├── lifetime/ │ │ │ │ ├── active-sale.tsx │ │ │ │ ├── body-copy-full.tsx │ │ │ │ ├── body-copy-member.tsx │ │ │ │ ├── lifetime-pricing-widget.tsx │ │ │ │ └── upcoming-sale.tsx │ │ │ ├── parity-coupon-message.tsx │ │ │ ├── powered-by-stripe.tsx │ │ │ ├── pricing-widget/ │ │ │ │ └── index.tsx │ │ │ ├── select-plan/ │ │ │ │ └── index.tsx │ │ │ ├── select-plan-new/ │ │ │ │ ├── assets/ │ │ │ │ │ ├── best-value-stamp.tsx │ │ │ │ │ └── colored-background.tsx │ │ │ │ └── index.tsx │ │ │ ├── stepper/ │ │ │ │ └── index.tsx │ │ │ └── testimonials/ │ │ │ ├── data.ts │ │ │ ├── index.tsx │ │ │ └── testimonials.stories.mdx │ │ ├── pro-member-features.tsx │ │ ├── route-loading-indicator.tsx │ │ ├── safe-image.tsx │ │ ├── scrimba-resource.tsx │ │ ├── search/ │ │ │ ├── components/ │ │ │ │ ├── callout.tsx │ │ │ │ ├── card.tsx │ │ │ │ ├── cta-card.tsx │ │ │ │ ├── hit/ │ │ │ │ │ ├── hit.stories.mdx │ │ │ │ │ └── index.tsx │ │ │ │ ├── no-search-results.tsx │ │ │ │ ├── preset-options.tsx │ │ │ │ ├── resource.tsx │ │ │ │ └── topic.tsx │ │ │ ├── curated/ │ │ │ │ ├── [slug]/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── angularjs/ │ │ │ │ │ ├── angularjs-page-data.ts │ │ │ │ │ ├── angularjs-page.stories.mdx │ │ │ │ │ └── index.tsx │ │ │ │ ├── aws/ │ │ │ │ │ ├── aws-page-data.ts │ │ │ │ │ ├── aws-page.stories.mdx │ │ │ │ │ └── index.tsx │ │ │ │ ├── css/ │ │ │ │ │ ├── css-page-data.ts │ │ │ │ │ ├── css-page.stories.mdx │ │ │ │ │ ├── index.tsx │ │ │ │ │ └── sanity-loading-data.tsx │ │ │ │ ├── curated-essential.tsx │ │ │ │ ├── default-cta.tsx │ │ │ │ ├── docker/ │ │ │ │ │ ├── docker-page-data.ts │ │ │ │ │ └── index.tsx │ │ │ │ ├── gatsby/ │ │ │ │ │ ├── gatsby-page-data.ts │ │ │ │ │ └── index.tsx │ │ │ │ ├── graphql/ │ │ │ │ │ ├── graphql-page-data.ts │ │ │ │ │ ├── graphql-page.stories.mdx │ │ │ │ │ └── index.tsx │ │ │ │ ├── index.tsx │ │ │ │ ├── javascript/ │ │ │ │ │ ├── index.tsx │ │ │ │ │ ├── javascript-page-data.ts │ │ │ │ │ └── javascript-page.stories.mdx │ │ │ │ ├── next/ │ │ │ │ │ ├── index.tsx │ │ │ │ │ └── next-page.stories.mdx │ │ │ │ ├── node/ │ │ │ │ │ ├── index.tsx │ │ │ │ │ ├── node-page-data.ts │ │ │ │ │ └── node-page.stories.mdx │ │ │ │ ├── react/ │ │ │ │ │ ├── index.tsx │ │ │ │ │ ├── react-page-data.ts │ │ │ │ │ └── react-page.stories.mdx │ │ │ │ ├── remix/ │ │ │ │ │ └── index.tsx │ │ │ │ └── typescript/ │ │ │ │ ├── index.tsx │ │ │ │ ├── typescript-page-data.ts │ │ │ │ └── typescript-page.stories.mdx │ │ │ ├── generic-topic.tsx │ │ │ ├── hits.tsx │ │ │ ├── index.tsx │ │ │ ├── instructors/ │ │ │ │ ├── alex-reardon/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── chris-achard/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── chris-biscardi/ │ │ │ │ │ ├── chris-biscardi-page-data.ts │ │ │ │ │ └── index.tsx │ │ │ │ ├── christian-nwamba/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── colby-fayock/ │ │ │ │ │ ├── colby-fayock-page.stories.mdx │ │ │ │ │ └── index.tsx │ │ │ │ ├── dan-abramov/ │ │ │ │ │ ├── dan-abramov-page-data.ts │ │ │ │ │ ├── dan-abramov-page.stories.mdx │ │ │ │ │ └── index.tsx │ │ │ │ ├── filip-hric/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── flavio-corpa/ │ │ │ │ │ ├── flavio-corpa-page-data.ts │ │ │ │ │ └── index.tsx │ │ │ │ ├── hiroko-nishimura/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── index.tsx │ │ │ │ ├── instructor-essential.tsx │ │ │ │ ├── jamund-ferguson/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── john-lindquist/ │ │ │ │ │ ├── index.tsx │ │ │ │ │ ├── john-lindquist-page-data.ts │ │ │ │ │ └── script-kit-cta.tsx │ │ │ │ ├── kadi-kraman/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── kamran-ahmed/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── kent-c-dodds/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── kevin-cunningham/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── kristian-freeman/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── kyle-shevlin/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── laurie-barth/ │ │ │ │ │ ├── index.tsx │ │ │ │ │ └── laurie-barth-page-data.ts │ │ │ │ ├── lazar-nikolov/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── matias-hernandez/ │ │ │ │ │ └── index.tsx │ │ │ │ ├── resource-cta.tsx │ │ │ │ ├── ryan-chenkie/ │ │ │ │ │ └── index.tsx │ │ │ │ └── stephanie-eckles/ │ │ │ │ └── index.tsx │ │ │ ├── pagination.tsx │ │ │ ├── refinement-list.tsx │ │ │ ├── search-box.tsx │ │ │ └── stats.tsx │ │ ├── share-bluesky.tsx │ │ ├── share.tsx │ │ ├── spinner/ │ │ │ ├── index.tsx │ │ │ └── spinner.stories.mdx │ │ ├── survey/ │ │ │ ├── data/ │ │ │ │ └── post-purchase-survey-data.ts │ │ │ ├── header-button-survey.tsx │ │ │ ├── level-up-cta.tsx │ │ │ ├── online-presence-cta.tsx │ │ │ ├── portfolio-foundations.tsx │ │ │ ├── post-purchase.tsx │ │ │ ├── project-club.tsx │ │ │ ├── questions/ │ │ │ │ ├── multi-line.tsx │ │ │ │ └── multiple-choice-question.tsx │ │ │ ├── survey-reducer.test.js │ │ │ ├── survey-reducer.ts │ │ │ └── survey.tsx │ │ ├── tag-image.tsx │ │ ├── talks/ │ │ │ ├── page-seo.tsx │ │ │ ├── talk-player.css │ │ │ └── talk-player.tsx │ │ ├── team/ │ │ │ ├── account-ownership-transfer.tsx │ │ │ ├── billing-section.tsx │ │ │ ├── copy-to-clipboard.tsx │ │ │ ├── member-table.tsx │ │ │ ├── remove-member-confirm-dialog.tsx │ │ │ ├── team-name.tsx │ │ │ └── transfer-ownership-confirm-dialog.tsx │ │ ├── tips/ │ │ │ ├── related-tips.tsx │ │ │ ├── styles.css │ │ │ ├── tip-card.tsx │ │ │ ├── tip-player.tsx │ │ │ ├── tip-teaser.tsx │ │ │ ├── tip-template.tsx │ │ │ ├── tip-uploader.tsx │ │ │ └── ui/ │ │ │ ├── card.tsx │ │ │ └── markdown-codeblock.tsx │ │ ├── tweet-resource.tsx │ │ ├── ui/ │ │ │ ├── code-block-with-copy.tsx │ │ │ └── switch.tsx │ │ ├── upload/ │ │ │ ├── modern-react-s3-uploader.tsx │ │ │ ├── s3upload.js │ │ │ └── video-uploader.tsx │ │ ├── users/ │ │ │ ├── request-email-change-form.tsx │ │ │ ├── saml-sign-in-form.tsx │ │ │ └── subscription-details.tsx │ │ ├── video/ │ │ │ └── video-transcript.tsx │ │ ├── workshop/ │ │ │ ├── claude-code/ │ │ │ │ ├── Hero.tsx │ │ │ │ ├── SignUpForm.tsx │ │ │ │ ├── active-sale-with-ppp-mock.tsx │ │ │ │ ├── active-sale.stories.mdx │ │ │ │ ├── active-sale.stories.tsx │ │ │ │ ├── active-sale.tsx │ │ │ │ ├── contact-form.tsx │ │ │ │ ├── cta-section.tsx │ │ │ │ ├── hero-logo.tsx │ │ │ │ ├── instructor-terminal.tsx │ │ │ │ ├── ppp-demo.stories.tsx │ │ │ │ ├── ppp-pricing-demo.tsx │ │ │ │ └── workshop-history.tsx │ │ │ ├── cursor/ │ │ │ │ ├── Conclusion.tsx │ │ │ │ ├── Features.tsx │ │ │ │ ├── Hero.tsx │ │ │ │ ├── SignUpForm.tsx │ │ │ │ ├── TestimonialBar.tsx │ │ │ │ ├── WorkshopStructure.tsx │ │ │ │ ├── active-sale.tsx │ │ │ │ ├── team/ │ │ │ │ │ ├── contact-form.tsx │ │ │ │ │ ├── hero.tsx │ │ │ │ │ ├── workshop-audience.tsx │ │ │ │ │ ├── workshop-benefits.tsx │ │ │ │ │ ├── workshop-content.tsx │ │ │ │ │ └── workshop-value.tsx │ │ │ │ └── ui/ │ │ │ │ ├── button.tsx │ │ │ │ ├── input.tsx │ │ │ │ └── utils.ts │ │ │ ├── shared/ │ │ │ │ ├── Instructor.tsx │ │ │ │ ├── animations.ts │ │ │ │ ├── cta-section.tsx │ │ │ │ ├── invoices/ │ │ │ │ │ ├── invoice-card.tsx │ │ │ │ │ ├── invoice-custom-text.tsx │ │ │ │ │ ├── invoice-print-button.tsx │ │ │ │ │ ├── invoice-teaser.tsx │ │ │ │ │ └── types.ts │ │ │ │ ├── parity-coupon-message.tsx │ │ │ │ ├── styles.css │ │ │ │ ├── testimonial.tsx │ │ │ │ └── time-and-location.tsx │ │ │ └── workshop-cta.tsx │ │ ├── workshop-transactions/ │ │ │ └── index.tsx │ │ └── write-for-egghead/ │ │ └── topic-list.tsx │ ├── config.ts │ ├── context/ │ │ └── viewer-context.tsx │ ├── data/ │ │ ├── courseDependencies.ts │ │ ├── courseDependenciesData.js │ │ ├── hot-content-slugs.json │ │ ├── hot-lesson-paths.json │ │ ├── hot-search-paths.json │ │ ├── podcast-archive.json │ │ ├── sorting-hat.ts │ │ └── test-survey.ts │ ├── db/ │ │ └── index.ts │ ├── emails/ │ │ ├── basic-email.tsx │ │ ├── lifetime-promo-email.tsx │ │ └── specific-product-email.tsx │ ├── hooks/ │ │ ├── mux/ │ │ │ ├── get-next-section.ts │ │ │ ├── use-global-player-shortcut.ts │ │ │ ├── use-mux-player.tsx │ │ │ ├── use-next-lesson.ts │ │ │ ├── use-player-prefs.ts │ │ │ └── use-video-player-overlay.tsx │ │ ├── next-data-sections.tsx │ │ ├── use-account.ts │ │ ├── use-affiliate-assigner.tsx │ │ ├── use-cio.tsx │ │ ├── use-commerce-machine.ts │ │ ├── use-convertkit-form.ts │ │ ├── use-copy-as-prompt.ts │ │ ├── use-egghead-schedule.tsx │ │ ├── use-enhanced-transcript.ts │ │ ├── use-experience-api.tsx │ │ ├── use-file-upload-reducer.tsx │ │ ├── use-identity-required.tsx │ │ ├── use-last-resource.tsx │ │ ├── use-lesson.tsx │ │ ├── use-load-topic-data.ts │ │ ├── use-logrocket.tsx │ │ ├── use-mux-player.tsx │ │ ├── use-next-up-data.tsx │ │ ├── use-purchase-and-play.ts │ │ ├── use-question.ts │ │ ├── use-share-course-review.tsx │ │ ├── use-token-signer.tsx │ │ └── use-video-resource.tsx │ ├── icons/ │ │ └── index.tsx │ ├── inngest/ │ │ ├── events/ │ │ │ ├── course-unpublished-event.ts │ │ │ ├── deepgram-webhook.ts │ │ │ ├── guide-published.ts │ │ │ ├── identify-customer-io.ts │ │ │ ├── index-lessons-forever-event.ts │ │ │ ├── lifetime-purchase.ts │ │ │ ├── mux-add-srt-to-asset.ts │ │ │ ├── mux-webhook.ts │ │ │ ├── received-transloadit-notification.ts │ │ │ ├── sanity/ │ │ │ │ └── webhooks/ │ │ │ │ └── lesson/ │ │ │ │ └── created.ts │ │ │ ├── sanity-course-document-created.ts │ │ │ ├── sanity-post.ts │ │ │ ├── send-feedback-email.ts │ │ │ ├── send-slack-message.ts │ │ │ ├── specific-product-purchase.ts │ │ │ ├── stripe-webhook.ts │ │ │ ├── tips.ts │ │ │ ├── transcript-requested.ts │ │ │ ├── verified-transloadit-notification.ts │ │ │ ├── video-uploaded.ts │ │ │ └── workshop-quote-request.ts │ │ ├── functions/ │ │ │ ├── create-course/ │ │ │ │ ├── index.ts │ │ │ │ └── utils/ │ │ │ │ ├── addLessonsToCourse.ts │ │ │ │ ├── createCourseInRails.ts │ │ │ │ ├── createEggAxios.ts │ │ │ │ ├── saveCourseDataToSanity.ts │ │ │ │ ├── updateOwnerToInstructor.ts │ │ │ │ └── upsertCourseToTypesense.ts │ │ │ ├── create-lesson.ts │ │ │ ├── handle-transloadit-notification.ts │ │ │ ├── identify-customer-io.ts │ │ │ ├── index-lessons.ts │ │ │ ├── lifetime-purchase.ts │ │ │ ├── mux/ │ │ │ │ ├── add-srt-to-mux-asset.ts │ │ │ │ └── mux-webhooks-handlers.ts │ │ │ ├── send-feedback-email.ts │ │ │ ├── send-slack-message.ts │ │ │ ├── send-specific-product-email.ts │ │ │ ├── send-workshop-quote-email.ts │ │ │ ├── stripe-webhook-handlers.ts │ │ │ ├── tip-video-uploaded.ts │ │ │ ├── transcript-ready.ts │ │ │ ├── typesense/ │ │ │ │ ├── delete-document.ts │ │ │ │ └── upsert-guide-to-typesense.ts │ │ │ └── video-uploaded.ts │ │ ├── inngest.config.ts │ │ ├── inngest.server.ts │ │ └── utils/ │ │ ├── lifetime-helpers.ts │ │ ├── specific-product-helpers.ts │ │ ├── stripe-helpers.ts │ │ └── stripe-webhook-utils.ts │ ├── layouts/ │ │ ├── fancy-guide.tsx │ │ ├── index.tsx │ │ └── ultimate-guide.tsx │ ├── lib/ │ │ ├── __tests__/ │ │ │ ├── course-builder-db.test.ts │ │ │ ├── course-resources.integration.test.ts │ │ │ ├── course-slugs.test.ts │ │ │ ├── email-change-requests.test.ts │ │ │ ├── format-content-as-prompt.test.ts │ │ │ ├── get-course-builder-metadata.test.ts │ │ │ ├── get-post.test.ts │ │ │ ├── load-lesson.integration.test.ts │ │ │ ├── markdown-dependency-compat.test.ts │ │ │ ├── playlists.integration.test.ts │ │ │ ├── podcasts.test.ts │ │ │ └── search-url-builder.test.ts │ │ ├── accounts.ts │ │ ├── ai-dev-essentials.ts │ │ ├── collections.ts │ │ ├── config.ts │ │ ├── contacts.ts │ │ ├── course-builder-db.ts │ │ ├── course-builder.ts │ │ ├── course-card.ts │ │ ├── course-resources.ts │ │ ├── course-slugs.ts │ │ ├── courses/ │ │ │ ├── get-latest-courses.ts │ │ │ ├── types.ts │ │ │ └── utils.ts │ │ ├── courses-query.ts │ │ ├── courses.ts │ │ ├── current-user.ts │ │ ├── customer-io.ts │ │ ├── customer.ts │ │ ├── db.ts │ │ ├── debug-logger.ts │ │ ├── deepgram-order-transcript.ts │ │ ├── deepgram-results-processor.ts │ │ ├── email-change-requests.ts │ │ ├── feature-flags.ts │ │ ├── format-content-as-prompt.ts │ │ ├── get-course-builder-metadata.ts │ │ ├── get-mux-options.ts │ │ ├── gifts.ts │ │ ├── guides-from-course-builder.ts │ │ ├── hot-content-slugs.ts │ │ ├── hot-lesson-paths.ts │ │ ├── hot-search-paths.ts │ │ ├── instructor-feed.ts │ │ ├── instructor-slug-aliases.ts │ │ ├── instructors.ts │ │ ├── jumbotron.ts │ │ ├── lesson-comments.ts │ │ ├── lessons.ts │ │ ├── likes.ts │ │ ├── load-course-builder-metadata-wrapper.ts │ │ ├── load-guide-wrapper.ts │ │ ├── logging.ts │ │ ├── mux.ts │ │ ├── name-to-slug.ts │ │ ├── playlists.ts │ │ ├── podcasts.ts │ │ ├── posthog-client.ts │ │ ├── posts/ │ │ │ ├── get-course.ts │ │ │ ├── get-post.ts │ │ │ ├── get-tags.ts │ │ │ └── utils.ts │ │ ├── posts-query.ts │ │ ├── prices.ts │ │ ├── progress.ts │ │ ├── ratings.ts │ │ ├── sale.ts │ │ ├── sanity-allowlist.ts │ │ ├── search-url-builder.ts │ │ ├── search-url-state.ts │ │ ├── search.ts │ │ ├── series-ranker.ts │ │ ├── slack.ts │ │ ├── srt-processor.ts │ │ ├── subscriptions.ts │ │ ├── tags.ts │ │ ├── teams.ts │ │ ├── tips.ts │ │ ├── upstash-redis.ts │ │ ├── users.ts │ │ ├── video-resources.ts │ │ └── viewer.ts │ ├── machines/ │ │ ├── __tests__/ │ │ │ ├── auth-token-polling-machine.test.ts │ │ │ └── commerce-machine.test.ts │ │ ├── auth-token-polling-machine.ts │ │ ├── commerce-machine.ts │ │ ├── confirmation-dialog-machine.ts │ │ ├── draft-course-machine.ts │ │ ├── lesson-machine.ts │ │ ├── request-email-change-machine.ts │ │ └── strong-confirmation-dialog-machine.ts │ ├── markdown/ │ │ ├── mdx-components.tsx │ │ ├── mdx.tsx │ │ ├── serialize-mdx.ts │ │ ├── shiki-remote-plugin.ts │ │ └── transcript-components.tsx │ ├── middleware.ts │ ├── module-builder/ │ │ ├── cloudinary-video-uploader.ts │ │ ├── create-tip-form.tsx │ │ ├── edit-tip-form.tsx │ │ ├── get-unique-filename.ts │ │ ├── upload-file.ts │ │ ├── use-file-change.ts │ │ └── video-uploader.tsx │ ├── next-seo.json │ ├── pages/ │ │ ├── 20-days.tsx │ │ ├── 404.tsx │ │ ├── 500.tsx │ │ ├── [post].tsx │ │ ├── _app.tsx │ │ ├── _document.tsx │ │ ├── _error.tsx │ │ ├── account-ownership-transfer/ │ │ │ └── [guid].tsx │ │ ├── answer/ │ │ │ └── online-presence.tsx │ │ ├── api/ │ │ │ ├── aws/ │ │ │ │ └── sign-s3.ts │ │ │ ├── cio/ │ │ │ │ └── identify/ │ │ │ │ └── [id].ts │ │ │ ├── cio-subscriber.ts │ │ │ ├── cors.ts │ │ │ ├── courses/ │ │ │ │ └── [slug]/ │ │ │ │ └── authed-bits.ts │ │ │ ├── discord.ts │ │ │ ├── newsletter/ │ │ │ │ └── subscribe.ts │ │ │ ├── og/ │ │ │ │ └── og-default.tsx │ │ │ ├── progress.ts │ │ │ ├── sanity/ │ │ │ │ └── lessons/ │ │ │ │ └── create.ts │ │ │ ├── schedule.ts │ │ │ ├── stripe/ │ │ │ │ ├── billing/ │ │ │ │ │ └── session.ts │ │ │ │ ├── checkout/ │ │ │ │ │ └── session.ts │ │ │ │ ├── transaction.ts │ │ │ │ └── webhook.ts │ │ │ ├── timeout.ts │ │ │ ├── topic.tsx │ │ │ ├── users/ │ │ │ │ ├── check-pro-status.ts │ │ │ │ ├── current.test.ts │ │ │ │ └── current.ts │ │ │ └── webhooks/ │ │ │ └── sanity/ │ │ │ └── videoResource/ │ │ │ ├── created.ts │ │ │ └── updated.ts │ │ ├── ask.tsx │ │ ├── blank.tsx │ │ ├── bookmarks/ │ │ │ └── index.tsx │ │ ├── case-studies/ │ │ │ ├── [slug].tsx │ │ │ └── index.tsx │ │ ├── clubs/ │ │ │ └── portfolio-project.mdx │ │ ├── code-of-conduct.mdx │ │ ├── collections/ │ │ │ └── [slug].tsx │ │ ├── confirm/ │ │ │ ├── forever.tsx │ │ │ └── membership.tsx │ │ ├── confirm.tsx │ │ ├── confirmed.tsx │ │ ├── courses/ │ │ │ ├── [course]/ │ │ │ │ └── index.tsx │ │ │ └── index.tsx │ │ ├── developer-portfolio-foundations/ │ │ │ ├── [slug].tsx │ │ │ └── index.mdx │ │ ├── discord/ │ │ │ ├── callback.tsx │ │ │ └── index.tsx │ │ ├── egghead-for-teams.tsx │ │ ├── email-change-request/ │ │ │ └── [token].tsx │ │ ├── faq.mdx │ │ ├── forever/ │ │ │ ├── email/ │ │ │ │ └── index.tsx │ │ │ └── index.tsx │ │ ├── gifts/ │ │ │ └── claim/ │ │ │ └── [guid].tsx │ │ ├── guides/ │ │ │ ├── [slug].tsx │ │ │ └── index.tsx │ │ ├── i/ │ │ │ └── [slug]/ │ │ │ ├── atom.xml.tsx │ │ │ ├── feed.json.tsx │ │ │ └── rss.xml.tsx │ │ ├── instructor/ │ │ │ └── index.tsx │ │ ├── invoices/ │ │ │ ├── [stripeTransactionId].tsx │ │ │ └── index.tsx │ │ ├── learn/ │ │ │ ├── 30x500/ │ │ │ │ ├── index.mdx │ │ │ │ └── sales-safari/ │ │ │ │ └── index.mdx │ │ │ ├── [slug].tsx │ │ │ ├── developer-portfolio/ │ │ │ │ └── index.tsx │ │ │ ├── digital-gardening/ │ │ │ │ └── index.tsx │ │ │ ├── javascript/ │ │ │ │ ├── es6.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── interact-DOM/ │ │ │ │ │ └── index.mdx │ │ │ │ ├── javascript-introduction/ │ │ │ │ │ └── index.mdx │ │ │ │ └── the-dom/ │ │ │ │ ├── DOMScroller.js │ │ │ │ ├── NodesScroller.js │ │ │ │ └── index.mdx │ │ │ ├── react/ │ │ │ │ ├── beginners/ │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── js-before-react.mdx │ │ │ │ │ ├── wtf-is-jsx.mdx │ │ │ │ │ └── wtf-is-react.mdx │ │ │ │ ├── index.mdx │ │ │ │ └── toolkit-or-framework.mdx │ │ │ └── state-management/ │ │ │ └── index.tsx │ │ ├── lessons/ │ │ │ └── [slug].tsx │ │ ├── level-up/ │ │ │ └── index.mdx │ │ ├── login.tsx │ │ ├── logout.tsx │ │ ├── newsletters/ │ │ │ └── ai-dev-essentials.tsx │ │ ├── own-your-online-presence/ │ │ │ ├── [slug].tsx │ │ │ └── index.mdx │ │ ├── playlists/ │ │ │ └── [slug].tsx │ │ ├── podcasts/ │ │ │ └── [slug].tsx │ │ ├── portfolios/ │ │ │ ├── [slug].tsx │ │ │ └── index.tsx │ │ ├── pricing/ │ │ │ ├── email/ │ │ │ │ └── index.tsx │ │ │ └── index.tsx │ │ ├── privacy.mdx │ │ ├── projects/ │ │ │ ├── build-a-developer-blog-with-gatsby/ │ │ │ │ └── index.tsx │ │ │ ├── build-modern-layouts-with-css-grid/ │ │ │ │ └── index.tsx │ │ │ ├── create-an-ecommerce-store-with-next-js-and-stripe-checkout/ │ │ │ │ └── index.tsx │ │ │ ├── introduction-to-cloudflare-workers/ │ │ │ │ └── index.tsx │ │ │ └── the-beginner-s-guide-to-vue-3/ │ │ │ └── index.tsx │ │ ├── q/ │ │ │ └── [[...all]].tsx │ │ ├── redirect.tsx │ │ ├── server-sitemap.xml/ │ │ │ └── index.tsx │ │ ├── signup/ │ │ │ ├── [topic].tsx │ │ │ └── index.tsx │ │ ├── site-directory/ │ │ │ ├── [tag].tsx │ │ │ ├── index.tsx │ │ │ └── tags.json │ │ ├── talks/ │ │ │ ├── [slug].tsx │ │ │ └── index.tsx │ │ ├── team/ │ │ │ └── index.tsx │ │ ├── team-invite/ │ │ │ └── [token].tsx │ │ ├── tipz/ │ │ │ └── index.tsx │ │ ├── topics.tsx │ │ ├── unsubscribed.tsx │ │ ├── upload/ │ │ │ └── index.tsx │ │ ├── workshop/ │ │ │ ├── claude-code/ │ │ │ │ ├── boss.tsx │ │ │ │ ├── index.tsx │ │ │ │ └── invoice/ │ │ │ │ └── [merchantChargeId].tsx │ │ │ ├── cursor/ │ │ │ │ ├── index.tsx │ │ │ │ ├── invoice/ │ │ │ │ │ └── [merchantChargeId].tsx │ │ │ │ └── team/ │ │ │ │ └── index.tsx │ │ │ └── email/ │ │ │ └── index.tsx │ │ └── write-for-egghead/ │ │ └── index.mdx │ ├── player/ │ │ ├── context.tsx │ │ ├── hls-source.tsx │ │ ├── index.ts │ │ ├── player.tsx │ │ └── selectors.ts │ ├── schemas/ │ │ ├── collection.ts │ │ ├── exercise.ts │ │ ├── guide.ts │ │ ├── lesson.ts │ │ ├── list.ts │ │ ├── module.ts │ │ ├── post.ts │ │ ├── resource.ts │ │ ├── section.ts │ │ ├── subscriber.ts │ │ ├── testimonial.ts │ │ └── video-resource.ts │ ├── server/ │ │ ├── __tests__/ │ │ │ ├── ability.test.ts │ │ │ ├── process-customer-cookies.test.ts │ │ │ └── with-header-banner-props.test.ts │ │ ├── ability.ts │ │ ├── content-query-canonicalization.ts │ │ ├── customer-io-cookies.ts │ │ ├── egghead-user-cookies.ts │ │ ├── get-middleware-response.ts │ │ ├── header-banners.ts │ │ ├── nxtp-query.ts │ │ ├── prisma.ts │ │ ├── process-customer-cookies.ts │ │ ├── rewrite-next-response-to-path.ts │ │ ├── routers/ │ │ │ ├── _app.ts │ │ │ ├── course.ts │ │ │ ├── customer-io.ts │ │ │ ├── feature-flag.ts │ │ │ ├── instructor.ts │ │ │ ├── lesson.ts │ │ │ ├── likes.ts │ │ │ ├── progress.ts │ │ │ ├── stripe.ts │ │ │ ├── subscription-detail.ts │ │ │ ├── tips.ts │ │ │ ├── topics.ts │ │ │ └── user.ts │ │ ├── search-query-canonicalization.ts │ │ ├── transformer.ts │ │ ├── trpc.ts │ │ └── with-header-banner-props.ts │ ├── spinner.tsx │ ├── stories/ │ │ ├── Button.jsx │ │ ├── Button.stories.js │ │ ├── Configure.mdx │ │ ├── Header.jsx │ │ ├── Header.stories.js │ │ ├── Page.jsx │ │ ├── Page.stories.js │ │ ├── assets/ │ │ │ └── avif-test-image.avif │ │ ├── button.css │ │ ├── header.css │ │ └── page.css │ ├── styles/ │ │ ├── cueplayer.css │ │ ├── icons.css │ │ ├── index.css │ │ └── material-theme-dark.json │ ├── types.ts │ ├── ui/ │ │ ├── alert.tsx │ │ ├── button.tsx │ │ ├── card.tsx │ │ ├── form.tsx │ │ ├── index.tsx │ │ ├── input.tsx │ │ ├── label.tsx │ │ ├── progress.tsx │ │ ├── select.tsx │ │ ├── skeleton.tsx │ │ ├── textarea.tsx │ │ └── utils.ts │ └── utils/ │ ├── __tests__/ │ │ ├── auth.test.ts │ │ ├── compacted-merge.test.ts │ │ ├── configured-graphql-client.test.ts │ │ ├── lesson-metadata.test.ts │ │ ├── typesense-host.test.ts │ │ └── with-timeout.test.ts │ ├── affiliate-token.ts │ ├── analytics/ │ │ ├── __tests__/ │ │ │ └── ai-dev-essentials.test.ts │ │ ├── ai-dev-essentials.ts │ │ ├── events.ts │ │ ├── identify.ts │ │ ├── index.ts │ │ └── track.ts │ ├── auth.ts │ ├── axios-request-id.ts │ ├── breakpoints.ts │ ├── cio/ │ │ ├── cio-identify.ts │ │ ├── get-cio-id-from-cookie.ts │ │ ├── report-cio-api-error.ts │ │ └── subscriber-attributes.ts │ ├── code.ts │ ├── compacted-merge.ts │ ├── configured-axios.ts │ ├── configured-graphql-client.ts │ ├── configured-libhoney.ts │ ├── convert-undefined-values-to-null.ts │ ├── cookies.ts │ ├── email-is-valid.ts │ ├── fetcher.ts │ ├── format-duration.ts │ ├── get-access-token-from-cookie.ts │ ├── honeycomb-tracer.ts │ ├── is-browser.ts │ ├── is-member.ts │ ├── lesson-metadata.ts │ ├── make-store.tsx │ ├── noop.ts │ ├── parse-header-cookie.ts │ ├── parse-server-cookie.ts │ ├── preprocess-mdx.ts │ ├── prettify-url.ts │ ├── query-params-present.ts │ ├── recur.tsx │ ├── remember-email.ts │ ├── request-contact-guid.ts │ ├── request-id.ts │ ├── request-signin-email.ts │ ├── sanity-client.ts │ ├── sanity-server.ts │ ├── sanity.fetch.only.server.ts │ ├── search/ │ │ └── topic-extractor.ts │ ├── send-an-email.ts │ ├── sleep.ts │ ├── srt-to-webvtt.js │ ├── stripe-customer.ts │ ├── stripe.ts │ ├── structured-log.ts │ ├── test/ │ │ └── simulated-clock.ts │ ├── time-utils.ts │ ├── tracing-js/ │ │ └── dist/ │ │ ├── src/ │ │ │ ├── deterministic-sampler.d.ts │ │ │ ├── deterministic-sampler.js │ │ │ ├── generate-id.d.ts │ │ │ ├── generate-id.js │ │ │ ├── headers.d.ts │ │ │ ├── headers.js │ │ │ ├── index.d.ts │ │ │ ├── index.js │ │ │ ├── setup-fetch.d.ts │ │ │ ├── setup-fetch.js │ │ │ ├── setup-http.d.ts │ │ │ ├── setup-http.js │ │ │ ├── shared.d.ts │ │ │ ├── shared.js │ │ │ ├── span-context.d.ts │ │ │ ├── span-context.js │ │ │ ├── span.d.ts │ │ │ ├── span.js │ │ │ ├── tags.d.ts │ │ │ ├── tags.js │ │ │ ├── tracer.d.ts │ │ │ └── tracer.js │ │ └── types/ │ │ └── libhoney.d.ts │ ├── typesense-host.ts │ ├── typesense.ts │ ├── video/ │ │ ├── default-handle-continue.ts │ │ └── handle-play-from-beginning.ts │ ├── with-timeout.ts │ └── workshop.ts ├── studio/ │ ├── .gitignore │ ├── .node-version │ ├── README.md │ ├── deskStructure.ts │ ├── package.json │ ├── plugins/ │ │ └── .gitkeep │ ├── resolvePreviewUrl.js │ ├── resolveProductionUrl.js │ ├── sanity.cli.ts │ ├── sanity.config.tsx │ ├── sanity.json.template │ ├── schemas/ │ │ ├── components/ │ │ │ ├── path-input.module.css │ │ │ ├── path-input.tsx │ │ │ └── portable-text-editor-components.tsx │ │ ├── documents/ │ │ │ ├── bigIdea.tsx │ │ │ ├── caseStudy.tsx │ │ │ ├── category.ts │ │ │ ├── collaborator.tsx │ │ │ ├── course.ts │ │ │ ├── email-address.ts │ │ │ ├── email-broadcast.ts │ │ │ ├── email-template.ts │ │ │ ├── essentialQuestion.ts │ │ │ ├── lesson.ts │ │ │ ├── person.tsx │ │ │ ├── podcastEpisode.ts │ │ │ ├── podcastSeason.ts │ │ │ ├── post.ts │ │ │ ├── resource.tsx │ │ │ ├── section.ts │ │ │ ├── software-library.tsx │ │ │ ├── tip.ts │ │ │ └── videoResource.ts │ │ ├── objects/ │ │ │ ├── author-reference.jsx │ │ │ ├── blockContent.js │ │ │ ├── blockText.js │ │ │ ├── body-portable-text.js │ │ │ ├── cta.js │ │ │ ├── email-send-at.ts │ │ │ ├── excerpt-portable-text.js │ │ │ ├── image-url.jsx │ │ │ ├── link.js │ │ │ ├── main-image.js │ │ │ ├── markdownText.js │ │ │ ├── muxAsset.js │ │ │ ├── production-process-state.js │ │ │ ├── scrimba-resource.js │ │ │ ├── seo.js │ │ │ ├── string-list.js │ │ │ └── versioned-software-library.jsx │ │ ├── plugs/ │ │ │ └── ctaPlug.js │ │ └── schema.js │ ├── set_sanity_env │ ├── src/ │ │ ├── components/ │ │ │ └── logo.tsx │ │ └── structure/ │ │ ├── blog.js │ │ ├── caseStudies.js │ │ ├── courses.js │ │ ├── feature.js │ │ ├── lessons.js │ │ ├── pages.js │ │ ├── portfolio.js │ │ ├── resources-courses.js │ │ ├── resources.js │ │ ├── tips.js │ │ └── videos.js │ ├── static/ │ │ └── .gitkeep │ ├── tsconfig.json │ └── webhook_projections/ │ └── courseCreate.groq ├── tags-sitemap.js ├── tailwind.config.js ├── test-copy-button.js ├── tsconfig.json └── vercel.json
SYMBOL INDEX (214 symbols across 4 files)
FILE: config/jest/cssTransform.js
method process (line 2) | process() {
method getCacheKey (line 5) | getCacheKey() {
FILE: jest/json-reporter.js
class GithubActionsReporter (line 1) | class GithubActionsReporter {
method constructor (line 2) | constructor(globalConfig, options) {
method onRunComplete (line 7) | onRunComplete(contexts, results) {
FILE: next.config.mjs
constant IMAGE_HOST_DOMAINS (line 25) | const IMAGE_HOST_DOMAINS = compact([
method redirects (line 99) | async redirects() {
FILE: public/bitmovin/bitmovinplayer-ui.js
function i (line 29) | function i(s, a) {
function t (line 70) | function t(e, t) {
function e (line 86) | function e(e, t, n) {
function e (line 162) | function e() {}
function o (line 266) | function o() {
function t (line 280) | function t() {
function o (line 328) | function o() {
function t (line 344) | function t(t) {
function o (line 414) | function o() {
function t (line 429) | function t(t) {
function o (line 516) | function o() {
function t (line 531) | function t(t) {
function o (line 596) | function o() {
function t (line 611) | function t(t) {
function o (line 678) | function o() {
function t (line 693) | function t() {
function o (line 727) | function o() {
function t (line 742) | function t(t) {
function o (line 785) | function o() {
function t (line 801) | function t(t) {
function o (line 887) | function o() {
function t (line 904) | function t(t) {
function o (line 988) | function o() {
function t (line 1004) | function t(t) {
function o (line 1076) | function o() {
function t (line 1091) | function t(t) {
function o (line 1162) | function o() {
function t (line 1177) | function t(t) {
function o (line 1238) | function o() {
function t (line 1252) | function t(t) {
function o (line 1306) | function o() {
function t (line 1321) | function t(t) {
function e (line 1360) | function e(e) {
function o (line 1569) | function o() {
function t (line 1586) | function t(t) {
function o (line 1682) | function o() {
function t (line 1700) | function t(t) {
function o (line 1772) | function o() {
function t (line 1789) | function t(t) {
function o (line 1866) | function o() {
function t (line 1881) | function t(t) {
function o (line 1960) | function o() {
function t (line 1976) | function t(t) {
function o (line 2096) | function o() {
function t (line 2112) | function t(t) {
function o (line 2169) | function o() {
function t (line 2185) | function t(t) {
function o (line 2290) | function o() {
function t (line 2307) | function t(t) {
function o (line 2407) | function o() {
function t (line 2424) | function t(t) {
function t (line 2509) | function t(t) {
function o (line 2562) | function o() {
function t (line 2579) | function t(t) {
function o (line 2738) | function o() {
function t (line 2757) | function t(t) {
function o (line 2821) | function o() {
function t (line 2836) | function t(t) {
function o (line 2916) | function o() {
function t (line 2931) | function t(t) {
function o (line 3009) | function o() {
function t (line 3033) | function t(t) {
function o (line 3175) | function o() {
function t (line 3191) | function t(t) {
function o (line 3303) | function o() {
function t (line 3318) | function t(t) {
function o (line 3358) | function o() {
function t (line 3376) | function t(t) {
function t (line 3448) | function t(t) {
function o (line 3519) | function o() {
function t (line 3542) | function t(t) {
function e (line 4174) | function e(e, t, n) {
function o (line 4282) | function o() {
function t (line 4301) | function t(t) {
function o (line 4500) | function o() {
function t (line 4516) | function t(t) {
function o (line 4598) | function o() {
function t (line 4621) | function t(t) {
function o (line 4863) | function o() {
function t (line 4885) | function t(t, n, o) {
function o (line 4991) | function o() {
function t (line 5008) | function t(t) {
function o (line 5138) | function o() {
function t (line 5152) | function t(t) {
function o (line 5200) | function o() {
function t (line 5214) | function t(t) {
function o (line 5256) | function o() {
function t (line 5271) | function t(t) {
function o (line 5328) | function o() {
function t (line 5345) | function t(t) {
function o (line 5442) | function o() {
function t (line 5456) | function t(t) {
function o (line 5498) | function o() {
function t (line 5513) | function t() {
function o (line 5547) | function o() {
function t (line 5567) | function t(t) {
function t (line 5767) | function t(t) {
function e (line 5807) | function e() {
function e (line 5883) | function e(e) {
function t (line 5945) | function t(t) {
function o (line 6011) | function o() {
function t (line 6027) | function t(t) {
function o (line 6077) | function o() {
function t (line 6092) | function t(t) {
function o (line 6195) | function o() {
function t (line 6210) | function t(t) {
function o (line 6294) | function o() {
function t (line 6309) | function t(t) {
function o (line 6395) | function o() {
function t (line 6410) | function t(t) {
function o (line 6506) | function o() {
function t (line 6521) | function t(t) {
function o (line 6619) | function o() {
function t (line 6634) | function t(t) {
function o (line 6707) | function o() {
function t (line 6722) | function t(t) {
function o (line 6806) | function o() {
function t (line 6820) | function t(t) {
function o (line 6867) | function o() {
function t (line 6883) | function t(t) {
function o (line 6936) | function o() {
function e (line 6952) | function e() {
function t (line 7065) | function t() {
function e (line 7080) | function e(e) {
function o (line 7142) | function o() {
function t (line 7170) | function t(t) {
function o (line 7328) | function o() {
function t (line 7343) | function t(t) {
function o (line 7391) | function o() {
function t (line 7406) | function t(t) {
function o (line 7502) | function o() {
function t (line 7517) | function t(t) {
function o (line 7585) | function o(e, t) {
function i (line 7595) | function i(e, t, n) {
function r (line 7602) | function r(e) {
function s (line 7608) | function s(e, t) {
function a (line 7611) | function a(e, t) {
function e (line 7622) | function e(e, t, n) {
function o (line 7847) | function o() {
function t (line 7862) | function t(t) {
function o (line 7954) | function o() {
function t (line 7969) | function t(t) {
function o (line 8087) | function o() {
function t (line 8102) | function t(t) {
function o (line 8211) | function o() {
function t (line 8230) | function t(t) {
function o (line 8520) | function o() {
function t (line 8535) | function t(t) {
function o (line 8606) | function o() {
function t (line 8623) | function t(t) {
function o (line 8718) | function o() {
function t (line 8733) | function t(t) {
function o (line 8851) | function o() {
function t (line 8866) | function t(t) {
function o (line 8922) | function o() {
function t (line 8937) | function t(t) {
function o (line 9015) | function o() {
function t (line 9030) | function t(t) {
function t (line 9094) | function t(e, t) {
function n (line 9127) | function n() {
function e (line 9272) | function e(e, t) {
function o (line 9648) | function o() {
function e (line 9663) | function e() {
function e (line 9715) | function e(e, t) {
function t (line 9739) | function t(t, n) {
function t (line 9789) | function t() {
function e (line 9805) | function e() {
function e (line 9877) | function e(e) {
function t (line 10782) | function t(e) {
function n (line 10785) | function n(e) {
function r (line 10796) | function r(t) {
function s (line 10800) | function s(e, t) {
function a (line 10806) | function a(e) {
function t (line 10827) | function t(e) {
function e (line 10866) | function e(e, t) {
function t (line 10913) | function t() {
function n (line 10931) | function n(t, n) {
function o (line 10934) | function o(t) {
function i (line 10939) | function i(t, o) {
function r (line 10944) | function r(t) {
function t (line 10970) | function t(t, n) {
function n (line 10985) | function n(e) {
function i (line 11016) | function i(e, t) {
function r (line 11020) | function r(e, t, n) {
function s (line 11039) | function s(e, n) {
function e (line 11103) | function e(t, n, r) {
function e (line 11208) | function e(e, t, n) {
function t (line 11303) | function t(t, n) {
function n (line 11306) | function n(t, n) {
function G (line 11311) | function G(t, n) {
function Y (line 11316) | function Y() {
function X (line 11415) | function X() {
function J (line 11454) | function J() {
function Z (line 11559) | function Z() {
function $ (line 11590) | function $() {
function ee (line 11630) | function ee(e, t) {
function te (line 11673) | function te(e, t) {
function ne (line 11696) | function ne(e, t) {
function o (line 11763) | function o(e) {
function o (line 11787) | function o() {
function e (line 11841) | function e(e, t, n) {
function e (line 12106) | function e(e, t, n) {
function t (line 12215) | function t() {
function e (line 12276) | function e(e) {
function t (line 12408) | function t(e, t) {
function e (line 12439) | function e(e) {
function e (line 12502) | function e(e) {
Copy disabled (too large)
Download .json
Condensed preview — 1234 files, each showing path, character count, and a content snippet. Download the .json file for the full structured content (104,924K chars).
[
{
"path": ".cursor/GUIDE.md",
"chars": 14149,
"preview": "# Rules and Workflows\n\n## Introduction\n\nThis document serves as a guide for understanding and utilizing the custom AI wo"
},
{
"path": ".cursor/PERSONALIZATION.md",
"chars": 3223,
"preview": "# Cursor Rules README\n\n## Overview\n\nThis directory contains rules that guide AI behavior in your development workflow. R"
},
{
"path": ".cursor/rules/_/.gitignore",
"chars": 14,
"preview": "*\n!.gitignore\n"
},
{
"path": ".cursor/rules/_context/.gitkeep",
"chars": 0,
"preview": ""
},
{
"path": ".cursor/rules/_core/communication.mdc",
"chars": 331,
"preview": "---\ndescription:\nglobs: \nalwaysApply: true\n---\n# Communication Style\n\nSpeak in extremely brief sentences. Your communica"
},
{
"path": ".cursor/rules/_core/persona.mdc",
"chars": 706,
"preview": "---\ndescription:\nglobs: \nalwaysApply: true\n---\n# Core Operating Directives & Persona\n\n**You ARE an aggressively proactiv"
},
{
"path": ".cursor/rules/_core/prefer-clis.mdc",
"chars": 516,
"preview": "---\ndescription:\nglobs: \nalwaysApply: true\n---\n# Project & Configuration Initialization\n\n- **Method:** Use popular CLIs "
},
{
"path": ".cursor/rules/_core/principles.mdc",
"chars": 400,
"preview": "---\ndescription:\nglobs: \nalwaysApply: true\n---\n# Guiding Principles\n\n1. **Observability:** Add excessive logging.\n2. **M"
},
{
"path": ".cursor/rules/_core/standards.mdc",
"chars": 1087,
"preview": "---\ndescription:\nglobs: \nalwaysApply: true\n---\n# Git Practices\n\n- **Commit Messages:** ALWAYS use `fix:`, `feat:`, or `c"
},
{
"path": ".cursor/rules/_core/terminal.mdc",
"chars": 416,
"preview": "---\ndescription:\nglobs: \nalwaysApply: true\n---\n# Terminal Command Execution\n\n- **CRITICAL:** \n\n- Avoid newline character"
},
{
"path": ".cursor/rules/_global.mdc",
"chars": 3120,
"preview": "---\ndescription: \nglobs: \nalwaysApply: true\n---\n# Core Operating Directives & Persona\n\n**You ARE an aggressively proacti"
},
{
"path": ".cursor/rules/_globs/GLOBS.md",
"chars": 993,
"preview": "# Glob-Based Rules Directory\n\nThis directory contains rules organized by the file patterns they apply to.\n\n## Directory "
},
{
"path": ".cursor/rules/_globs/react/best-practices.mdc",
"chars": 1633,
"preview": "---\ndescription:\nglobs: **/*.tsx\nalwaysApply: false\n---\n\n# React: Apply `useEffect` Dependency Best Practices\n\n**Your ta"
},
{
"path": ".cursor/rules/benchmarks-create.mdc",
"chars": 1098,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Create Benchmarks for a Function or Module\n\n**Your task: Generate micro"
},
{
"path": ".cursor/rules/cli-github-search.mdc",
"chars": 3920,
"preview": "---\ndescription: Search GitHub for examples\nglobs:\nalwaysApply: false\n---\n# How to Use the `ghx` CLI for GitHub Code Sea"
},
{
"path": ".cursor/rules/cli-pack.mdc",
"chars": 7402,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Using `repomix` CLI to Pack Repository Files\n\n**Your Task: When you nee"
},
{
"path": ".cursor/rules/cli-worktree.mdc",
"chars": 3184,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Using `wt` CLI for Git Worktree Management\n\n**Your Task: When managing "
},
{
"path": ".cursor/rules/cli-wrangler.mdc",
"chars": 6833,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Cloudflare Wrangler CLI Reference Guide\n\n**Your Task: When interacting "
},
{
"path": ".cursor/rules/docs-diagram.mdc",
"chars": 6050,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Create GitHub-Compatible Mermaid Diagrams\n\n**Your Task: When asked to c"
},
{
"path": ".cursor/rules/docs-openapi-spec.mdc",
"chars": 5698,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n## OpenAPI Specification Management Rule\n\n*This rule guides the creation "
},
{
"path": ".cursor/rules/docs-prd.mdc",
"chars": 8503,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Generate and Maintain `docs/PRD.md` (Product Requirements Document)\n\n**"
},
{
"path": ".cursor/rules/docs-structure.mdc",
"chars": 2229,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Generate `docs/STRUCTURE.md` for Project File Organization\n\n**Your task"
},
{
"path": ".cursor/rules/docs-sync.mdc",
"chars": 1929,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Synchronize Project Documentation with Recent Changes\n\n**Your task: Rev"
},
{
"path": ".cursor/rules/docs-tech-stack.mdc",
"chars": 10343,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Generate and Maintain `docs/TECH_STACK.md`\n\n**Your Core Task: Create or"
},
{
"path": ".cursor/rules/gh-docs-sync.mdc",
"chars": 1912,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Synchronize Project Documentation with Recent Changes\n\n\n**Your task: Re"
},
{
"path": ".cursor/rules/gh-task-continue.mdc",
"chars": 2007,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Continue Task from GitHub Issue\n\n**Your Primary Goal: Review commits si"
},
{
"path": ".cursor/rules/gh-task-execute.mdc",
"chars": 3713,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Execute Planned Task Commits from GitHub Issue\n\n\n**Your Primary Goal: S"
},
{
"path": ".cursor/rules/gh-task-plan.mdc",
"chars": 8613,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Create a GitHub Issue Task Plan\n\n\n**Your Core Task: Generate a multi-co"
},
{
"path": ".cursor/rules/logging-session.mdc",
"chars": 1643,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Session-Based Logging Rule\n\n**Your Task: Implement structured logging s"
},
{
"path": ".cursor/rules/pnpm-fixes.mdc",
"chars": 2097,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Resolve PNPM Build Script Issues for Trusted Dependencies\n\n**Your task:"
},
{
"path": ".cursor/rules/project-todos-next.mdc",
"chars": 1805,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Identify and Report TODO Items from Documentation (`docs/`)\n\n**Your tas"
},
{
"path": ".cursor/rules/project-update-rules.mdc",
"chars": 11223,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Update Project Context File: .cursor/rules/_project.mdc\n\n**Your primary"
},
{
"path": ".cursor/rules/project-update-user-rules.mdc",
"chars": 11665,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Update User Project Context File: .cursor/rules/_user-<username>.mdc\n\n*"
},
{
"path": ".cursor/rules/prompt-improve.mdc",
"chars": 4347,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Improve the User's Prompt Following the Patterns Below\n\n> Practical pro"
},
{
"path": ".cursor/rules/pull-request-create.mdc",
"chars": 5017,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Create a High-Quality Pull Request\n\n**Your Task: Follow this comprehens"
},
{
"path": ".cursor/rules/react-rules.mdc",
"chars": 1624,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n\n# React: Apply `useEffect` Dependency Best Practices\n\n**Your task: When "
},
{
"path": ".cursor/rules/scripts-create.mdc",
"chars": 1251,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Create Executable TypeScript Scripts with Bun\n\n**Your task: Create new,"
},
{
"path": ".cursor/rules/task-continue.mdc",
"chars": 1868,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Continue Task from Plan File\n\n**Your Primary Goal: Check commits since "
},
{
"path": ".cursor/rules/task-execute.mdc",
"chars": 3215,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Execute Planned Task Commits from Task File\n\n**Your Primary Goal: Syste"
},
{
"path": ".cursor/rules/task-next.mdc",
"chars": 1640,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Propose Next Development Task\n\n**Your primary task: Identify and recomm"
},
{
"path": ".cursor/rules/task-outline.mdc",
"chars": 1680,
"preview": "---\ndescription: Generate multiple task outline options\nglobs:\nalwaysApply: false\n---\n# Generate Task Outline Options\n\n*"
},
{
"path": ".cursor/rules/task-plan.mdc",
"chars": 9050,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Create a Detailed, Verifiable Task Plan\n\n**Your Core Task: Generate a m"
},
{
"path": ".cursor/rules/zen-coding.mdc",
"chars": 1296,
"preview": "---\ndescription:\nglobs:\nalwaysApply: false\n---\n# Adhere to the Zen of Coding Principles\n\n**Your primary goal: Internaliz"
},
{
"path": ".cursor/workflows/development/benchmarks.md",
"chars": 1051,
"preview": "# Create Benchmarks for a Function or Module\n\n**Your task: Generate micro-benchmark tests to measure the performance of "
},
{
"path": ".cursor/workflows/development/logging.md",
"chars": 1605,
"preview": "# Session-Based Logging Rule\n\n**Your Task: Implement structured logging so each application run writes to a separate fil"
},
{
"path": ".cursor/workflows/development/scripts.md",
"chars": 391,
"preview": "# Create Script with TypeScript and Bun\n\n- Create executable TypeScript scripts in a \"./scripts\" directory in the root o"
},
{
"path": ".cursor/workflows/documentation/diagram.md",
"chars": 5986,
"preview": "# Create GitHub-Compatible Mermaid Diagrams\n\n**Your Task: When asked to create a diagram, generate it using Mermaid synt"
},
{
"path": ".cursor/workflows/documentation/openapi-spec.md",
"chars": 5554,
"preview": "## OpenAPI Specification Management Rule\n\n_This rule guides the creation and maintenance of the `docs/openapi.yaml` file"
},
{
"path": ".cursor/workflows/documentation/prd.md",
"chars": 8432,
"preview": "# Generate and Maintain `docs/PRD.md` (Product Requirements Document)\n\n**Your Core Task: Create or update the `docs/PRD."
},
{
"path": ".cursor/workflows/documentation/sync.md",
"chars": 1884,
"preview": "# Synchronize Project Documentation with Recent Changes\n\n**Your task: Review and update all project documentation within"
},
{
"path": ".cursor/workflows/documentation/tech-stack.md",
"chars": 10274,
"preview": "# Generate and Maintain `docs/TECH_STACK.md`\n\n**Your Core Task: Create or update the `docs/TECH_STACK.md` file. This doc"
},
{
"path": ".cursor/workflows/task/parallel.md",
"chars": 3267,
"preview": "# Generate Parallel Task Plans\n\nWhen the user requests \"parallel tasks\" or \"create [number] parallel tasks\", you will ge"
},
{
"path": ".cursor/workflows/tools/cli/ghx.md",
"chars": 2632,
"preview": "# How to Use the `ghx` CLI for GitHub Code Search\n\n**Your task: When you need to find code examples, files, or specific "
},
{
"path": ".cursor/workflows/tools/cli/repomix.md",
"chars": 6647,
"preview": "# Using `repomix` CLI to Pack Repository Files\n\n**Your Task: When you need to consolidate multiple project files into a "
},
{
"path": ".cursor/workflows/tools/cli/worktree.md",
"chars": 2974,
"preview": "# Using `wt` CLI for Git Worktree Management\n\n**Your Task: When managing Git worktrees, especially for integration with "
},
{
"path": ".cursor/workflows/tools/cli/wrangler.md",
"chars": 6789,
"preview": "# Cloudflare Wrangler CLI Reference Guide\n\n**Your Task: When interacting with Cloudflare Workers, Pages, or other Cloudf"
},
{
"path": ".cursor/workflows/tools/package-managers/pnpm/build-script-fixes.md",
"chars": 2055,
"preview": "# Resolve PNPM Build Script Issues for Trusted Dependencies\n\n**Your task: When `pnpm` blocks essential build scripts fro"
},
{
"path": ".cursor/workflows/workflows/analysis/document-failures.md",
"chars": 4844,
"preview": "# Document Workflow Failures and Create Prevention Rule\n\n**DO THIS:** Analyze the conversation for failures, errors, and"
},
{
"path": ".cursor/workflows/workflows/config/personalize-rule.md",
"chars": 2211,
"preview": "# Personalize Existing Workflow Rules Locally\n\n**DO THIS:** Help user modify team workflow rules locally without committ"
},
{
"path": ".cursor/workflows/workflows/config/update-personal-rules.md",
"chars": 6265,
"preview": "# Create User Environment File: .cursor/rules/\\_/<username>.mdc\n\n**Your primary task: Create a user environment file tha"
},
{
"path": ".cursor/workflows/workflows/dependencies/audit.md",
"chars": 4332,
"preview": "# Audit Project Dependencies\n\n**Your task: Perform a comprehensive audit of project dependencies, checking for outdated "
},
{
"path": ".cursor/workflows/workflows/docs/structure.md",
"chars": 2184,
"preview": "# Generate `docs/STRUCTURE.md` for Project File Organization\n\n**Your task: Create a new file at `docs/STRUCTURE.md` that"
},
{
"path": ".cursor/workflows/workflows/docs/sync.md",
"chars": 1866,
"preview": "# Synchronize Project Documentation with Recent Changes\n\n**Your task: Review and update all project documentation within"
},
{
"path": ".cursor/workflows/workflows/github/continue-github.md",
"chars": 1962,
"preview": "# Continue Task from GitHub Issue\n\n**Your Primary Goal: Review commits since the last push, compare them against progres"
},
{
"path": ".cursor/workflows/workflows/github/execute-github.md",
"chars": 3658,
"preview": "# Execute Planned Task Commits from GitHub Issue\n\n**Your Primary Goal: Systematically execute the step-by-step plan defi"
},
{
"path": ".cursor/workflows/workflows/github/plan-github.md",
"chars": 8527,
"preview": "# Create a GitHub Issue Task Plan\n\n**Your Core Task: Generate a multi-commit task plan and post it as a GitHub issue usi"
},
{
"path": ".cursor/workflows/workflows/github/pr-create-github.md",
"chars": 4959,
"preview": "# Create a High-Quality Pull Request\n\n**Your Task: Follow this comprehensive checklist to prepare and create a well-docu"
},
{
"path": ".cursor/workflows/workflows/github/review-github.md",
"chars": 974,
"preview": "# Code Review Before Commit\n\n**Goal:** Inspect pending changes for readability, maintainability, performance, and securi"
},
{
"path": ".cursor/workflows/workflows/meta/create-workflow.md",
"chars": 5350,
"preview": "# Create New Workflow .mdc File from Conversation\n\n**🎯 PRIMARY OBJECTIVE:** Create an ACTUAL .mdc file in the appropriat"
},
{
"path": ".cursor/workflows/workflows/project/update-project-rules.md",
"chars": 11304,
"preview": "# Update Project Workflow Context File: .cursor/rules/\\_context/project.mdc\n\n**Your primary task: Meticulously update th"
},
{
"path": ".cursor/workflows/workflows/prompts/improve-prompt.md",
"chars": 4189,
"preview": "# Improve Workflow Prompts Following the Patterns Below\n\n> Practical prompt patterns to help anyone create clearer, more"
},
{
"path": ".cursor/workflows/workflows/scripts/create-script.md",
"chars": 1236,
"preview": "# Create Executable TypeScript Scripts with Bun\n\n**Your task: Create new, executable TypeScript scripts within a `script"
},
{
"path": ".cursor/workflows/workflows/task/continue.md",
"chars": 1826,
"preview": "# Continue Task from Plan File\n\n**Your Primary Goal: Check commits since the last push, reconcile them with a specified "
},
{
"path": ".cursor/workflows/workflows/task/execute.md",
"chars": 3163,
"preview": "# Execute Planned Task Commits from Task File\n\n**Your Primary Goal: Systematically execute the step-by-step plan defined"
},
{
"path": ".cursor/workflows/workflows/task/next.md",
"chars": 1596,
"preview": "# Propose Next Development Task\n\n**Your primary task: Identify and recommend the most logical next development task base"
},
{
"path": ".cursor/workflows/workflows/task/outline.md",
"chars": 1594,
"preview": "# Generate Task Outline Options\n\n**Goal:** Before committing to a single task plan, provide the user with several concis"
},
{
"path": ".cursor/workflows/workflows/task/plan.md",
"chars": 8965,
"preview": "# Create a Detailed, Verifiable Task Plan\n\n**Your Core Task: Generate a multi-commit task plan file, saved as `docs/task"
},
{
"path": ".cursor/workflows/workflows/task/todos-next.md",
"chars": 1750,
"preview": "# Identify and Report TODO Items from Documentation (`docs/`)\n\n**Your task: Scan all files within the `docs/` directory "
},
{
"path": ".eslintrc.js",
"chars": 860,
"preview": "module.exports = {\n root: true,\n env: {\n browser: true,\n node: true,\n es6: true,\n },\n parserOptions: {ecmaV"
},
{
"path": ".github/workflows/jest.yml",
"chars": 1746,
"preview": "name: Jest Tests CI\n\non: [deployment_status]\n\njobs:\n test:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/"
},
{
"path": ".gitignore",
"chars": 852,
"preview": "# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.\n\nrepomix-output.txt\nbundles.json\n."
},
{
"path": ".hive/issues.jsonl",
"chars": 2355,
"preview": "{\"id\":\"egghead-io-nextjs--imlp4-mjror8npun9\",\"title\":\"Diagnose cioIdentify failure on /unsubscribed page\",\"description\":"
},
{
"path": ".hive/memories.jsonl",
"chars": 206205,
"preview": "{\"id\":\"001fc5bc-c573-40ef-9db1-07981d23ea89\",\"information\":\"WODsmith Zod schema testing pattern: When testing Zod schema"
},
{
"path": ".husky/pre-commit",
"chars": 57,
"preview": "#!/bin/sh\n. \"$(dirname \"$0\")/_/husky.sh\"\n\nnpx lint-staged"
},
{
"path": ".kodiak.toml",
"chars": 375,
"preview": "# version is the only required field\nversion = 1\n\n# the following settings can be omitted since they have defaults\n\n[mer"
},
{
"path": ".node-version",
"chars": 8,
"preview": "22.17.1\n"
},
{
"path": ".nvmrc",
"chars": 7,
"preview": "22.17.1"
},
{
"path": ".storybook/main.js",
"chars": 398,
"preview": "/** @type { import('@storybook/nextjs').StorybookConfig } */\nconst config = {\n stories: ['../src/**/*.stories.@(js|jsx|"
},
{
"path": ".storybook/preview.js",
"chars": 291,
"preview": "import '../src/styles/index.css'\n\n/** @type { import('@storybook/nextjs').Preview } */\nconst preview = {\n parameters: {"
},
{
"path": "@types/assets/index.d.ts",
"chars": 415,
"preview": "declare module '\\*.svg' {\n import React = require('react')\n export const ReactComponent: React.SFC<React.SVGProps<SVGS"
},
{
"path": "@types/browser-cookies.d.ts",
"chars": 33,
"preview": "declare module 'browser-cookies'\n"
},
{
"path": "@types/cueplayer-react.d.ts",
"chars": 33,
"preview": "declare module 'cueplayer-react'\n"
},
{
"path": "@types/file-extension.d.ts",
"chars": 32,
"preview": "declare module 'file-extension'\n"
},
{
"path": "@types/friendly-time.d.ts",
"chars": 31,
"preview": "declare module 'friendly-time'\n"
},
{
"path": "@types/humanize-list.d.ts",
"chars": 31,
"preview": "declare module 'humanize-list'\n"
},
{
"path": "@types/mdx.d.ts",
"chars": 105,
"preview": "declare module '*.mdx' {\n let MDXComponent: (props: any) => JSX.Element\n export default MDXComponent\n}\n"
},
{
"path": "@types/react-textfit.d.ts",
"chars": 97,
"preview": "declare module 'react-textfit' {\n let Textfit: (props: any) => JSX.Element\n export {Textfit}\n}\n"
},
{
"path": "@types/remove-markdown.d.ts",
"chars": 33,
"preview": "declare module 'remove-markdown'\n"
},
{
"path": "@types/tincanjs.d.ts",
"chars": 26,
"preview": "declare module 'tincanjs'\n"
},
{
"path": "CLAUDE.md",
"chars": 8161,
"preview": "# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## "
},
{
"path": "LICENSE",
"chars": 518,
"preview": "\nAll Rights Reserved\n\nCopyright (c) 2020 egghead.io LLC\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND,"
},
{
"path": "README.md",
"chars": 2703,
"preview": "[](https://deepwiki.com/skillrecordings/egghead-next)\n\nWelcome to the `eg"
},
{
"path": "ai/diagrams/README.md",
"chars": 6041,
"preview": "# Egghead-Next Event Flow Diagrams\n\nThis directory contains comprehensive documentation of all event flows, data flows, "
},
{
"path": "ai/diagrams/analytics-tracking-flow.md",
"chars": 10488,
"preview": "# Analytics and Event Tracking Flow\n\n## Description\n\nComprehensive analytics system including user behavior tracking, pe"
},
{
"path": "ai/diagrams/auth-login-flow.md",
"chars": 2138,
"preview": "# Authentication Login Flow\n\n## Description\n\nComplete user authentication flow including login, token validation, and us"
},
{
"path": "ai/diagrams/course-progression-flow.md",
"chars": 5648,
"preview": "# Course Progression and Learning Flow\n\n## Description\n\nComplete learning experience including course enrollment, lesson"
},
{
"path": "ai/diagrams/email-automation-flow.md",
"chars": 8208,
"preview": "# Email Automation and Communication Flow\n\n## Description\n\nComprehensive email system including transactional emails, ma"
},
{
"path": "ai/diagrams/form-submission-flow.md",
"chars": 6982,
"preview": "# Form Submission and Validation Flow\n\n## Description\n\nComprehensive form handling including validation, submission, err"
},
{
"path": "ai/diagrams/free-user-pro-content-overlay-flow.md",
"chars": 12340,
"preview": "# Free User Pro Content Overlay System Flow\n\n## Description\n\nDetailed flow documenting the overlay system that manages w"
},
{
"path": "ai/diagrams/inngest-background-jobs-flow.md",
"chars": 5590,
"preview": "# Inngest Background Jobs Processing Flow\n\n## Description\n\nEvent-driven background job processing using Inngest for reli"
},
{
"path": "ai/diagrams/lesson-playback-flow.md",
"chars": 3347,
"preview": "# Lesson Video Playback Flow\n\n## Description\n\nComplete user experience for watching lesson videos including progress tra"
},
{
"path": "ai/diagrams/search-functionality-flow.md",
"chars": 3919,
"preview": "# Search Functionality Flow\n\n## Description\n\nComplete search experience including query processing, results display, fil"
},
{
"path": "ai/diagrams/stripe-payment-flow.md",
"chars": 3744,
"preview": "# Stripe Payment Processing Flow\n\n## Description\n\nComplete payment processing pipeline including checkout, webhooks, and"
},
{
"path": "ai/diagrams/subscription-access-control-flow.md",
"chars": 10751,
"preview": "# Subscription Access Control and Content Gating Flow\n\n## Description\n\nComprehensive flow documenting pro vs free subscr"
},
{
"path": "ai/diagrams/tip-creation-flow.md",
"chars": 4089,
"preview": "# Tip Creation and Management Flow\n\n## Description\n\nComplete workflow for creating, uploading, and managing video tips i"
},
{
"path": "ai/diagrams/trpc-api-flow.md",
"chars": 4536,
"preview": "# tRPC API Communication Flow\n\n## Description\n\nType-safe API communication between client and server using tRPC, includi"
},
{
"path": "ai/diagrams/user-navigation-flow.md",
"chars": 6582,
"preview": "# User Navigation and Routing Flow\n\n## Description\n\nComplete navigation experience including route protection, redirects"
},
{
"path": "ai/diagrams/video-upload-processing-flow.md",
"chars": 3017,
"preview": "# Video Upload and Processing Flow\n\n## Description\n\nComplete pipeline for video file upload, processing, transcription, "
},
{
"path": "ai/diagrams/webhook-processing-flow.md",
"chars": 5946,
"preview": "# Webhook Processing Flow\n\n## Description\n\nComprehensive webhook handling from external services including validation, p"
},
{
"path": "ai/diagrams/workshop-registration-flow.md",
"chars": 3930,
"preview": "# Workshop Registration and Management Flow\n\n## Description\n\nComplete workshop registration process including quote requ"
},
{
"path": "ai/diagrams/xstate-machine-flow.md",
"chars": 5471,
"preview": "# XState Machine State Management Flow\n\n## Description\n\nComplex state management using XState machines for predictable s"
},
{
"path": "bin/validate",
"chars": 2931,
"preview": "#!/bin/bash\n\n# Description:\n# Checks for foundation development dependencies. Basically, if it needs to be installed m"
},
{
"path": "config/jest/cssTransform.js",
"chars": 123,
"preview": "module.exports = {\n process() {\n return 'module.exports = {};'\n },\n getCacheKey() {\n return 'cssTransform'\n },"
},
{
"path": "cypress/fixtures/example.json",
"chars": 154,
"preview": "{\n \"name\": \"Using fixtures to represent data\",\n \"email\": \"hello@cypress.io\",\n \"body\": \"Fixtures are a great way to mo"
},
{
"path": "cypress/integration/spec.js",
"chars": 557,
"preview": "describe('egghead is working', () => {\n it('loads the homepage', () => {\n cy.visit('/')\n cy.contains('©egghead.io"
},
{
"path": "cypress/plugins/index.js",
"chars": 718,
"preview": "/// <reference types=\"cypress\" />\n// ***********************************************************\n// This example plugins"
},
{
"path": "cypress/support/commands.js",
"chars": 838,
"preview": "// ***********************************************\n// This example commands.js shows you how to\n// create various custom"
},
{
"path": "cypress/support/index.js",
"chars": 670,
"preview": "// ***********************************************************\n// This example support/index.js is processed and\n// load"
},
{
"path": "cypress.json",
"chars": 118,
"preview": "{\n \"baseUrl\": \"http://localhost:3000\",\n \"env\": {\n \"codeCoverage\": {\n \"url\": \"/api/__coverage__\"\n }\n }\n}\n"
},
{
"path": "docs/decisions/0001-adopt-architecture-decision-records.md",
"chars": 2279,
"preview": "---\nstatus: accepted\ndate: 2026-03-05\ndecision-makers:\n---\n\n# Adopt architecture decision records\n\n## Context and Proble"
},
{
"path": "docs/decisions/0002-upgrade-next-mdx-remote-to-v6.md",
"chars": 10075,
"preview": "---\nstatus: proposed\ndate: 2026-03-05\ndecision-makers: Cree\nconsulted: ''\ninformed: ''\n---\n\n# Upgrade next-mdx-remote fr"
},
{
"path": "docs/decisions/0003-direct-pg-course-shell.md",
"chars": 4802,
"preview": "# Direct PG course shell for `/courses/[course]`\n\n## Status\n\nproposed\n\n## Date\n\n2026-03-10\n\n## Context\n\nThis ADR is a co"
},
{
"path": "docs/decisions/README.md",
"chars": 1004,
"preview": "# Architecture Decision Records (ADR)\n\nAn Architecture Decision Record (ADR) captures an important architecture decision"
},
{
"path": "docs/latest-courses-component-plan.md",
"chars": 9495,
"preview": "# Latest Courses Component Implementation Plan\n\n## Overview\n\nCreate a component that displays the latest 4 courses from "
},
{
"path": "docs/post-page-refactoring-plan.md",
"chars": 26694,
"preview": "# Post Page Refactoring Plan\n\n## Overview\n\nThe current `[post].tsx` file is over 1000 lines and contains multiple respon"
},
{
"path": "docs/stripe-upgrade-analysis.md",
"chars": 9720,
"preview": "# Stripe Node.js SDK Upgrade Analysis\n\n**Current Version:** 9.8.0 \n**Latest Version:** 18.0.0 \n**Analysis Date:** 2025"
},
{
"path": "docs/stripe-upgrade-plan.md",
"chars": 13019,
"preview": "# Stripe SDK Upgrade Plan: v9.8.0 to v18.0.0\n\n**Project:** egghead-next \n**Current Version:** 9.8.0 \n**Target Version:"
},
{
"path": "docs/tasks/2025-06-02-11-40-ai-dev-essentials-landing-page.md",
"chars": 6493,
"preview": "# Task: Build AI Dev Essentials Newsletter Landing Page\n\n## Commit 1: feat: create database query function for AI Dev Es"
},
{
"path": "docs/tasks/2025-08-13-copy-as-prompt-feature.md",
"chars": 7811,
"preview": "# Copy as Prompt Feature Implementation Plan\n\n## Overview\n\nAdd a \"Copy as Prompt\" button to three main pages (posts, cou"
},
{
"path": "docs/tasks/2025-08-18-14-35-stripe-sdk-upgrade.md",
"chars": 7800,
"preview": "# Task: Upgrade Stripe Node.js SDK from v9.8.0 to v18.0.0\n\n## Commit 1: test: add comprehensive Stripe integration test "
},
{
"path": "docs/typesense-new-lessons-feature.md",
"chars": 10512,
"preview": "# TypeSense \"New Lessons\" Feature Plan\n\n## Current State Analysis\n\n### TypeSense Integration Overview\n\n**Current Data St"
},
{
"path": "jest/json-reporter.js",
"chars": 1009,
"preview": "class GithubActionsReporter {\n constructor(globalConfig, options) {\n this._globalConfig = globalConfig\n this._opt"
},
{
"path": "jest.config.js",
"chars": 750,
"preview": "module.exports = {\n collectCoverageFrom: [\n '**/*.{js,jsx,ts,tsx}',\n '!**/*.d.ts',\n '!**/node_modules/**',\n ]"
},
{
"path": "next-env.d.ts",
"chars": 277,
"preview": "/// <reference types=\"next\" />\n/// <reference types=\"next/image-types/global\" />\n/// <reference types=\"next/navigation-t"
},
{
"path": "next-sitemap.js",
"chars": 1968,
"preview": "require('dotenv-flow').config()\n\nmodule.exports = {\n siteUrl: process.env.NEXT_PUBLIC_DEPLOYMENT_URL,\n changefreq: 'da"
},
{
"path": "next.config.mjs",
"chars": 10366,
"preview": "import withSvgr from 'next-svgr';\nimport withBundleAnalyzer from '@next/bundle-analyzer';\nimport withPlugins from 'next-"
},
{
"path": "package.json",
"chars": 11819,
"preview": "{\n \"name\": \"egghead-io-nextjs\",\n \"version\": \"0.1.0\",\n \"engines\": {\n \"node\": \"22.x\"\n },\n \"resolutions\": {\n \"au"
},
{
"path": "postcss.config.js",
"chars": 144,
"preview": "module.exports = {\n plugins: {\n 'tailwindcss/nesting': {},\n tailwindcss: {},\n autoprefixer: {\n flexbox: '"
},
{
"path": "prisma/schema.prisma",
"chars": 4137,
"preview": "// This is your Prisma schema file,\n// learn more about it in the docs: https://pris.ly/d/prisma-schema\n\ngenerator clien"
},
{
"path": "public/bitmovin/bitmovinplayer-ui.css",
"chars": 113347,
"preview": "@charset \"UTF-8\";\n/**************************************************************************** \n * Copyright (C) 2021, "
},
{
"path": "public/bitmovin/bitmovinplayer-ui.js",
"chars": 508563,
"preview": "/****************************************************************************\n * Copyright (C) 2021, Bitmovin, Inc., All"
},
{
"path": "public/bitmovin/receiver.css",
"chars": 71,
"preview": ".bmpui-ui-skin-cast-receiver .bmpui-ui-watermark {\n display: none;\n}"
},
{
"path": "public/opensearch.xml",
"chars": 520,
"preview": "<OpenSearchDescription xmlns=\"http://a9.com/-/spec/opensearch/1.1/\" xmlns:moz=\"http://www.mozilla.org/2006/browser/searc"
},
{
"path": "public/robots.txt",
"chars": 2142,
"preview": "# Twitterbot\nUser-agent: Twitterbot\nDisallow: \n\n# ClaudeBot\nUser-agent: ClaudeBot\nCrawl-delay: 10\nDisallow: /q\n\n# GPTBot"
},
{
"path": "public/site.webmanifest",
"chars": 263,
"preview": "{\"name\":\"\",\"short_name\":\"\",\"icons\":[{\"src\":\"/android-chrome-192x192.png\",\"sizes\":\"192x192\",\"type\":\"image/png\"},{\"src\":\"/"
},
{
"path": "public/sitemap.xml",
"chars": 51799,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-1.xml",
"chars": 8535795,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-10.xml",
"chars": 8578855,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-11.xml",
"chars": 8683132,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-12.xml",
"chars": 8513674,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-13.xml",
"chars": 8610583,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-14.xml",
"chars": 8681739,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-15.xml",
"chars": 8630505,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-16.xml",
"chars": 8615081,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-17.xml",
"chars": 8561026,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-18.xml",
"chars": 8815206,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-19.xml",
"chars": 8636894,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "public/tags-sitemap-24.xml",
"chars": 8550202,
"preview": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" xmlns:news=\"http://ww"
},
{
"path": "test-copy-button.js",
"chars": 0,
"preview": ""
}
]
// ... and 1065 more files (download for full content)
About this extraction
This page contains the full source code of the skillrecordings/egghead-next GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 1234 files (250.6 MB), approximately 26.3M tokens, and a symbol index with 214 extracted functions, classes, methods, constants, and types. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.