aigroup-workflow 2.2.1 → 2.2.3

package/skills/backend/feature-forge/SKILL.md

@@ -1,98 +1,98 @@
----
-name: feature-forge
-description: Conducts structured requirements workshops to produce feature specifications, user stories, EARS-format functional requirements, acceptance criteria, and implementation checklists. Use when defining new features, gathering requirements, or writing specifications. Invoke for feature definition, requirements gathering, user stories, EARS format specs, PRDs, acceptance criteria, or requirement matrices.
-license: MIT
-metadata:
-  author: https://github.com/Jeffallan
-  version: "1.1.0"
-  domain: workflow
-  triggers: requirements, specification, feature definition, user stories, EARS, planning
-  role: specialist
-  scope: design
-  output-format: document
-  related-skills: fullstack-guardian, spec-miner, test-master
----
-
-# Feature Forge
-
-Requirements specialist conducting structured workshops to define comprehensive feature specifications.
-
-## Role Definition
-
-Operate with two perspectives:
-- **PM Hat**: Focused on user value, business goals, success metrics
-- **Dev Hat**: Focused on technical feasibility, security, performance, edge cases
-
-## When to Use This Skill
-
-- Defining new features from scratch
-- Gathering comprehensive requirements
-- Writing specifications in EARS format
-- Creating acceptance criteria
-- Planning implementation TODO lists
-
-## Core Workflow
-
-1. **Discover** - Use `AskUserQuestions` to understand the feature goal, target users, and user value. Present structured choices where possible (e.g., user types, priority level).
-2. **Interview** - Systematic questioning from both PM and Dev perspectives using `AskUserQuestions` for structured choices and open-ended follow-ups. Use multi-agent discovery with Task subagents when the feature spans multiple domains (see interview-questions.md for guidance).
-3. **Document** - Write EARS-format requirements
-4. **Validate** - Use `AskUserQuestions` to review acceptance criteria with stakeholder, presenting key trade-offs as structured choices
-5. **Plan** - Create implementation checklist
-
-## Reference Guide
-
-Load detailed guidance based on context:
-
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| EARS Syntax | `references/ears-syntax.md` | Writing functional requirements |
-| Interview Questions | `references/interview-questions.md` | Gathering requirements |
-| Specification Template | `references/specification-template.md` | Writing final spec document |
-| Acceptance Criteria | `references/acceptance-criteria.md` | Given/When/Then format |
-| Pre-Discovery Subagents | `references/pre-discovery-subagents.md` | Multi-domain features needing front-loaded context |
-
-## Constraints
-
-### MUST DO
-- Use `AskUserQuestions` tool for structured elicitation (priority, scope, format choices)
-- Use open-ended questions only when choices cannot be predetermined
-- Conduct thorough interview before writing spec
-- Use EARS format for all functional requirements
-- Include non-functional requirements (performance, security)
-- Provide testable acceptance criteria
-- Include implementation TODO checklist
-- Ask for clarification on ambiguous requirements
-
-### MUST NOT DO
-- Output interview questions as plain text when `AskUserQuestions` can provide structured options
-- Generate spec without conducting interview
-- Accept vague requirements ("make it fast")
-- Skip security considerations
-- Forget error handling requirements
-- Write untestable acceptance criteria
-
-## Output Templates
-
-The final specification must include:
-1. Overview and user value
-2. Functional requirements (EARS format)
-3. Non-functional requirements
-4. Acceptance criteria (Given/When/Then)
-5. Error handling table
-6. Implementation TODO checklist
-
-**Inline EARS format examples** (load `references/ears-syntax.md` for full syntax):
-```
-When <trigger>, the <system> shall <response>.
-Where <feature> is active, the <system> shall <behaviour>.
-The <system> shall <action> within <measure>.
-```
-
-**Inline acceptance criteria example** (load `references/acceptance-criteria.md` for full format):
-```
-Given a registered user is on the login page,
-When they submit valid credentials,
-Then they are redirected to the dashboard within 2 seconds.
-```
-
-Save as: `specs/{feature_name}.spec.md`
+---
+name: feature-forge
+description: Conducts structured requirements workshops to produce feature specifications, user stories, EARS-format functional requirements, acceptance criteria, and implementation checklists. Use when defining new features, gathering requirements, or writing specifications. Invoke for feature definition, requirements gathering, user stories, EARS format specs, PRDs, acceptance criteria, or requirement matrices.
+license: MIT
+metadata:
+  author: https://github.com/Jeffallan
+  version: "1.1.0"
+  domain: workflow
+  triggers: requirements, specification, feature definition, user stories, EARS, planning
+  role: specialist
+  scope: design
+  output-format: document
+  related-skills: fullstack-guardian, spec-miner, test-master
+---
+
+# Feature Forge
+
+Requirements specialist conducting structured workshops to define comprehensive feature specifications.
+
+## Role Definition
+
+Operate with two perspectives:
+- **PM Hat**: Focused on user value, business goals, success metrics
+- **Dev Hat**: Focused on technical feasibility, security, performance, edge cases
+
+## When to Use This Skill
+
+- Defining new features from scratch
+- Gathering comprehensive requirements
+- Writing specifications in EARS format
+- Creating acceptance criteria
+- Planning implementation TODO lists
+
+## Core Workflow
+
+1. **Discover** - Use `AskUserQuestions` to understand the feature goal, target users, and user value. Present structured choices where possible (e.g., user types, priority level).
+2. **Interview** - Systematic questioning from both PM and Dev perspectives using `AskUserQuestions` for structured choices and open-ended follow-ups. Use multi-agent discovery with Task subagents when the feature spans multiple domains (see interview-questions.md for guidance).
+3. **Document** - Write EARS-format requirements
+4. **Validate** - Use `AskUserQuestions` to review acceptance criteria with stakeholder, presenting key trade-offs as structured choices
+5. **Plan** - Create implementation checklist
+
+## Reference Guide
+
+Load detailed guidance based on context:
+
+| Topic | Reference | Load When |
+|-------|-----------|-----------|
+| EARS Syntax | `references/ears-syntax.md` | Writing functional requirements |
+| Interview Questions | `references/interview-questions.md` | Gathering requirements |
+| Specification Template | `references/specification-template.md` | Writing final spec document |
+| Acceptance Criteria | `references/acceptance-criteria.md` | Given/When/Then format |
+| Pre-Discovery Subagents | `references/pre-discovery-subagents.md` | Multi-domain features needing front-loaded context |
+
+## Constraints
+
+### MUST DO
+- Use `AskUserQuestions` tool for structured elicitation (priority, scope, format choices)
+- Use open-ended questions only when choices cannot be predetermined
+- Conduct thorough interview before writing spec
+- Use EARS format for all functional requirements
+- Include non-functional requirements (performance, security)
+- Provide testable acceptance criteria
+- Include implementation TODO checklist
+- Ask for clarification on ambiguous requirements
+
+### MUST NOT DO
+- Output interview questions as plain text when `AskUserQuestions` can provide structured options
+- Generate spec without conducting interview
+- Accept vague requirements ("make it fast")
+- Skip security considerations
+- Forget error handling requirements
+- Write untestable acceptance criteria
+
+## Output Templates
+
+The final specification must include:
+1. Overview and user value
+2. Functional requirements (EARS format)
+3. Non-functional requirements
+4. Acceptance criteria (Given/When/Then)
+5. Error handling table
+6. Implementation TODO checklist
+
+**Inline EARS format examples** (load `references/ears-syntax.md` for full syntax):
+```
+When <trigger>, the <system> shall <response>.
+Where <feature> is active, the <system> shall <behaviour>.
+The <system> shall <action> within <measure>.
+```
+
+**Inline acceptance criteria example** (load `references/acceptance-criteria.md` for full format):
+```
+Given a registered user is on the login page,
+When they submit valid credentials,
+Then they are redirected to the dashboard within 2 seconds.
+```
+
+Save as: `specs/{feature_name}.spec.md`

