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.
npx agentmods add rules/giantswarm/muster/github-workflowgit clone --depth 1 https://github.com/giantswarm/musterWhat 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 | $0.00987 | $0.00987 |
| Opus 5 | $0.00494 | $0.00494 |
| Sonnet 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 yesterday.
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.
- yesterday First seen · 59 lines · 987 tokens per session scan A b0f3927acbf4
github-workflow is a cursor rule published in the GitHub repository giantswarm/muster (28 stars, last pushed 2d ago), licensed Apache-2.0. It adds 987 tokens to every session, about $0.0049 per session on Opus 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
tdd
Final Verification: Always use: go test -v ./backend/api/handler/... | grep FAIL.
05-web-development
Use the following format for code blocks.
03-project-structure
The repository is organized in a monorepo using pnpm workspaces: pnpm-workspace.yaml. It contains the following.
php-types-validation
Guidelines for type definitions and validation in PHP MCP SDK.
php-client-implementation
Guidelines for implementing MCP clients in PHP.
on-load-rule
This guide outlines the critical development principles for this Swift project.