@relipa/ai-flow-kit 0.0.1

package/custom/prompts/feature.md

@@ -0,0 +1,190 @@
+# Feature Development Prompt
+
+## 📋 Requirements
+
+**Title:** {{TITLE}}
+
+**Description:**
+{{DESCRIPTION}}
+
+**User Stories:**
+{{USER_STORIES}}
+
+**Acceptance Criteria:**
+{{ACCEPTANCE_CRITERIA}}
+
+**Design Specifications:**
+{{DESIGN_SPECS}}
+
+**Constraints & Limitations:**
+{{CONSTRAINTS}}
+
+---
+
+## 🎯 Your Task
+
+Build this feature systematically following the phases below.
+
+### Phase 1: Design & Planning
+
+Before writing code:
+
+1. **Understand Requirements**
+   - What exactly needs to be built?
+   - Who will use this?
+   - When do they need it?
+
+2. **Plan Architecture**
+   - What layers/components are needed?
+   - How do they interact?
+   - What database changes are needed?
+   - What API endpoints are required?
+
+3. **Identify Dependencies**
+   - Does this depend on other features?
+   - Are there related systems to consider?
+   - Any performance implications?
+
+4. **Design Database Schema** (if applicable)
+   - New tables or columns?
+   - Relationships and indexes?
+   - Migration strategy?
+
+5. **Design API Endpoints** (if applicable)
+   - What endpoints are needed?
+   - Request/response formats?
+   - Error handling?
+
+### Phase 2: Implementation
+
+Build the feature following your design:
+
+1. **Backend/Core Logic**
+   - Models and migrations
+   - Services and business logic
+   - API endpoints or methods
+   - Error handling
+
+2. **Frontend/UI** (if applicable)
+   - Component structure
+   - User interactions
+   - State management
+   - Styling approach
+
+3. **Follow Team Patterns**
+   - Use existing conventions
+   - Match code style
+   - Use approved libraries
+   - Follow architectural patterns
+
+### Phase 3: Testing
+
+Ensure quality:
+
+```bash
+# Unit tests - test individual components
+npm test -- --unit
+
+# Integration tests - test component interactions
+npm test -- --integration
+
+# Run full test suite
+npm test
+
+# Check code quality
+npm run lint
+
+# Check performance (if applicable)
+npm run benchmark
+```
+
+Test everything:
+- ✅ Happy path (normal usage)
+- ✅ Edge cases (boundary conditions)
+- ✅ Error scenarios (what breaks?)
+- ✅ Acceptance criteria (meets requirements?)
+
+### Phase 4: Verification
+
+Verify against requirements:
+
+**Acceptance Criteria Checklist:**
+- [ ] {{ACCEPTANCE_CRITERIA_1}}
+- [ ] {{ACCEPTANCE_CRITERIA_2}}
+- [ ] {{ACCEPTANCE_CRITERIA_3}}
+
+**Code Quality:**
+- [ ] Code style compliant
+- [ ] No security issues
+- [ ] Performance acceptable
+- [ ] Tests comprehensive
+- [ ] Documentation complete
+
+---
+
+## 📚 Team Framework Rules
+
+{{FRAMEWORK_RULES}}
+
+---
+
+## 📏 Team Rules & Standards
+
+{{TEAM_RULES}}
+
+---
+
+## 🏗️ Implementation Checklist
+
+### Setup Phase
+- [ ] Created feature branch
+- [ ] Updated .env if needed
+- [ ] Database schema designed
+
+### Development Phase
+- [ ] Core logic implemented
+- [ ] API endpoints working
+- [ ] UI components built
+- [ ] Integrated together
+
+### Testing Phase
+- [ ] Unit tests written
+- [ ] Integration tests written
+- [ ] All tests passing
+- [ ] No linting errors
+
+### Review Phase
+- [ ] Meets acceptance criteria
+- [ ] Follows team patterns
+- [ ] Code quality high
+- [ ] Documentation complete
+- [ ] Performance acceptable
+- [ ] No breaking changes
+
+---
+
+## 💡 Tips
+
+- **Start with design** → Plan before coding
+- **Follow patterns** → Use what exists
+- **Write tests early** → Verify as you build
+- **Test thoroughly** → Don't skip edge cases
+- **Document as you go** → Help future maintainers
+- **Keep it simple** → Don't over-engineer
+
+---
+
+## 🚀 Success Criteria
+
+- [ ] All acceptance criteria met
+- [ ] Full test coverage
+- [ ] Code follows team standards
+- [ ] No performance issues
+- [ ] Ready for production
+- [ ] Team can understand and maintain
+
+---
+
+**Build features right: understand requirements, design well, test thoroughly.** ✨
+
+Start development now! 🚀

