heyra-global/heyra-dev
Developer plugin for Heyra engineers, installable in Claude Code, GitHub Copilot CLI, VS Code and the Copilot cloud agent. /commit, /pr-description, /review-changes, /doctor and /setup skills, TDD guidance, code-reviewer and test-writer subagents (Claude and Copilot formats), guard-rail hooks, Python and TypeScript language servers, and Context7 plus Playwright MCP servers. Ships both the Claude plugin manifest and the Agent Plugins 1.0 manifest.
Create a conventional commit from the staged changes, or stage everything first when nothing is staged, with a subject under 72 characters and a body that explains why. Use when the user says commit, save my work, or asks for a commit message. For a pull request description see pr-description, and for a review before committing see review-changes.
Check the local machine for the tools the heyra-dev plugin needs - git, Node, Python, jq, language servers, Claude Code, GitHub Copilot CLI - plus the installed plugins and MCP servers, and report what is missing with the install command. Use when a hook or MCP server fails, a skill does not load, or the user asks "is my setup ok". For first-time project setup see setup.
Write a pull request title and description from the commits and the diff of the current branch against its base branch. Use when the user asks for a PR description or PR body, or is about to open a pull request. For the commits themselves see commit, and for a review before opening the PR see review-changes.
Review the uncommitted changes, the staged changes, or the current branch against a base branch for bugs, missing tests and simplifications, in an isolated code-reviewer subagent so the diff does not fill the main conversation. Use when the user asks for a code review of their work before committing or opening a pull request. For the commit see commit, and for writing the missing tests see tdd.
Register the heyra-demo marketplace for this repository and enable the developer plugin for Claude Code and GitHub Copilot at project scope, so every teammate gets the same setup from the committed settings files. Use when the user starts working in a new repository or asks how to enable the plugins for the team. For an environment check see doctor.
Test-driven development workflow - write the failing test first, make it pass with the smallest change, then refactor - with rules for choosing the test level, naming tests and not mocking the unit under test. Use when adding a feature or fixing a bug in a codebase that has tests, or when the user mentions TDD, "tests first", or asks how to test something. For the commit afterwards see commit, and for a review see review-changes.