Skip to content

Plugin guidelines

Warning

These guidelines are not exhaustive and may evolve over time as new plugin capabilities and gameplay impacts emerge.

Info

To read these guidelines in other languages, visit https://legal.jagex.com/docs/policies/runescape-plugin-guidelines TODO: Verify this URL

Core Principles

The following core principles define the intended boundaries for plugin behaviour.

Plugins may

  • Enhance clarity, usability, or accessibility.
  • Help players access, interpret and organise visible, public, player-known or API-exposed information.
  • Support planning, tracking, and progression using known or historical information.
  • Provide notifications or summaries based on visible or known information.

Plugins must not

  • Automatically perform actions for the player.
  • Significantly replace player decision-making, skill, timing, reactions, or mechanical execution.
  • Trivialise intended gameplay challenge or fully solve gameplay mechanics.
  • Reveal hidden, future, or otherwise inaccessible information.
  • Undermine competitive integrity or fair play.
  • Mislead users, hide functionality, or otherwise behave maliciously or deceptively.

Plugin Permissions

Plugins which engage in certain behaviours are required to obtain permissions from users in order to operate.

Value Description
httpAccess Allows the use of HTTP-related functionality if provided.
Makes use of base URLs specified in the plugin's manifest file.
chatAccess Allows the use of Chat-related functionality if provided.

Moderation

All plugins are required to pass through the moderation process before they can be released. The features and capabilities that a plugin offers will place them into one of 2 categories: Allowed or Prohibited, giving more specific guidance on what is/isn't considered acceptable.

Allowed

Simple features that are generally considered acceptable for any use:

  • UI improvements and overlays that reorganise or more clearly display existing non-combat information.
  • Notifications based on visible or already-known non-combat events.
  • Filtering, sorting, and interface customisation.
  • XP calculators, planning tools, and resource trackers using public or player-known data.
  • Logging and historical tracking (drops, kills, session stats, etc.).
  • Manually placed markers or notes.

Subject to review

More complex or sensitive features may provide gameplay advantages depending on implementation. These are subject to additional review and may require iteration in order to comply with guidelines:

  • Any plugin which requests a permission.
  • Enemy timers and state tracking.
  • Combat information overlays.
  • Combat assistance features based on visible or deterministic gameplay information, where they do not reveal hidden or future game state.
  • Combat state features up to parity with existing combat design.
  • Navigation or guidance systems.
  • Timing, predictive, or assistive gameplay tools of a non-combat nature.
  • Input or menu customisation.
  • Detached camera features that allow world interaction or extended player visibility.
  • Obtaining any information about other players.
  • Containing custom resources like images or sounds.

Info

Combat feature parity refers to taking visual elements that are already present for some content, and using plugins to recreate those elements for other content. Examples of parity features:

  • Overhead enemy adrenaline bars that count auto attacks between special attacks. Feature is present at Sanctum of Rebirth, the same situation applies to Araxxor or Kalphite King.
  • Area attack telegraphs attached to fixed locations or determined by player position at attack start. Feature is present at the Gate of Elidinis, the same situation applies to Croesus or TzKal-Zuk.
  • Overhead or minimap markers for a specific enemy. Feature is present at Vorago (clones), the same situation applies to any boss where there is an important minion, such as Nex or Vorkath.

Approval depends on whether the feature:

  • Automates or substitutes player decisions.
  • Reduces intended gameplay challenge.
  • Creates unfair competitive advantages.
  • Uses inaccessible or future-state information.
  • Has dependencies on plugins which themselves also require review.

Features that provide interpreted or actionable gameplay recommendations may be subject to stricter review.

Prohibited

The following are not permitted:

  • Automating gameplay actions or sending inputs/actions to the game.
  • Predicting, calculating, or indicating future mechanics, attacks, safe locations, or NPC/player states, beyond parity with existing combat design.
  • Automatic prayer switching/ability recommendations or execution.
  • Automatically indicating where players should stand or move.
  • Revealing hidden information or inaccessible game state.
  • Modifying interfaces or click zones in ways that reduce intended difficulty.
  • Offensive, malicious, or deceptive content.
  • Copying someone else's plugin and making minor changes.
  • Any features that behave similarly to prohibited examples may also be disallowed.
  • Plugins cannot export any information about other players (we are hoping to revise this rule in the future).

Example prohibited features

Prohibited plugin features include, and are not limited to:

  • Next attack prediction (timing or attack style).
  • Projectile targets, or target locations, as well as impact locations derived from hidden or otherwise inaccessible information.
  • Prayer switching indicators or which prayer to use.
  • Combat attack counters or mechanic countdowns, excepting parity mentioned above.
  • Indicates the time where a boss mechanic may start or end.
  • Anything that automatically indicates where to stand, or not to stand. (This only applies to automatic indicators, and not tiles which have been manually marked.)
  • Any addition of new menu entries which cause actions to be sent to the server.
  • Any unhiding of hidden interface components.
  • Any movement or resizing of click zones for 3D components.
  • Any movement or resizing of click zones for any interface or component of the action bars, inventory, worn equipment, or familiar.
  • Indicates which player an NPC is focused on.
  • Provides additional player information in PvP contexts, such as scouting, targeting, opponent tracking, or loot prediction.
  • Detached camera features that provide unfair advantages or allow unintended interaction with game content.
  • Changing/overriding the appearance of player controlled models, except for hiding them entirely.

AI Policy

  • All plugin documentation should be clearly readable, well laid out, and written as though a brand new player needed to understand how to use the plugin.
  • Plugin code should be clearly commented. This will allow the Plugin Moderator to quickly grasp the intention of your plugin and complete the moderation process more smoothly. It will also set a good coding standard for novice plugin developers to follow and learn from.
  • Plugin code which is unnecessarily difficult to follow will result in rejection of the plugin. This includes code output from language transcoding processes, deliberate obfuscation, or unvetted AI generation. It is your responsibility to provide code which is lean, efficient and human-readable.

The goal isn't to police the use of AI itself, but to maintain a high standard of documentation and ensure plugins remain approachable, authentic, and consistent with the expectations of our community.

Our policy does not prohibit using Claude Code, Codex, or similar tools in your own project. AI-assisted code is acceptable provided you personally review and understand it, and the submitted plugin is readable, well documented, and maintainable. Unvetted or unnecessarily obscure AI-generated code may be rejected.

Any code, projects, or documentation provided by us, those materials must not be uploaded or exposed to an AI model. If the tool only accesses your own code and public documentation, not private API or client internals or anything we supplied, then that is fine.

Examples of things you cannot upload to AI

Any of the documentation website, examples supplied by any Jmod through the discord, or any other developer's code without their consent.

Things you can upload

Anything that is 100% your own work.