A community of tips

# Remove AI code slop Check the diff against main, and remove all AI generated slop introduced in this branch. This includes: - Extra comments that a human wouldn't add or is inconsistent with the rest of the file - Extra defensive checks or try/catch blocks that are abnormal for that area of the codebase (especially if called by trusted / validated codepaths) - Casts to any to get around type issues - Any other style that is inconsistent with the file Report at the end with only a 1-3 sentence summary of what you changed

# Code Review Checklist ## Overview Comprehensive checklist for conducting thorough code reviews to ensure quality, security, and maintainability. Make any changes you see to accomplish the goals of the review ## Review Categories ### Functionality - [ ] Code does what it's supposed to do - [ ] Edge cases are handled - [ ] Error handling is appropriate - [ ] No obvious bugs or logic errors ### Code Quality - [ ] Code is readable and well-structured - [ ] Functions are small and focused - [ ] Variable names are descriptive - [ ] No code duplication, if there is you should consolidate - [ ] Follows project conventions ### Security - [ ] No obvious security vulnerabilities - [ ] Input validation is present - [ ] Sensitive data is handled properly - [ ] No hardcoded secrets

# Generate App Store Release Notes Generate App Store release notes for the current version. ## Important - Review recent commits to understand what's new - Replace [App Name] and [Support Email] with actual values - Plain text only (no emojis, markdown, or EM dashes) - Keep tone calm, supportive, and user-friendly ## Template We're working fast to keep [App Name] improving, with new features and refinements in every update. Download the latest version to explore what's new. [Introduction: "Based on your feedback, [description]", "Here's what's new in v[X.Y.Z]:", "What's new:", etc.] What's new: - [Feature 1]: [Brief description] - [Feature 2]: [Brief description] - [Feature 3]: [Brief description] [Continue with additional features as needed] Under the hood: - [Bug fix 1]: [Brief description] - [Bug fix 2]: [Brief description] - Performance and UI/UX improvements as well as other bug fixes [Optional: Coming soon] Coming soon: [Description of upcoming features]. [Optional: Disclaimers] [Disclaimer text if needed] Thank you for being part of the [App Name] community. Your reviews help others discover us. Got feedback? Reach out any time at [Support Email] or directly from the app's Support page. [Closing: "Take care," (default), "Best,", "Thank you,", "Warmly,", etc.] The [App Name] Team ## Guidelines Review commits, identify features, group logically, write in calm tone. Introduction options: - "Based on your feedback..." when features were user-requested - "Here's what's new in v[X.Y.Z]..." when you want to include version number - "What's new:" for simple, direct introduction Closing options: - "Take care," most common, warm and friendly (default) - "Best," professional and concise - "Thank you," when emphasizing gratitude - "Warmly," especially warm and personal Content tips: - Focus on user benefits, not technical implementation details - Order features logically: main feature first, then supporting features, then general improvements - Include relevant disclaimers when appropriate (health metrics, medical advice, privacy notes) - Mention upcoming features if foundation has been laid - Keep bullet points concise and scannable

# Open a PR - Check that I'm in a branch other than `main` or `prod`. If not, bail and explain. - Check the diff between my branch and the main branch of the repo - If there's unstaged or staged work that hasn't been commited, commit all the relevant code first (Use `gh` in case it's installed) - Write up a quick PR description in the following format <feature_area>: <Title> (80 characters or less) <TLDR> (no more than 2 sentences) <Description> - 1~3 bullet points explaining what's changing - Always paste the link to the PR in your response so I can click it easily - Prepend GIT_EDITOR=true to all git commands you run, so you can avoid getting blocked as you execute commands

Fix all merge conflicts on the current Git branch non-interactively and make the repo buildable and tested. Requirements and constraints: - Operate from the repository root. If not in a Git repo, stop and report. - Do not ask the user for input. Choose sensible defaults and explain decisions in a brief summary. - Prefer minimal, correct changes that preserve both sides' intent when possible. - Use non-interactive flags for any tools you invoke. - Do not push or tag; only commit locally. High-level plan: 1) Detect conflicts - Run: git status --porcelain | cat - Collect files with conflict markers (U statuses or files containing <<<<<<< / ======= / >>>>>>>). 2) Resolve conflicts per file - Open each conflicting file and remove conflict markers. - Merge both sides logically when feasible. If mutually exclusive, pick the variant that: - Compiles and passes type checks, and - Preserves existing public APIs and behavior. - Language-aware strategy: - package.json/pnpm-lock.yaml/yarn.lock: merge keys conservatively; run install to regenerate lockfiles. - .lock files (package-lock.json, yarn.lock, pnpm-lock.yaml): prefer regenerating via the package manager rather than manual edits. - Generated files and build artifacts: prefer keeping them out of version control if applicable; otherwise prefer current branch (ours). - Config files: preserve union of safe settings; avoid deleting required fields. - Text/markdown: include both unique content, deduplicate headings. - Binary files: prefer current branch (ours) unless project docs indicate otherwise. 3) Validate - If Node/TypeScript/JS present: install deps if manifests changed (use --frozen-lockfile false equivalents), then run lint/typecheck/build/tests if available. - If other ecosystems detected (Python, Go, etc.), run their standard build/tests when available. 4) Finalize - Stage all resolved files and any regenerated lockfiles. - Create a single commit with message: "chore: resolve merge conflicts". - Output a concise summary of files touched and notable resolution choices. Operational guidance: - Assume the user isn’t available; make best-effort decisions. If a resolution is ambiguous and blocks build/tests, prefer the variant that compiles and green-tests. - If a file still contains conflict markers after your first pass, revisit and resolve them before proceeding. - For large refactors causing conflicts, prefer keeping consistent imports, types, and module boundaries. Use exhaustive switch guards in TypeScript and explicit type annotations where needed. - Keep edits minimal and readable; avoid reformatting unrelated code. Deliverables: - A clean working tree with all conflicts resolved. - Successful build/tests where applicable. - One local commit containing the resolutions.

# Weekly review - Go through all my commits for the past 7~10 days (on the main repo branch). Note: I must be the author of the commits using my email (git config user.email) - Ask me to set my user email if you can't find it. Explain me how to set my email - Create a very short synthesis of everything that I shipped based on the commits - Print 2~5 bullet points explaining my changes - Also, highlight what you believe was tech debt, what seemed like bug fixes, and what looked like net new functionality in a short paragraph at the end

# Commit current work Commit current work. ## Important - Prepend GIT_EDITOR=true to all git commands you run, especially the ones looking at diffs, so you can avoid getting blocked as you execute commands - If you can't get any information from git diff, just using your working memory to determine what has changed ## Instructions Review each file individually to make sure they're related to the work you just did, then write a brief commit message in the following format: - Short title description (< 80 characters) - 2~3 bullet points (< 80 characters) with a quick description ## Notes - You should only commit work when instructed. Do not keep committing subsquent work unless explicitly told so Optional: ask me if I would like to push the commit. (Only if I'm not on main)