package/custom/prompts/investigation.md

@@ -0,0 +1,164 @@
+# Code Investigation Prompt
+
+## 🔍 Investigation Question
+
+**Question:**
+{{QUESTION}}
+
+**Scope:**
+{{SCOPE}}
+
+**Background:**
+{{BACKGROUND}}
+
+---
+
+## 🎯 Your Task
+
+Investigate systematically to answer your question and document findings.
+
+### Phase 1: Clarify the Question
+
+- Restate the question clearly
+- Identify what you need to understand
+- What are you trying to learn?
+- Who needs this information?
+
+### Phase 2: Locate Relevant Code
+
+Identify which files and components are relevant:
+
+- Where does the feature start? (entry point)
+- How does it flow through the system?
+- What files are involved?
+- Are there tests that show usage?
+
+### Phase 3: Trace the Flow
+
+Follow the code flow from entry to end:
+
+```
+User Action / API Call
+    ↓
+Controller / Route Handler
+    ↓
+Service / Business Logic
+    ↓
+Model / Data Layer
+    ↓
+External Systems (if any)
+```
+
+Document:
+- What happens at each step?
+- What data is passed?
+- What transformations occur?
+- What are the key files?
+
+### Phase 4: Understand Patterns
+
+Look for patterns and conventions:
+
+- How is this feature structured?
+- What design patterns are used?
+- How does it follow team conventions?
+- Are there alternative approaches?
+
+### Phase 5: Identify Potential Issues
+
+Note:
+- Potential bugs or edge cases
+- Performance concerns
+- Security considerations
+- Opportunities for improvement
+
+### Phase 6: Document Findings
+
+Create clear documentation:
+
+**Summary:**
+- What you found
+- How the system works
+- Key takeaways
+
+**Code Examples:**
+- Show the important parts
+- Explain the logic
+- Highlight key patterns
+
+**Key Files:**
+- List files involved
+- Explain their roles
+- Show dependencies
+
+**Questions Answered:**
+- Your original question answered?
+- Any new questions?
+- Follow-up areas to investigate?
+
+---
+
+## 📚 Team Framework Rules
+
+{{FRAMEWORK_RULES}}
+
+---
+
+## 📏 Team Rules & Standards
+
+{{TEAM_RULES}}
+
+---
+
+## 🔬 Investigation Checklist
+
+### Understanding Phase
+- [ ] Question is clear
+- [ ] Scope is defined
+- [ ] Background understood
+
+### Code Exploration Phase
+- [ ] Entry point found
+- [ ] Flow traced
+- [ ] Key files identified
+- [ ] Tests examined
+
+### Analysis Phase
+- [ ] Patterns understood
+- [ ] Implementation clear
+- [ ] Interactions mapped
+- [ ] Issues noted
+
+### Documentation Phase
+- [ ] Summary written
+- [ ] Examples provided
+- [ ] Files documented
+- [ ] Findings saved
+
+---
+
+## 💡 Tips
+
+- **Start with tests** → Show how code is used
+- **Read code carefully** → Don't skim
+- **Ask questions** → Why is it this way?
+- **Follow the flow** → Don't jump around
+- **Document as you go** → Don't lose findings
+- **Save for team** → Use memory system
+
+---
+
+## ✅ Success Criteria
+
+- [ ] Original question fully answered
+- [ ] Code flow understood
+- [ ] Key patterns identified
+- [ ] Can explain to others
+- [ ] Findings documented
+- [ ] Saved to team memory
+
+---
+
+**Deep understanding leads to better code decisions.** 🔍
+
+Start investigating now! 🕵️

package/custom/rules/code-style.md

@@ -0,0 +1,7 @@
+# Code Style Guidelines
+
+- **Formatting:** Use Prettier (for JS/TS) or standard Laravel formatters (Pint) for PHP.
+- **Indentation:** 4 spaces for PHP, 2 spaces for JS/TS/CSS.
+- **Line Length:** Max 120 characters per line.
+- **Complexity:** Functions should do one thing only. If a function goes over 50 lines, reconsider the design.
+- **Comments:** Comment the "why", not the "what". Code should be self-explanatory whenever possible.

package/custom/rules/java/code-style.md

