A delivery accelerator for large Salesforce programmes. It installs into an SFDX project and gives Claude Code and GitHub Copilot one shared configuration: specialist agents, skills and path-scoped rules. Unsafe actions are blocked by deterministic hooks, every change passes a quality gate that tells new findings from legacy debt, and a persona-based Playwright suite checks the result. Before an agent changes code, it asks OrgIntel what the change touches.
PS C:\work\acme-crm> pnpm run booster:doctor ✓ Node.js ≥ 22.22.1 ✓ Salesforce CLI · Code Analyzer plugin ✓ Java 11+ (PMD engine) · Python 3.10+ (Flow engine) ✓ Playwright browser ✓ AI configuration in sync ✓ Legacy quality baseline ✓ CODEOWNERS ✓ OrgIntel checkout (knowledge base) ✓ uv (runs the OrgIntel MCP server) All checks passed.
The time saved is measured on client programmes while teams are still learning the tool, which is why the target sits well above it. Agents, skills and rules are added every release, so this page describes what they do rather than how many there are.
A long-lived org, a hundred developers and two assistants. Without a shared setup, every developer works with a different assistant, none of them knows the org, and the only safety net is an instruction the model may or may not follow.
A hundred people, two assistants, each with its own instruction file. The code that comes back follows a hundred conventions, and review cannot keep up.
Booster keeps one source for rules, agents and skills, and generates the files each assistant reads from it. A drift between them fails the pull request.
“Never force-push” in a prompt holds until the day it does not. Production orgs, credentials and protected branches need a guarantee.
Every rule that must hold is code: a hook that refuses the command and explains the compliant path, a permission, a git hook, a required CI check.
The first version required zero violations per file. On an org with thousands of legacy classes, every touched file failed, so people avoided necessary fixes or bypassed the hooks.
The gate now compares each finding with a baseline of the existing debt: new findings block, legacy findings never do, and the baseline only shrinks.
Booster is installed into an existing SFDX repository with a pinned version, a dry run first, and a backup of any file the project had changed. It adds configuration, tools and tests; it never changes the org by itself.
Least-privilege specialist agents (impact analyst, solution designer, builder, test engineer, code reviewer, release manager and more), each with only the tools its job needs and a named agent to hand off to.
Skills with progressive disclosure, from impact analysis to SAFe delivery, and rule sets that load only for the files they govern: Apex, tests, LWC, Aura and Visualforce, Flows, metadata and security, integrations, end-to-end tests.
One table of rules, enforced by the hooks of both assistants. It refuses force pushes, pushes to protected branches, --no-verify, writes to protected orgs, reading secrets or dumping the environment. It asks first before a deploy with no target org or a destructive data change.
Each refusal says why, and what to do instead. Every rule has a regression test.
Salesforce Code Analyzer v5 (PMD 7, ESLint, regex, Flow scanner, retire-js) runs on the files a branch changes, plus Booster's own rules for hardcoded record Ids, org URLs, endpoints and email addresses.
Findings are matched to a baseline of legacy debt by a line-insensitive fingerprint. New ones block, old ones are reported, fixed ones are locked in. A waiver is a tech-lead decision, logged in a protected file.
Playwright with passwordless personas: each one is a real test user, signed in through a single-use session, so permissions are tested as people really have them. It works with MFA and stores no password anywhere.
Test data is created and cleaned through the API, waits follow the page state, and tags (tier, domain, persona, ticket) drive smoke, critical and regression runs, sharded in CI.
The same loop runs in Claude Code and in GitHub Copilot; only the way an agent is invoked differs. Each step hands off to the next agent, guardrails run underneath all of them, and a person merges, always.
Each agent has a narrow job, the tools that job needs and nothing more, and a named agent to hand off to. The code reviewer reads the branch with no memory of how it was written, and it can only run read-only commands. Small, single-component fixes skip the loop through a quick-change skill.
requirements-analystTurns a request into a story or an enabler with Gherkin acceptance criteria, checks it against the definition of ready, and challenges custom work when a standard feature already does the job.
impact-analystAsks OrgIntel first: who uses the object, what runs on it and in which order, which contracts and which teams are involved. Returns the affected components, the tests to run and the owners. Another team's component means a dependency to raise, never a silent edit.
solution-designerStandard first, then access, feature toggles and bypasses, and an architecture decision record when the choice matters. In Claude Code the plan is reviewed in plan mode, before any code exists.
builderTest first: a characterisation test on the legacy behaviour, then the change behind a Custom Metadata toggle, then bulk, negative, permission and toggle-off tests. Each green step is committed.
/verifyLint, Jest, the quality gate and the related Apex tests on the developer's sandbox, then a read of the diff for unintended changes. It reports numbers, and a red gate lists only the findings this branch introduced.
code-reviewerAn independent review with no memory of how the code was written. Blocking findings are fixed, then the pull request is opened from a template that asks for the impact, the evidence, the rollout and a human-understanding checklist.
release-managerComputes the delta, validates it and writes the release notes. After the deploy, the smoke suite runs; releases add the critical and regression tiers. Fixed legacy findings are pruned from the baseline in the same pull request.
Agents and rules are edited in ai/, never in the generated folders. The sync writes both assistants' files, and the CI check refuses a pull request where they disagree, so Claude Code and Copilot cannot slowly become two different tools.
Instructions explain; code enforces. Anything that touches money, identity, compliance or a production org has a deterministic control, and the instruction that goes with it only explains the reason.
The rules live in one table. Claude Code and GitHub Copilot both load it through their own hooks, so a rule added once applies to both. When a hook cannot run, it fails closed, and the doctor command says why.
These are refused outright, with the reason and the compliant path in the refusal itself.
--no-verify..env, the CLI auth store or a key file; print tokens or the environment.Legitimate, sometimes necessary, and expensive when wrong. The hook stops and asks.
--target-org, which would go to whatever the default org is.ai/.A working miniature built on fixtures: an ACME story about invoices, not a client. Pick a scenario on the left, open the quality gate and change a line, or open the agent catalogue. Click anything. It also runs itself while you read.
InvoiceTrigger → InvoiceTriggerHandler → InvoiceService.submit, then the record-triggered flow Invoice_Submit.invoiceApproval, permission set Invoice_Approver, the ERP sync over the named credential ERP_Invoice.ERP_Invoice_Sync belongs to another team: raise the dependency at the ART sync, do not edit it.InvoiceServiceTest, InvoiceTriggerHandlerTest, Playwright @invoice @critical.| status | sev | rule | where | effect |
|---|---|---|---|---|
| NEW | 2 | OperationWithLimitsInLoop | InvoiceService.cls:88 | blocks |
| NEW | 4 | FieldNamingConventions | InvoiceService.cls:12 | advisory |
| EXISTING | 2 | AvoidHardcodingId | LegacyPricingService.cls:42 | never blocks |
| EXISTING | 3 | ApexSharingViolations | LegacyPricingService.cls:17 | never blocks |
| FIXED | 3 | ApexUnitTestClassShouldHaveAsserts | InvoiceServiceTest.cls | prune to lock in |
Each finding is fingerprinted by rule, file, normalised line and occurrence, so inserting lines above a legacy finding does not make it new. Changing the offending line does: touch it, own it. New findings at severity 3 or higher block; the rest are listed.
Blast radius of a change, OrgIntel first.
New code is clean, touched code is not worse, and the baseline only goes down. That is what lets a programme adopt a strict gate on day one without fixing ten years of history first, while the hotspot report (churn × debt) tells the teams where enabler work pays most.
They are written in the project's AGENTS.md for every assistant to read, and each one has a hook, a check or a template behind it.
Impact analysis goes through OrgIntel before any code search. On a large org, crawling files for dependents is slow, costly and incomplete.
A rule that must hold is a hook, a permission or a CI check. The instruction only explains it.
New code is clean, touched code is not worse, the legacy baseline only shrinks, and every waiver is logged.
The verify step reports numbers. A pull request carries its gate result and its test evidence, not a statement that it works.
The author must be able to explain every line an assistant wrote. The pull request template asks, and branch protection waits for a person.
Agents cannot read key files or the CLI auth store, print tokens or dump the environment. Tests read credentials from environment variables.
The documentation starts from the reader's role. Business analysts and product owners get story refinement and impact analysis; the roles below get a dedicated guide.
An adoption plan in batches with champions, AI governance, architecture decision records, and a debt trend measured every programme increment.
A daily workflow from branch to merge, prompts that work, and a /project-help skill that reads the branch and says what to do next.
The gate policy, waivers, the legacy-code strategy and the hotspot report that points enabler capacity at the debt that hurts.
Persona onboarding, page objects for Lightning, LWC and Visualforce, specs that run unchanged against a translated org, and execution evidence.
What follows is the state of the tool as it stands. It runs on client programmes, with a pinned version per project, and it updates with one command.
Configuration, tools and tests next to the Salesforce source. Nothing is deployed to the org by the installer.
Every check a developer needs is one pnpm run away, and the same commands run in CI.
Two output modes are on by default: terse prose, and lean code that reuses before it writes. On a small benchmark (48 answers, 6 Salesforce tasks, one model), both together cut prose by 60 % and the code from 133 to 65 lines, with every hidden test still passing.
A direction, not a guarantee: small single-function tasks, and the limits are written down next to the numbers.
Some programmes have to work against a production org. The production override covers that case end to end: a person unlocks one alias in their own terminal, with a reason, a ticket and an expiry.
Shell commands and the Playwright suite both respect it, CI always refuses, and the test report states that the run is not sandbox evidence.
booster update installs the new version, then runs the doctor, verify, the tool tests, the Playwright typecheck and the OrgIntel check, and prints one summary.
A file the project had changed is never replaced silently: it is named, and its previous content is kept. Files the new version no longer ships are removed the same way.
Version 2.0 applies one set of guardrails to everyone. The work in progress lets each programme choose how strict it wants to be, and see the cost of that choice before making it.
One configuration for Claude Code and GitHub Copilot; specialist agents, skills and path-scoped rules; guardrails enforced on both clients; the baseline quality gate on Code Analyzer v5; passwordless persona testing; pinned CI workflows; the OrgIntel wiring; and the production override, extended to the Playwright suite.
A policy file with light, standard and strict profiles; install profiles from AI configuration only to the full set, each with the risk it leaves open; and a configuration cockpit with a guardrail matrix, a simulator and the agent and skill inventory.
A local Code Analyzer pass required before a pull request is opened. Ingestion of the client's documentation (office files, PDF, Confluence and Jira). Skill evaluations run across several model sizes, then model and effort set per agent from the results.
When OrgIntel ships pull-request impact analysis, the CI pipeline calls it next to the quality gate, so every pull request carries the list of components it touches.
Salesforce Booster started as my own initiative. Capgemini now offers it to its clients as a Capgemini asset, and about 100 consultants use it. It is not a product you can download, and it is not sold as one. If it is relevant to a programme you are responsible for, the conversation starts on LinkedIn.