business-rule-e2e

Files (6)

• SKILL.md
• openai.yaml · agents/
• detox.md · references/
• playwright.md · references/
• refresh.md · references/
• test-model.md · references/

SKILL.md (first lines)

# Business Rule E2E

Build confidence from business intent outward. Treat UI actions, API effects, persisted state, authorization, and user-visible outcomes as one flow.

## Start

1. Read repository instructions completely.
2. Inspect package manifests, E2E configuration, existing tests, app routes/screens, API clients/routes, fixtures, and `docs/` business rules.
3. Read [references/test-model.md](references/test-model.md).
4. Select platform:
   - Web: read [references/playwright.md](references/playwright.md).
   - React Native: read [references/detox.md](references/detox.md).
   - Mixed project: read both; keep suites separate and share rule IDs.
5. Determine request scope: one rule, module, persona, or refresh.
6. If business intent is missing or contradictory, stop and ask the product decision needed. Never encode guessed business policy.

## Establish traceability

Before broad changes, report concisely:

- Problem/request
- Proposed test layers and flow
- Affected files
- Fixtures/data/environment needed
- Tradeoffs or team decision needed

Assign stable IDs such as `BR-BILLING-001`. Connect each rule to:

```text
Business rule -> atomic tests -> module scenarios -> persona flows -> evidence
```

Prefer existing project identifiers. Otherwise create a documented convention. Maintain business logic under `docs/`; default to `docs/testing/e2e/` when no project convention exists.

## Scope modes

### One business rule

Test the rule's complete observable lifecycle, not only its happy-path screen:

1. Arrange valid role, preconditions, and data through API/fixture when possible.
2. Trigger the rule through the user-facing UI.
3. Observe the relevant request/response when useful.
4. Assert visible outcome.
5. Verify durable state through API, DB-safe helper, or a second UI view.
6. Cover denial, boundary, and state-transition cases relevant to that rule.

### One module

Inventory module rules and states. Implement atomic coverage first, then molecular scenarios spanning related rules. Include role permissions, validation, lifecycle transitions, error recovery, and module boundary integrations.

### One user type

Map the persona from entry to terminal outcome: authentication, navigation, permitted actions, forbidden actions, cross-module handoffs, persistence, logout/session expiry where relevant. Use a few high-value journeys; do not duplicate every atomic case.

### Refresh

Read [references/refresh.md](references/refresh.md), then reconcile business docs, code, tests, and coverage. Refresh means update stale coverage and evidence, not blindly rewrite passing tests.

## Implement safely

- Reuse existing framework/configuration before adding dependencies.
- Ask before decisions affecting architecture, APIs, data models, UI flows, CI/deployment, QA ownership, or another teammate.
- Prefer accessibility locators and stable `testID`s; avoid CSS/layout coupling.
- Use API setup for speed; exercise UI for behavior under test.
- Keep tests isolated, deterministic, parallel-safe, and independently runnable.
- Never use production data or production mutation paths.
- Never log secrets, tokens, passwords, or PII.
- Add dev-only structured diagnostics when implementation adds or changes application behavior; follow repository logging rules.
- Do not weaken assertions, add arbitrary sleeps, or disable synchronization to make a test pass.
- Preserve user changes and avoid broad refactors.

## Verify

Run smallest scope first, then relevant module/flow suite. Use one worker initially while diagnosing. Capture:

- Command and environment
- Passed/failed/skipped counts
- Duration
- Trace/screenshots/video/logs on failure
- Rule IDs covered
- Remaining gaps and risk

Classify failures as product defect, test defect, environment defect, or unclear rule. Fix only within requested authority.

## Finish

Report what changed, why, verification evidence, risk, and team confirmation still needed. Update the coverage artifact and business-rule docs. Keep handoff concise and QA-friendly with exact reproduction commands.

From deepaktiwari09/team-agent-skills, MIT.

More from deepaktiwari09/team-agent-skills