package/skills/backend/feature-forge/references/acceptance-criteria.md

@@ -1,104 +1,104 @@
-# Acceptance Criteria
-
-## Given-When-Then Format
-
-```markdown
-### AC-001: [Scenario Name]
-Given [context/precondition]
-When [action taken]
-Then [expected result]
-```
-
-## Examples by Type
-
-### Happy Path
-
-```markdown
-### AC-001: Successful Login
-Given a registered user with valid credentials
-When they submit the login form
-Then they are redirected to the dashboard
-And a success message is displayed
-And their session is created
-
-### AC-002: Add Item to Cart
-Given a logged-in user viewing a product
-When they click "Add to Cart"
-Then the item appears in their cart
-And the cart badge updates with the count
-And a confirmation toast is shown
-```
-
-### Error Cases
-
-```markdown
-### AC-003: Invalid Login
-Given a user with incorrect password
-When they submit the login form
-Then an error message "Invalid credentials" is displayed
-And the password field is cleared
-And they remain on the login page
-
-### AC-004: Duplicate Email Registration
-Given an email already exists in the system
-When a new user tries to register with that email
-Then an error message "Email already registered" is displayed
-And the form is not submitted
-```
-
-### Edge Cases
-
-```markdown
-### AC-005: Empty Cart Checkout
-Given a user with an empty cart
-When they navigate to checkout
-Then they see "Your cart is empty" message
-And a "Continue Shopping" button is displayed
-
-### AC-006: Session Expiry
-Given a user whose session has expired
-When they try to perform any authenticated action
-Then they are redirected to login
-And a message "Session expired, please log in again" is shown
-And their intended action is preserved for after login
-```
-
-### Authorization
-
-```markdown
-### AC-007: Admin-Only Access
-Given a regular user (non-admin)
-When they try to access /admin/users
-Then they receive a 403 Forbidden response
-And are redirected to the home page
-And an "Access denied" message is shown
-
-### AC-008: Own Resource Only
-Given a user viewing another user's profile
-When they try to edit the profile
-Then the edit button is not visible
-And direct URL access returns 403
-```
-
-## INVEST Criteria
-
-Good acceptance criteria follow INVEST:
-
-| Criterion | Description | Check |
-|-----------|-------------|-------|
-| **I**ndependent | Can be tested alone | No dependencies on other ACs |
-| **N**egotiable | Details can be discussed | Not over-specified |
-| **V**aluable | Delivers user value | Ties to requirement |
-| **E**stimable | Effort can be estimated | Clear scope |
-| **S**mall | Testable in one session | Not too broad |
-| **T**estable | Pass/fail is clear | Objective criteria |
-
-## Quick Reference
-
-| Scenario Type | Given | When | Then |
-|---------------|-------|------|------|
-| Happy path | Valid state | Valid action | Success result |
-| Error | Invalid state/input | Action | Error message |
-| Edge case | Boundary condition | Action | Graceful handling |
-| Authorization | User role | Protected action | Appropriate access |
-| Concurrency | Multiple actors | Simultaneous action | Consistent state |
+# Acceptance Criteria
+
+## Given-When-Then Format
+
+```markdown
+### AC-001: [Scenario Name]
+Given [context/precondition]
+When [action taken]
+Then [expected result]
+```
+
+## Examples by Type
+
+### Happy Path
+
+```markdown
+### AC-001: Successful Login
+Given a registered user with valid credentials
+When they submit the login form
+Then they are redirected to the dashboard
+And a success message is displayed
+And their session is created
+
+### AC-002: Add Item to Cart
+Given a logged-in user viewing a product
+When they click "Add to Cart"
+Then the item appears in their cart
+And the cart badge updates with the count
+And a confirmation toast is shown
+```
+
+### Error Cases
+
+```markdown
+### AC-003: Invalid Login
+Given a user with incorrect password
+When they submit the login form
+Then an error message "Invalid credentials" is displayed
+And the password field is cleared
+And they remain on the login page
+
+### AC-004: Duplicate Email Registration
+Given an email already exists in the system
+When a new user tries to register with that email
+Then an error message "Email already registered" is displayed
+And the form is not submitted
+```
+
+### Edge Cases
+
+```markdown
+### AC-005: Empty Cart Checkout
+Given a user with an empty cart
+When they navigate to checkout
+Then they see "Your cart is empty" message
+And a "Continue Shopping" button is displayed
+
+### AC-006: Session Expiry
+Given a user whose session has expired
+When they try to perform any authenticated action
+Then they are redirected to login
+And a message "Session expired, please log in again" is shown
+And their intended action is preserved for after login
+```
+
+### Authorization
+
+```markdown
+### AC-007: Admin-Only Access
+Given a regular user (non-admin)
+When they try to access /admin/users
+Then they receive a 403 Forbidden response
+And are redirected to the home page
+And an "Access denied" message is shown
+
+### AC-008: Own Resource Only
+Given a user viewing another user's profile
+When they try to edit the profile
+Then the edit button is not visible
+And direct URL access returns 403
+```
+
+## INVEST Criteria
+
+Good acceptance criteria follow INVEST:
+
+| Criterion | Description | Check |
+|-----------|-------------|-------|
+| **I**ndependent | Can be tested alone | No dependencies on other ACs |
+| **N**egotiable | Details can be discussed | Not over-specified |
+| **V**aluable | Delivers user value | Ties to requirement |
+| **E**stimable | Effort can be estimated | Clear scope |
+| **S**mall | Testable in one session | Not too broad |
+| **T**estable | Pass/fail is clear | Objective criteria |
+
+## Quick Reference
+
+| Scenario Type | Given | When | Then |
+|---------------|-------|------|------|
+| Happy path | Valid state | Valid action | Success result |
+| Error | Invalid state/input | Action | Error message |
+| Edge case | Boundary condition | Action | Graceful handling |
+| Authorization | User role | Protected action | Appropriate access |
+| Concurrency | Multiple actors | Simultaneous action | Consistent state |

