In what order does IBM Bob load rules, AGENTS.md, and mode instructions?

IBM's custom rules page (read November 10, 2026) says Bob combines global rules from ~/.bob/rules/ first and workspace rules from .bob/rules/ second, and that within each level mode-specific rules (.bob/rules-{mode-slug}/) load before general rules. AGENTS.md in the workspace root loads after the mode-specific rules but before the general workspace rules. Files in each directory are read recursively in alphabetical order, symlinks are followed to a depth of five, and cache files and empty files are skipped. A mode's customInstructions are combined with its rules-{slug} files. Bob Shell adds a hierarchy for AGENTS.md: ~/.bob/AGENTS.md, then the project root and parent directories, then subdirectories. IBM says workspace rules can override global rules, but it does not publish a conflict-resolution algorithm, so write rules that never contradict each other.

How do I stop a Bob custom mode from editing files outside my autoscripts folder?

Give the mode an edit group restricted with fileRegex. In .bob/custom_modes.yaml the edit entry becomes a nested list: the word edit followed by an object with fileRegex and description, for example fileRegex '^autoscripts/.*\.(py|js)$'. The mode can then read anything its read group allows but can only write files whose workspace path matches the pattern. Leave out execute and mcp unless you need them, because omitting a group removes those tools, and unknown group names grant nothing. Test the regex before you commit it: IBM warns that an invalid fileRegex can stop the whole mode file from loading, which silently removes every custom mode in it.

What happens if two Bob custom modes share the same slug?

It depends on which client you read. The Bob IDE custom modes page says project overrides take precedence over global overrides, which take precedence over the built-in defaults, so a project mode with slug ask replaces Ask. The Bob Shell custom modes page says that if two modes share a slug, Shell uses the first one it finds in the order built-in, user-level, then project-level, which means the built-in wins. Both pages were read on November 10, 2026. Until IBM reconciles them, give every custom mode a unique slug, never reuse agent, plan, or ask, and never define the same slug in both ~/.bob/settings/custom_modes.yaml and .bob/custom_modes.yaml.

How do I write a Bob skill for Maximo automation scripts?

Create a folder under .bob/skills/ (or ~/.bob/skills/ for global use) and put a SKILL.md inside it with YAML frontmatter holding name and description, followed by the instructions. The Bob Shell skills page says the name must match the folder name, folder names must be lowercase kebab-case of up to 64 characters, and Bob skips folders with invalid names. Supporting files such as checklists, knowledge files, and scripts can sit next to SKILL.md. IBM's own maximo-script-optimizer skill in ibm-self-serve-assets/building-blocks is a good anatomy example: a SKILL.md of about 20 KB, a tools/fetch_maximo_scripts.py, a knowledge/ tree, and an examples/ folder. Note that its folder is maximo-code-optimization while its frontmatter name is maximo-script-optimizer, which breaks the documented folder-name rule.

Can I package Bob modes, rules, skills, and MCP servers as one plugin for my Maximo team?

Yes, with caveats. IBM's October 1, 2026 release post says skills, modes, rules files, and MCP configuration can live under .bob/plugins/ / in a workspace or ~/.bob/plugins/ / globally, and IDE 2.3.0 (October 2026) added an mcp.json inside a plugin that loads with the plugin's skills, modes, and rules. Commit the workspace plugin folder and everyone who opens the repository gets it. What we could not find is a plugin manifest specification or a docs page that defines the internal folder layout, so mirror the .bob layout and test it. For VS Code extensions such as a premium package, the RequiredExtensions group policy installs them from the marketplace on startup.

Teaching Bob Your Maximo House Rules: AGENTS.md, Rules, Custom Modes, Skills, and Plugins

🎯 Who this is for: Maximo developers and technical leads who have decided to pilot Bob (or have been told to) and now need it to write automation scripts the way their shop writes them. You know what a launch point, an MboSet, and an object structure are. You want files you can commit, not a feature tour.

Series: IBM Bob for Maximo Teams | Part 6 of 9 | Read time: ~35 minutes
Previous: Part 5, Pilot Playbook | Next: Part 7, Hooks, MCP, and Guardrails | Series index: Start here

🔥 The Rules File That Was There All Along

A team we spoke with had done the sensible thing. Their autoscript standards lived in a tidy markdown file in the repository: name scripts this way, log like this, close what you open, never touch the database. A senior developer had spent a week writing it.

Bob ignored it for a month.

Not out of malice. The file was called docs/AUTOSCRIPT_STANDARDS.md. Nothing in Bob's configuration pointed at it. Bob did what every agent does with an unreferenced file: it read it when it happened to search that folder, and otherwise wrote generic Jython with service.log() calls, a count() loop, and a save() on a relationship set inside an object launch point. The reviewers caught most of it. Not all.

The fix took ten minutes. They moved the standards into the places Bob actually loads, split them so the review persona and the writing persona each got what they needed, and fenced the writing persona so it could only touch the scripts folder. The findings in review dropped, and, more usefully, the remaining findings were about logic instead of style.

That is what this part is about. In Part 4 we said the single highest-leverage thing a Maximo team can do is feed Bob its house rules. In Part 5 we made "standards findings" a pilot metric. Here we show exactly where each kind of rule goes, in what order Bob reads them, how to turn advice into hard tool boundaries, and how to package the lot so the next developer gets it by cloning the repository.

💡 Key insight: A rule is advice. A mode is a boundary. A skill is a procedure. A command is a shortcut. A plugin is a delivery mechanism. Most teams write only the first and wonder why the agent still wanders. Use each for the job it is built for.

📌 The Short Version

Question	Short answer	Source
Where do always-on house rules go?	AGENTS.md at the repo root, plus .bob/rules/ for longer topic files	IBM custom rules docs, read Nov 10, 2026
Where do persona-specific rules go?	.bob/rules-{mode-slug}/, merged with the mode's customInstructions	IBM custom rules and custom modes docs
What order does Bob load them in?	Global rules, then workspace mode-specific, then AGENTS.md, then general workspace rules	IBM custom rules docs
How do I stop edits outside autoscripts/?	A custom mode whose edit group carries a fileRegex	IBM custom modes docs
What if two modes share a slug?	IDE and Shell docs disagree; use unique slugs	IBM IDE and Shell custom modes docs
How do I package a procedure?	A skill folder with SKILL.md; folder name must match name	IBM Shell skills docs
How do I share all of it?	.bob/plugins/<name>/, with mcp.json since IDE 2.3.0	IBM Oct 1, 2026 blog; IDE changelog 2.3.0
Is there a plugin manifest spec?	Not that we could find	Docs, changelogs, and IBM's empty marketplace template repo
Does IBM do this itself on Maximo code?	Yes, in ibm-mas/cli	GitHub, read live Nov 10, 2026

