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 skills/salesforcecommercecloud/b2c-developer-tooling/testingnpx skills add SalesforceCommerceCloud/b2c-developer-tooling --skill testinggit clone --depth 1 https://github.com/SalesforceCommerceCloud/b2c-developer-toolingWhat 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.00077 | $0.02684 |
| Opus 5 | $0.00039 | $0.01342 |
| Sonnet 5 | $0.00015 | $0.00537 |
| Haiku 4.5 | $0.00008 | $0.00268 |
Grade A, and why
testing scanned grade A with 1 finding 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 2d ago.
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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
async fetch(url: string, init?: RequestInit): Promise<Response> { How it starts
The opening of the file, as written. The whole thing — 378 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing
This skill covers project-specific testing patterns for the B2C CLI project.
Test Framework Stack
- Test Runner: Mocha
- Assertions: Chai (property-based)
- HTTP Mocking: MSW (Mock Service Worker)
- Stubbing/Mocking: Sinon
- Code Coverage: c8
- TypeScript: tsx (native execution without compilation)
Running Tests
For coding agents (minimal output - only failures shown):
# Run tests - only failures + summary
pnpm run test:agent
# Run tests for specific package
pnpm --filter @salesforce/b2c-tooling-sdk run test:agent
pnpm --filter @salesforce/b2c-cli run test:agent
For debugging (full output with coverage):
# Run all tests with coverage
pnpm run test
# Run tests for specific package
pnpm --filter @salesforce/b2c-tooling-sdk run test
pnpm --filter @salesforce/b2c-cli run test
# Run single test file (no coverage, faster)
cd packages/b2c-tooling-sdk
pnpm mocha "test/clients/webdav.test.ts"
# Run tests matching pattern
pnpm mocha --grep "mkcol" "test/**/*.test.ts"
# Watch mode for TDD
pnpm --filter @salesforce/b2c-tooling-sdk run test:watch
Test Organization
Tests mirror the source directory structure with .test.ts suffix:
packages/b2c-tooling-sdk/
├── src/
│ └── clients/
│ └── webdav.ts
└── test/
└── clients/
└── webdav.test.ts
Import Patterns
Always use package exports, not relative paths:
// Good - uses package exports
import { WebDavClient } from '@salesforce/b2c-tooling-sdk/clients';
import { OAuthStrategy } from '@salesforce/b2c-tooling-sdk/auth';
// Avoid - relative paths
import { WebDavClient } from '../../src/clients/webdav.js';
This ensures tests use the same export paths as consumers.
Config Isolation
Tests that check for "missing credentials" or "no config" scenarios need isolation from the developer's real configuration files (~/.mobify, dw.json) and environment variables.
Using Config Isolation Helpers
import { isolateConfig, restoreConfig } from '../helpers/config-isolation.js';
describe('config-dependent tests', () => {
beforeEach(() => {
isolateConfig();
});
afterEach(() => {
restoreConfig();
});
it('handles missing credentials', async () => {
// Test now runs without reading real ~/.mobify or SFCC_* env vars
});
});
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 2d ago First seen · 378 lines · 77 tokens per session scan A a9f0987f4537
testing is a skill published in the GitHub repository SalesforceCommerceCloud/b2c-developer-tooling (53 stars, last pushed 3d ago), licensed Apache-2.0. It adds 77 tokens to every session and 2,684 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
ios-simulator-skill
29 production-ready scripts for iOS app testing, building, and automation. Provides semantic UI navigation, build automation, accessibility testing, and simulator lifecycle management. Optimized for AI agents with minimal token output.
mall4j
Mall4j 开源版现有功能副驾驶:本地启动、mall4v/mall4m/mall4uni、商品/SKU、购物车、下单支付、订单发货、会员、运费、权限、部署排查。适用于下载 mall4j / yami-shop 后按现有功能使用或二次开发;不要编造开源版没有的能力。.
Troubleshooting Guide Builder
Builds a structured troubleshooting guide with symptom → cause → fix format for any tool or system.
Documentation Gap Finder
Audits a codebase or docs folder and lists everything that is undocumented, outdated, or unclear.
agent-tail
Capture browser console logs and dev server output to files with agent-tail. Use when debugging runtime errors, checking console output, tailing or diagnosing logs, or setting up Vite/Next.js log capture.
developer-experience
Developer Experience (DX) Audit: Assesses and improves developer productivity and satisfaction — build times, CI/CD speed, onboarding friction, tooling quality, documentation, and internal developer portal. Covers developer surveys, golden paths, platform engineering, and DX metrics. Use when the user mentions…