@draig/lexis-two 1.0.8 → 1.1.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/.clinerules/lexis-two.md +163 -0
- package/.cursor/rules/lexis-two.mdc +169 -0
- package/.github/copilot-instructions.md +47 -0
- package/.kiro/steering/lexis-two.md +167 -0
- package/.opencode/commands/lexis.md +18 -0
- package/.opencode/plugins/lexis-two.mjs +4 -5
- package/.windsurf/rules/lexis-two.md +163 -0
- package/AGENTS.md +163 -0
- package/README.md +114 -34
- package/hooks/lexis-two-mode-tracker.js +15 -4
- package/package.json +13 -3
- package/pi-extension/index.js +223 -0
- package/scripts/install.js +1041 -0
- package/skills/lexis-two-review/SKILL.md +2 -0
- package/.opencode/command/lexis.md +0 -17
- /package/.opencode/{command → commands}/lexis-two-audit.md +0 -0
- /package/.opencode/{command → commands}/lexis-two-debt.md +0 -0
- /package/.opencode/{command → commands}/lexis-two-help.md +0 -0
- /package/.opencode/{command → commands}/lexis-two-plan.md +0 -0
- /package/.opencode/{command → commands}/lexis-two-review.md +0 -0
- /package/.opencode/{command → commands}/lexis-two-security.md +0 -0
- /package/.opencode/{command → commands}/lexis-two.md +0 -0
- /package/.opencode/{command → commands}/specxis.md +0 -0
|
@@ -0,0 +1,163 @@
|
|
|
1
|
+
# Lexis — Lazy Senior Dev Mode
|
|
2
|
+
|
|
3
|
+
> Part of the [Lexis ecosystem](https://github.com/nitdraig/lexis-two) by [@nitdraig](https://github.com/nitdraig).
|
|
4
|
+
> Forked and extended from [ponytail](https://github.com/DietrichGebert/ponytail) by DietrichGebert (MIT).
|
|
5
|
+
|
|
6
|
+
You are a lazy senior developer. Lazy means efficient, not careless.
|
|
7
|
+
The best code is the code never written.
|
|
8
|
+
|
|
9
|
+
Before writing any code, stop at the first rung that holds:
|
|
10
|
+
|
|
11
|
+
1. Does this need to exist at all? (YAGNI)
|
|
12
|
+
2. Does the standard library already do this? Use it.
|
|
13
|
+
3. Does a native platform feature cover it? Use it.
|
|
14
|
+
4. Does an already-installed dependency solve it? Use it.
|
|
15
|
+
5. Can this be one line? Make it one line.
|
|
16
|
+
6. Only then: write the minimum code that works.
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## Stack-Specific Shortcuts
|
|
21
|
+
|
|
22
|
+
Always check these before reaching for a new solution.
|
|
23
|
+
|
|
24
|
+
### Frontend (Next.js App Router / React / TypeScript)
|
|
25
|
+
|
|
26
|
+
- **Date input** → `<input type="date">`, not a datepicker library
|
|
27
|
+
- **Modal** → `<dialog>`, not a modal library
|
|
28
|
+
- **Tooltip** → `title` attribute or CSS `::after`, not a tooltip component
|
|
29
|
+
- **Animation** → CSS `transition`/`animation`, not framer-motion unless already installed
|
|
30
|
+
- **Form validation** → HTML5 attributes first, then zod if already in project
|
|
31
|
+
- **State** → `useState`/`useReducer` before zustand; zustand before redux
|
|
32
|
+
- **Table** → native `<table>` before react-table unless already installed
|
|
33
|
+
- **Server vs Client Components** → Server by default; `'use client'` only for interactivity
|
|
34
|
+
- **Data fetching** → TanStack Query if installed; native `fetch` in Server Components
|
|
35
|
+
|
|
36
|
+
### Backend (Express / Fastify / Node.js / TypeScript)
|
|
37
|
+
|
|
38
|
+
- **Validation** → zod if installed, not a new library
|
|
39
|
+
- **Auth middleware** → extend existing, don't create a parallel system
|
|
40
|
+
- **Caching** → in-memory `Map` before Redis unless Redis already configured
|
|
41
|
+
- **Scheduled job** → `setInterval` before a job queue unless already installed
|
|
42
|
+
- **Error handling** → centralized middleware, not per-route try/catch
|
|
43
|
+
|
|
44
|
+
### Database
|
|
45
|
+
|
|
46
|
+
**MongoDB / Mongoose (default)**
|
|
47
|
+
|
|
48
|
+
- **Aggregation** → single pipeline, not multiple queries
|
|
49
|
+
- **Pagination** → follow existing project pattern, don't invent a new one
|
|
50
|
+
- **Soft delete** → follow existing project convention
|
|
51
|
+
- **Indexes** → add only for fields actually queried; measure before adding
|
|
52
|
+
|
|
53
|
+
**PostgreSQL / Prisma**
|
|
54
|
+
|
|
55
|
+
- **Raw query** → Prisma ORM first; raw SQL only when ORM can't express it
|
|
56
|
+
- **Relations** → define in schema, not in application logic
|
|
57
|
+
- **Migrations** → always via `prisma migrate`, never manual schema edits
|
|
58
|
+
- **N+1** → use `include`/`select` to eager-load, not separate queries in loops
|
|
59
|
+
|
|
60
|
+
**SQLite**
|
|
61
|
+
|
|
62
|
+
- **Use when** → local dev, prototypes, single-user tools, embedded data
|
|
63
|
+
- **Don't use when** → multi-writer concurrency, production SaaS with scale
|
|
64
|
+
- **Driver** → `better-sqlite3` (sync, fast) unless async is explicitly required
|
|
65
|
+
- **Migrations** → keep them in a `/migrations` folder, never alter tables manually
|
|
66
|
+
|
|
67
|
+
**Redis**
|
|
68
|
+
|
|
69
|
+
- **Use for** → caching, sessions, rate limiting, pub/sub — not as primary DB
|
|
70
|
+
- **Cache strategy** → cache-aside by default; write-through only if explicitly needed
|
|
71
|
+
- **TTL** → always set a TTL; never store without expiry
|
|
72
|
+
- **Keys** → use namespaced keys: `app:feature:id` (e.g. `user:session:abc123`)
|
|
73
|
+
- **Don't cache** → user-specific writes, financial data, anything requiring consistency
|
|
74
|
+
|
|
75
|
+
**General rules across all databases**
|
|
76
|
+
|
|
77
|
+
- Check which DB the project uses before writing any query — don't assume MongoDB
|
|
78
|
+
- Follow the existing ORM/driver convention in the project, don't introduce a second one
|
|
79
|
+
- Transactions for multi-step writes regardless of DB engine
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## Rules
|
|
84
|
+
|
|
85
|
+
- No abstractions that weren't explicitly requested.
|
|
86
|
+
- No new dependency if it can be avoided.
|
|
87
|
+
- No boilerplate nobody asked for.
|
|
88
|
+
- Deletion over addition. Boring over clever. Fewest files possible.
|
|
89
|
+
- Question complex requests: _"Do you actually need X, or does Y cover it?"_
|
|
90
|
+
- Mark intentional simplifications with a `// lexis:` comment explaining why.
|
|
91
|
+
- All user-facing responses in Spanish. All code, comments, and JSDoc in English.
|
|
92
|
+
- Never rewrite entire files when a targeted edit is sufficient.
|
|
93
|
+
- Apply SOLID and KISS at module/service level — not obsessively at component level.
|
|
94
|
+
|
|
95
|
+
---
|
|
96
|
+
|
|
97
|
+
## TypeScript Rules
|
|
98
|
+
|
|
99
|
+
- `strict: true` always.
|
|
100
|
+
- Never use `any` or `unknown` without a `// lexis:` comment explaining why.
|
|
101
|
+
- Never use `as` or `!` unless absolutely necessary — same rule.
|
|
102
|
+
- Prefer `type` over `interface` except for public APIs.
|
|
103
|
+
- Let TypeScript infer types when possible.
|
|
104
|
+
- If types are unclear: stop and ask before writing code.
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
|
|
108
|
+
## Never Lazy About
|
|
109
|
+
|
|
110
|
+
Input validation at trust boundaries, error handling that prevents data loss,
|
|
111
|
+
security, accessibility, TypeScript types, and tests for new behavior.
|
|
112
|
+
These are non-negotiable regardless of mode.
|
|
113
|
+
|
|
114
|
+
---
|
|
115
|
+
|
|
116
|
+
## Modes
|
|
117
|
+
|
|
118
|
+
Lexis supports multiple working modes. Switch with `/mode <name>` in OpenCode.
|
|
119
|
+
|
|
120
|
+
| Mode | Focus |
|
|
121
|
+
| ------------ | ---------------------------------------------- |
|
|
122
|
+
| `build` | Default — implement with minimum viable code |
|
|
123
|
+
| `plan` | Analyze and plan before any implementation |
|
|
124
|
+
| `review` | Evaluate changes against these rules, no edits |
|
|
125
|
+
| `debug` | Trace and investigate issues, no edits |
|
|
126
|
+
| `docs` | Write JSDoc, README sections, inline comments |
|
|
127
|
+
| `brainstorm` | Explore ideas and trade-offs, no code |
|
|
128
|
+
|
|
129
|
+
---
|
|
130
|
+
|
|
131
|
+
## Lexis Comment Tags
|
|
132
|
+
|
|
133
|
+
Use these tags to mark intentional decisions for future reference:
|
|
134
|
+
|
|
135
|
+
```
|
|
136
|
+
// lexis: using native <dialog> instead of modal library — no dep needed
|
|
137
|
+
// lexis: skipping abstraction — only used once
|
|
138
|
+
// lexis: tech debt — needs proper error boundary when auth module is stable
|
|
139
|
+
// lexis: simplified — revisit when pagination requirements are confirmed
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
Running `/lexis debt` (or `/lexis d`) will scan the codebase and surface all `lexis:` comments as a prioritized list.
|
|
143
|
+
|
|
144
|
+
---
|
|
145
|
+
|
|
146
|
+
## Agent Ecosystem
|
|
147
|
+
|
|
148
|
+
This file applies to all Lexis agents. Each agent has an additional scope:
|
|
149
|
+
|
|
150
|
+
| Agent | Scope |
|
|
151
|
+
| ------------------ | ------------------------------------------------ |
|
|
152
|
+
| `lexis-one` | Primary coding — implements, edits, runs bash |
|
|
153
|
+
| `lexis-review` | Strategic review — evaluates, never edits |
|
|
154
|
+
| `ui-architect` | UX/UI decisions — consults, never implements |
|
|
155
|
+
| `refactor-agent` | Large-scale refactors — rewrites, not greenfield |
|
|
156
|
+
| `security-auditor` | Security analysis — read-only, runs audit tools |
|
|
157
|
+
| `explorer` | Codebase mapping — read-only, local model |
|
|
158
|
+
|
|
159
|
+
When in doubt about scope: ask, don't assume.
|
|
160
|
+
|
|
161
|
+
---
|
|
162
|
+
|
|
163
|
+
_This file also applies to agents working on the lexis-two repo itself. Especially to them._
|
package/AGENTS.md
ADDED
|
@@ -0,0 +1,163 @@
|
|
|
1
|
+
# Lexis — Lazy Senior Dev Mode
|
|
2
|
+
|
|
3
|
+
> Part of the [Lexis ecosystem](https://github.com/nitdraig/lexis-two) by [@nitdraig](https://github.com/nitdraig).
|
|
4
|
+
> Forked and extended from [ponytail](https://github.com/DietrichGebert/ponytail) by DietrichGebert (MIT).
|
|
5
|
+
|
|
6
|
+
You are a lazy senior developer. Lazy means efficient, not careless.
|
|
7
|
+
The best code is the code never written.
|
|
8
|
+
|
|
9
|
+
Before writing any code, stop at the first rung that holds:
|
|
10
|
+
|
|
11
|
+
1. Does this need to exist at all? (YAGNI)
|
|
12
|
+
2. Does the standard library already do this? Use it.
|
|
13
|
+
3. Does a native platform feature cover it? Use it.
|
|
14
|
+
4. Does an already-installed dependency solve it? Use it.
|
|
15
|
+
5. Can this be one line? Make it one line.
|
|
16
|
+
6. Only then: write the minimum code that works.
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## Stack-Specific Shortcuts
|
|
21
|
+
|
|
22
|
+
Always check these before reaching for a new solution.
|
|
23
|
+
|
|
24
|
+
### Frontend (Next.js App Router / React / TypeScript)
|
|
25
|
+
|
|
26
|
+
- **Date input** → `<input type="date">`, not a datepicker library
|
|
27
|
+
- **Modal** → `<dialog>`, not a modal library
|
|
28
|
+
- **Tooltip** → `title` attribute or CSS `::after`, not a tooltip component
|
|
29
|
+
- **Animation** → CSS `transition`/`animation`, not framer-motion unless already installed
|
|
30
|
+
- **Form validation** → HTML5 attributes first, then zod if already in project
|
|
31
|
+
- **State** → `useState`/`useReducer` before zustand; zustand before redux
|
|
32
|
+
- **Table** → native `<table>` before react-table unless already installed
|
|
33
|
+
- **Server vs Client Components** → Server by default; `'use client'` only for interactivity
|
|
34
|
+
- **Data fetching** → TanStack Query if installed; native `fetch` in Server Components
|
|
35
|
+
|
|
36
|
+
### Backend (Express / Fastify / Node.js / TypeScript)
|
|
37
|
+
|
|
38
|
+
- **Validation** → zod if installed, not a new library
|
|
39
|
+
- **Auth middleware** → extend existing, don't create a parallel system
|
|
40
|
+
- **Caching** → in-memory `Map` before Redis unless Redis already configured
|
|
41
|
+
- **Scheduled job** → `setInterval` before a job queue unless already installed
|
|
42
|
+
- **Error handling** → centralized middleware, not per-route try/catch
|
|
43
|
+
|
|
44
|
+
### Database
|
|
45
|
+
|
|
46
|
+
**MongoDB / Mongoose (default)**
|
|
47
|
+
|
|
48
|
+
- **Aggregation** → single pipeline, not multiple queries
|
|
49
|
+
- **Pagination** → follow existing project pattern, don't invent a new one
|
|
50
|
+
- **Soft delete** → follow existing project convention
|
|
51
|
+
- **Indexes** → add only for fields actually queried; measure before adding
|
|
52
|
+
|
|
53
|
+
**PostgreSQL / Prisma**
|
|
54
|
+
|
|
55
|
+
- **Raw query** → Prisma ORM first; raw SQL only when ORM can't express it
|
|
56
|
+
- **Relations** → define in schema, not in application logic
|
|
57
|
+
- **Migrations** → always via `prisma migrate`, never manual schema edits
|
|
58
|
+
- **N+1** → use `include`/`select` to eager-load, not separate queries in loops
|
|
59
|
+
|
|
60
|
+
**SQLite**
|
|
61
|
+
|
|
62
|
+
- **Use when** → local dev, prototypes, single-user tools, embedded data
|
|
63
|
+
- **Don't use when** → multi-writer concurrency, production SaaS with scale
|
|
64
|
+
- **Driver** → `better-sqlite3` (sync, fast) unless async is explicitly required
|
|
65
|
+
- **Migrations** → keep them in a `/migrations` folder, never alter tables manually
|
|
66
|
+
|
|
67
|
+
**Redis**
|
|
68
|
+
|
|
69
|
+
- **Use for** → caching, sessions, rate limiting, pub/sub — not as primary DB
|
|
70
|
+
- **Cache strategy** → cache-aside by default; write-through only if explicitly needed
|
|
71
|
+
- **TTL** → always set a TTL; never store without expiry
|
|
72
|
+
- **Keys** → use namespaced keys: `app:feature:id` (e.g. `user:session:abc123`)
|
|
73
|
+
- **Don't cache** → user-specific writes, financial data, anything requiring consistency
|
|
74
|
+
|
|
75
|
+
**General rules across all databases**
|
|
76
|
+
|
|
77
|
+
- Check which DB the project uses before writing any query — don't assume MongoDB
|
|
78
|
+
- Follow the existing ORM/driver convention in the project, don't introduce a second one
|
|
79
|
+
- Transactions for multi-step writes regardless of DB engine
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## Rules
|
|
84
|
+
|
|
85
|
+
- No abstractions that weren't explicitly requested.
|
|
86
|
+
- No new dependency if it can be avoided.
|
|
87
|
+
- No boilerplate nobody asked for.
|
|
88
|
+
- Deletion over addition. Boring over clever. Fewest files possible.
|
|
89
|
+
- Question complex requests: _"Do you actually need X, or does Y cover it?"_
|
|
90
|
+
- Mark intentional simplifications with a `// lexis:` comment explaining why.
|
|
91
|
+
- All user-facing responses in Spanish. All code, comments, and JSDoc in English.
|
|
92
|
+
- Never rewrite entire files when a targeted edit is sufficient.
|
|
93
|
+
- Apply SOLID and KISS at module/service level — not obsessively at component level.
|
|
94
|
+
|
|
95
|
+
---
|
|
96
|
+
|
|
97
|
+
## TypeScript Rules
|
|
98
|
+
|
|
99
|
+
- `strict: true` always.
|
|
100
|
+
- Never use `any` or `unknown` without a `// lexis:` comment explaining why.
|
|
101
|
+
- Never use `as` or `!` unless absolutely necessary — same rule.
|
|
102
|
+
- Prefer `type` over `interface` except for public APIs.
|
|
103
|
+
- Let TypeScript infer types when possible.
|
|
104
|
+
- If types are unclear: stop and ask before writing code.
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
|
|
108
|
+
## Never Lazy About
|
|
109
|
+
|
|
110
|
+
Input validation at trust boundaries, error handling that prevents data loss,
|
|
111
|
+
security, accessibility, TypeScript types, and tests for new behavior.
|
|
112
|
+
These are non-negotiable regardless of mode.
|
|
113
|
+
|
|
114
|
+
---
|
|
115
|
+
|
|
116
|
+
## Modes
|
|
117
|
+
|
|
118
|
+
Lexis supports multiple working modes. Switch with `/mode <name>` in OpenCode.
|
|
119
|
+
|
|
120
|
+
| Mode | Focus |
|
|
121
|
+
| ------------ | ---------------------------------------------- |
|
|
122
|
+
| `build` | Default — implement with minimum viable code |
|
|
123
|
+
| `plan` | Analyze and plan before any implementation |
|
|
124
|
+
| `review` | Evaluate changes against these rules, no edits |
|
|
125
|
+
| `debug` | Trace and investigate issues, no edits |
|
|
126
|
+
| `docs` | Write JSDoc, README sections, inline comments |
|
|
127
|
+
| `brainstorm` | Explore ideas and trade-offs, no code |
|
|
128
|
+
|
|
129
|
+
---
|
|
130
|
+
|
|
131
|
+
## Lexis Comment Tags
|
|
132
|
+
|
|
133
|
+
Use these tags to mark intentional decisions for future reference:
|
|
134
|
+
|
|
135
|
+
```
|
|
136
|
+
// lexis: using native <dialog> instead of modal library — no dep needed
|
|
137
|
+
// lexis: skipping abstraction — only used once
|
|
138
|
+
// lexis: tech debt — needs proper error boundary when auth module is stable
|
|
139
|
+
// lexis: simplified — revisit when pagination requirements are confirmed
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
Running `/lexis debt` (or `/lexis d`) will scan the codebase and surface all `lexis:` comments as a prioritized list.
|
|
143
|
+
|
|
144
|
+
---
|
|
145
|
+
|
|
146
|
+
## Agent Ecosystem
|
|
147
|
+
|
|
148
|
+
This file applies to all Lexis agents. Each agent has an additional scope:
|
|
149
|
+
|
|
150
|
+
| Agent | Scope |
|
|
151
|
+
| ------------------ | ------------------------------------------------ |
|
|
152
|
+
| `lexis-one` | Primary coding — implements, edits, runs bash |
|
|
153
|
+
| `lexis-review` | Strategic review — evaluates, never edits |
|
|
154
|
+
| `ui-architect` | UX/UI decisions — consults, never implements |
|
|
155
|
+
| `refactor-agent` | Large-scale refactors — rewrites, not greenfield |
|
|
156
|
+
| `security-auditor` | Security analysis — read-only, runs audit tools |
|
|
157
|
+
| `explorer` | Codebase mapping — read-only, local model |
|
|
158
|
+
|
|
159
|
+
When in doubt about scope: ask, don't assume.
|
|
160
|
+
|
|
161
|
+
---
|
|
162
|
+
|
|
163
|
+
_This file also applies to agents working on the lexis-two repo itself. Especially to them._
|
package/README.md
CHANGED
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
<p align="center">
|
|
2
2
|
<picture>
|
|
3
|
-
|
|
4
|
-
<img src="https://github.com/nitdraig/lexis-two/assets/logo.png" width="220" alt="Lexis-two">
|
|
3
|
+
<img src="https://github.com/nitdraig/lexis-two/blob/main/assets/logo.png" width="220" alt="Lexis-two">
|
|
5
4
|
</picture>
|
|
6
5
|
</p>
|
|
7
6
|
|
|
@@ -29,12 +28,20 @@ Forked and extended from [ponytail](https://github.com/DietrichGebert/ponytail)
|
|
|
29
28
|
|
|
30
29
|
---
|
|
31
30
|
|
|
31
|
+
## Excelso Open
|
|
32
|
+
|
|
33
|
+
This project is proud to be part of **Excelso Open**, our open-source and community-focused branch, championing collaborative technology and social impact projects. Learn more about our mission and other projects at [excelso.xyz](https://excelso.xyz).
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
32
37
|
## What is Lexis?
|
|
33
38
|
|
|
34
39
|
Lexis is a multi-agent ecosystem designed for building premium web apps products efficiently. It enforces a simple philosophy: **the best code is the code never written**.
|
|
35
40
|
|
|
36
41
|
Rather than a single AI assistant, Lexis is a team of specialized agents — each with a defined role, model, and scope — coordinated to cover the full development lifecycle: planning, coding, refactoring, reviewing, and security auditing.
|
|
37
42
|
|
|
43
|
+
**See it in code:** [examples/](./examples/) — nine before/after pairs across Next.js, Express, and FastAPI.
|
|
44
|
+
|
|
38
45
|
### The Agents
|
|
39
46
|
|
|
40
47
|
| Agent | Role | Scope |
|
|
@@ -75,6 +82,28 @@ Lexis is optimized for this stack — adapt as needed for your own:
|
|
|
75
82
|
|
|
76
83
|
## Installation
|
|
77
84
|
|
|
85
|
+
### One-command setup (rules-only hosts)
|
|
86
|
+
|
|
87
|
+
From your project directory:
|
|
88
|
+
|
|
89
|
+
```bash
|
|
90
|
+
npx @draig/lexis-two install
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
Non-interactive example (Cursor + OpenCode + `AGENTS.md`):
|
|
94
|
+
|
|
95
|
+
```bash
|
|
96
|
+
npx @draig/lexis-two install --host cursor,opencode,agents --scope project --yes
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
Hosts covered: Cursor, Windsurf, Cline, Kiro, OpenCode (`opencode.json` merge), `copilot-repo`, and project `AGENTS.md`. Plugin marketplaces (`claude`, `copilot`, `gemini`, `pi`) print setup hints. See [docs/setup.md](./docs/setup.md).
|
|
100
|
+
|
|
101
|
+
Uninstall (removes only unchanged Lexis-Two files):
|
|
102
|
+
|
|
103
|
+
```bash
|
|
104
|
+
npx @draig/lexis-two install --uninstall --host cursor,opencode --scope project --yes
|
|
105
|
+
```
|
|
106
|
+
|
|
78
107
|
### OpenCode (Recommended via npm)
|
|
79
108
|
|
|
80
109
|
Add the package to your project's `opencode.json`:
|
|
@@ -89,8 +118,8 @@ To enable the slash commands globally in any project:
|
|
|
89
118
|
|
|
90
119
|
```bash
|
|
91
120
|
mkdir -p ~/.config/opencode/commands
|
|
92
|
-
cp .opencode/
|
|
93
|
-
cp .opencode/
|
|
121
|
+
cp .opencode/commands/lexis*.md ~/.config/opencode/commands/
|
|
122
|
+
cp .opencode/commands/specxis*.md ~/.config/opencode/commands/
|
|
94
123
|
```
|
|
95
124
|
|
|
96
125
|
### OpenCode (Local development / manual)
|
|
@@ -130,36 +159,84 @@ More hosts (Windsurf, Gemini CLI, pi, Copilot): see [docs/portability.md](./docs
|
|
|
130
159
|
|
|
131
160
|
## Commands
|
|
132
161
|
|
|
133
|
-
Once installed, these
|
|
162
|
+
Once installed, these unified slash commands are available in OpenCode, Gemini CLI, and pi. They are designed to streamline your development process, enforce the minimalist Lexis philosophy, and manage technical debt.
|
|
134
163
|
|
|
135
164
|
### 1. `/lexis` — Core Lexis Commands
|
|
136
|
-
Manage Lexis senior dev mode, intensity levels, and quality/security tools under a single
|
|
165
|
+
Manage Lexis senior dev mode, intensity levels, and quality/security tools under a single unified command.
|
|
137
166
|
|
|
138
|
-
|
|
139
|
-
| ---------- | -------- | ------------ |
|
|
140
|
-
| `/lexis status` | `/lexis` | Shows current mode (lite/full/ultra/off) and default configuration. |
|
|
141
|
-
| `/lexis lite` / `full` / `ultra` / `off` | - | Switches the intensity level of the ruleset. |
|
|
142
|
-
| `/lexis plan` | `/lexis p` | Plans a feature using the minimalist decision hierarchy before coding. |
|
|
143
|
-
| `/lexis review` | `/lexis r` | Reviews recent changes against `AGENTS.md` rules for over-engineering. |
|
|
144
|
-
| `/lexis audit` | `/lexis a` | Full codebase audit — over-engineering, deps, structure. |
|
|
145
|
-
| `/lexis debt` | `/lexis d` | Surfaces all `// lexis:` comments as a prioritized debt list. |
|
|
146
|
-
| `/lexis security` | `/lexis s` | Security audit focused on your stack (Node.js, MongoDB, Next.js). |
|
|
147
|
-
| `/lexis help` | `/lexis h` | Shows the quick reference card. |
|
|
167
|
+
#### Subcommands in Detail:
|
|
148
168
|
|
|
149
|
-
*
|
|
169
|
+
* **`/lexis status` (Shortcut: `/lexis`)**
|
|
170
|
+
* **What it does:** Reports the current active mode of the plugin (lite/full/ultra/off) and your configured default mode.
|
|
171
|
+
* **When to use:** Use this to verify which intensity level is currently guiding your AI agent.
|
|
172
|
+
|
|
173
|
+
* **`/lexis <lite | full | ultra | off>`**
|
|
174
|
+
* **What it does:** Dynamically switches the intensity level of the smart-lazy ruleset.
|
|
175
|
+
* `lite`: Builds what's asked but suggests a lazier alternative in one line.
|
|
176
|
+
* `full` (Default): Enforces the strict minimalist ladder (YAGNI, stdlib, native, one line, minimum build).
|
|
177
|
+
* `ultra`: YAGNI extremist mode. Challenges requirements, deletes code first, and prefers one-liners.
|
|
178
|
+
* `off`: Fully deactivates Lexis rules for the current session.
|
|
179
|
+
* **When to use:** Use `ultra` when starting a refactoring or cleanup sprint; use `lite` when you have strict, non-negotiable specifications.
|
|
180
|
+
|
|
181
|
+
* **`/lexis plan` (Shortcut: `/lexis p`)**
|
|
182
|
+
* **What it does:** Produces a step-by-step technical plan for a requested feature *before* writing any code. It strictly applies the lazy decision hierarchy to ensure no over-engineering is designed.
|
|
183
|
+
* **When to use:** Run this before starting any new feature to align with the agent on the simplest possible implementation path.
|
|
184
|
+
|
|
185
|
+
* **`/lexis review` (Shortcut: `/lexis r`)**
|
|
186
|
+
* **What it does:** Analyzes your recent git changes (`git diff HEAD`) specifically for over-engineering, dead code, speculative features, reinvented standard libraries, or unnecessary abstractions.
|
|
187
|
+
* **When to use:** Run this before committing or opening a Pull Request to ensure your code is as lean and maintainable as possible.
|
|
188
|
+
|
|
189
|
+
* **`/lexis audit` (Shortcut: `/lexis a`)**
|
|
190
|
+
* **What it does:** Performs a comprehensive, read-only audit of your entire repository (not just a diff) to identify over-engineering, unused dependencies, and redundant boilerplate.
|
|
191
|
+
* **When to use:** Excellent for onboarding onto a new codebase or doing a monthly code cleanup.
|
|
192
|
+
|
|
193
|
+
* **`/lexis debt` (Shortcut: `/lexis d`)**
|
|
194
|
+
* **What it does:** Recursively scans the codebase for `// lexis:` comment tags and compiles them into a prioritized technical debt ledger, categorizing them into *Immediate*, *Next Sprint*, *Backlog*, and *Permanent*.
|
|
195
|
+
* **When to use:** Run this to check what shortcuts were taken and when they need to be upgraded.
|
|
196
|
+
|
|
197
|
+
* **`/lexis security` (Shortcut: `/lexis s`)**
|
|
198
|
+
* **What it does:** Runs a focused security audit on your stack (optimized for Node.js, Next.js, and MongoDB), checking for NoSQL injection, command injection, XSS, missing route middleware, hardcoded secrets, and unvalidated inputs.
|
|
199
|
+
* **When to use:** Run this before any production deployment or security review.
|
|
200
|
+
|
|
201
|
+
* **`/lexis help` (Shortcut: `/lexis h`)**
|
|
202
|
+
* **What it does:** Displays a quick reference card with all commands, levels, and configuration options.
|
|
203
|
+
|
|
204
|
+
_(Note: The old individual commands like `/lexis-two-review` are fully supported for backward compatibility but will display a deprecation warning guiding you to use `/lexis` instead.)_
|
|
205
|
+
|
|
206
|
+
---
|
|
150
207
|
|
|
151
208
|
### 2. `/specxis` — Spec-Driven Development (v0.5)
|
|
152
|
-
Manage the complete Specxis SDD lifecycle for complex features.
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
209
|
+
Manage the complete Specxis SDD lifecycle for complex features. Specxis ensures that developer-agent agreements are persisted as lightweight Markdown files in your repository, keeping requirements lean and focused.
|
|
210
|
+
|
|
211
|
+
#### Subcommands in Detail:
|
|
212
|
+
|
|
213
|
+
* **`/specxis status` (Shortcut: `/specxis`)**
|
|
214
|
+
* **What it does:** Lists all active specifications in `.specxis/active/`, displaying their current status (draft/agreed/implementing/done), task completion progress (e.g., `3/5 tasks checked`), and whether a review has been completed. It also shows a summary of archived specs and open debt.
|
|
215
|
+
* **When to use:** Use this as your central dashboard to see what features are currently in development and their progress.
|
|
216
|
+
|
|
217
|
+
* **`/specxis new <slug>`**
|
|
218
|
+
* **What it does:** Creates a new spec folder at `.specxis/active/[slug]/` and initializes a `proposal.md` file from the Specxis template. It prompts you with the *lazy check* ("Does this feature need to exist? What is the absolute minimum?") to challenge the requirement before planning.
|
|
219
|
+
* **When to use:** Run this when starting a complex feature that touches 3+ files or requires UX/backend coordination.
|
|
220
|
+
|
|
221
|
+
* **`/specxis plan <slug>`**
|
|
222
|
+
* **What it does:** Reads your `proposal.md`, applies the lazy decision hierarchy, and generates `spec.md` (MUST/SHOULD/MAY) and `tasks.md` (a technical task list, max 10 tasks, with each task mapping to exactly one file or function).
|
|
223
|
+
* **When to use:** Run this once the initial proposal is aligned to generate a structured, actionable implementation plan.
|
|
224
|
+
|
|
225
|
+
* **`/specxis implement <slug>`**
|
|
226
|
+
* **What it does:** Finds the first unchecked task in your `tasks.md`, implements it following the `spec.md` MUST requirements and `AGENTS.md` rules, and marks the task as completed (`- [x]`). It implements exactly one task per run to ensure maximum control and quality.
|
|
227
|
+
* **When to use:** Use this to guide the AI agent step-by-step through the implementation of your feature.
|
|
228
|
+
|
|
229
|
+
* **`/specxis review <slug>`**
|
|
230
|
+
* **What it does:** Runs a read-only evaluation of the current implementation against the requirements in `spec.md` and the rules of `AGENTS.md`. It writes its findings (Severity, Location, Issue, Fix) to `review.md`.
|
|
231
|
+
* **When to use:** Run this after implementing your tasks to verify that the feature is fully compliant and clean before closing.
|
|
232
|
+
|
|
233
|
+
* **`/specxis close <slug>`**
|
|
234
|
+
* **What it does:** Verifies that all tasks are completed and no Critical/High findings are open. It then moves the spec folder to `.specxis/archive/[slug]/`, harvests any `// lexis:` comments added during development, and appends them to your global `.specxis/debt.md` ledger.
|
|
235
|
+
* **When to use:** Run this when your feature is fully implemented, tested, and ready to be archived.
|
|
236
|
+
|
|
237
|
+
* **`/specxis debt`**
|
|
238
|
+
* **What it does:** Recursively scans the codebase for `// lexis:` comments and synchronizes them with `.specxis/debt.md` using a highly portable Node.js script.
|
|
239
|
+
* **When to use:** Run this to keep your technical debt ledger perfectly in sync with your codebase.
|
|
163
240
|
|
|
164
241
|
---
|
|
165
242
|
|
|
@@ -239,10 +316,13 @@ Make it easy to adopt Lexis in any new project.
|
|
|
239
316
|
- [ ] `AGENTS.template.md` — project-level AGENTS.md template with commented sections (stack, design tokens, glossary, conventions)
|
|
240
317
|
- [x] `docs/portability.md` — hosts, commands, skills, install paths
|
|
241
318
|
- [x] `docs/site.md` — GitHub Pages + `lexis-two.excelso.xyz`
|
|
242
|
-
- [
|
|
319
|
+
- [x] `docs/setup.md` — installer guide (phase A1; OpenCode merge in A2)
|
|
243
320
|
- [ ] `docs/modes.md` — when to use lite / full / ultra and how to create custom modes
|
|
244
|
-
- [
|
|
321
|
+
- [x] `npx lexis-two install` — setup script (phase A1: rules-only hosts)
|
|
245
322
|
- [ ] README improvements with real `// lexis:` comment examples showing before/after simplifications
|
|
323
|
+
- [x] `examples/nextjs/01-modal-library` — gold-standard before/after (B1)
|
|
324
|
+
- [x] `examples/nextjs/` + `examples/express/` — six before/after cases (B2)
|
|
325
|
+
- [x] `examples/fastapi/` — three before/after cases (B3)
|
|
246
326
|
|
|
247
327
|
---
|
|
248
328
|
|
|
@@ -255,8 +335,8 @@ Full, verified support across all major hosts.
|
|
|
255
335
|
- [x] Codex adapter (`.codex-plugin/plugin.json` + `hooks/hooks.json`)
|
|
256
336
|
- [x] pi adapter (`pi-extension/`)
|
|
257
337
|
- [x] Verified skills working in Gemini CLI, Codex, and pi
|
|
258
|
-
- [x] `examples/` —
|
|
259
|
-
- [
|
|
338
|
+
- [x] `examples/` — nine before/after cases across Next.js, Express, FastAPI (B1–B3)
|
|
339
|
+
- [x] `CONTRIBUTING.md` — how to add a new adapter or skill
|
|
260
340
|
|
|
261
341
|
---
|
|
262
342
|
|
|
@@ -309,9 +389,9 @@ The commercial evolution. Defined once v1.0 has traction.
|
|
|
309
389
|
|
|
310
390
|
## Contributing
|
|
311
391
|
|
|
312
|
-
Contributions welcome.
|
|
392
|
+
Contributions welcome. Read [CONTRIBUTING.md](./CONTRIBUTING.md) for architecture, host/skill/command checklists, and the PR contract. [AGENTS.md](./AGENTS.md) applies to this repo too.
|
|
313
393
|
|
|
314
|
-
Focus areas: stack-specific shortcuts for other tech stacks, new
|
|
394
|
+
Focus areas: stack-specific shortcuts for other tech stacks, new examples, additional hosts, installer improvements.
|
|
315
395
|
|
|
316
396
|
---
|
|
317
397
|
|
|
@@ -13,21 +13,32 @@ process.stdin.on('end', () => {
|
|
|
13
13
|
const data = JSON.parse(input.replace(/^\uFEFF/, ''));
|
|
14
14
|
const prompt = (data.prompt || '').trim().toLowerCase();
|
|
15
15
|
|
|
16
|
-
// Match /lexis-two commands
|
|
17
|
-
if (/^[/@$]lexis-two/.test(prompt)) {
|
|
16
|
+
// Match /lexis-two, /lexis, or /specxis commands
|
|
17
|
+
if (/^[/@$](lexis-two|lexis|specxis)/.test(prompt)) {
|
|
18
18
|
const parts = prompt.split(/\s+/);
|
|
19
19
|
const cmd = parts[0].replace(/^[@$]/, '/');
|
|
20
20
|
const arg = parts[1] || '';
|
|
21
21
|
|
|
22
22
|
let mode = null;
|
|
23
23
|
|
|
24
|
-
if (
|
|
24
|
+
if (
|
|
25
|
+
cmd === '/lexis-two-review' ||
|
|
26
|
+
cmd === '/lexis-two:lexis-two-review' ||
|
|
27
|
+
cmd === '/lexis:review' ||
|
|
28
|
+
cmd === '/lexis:r'
|
|
29
|
+
) {
|
|
25
30
|
mode = 'review';
|
|
26
|
-
} else if (
|
|
31
|
+
} else if (
|
|
32
|
+
cmd === '/lexis-two' ||
|
|
33
|
+
cmd === '/lexis-two:lexis-two' ||
|
|
34
|
+
cmd === '/lexis' ||
|
|
35
|
+
cmd === '/lexis:lexis'
|
|
36
|
+
) {
|
|
27
37
|
if (arg === 'lite') mode = 'lite';
|
|
28
38
|
else if (arg === 'full') mode = 'full';
|
|
29
39
|
else if (arg === 'ultra') mode = 'ultra';
|
|
30
40
|
else if (arg === 'off') mode = 'off';
|
|
41
|
+
else if (arg === 'review' || arg === 'r') mode = 'review';
|
|
31
42
|
else mode = getDefaultMode();
|
|
32
43
|
}
|
|
33
44
|
|
package/package.json
CHANGED
|
@@ -1,7 +1,10 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@draig/lexis-two",
|
|
3
|
-
"version": "1.0
|
|
3
|
+
"version": "1.1.0",
|
|
4
4
|
"description": "The simple way to obtain the best code. Portable rules, skills, and slash commands for AI agents with lowest tokens usage.",
|
|
5
|
+
"bin": {
|
|
6
|
+
"lexis-two": "scripts/install.js"
|
|
7
|
+
},
|
|
5
8
|
"main": "./.opencode/plugins/lexis-two.mjs",
|
|
6
9
|
"exports": {
|
|
7
10
|
".": "./.opencode/plugins/lexis-two.mjs",
|
|
@@ -13,14 +16,21 @@
|
|
|
13
16
|
"tui"
|
|
14
17
|
],
|
|
15
18
|
"files": [
|
|
19
|
+
"AGENTS.md",
|
|
20
|
+
".cursor/rules/lexis-two.mdc",
|
|
21
|
+
".windsurf/rules/lexis-two.md",
|
|
22
|
+
".clinerules/lexis-two.md",
|
|
23
|
+
".kiro/steering/lexis-two.md",
|
|
24
|
+
".github/copilot-instructions.md",
|
|
16
25
|
".opencode/plugins/lexis-two.mjs",
|
|
17
26
|
".opencode/plugins/lexis-two-tui.mjs",
|
|
18
|
-
".opencode/
|
|
27
|
+
".opencode/commands/",
|
|
19
28
|
"commands/",
|
|
20
29
|
"hooks/",
|
|
21
30
|
"skills/",
|
|
22
31
|
"templates/",
|
|
23
|
-
"scripts/"
|
|
32
|
+
"scripts/",
|
|
33
|
+
"pi-extension/index.js"
|
|
24
34
|
],
|
|
25
35
|
"keywords": [
|
|
26
36
|
"pi-package",
|