@p_tipso/agentive 1.1.0 → 1.1.2
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/README.md
CHANGED
|
@@ -99,17 +99,12 @@ We love contributions! Whether it's adding new built-in skills, fixing bugs, or
|
|
|
99
99
|
|
|
100
100
|
Please read our [Contributing Guide](CONTRIBUTING.md) to get started with setting up your local environment and submitting a Pull Request.
|
|
101
101
|
|
|
102
|
+
|
|
102
103
|
---
|
|
103
104
|
|
|
104
105
|
## ⭐ Star History
|
|
105
106
|
|
|
106
|
-
|
|
107
|
-
<picture>
|
|
108
|
-
<source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/svg?repos=TiPS0/agentive&type=Date&theme=dark" />
|
|
109
|
-
<source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/svg?repos=TiPS0/agentive&type=Date" />
|
|
110
|
-
<img alt="Star History Chart" src="https://api.star-history.com/svg?repos=TiPS0/agentive&type=Date" />
|
|
111
|
-
</picture>
|
|
112
|
-
</a>
|
|
107
|
+
[](https://star-history.com/#TiPS0/agentive&Date)
|
|
113
108
|
|
|
114
109
|
---
|
|
115
110
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@p_tipso/agentive",
|
|
3
|
-
"version": "1.1.
|
|
3
|
+
"version": "1.1.2",
|
|
4
4
|
"description": "A universal, framework-agnostic AI agent repository setup CLI. Scaffold a .agents/ workspace, AGENTS.md, and .aiignore to sync and optimize context for Cursor, Claude, and Windsurf.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"author": "Pakawat Tipso",
|
package/src/commands/init.js
CHANGED
|
@@ -39,7 +39,7 @@ async function runInit() {
|
|
|
39
39
|
message: 'What type of project are you building?',
|
|
40
40
|
choices: [
|
|
41
41
|
{ title: 'General / Universal', value: 'general' },
|
|
42
|
-
{ title: 'Web Development', value: 'web'
|
|
42
|
+
{ title: 'Web Development', value: 'web' },
|
|
43
43
|
{ title: 'Mobile Development', value: 'mobile' },
|
|
44
44
|
],
|
|
45
45
|
initial: 0,
|
|
@@ -51,18 +51,35 @@ async function runInit() {
|
|
|
51
51
|
}
|
|
52
52
|
|
|
53
53
|
let framework = null;
|
|
54
|
-
if (typeResponse.projectType === '
|
|
54
|
+
if (typeResponse.projectType === 'web') {
|
|
55
|
+
const fwResponse = await prompts({
|
|
56
|
+
type: 'select',
|
|
57
|
+
name: 'framework',
|
|
58
|
+
message: 'Which framework are you using?',
|
|
59
|
+
choices: [
|
|
60
|
+
{ title: 'Next.js', value: 'nextjs' },
|
|
61
|
+
{ title: 'Nuxt', value: 'nuxt' },
|
|
62
|
+
],
|
|
63
|
+
initial: 0,
|
|
64
|
+
});
|
|
65
|
+
|
|
66
|
+
if (!fwResponse.framework) {
|
|
67
|
+
console.log(chalk.red(' ✖ ') + 'Setup cancelled.');
|
|
68
|
+
process.exit(1);
|
|
69
|
+
}
|
|
70
|
+
framework = fwResponse.framework;
|
|
71
|
+
} else if (typeResponse.projectType === 'mobile') {
|
|
55
72
|
const fwResponse = await prompts({
|
|
56
73
|
type: 'select',
|
|
57
74
|
name: 'framework',
|
|
58
75
|
message: 'Which framework are you using?',
|
|
59
76
|
choices: [
|
|
60
77
|
{ title: 'Expo (Recommended)', value: 'expo' },
|
|
61
|
-
{ title: 'React Native', value: 'react-native' },
|
|
78
|
+
{ title: 'React Native', value: 'react-native', disabled: true },
|
|
62
79
|
],
|
|
63
80
|
initial: 0,
|
|
64
81
|
});
|
|
65
|
-
|
|
82
|
+
|
|
66
83
|
if (!fwResponse.framework) {
|
|
67
84
|
console.log(chalk.red(' ✖ ') + 'Setup cancelled.');
|
|
68
85
|
process.exit(1);
|
|
@@ -4,26 +4,51 @@ This folder contains **skill definitions** — instructions that teach AI agents
|
|
|
4
4
|
|
|
5
5
|
## How to use
|
|
6
6
|
|
|
7
|
-
Each
|
|
7
|
+
Each skill lives in its **own subfolder**, named after the skill. The folder must contain a `SKILL.md` file as its entry point.
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
```
|
|
10
|
+
.agents/skills/
|
|
11
|
+
├── route-groups-setup/
|
|
12
|
+
│ └── SKILL.md
|
|
13
|
+
├── create-expo-app/
|
|
14
|
+
│ └── SKILL.md
|
|
15
|
+
└── my-custom-skill/
|
|
16
|
+
└── SKILL.md
|
|
17
|
+
```
|
|
10
18
|
|
|
11
|
-
|
|
19
|
+
IDE and CLI tools that support slash-commands will autocomplete the folder name, then load the `SKILL.md` inside it (e.g., typing `/route-groups-setup` activates that skill).
|
|
12
20
|
|
|
13
|
-
|
|
14
|
-
- **Responsibilities:** Specific tasks the agent handles
|
|
15
|
-
- **Inputs / Outputs:** What the agent expects and what it produces
|
|
16
|
-
- **Constraints:** Boundaries the agent must respect
|
|
21
|
+
## SKILL.md Structure
|
|
17
22
|
|
|
18
|
-
|
|
23
|
+
Each `SKILL.md` file must include a YAML frontmatter block at the top:
|
|
19
24
|
|
|
20
|
-
|
|
25
|
+
```markdown
|
|
26
|
+
---
|
|
27
|
+
name: my-skill-name
|
|
28
|
+
description: A short description of what this skill does.
|
|
29
|
+
version: 1.0.0
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
# Skill instructions go here...
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
- **`name`** and **`description`** are required — they are used for skill discovery and autocomplete matching.
|
|
36
|
+
- The body (below the frontmatter) contains the actual instructions the agent follows when the skill is activated.
|
|
37
|
+
|
|
38
|
+
## Skill Folder Layout
|
|
39
|
+
|
|
40
|
+
A skill folder can include optional subdirectories for more complex skills:
|
|
41
|
+
|
|
42
|
+
| Path | Purpose |
|
|
21
43
|
|------|---------|
|
|
22
|
-
| `
|
|
23
|
-
| `
|
|
24
|
-
| `
|
|
25
|
-
| `
|
|
44
|
+
| `SKILL.md` | *(Required)* Main instructions with YAML frontmatter |
|
|
45
|
+
| `scripts/` | Helper scripts the agent can run |
|
|
46
|
+
| `examples/` | Reference implementations or usage patterns |
|
|
47
|
+
| `resources/` | Templates, assets, or additional files |
|
|
48
|
+
| `references/` | Extra documentation the agent can read on demand |
|
|
26
49
|
|
|
27
50
|
## Adding new skills
|
|
28
51
|
|
|
29
|
-
Create a new
|
|
52
|
+
1. Create a new folder under `.agents/skills/` named after your skill (e.g., `api-designer/`)
|
|
53
|
+
2. Add a `SKILL.md` file inside it with the required frontmatter
|
|
54
|
+
3. Describe the agent's role, responsibilities, and constraints in the body
|
|
@@ -0,0 +1,110 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: route-groups-setup
|
|
3
|
+
description: Guidelines for enforcing the Route Groups pattern across modern file-based routing frameworks (Next.js, Expo Router, Nuxt).
|
|
4
|
+
version: 1.1.0
|
|
5
|
+
updated_at: 2026-07-10
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Modern File-Based Routing Guidelines
|
|
9
|
+
|
|
10
|
+
**CRITICAL INSTRUCTION FOR AI AGENTS**: When working with modern meta-frameworks (e.g., **Next.js**, **Expo Router**, or **Nuxt**) in this workspace, you must enforce a clean routing structure using **Route Groups**. This applies regardless of the specific framework or version.
|
|
11
|
+
|
|
12
|
+
## Route Groups Context
|
|
13
|
+
|
|
14
|
+
Route Groups (directories named with parentheses, like `(tabs)`, `(auth)`, or `(marketing)`) allow you to organize files and share layouts without adding a segment to the URL path.
|
|
15
|
+
|
|
16
|
+
As projects grow, a flat file-based routing structure can quickly become messy and hard to maintain. To prevent this, the modern standard is to use Route Groups to keep the routing directory organized, modular, and clean.
|
|
17
|
+
|
|
18
|
+
## The Standard Routing Pattern
|
|
19
|
+
|
|
20
|
+
You must strictly enforce the following rules for routing:
|
|
21
|
+
|
|
22
|
+
### 1. Structural Requirements
|
|
23
|
+
|
|
24
|
+
- **Root Directory**: The routing root is `app/` or `src/app/` (Next.js App Router, Expo Router). _Note: These rules do not apply to the legacy Next.js `pages/` router._
|
|
25
|
+
- **Global Layouts**: Base files like `index.tsx`, `page.tsx`, `_layout.tsx`, `layout.tsx`, and `+not-found.tsx` MUST remain at the root of the routing directory.
|
|
26
|
+
- **Top-Level Feature Modules**: ALL distinct top-level feature modules or screen sections MUST be wrapped in parentheses `()` to form a Route Group.
|
|
27
|
+
- **DO NOT** create flat static directories at the root level (e.g., `app/profile/index.tsx`).
|
|
28
|
+
- **DO** create Route Group directories for top-level features (e.g., `app/(profile)/index.tsx`).
|
|
29
|
+
- _Note: Normal static folders are completely fine INSIDE a Route Group when you specifically need to add a URL segment._
|
|
30
|
+
- **Consistency**: Ensure that layouts and screens for a specific feature are contained entirely within their respective Route Group directory.
|
|
31
|
+
|
|
32
|
+
#### ⚠️ Critical Rule — Route Groups Are Invisible in the URL
|
|
33
|
+
|
|
34
|
+
Route Groups `(name)` are **completely ignored** in the final URL path. They exist purely for layout organization. This has a critical implication for dynamic routes:
|
|
35
|
+
|
|
36
|
+
- **DO NOT** place two dynamic segments at the same URL depth using nested Route Groups.
|
|
37
|
+
- ❌ `app/(shop)/[storeId].tsx` + `app/(shop)/(product)/[productId].tsx` → **Both resolve to `/:id` — URL collision!**
|
|
38
|
+
- **DO** chain dynamic segments directly by nesting them, or use static folders to separate them.
|
|
39
|
+
- ✅ `app/(shop)/[storeId]/[productId]/page.tsx` → URLs: `/:storeId` and `/:storeId/:productId`
|
|
40
|
+
|
|
41
|
+
### 2. Folder Naming Conventions (Quick Matrix)
|
|
42
|
+
|
|
43
|
+
You must understand the exact differences between folder types to construct valid routes:
|
|
44
|
+
|
|
45
|
+
| Folder Pattern | URL Impact | Type | Best Used For |
|
|
46
|
+
| -------------- | -------------------- | ----------------- | ------------------------------------------------------------------------ |
|
|
47
|
+
| `(groupName)/` | **None (Hidden)** | **Route Group** | Organizing code by feature or sharing layouts (e.g., `(auth)`) |
|
|
48
|
+
| `folderName/` | Exact Match | **Static Route** | Fixed pages with hardcoded URLs (e.g., `dashboard`, `shop`) |
|
|
49
|
+
| `[paramName]/` | Variable Placeholder | **Dynamic Route** | Dynamic data pages matching IDs or slugs (e.g., `[userId]`, `[storeId]`) |
|
|
50
|
+
|
|
51
|
+
### 3. The Purpose of Layout Files (`_layout.tsx` / `layout.tsx`)
|
|
52
|
+
|
|
53
|
+
Layout files are crucial in Route Groups. Even though the Route Group folder `(groupName)` is invisible in the URL, the routing framework relies on the `_layout.tsx` file inside it to know _how_ to render the screens it contains.
|
|
54
|
+
|
|
55
|
+
**Why it is needed:**
|
|
56
|
+
Without a layout file (`_layout.tsx` in Expo returning a `<Stack />`, or `layout.tsx` in Next.js returning `{children}`), the framework won't know how to render the screens or provide navigation between them (e.g., it won't know how to slide screens in or provide a back button).
|
|
57
|
+
|
|
58
|
+
**Advanced Use Cases:**
|
|
59
|
+
|
|
60
|
+
1. **Shared Context Providers**: If you build a state manager that only applies to specific screens (e.g., `<ShopStateProvider>`), wrap it inside `(shop)/layout.tsx` so it doesn't degrade performance for the rest of the app.
|
|
61
|
+
2. **Auth Guards**: You can enforce security at the folder level. Checking `if (!isAuthenticated)` inside `(dashboard)/layout.tsx` instantly protects every screen inside the dashboard folder (like the profile page).
|
|
62
|
+
3. **Shared UI**: Use the layout file to inject a custom header, footer, or navigation bar that applies to every screen in that specific Route Group.
|
|
63
|
+
|
|
64
|
+
### 4. Example Valid Directory Tree
|
|
65
|
+
|
|
66
|
+
```text
|
|
67
|
+
app/ (or src/app/)
|
|
68
|
+
├── _layout.tsx (or layout.tsx)
|
|
69
|
+
├── index.tsx (or page.tsx)
|
|
70
|
+
│
|
|
71
|
+
├── (auth)/ ← Route Group: shared auth layout
|
|
72
|
+
│ ├── _layout.tsx (or layout.tsx)
|
|
73
|
+
│ └── login.tsx → URL: /login
|
|
74
|
+
│
|
|
75
|
+
├── (tabs)/ ← Route Group: tab bar layout
|
|
76
|
+
│ ├── _layout.tsx (or layout.tsx)
|
|
77
|
+
│ ├── dashboard.tsx → URL: /dashboard
|
|
78
|
+
│ └── shop.tsx → URL: /shop (tab entry point)
|
|
79
|
+
│
|
|
80
|
+
├── (dashboard)/ ← Route Group: dashboard layout
|
|
81
|
+
│ ├── _layout.tsx (or layout.tsx)
|
|
82
|
+
│ └── profile.tsx → URL: /profile
|
|
83
|
+
│
|
|
84
|
+
└── (shop)/ ← Route Group: shared shop layout (URL-invisible)
|
|
85
|
+
├── _layout.tsx (or layout.tsx)
|
|
86
|
+
└── [storeId]/ ← Dynamic folder → URL: /:storeId
|
|
87
|
+
├── index.tsx (or page.tsx) → URL: /123
|
|
88
|
+
└── [productId]/ ← Nested dynamic folder → URL: /:storeId/:productId
|
|
89
|
+
└── index.tsx (or page.tsx) → URL: /123/456
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
**How the shop flow works:**
|
|
93
|
+
|
|
94
|
+
1. `(tabs)/shop.tsx` → the tab that shows the store list (`/shop`)
|
|
95
|
+
2. User selects a store → navigates to `(shop)/[storeId]/index.tsx` → URL: `/123`
|
|
96
|
+
3. User selects a product → navigates to `(shop)/[storeId]/[productId]/index.tsx` → URL: `/123/456`
|
|
97
|
+
|
|
98
|
+
The `(shop)` Route Group provides a **shared layout** (e.g., a back-button header) for both the store and product screens, without polluting the URL.
|
|
99
|
+
|
|
100
|
+
**Important File Naming Note:**
|
|
101
|
+
When using dynamic folders like `[storeId]`, always name the main entry file `index.tsx` (Expo Router) or `page.tsx` (Next.js). Do NOT name the file `storeId.tsx` inside the `[storeId]` folder, as that would result in an awkward URL like `/123/storeId`.
|
|
102
|
+
|
|
103
|
+
## Required Agent Workflow for Routing Tasks
|
|
104
|
+
|
|
105
|
+
Whenever you are asked to create, modify, or debug routes/screens, you must execute these steps:
|
|
106
|
+
|
|
107
|
+
1. **Identify the Framework**: Check `package.json` to determine if the project uses Next.js, Expo, Remix, or Nuxt, and note the correct file naming conventions (`page.tsx`, `index.tsx`, `index.vue`).
|
|
108
|
+
2. **Verify the Structure**: Check the `app/` or `src/app/` directory to understand the existing root.
|
|
109
|
+
3. **Enforce Route Groups**: Ensure that top-level feature modules are created exclusively inside parentheses `(group_name)`. You are FORBIDDEN from creating new standard flat folder routes directly at the root of `app/` (e.g., `app/home/`).
|
|
110
|
+
4. **Refactor if Necessary**: If you encounter an existing flat routing structure at the root (e.g., `app/home/`), you MUST transition it to the standard Route Group pattern (e.g., `app/(home)/`) before adding new features.
|
package/src/utils/fileSystem.js
CHANGED
|
@@ -42,8 +42,6 @@ async function createAgentDirectory(cwd, overwrite = false) {
|
|
|
42
42
|
|
|
43
43
|
if (overwrite) {
|
|
44
44
|
await fs.rm(agentsDir, { recursive: true, force: true });
|
|
45
|
-
// Also remove old AGENTS.md if overwriting
|
|
46
|
-
try { await fs.rm(path.join(cwd, 'AGENTS.md'), { force: true }); } catch { /* noop */ }
|
|
47
45
|
}
|
|
48
46
|
|
|
49
47
|
await fs.mkdir(agentsDir, { recursive: true });
|
|
@@ -130,10 +128,21 @@ async function copyTemplates(templatesDir, agentsDir, projectName, projectType =
|
|
|
130
128
|
|
|
131
129
|
// 1. Copy AGENTS.md from base to project root
|
|
132
130
|
const agentMdSrc = path.join(templatesDir, 'base', 'AGENTS.md');
|
|
131
|
+
const targetAgentMdPath = path.join(cwd, 'AGENTS.md');
|
|
133
132
|
try {
|
|
134
133
|
let content = await fs.readFile(agentMdSrc, 'utf-8');
|
|
135
134
|
content = replacePlaceholders(content, projectName);
|
|
136
|
-
|
|
135
|
+
|
|
136
|
+
let finalContent = content;
|
|
137
|
+
try {
|
|
138
|
+
const existingContent = await fs.readFile(targetAgentMdPath, 'utf-8');
|
|
139
|
+
if (existingContent.trim()) {
|
|
140
|
+
// Prepend the new template content to the existing content
|
|
141
|
+
finalContent = content + '\n\n' + existingContent;
|
|
142
|
+
}
|
|
143
|
+
} catch { /* target may not exist, that's fine */ }
|
|
144
|
+
|
|
145
|
+
await fs.writeFile(targetAgentMdPath, finalContent, 'utf-8');
|
|
137
146
|
} catch { /* template may not exist */ }
|
|
138
147
|
|
|
139
148
|
// 1.5 Copy aiignore from base to project root as .aiignore
|