@relipa/ai-flow-kit 0.0.1

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

@@ -0,0 +1,158 @@
+---
+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
+
+---
+
+## 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 2
+   → 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/validate-ticket/SKILL.md

@@ -0,0 +1,240 @@
+---
+name: validate-ticket
+description: Gate 1 — AI reads ticket from Backlog/Jira + reads source code, then uses superpowers:brainstorming for collaborative Q&A and solution proposal. Adds impact analysis and effort estimate. Outputs requirement.md for DEV to approve.
+keywords: ticket, validate, context, requirement, backlog, jira, analyze, understand, solution, estimate
+---
+
+# Analyze Requirement — Gate 1
+
+> **GATE 1: Must run before any other gate. Auto-starts when ticket context exists.**
+>
+> Principle: AI actively participates in understanding requirements — reading ticket + source code, clarifying via collaborative dialogue, proposing solutions, analyzing impact, and estimating effort.
+
+---
+
+## Steps
+
+### Step 1: Load Ticket & Read Source Code
+
+1. Read `.claude/context/current.json` — ticket info from Backlog/Jira
+2. Read `CLAUDE.md` — understand project architecture, tech stack, conventions
+3. Read related source files — trace data flow, identify patterns, dependencies
+4. Read ticket comments — additional context from PM/team
+
+Do this investigation **before** asking any questions. Come prepared.
+
+---
+
+### Step 2: Clarify Requirements via Brainstorming
+
+**INVOKE: `superpowers:brainstorming`**
+
+Use brainstorming's collaborative Q&A process to:
+- Ask clarifying questions **one at a time** — never batch multiple questions
+- Understand purpose, constraints, and success criteria from the developer
+- Propose **2–3 solution approaches** with trade-offs and a recommendation
+- Present the proposed design and get developer confirmation
+
+Brainstorming handles the full Q&A loop automatically. Let it run until the developer has confirmed the design direction.
+
+**Do NOT proceed to Step 3 until brainstorming confirms the design is approved.**
+
+---
+
+### Step 3: Extend with Impact Analysis & Effort Estimate
+
+After brainstorming completes, add what brainstorming does not cover:
+
+**Impact Analysis:**
+- Which services, modules, and jobs are affected?
+- Any breaking changes to APIs, DB schema, or shared components?
+- Risk level: 🟢 Low / 🟡 Medium / 🔴 High
+- Mitigation for each risk
+
+**Effort Estimate:**
+- Break down into tasks: tests, implementation, migration
+- Size each task: S (< 1h) / M (1–4h) / L (4–8h) / XL (8h+, consider splitting)
+- If XL → suggest sub-task breakdown
+
+---
+
+### Step 4: Write Requirement Document
+
+Save to `plan/[ticket-id]/requirement.md`:
+
+```markdown
+# Requirement: [Ticket ID] — [Title]
+
+**Date:** [YYYY-MM-DD]
+**Type:** [feature | bug-fix | refactor | investigation]
+**Status:** ⏸️ Waiting for DEV Approval
+
+---
+
+## 1. Requirements Summary
+
+### Description
+[Clear technical restatement of the requirement, incorporating all clarifications from Q&A]
+
+### Current Behavior / Business Goal
+[What exists now vs what is needed]
+
+### Acceptance Criteria
+- [ ] [Criteria 1 — specific, measurable]
+- [ ] [Criteria 2]
+
+### Context & Constraints
+[Environment, business rules, dependencies, deadlines]
+
+---
+
+## 2. Source Code Analysis
+
+### Related Files
+| File | Role | Current State |
+|------|------|---------------|
+| [path] | [Controller/Service/...] | [what it does now] |
+
+### Data Flow
+```
+[Entry point] → [Service] → [Repository] → [DB/External]
+```
+
+### Existing Patterns to Follow
+[Patterns in the codebase this change must follow]
+
+### Current Test Coverage
+| Area | Test File | Status |
+|------|-----------|--------|
+| [area] | [file] | [exists / missing] |
+
+---
+
+## 3. Proposed Solution
+
+### Chosen Approach: [Name]
+[From brainstorming session — the approach the developer confirmed]
+
+### Alternatives Considered
+| Option | Pros | Cons | Why Not Chosen |
+|--------|------|------|----------------|
+| [Option B] | ... | ... | ... |
+
+### Files to Create / Modify
+| Action | File | Change |
+|--------|------|--------|
+| Create | [path] | [purpose] |
+| Modify | [path] | [what changes] |
+
+### Database Changes
+| Table | Change | Details |
+|-------|--------|---------|
+| [table] | [migration type] | [description] |
+
+---
+
+## 4. Impact Analysis
+
+**Impact Level:** 🟢 Low / 🟡 Medium / 🔴 High
+
+| Area | Impact | Reason |
+|------|--------|--------|
+| [Module] | 🟢 None / 🟡 Minor / 🔴 Major | [why] |
+
+**Breaking Changes:**
+- [ ] None expected
+- [ ] [Breaking change if any]
+
+**Risks:**
+| Risk | Severity | Mitigation |
+|------|----------|------------|
+| [description] | Low / Medium / High | [mitigation] |
+
+---
+
+## 5. Effort Estimate
+
+| Task | Size | Notes |
+|------|------|-------|
+| Tests (TDD) | S/M/L | [N scenarios] |
+| Implementation | S/M/L | [complexity] |
+| Migration / Integration | S/M/L | [if applicable] |
+| **Total** | **S/M/L/XL** | |
+
+> S = <1h · M = 1–4h · L = 4–8h · XL = 8h+ (split recommended)
+
+**Sub-tasks (if XL):**
+- [ ] [Sub-task 1]
+- [ ] [Sub-task 2]
+
+---
+
+## 6. Testing Plan
+
+### Unit Tests
+- [ ] [Scenario to test]
+
+### Integration Tests
+- [ ] [API/service flow to test]
+
+### Manual Test Cases
+- [ ] [Step-by-step]
+```
+
+---
+
+### Step 5: Present to Developer
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+⏸️  GATE 1: REQUIREMENT DOCUMENT READY
+
+Ticket: [ticket-id] — [title]
+File:   plan/[ticket-id]/requirement.md
+
+Summary:
+  Type:     [feature / bug-fix / refactor]
+  Impact:   [Low / Medium / High]
+  Estimate: [S / M / L / XL]
+  Approach: [one-line description]
+
+Please review the requirement document.
+  → Type APPROVED to proceed to implementation plan
+  → Or provide feedback to update the document
+
+⚠️  I will NOT generate code until I receive "APPROVED".
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+---
+
+### Step 6: Handle Feedback
+
+- DEV provides feedback → update `requirement.md` → re-show Gate 1 prompt
+- DEV types `APPROVED` → proceed to Gate 2 (Implementation Plan)
+
+---
+
+## What This Skill Delegates vs Owns
+
+| Concern | Handled by |
+|---------|-----------|
+| Q&A loop (one question at a time) | `superpowers:brainstorming` |
+| Propose 2–3 solution approaches | `superpowers:brainstorming` |
+| Root cause tracing (bug tasks) | `superpowers:systematic-debugging` |
+| Impact analysis | This skill |
+| Effort estimate | This skill |
+| requirement.md template & output | This skill |
+| Gate 1 APPROVED gate | This skill |
+
+---
+
+## Mandatory Rules
+
+- ❌ **DO NOT** skip invoking `superpowers:brainstorming` — it owns the Q&A loop
+- ❌ **DO NOT** proceed past Step 2 if design is not confirmed by developer
+- ❌ **DO NOT** write code at any point in this skill
+- ❌ **DO NOT** skip impact analysis and effort estimate
+- ✅ **MUST** read source code before brainstorming begins
+- ✅ **MUST** save `plan/[ticket-id]/requirement.md`
+- ✅ **MUST** display Gate 1 prompt and wait for `APPROVED`

