@lenardangeloolajay/len-toolkit 1.1.0 → 1.2.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/README.md +225 -209
- package/bin/cli.js +13 -0
- package/package.json +35 -35
- package/src/installer.js +7 -0
package/README.md
CHANGED
|
@@ -1,209 +1,225 @@
|
|
|
1
|
-
#
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
- `
|
|
136
|
-
- `
|
|
137
|
-
- `
|
|
138
|
-
- `
|
|
139
|
-
- `
|
|
140
|
-
- `
|
|
141
|
-
- `
|
|
142
|
-
- `
|
|
143
|
-
- `
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
|
|
186
|
-
|
|
187
|
-
|
|
188
|
-
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
##
|
|
197
|
-
|
|
198
|
-
|
|
199
|
-
|
|
200
|
-
|
|
201
|
-
|
|
202
|
-
|
|
203
|
-
|
|
204
|
-
|
|
205
|
-
|
|
206
|
-
|
|
207
|
-
|
|
208
|
-
|
|
209
|
-
|
|
1
|
+
# Foreword
|
|
2
|
+
|
|
3
|
+
Day by day AI keeps improving especially in the coding sector, I believe instead of hating it we should learn how to harness it.
|
|
4
|
+
Believe me that I'd rather learn from "scratch" and the "basics" but this is the world we live in.
|
|
5
|
+
Billions are invested in this sector and it will only keep on progressing no matter how much you hate it and as a software engineer it is essential for us to learn it in order to survive in this field.
|
|
6
|
+
And if you disagree with me, well you can **** off.
|
|
7
|
+
|
|
8
|
+
## Len's Toolkit
|
|
9
|
+
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
[](https://www.npmjs.com/package/@lenardangeloolajay/len-toolkit)
|
|
13
|
+
[](LICENSE)
|
|
14
|
+
|
|
15
|
+
> [!NOTE]
|
|
16
|
+
> **Collection Disclaimer and Attribution:**
|
|
17
|
+
> This repository is strictly a curated collection of tools, skills, and engineering rulesets sourced from experienced engineers across the software industry.
|
|
18
|
+
> I am not the author of these files, and I do not claim 100% ownership over them.
|
|
19
|
+
> I gathered and adapted these tools from other people to build a streamlined AI coding workflow, and I credit them fully for their work.
|
|
20
|
+
|
|
21
|
+
This repository contains my personal guidelines, rulesets, and skills for AI pair programming.
|
|
22
|
+
Feel free to copy whatever you want and create PRs!
|
|
23
|
+
Technically this is a disciplined ruleset designed to help build solid, high quality code instead of unverified slop.
|
|
24
|
+
|
|
25
|
+
A personal, dependency-free toolkit for Len's GPT-to-Antigravity workflow.
|
|
26
|
+
GPT explores the product and defines architecture with Len.
|
|
27
|
+
Len approves the specs and plan.
|
|
28
|
+
Gemini implements approved phases with checks and local commits.
|
|
29
|
+
|
|
30
|
+
## Start a project session
|
|
31
|
+
|
|
32
|
+
Run this from any project directory to initialize the toolkit:
|
|
33
|
+
|
|
34
|
+
```powershell
|
|
35
|
+
npx @lenardangeloolajay/len-toolkit start
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
To update installed skills and templates in an existing project to the latest version:
|
|
39
|
+
|
|
40
|
+
```powershell
|
|
41
|
+
npx @lenardangeloolajay/len-toolkit update
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
Alternatively, to run directly from a local checkout without using the npm registry, substitute its absolute path:
|
|
45
|
+
|
|
46
|
+
```powershell
|
|
47
|
+
npm exec --offline --package="C:\path\to\Len's_Toolkit" -- len-toolkit start
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
The local-package form was exercised with npm in a temporary project on Windows.
|
|
51
|
+
It does not require a global install.
|
|
52
|
+
Then launch your usual Antigravity CLI:
|
|
53
|
+
|
|
54
|
+
```powershell
|
|
55
|
+
agi
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
Tell the receiving agent: "Read project AGENTS.md and HANDOFF.md, follow their approved references, and execute the approved plan."
|
|
59
|
+
If the project has no approved handoff yet, work with GPT on the specs first.
|
|
60
|
+
Automatic Antigravity instruction discovery has not been verified here; explicitly point it to the files.
|
|
61
|
+
|
|
62
|
+
## What startup does
|
|
63
|
+
|
|
64
|
+
- Initializes Git only when there is no enclosing repository, reporting the branch and existing edits.
|
|
65
|
+
- Installs missing personal rules, 24 skills, reusable document templates, and basic development configs.
|
|
66
|
+
- Preserves existing files and reports differences with paths to the proposed versions.
|
|
67
|
+
- Checks whether Git can resolve author and committer identity without changing your configuration.
|
|
68
|
+
- Reports whether the index, handoff, and root plan exist, leaving content and approval review to the agent.
|
|
69
|
+
|
|
70
|
+
Startup does not approve work, create a second spec tree, launch an agent, stage files, commit, or push.
|
|
71
|
+
It refuses `--force` and `--global`; use the legacy commands only when their broader behavior is intended.
|
|
72
|
+
A successful exit means setup checks finished, not that differences are resolved or the project is approved for implementation.
|
|
73
|
+
A failed setup may have created a repository or installed some missing files before the error; address the reported issue and rerun safely.
|
|
74
|
+
Existing custom instructions require review, not an automatic overwrite disguised as an upgrade.
|
|
75
|
+
|
|
76
|
+
## The personal workflow
|
|
77
|
+
|
|
78
|
+
1. Explore the whole product with GPT in focused question rounds, including proposed defaults and unresolved requirements.
|
|
79
|
+
2. Settle planned features, main user flows, shared data, boundaries, architecture, and major constraints.
|
|
80
|
+
3. Approve the product baseline and architecture in chat.
|
|
81
|
+
4. Detail one feature's observable requirements, then its implementation plan; approve both in chat.
|
|
82
|
+
5. Maintain one current handoff with exact approved revisions, allowed phases, progress, checks, attempts, and next action.
|
|
83
|
+
6. Gemini implements each approved phase, verifies it, updates the records, reviews the staged diff, and commits only related changes.
|
|
84
|
+
7. Gemini continues automatically until the last approved phase or a real blocker.
|
|
85
|
+
|
|
86
|
+
A phase is complete only after passing required checks and a successful commit.
|
|
87
|
+
Interrupted or failing work remains uncommitted.
|
|
88
|
+
For the same unresolved problem, Gemini gets three unsuccessful fix-and-check attempts after the initial observed failure, then reports a blocker without resetting the count on resume.
|
|
89
|
+
Missing decisions, unavailable access or hardware, and necessary architecture changes block affected work immediately.
|
|
90
|
+
Gemini can report a disagreement but cannot silently replace approved architecture or add features.
|
|
91
|
+
Len's approval applies to specific revisions, not future substantive changes.
|
|
92
|
+
|
|
93
|
+
## Documents that stay organized
|
|
94
|
+
|
|
95
|
+
```text
|
|
96
|
+
project/
|
|
97
|
+
AGENTS.md Shared personal workflow
|
|
98
|
+
GEMINI.md Gemini entry point
|
|
99
|
+
HANDOFF.md One current handoff
|
|
100
|
+
IMPLEMENTATION_PLAN.md Optional pointer to the active plan
|
|
101
|
+
.agents/
|
|
102
|
+
skills/ Spec, Council, plan, and Ponytail suite
|
|
103
|
+
templates/docs/ Reusable templates, not active specs
|
|
104
|
+
docs/
|
|
105
|
+
SPEC_INDEX.md Current documents, revisions, and status
|
|
106
|
+
product/
|
|
107
|
+
OVERVIEW.md
|
|
108
|
+
ARCHITECTURE.md
|
|
109
|
+
DATA_MODEL.md
|
|
110
|
+
CONSTRAINTS.md
|
|
111
|
+
features/FEAT-001-name.md Behavior and acceptance criteria
|
|
112
|
+
plans/FEAT-001-implementation.md Tasks, checks, and phase progress
|
|
113
|
+
evidence/FEAT-001-verification.md
|
|
114
|
+
archive/ Superseded documents with replacement links
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
Create categories only when needed and adopt an existing project convention rather than duplicating it.
|
|
118
|
+
Search the index and current specs before creating a file.
|
|
119
|
+
Refinements update the existing feature spec; superseded documents move to the archive with replacement links and updated references.
|
|
120
|
+
Active filenames are stable, while creation and substantive-update timestamps inside documents use ISO 8601 with `+08:00`.
|
|
121
|
+
Requirements have stable IDs, and plans and evidence reference them.
|
|
122
|
+
Specs describe behavior; plans contain task checkboxes and commands.
|
|
123
|
+
|
|
124
|
+
Use [the fictional Flutter handoff](templates/examples/flutter-handoff/docs/SPEC_INDEX.md) to inspect a complete example.
|
|
125
|
+
Its approvals, implementation, and verification are deliberately pending.
|
|
126
|
+
[Inspection exercises](templates/examples/flutter-handoff/EXERCISES.md) cover reuse, supersession, interruption, retries, and evidence boundaries.
|
|
127
|
+
No fictional project has been tested on an emulator or device.
|
|
128
|
+
|
|
129
|
+
## Skills and templates
|
|
130
|
+
|
|
131
|
+
Len's Toolkit includes 24 curated skills across core workflow, security, and software engineering book principles:
|
|
132
|
+
|
|
133
|
+
### Core Workflow and Optimization Skills
|
|
134
|
+
|
|
135
|
+
- `spec`: product discovery, organized requirements, document reuse, and revision approval.
|
|
136
|
+
- `council`: consequential architecture trade-offs and failure modes before approval.
|
|
137
|
+
- `implementation-plan`: approved phases, verification, commits, and recovery.
|
|
138
|
+
- `ponytail`: reuse, standard-library-first implementation, and minimal necessary code.
|
|
139
|
+
- `ponytail-review` and `ponytail-audit`: complexity findings without automatic fixes.
|
|
140
|
+
- `ponytail-debt`: recorded deliberate shortcuts.
|
|
141
|
+
- `ponytail-gain`: attributable evidence only; no unsupported savings figures.
|
|
142
|
+
- `ponytail-help`: the Ponytail reference card.
|
|
143
|
+
- `security-audit`: security guidance, vulnerability review, and structured audit harness.
|
|
144
|
+
|
|
145
|
+
### Software Engineering Book Skills
|
|
146
|
+
|
|
147
|
+
Distilled rules from classic software engineering literature, adapted from [Maciej Ciemborowicz's agent-rules-books](https://github.com/ciembor/agent-rules-books):
|
|
148
|
+
|
|
149
|
+
- `a-philosophy-of-software-design`: complexity reduction and deep module boundaries (John Ousterhout).
|
|
150
|
+
- `clean-architecture`: separation of business policy from frameworks and details (Robert C. Martin).
|
|
151
|
+
- `clean-code`: readability, naming, small functions, and clean code hygiene (Robert C. Martin).
|
|
152
|
+
- `code-complete`: software construction, routine design, and defensive programming (Steve McConnell).
|
|
153
|
+
- `designing-data-intensive-applications`: reliability, scalability, and consistency in data systems (Martin Kleppmann).
|
|
154
|
+
- `domain-driven-design`: domain modeling, bounded contexts, and ubiquitous language (Eric Evans).
|
|
155
|
+
- `domain-driven-design-distilled`: lightweight domain modeling and subdomains (Vaughn Vernon).
|
|
156
|
+
- `implementing-domain-driven-design`: tactical DDD patterns, aggregates, and domain events (Vaughn Vernon).
|
|
157
|
+
- `patterns-of-enterprise-application-architecture`: enterprise layers, repositories, and mappers (Martin Fowler).
|
|
158
|
+
- `refactoring`: systematic code refactoring and mechanics (Martin Fowler).
|
|
159
|
+
- `refactoring-guru`: code smell diagnosis and refactoring technique catalogs (Refactoring.Guru).
|
|
160
|
+
- `release-it`: production stability, circuit breakers, and resilience (Michael T. Nygard).
|
|
161
|
+
- `the-pragmatic-programmer`: pragmatic judgment, orthogonality, and DRY principles (David Thomas and Andrew Hunt).
|
|
162
|
+
- `working-effectively-with-legacy-code`: safely modifying legacy systems with characterization tests and seams (Michael Feathers).
|
|
163
|
+
|
|
164
|
+
The shared policy lives in [the AGENTS template](templates/rules/AGENTS.md).
|
|
165
|
+
The [plan template](templates/docs/IMPLEMENTATION_PLAN.md) is used by both CLI plan generation and agent guidance.
|
|
166
|
+
Templates contain unresolved fields until the agent inspects the actual project; they are not ready-to-execute commands.
|
|
167
|
+
|
|
168
|
+
## Evidence, not promises
|
|
169
|
+
|
|
170
|
+
Record the requirement, actual command or scenario, environment, result, timestamp, and limitations.
|
|
171
|
+
Attach meaningful UI screenshots when available.
|
|
172
|
+
Emulator results establish emulator behavior only; Len performs physical-device checks.
|
|
173
|
+
Keep hardware-bench and field validation separate, with unrun checks explicitly pending.
|
|
174
|
+
Implementation, simulation, or an attractive spec does not prove effectiveness in the intended environment.
|
|
175
|
+
|
|
176
|
+
## Compatibility commands
|
|
177
|
+
|
|
178
|
+
```powershell
|
|
179
|
+
npx @lenardangeloolajay/len-toolkit --help
|
|
180
|
+
npx @lenardangeloolajay/len-toolkit update
|
|
181
|
+
npx @lenardangeloolajay/len-toolkit skills
|
|
182
|
+
npx @lenardangeloolajay/len-toolkit rules
|
|
183
|
+
npx @lenardangeloolajay/len-toolkit plan "Feature name"
|
|
184
|
+
npx @lenardangeloolajay/len-toolkit --yes
|
|
185
|
+
npx @lenardangeloolajay/len-toolkit skills --global
|
|
186
|
+
```
|
|
187
|
+
|
|
188
|
+
The legacy default remains an interactive installer.
|
|
189
|
+
Local skill installation also supplies document templates.
|
|
190
|
+
The legacy global skill destination remains `~/.gemini/config/skills/`; it is not the recommended personal setup and does not replace local startup.
|
|
191
|
+
The `plan` command writes a draft root `IMPLEMENTATION_PLAN.md` and preserves an existing file by default.
|
|
192
|
+
For categorized feature plans, use the spec/plan workflow and a root pointer instead of generating a second active plan.
|
|
193
|
+
Legacy `--force` overwrites existing selected files, including `.gitignore` and a root plan; it is never used by `start`.
|
|
194
|
+
Cursor-related compatibility files remain available but are not installed by personal startup.
|
|
195
|
+
|
|
196
|
+
## Local verification
|
|
197
|
+
|
|
198
|
+
The package advertises Node 18 or newer and uses no npm dependencies.
|
|
199
|
+
This change was exercised on Windows with Node 24.14.0; other supported runtime versions remain unverified here.
|
|
200
|
+
|
|
201
|
+
```powershell
|
|
202
|
+
npm test
|
|
203
|
+
node --check bin/cli.js
|
|
204
|
+
node --check src/installer.js
|
|
205
|
+
npm pack --dry-run --ignore-scripts
|
|
206
|
+
```
|
|
207
|
+
|
|
208
|
+
The automated suite exercises file preservation, CLI behavior, startup failure cases, enclosing repositories, and shared plan rendering.
|
|
209
|
+
Workflow exercises are instruction inspections, not proof that Gemini will always comply.
|
|
210
|
+
Publishing or pushing remains a separate explicit action.
|
|
211
|
+
|
|
212
|
+
## License and attribution
|
|
213
|
+
|
|
214
|
+
[MIT](LICENSE).
|
|
215
|
+
|
|
216
|
+
This repository is strictly a curated collection of tools and guidelines.
|
|
217
|
+
I am not the author of these files, and I do not claim 100% ownership over them.
|
|
218
|
+
I gathered these tools from other experienced engineers and credit them fully for their contributions:
|
|
219
|
+
|
|
220
|
+
- Ponytail derives from [Dietrich Gebert's Ponytail](https://github.com/DietrichGebert/ponytail).
|
|
221
|
+
- Council is inspired by [hex/claude-council](https://github.com/hex/claude-council).
|
|
222
|
+
- Security audit skill derives from [Cloudflare's security-audit-skill](https://github.com/cloudflare/security-audit-skill).
|
|
223
|
+
- Software engineering book skills derive from [Maciej Ciemborowicz's agent-rules-books](https://github.com/ciembor/agent-rules-books).
|
|
224
|
+
- Book summaries and architectural patterns are based on the published works of John Ousterhout, Robert C. Martin, Steve McConnell, Martin Kleppmann, Eric Evans, Vaughn Vernon, Martin Fowler, Michael T. Nygard, David Thomas, Andrew Hunt, Michael Feathers, and the authors of Refactoring.Guru.
|
|
225
|
+
All upstream authors retain copyright to their respective original works.
|
package/bin/cli.js
CHANGED
|
@@ -11,6 +11,7 @@ import process from 'node:process';
|
|
|
11
11
|
import { readFileSync } from 'node:fs';
|
|
12
12
|
import {
|
|
13
13
|
installSkills,
|
|
14
|
+
updateSkills,
|
|
14
15
|
installRules,
|
|
15
16
|
installConfigs,
|
|
16
17
|
createPlanTemplate,
|
|
@@ -53,6 +54,7 @@ function printHelp() {
|
|
|
53
54
|
|
|
54
55
|
\x1b[1mCOMMANDS:\x1b[0m
|
|
55
56
|
start Prepare local GPT/Antigravity workflow safely (recommended)
|
|
57
|
+
update Update installed skills library to latest version
|
|
56
58
|
init Initialize vibe coding environment in current project (default)
|
|
57
59
|
plan [name] Generate a phased IMPLEMENTATION_PLAN.md file
|
|
58
60
|
skills Install only the skills library (.agents/skills/)
|
|
@@ -216,6 +218,17 @@ async function main() {
|
|
|
216
218
|
return;
|
|
217
219
|
}
|
|
218
220
|
|
|
221
|
+
if (command === 'update') {
|
|
222
|
+
const dest = updateSkills(targetDir, flags.global);
|
|
223
|
+
if (flags.force) {
|
|
224
|
+
const rules = installRules(targetDir, true);
|
|
225
|
+
console.log(`\x1b[32m✓ Updated skills in ${dest} and rules: ${rules.join(', ')}\x1b[0m`);
|
|
226
|
+
} else {
|
|
227
|
+
console.log(`\x1b[32m✓ Updated skills in ${dest} to v${VERSION}\x1b[0m`);
|
|
228
|
+
}
|
|
229
|
+
return;
|
|
230
|
+
}
|
|
231
|
+
|
|
219
232
|
if (command === 'rules') {
|
|
220
233
|
const rules = installRules(targetDir, flags.force);
|
|
221
234
|
console.log(`\x1b[32m✓ Installed agent rules: ${rules.join(', ')}\x1b[0m`);
|
package/package.json
CHANGED
|
@@ -1,35 +1,35 @@
|
|
|
1
|
-
{
|
|
2
|
-
"name": "@lenardangeloolajay/len-toolkit",
|
|
3
|
-
"version": "1.
|
|
4
|
-
"description": "Len's personal GPT-to-Antigravity workflow: organized specs, explicit approval, safe startup, verified phase commits, and bounded recovery.",
|
|
5
|
-
"type": "module",
|
|
6
|
-
"bin": {
|
|
7
|
-
"len-toolkit": "bin/cli.js"
|
|
8
|
-
},
|
|
9
|
-
"files": [
|
|
10
|
-
"bin",
|
|
11
|
-
"src",
|
|
12
|
-
"templates",
|
|
13
|
-
"LICENSE",
|
|
14
|
-
"README.md"
|
|
15
|
-
],
|
|
16
|
-
"scripts": {
|
|
17
|
-
"start": "node ./bin/cli.js",
|
|
18
|
-
"test": "node --test \"test/**/*.test.js\""
|
|
19
|
-
},
|
|
20
|
-
"keywords": [
|
|
21
|
-
"antigravity",
|
|
22
|
-
"ai-agent",
|
|
23
|
-
"vibe-coding",
|
|
24
|
-
"skills",
|
|
25
|
-
"ponytail",
|
|
26
|
-
"claude-council",
|
|
27
|
-
"scaffold",
|
|
28
|
-
"cli"
|
|
29
|
-
],
|
|
30
|
-
"author": "Len",
|
|
31
|
-
"license": "MIT",
|
|
32
|
-
"engines": {
|
|
33
|
-
"node": ">=18.0.0"
|
|
34
|
-
}
|
|
35
|
-
}
|
|
1
|
+
{
|
|
2
|
+
"name": "@lenardangeloolajay/len-toolkit",
|
|
3
|
+
"version": "1.2.0",
|
|
4
|
+
"description": "Len's personal GPT-to-Antigravity workflow: organized specs, explicit approval, safe startup, verified phase commits, and bounded recovery.",
|
|
5
|
+
"type": "module",
|
|
6
|
+
"bin": {
|
|
7
|
+
"len-toolkit": "bin/cli.js"
|
|
8
|
+
},
|
|
9
|
+
"files": [
|
|
10
|
+
"bin",
|
|
11
|
+
"src",
|
|
12
|
+
"templates",
|
|
13
|
+
"LICENSE",
|
|
14
|
+
"README.md"
|
|
15
|
+
],
|
|
16
|
+
"scripts": {
|
|
17
|
+
"start": "node ./bin/cli.js",
|
|
18
|
+
"test": "node --test \"test/**/*.test.js\""
|
|
19
|
+
},
|
|
20
|
+
"keywords": [
|
|
21
|
+
"antigravity",
|
|
22
|
+
"ai-agent",
|
|
23
|
+
"vibe-coding",
|
|
24
|
+
"skills",
|
|
25
|
+
"ponytail",
|
|
26
|
+
"claude-council",
|
|
27
|
+
"scaffold",
|
|
28
|
+
"cli"
|
|
29
|
+
],
|
|
30
|
+
"author": "Len",
|
|
31
|
+
"license": "MIT",
|
|
32
|
+
"engines": {
|
|
33
|
+
"node": ">=18.0.0"
|
|
34
|
+
}
|
|
35
|
+
}
|
package/src/installer.js
CHANGED
|
@@ -80,6 +80,13 @@ export function installSkills(targetDir, isGlobal = false, overwrite = false) {
|
|
|
80
80
|
return destDir;
|
|
81
81
|
}
|
|
82
82
|
|
|
83
|
+
/**
|
|
84
|
+
* Updates skills in target directory to latest bundled version
|
|
85
|
+
*/
|
|
86
|
+
export function updateSkills(targetDir, isGlobal = false) {
|
|
87
|
+
return installSkills(targetDir, isGlobal, true);
|
|
88
|
+
}
|
|
89
|
+
|
|
83
90
|
function templateFiles(source, destination) {
|
|
84
91
|
return fs.readdirSync(source, { withFileTypes: true }).flatMap((entry) => {
|
|
85
92
|
const src = path.join(source, entry.name);
|