@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.
@@ -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
- <!-- <source media="(prefers-color-scheme: dark)" srcset="assets/logo-dark.png"> -->
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/command/lexis*.md ~/.config/opencode/commands/
93
- cp .opencode/command/specxis*.md ~/.config/opencode/commands/
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 unifed slash commands are available in OpenCode, Gemini CLI, and pi:
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 unifed command.
165
+ Manage Lexis senior dev mode, intensity levels, and quality/security tools under a single unified command.
137
166
 
138
- | Subcommand | Shortcut | What it does |
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
- *(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.)*
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
- | Subcommand | What it does |
155
- | ---------- | ------------ |
156
- | `/specxis` or `/specxis status` | Shows active specs, tasks progress, and debt. |
157
- | `/specxis new <slug>` | Creates a new spec folder and `proposal.md` applying the lazy check. |
158
- | `/specxis plan <slug>` | Generates `spec.md` and `tasks.md` from `proposal.md`. |
159
- | `/specxis implement <slug>` | Implements the next unchecked task in the active spec. |
160
- | `/specxis review <slug>` | Reviews the implementation against `spec.md` and `AGENTS.md`. |
161
- | `/specxis close <slug>` | Archives the completed spec and syncs its debt to `.specxis/debt.md`. |
162
- | `/specxis debt` | Sincroniza todos los comentarios `// lexis:` del código de forma portable. |
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
- - [ ] `docs/setup.md` — detailed installation guide per host
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
- - [ ] `npx lexis-two install` — setup script that detects the host (cursor, windsurf, opencode…) and copies the right files
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/` — real before/after cases with `// lexis:` comments across the stack (Next.js, Express, MongoDB, PostgreSQL)
259
- - [ ] `docs/contributing.md` — how to add a new adapter or skill
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. Before opening a PR, read `AGENTS.md` it applies here too.
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 modes, additional commands.
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 (cmd === '/lexis-two-review' || cmd === '/lexis-two:lexis-two-review') {
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 (cmd === '/lexis-two' || cmd === '/lexis-two:lexis-two') {
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.8",
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/command/",
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",