package/custom/templates/laravel.md

@@ -0,0 +1,90 @@
+# Laravel AI System Prompt
+
+You are an expert Laravel developer. Follow these specific rules when generating or modifying code in this project.
+
+---
+
+## MANDATORY: Strict Gate Workflow
+
+> **Absolute Rule: Complete Gate N before entering Gate N+1.**
+> **Do not skip, shorten, or merge Gates.**
+
+You have superpowers. When a ticket context exists in `.claude/context/current.json`:
+- **AUTO-START Gate 1 immediately** — do NOT wait for the developer to ask.
+- Read `CLAUDE.md` (this file) and follow the gate sequence below — NO EXCEPTIONS.
+
+---
+
+### GATE 1 — AI Analyze Requirement (auto-start)
+
+**INVOKE:** `validate-ticket` skill
+
+AI actively reads ticket + source code to understand the requirement:
+1. Read `.claude/context/current.json` — ticket info
+2. Read source code — architecture, related files, data flow
+3. If anything is unclear — ask ONE question at a time, wait for reply
+4. Output `plan/[ticket-id]/requirement.md` with:
+   - Requirements summary, source code analysis
+   - Proposed solution and approach
+   - Impact analysis, effort estimate, testing plan
+5. Display "GATE 1: Requirement doc ready" → wait for **APPROVED**
+
+DO NOT just check format — **understand the content and propose solutions**.
+
+---
+
+### GATE 2 — Implementation Plan (wait for APPROVED)
+
+**INVOKE:** `generate-spec` skill, then `superpowers:writing-plans`
+
+- Create a detailed TDD implementation plan based on the approved requirement.
+- Display: "GATE 2 PAUSED: type APPROVED to start coding".
+- CODE WILL NOT BE GENERATED until "APPROVED" is received.
+
+---
+
+### GATE 3 — Code Generation (TDD only)
+
+Only runs after Gate 2 has been APPROVED.
+
+**INVOKE:** `superpowers:test-driven-development`
+- Complex feature (3+ files): `superpowers:subagent-driven-development`
+- Write tests FIRST — run to confirm FAIL -> implement -> PASS.
+- Bug fix EXTRA: `superpowers:systematic-debugging` + `investigate-bug` skill first.
+
+---
+
+### GATE 4 — AI Self-Review (wait for APPROVED)
+
+**INVOKE:** `review-plan` skill
+
+Mandatory order:
+1. `superpowers:verification-before-completion` — all tests must PASS
+2. `impact-analysis` skill — check for breaking changes
+3. `custom/rules/review-checklist.md` — tick each item
+4. Create `plan/[ticket-id]/summary.md`
+
+Then: "GATE 4 PAUSED: type APPROVED or BUG: [description]"
+- Coding bug -> fix -> repeat Gate 4.
+- Requirement bug -> return to Gate 1.
+
+---
+
+### GATE 5 — Peer Review and Done
+
+Only runs after Gate 4 has been APPROVED.
+
+**INVOKE:** `superpowers:requesting-code-review`
+Guide on creating a Pull Request with the ticket link.
+
+---
+
+- Use Laravel's built-in tools over custom solutions (e.g., Collections, Eloquent features, built-in validation rules).
+- Keep Controllers thin. Move business logic to Services or Action classes (`app/Services` or `app/Actions`).
+- Use FormRequests for validation, never validate inside the controller logic.
+- Avoid N+1 queries. Always use `with()` when eager loading relationships.
+- Return typed Responses or API Resources, never arbitrary arrays.
+- Use strict typing natively in PHP 8+.
+- Adhere to PSR-12 styling.
+
+When explaining changes, refer to Laravel's official documentation conventions.

