@riligar/agents-kit 1.8.0 → 1.10.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agent/rules/code-style.md +127 -0
- package/.agent/rules/conventional-commits.md +90 -12
- package/.agent/rules/javascript-only.md +116 -0
- package/.agent/rules/naming-conventions.md +168 -0
- package/.agent/rules/pr-guidelines.md +121 -0
- package/.agent/skills/riligar-business-startup-analyst/SKILL.md +2 -3
- package/.agent/skills/riligar-business-startup-financial/SKILL.md +2 -3
- package/.agent/skills/riligar-business-startup-market/SKILL.md +2 -3
- package/.agent/skills/riligar-design-system/SKILL.md +1 -1
- package/.agent/skills/riligar-dev-architecture/SKILL.md +1 -1
- package/.agent/skills/riligar-dev-auth-elysia/SKILL.md +1 -0
- package/.agent/skills/riligar-dev-auth-react/SKILL.md +1 -0
- package/.agent/skills/riligar-dev-autopilot/SKILL.md +2 -5
- package/.agent/skills/riligar-dev-backend/SKILL.md +3 -3
- package/.agent/skills/riligar-dev-clean-code/SKILL.md +2 -4
- package/.agent/skills/riligar-dev-code-review/SKILL.md +2 -2
- package/.agent/skills/riligar-dev-database/SKILL.md +2 -2
- package/.agent/skills/riligar-dev-frontend/SKILL.md +3 -3
- package/.agent/skills/riligar-dev-landing-page/SKILL.md +1 -1
- package/.agent/skills/riligar-dev-seo/SKILL.md +2 -2
- package/.agent/skills/riligar-dev-stripe/SKILL.md +152 -0
- package/.agent/skills/riligar-infrastructure/SKILL.md +1 -4
- package/.agent/skills/riligar-marketing-copy/SKILL.md +2 -2
- package/.agent/skills/riligar-marketing-email/SKILL.md +3 -2
- package/.agent/skills/riligar-marketing-seo/SKILL.md +2 -7
- package/.agent/skills/riligar-plan-writing/SKILL.md +1 -1
- package/.agent/skills/riligar-tech-stack/SKILL.md +1 -4
- package/.agent/skills/skill-creator/SKILL.md +37 -6
- package/package.json +1 -1
|
@@ -0,0 +1,127 @@
|
|
|
1
|
+
# Code Style
|
|
2
|
+
|
|
3
|
+
All code must follow the RiLiGar formatting standards enforced by Prettier.
|
|
4
|
+
|
|
5
|
+
## Formatting Rules
|
|
6
|
+
|
|
7
|
+
| Rule | Value | Example |
|
|
8
|
+
| --- | --- | --- |
|
|
9
|
+
| Indentation | 4 spaces | ` const x = 1` |
|
|
10
|
+
| Tabs | Never | Use spaces only |
|
|
11
|
+
| Semicolons | Never | `const x = 1` not `const x = 1;` |
|
|
12
|
+
| Quotes | Single | `'string'` not `"string"` |
|
|
13
|
+
| Trailing Commas | ES5 | Arrays and objects, not function params |
|
|
14
|
+
| Bracket Spacing | Yes | `{ key: value }` not `{key: value}` |
|
|
15
|
+
| Arrow Parens | Avoid | `x => x` not `(x) => x` |
|
|
16
|
+
| Line Endings | LF | Unix-style |
|
|
17
|
+
| Print Width | 300 | Long lines allowed |
|
|
18
|
+
| JSX Attributes | One per line | See below |
|
|
19
|
+
|
|
20
|
+
## JSX Formatting
|
|
21
|
+
|
|
22
|
+
```jsx
|
|
23
|
+
// Good - one attribute per line
|
|
24
|
+
<Button
|
|
25
|
+
variant="filled"
|
|
26
|
+
color="blue"
|
|
27
|
+
onClick={handleClick}
|
|
28
|
+
>
|
|
29
|
+
Submit
|
|
30
|
+
</Button>
|
|
31
|
+
|
|
32
|
+
// Bad - multiple attributes on same line
|
|
33
|
+
<Button variant="filled" color="blue" onClick={handleClick}>Submit</Button>
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
## Code Examples
|
|
37
|
+
|
|
38
|
+
```javascript
|
|
39
|
+
// Good
|
|
40
|
+
const getUserData = async id => {
|
|
41
|
+
const response = await fetch(`/api/users/${id}`)
|
|
42
|
+
return response.json()
|
|
43
|
+
}
|
|
44
|
+
|
|
45
|
+
const config = {
|
|
46
|
+
apiUrl: 'https://api.example.com',
|
|
47
|
+
timeout: 5000,
|
|
48
|
+
retries: 3,
|
|
49
|
+
}
|
|
50
|
+
|
|
51
|
+
// Bad
|
|
52
|
+
const getUserData = async (id) => {
|
|
53
|
+
const response = await fetch("/api/users/" + id);
|
|
54
|
+
return response.json();
|
|
55
|
+
};
|
|
56
|
+
|
|
57
|
+
const config = {apiUrl: "https://api.example.com", timeout: 5000, retries: 3}
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
## Object and Array Formatting
|
|
61
|
+
|
|
62
|
+
```javascript
|
|
63
|
+
// Good - trailing comma
|
|
64
|
+
const options = {
|
|
65
|
+
name: 'app',
|
|
66
|
+
version: '1.0.0',
|
|
67
|
+
debug: true,
|
|
68
|
+
}
|
|
69
|
+
|
|
70
|
+
const items = [
|
|
71
|
+
'first',
|
|
72
|
+
'second',
|
|
73
|
+
'third',
|
|
74
|
+
]
|
|
75
|
+
|
|
76
|
+
// Bad - no trailing comma
|
|
77
|
+
const options = {
|
|
78
|
+
name: 'app',
|
|
79
|
+
version: '1.0.0',
|
|
80
|
+
debug: true
|
|
81
|
+
}
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
## Import Organization
|
|
85
|
+
|
|
86
|
+
```javascript
|
|
87
|
+
// 1. External dependencies
|
|
88
|
+
import { useState, useEffect } from 'react'
|
|
89
|
+
import { Button, Text } from '@mantine/core'
|
|
90
|
+
|
|
91
|
+
// 2. Internal modules
|
|
92
|
+
import { useAuth } from '@/hooks/useAuth'
|
|
93
|
+
import { api } from '@/services/api'
|
|
94
|
+
|
|
95
|
+
// 3. Components
|
|
96
|
+
import { Header } from '@/components/Header'
|
|
97
|
+
|
|
98
|
+
// 4. Styles, assets, types (if any)
|
|
99
|
+
import styles from './styles.module.css'
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
## Prettier Config Reference
|
|
103
|
+
|
|
104
|
+
```json
|
|
105
|
+
{
|
|
106
|
+
"printWidth": 300,
|
|
107
|
+
"singleAttributePerLine": true,
|
|
108
|
+
"tabWidth": 4,
|
|
109
|
+
"useTabs": false,
|
|
110
|
+
"semi": false,
|
|
111
|
+
"singleQuote": true,
|
|
112
|
+
"quoteProps": "as-needed",
|
|
113
|
+
"trailingComma": "es5",
|
|
114
|
+
"bracketSpacing": true,
|
|
115
|
+
"bracketSameLine": false,
|
|
116
|
+
"arrowParens": "avoid",
|
|
117
|
+
"endOfLine": "lf"
|
|
118
|
+
}
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
## Auto-Format
|
|
122
|
+
|
|
123
|
+
Run Prettier before committing:
|
|
124
|
+
|
|
125
|
+
```bash
|
|
126
|
+
bunx prettier --write .
|
|
127
|
+
```
|
|
@@ -1,18 +1,96 @@
|
|
|
1
|
-
# Conventional Commits
|
|
1
|
+
# Conventional Commits
|
|
2
2
|
|
|
3
|
-
All commits
|
|
3
|
+
All commits must follow the Conventional Commits specification for automated releases and changelogs.
|
|
4
4
|
|
|
5
5
|
## Format
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
```
|
|
8
|
+
<type>(<scope>): <description>
|
|
8
9
|
|
|
9
|
-
|
|
10
|
+
[optional body]
|
|
10
11
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
12
|
+
[optional footer(s)]
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
## Types and Version Bumps
|
|
16
|
+
|
|
17
|
+
| Type | Description | Version Bump |
|
|
18
|
+
| --- | --- | --- |
|
|
19
|
+
| `feat` | New feature | MINOR |
|
|
20
|
+
| `fix` | Bug fix | PATCH |
|
|
21
|
+
| `docs` | Documentation changes | PATCH (if scope: README) |
|
|
22
|
+
| `style` | Code style (formatting, no logic change) | PATCH |
|
|
23
|
+
| `refactor` | Code refactoring (no new feature, no fix) | PATCH |
|
|
24
|
+
| `perf` | Performance improvement | PATCH |
|
|
25
|
+
| `test` | Adding or fixing tests | No release |
|
|
26
|
+
| `chore` | Build process, dependencies, tooling | No release |
|
|
27
|
+
| `chore(release)` | Automated release commits | No release (skip CI) |
|
|
28
|
+
|
|
29
|
+
## Breaking Changes
|
|
30
|
+
|
|
31
|
+
For MAJOR version bumps, add `BREAKING CHANGE:` in the footer or `!` after type:
|
|
32
|
+
|
|
33
|
+
```
|
|
34
|
+
feat!: remove deprecated API endpoints
|
|
35
|
+
|
|
36
|
+
BREAKING CHANGE: The /v1/users endpoint has been removed. Use /v2/users instead.
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
## Scope (Optional)
|
|
40
|
+
|
|
41
|
+
Scope provides context. Common scopes:
|
|
42
|
+
|
|
43
|
+
- `feat(auth)`: Authentication feature
|
|
44
|
+
- `fix(api)`: API bug fix
|
|
45
|
+
- `docs(README)`: README update
|
|
46
|
+
- `refactor(components)`: Component refactoring
|
|
47
|
+
|
|
48
|
+
## Examples
|
|
49
|
+
|
|
50
|
+
```bash
|
|
51
|
+
# Feature (MINOR bump)
|
|
52
|
+
feat: add dark mode toggle to settings
|
|
53
|
+
|
|
54
|
+
# Bug fix (PATCH bump)
|
|
55
|
+
fix: resolve race condition in form submission
|
|
56
|
+
|
|
57
|
+
# Documentation (PATCH bump if README)
|
|
58
|
+
docs(README): update installation instructions
|
|
59
|
+
|
|
60
|
+
# Refactor (PATCH bump)
|
|
61
|
+
refactor: extract validation logic to separate module
|
|
62
|
+
|
|
63
|
+
# Style (PATCH bump)
|
|
64
|
+
style: format code with prettier
|
|
65
|
+
|
|
66
|
+
# Chore (no release)
|
|
67
|
+
chore: update dependencies
|
|
68
|
+
|
|
69
|
+
# Breaking change (MAJOR bump)
|
|
70
|
+
feat!: redesign authentication flow
|
|
71
|
+
|
|
72
|
+
BREAKING CHANGE: Session tokens now use JWT format.
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
## Branches
|
|
76
|
+
|
|
77
|
+
| Branch | Release Type | Tag |
|
|
78
|
+
| --- | --- | --- |
|
|
79
|
+
| `prod` | Production release | `v1.2.3` |
|
|
80
|
+
| `main` | Pre-release | `v1.2.3-rc.1` |
|
|
81
|
+
|
|
82
|
+
## Quick Reference
|
|
83
|
+
|
|
84
|
+
```bash
|
|
85
|
+
# Good
|
|
86
|
+
feat: add user profile page
|
|
87
|
+
fix(auth): handle expired tokens gracefully
|
|
88
|
+
docs: update API documentation
|
|
89
|
+
refactor(utils): simplify date formatting
|
|
90
|
+
|
|
91
|
+
# Bad
|
|
92
|
+
added new feature # no type
|
|
93
|
+
feat add something # missing colon
|
|
94
|
+
Feat: Add Something # wrong case
|
|
95
|
+
feat(): empty scope # don't use empty scope
|
|
96
|
+
```
|
|
@@ -0,0 +1,116 @@
|
|
|
1
|
+
# JavaScript Only
|
|
2
|
+
|
|
3
|
+
RiLiGar projects use **JavaScript ES6+ exclusively**. TypeScript is prohibited.
|
|
4
|
+
|
|
5
|
+
## Why No TypeScript
|
|
6
|
+
|
|
7
|
+
- **Simplicity** — Less tooling, faster builds, no compilation step
|
|
8
|
+
- **Bun Native** — Bun runs JavaScript directly with excellent performance
|
|
9
|
+
- **Reduced Complexity** — No type gymnastics, no `any` escapes, no config overhead
|
|
10
|
+
- **Runtime Validation** — Use runtime checks where needed (Zod, validators)
|
|
11
|
+
|
|
12
|
+
## Allowed
|
|
13
|
+
|
|
14
|
+
```javascript
|
|
15
|
+
// Modern JavaScript ES6+
|
|
16
|
+
const fetchUser = async id => {
|
|
17
|
+
const response = await fetch(`/api/users/${id}`)
|
|
18
|
+
return response.json()
|
|
19
|
+
}
|
|
20
|
+
|
|
21
|
+
// Destructuring
|
|
22
|
+
const { name, email } = user
|
|
23
|
+
|
|
24
|
+
// Spread operator
|
|
25
|
+
const newConfig = { ...config, debug: true }
|
|
26
|
+
|
|
27
|
+
// Optional chaining
|
|
28
|
+
const city = user?.address?.city
|
|
29
|
+
|
|
30
|
+
// Nullish coalescing
|
|
31
|
+
const value = input ?? 'default'
|
|
32
|
+
|
|
33
|
+
// Array methods
|
|
34
|
+
const names = users.map(u => u.name).filter(Boolean)
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## Prohibited
|
|
38
|
+
|
|
39
|
+
```typescript
|
|
40
|
+
// NO TypeScript files
|
|
41
|
+
// ❌ .ts, .tsx files
|
|
42
|
+
// ❌ tsconfig.json
|
|
43
|
+
// ❌ Type annotations
|
|
44
|
+
|
|
45
|
+
// Bad
|
|
46
|
+
const fetchUser = async (id: string): Promise<User> => { ... }
|
|
47
|
+
interface User { name: string; email: string }
|
|
48
|
+
type Status = 'active' | 'inactive'
|
|
49
|
+
|
|
50
|
+
// Good (JavaScript)
|
|
51
|
+
const fetchUser = async id => { ... }
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
## File Extensions
|
|
55
|
+
|
|
56
|
+
| Allowed | Prohibited |
|
|
57
|
+
| --- | --- |
|
|
58
|
+
| `.js` | `.ts` |
|
|
59
|
+
| `.jsx` | `.tsx` |
|
|
60
|
+
| `.mjs` | `.mts` |
|
|
61
|
+
| `.cjs` | `.cts` |
|
|
62
|
+
|
|
63
|
+
## Runtime Validation (When Needed)
|
|
64
|
+
|
|
65
|
+
For API boundaries or user input, use runtime validation:
|
|
66
|
+
|
|
67
|
+
```javascript
|
|
68
|
+
// Using Zod for runtime validation
|
|
69
|
+
import { z } from 'zod'
|
|
70
|
+
|
|
71
|
+
const UserSchema = z.object({
|
|
72
|
+
name: z.string().min(1),
|
|
73
|
+
email: z.string().email(),
|
|
74
|
+
age: z.number().optional(),
|
|
75
|
+
})
|
|
76
|
+
|
|
77
|
+
const validateUser = data => {
|
|
78
|
+
return UserSchema.parse(data)
|
|
79
|
+
}
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
## JSDoc (Optional)
|
|
83
|
+
|
|
84
|
+
If documentation is needed, use JSDoc comments:
|
|
85
|
+
|
|
86
|
+
```javascript
|
|
87
|
+
/**
|
|
88
|
+
* Fetches user data from the API
|
|
89
|
+
* @param {string} id - The user ID
|
|
90
|
+
* @returns {Promise<Object>} The user data
|
|
91
|
+
*/
|
|
92
|
+
const fetchUser = async id => {
|
|
93
|
+
const response = await fetch(`/api/users/${id}`)
|
|
94
|
+
return response.json()
|
|
95
|
+
}
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
## IDE Support
|
|
99
|
+
|
|
100
|
+
For better IDE experience without TypeScript:
|
|
101
|
+
|
|
102
|
+
1. Use JSDoc annotations where helpful
|
|
103
|
+
2. Configure VS Code `jsconfig.json` for path aliases
|
|
104
|
+
3. Rely on Prettier for consistent formatting
|
|
105
|
+
|
|
106
|
+
```json
|
|
107
|
+
// jsconfig.json
|
|
108
|
+
{
|
|
109
|
+
"compilerOptions": {
|
|
110
|
+
"baseUrl": ".",
|
|
111
|
+
"paths": {
|
|
112
|
+
"@/*": ["src/*"]
|
|
113
|
+
}
|
|
114
|
+
}
|
|
115
|
+
}
|
|
116
|
+
```
|
|
@@ -0,0 +1,168 @@
|
|
|
1
|
+
# Naming Conventions
|
|
2
|
+
|
|
3
|
+
Consistent naming across all RiLiGar projects.
|
|
4
|
+
|
|
5
|
+
## Quick Reference
|
|
6
|
+
|
|
7
|
+
| Element | Convention | Example |
|
|
8
|
+
| --- | --- | --- |
|
|
9
|
+
| Components | PascalCase | `UserProfile`, `NavBar` |
|
|
10
|
+
| Functions | camelCase | `getUserData`, `handleSubmit` |
|
|
11
|
+
| Variables | camelCase | `userName`, `isLoading` |
|
|
12
|
+
| Constants | SCREAMING_SNAKE | `API_URL`, `MAX_RETRIES` |
|
|
13
|
+
| Files (components) | PascalCase | `UserProfile.jsx` |
|
|
14
|
+
| Files (utilities) | camelCase | `formatDate.js` |
|
|
15
|
+
| Directories | kebab-case | `user-profile/`, `api-utils/` |
|
|
16
|
+
| CSS classes | kebab-case | `nav-bar`, `user-card` |
|
|
17
|
+
| Database tables | snake_case | `user_profiles`, `order_items` |
|
|
18
|
+
| API endpoints | kebab-case | `/api/user-profiles`, `/api/order-items` |
|
|
19
|
+
|
|
20
|
+
## Components
|
|
21
|
+
|
|
22
|
+
```javascript
|
|
23
|
+
// File: UserProfile.jsx
|
|
24
|
+
// Component name matches file name
|
|
25
|
+
|
|
26
|
+
// Good
|
|
27
|
+
const UserProfile = ({ user }) => {
|
|
28
|
+
return <div>{user.name}</div>
|
|
29
|
+
}
|
|
30
|
+
|
|
31
|
+
export default UserProfile
|
|
32
|
+
|
|
33
|
+
// Bad
|
|
34
|
+
const userProfile = ({ user }) => { ... } // lowercase
|
|
35
|
+
const User_Profile = ({ user }) => { ... } // underscore
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
## Functions and Variables
|
|
39
|
+
|
|
40
|
+
```javascript
|
|
41
|
+
// Good
|
|
42
|
+
const getUserById = async id => { ... }
|
|
43
|
+
const isAuthenticated = true
|
|
44
|
+
const handleFormSubmit = event => { ... }
|
|
45
|
+
const totalItemCount = items.length
|
|
46
|
+
|
|
47
|
+
// Bad
|
|
48
|
+
const GetUserById = async id => { ... } // PascalCase
|
|
49
|
+
const is_authenticated = true // snake_case
|
|
50
|
+
const handle_form_submit = event => { ... } // snake_case
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
## Constants
|
|
54
|
+
|
|
55
|
+
```javascript
|
|
56
|
+
// Good
|
|
57
|
+
const API_BASE_URL = 'https://api.example.com'
|
|
58
|
+
const MAX_RETRY_ATTEMPTS = 3
|
|
59
|
+
const DEFAULT_PAGE_SIZE = 20
|
|
60
|
+
|
|
61
|
+
// Bad
|
|
62
|
+
const apiBaseUrl = 'https://api.example.com' // camelCase
|
|
63
|
+
const maxRetryAttempts = 3 // camelCase
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
## Booleans
|
|
67
|
+
|
|
68
|
+
Prefix with `is`, `has`, `can`, `should`:
|
|
69
|
+
|
|
70
|
+
```javascript
|
|
71
|
+
// Good
|
|
72
|
+
const isLoading = true
|
|
73
|
+
const hasPermission = user.role === 'admin'
|
|
74
|
+
const canEdit = hasPermission && !isLocked
|
|
75
|
+
const shouldRefresh = lastUpdate < threshold
|
|
76
|
+
|
|
77
|
+
// Bad
|
|
78
|
+
const loading = true
|
|
79
|
+
const permission = true
|
|
80
|
+
const edit = true
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
## Event Handlers
|
|
84
|
+
|
|
85
|
+
Prefix with `handle` or `on`:
|
|
86
|
+
|
|
87
|
+
```javascript
|
|
88
|
+
// In component definition - use "handle"
|
|
89
|
+
const handleClick = () => { ... }
|
|
90
|
+
const handleSubmit = event => { ... }
|
|
91
|
+
const handleInputChange = value => { ... }
|
|
92
|
+
|
|
93
|
+
// In props - use "on"
|
|
94
|
+
<Button onClick={handleClick} />
|
|
95
|
+
<Form onSubmit={handleSubmit} />
|
|
96
|
+
<Input onChange={handleInputChange} />
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
## Hooks
|
|
100
|
+
|
|
101
|
+
Prefix with `use`:
|
|
102
|
+
|
|
103
|
+
```javascript
|
|
104
|
+
// Good
|
|
105
|
+
const useAuth = () => { ... }
|
|
106
|
+
const useLocalStorage = key => { ... }
|
|
107
|
+
const useFetch = url => { ... }
|
|
108
|
+
|
|
109
|
+
// Bad
|
|
110
|
+
const auth = () => { ... }
|
|
111
|
+
const getFromLocalStorage = key => { ... }
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
## Directory Structure
|
|
115
|
+
|
|
116
|
+
```
|
|
117
|
+
src/
|
|
118
|
+
├── components/ # kebab-case directories
|
|
119
|
+
│ ├── user-profile/
|
|
120
|
+
│ │ ├── UserProfile.jsx # PascalCase component
|
|
121
|
+
│ │ └── UserAvatar.jsx
|
|
122
|
+
│ └── nav-bar/
|
|
123
|
+
│ └── NavBar.jsx
|
|
124
|
+
├── hooks/
|
|
125
|
+
│ ├── useAuth.js # camelCase hook files
|
|
126
|
+
│ └── useFetch.js
|
|
127
|
+
├── utils/
|
|
128
|
+
│ ├── formatDate.js # camelCase utility files
|
|
129
|
+
│ └── validateEmail.js
|
|
130
|
+
└── services/
|
|
131
|
+
└── api.js
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
## Database and API
|
|
135
|
+
|
|
136
|
+
```javascript
|
|
137
|
+
// Database tables - snake_case
|
|
138
|
+
// user_profiles, order_items, payment_transactions
|
|
139
|
+
|
|
140
|
+
// API endpoints - kebab-case
|
|
141
|
+
// GET /api/user-profiles
|
|
142
|
+
// POST /api/order-items
|
|
143
|
+
// GET /api/payment-transactions/:id
|
|
144
|
+
|
|
145
|
+
// API response keys - camelCase (for JavaScript consumption)
|
|
146
|
+
{
|
|
147
|
+
"userId": 123,
|
|
148
|
+
"userName": "john",
|
|
149
|
+
"createdAt": "2024-01-01"
|
|
150
|
+
}
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
## Abbreviations
|
|
154
|
+
|
|
155
|
+
Treat abbreviations as words:
|
|
156
|
+
|
|
157
|
+
```javascript
|
|
158
|
+
// Good
|
|
159
|
+
const userId = 123
|
|
160
|
+
const apiUrl = '/api'
|
|
161
|
+
const htmlContent = '<div>...</div>'
|
|
162
|
+
const xmlParser = new Parser()
|
|
163
|
+
|
|
164
|
+
// Bad
|
|
165
|
+
const userID = 123 // ID should be Id
|
|
166
|
+
const APIURL = '/api' // Should be ApiUrl
|
|
167
|
+
const HTMLContent = '<div>...</div>'
|
|
168
|
+
```
|
|
@@ -0,0 +1,121 @@
|
|
|
1
|
+
# Pull Request Guidelines
|
|
2
|
+
|
|
3
|
+
Standards for creating and reviewing Pull Requests in RiLiGar projects.
|
|
4
|
+
|
|
5
|
+
## PR Title
|
|
6
|
+
|
|
7
|
+
Follow Conventional Commits format:
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
<type>(<scope>): <description>
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
Examples:
|
|
14
|
+
- `feat(auth): add magic link authentication`
|
|
15
|
+
- `fix(api): handle timeout errors gracefully`
|
|
16
|
+
- `refactor(components): extract shared button styles`
|
|
17
|
+
|
|
18
|
+
## PR Description Template
|
|
19
|
+
|
|
20
|
+
```markdown
|
|
21
|
+
## Summary
|
|
22
|
+
<!-- 1-3 bullet points describing what this PR does -->
|
|
23
|
+
|
|
24
|
+
- Add magic link authentication flow
|
|
25
|
+
- Create email template for magic links
|
|
26
|
+
- Update auth middleware to handle magic tokens
|
|
27
|
+
|
|
28
|
+
## Test Plan
|
|
29
|
+
<!-- How to verify this PR works -->
|
|
30
|
+
|
|
31
|
+
- [ ] Sign up with email and verify magic link arrives
|
|
32
|
+
- [ ] Click magic link and verify redirect to dashboard
|
|
33
|
+
- [ ] Verify expired links show appropriate error
|
|
34
|
+
- [ ] Test on mobile browsers
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## PR Size
|
|
38
|
+
|
|
39
|
+
Keep PRs small and focused:
|
|
40
|
+
|
|
41
|
+
| Size | Lines Changed | Recommendation |
|
|
42
|
+
| --- | --- | --- |
|
|
43
|
+
| Small | < 100 | Ideal |
|
|
44
|
+
| Medium | 100-300 | Acceptable |
|
|
45
|
+
| Large | 300-500 | Split if possible |
|
|
46
|
+
| Too Large | > 500 | Must split |
|
|
47
|
+
|
|
48
|
+
## Branch Naming
|
|
49
|
+
|
|
50
|
+
```
|
|
51
|
+
<type>/<short-description>
|
|
52
|
+
|
|
53
|
+
feat/magic-link-auth
|
|
54
|
+
fix/timeout-handling
|
|
55
|
+
refactor/button-components
|
|
56
|
+
docs/api-documentation
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
## Checklist Before Submitting
|
|
60
|
+
|
|
61
|
+
```markdown
|
|
62
|
+
- [ ] Code follows RiLiGar style guidelines
|
|
63
|
+
- [ ] No TypeScript (JavaScript only)
|
|
64
|
+
- [ ] Prettier formatting applied
|
|
65
|
+
- [ ] No console.log or debug code
|
|
66
|
+
- [ ] Tests pass locally
|
|
67
|
+
- [ ] Self-reviewed the diff
|
|
68
|
+
- [ ] PR title follows Conventional Commits
|
|
69
|
+
- [ ] Description includes test plan
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
## Review Process
|
|
73
|
+
|
|
74
|
+
### For Authors
|
|
75
|
+
|
|
76
|
+
1. **Self-review first** — Read your own diff before requesting review
|
|
77
|
+
2. **Small PRs** — Easier to review, faster to merge
|
|
78
|
+
3. **Clear description** — Explain the "why", not just the "what"
|
|
79
|
+
4. **Respond promptly** — Address feedback within 24 hours
|
|
80
|
+
|
|
81
|
+
### For Reviewers
|
|
82
|
+
|
|
83
|
+
1. **Be constructive** — Suggest improvements, don't just criticize
|
|
84
|
+
2. **Ask questions** — If something is unclear, ask
|
|
85
|
+
3. **Approve when ready** — Don't block on nitpicks
|
|
86
|
+
4. **Review within 24h** — Keep the flow moving
|
|
87
|
+
|
|
88
|
+
## Comment Prefixes
|
|
89
|
+
|
|
90
|
+
Use prefixes to clarify intent:
|
|
91
|
+
|
|
92
|
+
| Prefix | Meaning |
|
|
93
|
+
| --- | --- |
|
|
94
|
+
| `nit:` | Minor suggestion, non-blocking |
|
|
95
|
+
| `question:` | Seeking clarification |
|
|
96
|
+
| `suggestion:` | Alternative approach to consider |
|
|
97
|
+
| `issue:` | Must be addressed before merge |
|
|
98
|
+
| `praise:` | Highlighting good code |
|
|
99
|
+
|
|
100
|
+
Examples:
|
|
101
|
+
```
|
|
102
|
+
nit: Could rename this to `fetchUserData` for clarity
|
|
103
|
+
|
|
104
|
+
question: Is there a reason we're not using the existing `useAuth` hook here?
|
|
105
|
+
|
|
106
|
+
issue: This will cause a memory leak - need to cleanup the subscription
|
|
107
|
+
|
|
108
|
+
praise: Nice use of early returns here, very readable!
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
## Merge Strategy
|
|
112
|
+
|
|
113
|
+
- **Squash and merge** — Default for feature branches
|
|
114
|
+
- **Merge commit** — For release branches
|
|
115
|
+
- **Rebase** — Avoid (rewrites history)
|
|
116
|
+
|
|
117
|
+
## After Merge
|
|
118
|
+
|
|
119
|
+
1. Delete the feature branch
|
|
120
|
+
2. Verify deployment (if applicable)
|
|
121
|
+
3. Close related issues
|
|
@@ -1,8 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-business-startup-analyst
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
allowed-tools: Read Write Edit Glob Grep Bash WebSearch WebFetch
|
|
3
|
+
type: business
|
|
4
|
+
description: Generate comprehensive investor-ready business case document with market, solution, financials, and strategy. Use when creating business cases for fundraising or strategic planning.
|
|
6
5
|
---
|
|
7
6
|
|
|
8
7
|
# Business Case Generator
|
|
@@ -1,8 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-business-startup-financial
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
allowed-tools: Read Write Edit Glob Grep Bash WebSearch WebFetch
|
|
3
|
+
type: business
|
|
4
|
+
description: Create detailed 3-5 year financial model with revenue, costs, cash flow, and scenarios. Use when building financial projections for startups or fundraising.
|
|
6
5
|
---
|
|
7
6
|
|
|
8
7
|
# Financial Projections
|
|
@@ -1,8 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-business-startup-market
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
allowed-tools: Read Write Edit Glob Grep Bash WebSearch WebFetch
|
|
3
|
+
type: business
|
|
4
|
+
description: Generate comprehensive market opportunity analysis with TAM/SAM/SOM calculations. Use when analyzing market size and opportunity for startups.
|
|
6
5
|
---
|
|
7
6
|
|
|
8
7
|
# Market Opportunity Analysis
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-design-system
|
|
3
|
+
type: design
|
|
3
4
|
description: Especialista no Sistema Visual da RiLiGar. Use para: (1) Criação de interfaces web e mobile (Light/Dark Mode), (2) Implementação de componentes UI (Mantine Only), (3) Garantir estética minimalista "Content-First", (4) Aplicar tokens de design via Mantine Theme.
|
|
4
|
-
license: Apache-2.0
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# RiLiGar Design System Expert
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-dev-architecture
|
|
3
|
+
type: development
|
|
3
4
|
description: Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.
|
|
4
|
-
allowed-tools: Read, Glob, Grep
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Architecture Decision Framework
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-dev-auth-elysia
|
|
3
|
+
type: development
|
|
3
4
|
description: 'Comprehensive guide for integrating the Riligar Auth Elysia SDK into backend servers. Use when a user needs to: (1) Set up a backend auth plugin, (2) Configure Elysia with Riligar Secret Key, (3) Protect API routes or groups, (4) Access authenticated user data in handlers, (5) Perform manual JWT verification.'
|
|
4
5
|
---
|
|
5
6
|
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-dev-auth-react
|
|
3
|
+
type: development
|
|
3
4
|
description: 'Comprehensive guide for integrating the Riligar Auth React SDK into web applications. Use when a user needs to: (1) Set up authentication from scratch, (2) Configure AuthProvider, (3) Implement route protection, (4) Use auth hooks or pre-built UI components, (5) Handle login/signup/profile/magic links in React.'
|
|
4
5
|
---
|
|
5
6
|
|
|
@@ -1,10 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-dev-autopilot
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
metadata:
|
|
6
|
-
author: riligar
|
|
7
|
-
version: '1.0'
|
|
3
|
+
type: development
|
|
4
|
+
description: Automação do ciclo de vida de desenvolvimento. Validação com Bun, Auto-correção, Commit Semântico e Deploy. Use para garantir código funcional e entregue em produção.
|
|
8
5
|
---
|
|
9
6
|
|
|
10
7
|
# RiLiGar Dev-Autopilot Expert
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: riligar-dev-
|
|
3
|
-
|
|
4
|
-
|
|
2
|
+
name: riligar-dev-backend
|
|
3
|
+
type: development
|
|
4
|
+
description: API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination. Use when designing APIs or backend services.
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# API Patterns
|
|
@@ -1,9 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-dev-clean-code
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
version: 2.1
|
|
6
|
-
priority: CRITICAL
|
|
3
|
+
type: development
|
|
4
|
+
description: Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments. CRITICAL skill that defines RiLiGar coding standards. Use when writing or reviewing any code.
|
|
7
5
|
---
|
|
8
6
|
|
|
9
7
|
# Clean Code - Pragmatic AI Coding Standards (RiLiGar)
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-dev-code-review
|
|
3
|
-
|
|
4
|
-
|
|
3
|
+
type: development
|
|
4
|
+
description: Code review guidelines covering code quality, security, and best practices. Use when reviewing code or creating review checklists.
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Code Review Checklist
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-dev-database
|
|
3
|
-
|
|
4
|
-
|
|
3
|
+
type: development
|
|
4
|
+
description: Database design principles and decision-making. Schema design, indexing strategy, ORM selection, serverless databases. Use when designing schemas or optimizing database performance.
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Database Design
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: riligar-dev-
|
|
3
|
-
|
|
4
|
-
|
|
2
|
+
name: riligar-dev-frontend
|
|
3
|
+
type: development
|
|
4
|
+
description: Modern React patterns and principles. Hooks, composition, performance, and JavaScript best practices. Use when building React components, managing state, or implementing UI patterns.
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# React Patterns
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-dev-landing-page
|
|
3
|
+
type: development
|
|
3
4
|
description: Specialist in High-Conversion Landing Pages using RiLiGar Design System. Use for: (1) Creating marketing/sales pages, (2) Structuring conversion flows (AIDA/PAS), (3) Implementing high-trust components (Hero, Social Proof, Pricing), (4) Writing persuasive copy.
|
|
4
|
-
license: Apache-2.0
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# RiLiGar Landing Page Architect
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-dev-seo
|
|
3
|
-
|
|
4
|
-
|
|
3
|
+
type: development
|
|
4
|
+
description: Implementação de infraestrutura de SEO técnico seguindo a stack RiLiGar (React, Vite, Bun, Elysia). Use para configurar sitemaps, robots.txt, meta tags, OpenGraph, dados estruturados (JSON-LD) e URLs canônicas.
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# SEO Técnico (RiLiGar Tech Stack)
|
|
@@ -0,0 +1,152 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: riligar-dev-stripe
|
|
3
|
+
type: development
|
|
4
|
+
description: Stripe payment integration patterns. Use when implementing payments, subscriptions, webhooks, checkout flows, or billing in Elysia/Bun applications.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Stripe Integration Patterns
|
|
8
|
+
|
|
9
|
+
> Patterns for integrating Stripe payments in RiLiGar applications.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Mandatory Guidelines
|
|
14
|
+
|
|
15
|
+
> [!IMPORTANT]
|
|
16
|
+
> All work in this skill MUST adhere to:
|
|
17
|
+
>
|
|
18
|
+
> - @[.agent/skills/riligar-dev-backend] (API Standards)
|
|
19
|
+
> - @[.agent/skills/riligar-dev-clean-code] (Clean Code Standards)
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## 1. Core Concepts
|
|
24
|
+
|
|
25
|
+
| Concept | Description |
|
|
26
|
+
| --- | --- |
|
|
27
|
+
| **Customer** | User identity in Stripe |
|
|
28
|
+
| **Product** | What you're selling |
|
|
29
|
+
| **Price** | How much and billing cycle |
|
|
30
|
+
| **Subscription** | Recurring payment |
|
|
31
|
+
| **PaymentIntent** | One-time payment |
|
|
32
|
+
| **Webhook** | Event notifications |
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## 2. Environment Setup
|
|
37
|
+
|
|
38
|
+
```bash
|
|
39
|
+
# .env
|
|
40
|
+
STRIPE_SECRET_KEY=sk_live_...
|
|
41
|
+
STRIPE_WEBHOOK_SECRET=whsec_...
|
|
42
|
+
STRIPE_PUBLISHABLE_KEY=pk_live_...
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
> [!IMPORTANT]
|
|
46
|
+
> Never expose `STRIPE_SECRET_KEY` in frontend code.
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## 3. Server-Side Patterns (Elysia)
|
|
51
|
+
|
|
52
|
+
### Initialize Stripe
|
|
53
|
+
|
|
54
|
+
```javascript
|
|
55
|
+
import Stripe from 'stripe'
|
|
56
|
+
|
|
57
|
+
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY)
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
### Create Checkout Session
|
|
61
|
+
|
|
62
|
+
```javascript
|
|
63
|
+
const session = await stripe.checkout.sessions.create({
|
|
64
|
+
mode: 'subscription',
|
|
65
|
+
customer_email: user.email,
|
|
66
|
+
line_items: [{ price: priceId, quantity: 1 }],
|
|
67
|
+
success_url: `${baseUrl}/success?session_id={CHECKOUT_SESSION_ID}`,
|
|
68
|
+
cancel_url: `${baseUrl}/cancel`,
|
|
69
|
+
})
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
### Webhook Handler
|
|
73
|
+
|
|
74
|
+
```javascript
|
|
75
|
+
app.post('/webhook/stripe', async ({ request, set }) => {
|
|
76
|
+
const sig = request.headers.get('stripe-signature')
|
|
77
|
+
const body = await request.text()
|
|
78
|
+
|
|
79
|
+
const event = stripe.webhooks.constructEvent(
|
|
80
|
+
body,
|
|
81
|
+
sig,
|
|
82
|
+
process.env.STRIPE_WEBHOOK_SECRET
|
|
83
|
+
)
|
|
84
|
+
|
|
85
|
+
switch (event.type) {
|
|
86
|
+
case 'checkout.session.completed':
|
|
87
|
+
await handleCheckoutComplete(event.data.object)
|
|
88
|
+
break
|
|
89
|
+
case 'customer.subscription.updated':
|
|
90
|
+
await handleSubscriptionUpdate(event.data.object)
|
|
91
|
+
break
|
|
92
|
+
case 'customer.subscription.deleted':
|
|
93
|
+
await handleSubscriptionCancel(event.data.object)
|
|
94
|
+
break
|
|
95
|
+
}
|
|
96
|
+
|
|
97
|
+
return { received: true }
|
|
98
|
+
})
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
## 4. Essential Webhooks
|
|
104
|
+
|
|
105
|
+
| Event | When to Handle |
|
|
106
|
+
| --- | --- |
|
|
107
|
+
| `checkout.session.completed` | Provision access after payment |
|
|
108
|
+
| `customer.subscription.updated` | Plan changes, renewals |
|
|
109
|
+
| `customer.subscription.deleted` | Cancellation |
|
|
110
|
+
| `invoice.payment_failed` | Payment issues |
|
|
111
|
+
| `invoice.paid` | Successful recurring payment |
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## 5. Customer Portal
|
|
116
|
+
|
|
117
|
+
```javascript
|
|
118
|
+
const portalSession = await stripe.billingPortal.sessions.create({
|
|
119
|
+
customer: customerId,
|
|
120
|
+
return_url: `${baseUrl}/account`,
|
|
121
|
+
})
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
---
|
|
125
|
+
|
|
126
|
+
## 6. Security Checklist
|
|
127
|
+
|
|
128
|
+
- [ ] Verify webhook signatures
|
|
129
|
+
- [ ] Use idempotency keys for retries
|
|
130
|
+
- [ ] Store customer ID in database
|
|
131
|
+
- [ ] Handle edge cases (expired cards, disputes)
|
|
132
|
+
- [ ] Test with Stripe CLI locally
|
|
133
|
+
|
|
134
|
+
---
|
|
135
|
+
|
|
136
|
+
## 7. Testing
|
|
137
|
+
|
|
138
|
+
```bash
|
|
139
|
+
# Install Stripe CLI
|
|
140
|
+
brew install stripe/stripe-cli/stripe
|
|
141
|
+
|
|
142
|
+
# Forward webhooks to local server
|
|
143
|
+
stripe listen --forward-to localhost:3000/webhook/stripe
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
---
|
|
147
|
+
|
|
148
|
+
## Related Skills
|
|
149
|
+
|
|
150
|
+
- @[.agent/skills/riligar-dev-backend]
|
|
151
|
+
- @[.agent/skills/riligar-dev-auth-elysia]
|
|
152
|
+
- @[.agent/skills/riligar-tech-stack]
|
|
@@ -1,10 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-infrastructure
|
|
3
|
+
type: infrastructure
|
|
3
4
|
description: Especialista em Infraestrutura da RiLiGar. Use para configurar deployments no Fly.io, DNS e proxying no Cloudflare, e garantir padrões de infraestrutura e deployment.
|
|
4
|
-
license: Apache-2.0
|
|
5
|
-
metadata:
|
|
6
|
-
author: riligar
|
|
7
|
-
version: '1.0'
|
|
8
5
|
---
|
|
9
6
|
|
|
10
7
|
# RiLiGar Infrastructure Expert
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-marketing-copy
|
|
3
|
-
|
|
4
|
-
|
|
3
|
+
type: marketing
|
|
4
|
+
description: Generate compelling marketing copy using the Elevated Direct Response framework. Use when creating landing pages, headlines, email campaigns, ad copy, CTAs, value propositions, or any persuasive marketing content.
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Elevated Direct Response Copywriter
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: email
|
|
3
|
-
|
|
2
|
+
name: riligar-marketing-email
|
|
3
|
+
type: marketing
|
|
4
|
+
description: Email sequence design and optimization. Use when creating drip campaigns, automated flows, nurture sequences, onboarding emails, welcome sequences, re-engagement emails, or lifecycle email programs.
|
|
4
5
|
---
|
|
5
6
|
|
|
6
7
|
# Email Sequence Design
|
|
@@ -1,12 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-marketing-seo
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
at scale using templates and structured data. Use when the user mentions
|
|
6
|
-
programmatic SEO, pages at scale, template pages, directory pages, location pages,
|
|
7
|
-
comparison pages, integration pages, or keyword-pattern page generation.
|
|
8
|
-
This skill focuses on feasibility, strategy, and page system design—not execution
|
|
9
|
-
unless explicitly requested.
|
|
3
|
+
type: marketing
|
|
4
|
+
description: Design and evaluate programmatic SEO strategies for creating SEO-driven pages at scale. Use when working with programmatic SEO, template pages, directory pages, location pages, or keyword-pattern page generation.
|
|
10
5
|
---
|
|
11
6
|
|
|
12
7
|
---
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-plan-writing
|
|
3
|
+
type: development
|
|
3
4
|
description: Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.
|
|
4
|
-
allowed-tools: Read, Glob, Grep
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Plan Writing
|
|
@@ -1,10 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: riligar-tech-stack
|
|
3
|
+
type: development
|
|
3
4
|
description: Especialista na Tech Stack da RiLiGar. Use para criar projetos React/Vite, componentes com Mantine, APIs Bun/Elysia, e garantir padrões de código e estrutura de projetos.
|
|
4
|
-
license: Apache-2.0
|
|
5
|
-
metadata:
|
|
6
|
-
author: riligar
|
|
7
|
-
version: '1.0'
|
|
8
5
|
---
|
|
9
6
|
|
|
10
7
|
# RiLiGar Tech Stack Expert
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: skill-creator
|
|
3
|
-
|
|
4
|
-
|
|
3
|
+
type: meta
|
|
4
|
+
description: Guide for creating effective skills. Use when creating a new skill or updating an existing skill that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Skill Creator
|
|
@@ -53,6 +53,7 @@ skill-name/
|
|
|
53
53
|
├── SKILL.md (required)
|
|
54
54
|
│ ├── YAML frontmatter metadata (required)
|
|
55
55
|
│ │ ├── name: (required)
|
|
56
|
+
│ │ ├── type: (required)
|
|
56
57
|
│ │ └── description: (required)
|
|
57
58
|
│ └── Markdown instructions (required)
|
|
58
59
|
└── Bundled Resources (optional)
|
|
@@ -61,11 +62,30 @@ skill-name/
|
|
|
61
62
|
└── assets/ - Files used in output (templates, icons, fonts, etc.)
|
|
62
63
|
```
|
|
63
64
|
|
|
65
|
+
### Skill Types (Taxonomy)
|
|
66
|
+
|
|
67
|
+
Every skill must have a `type` field that categorizes it. This enables organization, filtering, and discovery.
|
|
68
|
+
|
|
69
|
+
| Type | Description | Naming Pattern |
|
|
70
|
+
| --- | --- | --- |
|
|
71
|
+
| `development` | Software development skills (frontend, backend, database, architecture, auth, testing) | `riligar-dev-*` |
|
|
72
|
+
| `design` | UI/UX and visual design skills | `riligar-design-*` |
|
|
73
|
+
| `marketing` | Copywriting, email, SEO, and content marketing | `riligar-marketing-*` |
|
|
74
|
+
| `business` | Business analysis, financial modeling, market research | `riligar-business-*` |
|
|
75
|
+
| `infrastructure` | Deployment, DNS, hosting, DevOps | `riligar-infrastructure` |
|
|
76
|
+
| `meta` | Skills about skills (this skill) | `skill-creator` |
|
|
77
|
+
|
|
78
|
+
**Naming Convention:**
|
|
79
|
+
|
|
80
|
+
- Directory name MUST match the `name` field in frontmatter
|
|
81
|
+
- Use pattern: `riligar-{type}-{specific-name}`
|
|
82
|
+
- Examples: `riligar-dev-frontend`, `riligar-marketing-copy`, `riligar-business-startup-analyst`
|
|
83
|
+
|
|
64
84
|
#### SKILL.md (required)
|
|
65
85
|
|
|
66
86
|
Every SKILL.md consists of:
|
|
67
87
|
|
|
68
|
-
- **Frontmatter** (YAML): Contains `name` and `description` fields. These are the only fields that Claude reads to determine when the skill gets used, thus it is very important to be clear and comprehensive in describing what the skill is, and when it should be used.
|
|
88
|
+
- **Frontmatter** (YAML): Contains `name`, `type`, and `description` fields. These are the only fields that Claude reads to determine when the skill gets used, thus it is very important to be clear and comprehensive in describing what the skill is, and when it should be used.
|
|
69
89
|
- **Body** (Markdown): Instructions and guidance for using the skill. Only loaded AFTER the skill triggers (if at all).
|
|
70
90
|
|
|
71
91
|
#### Bundled Resources (optional)
|
|
@@ -303,15 +323,26 @@ Any example files and directories not needed for the skill should be deleted. Th
|
|
|
303
323
|
|
|
304
324
|
##### Frontmatter
|
|
305
325
|
|
|
306
|
-
Write the YAML frontmatter with `name` and `description`:
|
|
326
|
+
Write the YAML frontmatter with `name`, `type`, and `description`:
|
|
307
327
|
|
|
308
|
-
- `name`: The skill name
|
|
328
|
+
- `name`: The skill name (must match directory name)
|
|
329
|
+
- `type`: The skill category (see Skill Types taxonomy above)
|
|
309
330
|
- `description`: This is the primary triggering mechanism for your skill, and helps Claude understand when to use the skill.
|
|
310
331
|
- Include both what the Skill does and specific triggers/contexts for when to use it.
|
|
311
332
|
- Include all "when to use" information here - Not in the body. The body is only loaded after triggering, so "When to Use This Skill" sections in the body are not helpful to Claude.
|
|
312
333
|
- Example description for a `docx` skill: "Comprehensive document creation, editing, and analysis with support for tracked changes, comments, formatting preservation, and text extraction. Use when Claude needs to work with professional documents (.docx files) for: (1) Creating new documents, (2) Modifying or editing content, (3) Working with tracked changes, (4) Adding comments, or any other document tasks"
|
|
313
334
|
|
|
314
|
-
|
|
335
|
+
**Example frontmatter:**
|
|
336
|
+
|
|
337
|
+
```yaml
|
|
338
|
+
---
|
|
339
|
+
name: riligar-dev-example
|
|
340
|
+
type: development
|
|
341
|
+
description: Brief description of what the skill does. Use when [specific triggers].
|
|
342
|
+
---
|
|
343
|
+
```
|
|
344
|
+
|
|
345
|
+
Do not include any other fields in YAML frontmatter (no `allowed-tools`, `license`, `metadata`, `version`, etc.).
|
|
315
346
|
|
|
316
347
|
##### Body
|
|
317
348
|
|