Use when creating or modifying Go backend API endpoints, modifying Spanner database schemas, or working with OpenAPI and Spanner mappers.
Use when working with the webstatus notification pipeline, event producer, push delivery, or push workers (e.g., Email, Webhooks), and Pub/Sub subscribers.
Use when modifying the ANTLR search grammar, adding new search terms, or working with the query parser and builder.
Use when writing, modifying, or debugging Playwright end-to-end (E2E) tests for webstatus.dev.
Use when modifying the frontend SPA, working with TypeScript, Lit web components, Shoelace components, or frontend tests.
Use when working on Go data ingestion workflows, scheduled Cloud Run jobs, or adding new scrapers for BCD, WPT, or other data sources.
| name | webstatus-pr-creation |
| description | How to commit code and create a Pull Request |
When you have finished implementing a feature or fixing a bug and the user asks you to "create a PR" or "commit these changes", you MUST follow these specific steps to ensure the repository remains clean and PRs are descriptive.
git status to see what files have been modified.git diff to quickly review the changes. Ensure you haven't left any stray console.log statements, commented-out debugger code, or unresolved merge conflict markers.make precommit, make go-lint, or make node-lint). Additionally, cross-reference your changes against the project's specific skills (e.g., webstatus-backend, webstatus-frontend) and standard Google Style Guides (e.g., Google Go Style Guide, Google TypeScript Style Guide). If you are unsure about a style rule, you may search for it or ask the user.main.
git checkout -b feature/<short-description> or git checkout -b fix/<short-description>git add <file1> <file2>. Try to avoid git add . unless you are absolutely certain no unrelated files (like local IDE configs) are present.type(scope): subject). Make sure to prefix the commit with feat:, fix:, chore:, docs:, test:, or refactor:.
feat: implement dark mode componentfix(api): handle missing search name in payloaddocs: update knowledge base and skillsgit commit -m "<your message>". You can omit the -m flag and let it open an editor if you prefer to write a multi-line body explaining why the change was made (encouraged for complex bug fixes!).git push -u origin <branch-name>gh) to create the PR.
gh pr create --title "<Commit Subject>" --body "<Detailed Description>"--body must explain:
Fixes #123).[!IMPORTANT] A PR with just "fixed the bug" in the body is unacceptable. Take the time to write a body that a human reviewer can immediately understand without having to read every line of code first.
When tasked with a massive feature or refactor, always aim to split the work into smaller, focused PRs that build upon each other (dependent PRs). This makes reviewing significantly easier for humans.
main for the first piece of work (PR 1).git checkout -b feature/pr2).pr4 off of pr3, pr3 off of pr2, etc.When the base branch (origin/main) advances (e.g., after PR 1 merges), you must rebase your dependent branches so they stack cleanly on the new main. Use the git rebase --onto strategy.
git fetchN=2 if PR 2 added 2 commits on top of PR 1).git rebase --onto origin/main HEAD~<N> <BranchName>origin/main for the new base branch as needed.