@draig/lexis-two 1.0.7 → 1.0.9
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/.opencode/command/lexis.md +17 -0
- package/.opencode/command/specxis.md +18 -0
- package/README.md +94 -19
- package/commands/lexis-two-audit.toml +3 -0
- package/commands/lexis-two-debt.toml +3 -0
- package/commands/lexis-two-help.toml +3 -0
- package/commands/lexis-two-plan.toml +3 -0
- package/commands/lexis-two-review.toml +3 -0
- package/commands/lexis-two-security.toml +3 -0
- package/commands/lexis-two.toml +3 -0
- package/commands/lexis.toml +3 -0
- package/commands/specxis.toml +3 -0
- package/package.json +4 -2
- package/scripts/check-rule-copies.js +82 -0
- package/scripts/specxis-debt.js +121 -0
- package/scripts/specxis-init.js +45 -0
- package/skills/specxis/SKILL.md +46 -0
- package/templates/specxis/proposal.md +21 -0
- package/templates/specxis/review.md +17 -0
- package/templates/specxis/spec.md +24 -0
- package/templates/specxis/tasks.md +16 -0
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Manage Lexis senior dev mode, intensity levels, and quality/security tools"
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Manage Lexis senior dev mode, intensity levels, and quality/security tools.
|
|
6
|
+
|
|
7
|
+
Usage:
|
|
8
|
+
- `/lexis` or `/lexis status`: Show current mode and status.
|
|
9
|
+
- `/lexis lite` / `/lexis full` / `/lexis ultra` / `/lexis off`: Switch the intensity level of the ruleset.
|
|
10
|
+
- `/lexis plan` (or `/lexis p`): Plan a feature using the lazy hierarchy before coding.
|
|
11
|
+
- `/lexis review` (or `/lexis r`): Review current changes for over-engineering.
|
|
12
|
+
- `/lexis audit` (or `/lexis a`): Audit the entire repository for over-engineering.
|
|
13
|
+
- `/lexis debt` (or `/lexis d`): Harvest all `// lexis:` comments into a tracked ledger.
|
|
14
|
+
- `/lexis security` (or `/lexis s`): Run a focused security audit on the stack.
|
|
15
|
+
- `/lexis help` (or `/lexis h`): Show the quick reference card.
|
|
16
|
+
|
|
17
|
+
Respond in Spanish.
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Manage the Specxis Spec-Driven Development lifecycle (new, plan, implement, review, close, debt, status)"
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Manage the Specxis Spec-Driven Development lifecycle.
|
|
6
|
+
|
|
7
|
+
Usage:
|
|
8
|
+
- `/specxis` or `/specxis status`: Show active specs, tasks progress, and debt.
|
|
9
|
+
- `/specxis new <slug>`: Create a new spec folder and proposal.md.
|
|
10
|
+
- `/specxis plan <slug>`: Generate spec.md and tasks.md from proposal.md.
|
|
11
|
+
- `/specxis implement <slug>`: Implement the next unchecked task.
|
|
12
|
+
- `/specxis review <slug>`: Review the implementation against spec.md and AGENTS.md.
|
|
13
|
+
- `/specxis close <slug>`: Archive the completed spec and sync its debt.
|
|
14
|
+
- `/specxis debt`: Sync all `// lexis:` comments from the codebase to `.specxis/debt.md`.
|
|
15
|
+
|
|
16
|
+
If `.specxis/` does not exist, suggest running `node node_modules/@draig/lexis-two/scripts/specxis-init.js` (or local script path if in development).
|
|
17
|
+
|
|
18
|
+
Respond in Spanish.
|
package/README.md
CHANGED
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
<p align="center">
|
|
2
2
|
<picture>
|
|
3
|
-
|
|
4
|
-
<img src="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,6 +28,12 @@ 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**.
|
|
@@ -89,7 +94,8 @@ To enable the slash commands globally in any project:
|
|
|
89
94
|
|
|
90
95
|
```bash
|
|
91
96
|
mkdir -p ~/.config/opencode/commands
|
|
92
|
-
cp .opencode/command/lexis
|
|
97
|
+
cp .opencode/command/lexis*.md ~/.config/opencode/commands/
|
|
98
|
+
cp .opencode/command/specxis*.md ~/.config/opencode/commands/
|
|
93
99
|
```
|
|
94
100
|
|
|
95
101
|
### OpenCode (Local development / manual)
|
|
@@ -129,15 +135,84 @@ More hosts (Windsurf, Gemini CLI, pi, Copilot): see [docs/portability.md](./docs
|
|
|
129
135
|
|
|
130
136
|
## Commands
|
|
131
137
|
|
|
132
|
-
Once installed, these slash commands are available in OpenCode
|
|
138
|
+
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.
|
|
139
|
+
|
|
140
|
+
### 1. `/lexis` — Core Lexis Commands
|
|
141
|
+
Manage Lexis senior dev mode, intensity levels, and quality/security tools under a single unified command.
|
|
142
|
+
|
|
143
|
+
#### Subcommands in Detail:
|
|
144
|
+
|
|
145
|
+
* **`/lexis status` (Shortcut: `/lexis`)**
|
|
146
|
+
* **What it does:** Reports the current active mode of the plugin (lite/full/ultra/off) and your configured default mode.
|
|
147
|
+
* **When to use:** Use this to verify which intensity level is currently guiding your AI agent.
|
|
148
|
+
|
|
149
|
+
* **`/lexis <lite | full | ultra | off>`**
|
|
150
|
+
* **What it does:** Dynamically switches the intensity level of the smart-lazy ruleset.
|
|
151
|
+
* `lite`: Builds what's asked but suggests a lazier alternative in one line.
|
|
152
|
+
* `full` (Default): Enforces the strict minimalist ladder (YAGNI, stdlib, native, one line, minimum build).
|
|
153
|
+
* `ultra`: YAGNI extremist mode. Challenges requirements, deletes code first, and prefers one-liners.
|
|
154
|
+
* `off`: Fully deactivates Lexis rules for the current session.
|
|
155
|
+
* **When to use:** Use `ultra` when starting a refactoring or cleanup sprint; use `lite` when you have strict, non-negotiable specifications.
|
|
156
|
+
|
|
157
|
+
* **`/lexis plan` (Shortcut: `/lexis p`)**
|
|
158
|
+
* **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.
|
|
159
|
+
* **When to use:** Run this before starting any new feature to align with the agent on the simplest possible implementation path.
|
|
160
|
+
|
|
161
|
+
* **`/lexis review` (Shortcut: `/lexis r`)**
|
|
162
|
+
* **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.
|
|
163
|
+
* **When to use:** Run this before committing or opening a Pull Request to ensure your code is as lean and maintainable as possible.
|
|
164
|
+
|
|
165
|
+
* **`/lexis audit` (Shortcut: `/lexis a`)**
|
|
166
|
+
* **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.
|
|
167
|
+
* **When to use:** Excellent for onboarding onto a new codebase or doing a monthly code cleanup.
|
|
168
|
+
|
|
169
|
+
* **`/lexis debt` (Shortcut: `/lexis d`)**
|
|
170
|
+
* **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*.
|
|
171
|
+
* **When to use:** Run this to check what shortcuts were taken and when they need to be upgraded.
|
|
172
|
+
|
|
173
|
+
* **`/lexis security` (Shortcut: `/lexis s`)**
|
|
174
|
+
* **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.
|
|
175
|
+
* **When to use:** Run this before any production deployment or security review.
|
|
176
|
+
|
|
177
|
+
* **`/lexis help` (Shortcut: `/lexis h`)**
|
|
178
|
+
* **What it does:** Displays a quick reference card with all commands, levels, and configuration options.
|
|
179
|
+
|
|
180
|
+
_(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.)_
|
|
181
|
+
|
|
182
|
+
---
|
|
183
|
+
|
|
184
|
+
### 2. `/specxis` — Spec-Driven Development (v0.5)
|
|
185
|
+
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.
|
|
186
|
+
|
|
187
|
+
#### Subcommands in Detail:
|
|
188
|
+
|
|
189
|
+
* **`/specxis status` (Shortcut: `/specxis`)**
|
|
190
|
+
* **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.
|
|
191
|
+
* **When to use:** Use this as your central dashboard to see what features are currently in development and their progress.
|
|
192
|
+
|
|
193
|
+
* **`/specxis new <slug>`**
|
|
194
|
+
* **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.
|
|
195
|
+
* **When to use:** Run this when starting a complex feature that touches 3+ files or requires UX/backend coordination.
|
|
196
|
+
|
|
197
|
+
* **`/specxis plan <slug>`**
|
|
198
|
+
* **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).
|
|
199
|
+
* **When to use:** Run this once the initial proposal is aligned to generate a structured, actionable implementation plan.
|
|
200
|
+
|
|
201
|
+
* **`/specxis implement <slug>`**
|
|
202
|
+
* **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.
|
|
203
|
+
* **When to use:** Use this to guide the AI agent step-by-step through the implementation of your feature.
|
|
204
|
+
|
|
205
|
+
* **`/specxis review <slug>`**
|
|
206
|
+
* **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`.
|
|
207
|
+
* **When to use:** Run this after implementing your tasks to verify that the feature is fully compliant and clean before closing.
|
|
208
|
+
|
|
209
|
+
* **`/specxis close <slug>`**
|
|
210
|
+
* **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.
|
|
211
|
+
* **When to use:** Run this when your feature is fully implemented, tested, and ready to be archived.
|
|
133
212
|
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
| `/lexis-two-audit` | Full codebase audit — over-engineering, deps, structure |
|
|
138
|
-
| `/lexis-two-debt` | Surfaces all `// lexis:` comments as prioritized debt list |
|
|
139
|
-
| `/lexis-two-plan` | Plans a feature using the minimalist decision hierarchy before coding |
|
|
140
|
-
| `/lexis-two-security` | Security audit focused on your stack (Node.js, MongoDB, Next.js) |
|
|
213
|
+
* **`/specxis debt`**
|
|
214
|
+
* **What it does:** Recursively scans the codebase for `// lexis:` comments and synchronizes them with `.specxis/debt.md` using a highly portable Node.js script.
|
|
215
|
+
* **When to use:** Run this to keep your technical debt ledger perfectly in sync with your codebase.
|
|
141
216
|
|
|
142
217
|
---
|
|
143
218
|
|
|
@@ -166,7 +241,7 @@ Lexis marks intentional simplifications with inline comments:
|
|
|
166
241
|
// lexis: tech debt — revisit when auth module is stable
|
|
167
242
|
```
|
|
168
243
|
|
|
169
|
-
Run `/lexis
|
|
244
|
+
Run `/lexis debt` (or `/lexis d`) to collect and prioritize all tagged items across the codebase.
|
|
170
245
|
|
|
171
246
|
---
|
|
172
247
|
|
|
@@ -250,17 +325,17 @@ The public orchestrator — a generalized pattern extracted from the private Lex
|
|
|
250
325
|
|
|
251
326
|
---
|
|
252
327
|
|
|
253
|
-
### v0.5 — Specxis (Spec-Driven Development)
|
|
328
|
+
### v0.5 — Specxis (Spec-Driven Development) ✅
|
|
254
329
|
|
|
255
330
|
Lightweight SDD layer for complex features — inspired by OpenSpec and Spec Kit,
|
|
256
331
|
built for the Lexis philosophy.
|
|
257
332
|
|
|
258
|
-
- [
|
|
259
|
-
- [
|
|
260
|
-
- [
|
|
261
|
-
- [
|
|
262
|
-
- [
|
|
263
|
-
- [
|
|
333
|
+
- [x] `.specxis/` folder convention documented
|
|
334
|
+
- [x] Commands: specxis-new, specxis-plan, specxis-implement, specxis-review, specxis-close, specxis-debt
|
|
335
|
+
- [x] Skills: specxis, specxis-plan, specxis-review, specxis-close
|
|
336
|
+
- [x] `scripts/specxis-init.js` — creates .specxis/ structure in any project
|
|
337
|
+
- [x] `templates/specxis/` — proposal, spec, and tasks templates
|
|
338
|
+
- [x] `docs/specxis.md` — when to use SDD vs direct implementation
|
|
264
339
|
- [ ] Integration guide for Lexis-One private config
|
|
265
340
|
|
|
266
341
|
---
|
|
@@ -0,0 +1,3 @@
|
|
|
1
|
+
name = "lexis-two-help"
|
|
2
|
+
description = "Quick reference for lexis-two levels, skills, and commands"
|
|
3
|
+
prompt = "Show the lexis-two quick reference. One shot, change nothing: do not switch mode, write flag files, or persist anything. Levels: /lexis-two lite, /lexis-two (full, default), /lexis-two ultra. Commands: /lexis-two-review, /lexis-two-audit, /lexis-two-debt, /lexis-two-plan, /lexis-two-security, /lexis-two-help."
|
|
@@ -0,0 +1,3 @@
|
|
|
1
|
+
name = "lexis-two"
|
|
2
|
+
description = "Switch lexis-two intensity level (lite/full/ultra/off)"
|
|
3
|
+
prompt = "Switch to lexis-two {{args}} mode. If no level specified, use full. Lazy senior dev mode, before any code: does it need to exist at all (YAGNI)? Does the standard library do it? A native platform feature? Can it be one line? Build the minimum that works. No unrequested abstractions, no avoidable dependencies, no boilerplate. Mark intentional simplifications with a lexis: comment."
|
|
@@ -0,0 +1,3 @@
|
|
|
1
|
+
name = "lexis"
|
|
2
|
+
description = "Manage Lexis senior dev mode, intensity levels, and quality/security tools"
|
|
3
|
+
prompt = "Manage Lexis senior dev mode. Handle the requested subcommand: plan (p), review (r), audit (a), debt (d), security (s), help (h), status, or intensity level (lite/full/ultra/off)."
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@draig/lexis-two",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.9",
|
|
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
5
|
"main": "./.opencode/plugins/lexis-two.mjs",
|
|
6
6
|
"exports": {
|
|
@@ -16,9 +16,11 @@
|
|
|
16
16
|
".opencode/plugins/lexis-two.mjs",
|
|
17
17
|
".opencode/plugins/lexis-two-tui.mjs",
|
|
18
18
|
".opencode/command/",
|
|
19
|
+
"commands/",
|
|
19
20
|
"hooks/",
|
|
20
21
|
"skills/",
|
|
21
|
-
"
|
|
22
|
+
"templates/",
|
|
23
|
+
"scripts/"
|
|
22
24
|
],
|
|
23
25
|
"keywords": [
|
|
24
26
|
"pi-package",
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
// lexis-two — rule copy integrity check
|
|
3
|
+
//
|
|
4
|
+
// To avoid runtime overhead, instruction-tier hosts (Windsurf, Cline, Kiro,
|
|
5
|
+
// Cursor) load static copies of the rules. This script acts as a build/CI guard
|
|
6
|
+
// to ensure those copies never drift from the canonical source (AGENTS.md).
|
|
7
|
+
//
|
|
8
|
+
// It asserts that:
|
|
9
|
+
// 1. Every rule copy file exists.
|
|
10
|
+
// 2. Every copy is completely identical to AGENTS.md (ignoring host-specific frontmatter).
|
|
11
|
+
// 3. The canonical AGENTS.md itself contains the load-bearing Lexis-Two rules.
|
|
12
|
+
|
|
13
|
+
const fs = require('fs');
|
|
14
|
+
const path = require('path');
|
|
15
|
+
|
|
16
|
+
const root = path.join(__dirname, '..');
|
|
17
|
+
|
|
18
|
+
// Canonical source of truth
|
|
19
|
+
const SOURCE_FILE = 'AGENTS.md';
|
|
20
|
+
|
|
21
|
+
// Static copies to validate
|
|
22
|
+
const COPIES = [
|
|
23
|
+
'.windsurf/rules/lexis-two.md',
|
|
24
|
+
'.clinerules/lexis-two.md',
|
|
25
|
+
'.kiro/steering/lexis-two.md',
|
|
26
|
+
'.cursor/rules/lexis-two.mdc',
|
|
27
|
+
];
|
|
28
|
+
|
|
29
|
+
// Load-bearing phrases that MUST exist in the source of truth. If these are
|
|
30
|
+
// missing, the source file has been gutted, and the copies are validating
|
|
31
|
+
// against an empty shell.
|
|
32
|
+
const INVARIANTS = [
|
|
33
|
+
'lazy senior',
|
|
34
|
+
'Input validation at trust boundaries',
|
|
35
|
+
'YAGNI',
|
|
36
|
+
];
|
|
37
|
+
|
|
38
|
+
function read(relPath) {
|
|
39
|
+
try {
|
|
40
|
+
return fs.readFileSync(path.join(root, relPath), 'utf8');
|
|
41
|
+
} catch (e) {
|
|
42
|
+
console.error(`Error: failed to read ${relPath}`);
|
|
43
|
+
process.exit(1);
|
|
44
|
+
}
|
|
45
|
+
}
|
|
46
|
+
|
|
47
|
+
// 1. Validate canonical source
|
|
48
|
+
const source = read(SOURCE_FILE);
|
|
49
|
+
for (const phrase of INVARIANTS) {
|
|
50
|
+
if (!source.includes(phrase)) {
|
|
51
|
+
console.error(`Error: canonical source (${SOURCE_FILE}) is missing load-bearing rule: "${phrase}"`);
|
|
52
|
+
process.exit(1);
|
|
53
|
+
}
|
|
54
|
+
}
|
|
55
|
+
|
|
56
|
+
// Helper to strip frontmatter (metadata blocks between '---' at start of file)
|
|
57
|
+
function stripFrontmatter(content) {
|
|
58
|
+
return content.replace(/^---[\s\S]*?---\s*/, '');
|
|
59
|
+
}
|
|
60
|
+
|
|
61
|
+
// 2. Validate copies
|
|
62
|
+
let failed = false;
|
|
63
|
+
const canonicalBody = stripFrontmatter(source).trim();
|
|
64
|
+
|
|
65
|
+
for (const copyPath of COPIES) {
|
|
66
|
+
const copyContent = read(copyPath);
|
|
67
|
+
const copyBody = stripFrontmatter(copyContent).trim();
|
|
68
|
+
|
|
69
|
+
if (copyBody !== canonicalBody) {
|
|
70
|
+
console.error(`Drift detected: ${copyPath} does not match ${SOURCE_FILE}`);
|
|
71
|
+
failed = true;
|
|
72
|
+
}
|
|
73
|
+
}
|
|
74
|
+
|
|
75
|
+
if (failed) {
|
|
76
|
+
console.error('\nIntegrity check FAILED. Rule copies have drifted from AGENTS.md.');
|
|
77
|
+
console.error('To fix, copy AGENTS.md content into the drifted files, preserving their frontmatter if any.');
|
|
78
|
+
process.exit(1);
|
|
79
|
+
}
|
|
80
|
+
|
|
81
|
+
console.log('Rule copy integrity check PASSED.');
|
|
82
|
+
process.exit(0);
|
|
@@ -0,0 +1,121 @@
|
|
|
1
|
+
// scripts/specxis-debt.js
|
|
2
|
+
// Portable Node.js script to scan the codebase for "// lexis:" comments
|
|
3
|
+
// and sync them with .specxis/debt.md.
|
|
4
|
+
// Works on Windows, macOS, and Linux.
|
|
5
|
+
|
|
6
|
+
const fs = require('fs');
|
|
7
|
+
const path = require('path');
|
|
8
|
+
|
|
9
|
+
const DEBT_FILE = '.specxis/debt.md';
|
|
10
|
+
|
|
11
|
+
// Recursive directory scan
|
|
12
|
+
function scanDir(dir, fileList = []) {
|
|
13
|
+
if (!fs.existsSync(dir)) return fileList;
|
|
14
|
+
const files = fs.readdirSync(dir);
|
|
15
|
+
for (const file of files) {
|
|
16
|
+
const filePath = path.join(dir, file);
|
|
17
|
+
const stat = fs.statSync(filePath);
|
|
18
|
+
if (stat.isDirectory()) {
|
|
19
|
+
// Skip common ignore folders
|
|
20
|
+
if (['node_modules', '.git', '.specxis', '.astro', 'dist', 'build', '.cache'].includes(file)) continue;
|
|
21
|
+
scanDir(filePath, fileList);
|
|
22
|
+
} else {
|
|
23
|
+
// Only scan relevant code files
|
|
24
|
+
if (['.ts', '.tsx', '.js', '.jsx', '.mjs', '.cjs'].includes(path.extname(file))) {
|
|
25
|
+
fileList.push(filePath);
|
|
26
|
+
}
|
|
27
|
+
}
|
|
28
|
+
}
|
|
29
|
+
return fileList;
|
|
30
|
+
}
|
|
31
|
+
|
|
32
|
+
function findLexisComments() {
|
|
33
|
+
const files = scanDir('.');
|
|
34
|
+
const comments = [];
|
|
35
|
+
const regex = /\/\/\s*lexis:\s*(.*)/gi;
|
|
36
|
+
|
|
37
|
+
for (const file of files) {
|
|
38
|
+
const content = fs.readFileSync(file, 'utf8');
|
|
39
|
+
const lines = content.split(/\r?\n/);
|
|
40
|
+
lines.forEach((line, index) => {
|
|
41
|
+
let match;
|
|
42
|
+
// Reset regex lastIndex
|
|
43
|
+
regex.lastIndex = 0;
|
|
44
|
+
while ((match = regex.exec(line)) !== null) {
|
|
45
|
+
comments.push({
|
|
46
|
+
file: file.replace(/\\/g, '/'), // normalize to forward slashes
|
|
47
|
+
line: index + 1,
|
|
48
|
+
comment: match[1].trim()
|
|
49
|
+
});
|
|
50
|
+
}
|
|
51
|
+
});
|
|
52
|
+
}
|
|
53
|
+
return comments;
|
|
54
|
+
}
|
|
55
|
+
|
|
56
|
+
function syncDebt() {
|
|
57
|
+
if (!fs.existsSync(DEBT_FILE)) {
|
|
58
|
+
console.error(`Error: ${DEBT_FILE} does not exist. Run specxis-init first.`);
|
|
59
|
+
process.exit(1);
|
|
60
|
+
}
|
|
61
|
+
|
|
62
|
+
const found = findLexisComments();
|
|
63
|
+
console.log(`Found ${found.length} '// lexis:' comments in codebase.`);
|
|
64
|
+
|
|
65
|
+
let debtContent = fs.readFileSync(DEBT_FILE, 'utf8');
|
|
66
|
+
|
|
67
|
+
// We want to reconstruct or append to .specxis/debt.md.
|
|
68
|
+
// Let's create a prioritized ledger as described in SPECXIS.md.
|
|
69
|
+
// Categories:
|
|
70
|
+
// - Immediate: shortcuts causing pain or blocking features
|
|
71
|
+
// - Next sprint: shortcuts with a known ceiling approaching
|
|
72
|
+
// - Backlog: fine for now, revisit at scale
|
|
73
|
+
// - Permanent: intentional, no action needed
|
|
74
|
+
|
|
75
|
+
const immediate = [];
|
|
76
|
+
const nextSprint = [];
|
|
77
|
+
const backlog = [];
|
|
78
|
+
const permanent = [];
|
|
79
|
+
|
|
80
|
+
found.forEach(item => {
|
|
81
|
+
const text = item.comment.toLowerCase();
|
|
82
|
+
const entry = `- [ ] **${item.file}:${item.line}**: ${item.comment}`;
|
|
83
|
+
|
|
84
|
+
if (text.includes('immediate') || text.includes('critical') || text.includes('pain') || text.includes('block')) {
|
|
85
|
+
immediate.push(entry);
|
|
86
|
+
} else if (text.includes('sprint') || text.includes('soon') || text.includes('ceiling')) {
|
|
87
|
+
nextSprint.push(entry);
|
|
88
|
+
} else if (text.includes('permanent') || text.includes('intentional') || text.includes('no action')) {
|
|
89
|
+
permanent.push(`- **${item.file}:${item.line}**: ${item.comment} (Permanent)`);
|
|
90
|
+
} else {
|
|
91
|
+
backlog.push(entry);
|
|
92
|
+
}
|
|
93
|
+
});
|
|
94
|
+
|
|
95
|
+
const header = `# Specxis Debt Ledger
|
|
96
|
+
|
|
97
|
+
Consolidated // lexis: comments across all features.
|
|
98
|
+
Updated automatically by /specxis-debt and /specxis-close.
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
## Prioritized Ledger
|
|
103
|
+
|
|
104
|
+
### Immediate (shortcuts causing pain or blocking features)
|
|
105
|
+
${immediate.length > 0 ? immediate.join('\n') : '*No immediate debt found.*'}
|
|
106
|
+
|
|
107
|
+
### Next Sprint (shortcuts with a known ceiling approaching)
|
|
108
|
+
${nextSprint.length > 0 ? nextSprint.join('\n') : '*No next sprint debt found.*'}
|
|
109
|
+
|
|
110
|
+
### Backlog (fine for now, revisit at scale)
|
|
111
|
+
${backlog.length > 0 ? backlog.join('\n') : '*No backlog debt found.*'}
|
|
112
|
+
|
|
113
|
+
### Permanent (intentional, no action needed)
|
|
114
|
+
${permanent.length > 0 ? permanent.join('\n') : '*No permanent debt found.*'}
|
|
115
|
+
`;
|
|
116
|
+
|
|
117
|
+
fs.writeFileSync(DEBT_FILE, header);
|
|
118
|
+
console.log(`Updated ${DEBT_FILE} with prioritized ledger.`);
|
|
119
|
+
}
|
|
120
|
+
|
|
121
|
+
syncDebt();
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
// scripts/specxis-init.js
|
|
2
|
+
// Initializes .specxis/ folder structure in the current project.
|
|
3
|
+
// Run with: node scripts/specxis-init.js
|
|
4
|
+
|
|
5
|
+
const fs = require('fs');
|
|
6
|
+
const path = require('path');
|
|
7
|
+
|
|
8
|
+
const dirs = [
|
|
9
|
+
'.specxis/active',
|
|
10
|
+
'.specxis/archive',
|
|
11
|
+
];
|
|
12
|
+
|
|
13
|
+
const debtTemplate = `# Specxis Debt Ledger
|
|
14
|
+
|
|
15
|
+
Consolidated // lexis: comments across all features.
|
|
16
|
+
Updated automatically by /specxis-debt and /specxis-close.
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
<!-- Entries added by specxis-close and specxis-debt commands -->
|
|
21
|
+
`;
|
|
22
|
+
|
|
23
|
+
for (const dir of dirs) {
|
|
24
|
+
fs.mkdirSync(dir, { recursive: true });
|
|
25
|
+
console.log(`created ${dir}/`);
|
|
26
|
+
}
|
|
27
|
+
|
|
28
|
+
const debtPath = '.specxis/debt.md';
|
|
29
|
+
if (!fs.existsSync(debtPath)) {
|
|
30
|
+
fs.writeFileSync(debtPath, debtTemplate);
|
|
31
|
+
console.log(`created ${debtPath}`);
|
|
32
|
+
}
|
|
33
|
+
|
|
34
|
+
// Add .specxis/archive to .gitignore if not already there
|
|
35
|
+
// (active specs stay in git; archive is optional)
|
|
36
|
+
const gitignorePath = '.gitignore';
|
|
37
|
+
if (fs.existsSync(gitignorePath)) {
|
|
38
|
+
const content = fs.readFileSync(gitignorePath, 'utf8');
|
|
39
|
+
if (!content.includes('.specxis/archive')) {
|
|
40
|
+
fs.appendFileSync(gitignorePath, '\n# Specxis archived specs (optional)\n# .specxis/archive\n');
|
|
41
|
+
console.log('added .specxis/archive comment to .gitignore');
|
|
42
|
+
}
|
|
43
|
+
}
|
|
44
|
+
|
|
45
|
+
console.log('\nSpecxis initialized. Run /specxis-new to create your first spec.');
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: specxis
|
|
3
|
+
description: Manage the Specxis Spec-Driven Development lifecycle (new, plan, implement, review, close, debt, status)
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
You are the Specxis orchestrator. Handle the requested subcommand or action:
|
|
7
|
+
|
|
8
|
+
### 1. STATUS (default: `/specxis` or `/specxis status`)
|
|
9
|
+
- List folders in `.specxis/active/`. For each, show: slug, status (draft/agreed/implementing/done), task progress (X/Y), and if review.md exists.
|
|
10
|
+
- List count of archived specs in `.specxis/archive/`.
|
|
11
|
+
- Show open items in `.specxis/debt.md` by priority.
|
|
12
|
+
|
|
13
|
+
### 2. NEW (`/specxis new <slug>`)
|
|
14
|
+
- Ask for slug if not provided (kebab-case, e.g. "user-auth").
|
|
15
|
+
- Create `.specxis/active/[slug]/proposal.md` from the template in `node_modules/@draig/lexis-two/templates/specxis/proposal.md` (or local path).
|
|
16
|
+
- Apply the lazy check: ask "Does this need to exist? What's the minimum?". Fill what you know, leave unknowns blank.
|
|
17
|
+
|
|
18
|
+
### 3. PLAN (`/specxis plan <slug>`)
|
|
19
|
+
- Read `.specxis/active/[slug]/proposal.md`.
|
|
20
|
+
- Apply the lazy hierarchy to every requirement.
|
|
21
|
+
- Create `.specxis/active/[slug]/spec.md` (MUST/SHOULD/MAY) and `.specxis/active/[slug]/tasks.md` (max 10 tasks, one per file/function).
|
|
22
|
+
- Ask for approval before starting implementation.
|
|
23
|
+
|
|
24
|
+
### 4. IMPLEMENT (`/specxis implement <slug>`)
|
|
25
|
+
- Read `.specxis/active/[slug]/tasks.md`. Find the first unchecked task (`- [ ]`).
|
|
26
|
+
- Implement it following spec.md MUST requirements and AGENTS.md rules.
|
|
27
|
+
- Mark as done (`- [x]`), add `// lexis:` comments for deviations, and update "Lexis Tags Added" in tasks.md.
|
|
28
|
+
- Implement only one task per run. Stop and report.
|
|
29
|
+
|
|
30
|
+
### 5. REVIEW (`/specxis review <slug>`)
|
|
31
|
+
- Read `.specxis/active/[slug]/spec.md` and run `git diff HEAD`.
|
|
32
|
+
- Evaluate spec compliance, SHOULD compliance, AGENTS.md rules, and tests.
|
|
33
|
+
- Write findings to `.specxis/active/[slug]/review.md` (Severity: Critical/High/Medium/Low, Location, Issue, Fix).
|
|
34
|
+
|
|
35
|
+
### 6. CLOSE (`/specxis close <slug>`)
|
|
36
|
+
- Verify all tasks are checked and no Critical/High findings are open.
|
|
37
|
+
- Move `.specxis/active/[slug]/` to `.specxis/archive/[slug]/`.
|
|
38
|
+
- Collect all `// lexis:` comments added during this feature and append them to `.specxis/debt.md`.
|
|
39
|
+
|
|
40
|
+
### 7. DEBT (`/specxis debt`)
|
|
41
|
+
- Run `node node_modules/@draig/lexis-two/scripts/specxis-debt.js` (or local path) to scan the codebase and update `.specxis/debt.md` with a prioritized ledger.
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
If `.specxis/` does not exist, suggest running `node node_modules/@draig/lexis-two/scripts/specxis-init.js` first.
|
|
46
|
+
Respond in Spanish. All code, comments, JSDoc in English.
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Proposal: [feature-slug]
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
One sentence — what does this feature do for the user?
|
|
5
|
+
|
|
6
|
+
## Lazy Check
|
|
7
|
+
Answer before writing any code:
|
|
8
|
+
- Does this need to exist? Could the requirement be met another way?
|
|
9
|
+
- Does stdlib, the framework, or an installed dep already cover it?
|
|
10
|
+
- What is the absolute minimum that satisfies the requirement?
|
|
11
|
+
|
|
12
|
+
## Context
|
|
13
|
+
- Affected domain / feature folder:
|
|
14
|
+
- Related existing files:
|
|
15
|
+
- Dependencies already installed that are relevant:
|
|
16
|
+
|
|
17
|
+
## Out of Scope (YAGNI)
|
|
18
|
+
Explicitly list what this proposal does NOT include.
|
|
19
|
+
|
|
20
|
+
## Open Questions
|
|
21
|
+
Anything that needs clarification before planning.
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
# Review: [feature-slug]
|
|
2
|
+
|
|
3
|
+
> Generated by /specxis-review on close.
|
|
4
|
+
|
|
5
|
+
## Summary
|
|
6
|
+
One sentence on overall quality.
|
|
7
|
+
|
|
8
|
+
## Spec Compliance
|
|
9
|
+
Did the implementation follow spec.md?
|
|
10
|
+
- MUST requirements met: yes / no / partial
|
|
11
|
+
- Deviations: list with // lexis: references
|
|
12
|
+
|
|
13
|
+
## Debt Registered
|
|
14
|
+
// lexis: comments added during this feature — moved to .specxis/debt.md.
|
|
15
|
+
|
|
16
|
+
## Next Steps
|
|
17
|
+
Recommended follow-up actions in priority order.
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# Spec: [feature-slug]
|
|
2
|
+
|
|
3
|
+
> Status: draft | agreed | implementing | done
|
|
4
|
+
|
|
5
|
+
## Requirements
|
|
6
|
+
|
|
7
|
+
### MUST (non-negotiable)
|
|
8
|
+
- [ ]
|
|
9
|
+
|
|
10
|
+
### SHOULD (strong preference, can deviate with // lexis: comment)
|
|
11
|
+
- [ ]
|
|
12
|
+
|
|
13
|
+
### MAY (optional, implement only if trivial)
|
|
14
|
+
- [ ]
|
|
15
|
+
|
|
16
|
+
## Constraints
|
|
17
|
+
- Performance:
|
|
18
|
+
- Security:
|
|
19
|
+
- Accessibility:
|
|
20
|
+
- TypeScript: strict — no any, as, or ! without // lexis: explanation
|
|
21
|
+
|
|
22
|
+
## Acceptance Criteria
|
|
23
|
+
How do we know this is done?
|
|
24
|
+
- [ ]
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
# Tasks: [feature-slug]
|
|
2
|
+
|
|
3
|
+
> Generated by /specxis-plan. Each task maps to one file or one function.
|
|
4
|
+
> Do not start implementing until tasks are agreed.
|
|
5
|
+
|
|
6
|
+
## Tasks
|
|
7
|
+
|
|
8
|
+
- [ ] task-001:
|
|
9
|
+
- [ ] task-002:
|
|
10
|
+
- [ ] task-003:
|
|
11
|
+
|
|
12
|
+
## Implementation Notes
|
|
13
|
+
Decisions made during planning that affect implementation.
|
|
14
|
+
|
|
15
|
+
## Lexis Tags Added
|
|
16
|
+
// lexis: comments added during implementation (updated as work progresses).
|