Skip to content

Latest commit

 

History

History
120 lines (89 loc) · 4.15 KB

File metadata and controls

120 lines (89 loc) · 4.15 KB

Contributing to Steam Developer Tools

Thanks for your interest in contributing to this Cursor plugin.

Getting Started

  1. Fork the repository
  2. Clone your fork:
    git clone https://github.com/YOUR_USERNAME/Steam-Cursor-Plugin.git
  3. Create a feature branch:
    git checkout -b feature/your-feature-name

Local Development

To test the plugin locally, symlink or copy the repo to your Cursor plugins directory:

~/.cursor/plugins/local/steam-cursor-plugin/

On Windows:

New-Item -ItemType SymbolicLink -Path "$env:USERPROFILE\.cursor\plugins\local\steam-cursor-plugin" -Target (Resolve-Path .\Steam-Cursor-Plugin)

On macOS/Linux:

ln -s "$(pwd)/Steam-Cursor-Plugin" ~/.cursor/plugins/local/steam-cursor-plugin

Cursor will pick up changes to skills and rules without restarting.

Plugin Structure

The plugin currently has 30 skills and 9 rules.

.cursor-plugin/
  plugin.json          # Plugin manifest (name, version, metadata)
skills/                # 30 skill directories
  <skill-name>/
    SKILL.md           # Skill definition with frontmatter + instructions
rules/                 # 9 rule files
  <rule-name>.mdc      # Rule definition with frontmatter + guidance

Adding a Skill

  1. Create a new directory under skills/ with a kebab-case name
  2. Add a SKILL.md file with YAML frontmatter:
    ---
    name: your-skill-name
    description: One-line description of what the skill does and when to use it.
    ---
  3. Structure the body with these sections (in order):
    • Trigger - when Cursor should load this skill
    • Required Inputs - what the user must provide
    • Workflow - step-by-step instructions for the agent
    • Key References - links to official Steamworks/Steam docs
    • Example Interaction - sample prompt and response
    • MCP Usage - table mapping workflow steps to MCP tools (required even for SDK-only skills)
    • Common Pitfalls - numbered list of mistakes to avoid
    • See Also - links to related skills

Adding a Rule

  1. Create a .mdc file under rules/
  2. Add YAML frontmatter:
    ---
    description: What this rule enforces.
    alwaysApply: true   # or false with globs
    globs:               # only if alwaysApply is false
      - "**/*.vdf"
    ---
  3. Write clear, actionable guidance in the body

Pull Request Process

  1. Keep changes focused - one skill or rule per PR when possible
  2. Ensure all frontmatter is valid YAML
  3. Test the skill/rule locally in Cursor before submitting
  4. Write a clear PR description explaining what the change does and why

Developer Certificate of Origin and Inbound License Grant

This project uses CC-BY-NC-ND-4.0 as its outbound license, which forbids derivatives. Every pull request is a derivative. Contributions are accepted inbound under a broader grant via the Developer Certificate of Origin (DCO), which resolves the conflict so the project can accept and redistribute contributions.

Required grant

By submitting a contribution to this repository, you certify that you have the right to do so under the Developer Certificate of Origin (DCO) 1.1, and you grant TMHSDigital a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license to use, reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your contribution under the project's current license (CC-BY-NC-ND-4.0) or any successor license chosen by the project.

DCO sign-off

Every commit in a pull request must have a Signed-off-by: trailer matching the commit author:

Signed-off-by: Jane Developer <jane@example.com>

Signing is done at commit time:

git commit -s -m "feat: add new skill"

The GitHub DCO App enforces this on every PR.

For the full inbound/outbound model and rationale, see standards/licensing.md in the Developer-Tools-Directory meta-repo.

Code of Conduct

By participating in this project, you agree to abide by our Code of Conduct. Be respectful, constructive, and collaborative.