@relipa/ai-flow-kit 0.1.4 → 0.1.5-beta.1

package/custom/skills/review-plan/SKILL.md

@@ -1,194 +1,194 @@
----
-name: review-plan
-description: Gate 4 — After AI generates code, the developer reviews source code + summary. Developer must provide APPROVED or report a bug before closing the task.
-keywords: review, code review, approve, summary, checklist
----
-
-# Review Plan — Gate 4
-
-> **GATE 4: Runs after AI has completed code generation.**
->
-> Principle: AI self-reviews first (verification + impact-analysis), then presents a summary to the developer. The developer decides: APPROVED or report a bug.
-
----
-
-## Conditions to enter Gate 4
-
-- ✅ Gate 1 (requirement doc) has been APPROVED
-- ✅ Gate 2 (implementation plan) has been APPROVED
-- ✅ AI has completed code generation (Gate 3)
-- ✅ `superpowers:verification-before-completion` has run — tests pass
-- ✅ `impact-analysis` skill has run
-
-## Mode Selection
-
-Check `mode` in `.aiflow/context/current.json`:
-
-| Mode | Impact Analysis | Review Checklist | summary.md |
-|------|----------------|-----------------|-----------|
-| `fast` | Quick scan — reason from diff only | 3 items | Short format |
-| `full` | Full grep scan across codebase | 10 items | Full format |
-
-### Fast Track Impact Analysis (mode: fast)
-Assess impact by reasoning about the changed files only:
-1. List each file you modified
-2. For each file: "Does this file have callers/dependents outside the ticket scope?"
-3. If yes → list them and assign impact level
-4. DO NOT run grep on the full codebase
-
-### Fast Track Review Checklist (mode: fast)
-- [ ] All tests pass
-- [ ] No hardcoded credentials or secrets
-- [ ] No SQL injection risk in new queries
-
-## Fast Mode Output Rules (CRITICAL)
-
-When creating `plan/[ticket-id]/summary.md` in **fast mode**:
-- **Do not write long explanations or descriptions.**
-- **List format only:** Bullet points with `[NEW]`, `[MODIFIED]`, `[DELETED]`.
-- **Purpose:** Next to each file, write exactly 1 sentence explaining the *purpose* (the "why"), not the implementation details.
-
-**Example summary.md block:**
-```markdown
-### Gate 3 — Code
-- ✅ **Implemented batch endpoints**
-  - \`[NEW] src/controllers/BatchController.ts\`: Handle bulk export requests
-  - \`[MODIFIED] src/services/ExportService.ts\`: Added S3 upload integration
-```
-
----
-
-## Process
-
-### Step 1: AI self-review (before showing the developer)
-
-Run in the following mandatory order:
-
-```
-1. superpowers:verification-before-completion
-   → All tests must PASS. If any fail → fix immediately, do not show the developer.
-
-2. impact-analysis skill
-   → Check for breaking changes and side effects.
-
-3. review-checklist (.rules/review-checklist.md)
-   → Tick each item in the checklist.
-```
-
-**If any step fails → fix first, do not proceed to Step 2.**
-
-### Step 2: Create Summary Report
-
-Create file `plan/[ticket-id]/summary.md`:
-
-```markdown
-# Summary: [Ticket ID] — [Title]
-
-**Date:** [YYYY-MM-DD]
-**Status:** Waiting for DEV review
-
----
-
-## Implementation Details
-
-| File | Change | Reason |
-|------|----------|-------|
-| [path/to/file] | Created / Modified | [reason] |
-
----
-
-## Acceptance Criteria — results
-
-| Criteria | Status | Notes |
-|---------|--------|---------|
-| [Criteria 1] | ✅ Done | [implementation details] |
-| [Criteria 2] | ✅ Done | |
-
----
-
-## Tests Written
-
-| Test file | Test cases | Coverage |
-|-----------|-----------|---------|
-| [file] | [N] cases | [X%] |
-
-**Test output:**
-```
-[Paste test results here]
-```
-
----
-
-## Impact Analysis results
-
-**Level:** 🟢 Low / 🟡 Medium / 🔴 High
-
-**Impact Scope:**
-- [File/Service A] — [reason for impact / lack of impact]
-
-**Breaking changes:** None / [description if any]
-
----
-
-## Review Checklist
-
-- [ ] Code compiles and all tests pass
-- [ ] No hardcoded credentials / config
-- [ ] Security: no SQL injection, no exposure of sensitive data
-- [ ] Impact Analysis has been run
-- [ ] Naming and Code Style follow conventions
-- [ ] Sufficient tests (unit + integration)
-- [ ] No dead code / leftover console.logs
-```
-
-### Step 3: GATE 4 — Present to Developer
-
-```markdown
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-⏸️  GATE 4: WAITING FOR DEV REVIEW
-
-I have completed implementation and self-review.
-Summary: plan/[ticket-id]/summary.md
-
-**Self-review results:**
-- Tests: ✅ [N] passed / ❌ [N] failed  
-- Impact: [Low/Medium/High]
-- Checklist: [N/N] items ✅
-
-**You need to:**
-1. Review the summary above
-2. Check the source code if necessary
-3. Run manual tests if desired
-
-**After review, reply with one of the following:**
-
-✅ If OK: type **"APPROVED"**
-🐛 If there are bugs: type **"BUG: [description]"**
-   → If a requirement bug: I will return to Gate 1
-   → If a coding bug: I will fix and repeat Gate 4
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-### Step 4: Handle feedback
-
-**If the developer types "APPROVED":**
-→ Invoke `superpowers:requesting-code-review` to send for peer review
-→ Guide on creating a Pull Request
-
-**If the developer types "BUG: [description]" — coding bug:**
-→ Analyze bug, fix, rerun verification
-→ Repeat from Step 1 of Gate 4
-
-**If the developer types "BUG: [description]" — requirement bug:**
-→ Notify: "This is a requirement bug, requirement document needs update"
-→ Return to Gate 1, update requirement.md, wait for APPROVED again
-
----
-
-## Mandatory Rules
-
-- ❌ **DO NOT** invoke `requesting-code-review` before the developer provides APPROVED
-- ❌ **DO NOT** decide "task is done" on your own — must be confirmed by the developer
-- ✅ **MUST** run verification + impact-analysis before showing the developer
-- ✅ **MUST** clearly classify: requirement bug vs coding bug
-- ✅ **MUST** update summary.md each time changes are made
+---
+name: review-plan
+description: Gate 4 — After AI generates code, the developer reviews source code + summary. Developer must provide APPROVED or report a bug before closing the task.
+keywords: review, code review, approve, summary, checklist
+---
+
+# Review Plan — Gate 4
+
+> **GATE 4: Runs after AI has completed code generation.**
+>
+> Principle: AI self-reviews first (verification + impact-analysis), then presents a summary to the developer. The developer decides: APPROVED or report a bug.
+
+---
+
+## Conditions to enter Gate 4
+
+- ✅ Gate 1 (requirement doc) has been APPROVED
+- ✅ Gate 2 (implementation plan) has been APPROVED
+- ✅ AI has completed code generation (Gate 3)
+- ✅ `superpowers:verification-before-completion` has run — tests pass
+- ✅ `impact-analysis` skill has run
+
+## Mode Selection
+
+Check `mode` in `.aiflow/context/current.json`:
+
+| Mode | Impact Analysis | Review Checklist | summary.md |
+|------|----------------|-----------------|-----------|
+| `fast` | Quick scan — reason from diff only | 3 items | Short format |
+| `full` | Full grep scan across codebase | 10 items | Full format |
+
+### Fast Track Impact Analysis (mode: fast)
+Assess impact by reasoning about the changed files only:
+1. List each file you modified
+2. For each file: "Does this file have callers/dependents outside the ticket scope?"
+3. If yes → list them and assign impact level
+4. DO NOT run grep on the full codebase
+
+### Fast Track Review Checklist (mode: fast)
+- [ ] All tests pass
+- [ ] No hardcoded credentials or secrets
+- [ ] No SQL injection risk in new queries
+
+## Fast Mode Output Rules (CRITICAL)
+
+When creating `04.Coding/04.Reviews/[functionId]/[ticketId].md` in **fast mode**:
+- **Do not write long explanations or descriptions.**
+- **List format only:** Bullet points with `[NEW]`, `[MODIFIED]`, `[DELETED]`.
+- **Purpose:** Next to each file, write exactly 1 sentence explaining the *purpose* (the "why"), not the implementation details.
+
+**Example summary.md block:**
+```markdown
+### Gate 3 — Code
+- ✅ **Implemented batch endpoints**
+  - \`[NEW] src/controllers/BatchController.ts\`: Handle bulk export requests
+  - \`[MODIFIED] src/services/ExportService.ts\`: Added S3 upload integration
+```
+
+---
+
+## Process
+
+### Step 1: AI self-review (before showing the developer)
+
+Run in the following mandatory order:
+
+```
+1. superpowers:verification-before-completion
+   → All tests must PASS. If any fail → fix immediately, do not show the developer.
+
+2. impact-analysis skill
+   → Check for breaking changes and side effects.
+
+3. review-checklist (.rules/review-checklist.md)
+   → Tick each item in the checklist.
+```
+
+**If any step fails → fix first, do not proceed to Step 2.**
+
+### Step 2: Create Summary Report
+
+Create file `04.Coding/04.Reviews/[functionId]/[ticketId].md`:
+
+```markdown
+# Summary: [Ticket ID] — [Title]
+
+**Date:** [YYYY-MM-DD]
+**Status:** Waiting for DEV review
+
+---
+
+## Implementation Details
+
+| File | Change | Reason |
+|------|----------|-------|
+| [path/to/file] | Created / Modified | [reason] |
+
+---
+
+## Acceptance Criteria — results
+
+| Criteria | Status | Notes |
+|---------|--------|---------|
+| [Criteria 1] | ✅ Done | [implementation details] |
+| [Criteria 2] | ✅ Done | |
+
+---
+
+## Tests Written
+
+| Test file | Test cases | Coverage |
+|-----------|-----------|---------|
+| [file] | [N] cases | [X%] |
+
+**Test output:**
+```
+[Paste test results here]
+```
+
+---
+
+## Impact Analysis results
+
+**Level:** 🟢 Low / 🟡 Medium / 🔴 High
+
+**Impact Scope:**
+- [File/Service A] — [reason for impact / lack of impact]
+
+**Breaking changes:** None / [description if any]
+
+---
+
+## Review Checklist
+
+- [ ] Code compiles and all tests pass
+- [ ] No hardcoded credentials / config
+- [ ] Security: no SQL injection, no exposure of sensitive data
+- [ ] Impact Analysis has been run
+- [ ] Naming and Code Style follow conventions
+- [ ] Sufficient tests (unit + integration)
+- [ ] No dead code / leftover console.logs
+```
+
+### Step 3: GATE 4 — Present to Developer
+
+```markdown
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+⏸️  GATE 4: WAITING FOR DEV REVIEW
+
+I have completed implementation and self-review.
+Summary: 04.Coding/04.Reviews/[functionId]/[ticketId].md
+
+**Self-review results:**
+- Tests: ✅ [N] passed / ❌ [N] failed  
+- Impact: [Low/Medium/High]
+- Checklist: [N/N] items ✅
+
+**You need to:**
+1. Review the summary above
+2. Check the source code if necessary
+3. Run manual tests if desired
+
+**After review, reply with one of the following:**
+
+✅ If OK: type **"APPROVED"**
+🐛 If there are bugs: type **"BUG: [description]"**
+   → If a requirement bug: I will return to Gate 1
+   → If a coding bug: I will fix and repeat Gate 4
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+### Step 4: Handle feedback
+
+**If the developer types "APPROVED":**
+→ Invoke `superpowers:requesting-code-review` to send for peer review
+→ Guide on creating a Pull Request
+
+**If the developer types "BUG: [description]" — coding bug:**
+→ Analyze bug, fix, rerun verification
+→ Repeat from Step 1 of Gate 4
+
+**If the developer types "BUG: [description]" — requirement bug:**
+→ Notify: "This is a requirement bug, requirement document needs update"
+→ Return to Gate 1, update requirement.md, wait for APPROVED again
+
+---
+
+## Mandatory Rules
+
+- ❌ **DO NOT** invoke `requesting-code-review` before the developer provides APPROVED
+- ❌ **DO NOT** decide "task is done" on your own — must be confirmed by the developer
+- ✅ **MUST** run verification + impact-analysis before showing the developer
+- ✅ **MUST** clearly classify: requirement bug vs coding bug
+- ✅ **MUST** update summary.md each time changes are made

package/custom/skills/test-skills/rules/directory-and-naming-convention.md

@@ -0,0 +1,158 @@
+# 00. Directory Structure & File Naming Convention
+
+## Objective
+
+Define and standardize directory organization and file naming rules for all Artifacts generated in the QA Workflow. Ensures consistency, traceability, and maintainability across the project.
+
+> **Important**: This document is the **mandatory reference** for the entire workflow. All generated Artifacts (Result, QA, TestCase) must strictly follow the rules defined here before executing any step in the workflow.
+
+---
+
+## 1. Directory Overview
+
+```text
+03.Testing/
+├── 01.Testcases/
+│   └── [functionId]/
+│       └── [functionId]_TestCase.md                  ← Gate 4 tạo
+└── 07.AI-Artifacts/
+    └── [functionId]/
+        ├── [functionId]_01_Requirement_Analysis_Result.md     ← Gate 1 tạo
+        ├── [functionId]_01_Requirement_Analysis_QA.md         ← Gate 1 tạo (nếu có issue)
+        ├── [functionId]_02_Test_Scenarios_Result.md           ← Gate 2 tạo
+        ├── [functionId]_02_Scenario_Building_QA.md            ← Gate 2 tạo (nếu có issue)
+        ├── [functionId]_03_Test_Cases_Draft_Result.md         ← Gate 3 tạo
+        ├── [functionId]_03_Test_Design_QA.md                  ← Gate 3 tạo (nếu có issue)
+        ├── [functionId]_04_Test_Cases_Final_Result.md         ← Gate 4 tạo (cùng TestCase)
+        └── [functionId]_04_Test_Review_QA.md                  ← Gate 4 tạo
+```
+
+Example: `functionId = AD06` → root folder is `03.Testing/`
+
+---
+
+## 2. 07.AI-Artifacts/ Directory Rules
+
+- **Root path**: `03.Testing/07.AI-Artifacts/[functionId]/`
+- **Purpose**: Store all official result artifacts and QA tracking files generated at each workflow gate.
+
+### 2.1. File Naming Convention
+
+Files are placed under `03.Testing/07.AI-Artifacts/[functionId]/` with the `[functionId]` as prefix:
+
+```
+[functionId]_[step]_Result.md
+[functionId]_[step]_QA.md
+```
+
+### 2.2. File Name Table by Gate
+
+| Gate | Step Name | Result File Name | QA File Name (if issues) |
+| :---: | :--- | :--- | :--- |
+| **01** | `01_Requirement_Analysis` | `[functionId]_01_Requirement_Analysis_Result.md` | `[functionId]_01_Requirement_Analysis_QA.md` |
+| **02** | `02_Test_Scenarios` | `[functionId]_02_Test_Scenarios_Result.md` | `[functionId]_02_Scenario_Building_QA.md` |
+| **03** | `03_Test_Cases_Draft` | `[functionId]_03_Test_Cases_Draft_Result.md` | `[functionId]_03_Test_Design_QA.md` |
+| **04** | `04_Test_Cases_Final` | `[functionId]_04_Test_Cases_Final_Result.md` | `[functionId]_04_Test_Review_QA.md` |
+
+### 2.3. Full Path Examples
+
+```
+03.Testing/07.AI-Artifacts/AD06/AD06_01_Requirement_Analysis_Result.md
+03.Testing/07.AI-Artifacts/AD06/AD06_01_Requirement_Analysis_QA.md
+03.Testing/07.AI-Artifacts/AD06/AD06_02_Test_Scenarios_Result.md
+03.Testing/07.AI-Artifacts/AD06/AD06_03_Test_Cases_Draft_Result.md
+03.Testing/07.AI-Artifacts/AD06/AD06_04_Test_Cases_Final_Result.md
+```
+
+> QA files are only created when there are issues (Critical/Major block, or Minor carry-forward).
+
+---
+
+## 3. 01.Testcases/ Directory Rules
+
+- **Root path**: `03.Testing/01.Testcases/[functionId]/`
+- **Purpose**: Store the final test case artifact ready for execution. This file contains only the **test case tables** (not review summaries, findings, or coverage validation) and is generated **simultaneously** with `04_Test_Cases_Final_Result.md` at the end of Gate 4.
+
+### 3.1. File Naming Convention
+
+```
+[functionId]_TestCase.md
+```
+
+### 3.2. Full Path Example
+
+```
+03.Testing/01.Testcases/AD06/AD06_TestCase.md
+```
+
+### 3.3. File Content
+
+The TestCase file follows the **standard template** at `.claude/skills/test-skills/template/testcase-template.md` and **only includes**:
+
+- **Section 1**: General Information (fill in functionId, creation date)
+- **Section 2**: Test Execution Summary (reset to 0, waiting for execution)
+- **Section 3**: Detailed Test Cases (all 5 groups and test case tables)
+
+> **Does NOT include**: Review Summary, Review Findings, Coverage Validation (RTM), Sign-off Status — these belong in `04_Test_Cases_Final_Result.md` within `07.AI-Artifacts/[functionId]/`.
+
+### 3.4. Generation Timing
+
+The TestCase file is generated **simultaneously** with `04_Test_Cases_Final_Result.md` at the end of Gate 4, after all Critical/Major issues are resolved and the test case set has been signed off.
+
+---
+
+## 4. Full Artifact Matrix
+
+| Gate | Description | Result Artifact | QA Artifact | TestCase Artifact |
+| :---: | :--- | :--- | :--- | :--- |
+| **01** | Requirement & Risk Analysis | `[fId]_01_Requirement_Analysis_Result.md` | `[fId]_01_Requirement_Analysis_QA.md` | — |
+| **02** | Scenario Building | `[fId]_02_Test_Scenarios_Result.md` | `[fId]_02_Scenario_Building_QA.md` | — |
+| **03** | Test Case Design | `[fId]_03_Test_Cases_Draft_Result.md` | `[fId]_03_Test_Design_QA.md` | — |
+| **04** | Review & Optimization | `[fId]_04_Test_Cases_Final_Result.md` | `[fId]_04_Test_Review_QA.md` | `[fId]_TestCase.md` |
+
+> `[fId]` = `[functionId]`
+
+---
+
+## 5. Additional Rules
+
+### 5.1. Update Rule
+
+- If a file already exists, **update and overwrite** with the latest content.
+- **Do not create duplicate files** with version suffixes (e.g. `_v1`, `_v2`, `_final`, `_new`).
+
+### 5.2. functionId Naming
+
+- Use the **exact functionId** determined in Gate 1 Pre-flight (e.g. `AD06`, `AD10`, `LOGIN`).
+- Valid examples: `AD06`, `AD10_Create_Product`, `LOGIN`, `ORD002`
+- **Invalid**: `product`, `login`, `tag_feature` (custom names diverging from the functionId)
+- The workflow **MUST** strictly require a `functionId` before starting.
+
+### 5.3. Consistency Principle
+
+- `07.AI-Artifacts/` and `01.Testcases/` artifacts for the same functionId **must all use the same functionId prefix** and be grouped in a `[functionId]` subfolder.
+- This ensures fast cross-lookup and traceability.
+
+---
+
+## 6. Application Checklist
+
+Before starting any workflow gate, verify:
+
+- [ ] functionId has been confirmed in Gate 1 Pre-flight?
+- [ ] Root folder `03.Testing/` exists?
+- [ ] `07.AI-Artifacts/[functionId]/` subfolder exists?
+- [ ] Result file name follows pattern `[functionId]_[step]_Result.md`?
+- [ ] QA file name follows pattern `[functionId]_[step]_QA.md`?
+- [ ] (After Gate 4) `01.Testcases/[functionId]/` subfolder exists?
+- [ ] (After Gate 4) TestCase file name follows pattern `[functionId]_TestCase.md`?
+- [ ] (After Gate 4) TestCase file contains only Section 1+2+3 per template (no review metadata)?
+- [ ] No duplicate or incorrectly named files?
+
+---
+
+## 7. References
+
+- `create-testcase-workflow.md` — Full 4-Gate QA workflow definition
+- `.claude/skills/test-skills/template/testcase-template.md` — Standard test case template
+- `.claude/skills/test-skills/rules/qa-writing-standards.md` — QA writing standards