hubble.md

Ask Claude Code to make a taste-driven call on something ambiguous — UI polish, prose phrasing, naming, formatting. Use when you'd otherwise guess.

Prepare Hubble desktop releases using tag-triggered GitHub Releases. Use when cutting, automating, or explaining app releases, version bumps, tags, GitHub Actions publishing, Electron artifacts, or updater release management.

Review a pull request or local branch diff for correctness, security, lifecycle, error handling, tests, and meaningful performance risks. Use when asked to review PR changes, a branch, a commit range, or the current working tree and return a structured review.

Request an automated review of the current pull request, address valid feedback, and repeat until approval. Use after opening a PR and before handing it to a human reviewer.

Add a user-facing entry to CHANGELOG.md for work that just landed. Use when wrapping up a feature/fix, or when asked to record what changed. Called standalone or from the `done` skill.

Open a pull request for the current branch. Use whenever asked to make/create/open a PR.

Use when testing the Hubble Electron desktop app, especially when inspecting, clicking, screenshotting, or verifying a real note edit in the running app.

Implement a fix or feature from a GitHub, Jira, Linear, or other issue-tracker issue by fetching issue context, inspecting the current codebase, making code changes, validating them, opening a GitHub pull request, and reporting progress back to the original issue.

Triage an incoming GitHub, Jira, Linear, or other issue-tracker issue against the current codebase and related open issues, then return a structured decision with exactly one implementation-readiness state. Use whenever the user asks to triage, classify, assess, prioritize, or label an issue for implementation readiness, especially when an issue URL, key, or number is supplied in the prompt.

Write a PRODUCT.md spec for a significant Hubble user-facing feature, focused only on user experience and observable behavior. Use when the user asks for a product spec, UX spec, PRD, desired behavior doc, or wants feature behavior clarified before implementation.

Write a TECH.md spec for a significant Hubble feature after researching the monorepo architecture. Use when the user asks for a technical spec, implementation plan, architecture plan, or package/app/module breakdown tied to product behavior.

Use when writing or reviewing code comments.

Use when code is working and ready for a final human-review pass.

Use this skill automatically when you feel your code ready for human review. This means the code works and achieves a stated goal, verified by your own tests and/or, if you deem it necessary, human testing.

Builds reusable Convex components with isolated tables and app-facing APIs. Use for new components, reusable backend modules, integrations, or component boundary work.

Plans Convex schema and data migrations with widen-migrate-narrow and @convex-dev/migrations. Use for breaking schema changes, backfills, table reshaping, or zero-downtime rollouts.

Audits Convex performance for reads, subscriptions, write contention, and function limits. Use for slow features, insights findings, OCC conflicts, or read amplification.