home / skills / hoangnguyen0403 / agent-skills-standard / business-analysis

This skill conducts deep business analysis by enforcing atomic decomposition, actor mapping, edge-case discovery, and anti-pattern checks for accurate impact.

npx playbooks add skill hoangnguyen0403/agent-skills-standard --skill business-analysis

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
1.6 KB
---
name: Business Analysis
description: Standard for deep requirement investigation, logic validation, and technical impact mapping.
metadata:
  labels: [ba, requirement-analysis, logic-validation, technical-impact]
  triggers:
    files: ['**/user_story.md', '**/requirements.md', '**/jira_*.xml']
    keywords:
      [
        analyze requirements,
        scenario decomposition,
        logic conflict,
        technical impact,
      ]
---

# Business Analysis Standards (Deep Analysis)

## **Priority: P0 (CRITICAL)**

## 1. Deep Investigation Protocol

- **Atomic Decomposition**: Split AC into 1-Condition logic units.
- **Variable Identification**: Extract all Toggles, Market Rules, and User Roles.
- **Platform Parity Audit**: Verify if logic applies to both Web and Mobile; Flag divergent behavior.
- **Truth Table Verification**: Map complex logic to a [Logic Truth Table](references/logic_truth_tables.md).

## 2. Dynamic Actor Mapping

- Identify all Actors (Customer, Sales Rep, Admin).
- Map specific permissions and constraints per Actor.
- [Permissions Patterns](references/analysis_patterns.md)

## 3. Edge Case Discovery

- **State Validation**: Verify behavior across all entity and network states.
- **Boundary Detection**: Analyze currency, date, and count limits.
- **Audit**: Check for null-safety and unauthorized access paths.

## 4. Anti-Patterns

- **No Surface Reading**: investigate the _implications_, don't just restate.
- **No Assumption**: Flag undefined states (e.g., Offline) as P0 blockers.
- **No Loose Mapping**: Ensure AC aligns 100% with Technical Impact notes.

Overview

This skill defines a practical standard for deep requirement investigation, logic validation, and technical impact mapping for engineering teams. It guides agents to decompose acceptance criteria, map actors and permissions, and surface edge cases that could break production. The focus is on concrete checks that prevent ambiguous or unsafe implementations.

How this skill works

The skill inspects acceptance criteria and feature descriptions to extract atomic logic units, toggles, roles, and platform differences. It creates truth tables for complex conditional logic, enumerates actors with permission matrices, and runs a checklist of state, boundary, and null-safety validations. Outputs include flagged P0 issues, divergence reports between web and mobile, and precise notes tying AC to technical impacts.

When to use it

  • Scoping new features or user stories before design or implementation
  • Reviewing acceptance criteria for ambiguous or missing states
  • Validating cross-platform parity between web and mobile behaviors
  • Prioritizing test cases and QA focus based on risk and edge cases
  • Auditing permissions and role-based access for compliance

Best practices

  • Decompose each acceptance criterion into single-condition logic units before mapping to tests
  • Always list toggles, market rules, and user roles explicitly and link them to behavior
  • Build truth tables for multi-condition logic to prevent misinterpretation
  • Flag any undefined states (offline, missing data, rate limits) as blockers until resolved
  • Verify platform parity and call out required platform-specific implementations
  • Document technical impacts alongside AC to ensure 1:1 alignment with implementation notes

Example use cases

  • A payments flow needing currency, rounding, and boundary checks across countries
  • A multi-role admin panel where actions differ by Sales Rep, Admin, and Customer
  • Feature toggles that change behavior and require audits for both enabled and disabled states
  • A mobile/web feature where offline and sync behavior must be validated separately
  • Designing tests from acceptance criteria using truth tables to derive deterministic scenarios

FAQ

What is the highest priority issue to surface?

Undefined or missing states (e.g., Offline, null inputs, permission gaps) are P0 and must be resolved before implementation.

How granular should decomposition be?

Split acceptance criteria until each unit expresses a single conditional outcome that can be validated with a test or truth table.