@@ -0,0 +1,11 @@
+# Code Style Guidelines — Java / Spring Boot
+
+- **Formatter:** Google Java Format or IntelliJ default Java formatter
+- **Indentation:** 4 spaces (no tabs)
+- **Line Length:** Max 120 characters per line
+- **Braces:** Always use braces even for single-line if/else/for
+- **Blank lines:** 1 blank line between methods; 2 blank lines between top-level declarations
+- **Complexity:** Methods should do one thing only. If a method exceeds ~30 lines, consider extracting
+- **Comments:** Comment the "why", not the "what". Use Javadoc for public API methods
+- **Annotations:** Place each annotation on its own line above the declaration
+- **Imports:** No wildcard imports (`import java.util.*`). Organize: Java → javax → third-party → internal

package/custom/rules/java/naming.md

@@ -0,0 +1,17 @@
+# Naming Conventions — Java / Spring Boot
+
+- **Classes:** PascalCase → `UserService`, `OrderController`, `PaymentRepository`
+- **Interfaces:** PascalCase (no `I` prefix) → `UserService`, NOT `IUserService`
+- **Implementations:** Append `Impl` → `UserServiceImpl`
+- **Methods:** camelCase, verb-first → `findById()`, `createOrder()`, `isActive()`
+- **Variables:** camelCase, descriptive → `userId`, `orderList`, NOT `u`, `ol`
+- **Constants:** UPPER_SNAKE_CASE → `MAX_RETRY_COUNT`, `DEFAULT_TIMEOUT_MS`
+- **Packages:** all lowercase → `com.company.project.service`
+- **Database tables:** snake_case → `user_orders`, `product_items`
+- **Database columns:** snake_case → `created_at`, `user_id`, `is_deleted`
+- **REST endpoints:** kebab-case, plural → `/api/v1/user-profiles`, `/api/v1/orders`
+- **Request DTOs:** `[Action][Resource]Request` → `CreateUserRequest`, `UpdateOrderRequest`
+- **Response DTOs:** `[Resource]Response` → `UserResponse`, `OrderDetailResponse`
+- **Enums:** PascalCase class, UPPER_SNAKE_CASE values → `OrderStatus.PENDING`
+- **Test classes:** `[ClassUnderTest]Test` → `UserServiceImplTest`
+- **Test methods:** `methodName_shouldExpectedBehavior_whenCondition` → `create_shouldThrowException_whenEmailDuplicated`

package/custom/rules/java/review-checklist.md

@@ -0,0 +1,36 @@
+# Code Review Checklist — Java / Spring Boot
+
+## Architecture
+- [ ] Controller only handles HTTP (parse request, call service, return response) — no business logic
+- [ ] Business logic resides in Service, not in Controller or Repository
+- [ ] Repository only performs data access — no business logic
+- [ ] Entity is not exposed directly — always use DTOs
+
+## Code Quality
+- [ ] No `@Autowired` field injection — use constructor injection (Lombok `@RequiredArgsConstructor`)
+- [ ] No `@Data` on Entity — use `@Getter @Setter` separately
+- [ ] No `new RuntimeException()` — create specific custom exceptions
+- [ ] No magic numbers/strings — use named constants
+- [ ] No dead code (commented-out code, unused variables)
+
+## Database & Performance
+- [ ] No N+1 queries — use `@EntityGraph` or `JOIN FETCH`
+- [ ] Lists are paginated — do not return the entire table
+- [ ] Read-only service methods have `@Transactional(readOnly = true)`
+- [ ] Indexes on columns frequently used in WHERE/JOIN
+
+## Testing
+- [ ] Unit tests for Service layer (Mockito)
+- [ ] Tests cover: happy path, error cases, edge cases
+- [ ] Do not mock things that don't need mocking
+
+## Security
+- [ ] Input is validated using Bean Validation (`@Valid`)
+- [ ] No logging of passwords, tokens, or PII
+- [ ] SQL injection is not possible (use parameterized JPA/JPQL)
+- [ ] Stack traces are not returned to the client
+
+## Logging
+- [ ] Use `@Slf4j` + SLF4J — no `System.out.println`
+- [ ] Correct log levels: `info` (normal), `warn` (recoverable), `error` (unexpected + exception)
+- [ ] Log messages have enough context for debugging (include ID, action)

package/custom/rules/javascript/code-style.md

@@ -0,0 +1,12 @@
+# Code Style Guidelines — JavaScript / TypeScript
+
+- **Formatter:** Prettier (auto-format on save)
+- **Linter:** ESLint with team config
+- **Indentation:** 2 spaces (no tabs)
+- **Line Length:** Max 100 characters per line
+- **Quotes:** Single quotes for JS/TS; double quotes in JSX attributes
+- **Semicolons:** Required at end of statements
+- **Trailing comma:** Required in multi-line arrays/objects/params
+- **Complexity:** Functions should do one thing only. Max ~40 lines; extract if longer
+- **Comments:** Comment the "why", not the "what". JSDoc for exported functions
+- **TypeScript:** No `any`. Use proper types, generics, or `unknown`