Labels, as in earlier parts: [IBM] means the claim is on an IBM page or IBM repository, with the date we read it. [TMG] means it is our assessment or our example. We wrote and linted every file in this part, but we did not run them against a customer's Bob tenant, and we say so where it matters.

🗺️ Six Mechanisms, Six Maximo Jobs

Before the detail, here is the whole map. Every mechanism below is a plain file under .bob/ (or ~/.bob/ for global use) that you can version, review, and diff.

Mechanism	Where it lives	What it is for	The Maximo use for it
AGENTS.md	Workspace root (Shell also reads parents, subfolders, and ~/.bob/AGENTS.md)	Always-on team conventions, readable by other agents too	The ten rules a reviewer would reject a PR for: naming, launch points, logging, MboSet ownership, save() discipline, no SQL
Rules	.bob/rules/ (all modes), .bob/rules-{slug}/ (one mode), ~/.bob/rules/ (global)	Longer topic files, scoped by mode	A full autoscript style guide, a Java MBO guide, an integration (OSIN/OSOUT/publish channel) guide
Custom modes	.bob/custom_modes.yaml, ~/.bob/settings/custom_modes.yaml	A persona with an exact tool set and file fence	An autoscript writer that can only edit autoscripts/, a reviewer that cannot edit at all
Skills	.bob/skills/<name>/SKILL.md, ~/.bob/skills/	A named, on-demand procedure with supporting files	Autoscript review against a checklist, Java-to-script conversion, launch-point selection
Slash commands	.bob/commands/*.md, ~/.bob/commands/	A reusable prompt with arguments	/autoscript-review <file>, /new-autoscript <object> <event>
Plugins	.bob/plugins/<name>/, ~/.bob/plugins/<name>/	Ship modes, rules, skills, and MCP config together	One "tmg-maximo" bundle per estate, with a read-only Maximo MCP server definition switched off by default

Two things are deliberately missing from this table. Hooks (the deterministic layer that can block a tool call) and the MCP server itself (how Bob talks to a live Maximo) get their own treatment in Part 7. Bob Shell in CI is Part 8. Rules and modes shape what Bob tries to do. Hooks decide what it is allowed to finish. You need both, and this part is the first half.

📚 How Bob Loads Your Rules

IBM documents the rule system on two pages that say nearly the same thing: the IDE custom rules page and the Shell custom rules page, both read on November 10, 2026 [IBM]. The Shell page states plainly that "Bob Shell uses the same custom rules system as IBM Bob IDE."

The sources

Source	Scope	Notes [IBM]
~/.bob/rules/	Global, every project	Windows: %USERPROFILE%\.bob\rules\
.bob/rules/	This workspace, every mode	Read recursively, so subfolders count
.bob/rules-{mode-slug}/	This workspace, one mode	Works for built-in modes (rules-agent, rules-plan, rules-ask) and any custom slug
A mode's customInstructions	One mode	Combined with that mode's rules-{slug} files
AGENTS.md (workspace root)	This workspace	On by default. Disable with "bob-code.useAgentRules": false (IDE) or "bob-shell.useAgentRules": false (Shell)
~/.bob/AGENTS.md, parent and subfolder AGENTS.md	Shell only	Documented on the Shell configuring page as global, project, and local context

The order

IBM's wording is: Bob combines "Global rules (~/.bob/rules/)" then "Workspace rules (.bob/rules/)", and "within each level, mode-specific rules load before general rules." For AGENTS.md it says the file is "loaded after mode-specific rules but before general workspace rules" [IBM, rules docs, Nov 10, 2026]. Put together:

 1. ~/.bob/rules-{active-mode}/     global, mode-specific
 2. ~/.bob/rules/                   global, general
 3. .bob/rules-{active-mode}/       workspace, mode-specific (+ mode customInstructions)
 4. AGENTS.md                       workspace root (Shell: plus ~/.bob, parents, subfolders)
 5. .bob/rules/                     workspace, general (recursive, alphabetical)

Step 1 is our reading of "within each level" applied to the global level. IBM's pages only show the workspace form of the mode-specific folder, so treat a global ~/.bob/rules-{slug}/ as something to test before you depend on it [TMG].

File behavior worth knowing

Recursive and alphabetical. Every file in a rules directory is read, including subdirectories, in alphabetical order by filename. Prefix files with numbers (01-naming.md, 02-logging.md) if order matters to you.
Filtered. .DS_Store, *.bak, *.cache, *.log, *.tmp, and Thumbs.db are skipped. So are empty files.
Symlinks are followed to a depth of five. That is how you share one standards file across several Maximo repositories without copying it.
No file type restriction is documented. IBM's own example mixes .md and .txt. Stick to markdown so humans can read it in the repository.

What "override" means here

Both pages say "Workspace rules can override global rules." Neither describes a conflict-resolution algorithm. In practice the rules are text concatenated into the agent's context, so "override" means "the later, more specific instruction usually wins in the model's judgment." That is not a guarantee. Write rules that never contradict each other, and when a workspace rule deliberately replaces a global one, say so in the text: "This replaces the global logging rule for this repository" [TMG].

A trap in the recursive read

Because .bob/rules/ is read recursively for every mode, a file at .bob/rules/python/development-guide.md reaches Ask and Plan as well as your coding mode. If you want a guide to apply to one persona only, put it in .bob/rules-{slug}/, not in a subfolder of .bob/rules/. We will see IBM's own MAS CLI team make exactly this choice, probably on purpose, later in this part.

📝 A Maximo AGENTS.md You Can Copy

AGENTS.md is the right home for rules that should apply everywhere, to every persona and every agent. It is also read by other coding agents, so a developer using Claude Code or Copilot in the same repository gets the same rules. Keep it short enough that nobody is tempted to skip it, and put the long explanations in .bob/rules/.

The rules below come from three places: IBM Community guidance from IBM's own Maximo engineers, the patterns in IBM's maximo-script-optimizer skill, and the standards TMG ships in Max_autoscripts. Where those sources disagree, we picked a side and say why underneath.

# AGENTS.md — Maximo Manage customization repository

This repository holds automation scripts, launch-point metadata, and integration
configuration for <CLIENT> MAS Manage <VERSION>. These rules apply to every agent
and every mode. Longer guides are in .bob/rules/.

## 1. Scope and safety
- Never connect to, query, or change a Maximo environment unless the task says so
  and names the environment. Default to working on files only.
- Never write credentials, API keys, hostnames, or person data into any file.
  Use environment variables or ask.
- If a field, relationship, object, or domain name is not in this repository or
  in the task, STOP and ask. Never invent attribute or relationship names.

## 2. Layout and naming
- Scripts live in autoscripts/<LAUNCHPOINT_TYPE>/<SCRIPTNAME>.py (Jython) or .js (Nashorn).
- Custom scripts: <CLIENTPREFIX>_<OBJECT>_<PURPOSE>, upper case, e.g. ACME_WO_FAILCODE_REQ.
- Scripts that bind by naming convention (for example OSIN.<OS>, OSOUT.<OS>,
  OSACTION.<OS>.<ACTION>) keep IBM's exact name. Never rename them; the name is the binding.
- Every script has a header: purpose, launch point type and event, object or
  attribute, variables, author, date, ticket.
- One business rule per script. Shared logic goes in a library script, not copied.

## 3. Launch points
- Choose the narrowest launch point that does the job. Attribute validate before
  object save; object save before object init. Never put heavy logic in object
  Init: it runs for every record a list tab loads.
- Object save scripts: state the event (add/update/delete) and timing
  (before save / after save / after commit) in the header and justify it.
- Use after commit only for work that must not roll back with the transaction,
  such as an outbound notification.

## 4. Logging
- Do not use bare service.log() or the generic "maximo.script" logger.
- MBO launch points: logger = mbo.getMboLogger(). Integration scripts: a named
  logger such as maximo.integration.<SCRIPTNAME>.
- Guard debug output: if logger.isDebugEnabled(): logger.debug(...).
- Never log person data, passwords, or full record payloads.

## 5. MboSets
- If you got the MboSet from MXServer.getMXServer().getMboSet(...), you own it:
  set the where clause, process, save once if needed, and close() it in finally.
- If you got it from a relationship on the launch-point mbo, you do not own it:
  never save(), close(), or moveXXX() it.
- Do not use count() to test existence or to drive a loop. Use isEmpty() or
  notExist() to test, and iterate with moveFirst()/moveNext() or getMbo(i)
  until it returns None on a set you own.

## 6. Saving
- Never call mbo.save() or mboSet.save() inside an object launch point on the
  object being saved. The framework saves it.
- Never call save() inside a loop. Make all changes, then save the owned set once.
- Use setValue with the right access modifiers instead of saving to bypass validation.

## 7. Data access
- No direct SQL. No JDBC connections, no DBShortcut, no executeQuery, no
  string-built SQL against database tables.
- Where clauses on owned MboSets: never concatenate user-supplied values. Use
  SqlFormat binding, or at minimum escape single quotes.
- Reads and writes go through MBOs, object structures, or the REST/OSLC API.

## 8. Errors
- User-facing errors use service.error(group, key) with a message from MAXMESSAGES.
  Never hard-code message text.
- Do not swallow exceptions silently. Log, then re-raise or set a clear error.

## 9. Before you finish
- List every file you changed and every launch point the change affects.
- State which Maximo version and language (Jython/Nashorn) the script assumes.
- Propose test steps a functional tester can run in a non-production environment.

Why these rules, and where the sources disagree

Logging. Jason Uppenborn, in the IBM Community thread Automation Scripts: Do/Don't, Performance & Code Styling (November 15, 2022, read November 10, 2026), says to "actively discourage the use of service.log() and of getting the plain 'maximo.script' logger," and recommends mbo.getMboLogger() for MBO-based launch points and a maximo.integration.SCRIPTNAME logger for integration scripts. IBM's maximo-script-optimizer skill instead teaches MXLoggerFactory.getLogger("maximo.script.SCRIPTNAME"). Both are better than bare service.log(). We chose the Community guidance because it ties log output to the object's own logger settings. Pick one and write it down, because if you do not, the skill's example will become your standard by default.

MboSet ownership. The same thread states the rule that "if they didn't get the MboSet from MXServer, then it is not up to them to save() or close() or even moveXXXX() on it." IBM's skill shows a try/finally that closes a set obtained with mbo.getMboSet("WORKORDER"), which is a relationship set. Those two positions conflict. We follow the Community rule in the house rules, and this is precisely why house rules exist: when you enable an IBM skill, its examples arrive in Bob's context as well, and your AGENTS.md is what tells Bob which one your shop follows.

`count()`. Steven Shull, in the same thread, advises developers "to avoid count() entirely over just minimizing it," because it is usually used to loop or to test existence, and both have better forms. The IBM skill's own resource pattern loops with for i in range(mboSet.count()). Again, the house rule settles it.

Launch points. Shull also writes that "choosing the right launch point is critical" and that much working code "isn't optimized because the developer chose the wrong event." That is why section 3 asks the agent to justify its event and timing in the header. An agent that has to explain its choice makes fewer careless ones.

Naming. The OSACTION.MXAPIINSPRESULT.CREATEWO example comes straight from IBM's skill, which insists on preserving "exact script name from Maximo API response." The client prefix convention is ours [TMG]. Replace it with yours.

⚠️ Keep `AGENTS.md` under two screens. Every line is loaded into every request in every mode. A 900-line AGENTS.md costs Bobcoins on every turn and dilutes the rules that matter. Move explanations, examples, and long checklists into .bob/rules/ or a skill, where they load only when relevant.

What goes in `.bob/rules/` instead

AGENTS.md says what. The rules folder can say how, at length:

.bob/
  rules/
    01-maximo-environment.md     # versions, languages, which environments exist (no hostnames)
    02-autoscript-style.md       # full style guide with good/bad examples
    03-integration.md            # object structures, publish channels, enterprise services
    04-java-customization.md     # MBO class rules, if you still maintain Java
  rules-maximo-autoscript/
    01-templates.md              # header template, library-script pattern
  rules-maximo-reviewer/
    01-review-format.md          # findings table format, severity scale

Because rules/ loads in every mode, keep it to facts and standards everyone needs. Persona behavior, such as the review output format, belongs in rules-maximo-reviewer/, which only the reviewer sees.

🎭 Custom Modes: Turning Advice into Boundaries

Rules tell Bob what you would like. A custom mode decides what it can do. IBM documents modes on the IDE custom modes page and the Shell custom modes page, both read November 10, 2026 [IBM].

Where modes live and what they contain

Project modes: .bob/custom_modes.yaml. Global modes: ~/.bob/settings/custom_modes.yaml.
The file holds a top-level customModes: list. YAML is preferred; JSON is accepted because YAML is a superset.
Fields: slug (letters, numbers, hyphens only), name, roleDefinition, whenToUse (optional), description (optional, shown in the mode picker), customInstructions (optional), groups, and allowedSubagents (optional).
In the Shell you start in a mode with bob --mode <slug> or bob run --mode <slug>, and switch with /mode.

The tool groups

Group	What it grants [IBM]	IDE	Shell	In policy DisabledAutoApprovalGroups
read	Read files and directories, search	Yes	Yes	Yes
edit	Write, create, delete files; can be fenced with fileRegex	Yes	Yes	Yes
execute	Terminal commands (command is a legacy alias)	Yes	Yes	Yes
mcp	All MCP server tool calls	Yes	Yes	Yes
skill	Load and activate skills	Yes	Yes	Yes
workflow	Launch pre-defined workflows	Yes	Not listed	Not listed
todo	Update the task todo list	Yes	Yes	Yes
subtask	Create subtasks	Yes	Not listed	Yes
subagent	Spawn subagents	Yes	Yes	Yes
mode	Switch to another mode	Yes	Yes	Yes
browser	Fetch public web pages (experimental)	Not listed	Yes	Not listed

Three validation rules from IBM decide most outcomes: if you omit `groups`, the mode gets no grouped tools; unknown group names grant nothing (so a typo silently removes a capability rather than failing loudly); and an invalid `fileRegex` can prevent the mode file from loading at all.

The full file: two Maximo modes

This is a complete .bob/custom_modes.yaml. We validated it as YAML and tested both regular expressions against sample paths [TMG]. We have not loaded it into a licensed Bob tenant for this article.

customModes:
  # ---------------------------------------------------------------
  # 1. Writes and refactors automation scripts. Cannot touch
  #    anything outside autoscripts/. Cannot run commands or MCP.
  # ---------------------------------------------------------------
  - slug: maximo-autoscript
    name: 🛠️ Maximo Autoscript
    description: Writes and refactors Maximo automation scripts in autoscripts/ only.
    roleDefinition: >-
      You are a senior IBM Maximo Manage developer. You write Jython and
      Nashorn automation scripts that follow this repository's AGENTS.md and
      .bob/rules exactly. You prefer the narrowest launch point, you never
      invent attribute or relationship names, and you explain every launch
      point and event choice.
    whenToUse: |-
      Use this mode to create, modify, or refactor automation scripts and
      their launch-point metadata under autoscripts/. Do not use it for Java
      MBO classes, application XML, integration mapping, or anything that
      needs a live Maximo connection.
    customInstructions: |-
      - Before editing, state the launch point type, object or attribute,
        event, and timing you intend to use, and why.
      - Edit only files under autoscripts/. If the task needs another file,
        stop and say which file and why.
      - Never add direct SQL, DBShortcut, or JDBC code.
      - When finished, list changed files and give test steps for a
        non-production environment.
    groups:
      - read
      - - edit
        - fileRegex: '^autoscripts/.*\.(py|js|json|md)$'
          description: Automation scripts, launch-point metadata, and script notes only
      - skill
      - todo
      - subagent
    allowedSubagents:
      - explore

  # ---------------------------------------------------------------
  # 2. Reviews scripts and diffs. Cannot edit, run commands, or
  #    call MCP tools. Its only helper is a read-only explorer.
  # ---------------------------------------------------------------
  - slug: maximo-reviewer
    name: 🔍 Maximo Reviewer
    description: Read-only review of Maximo scripts against house rules.
    roleDefinition: >-
      You are a strict Maximo code reviewer. You check automation scripts
      against AGENTS.md and .bob/rules, and you report findings. You never
      change files.
    whenToUse: |-
      Use this mode to review an automation script, a folder of scripts, or a
      branch diff before a pull request. Use it before enabling any skill
      that writes files.
    customInstructions: |-
      - Report findings as a table: file, line, rule (cite the AGENTS.md
        section), severity (Critical, High, Medium, Low), suggested fix.
      - Flag any attribute, relationship, or object name you cannot confirm
        from the repository as "unverified name".
      - End with a verdict: ready, ready with fixes, or not ready.
    groups:
      - read
      - skill
      - todo
      - subagent
    allowedSubagents:
      - explore

Notes on the choices:

The fence is the point. fileRegex matches the workspace-relative path; IBM's own examples include ^src/.*, which only works on relative paths. Our pattern allows .py, .js, .json (for launch-point metadata exported alongside scripts), and .md (for per-script notes) under autoscripts/ and nothing else. The description next to it is what Bob tells the user when it refuses an edit.
Quote the regex. In YAML, single quotes keep the backslash literal, which is what the regular expression needs. IBM's example uses double quotes with an escaped backslash ("\\."); both work, mixing them up does not.
No `execute`, no `mcp`. The writer cannot run anything and cannot reach Maximo. That keeps writing and talking to a live system in separate personas. If you need a linter, add execute and restrict commands with allowedExecutors in Shell settings, which Part 7 covers alongside hooks.
No `edit` in the reviewer. A reviewer that can "just fix it" is a writer with less scrutiny. If the reviewer activates a skill whose instructions say to write files, the mode still has no edit tools. That is our reading of how groups and skills interact (skills provide instructions, the mode provides tools); IBM does not state it in one sentence, so test it [TMG].
`allowedSubagents`. IBM's subagents page (read Nov 10, 2026) lists two subagent types: explore, "read-only codebase exploration, runs on a lighter model," and general, with "full tool access." The custom modes page says that "if you set allowedSubagents, only the listed subagent presets are available in that mode." Restricting both modes to explore stops a reviewer from spawning a general subagent that could edit. IBM lists the field but shows no YAML example of it, so the list-of-names form above is our inference from the field description [TMG]. The subagent group must also be present, or no subagent can spawn at all.
`todo` but not `mode`. Neither persona can switch itself into Agent mode. A human does that.

Mode-specific rules, next to the mode

Each slug gets its own rules folder, combined with customInstructions:

.bob/
  custom_modes.yaml
  rules-maximo-autoscript/
    01-templates.md
    02-library-scripts.md
  rules-maximo-reviewer/
    01-review-format.md
    02-severity-scale.md

Keep customInstructions to a handful of lines that define the persona, and put anything longer in these files. They diff better, and you can link to them in pull requests.

The duplicate-slug conflict

This is the one place where IBM's two documentation sets flatly disagree [IBM, both read Nov 10, 2026]:

	Bob IDE custom modes page	Bob Shell custom modes page
Rule	"Project-specific overrides take precedence over global overrides, which take precedence over defaults."	"If two modes share a slug, Bob Shell uses the first one it finds, in this order: Built-in modes, User-level modes, Project-level modes."
Effect of a project mode with slug ask	Replaces the built-in Ask	Built-in Ask wins; your mode is ignored
Effect of the same custom slug in global and project files	Project wins	Global (user-level) wins

The IDE page even documents overriding Ask with a project mode as a feature. The Shell page tells you to "use a unique slug for each custom mode." If you override ask in the IDE and then run the same repository in Shell on a CI runner, you get two different behaviors from one file. And the IDE page separately warns that "duplicate slugs can prevent modes from loading correctly."

Our rule: never reuse agent, plan, or ask; prefix every custom slug (maximo-, or your client prefix); and never define the same slug in both the global and the project file. If you want stricter defaults for Ask, do it with .bob/rules-ask/, which both clients honor, rather than by overriding the mode [TMG].

🧰 Writing a Maximo Skill

A skill is a procedure with a name. It is not loaded until Bob decides it is relevant (or you invoke it), which is why long, task-specific material belongs here rather than in AGENTS.md. IBM documents skills on the IDE skills page and the Shell skills page, read November 10, 2026 [IBM].

The format

Location: .bob/skills/<name>/SKILL.md in the project, or ~/.bob/skills/<name>/SKILL.md globally. If both define the same name, the project skill wins.
Frontmatter: name and description are required. The IDE page says skills without descriptions are ignored. Everything after the closing --- is the instruction body.
The folder-name rule: the Shell page says name must "match the skill's folder name," because "Bob uses the folder name to identify and reference the skill." Folder names must be lowercase kebab-case (letters, numbers, single hyphens), at most 64 characters, and "Bob skips folders with invalid names." The October 1 release added a startup warning for invalid skill directory names [IBM, Oct 1, 2026 blog].
Supporting files: checklists, templates, reference documents, and scripts in subfolders, which Bob can read once the skill is active.
Loading: "Skills load once per conversation." Bob picks a skill by its description, so the description is effectively the trigger.
Approval: by default Bob asks before activating a skill. You can auto-approve skills in IDE settings or by adding "skill" to approval.allowed_permissions in Shell. On client machines, don't.

Anatomy of IBM's `maximo-script-optimizer`

IBM's Build Engineering team publishes this skill in `ibm-self-serve-assets/building-blocks`, under ibm-bob/skills/maximo-code-optimization/. It was added on June 12, 2026 (commit 7ad7a7d) and last updated on October 21, 2026 (commit 8ab8576, "[Updated] to alight with the new data changes") [IBM, GitHub, read live Nov 10, 2026]. The same skill also ships as maximo-code-optimization.zip under automation/operate/asset-management/bob-skills/, which is the path Part 4 documented.

The unpacked tree is a textbook skill layout:

maximo-code-optimization/
  SKILL.md                                  # ~20 KB, 645 lines
  tools/
    fetch_maximo_scripts.py                 # pulls scripts via MXAPIAUTOSCRIPT
  knowledge/
    INDEX.md
    core/
      maximo-scripting-fundamentals.md
      performance-optimization.md
      security-best-practices.md
    procedures/
      script-optimization-workflow.md
    reference/
      quick-reference.md
    troubleshooting/
      common-issues.md
  examples/
    optimization-example.md

Part of the skill	What IBM put there	Lesson for your own skill
Frontmatter	name: maximo-script-optimizer; description "Expert skill for fetching, analyzing, optimizing, and securing IBM Maximo automation scripts..."	The description is the trigger; make it say when to use the skill
"When to Use" section	Trigger phrases such as "optimize my Maximo scripts"	Lists like this help, but the frontmatter description is what Bob matches
Interactive workflow	Phases: environment setup, fetch, analysis, optimization, report	Phase the procedure so a reviewer can stop it between phases
File naming rules	Preserve exact Maximo script names; original/, optimized/, reports/ folders	Fix the output layout so diffs are predictable
Patterns	SQL escaping, try/finally MboSet close, MXLoggerFactory logging, null checks	These examples will compete with your house rules; see the AGENTS.md notes
tools/	A Python script that reads MAXIMO_URL and MAXIMO_API_KEY from a .env file	A skill with a tool is code running under your privileges
knowledge/	Long reference material, linked from INDEX.md	Keep SKILL.md focused; push depth into supporting files, as IBM's docs advise
examples/	One worked optimization	One concrete example beats ten rules

Four things we noticed when we read it, which are worth knowing before you copy its pattern:

It breaks the folder-name rule. The folder is maximo-code-optimization; the frontmatter name is maximo-script-optimizer. Under the Shell docs, Bob identifies the skill by folder, so expect to see and reference it as maximo-code-optimization. It will probably still load, because the folder name itself is valid kebab-case, but it is the kind of mismatch that makes "which skill ran?" hard to answer in a log. Do not repeat it.
The October 21 update was a link fix. We compared the trees at both commits. SKILL.md, the tool, and the example are byte-identical. What changed was knowledge/INDEX.md (two broken links and two anchors repaired) and the "Related" lines at the end of performance-optimization.md and security-best-practices.md (dead links removed). The commit touched 300 files across the repository. If anyone tells you the skill was substantially revised in October, it was not.
The tool disables TLS verification. fetch_maximo_scripts.py calls requests.get(..., verify=False, ...), to "handle SSL certificate issues for self-signed certificates." That is convenient on a lab cluster and wrong anywhere else. If you adapt the tool, point it at your CA bundle instead.
The workflow asks for an API key and writes it to a file. Phase 1 tells Bob to ask for the base URL and API key and write both into maximo-scripts/.env. The skill says "DO NOT commit to git," but nothing enforces it. Add maximo-scripts/.env to .gitignore and .bobignore before anyone runs the skill, and use a read-only key.

A Maximo skill of your own

Here is a small, review-only skill that leans on your house rules instead of carrying its own. Note that the folder and name match.

.bob/skills/maximo-autoscript-review/
  SKILL.md
  checklist.md
  severity-scale.md
  examples/
    wo-failcode-before.py
    wo-failcode-review.md

---
name: maximo-autoscript-review
description: Review one or more Maximo automation scripts against this repository's AGENTS.md and .bob/rules, and report findings without editing files. Use for "review this autoscript", "check my launch point script", or before a pull request that touches autoscripts/.
---

# Maximo autoscript review

Do not edit any file while this skill is active.

1. For each script, identify: language (Jython or Nashorn), launch point type,
   object or attribute, event, timing, and implicit variables used.
2. Walk `checklist.md` item by item. Every finding must cite the AGENTS.md
   section number or the .bob/rules file it violates.
3. Pay particular attention to:
   - MboSets: who owns each set (MXServer vs relationship), and whether it is
     saved, closed, or moved by code that does not own it.
   - save() calls inside the launch point object's own save event, or inside loops.
   - count() used to test existence or drive a loop.
   - Bare service.log() or the generic maximo.script logger.
   - Any SQL string, DBShortcut, JDBC, or unescaped value in setWhere().
   - Attribute, relationship, or object names you cannot find in this repository:
     mark them "unverified name", do not assume they exist.
4. Grade each finding with `severity-scale.md`.
5. Output one table per script (file, line, rule, severity, finding, suggested fix),
   then a one-line verdict: ready, ready with fixes, or not ready.
6. Compare your output format with `examples/wo-failcode-review.md`.

Run it from the maximo-reviewer mode and it inherits that mode's lack of edit tools. Run it from Agent mode and the only thing stopping an edit is the first line of the instructions. That difference is the whole argument for custom modes.

⌨️ Custom Slash Commands

A slash command is a saved prompt. IBM documents them on the Shell slash commands page (read Nov 10, 2026), which says they "work identically across both Bob Shell and Bob IDE" [IBM].

Location: .bob/commands/ (project) or ~/.bob/commands/ (global). Project commands override global ones with the same name.
Name: the filename. .bob/commands/autoscript-review.md becomes /autoscript-review. Names are lowercased and slugified.
Frontmatter: description (shown in the menu) and argument-hint (the grey hint after the command).
Arguments: $1, $2, and so on in the body.
One hard limit: "Custom workflow commands cannot change the active mode." A command cannot put Bob into your reviewer mode. It can only ask.

Two commands a Maximo team will use daily:

---
description: Review a Maximo automation script against house rules (no edits)
argument-hint: <script-path>
---
Use the maximo-autoscript-review skill on $1.

If the active mode is not "Maximo Reviewer", stop and tell me to switch with
/mode before you read the file. Do not edit any file.

---
description: Draft a new automation script from the house template
argument-hint: <OBJECT> <EVENT>
---
Draft a new automation script for the $1 object on the $2 event.

1. Propose the launch point type, timing, and script name per AGENTS.md
   sections 2 and 3, and wait for my confirmation.
2. Use the header template in .bob/rules-maximo-autoscript/01-templates.md.
3. Write the file only under autoscripts/. Never invent attribute names: list
   any you need and ask me to confirm them.
4. Finish with test steps for a non-production environment.

Commands are where you encode the conversation your best developer has with a junior one. They are also the cheapest thing in this part to write, so start here if you have one afternoon.

📦 Packaging It as a Plugin

Everything so far lives in one repository's .bob/ folder. That is fine for one estate. A consultancy or a client with several Maximo repositories wants one bundle. That is what plugins are for.

What IBM has said

September 2026 (IDE 2.2.0): a "plugins/ subdirectory for skills, modes, rules, and MCP" so you can "distribute and share Bob extensions with your team" IBM, [IDE changelog, read Nov 10, 2026].
October 1, 2026: "Skills, modes, rules files, and MCP configuration can now be placed under .bob/plugins/<plugin-name>/ at the workspace level, or ~/.bob/plugins/<plugin-name>/ globally, and Bob picks them up on startup. A team can ship a custom mode, the rules it references, the skills it invokes, and the MCP config together in one plugin directory. The existing root-level layout continues to work" IBM, [Run Bob on your own infrastructure].
October 2026 (IDE 2.3.0): "MCP server configuration inside plugins," an mcp.json that loads "automatically with the rest of the plugin," and "Global plugin directory for MCP configurations" at ~/.bob/plugins/<plugin-name>/mcp.json, which Bob "discovers and watches... live without requiring a restart" [IBM, IDE changelog 2.3.0].
Fix in 2.3.0: "Plugin skills inherit enabled or disabled state." Before this, turning a plugin off did not hide its skills [IBM, IDE changelog].

What IBM has not said

We could not find a plugin documentation page, a manifest file format, a version field, or a defined internal layout. The IBM/ibm-bob-plugin-marketplace repository on GitHub is an empty template [IBM GitHub, read by our research on Nov 10, 2026]. DOC16, our field guide, quotes IBM saying it supports "the plugin format that's become a de-facto standard across the ecosystem," but no page we read says which format that is. So the layout below mirrors the `.bob/` root layout inside the plugin folder, which is the most natural reading of "the existing root-level layout continues to work." Test it on one machine before you roll it out [TMG].

A Maximo plugin layout

.bob/plugins/tmg-maximo/
  custom_modes.yaml                     # maximo-autoscript, maximo-reviewer
  rules/
    01-maximo-environment.md
    02-autoscript-style.md
  rules-maximo-autoscript/
    01-templates.md
  rules-maximo-reviewer/
    01-review-format.md
  skills/
    maximo-autoscript-review/
      SKILL.md
      checklist.md
      severity-scale.md
  mcp.json                              # IDE 2.3.0+, disabled by default
  README.md                             # what this plugin does, who owns it

Two items stay outside the plugin. `AGENTS.md` stays at the repository root, because that is where Bob and every other agent look for it. `.bob/commands/` stays at the workspace level, because none of IBM's plugin statements lists commands among the things a plugin can carry.

The plugin's `mcp.json`

The format is the same mcpServers object as .bob/mcp.json IBM, [MCP in Bob, read Nov 10, 2026]. This one defines the MAS 9.2 Maximo MCP server for a development environment, read-only key, switched off:

{
  "mcpServers": {
    "maximo-dev-readonly": {
      "type": "streamable-http",
      "url": "https://<instance>-mcp.<cluster-apps-domain>/mcp",
      "headers": {
        "apikey": "${MAXIMO_DEV_RO_APIKEY}"
      },
      "protocolNegotiation": "auto",
      "alwaysAllow": [],
      "disabled": true
    }
  }
}

`disabled: true` means nobody connects to Maximo just by opening the repository. A developer turns it on deliberately, in a session where they meant to.
`alwaysAllow: []` means every MCP tool call prompts. Do not pre-approve tools against a live system in a shared file.
The key is not in the file. The Shell documents ${KEY} references to secrets stored with /manage-secrets set [IBM, slash commands page]. We did not find the same substitution documented for the IDE's mcp.json, so verify it in your IDE build before relying on it, and never replace the placeholder with a real key in a committed file.
Transport check. HTTP+SSE was removed in the October 1 release, and Bob "rejects HTTP+SSE configurations on startup" [IBM, Oct 1 blog]. In Part 4 we noted that IBM's 9.2 server returns results over SSE. Streamable HTTP can stream responses that way, so this is probably fine, but test the connection in a sandbox before you ship the definition to a team.

Part 7 goes deeper on MCP: scoping the API key, read-only object structures, and the hooks that can stop a destructive tool call even when the model asks for it.

🚚 Rolling It Out Team-Wide

You now have files. Getting the same files onto every developer's machine, and keeping them there, is a different problem with three layers.

Layer	Mechanism	What it delivers	Who controls it
Repository	Commit AGENTS.md, .bob/, and .bob/plugins/tmg-maximo/	Rules, modes, skills, commands, plugin, for anyone who clones	Repository owners, through pull requests
User	Global plugin in ~/.bob/plugins/<name>/, global rules in ~/.bob/rules/	Cross-repository standards for one person	The developer (or a setup script)
Machine	Group policy: RequiredExtensions, DisabledAutoApprovalGroups, EnforcedHooks	Extensions installed, approvals locked, hooks enforced	IT, through ADMX/ADML, MDM, or /etc/bob/policy.json

RequiredExtensions

IBM's release post says: "The group policy that distributes the self-hosted endpoint can now also install VS Code extensions. Admins list extension IDs in the new RequiredExtensions policy, and Bob installs them from the marketplace on startup, with no action required from the developer." The IDE 2.2.0 changelog adds that extensions "are installed silently in the background with no prompts" [IBM, Oct 1, 2026 blog; IDE changelog 2.2.0].

Be precise about what that means for a Maximo team:

RequiredExtensions installs VS Code extensions, such as a premium package VSIX or the MAF Local Dev Mode extension. It does not install .bob/ plugins, which are folders, not extensions. Plugins travel through the repository or a global folder.
The group policies page, read November 10, 2026, still lists only four policies: DisabledAutoApprovalGroups, UpdateMode, GatewayUrl, and EnforcedHooks. RequiredExtensions appears in the changelog and the blog but not on the reference page, so its exact value format is undocumented. The other string policies use comma-separated lists, and we expect the same, but confirm with IBM before you deploy.
The same page says "Enterprise policies are currently supported by Bob IDE only." Plan on Shell machines and CI runners getting their configuration from the repository instead. Part 8 covers that.

On Linux, a policy file for a Maximo pilot might look like this (root-owned, mode 644, at /etc/bob/policy.json):

{
  "RequiredExtensions": "<publisher.extension-id>,<publisher.extension-id>",
  "DisabledAutoApprovalGroups": "edit,execute,mcp,skill",
  "UpdateMode": "manual"
}

DisabledAutoApprovalGroups is the policy that matters most here. It locks the auto-approve toggles for the listed groups, so even in Agent mode every edit, command, MCP call, and skill activation prompts. That is the machine-level backstop to the mode-level fence. IBM notes that unknown keys are ignored and that a malformed file means "Bob starts without any enforced policies," so validate the JSON in your configuration management tool before it ships.

A rollout sequence that works

Week 0: commit AGENTS.md and .bob/rules/ only. Run the same three tasks with and without them and record the standards findings (the Part 5 metric).
Week 1: add the two custom modes. Tell the team to use maximo-reviewer first and maximo-autoscript second.
Week 2: add the review skill and the two commands. Delete anything nobody used.
Week 3: move modes, rules, and skills into .bob/plugins/tmg-maximo/, keep AGENTS.md at the root, and confirm on a clean clone that nothing was lost.
With IT, in parallel: the policy file with DisabledAutoApprovalGroups, and RequiredExtensions once IBM confirms the format.

🏛️ The Real IBM Example: `ibm-mas/cli`

Everything above is our design. Here is what IBM's own MAS CLI team actually commits. The `ibm-mas/cli` repository, the tooling behind mas install and the Tekton pipelines that install and upgrade MAS, has a .bob/ folder at its root. We listed and read it live with gh api repos/ibm-mas/cli/contents/.bob on November 10, 2026 [IBM GitHub].

ibm-mas/cli (default branch: master)
  .bob/
    custom_modes.yaml
    rules/
      general-guidelines.md          (4.8 KB)
      tekton-development.md          (10.1 KB)
      python/
        development-guide.md         (3.4 KB)
        docstrings.md                (5.9 KB)
    skills/
      test-driven-development/
        SKILL.md                     (9.9 KB)
        testing-anti-patterns.md
      reverse-engineer-tdd-tests/
        SKILL.md                     (18.7 KB)
    plans/                           (23 dated plan files, 2025-01-31 onward)
    redis-locking/                   (README, setup guide, shell script)

There is no AGENTS.md at the repository root, no .bob/mcp.json, no .bob/commands/, and no .bob/plugins/. The most recent commit touching .bob/ was on November 5, 2026; custom_modes.yaml last changed on June 9, 2026.

The mode

The file defines one mode, code-python, named "🐍 Code (Python TDD)". Its roleDefinition is one line: "You are a Python software engineer, with a test-driven development workflow." Its customInstructions tell Bob to use the developer's .venv, to "refuse to proceed with any code changes" if the virtual environment is missing, and to follow .bob/rules/python/development-guide.md "ALWAYS". Its groups are read, edit, command, mcp, and skill, each annotated with the tools it grants, for example edit # (apply_diff, write_to_file).

What it teaches

`command`, not `execute`. IBM's team uses the legacy alias. It still works per the Shell docs, but new files should say execute.
No `fileRegex`. The Python mode can edit any file. For a CLI repository maintained by its own developers that is a reasonable choice. For a Maximo customization repository edited by a pilot group, we would fence it.
Recursive rules on purpose. The Python guide lives in .bob/rules/python/, so it loads in every mode, not just code-python, and the mode's instructions reference it again for emphasis. The alternative was .bob/rules-code-python/. Loading it everywhere means Plan mode also knows the Python standards when it writes a plan, which is probably the intent.
Rules that drive process, not style. general-guidelines.md tells Bob to keep responses concise, to "use the new_task tool with mode set to 'plan' to generate a plan before making non-trivial changes," to write plans to .bob/plans/ with dated names, and to "track progress ONLY in the plan document, NOT in chat todo lists." The 23 committed plan files show the team follows it. For Maximo work, a committed plan per change is an audit trail you get for free.
Mode and rules are consistent, mostly. The rules forbid update_todo_list, and the mode omits the todo group, which enforces the rule. The rules also require new_task, but the mode does not list the subtask group. The mode predates Bob V2 (June 24, 2026), so the groups may have been reorganized since it was written; if you copy this pattern, check that every tool your rules require is in your mode's groups [TMG].
Skills that are about method. Neither skill is Maximo-specific. test-driven-development opens with "NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST," and the development guide links to it by path. Folder names and name fields match in both.

The lesson is less about any single file than about the shape: a short process rule file, a longer domain guide, one persona, method skills, and committed plans. That shape transfers directly to a Maximo customization repository.

🔬 Worked Scenarios

Scenario 1: the writer tries to touch the wrong file

You are in maximo-autoscript mode and ask Bob to add a required failure code check before a work order goes to COMP. Bob drafts autoscripts/object/ACME_WO_FAILCODE_REQ.py and its launch-point JSON. It then decides the domain needs a new value and tries to write dbconfig/domains/FAILCODE.xml.

What should happen: the edit is refused, because the path does not match ^autoscripts/.*\.(py|js|json|md)$, and Bob reports the fence's description. Its customInstructions tell it to say which file it needed and why. You now know the change has a configuration dependency, which is exactly what a reviewer wants to hear before merge rather than after.

What to check in your pilot: that the refusal really happens on your build. If it does not, the mode file may have failed to load (see Pitfalls) and you are running with built-in Agent tools.

Scenario 2: the IBM skill disagrees with your house rules

You enable IBM's optimizer skill and point it at a script. Its report recommends wrapping a relationship set in try/finally with close(), as its resource pattern shows. Your AGENTS.md section 5 says the opposite.

What should happen: in maximo-reviewer mode with AGENTS.md loaded, Bob should flag the conflict rather than silently follow the skill. In our experience with agents generally, it often does, but not always [TMG]. Make it explicit: add a line to .bob/rules-maximo-reviewer/01-review-format.md saying "Where a skill's example conflicts with AGENTS.md, AGENTS.md wins; say which rule you applied." Then count how often the conflict is reported correctly. That count is a better measure of whether your rules work than any feeling.

Scenario 3: same repository, IDE and Shell, different Ask

A developer overrides ask in .bob/custom_modes.yaml to make Ask answer only from repository files. In the IDE it works. In a Shell session on a build server it is ignored, because Shell's documented order puts built-in modes first.

Fix: delete the override, rename it maximo-ask, and move the stricter behavior into .bob/rules-ask/ for anyone who still uses the built-in Ask.

Scenario 4: a new developer clones the repository

On day one, a new team member clones the repository, opens it in Bob IDE, and sees 🛠️ Maximo Autoscript and 🔍 Maximo Reviewer in the mode picker, the review skill in the Skills tab, /autoscript-review in the command menu, and a disabled maximo-dev-readonly server in MCP settings. Their machine policy has already locked auto-approval for edits and MCP. They did not install or configure anything. That is the end state this part is aiming for.

⚠️ Pitfalls and Troubleshooting

Symptom	Likely cause	Fix
Custom modes missing from the picker	Invalid fileRegex, a YAML indentation error, or a duplicate slug stopped the file loading	Validate the YAML, test each regex, check slugs are unique across global and project files
Mode loads but has no tools	groups omitted, or a group name misspelled (unknown names grant nothing)	Compare each group name against the IBM list; exec and edits grant nothing
Writer edits files outside autoscripts/	The fence regex is wrong, or the user is actually in Agent mode	Check the mode chip (IDE 2.3.0 shows it in the prompt box); test the regex against real paths
House rules ignored	Rules in a folder Bob does not read, useAgentRules set to false, or workspace not trusted	Move standards into AGENTS.md or .bob/rules/; check settings and workspace trust
Rules apply to the wrong persona	A persona file placed under .bob/rules/ (all modes) instead of .bob/rules-{slug}/	Move it; remember rules/ is read recursively
Skill never activates	Folder name invalid or does not match name, or a vague description	Rename to kebab-case matching name; rewrite the description to say when to use it
Two skills with one name behave oddly	Same name in ~/.bob/skills/ and .bob/skills/	Project wins by design; delete or rename the global copy
Plugin skills still visible after disabling the plugin	IDE build older than 2.3.0	Upgrade; 2.3.0 fixed plugin skill inheritance
Plugin MCP server not loading	IDE older than 2.3.0, or an HTTP+SSE server definition	Upgrade; move the server to Streamable HTTP
Optimizer skill fails on TLS or writes a key to disk	Its fetch tool uses verify=False and a .env file	Use a CA bundle; add .env to .gitignore and .bobignore; use a read-only key
AGENTS.md costs climbing	Long explanations in an always-loaded file	Move detail into .bob/rules-{slug}/ or a skill

❓ Open Items and Discrepancies

These are the points we could not settle from IBM's published material as of November 10, 2026. Each one is worth an email to your IBM contact before you standardize on a configuration.

Duplicate-slug precedence. The IDE says project beats global beats built-in; the Shell says built-in beats user beats project. One of the two pages is wrong, or the clients really behave differently.
Global mode-specific rules. "Within each level, mode-specific rules load before general rules" implies ~/.bob/rules-{slug}/, but no page shows that path.
`allowedSubagents` syntax. The field is documented; its value format is not. We used a list of subagent type names (explore, general).
Plugin manifest and layout. No manifest spec, no versioning, no documented internal layout. The marketplace template repository is empty.
Commands in plugins. IBM lists skills, modes, rules, and MCP configuration as plugin contents. Commands are not mentioned.
`RequiredExtensions` format. In the changelog and blog, absent from the group policies reference page.
Variable substitution in the IDE's `mcp.json`. ${KEY} secrets are documented for the Shell; we found no equivalent statement for the IDE.
Skill folder name versus `name`. IBM's own Maximo skill uses different values. Which one appears in logs and the Skills tab should be checked in a live build.
Group lists differ. The IDE lists workflow and subtask; the Shell lists browser and omits both. A mode file shared between clients may grant different tools in each.

🗺️ Where This Leaves You

House rules are not a prompt-engineering trick. They are how your team's review standards stop living in two senior developers' heads and start living in files that every agent, and every new hire, reads first. Bob gives you more places to put them than most agents, and the ordering is documented well enough to be predictable, if you avoid the two or three spots where IBM's pages disagree.

Your next steps

This week:

Write AGENTS.md from the template above, replacing the naming convention with yours. Keep it under two screens.
Move any long standards document into .bob/rules/, split by topic, numbered.
Add the two custom modes and test both regular expressions against real paths in your repository.

Next week:

Add maximo-autoscript-review and the two slash commands.
Read IBM's optimizer skill end to end before enabling it, fix its .env handling, and decide which of its patterns your house rules override.
Run the same three Part 5 pilot tasks with and without the configuration, and record standards findings.

Before rollout:

Package modes, rules, and skills as .bob/plugins/<your-name>/, keep AGENTS.md at the root, and test on a clean clone.
Ask IT for a policy file with DisabledAutoApprovalGroups, and ask IBM for the RequiredExtensions value format in writing.
Send IBM the open items list above.

Rules and modes shape intent. In Part 7 we add the layer that does not depend on the model agreeing with you: lifecycle hooks, enforced hooks, and the MCP guardrails that keep a Maximo API key from becoming a liability.

References

Custom rules, Bob IDE (IBM Bob docs), read November 10, 2026
Custom rules, Bob Shell (IBM Bob docs), read November 10, 2026
Configuring Bob Shell: context files (IBM Bob docs), read November 10, 2026
Custom modes, Bob IDE (IBM Bob docs), read November 10, 2026
Custom modes, Bob Shell (IBM Bob docs), read November 10, 2026
Subagents (IBM Bob docs), read November 10, 2026
Skills, Bob IDE (IBM Bob docs), read November 10, 2026
Skills, Bob Shell (IBM Bob docs), read November 10, 2026
Slash commands (IBM Bob docs), read November 10, 2026
MCP in Bob (IBM Bob docs), read November 10, 2026
Group policies (IBM Bob docs), read November 10, 2026
Bob IDE changelog, 2.2.0 and 2.3.0 (IBM Bob docs), read November 10, 2026
Run Bob on your own infrastructure, October 1, 2026 (Bob blog)
maximo-code-optimization skill, ibm-self-serve-assets/building-blocks (IBM GitHub), commits 7ad7a7d (June 12, 2026) and 8ab8576 (October 21, 2026)
ibm-mas/cli .bob folder (IBM GitHub), read November 10, 2026
Automation Scripts: Do/Don't, Performance & Code Styling (IBM Community), read November 10, 2026
Max_autoscripts (TheMaximoGuys, MIT)
Teach Your AI the House Rules (TheMaximoGuys, Enterprise Vibe Coding series)

Continue the Series

Previous: Part 5, Piloting Bob on Maximo
Next: Part 7, Hooks, MCP, and Guardrails

About TheMaximoGuys: We help Maximo developers and teams navigate the move to MAS 9 with practical, no-hype guidance grounded in how the platform actually behaves.

Published by TheMaximoGuys | November 2026

TL;DR

Key Takeaways

MAS BOB Series