Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/giantswarm/musterWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/giantswarm/muster/github-workflow)<a href="https://agentmods.dev/rules/giantswarm/muster/github-workflow"><img src="https://agentmods.dev/badge/rules/giantswarm/muster/github-workflow/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/rules/giantswarm/muster/github-workflow"><img src="https://agentmods.dev/badge/rules/giantswarm/muster/github-workflow.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00987 | $0.00987 |
| Opus 5.5 | $0.00395 | $0.00395 |
| Sonnet 5.5 | $0.00197 | $0.00197 |
| Haiku 4.5 | $0.00099 | $0.00099 |
Grade A, and why
github-workflow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 59 lines — stays where its author put it; the contents beside it link to each section on GitHub.
- Github Tools Usage
- Always use the Github tools via mcp-debug
- The Github tools via mcp_mcp-debug_list_tools
- Github Tools Discovery
- Sub-points with details
- Examples and explanations
- Issue Management Best Practices
- When updating existing issues:
- Always update the issue description if the scope of the issue has changed. A comment is not enough. But only do the necessary changes to the description.
- Add a short comment underneath explaining what was added/changed
- Avoid lengthy comments that repeat the description content
- When adding subtasks to main issues:
- Create separate issues for each subtask with detailed information
- Include full description, objective, implementation details, and acceptance criteria in subtask issues
- Link subtask issues in the main issue's "Related Subtasks" section
- Use consistent naming: "Subtask X.Y: [Description]"
- Add appropriate labels:
subtask, relevant components, priority
- Subtask issue structure:
- Parent Issue: Link to main issue (e.g., "#71 - Task 13: Main Task Title")
- Objective: Clear, one-sentence goal
- Implementation Details: Specific technical requirements and approach
- Files to Create/Modify: Explicit file listing
- Acceptance Criteria: Detailed, testable requirements
- Dependencies: Links to related issues/tasks
- When updating existing issues:
- New Task
- Use the
x_github_list_issuestool to fetch the list of open issues from thegiantswarm/musterrepository, ordered by issue number descending (newest first). - Decide which is the next best issue in that list (still open issue) and use the
x_github_get_issuetool with its issue number to retrieve full details. Also make sure to use thex_github_get_issue_commentstool to get the comments for the issue. - Summarize that issue (title, number, body, key tasks) in the chat before starting implementation steps.
- After summarizing, outline the approach for addressing the issue and continue with the implementation.
- Use the
- New Issue
- Gather the necessary information for the issue:
titleandbody.labelsandassigneescan also be included if provided. - Use the
x_github_create_issuetool to create the new issue in thegiantswarm/musterrepository. Setownertogiantswarmandrepotomuster. - Announce the new issue (title and number) in the chat after it has been created.
- Gather the necessary information for the issue:
- Commit and Push Workflow
- Get the current branch name using
git rev-parse --abbrev-ref HEAD - If the current branch is
mainormaster, generate a new branch name using the pattern<type>/issue-<issue_num>-<slugified_issue_title>. - Checkout the new branch using
git checkout -b <new_branch_name>
- Get the current branch name using
- IMPORTANT - Before staging, committing and pushing changes
- Make sure to run
goimports -w .andgo fmt ./...before you commit any code. - Run tests by executing the
make testcommand in the terminal usingrun_terminal_cmd. - If tests fail, you have to fix the tests.
- Make sure to run
- Stage changes:
- Run
git add .usingrun_terminal_cmd.
- Run
- Commit changes:
- Construct a commit message. The suggested pattern is:
<CommitType>: <issue_title> (closes #<issue_num>). Example:Refactor: Refactor getPodNameForPortForward for clarity, scope, and context handling (closes #37). The<CommitType>(e.g., Refactor, Fix, Feat) should match the nature of the work. - Run
git commit -m "<commit_message>"usingrun_terminal_cmd.
- Construct a commit message. The suggested pattern is:
- Push changes:
- Run
git push origin <target_branch>usingrun_terminal_cmd. - Inform the user that the changes have been committed to
<target_branch>and pushed to origin.
- Run
- Closing an issue
- Confirm with the user that the issue is ready to be closed.
- Add a comment to the issue with the changes that were made. Use the
x_github_add_issue_commenttool to add the comment. - Use the
x_github_update_issuetool to change the state of the issue to 'closed'.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 59 lines · 987 tokens per session scan A b0f3927acbf4
github-workflow is a cursor rule published in the GitHub repository giantswarm/muster (35 stars, last pushed today), licensed Apache-2.0. It adds 987 tokens to every session, about $0.0039 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other cursor rules, from other repositories
changesets
Changeset format and bump rules enforced by CI.
project-context
Current repository context, commands, and documentation authority.
iris
GitHub operations specialist — branches, pull requests, issues, releases, tags. Called by zeus after review. Never pushes or merges without explicit human approval. Integrates with VS Code GitHub Pull Requests extension.
project-onboarding-rule
Automatically onboards existing projects into the AI-driven development workflow.
github-repo-triage
Triage and maintain GitHub repos — issues, PRs, cherry-picks, releases, publishing.
git_rules
When asked to interact with git, github or project management tooling (jira, linear, asana etc).