package/custom/rules/javascript/naming.md

@@ -0,0 +1,14 @@
+# Naming Conventions — JavaScript / TypeScript
+
+- **Files (components):** PascalCase → `UserCard.tsx`, `OrderList.tsx`
+- **Files (utils/hooks):** camelCase → `useUserList.ts`, `formatDate.ts`
+- **Components:** PascalCase → `UserCard`, `OrderDetail`
+- **Functions/methods:** camelCase, verb-first → `getUser()`, `handleSubmit()`, `formatDate()`
+- **Variables:** camelCase, descriptive → `userId`, `orderList`, NOT `u`, `ol`
+- **Constants:** UPPER_SNAKE_CASE → `MAX_RETRY`, `API_TIMEOUT`
+- **Types/Interfaces:** PascalCase → `User`, `CreateUserRequest`, `ApiResponse<T>`
+- **Boolean variables:** `is/has/can` prefix → `isLoading`, `hasError`, `canEdit`
+- **Event handlers:** `handle` prefix → `handleDelete`, `handleFormSubmit`
+- **Custom hooks:** `use` prefix → `useUserList`, `useAuth`, `useModal`
+- **Enums:** PascalCase → `OrderStatus.Pending`
+- **CSS classes:** kebab-case → `user-card`, `nav-item`

package/custom/rules/naming.md

@@ -0,0 +1,9 @@
+# Naming Conventions
+
+- **Variables & Functions:** `camelCase`
+- **Classes & Interfaces:** `PascalCase`
+- **Database Tables:** `snake_case` (plural), e.g., `user_settings`
+- **Constants:** `UPPER_SNAKE_CASE`
+- **Files/Folders:**
+  - `kebab-case` for Vue/React components and standard files by default.
+  - Exception: Next.js or Laravel core conventions override this rule (e.g. `PascalCase.tsx` if team uses it).

package/custom/rules/php/code-style.md

@@ -0,0 +1,10 @@
+# Code Style Guidelines — PHP / Laravel
+
+- **Formatter:** Laravel Pint (runs `./vendor/bin/pint`)
+- **Standard:** PSR-12
+- **Indentation:** 4 spaces (no tabs)
+- **Line Length:** Max 120 characters per line
+- **PHP Version:** 8.1+ — use typed properties, enums, match expression, named arguments
+- **Strict types:** Always declare `declare(strict_types=1)` at top of every file
+- **Complexity:** Methods should do one thing only. Max ~30 lines; use Services/Actions for complex logic
+- **Comments:** Comment the "why", not the "what". PHPDoc for public methods

package/custom/rules/php/naming.md

@@ -0,0 +1,15 @@
+# Naming Conventions — PHP / Laravel
+
+- **Classes:** PascalCase → `UserService`, `OrderController`
+- **Methods:** camelCase → `findById()`, `createOrder()`
+- **Variables:** camelCase → `$userId`, `$orderList`
+- **Constants:** UPPER_SNAKE_CASE → `MAX_RETRY_COUNT`
+- **Database tables:** snake_case, plural → `users`, `order_items`
+- **Database columns:** snake_case → `created_at`, `user_id`
+- **Routes:** kebab-case → `/user-profiles`, `/order-history`
+- **Controllers:** singular + Controller → `UserController`, `OrderController`
+- **Models:** singular PascalCase → `User`, `OrderItem`
+- **Migrations:** descriptive snake_case → `create_users_table`, `add_status_to_orders_table`
+- **Form Requests:** `[Action][Resource]Request` → `CreateUserRequest`, `UpdateOrderRequest`
+- **Events:** past tense → `UserCreated`, `OrderShipped`
+- **Jobs:** imperative → `SendWelcomeEmail`, `ProcessPayment`

package/custom/rules/review-checklist.md

@@ -0,0 +1,9 @@
+# Code Review Checklist
+
+Before creating a Pull Request, verify:
+- [ ] Code compiles and passes all local tests.
+- [ ] No strict dependency on local environment (hardcoded IPs, paths).
+- [ ] Security checks: No exposed API keys, no raw SQL vulnerability.
+- [ ] Impact Analysis run (via `impact-analysis` skill) and implications documented.
+- [ ] Naming and Code Style rules observed.
+- [ ] Feature is covered by unit/feature tests where applicable.