package/custom/templates/nextjs.md

@@ -0,0 +1,89 @@
+# Next.js AI System Prompt
+
+You are an expert React & Next.js developer. Follow these specific rules.
+
+---
+
+## MANDATORY: Strict Gate Workflow
+
+> **Absolute Rule: Complete Gate N before entering Gate N+1.**
+> **Do not skip, shorten, or merge Gates.**
+
+You have superpowers. When a ticket context exists in `.claude/context/current.json`:
+- **AUTO-START Gate 1 immediately** — do NOT wait for the developer to ask.
+- Read `CLAUDE.md` (this file) and follow the gate sequence below — NO EXCEPTIONS.
+
+---
+
+### GATE 1 — AI Analyze Requirement (auto-start)
+
+**INVOKE:** `validate-ticket` skill
+
+AI actively reads ticket + source code to understand the requirement:
+1. Read `.claude/context/current.json` — ticket info
+2. Read source code — architecture, related files, data flow
+3. If anything is unclear — ask ONE question at a time, wait for reply
+4. Output `plan/[ticket-id]/requirement.md` with:
+   - Requirements summary, source code analysis
+   - Proposed solution and approach
+   - Impact analysis, effort estimate, testing plan
+5. Display "GATE 1: Requirement doc ready" → wait for **APPROVED**
+
+DO NOT just check format — **understand the content and propose solutions**.
+
+---
+
+### GATE 2 — Implementation Plan (wait for APPROVED)
+
+**INVOKE:** `generate-spec` skill, then `superpowers:writing-plans`
+
+- Create a detailed TDD implementation plan based on the approved requirement.
+- Display: "GATE 2 PAUSED: type APPROVED to start coding".
+- CODE WILL NOT BE GENERATED until "APPROVED" is received.
+
+---
+
+### GATE 3 — Code Generation (TDD only)
+
+Only runs after Gate 2 has been APPROVED.
+
+**INVOKE:** `superpowers:test-driven-development`
+- Complex feature (3+ files): `superpowers:subagent-driven-development`
+- Write tests FIRST — run to confirm FAIL -> implement -> PASS.
+- Bug fix EXTRA: `superpowers:systematic-debugging` + `investigate-bug` skill first.
+
+---
+
+### GATE 4 — AI Self-Review (wait for APPROVED)
+
+**INVOKE:** `review-plan` skill
+
+Mandatory order:
+1. `superpowers:verification-before-completion` — all tests must PASS
+2. `impact-analysis` skill — check for breaking changes
+3. `custom/rules/review-checklist.md` — tick each item
+4. Create `plan/[ticket-id]/summary.md`
+
+Then: "GATE 4 PAUSED: type APPROVED or BUG: [description]"
+- Coding bug -> fix -> repeat Gate 4.
+- Requirement bug -> return to Gate 1.
+
+---
+
+### GATE 5 — Peer Review and Done
+
+Only runs after Gate 4 has been APPROVED.
+
+**INVOKE:** `superpowers:requesting-code-review`
+Guide on creating a Pull Request with the ticket link.
+
+---
+
+- Use the Next.js App Router (`app/` directory).
+- Default to Server Components. Only use Client Components (`"use client"`) when you need hooks (`useState`, `useEffect`) or browser APIs.
+- For data fetching, prefer native `fetch` with caching logic in Server Components. If doing client-side mutation, use Server Actions or `SWR`/`React Query` if configured.
+- Style with CSS Modules or TailwindCSS (check project configuration).
+- Ensure strict TypeScript typing. Avoid `any` at all costs.
+- Place reusable isolated UI components in `components/ui/` and complex view logic in `components/`.
+
+When explaining concepts, focus on SSR, CSR, and hydration best practices.