메뉴
Converts trusted business logic into product-owner-grade acceptance criteria and developer-ready tasks using Given/When/Then scenarios. Use when creating user stories, preparing for sprints, or turning BL into executable requirements.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Identifies missing, vague, underspecified, or contradictory business logic within BL documents. Finds incomplete edge cases, missing state transitions, ambiguous terminology, and weak billing rules. Use when reviewing business logic quality, hardening requirements, or preparing BL for implementation.
Generates scenario tests, rule tests, edge case tests, state transition tests, and billing tests from trusted business logic. Use when creating test suites from BL, ensuring BL coverage, or turning requirements into verifiable tests.
Rewrites vague business logic into deterministic, testable rules by separating policy from mechanism, normalizing terminology, and defining explicit state machines. Use when preparing BL for code implementation, making BL executable, or normalizing ambiguous requirements.
Reverse engineers business logic from source code by extracting operational business truth. Use when user asks to understand what the system actually does, analyze business rules, extract domain logic, infer workflows from code, explain state transitions, or identify decision logic. Works with API views (Django, FastAPI, etc.), domain models, background tasks, and multi-step workflows.
Tailors the universal BDD skills in this directory to a specific project. Use when adopting BDD skills in a new repo, defining where BL docs live, which terminology to use, and how to find entry points (views, models, tasks). Creates or updates project BDD config so other skills (reverse-engineering, validate, derive-acceptance-criteria, etc.) work correctly.
Verifies whether documented business logic is actually implemented by mapping BL rules to code evidence. Flags rules as implemented, partially implemented, contradicted, or not found. Use when validating business logic documents, checking code coverage against requirements, or verifying BL-to-code alignment.
| name | deriving-acceptance-criteria-from-business-logic |
| description | Converts trusted business logic into product-owner-grade acceptance criteria and developer-ready tasks using Given/When/Then scenarios. Use when creating user stories, preparing for sprints, or turning BL into executable requirements. |
Project-agnostic. Use BDD/project_config.yaml → terminology for domain terms in scenarios when present (see tailor-bdd-skills-for-project).
Transform trusted business logic into clear, testable acceptance criteria that can guide development and verify implementation. This is how BL starts leading software development.
refining-business-logic-for-implementation first)Read the refined BL and identify:
cat path/to/refined_bl_document.md
Extract:
For each capability, frame it as a user story:
Format:
As a <actor>,
I want to <capability>,
So that <business_value>.
Examples:
As a [user role],
I want to [perform core action],
So that [business value].
As an administrator,
I want to monitor [account/balance] state,
So that I can ensure service continuity.
For each user story, create specific scenarios using the Gherkin format:
Scenario: <Descriptive title>
Given <initial context>
When <action occurs>
Then <expected outcome>
And <additional outcomes>
Scenario Categories:
For each user story, list concrete acceptance criteria:
Acceptance Criteria:
1. [Specific, testable requirement]
2. [Specific, testable requirement]
...
Good acceptance criteria are:
Add technical checklist items for developers:
Implementation Checklist:
- [ ] Database migration if needed
- [ ] API endpoint changes
- [ ] Background task modifications
- [ ] Validation logic
- [ ] Error handling
- [ ] Logging requirements
- [ ] Test coverage
Add relevant non-functional requirements:
Non-Functional Requirements:
- Performance: <specific metrics>
- Security: <specific requirements>
- Reliability: <specific guarantees>
- Scalability: <specific constraints>
Specify what "done" means for this story:
Done Means:
- Code reviewed and approved
- Unit tests written and passing
- Integration tests passing
- API documentation updated
- Business logic document updated
- No critical bugs outstanding
Structure the document:
# Acceptance Criteria: [Feature Name]
## User Stories
[List of user stories]
## Scenarios
[Given/When/Then scenarios for each story]
## Acceptance Criteria
[Testable requirements for each story]
## Implementation Checklist
[Developer checklist]
## Non-Functional Requirements
[Performance, security, etc.]
## Done Criteria
[Definition of done]
Given/When/Then Guidelines:
Acceptance Criteria Guidelines:
Implementation Checklist Guidelines:
❌ Vague scenarios:
Scenario: Query is processed
Given a valid request
When the request is processed
Then it should work
✅ Specific scenarios:
Scenario: Request submitted with sufficient balance
Given an account with 100 [balance units]
And the operation cost is 10 [units]
When the user submits the [operation]
Then the request is created with status "SUBMITTED"
And the account balance is 90 [units]
❌ Implementation details in scenarios:
Scenario: Database transaction works
Given the database is available
When the transaction starts
Then the lock is acquired
✅ Business-focused scenarios:
Scenario: Concurrent operations handled correctly
Given an account with exactly 10 [balance units]
When two users submit 10-unit operations simultaneously
Then only one operation succeeds
And the other is rejected with insufficient balance error
User request:
Create acceptance criteria for [request/operation] submission
You would:
User Story: As a [role], I want to [action], So that [value].
Scenarios: Write Given/When/Then for:
Acceptance Criteria: List testable conditions for: when the operation is accepted, when and how balance is deducted, when it is rejected and with which codes, and what the response includes.
Implementation Checklist: Validation, balance check, deduction (with concurrency safety if needed), ledger/audit, error codes, tests for concurrency. Use project terminology from config.
User request:
Create acceptance criteria for [async job] status polling
You would:
User Story: As a [role], I want to check [job/file] status so that I know when the result is ready.
Scenarios: Given/When/Then for: initial poll returns PROCESSING (with submission_time, estimated_completion); poll returns COMPLETED (with download/result URL and metadata); timeout leads to STALLED and user can request continue polling.
Acceptance Criteria: What the status API returns (status enum, timestamps, for COMPLETED: result URL/metadata, for STALLED: continue option); polling interval and max duration; STALLED and CONTINUE rules (reset counter, max CONTINUEs).
Non-Functional Requirements: Performance (e.g. API response time), reliability (retries), monitoring if applicable.
# Acceptance Criteria: [Feature Name]
## User Story
As a <actor>,
I want to <capability>,
So that <business_value>.
## Scenarios
### Happy Path
Scenario: [Descriptive title]
Given [context]
When [action]
Then [outcome]
### Sad Path
Scenario: [Descriptive title]
Given [context]
When [action]
Then [outcome]
### Edge Cases
Scenario: [Descriptive title]
Given [context]
When [action]
Then [outcome]
## Acceptance Criteria
1. [Requirement 1]
- [Sub-requirement or detail]
- [Sub-requirement or detail]
2. [Requirement 2]
- [Sub-requirement or detail]
## Implementation Checklist
- [ ] [Task 1]
- [ ] [Task 2]
- [ ] [Task 3]
## Non-Functional Requirements
- **Performance**: [Specific requirement]
- **Security**: [Specific requirement]
- **Reliability**: [Specific requirement]
## Done Means
- [ ] [Criteria 1]
- [ ] [Criteria 2]
- [ ] [Criteria 3]
The skill generates: