agentsclimarketplace
Sign in

Sf test scenario generator

Skill SahirVhora/sf-agent-skills/skills/sf-test-scenario-generator

Use when you need to generate UAT test scenarios from live SF business rules and workflow config -- covering happy path, edge cases, and cross-process interactions.From its SKILL.md

Install
npx -y skills add SahirVhora/sf-agent-skills --skill sf-test-scenario-generator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.6 KB, 716 tokens by cl100k_base, as published. Nobody here has run it

SF Test Scenario Generator

Generate realistic, coverage-complete test scenarios from your actual business rules, not generic templates.

When to Use

  • Preparing for UAT before a release
  • Building a regression test suite
  • Onboarding new testers who don't know the configuration
  • Proving to auditors that all business rules have test coverage
  • After a business rule change -- regenerate affected scenarios

Prerequisites

  • Business rule configuration export
  • Workflow/approval process definitions
  • Knowledge of which rules changed (for targeted regeneration)

Workflow

Step 1: Parse Configuration

Extract from business rules:

  • Trigger conditions (when does the rule fire?)
  • Field reads (what data does it check?)
  • Field writes (what data does it set?)
  • Error/raise conditions (what should it block?)

Step 2: Generate Scenarios

For each rule, generate:

  • Happy path: all conditions met, rule fires successfully
  • Edge case -- null input: what if the checked field is empty?
  • Edge case -- boundary: what if the value is at the max/min?
  • Error condition: what if the rule should block the save?
  • Cross-rule interaction: what if Rule A and Rule B fire together?

Step 3: Build Test Cases

Each test case includes:

  • Pre-conditions (data setup needed)
  • Test steps (exactly what to do in the UI)
  • Expected result (what the system should do)
  • Test data (which employee, which values)
  • Rules validated (traceability to specific business rules)

Step 4: Produce Traceability Matrix

Map every business rule to at least one test case. For audit sign-off, show:

  • Rule ID → Test Case ID
  • Coverage status (covered / partial / uncovered)
  • Last run date

Edge Cases

  • Effective-dated rules: generate scenarios across effective date boundaries
  • Compound rules (A AND B AND C): test all false combinations, not just all true
  • Workflows with external approvers: test what happens when the external system is down
  • Propagation cascades: test rules that trigger other rules through 3+ levels
  • Dynamic role resolution: test with different role assignments (manager, HRBP, etc.)
  • Off-cycle events: mid-period changes, retroactive updates, future-dated changes

Common Pitfalls

  1. Only testing the happy path: 80% of production issues come from edge cases. Generate at least one edge case per rule.
  2. No cross-rule scenarios: Rules don't execute in isolation. Test the combinations that happen in real workflows.
  3. Missing test data setup: A scenario that says "change department to Sales" but no employee is in a non-Sales department to start with is useless.
  4. Not covering error conditions: If a rule is supposed to block invalid data, test that it actually blocks it.
  5. Forgetting propagation rules: A Person rule that sets a field used by a Position rule -- test the full chain, not each rule alone.

Verification Checklist

  • Every business rule has at least one test scenario
  • Happy path and edge case coverage >90%
  • Cross-rule interaction scenarios included
  • Test data requirements documented per scenario
  • Traceability matrix produced
  • Error/block conditions tested
  • Propagation chains tested end-to-end

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most test skills give in 716 tokens

Counted across 964 of the 1,571 authors here whose files we hold, read 2026-08-07

  • Close the browser when donein 55 of 964, across 12 files
  • Wait for network idle statein 51 of 964, across 6 files
  • Launch Chromium in headless modein 49 of 964, across 6 files
  • Use descriptive selectors for elementsin 49 of 964, across 6 files
  • Run provided scripts with help flag firstin 49 of 964, across 6 files
  • Add appropriate explicit waitsin 48 of 964, across 5 files
  • Use bundled scripts as black boxesin 46 of 964, across 3 files
  • Do not read script source codein 46 of 964, across 3 files
  • Use sync playwright for scriptsin 46 of 964, across 3 files
  • Inspect dom before executing actionsin 46 of 964, across 3 files
  • Run the full test suitein 37 of 964
  • Write the failing test firstin 29 of 964, across 23 files

Said here and by no other author read

  • generate scenarios from actual business rules
  • extract trigger conditions from business rules
  • extract field reads from business rules
  • generate an edge case scenario for each rule
  • include test steps in each test case
  • map every business rule to a test case

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,736. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.