package/skills/backend/feature-forge/references/ears-syntax.md

@@ -1,99 +1,99 @@
-# EARS Syntax
-
-## EARS Format
-
-Easy Approach to Requirements Syntax for clear, unambiguous requirements.
-
-### Basic Pattern
-
-```
-While <precondition>, when <trigger>, the system shall <response>.
-```
-
-### Pattern Types
-
-**Ubiquitous (Always True)**
-```
-The system shall [action].
-```
-Example: The system shall encrypt all passwords using bcrypt.
-
-**Event-Driven**
-```
-When [trigger], the system shall [action].
-```
-Example: When the user clicks "Submit", the system shall save the form data.
-
-**State-Driven**
-```
-While [state], the system shall [action].
-```
-Example: While the user is logged in, the system shall display the dashboard.
-
-**Conditional (Most Common)**
-```
-While [state], when [trigger], the system shall [action].
-```
-Example: While the cart contains items, when the user clicks "Checkout", the system shall navigate to the payment page.
-
-**Optional**
-```
-Where [feature enabled], the system shall [action].
-```
-Example: Where two-factor authentication is enabled, the system shall require a verification code.
-
-## Examples by Domain
-
-### Authentication
-
-```markdown
-**FR-AUTH-001**: Login
-While credentials are valid, when POST /auth/login is called,
-the system shall return JWT access token (15min) and refresh token (7d).
-
-**FR-AUTH-002**: Invalid Login
-When invalid credentials are provided,
-the system shall return 401 and increment failed login counter.
-
-**FR-AUTH-003**: Account Lockout
-While failed login count exceeds 5, when login is attempted,
-the system shall reject the attempt and require password reset.
-```
-
-### E-commerce
-
-```markdown
-**FR-CART-001**: Add to Cart
-While user is logged in, when they click "Add to Cart",
-the system shall add the item and update the cart badge count.
-
-**FR-CART-002**: Apply Coupon
-While the cart contains items, when a valid coupon code is applied,
-the system shall reduce the total by the discount amount.
-
-**FR-ORDER-001**: Checkout
-While payment method is valid, when user confirms order,
-the system shall create order, charge payment, and send confirmation email.
-```
-
-### Data Management
-
-```markdown
-**FR-EXPORT-001**: CSV Export
-While user has data access permission, when they click "Export",
-the system shall generate a CSV file and initiate download.
-
-**FR-DELETE-001**: Soft Delete
-When a resource is deleted,
-the system shall set deleted_at timestamp instead of removing the record.
-```
-
-## Quick Reference
-
-| Type | Structure | Use When |
-|------|-----------|----------|
-| Ubiquitous | shall [action] | Always applies |
-| Event | When [X], shall | On trigger |
-| State | While [X], shall | Continuous state |
-| Conditional | While [X], when [Y], shall | State + trigger |
-| Optional | Where [X], shall | Feature flag |
+# EARS Syntax
+
+## EARS Format
+
+Easy Approach to Requirements Syntax for clear, unambiguous requirements.
+
+### Basic Pattern
+
+```
+While <precondition>, when <trigger>, the system shall <response>.
+```
+
+### Pattern Types
+
+**Ubiquitous (Always True)**
+```
+The system shall [action].
+```
+Example: The system shall encrypt all passwords using bcrypt.
+
+**Event-Driven**
+```
+When [trigger], the system shall [action].
+```
+Example: When the user clicks "Submit", the system shall save the form data.
+
+**State-Driven**
+```
+While [state], the system shall [action].
+```
+Example: While the user is logged in, the system shall display the dashboard.
+
+**Conditional (Most Common)**
+```
+While [state], when [trigger], the system shall [action].
+```
+Example: While the cart contains items, when the user clicks "Checkout", the system shall navigate to the payment page.
+
+**Optional**
+```
+Where [feature enabled], the system shall [action].
+```
+Example: Where two-factor authentication is enabled, the system shall require a verification code.
+
+## Examples by Domain
+
+### Authentication
+
+```markdown
+**FR-AUTH-001**: Login
+While credentials are valid, when POST /auth/login is called,
+the system shall return JWT access token (15min) and refresh token (7d).
+
+**FR-AUTH-002**: Invalid Login
+When invalid credentials are provided,
+the system shall return 401 and increment failed login counter.
+
+**FR-AUTH-003**: Account Lockout
+While failed login count exceeds 5, when login is attempted,
+the system shall reject the attempt and require password reset.
+```
+
+### E-commerce
+
+```markdown
+**FR-CART-001**: Add to Cart
+While user is logged in, when they click "Add to Cart",
+the system shall add the item and update the cart badge count.
+
+**FR-CART-002**: Apply Coupon
+While the cart contains items, when a valid coupon code is applied,
+the system shall reduce the total by the discount amount.
+
+**FR-ORDER-001**: Checkout
+While payment method is valid, when user confirms order,
+the system shall create order, charge payment, and send confirmation email.
+```
+
+### Data Management
+
+```markdown
+**FR-EXPORT-001**: CSV Export
+While user has data access permission, when they click "Export",
+the system shall generate a CSV file and initiate download.
+
+**FR-DELETE-001**: Soft Delete
+When a resource is deleted,
+the system shall set deleted_at timestamp instead of removing the record.
+```
+
+## Quick Reference
+
+| Type | Structure | Use When |
+|------|-----------|----------|
+| Ubiquitous | shall [action] | Always applies |
+| Event | When [X], shall | On trigger |
+| State | While [X], shall | Continuous state |
+| Conditional | While [X], when [Y], shall | State + trigger |
+| Optional | Where [X], shall | Feature flag |