zaileys 2.2.7 → 3.0.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/.agent/skills/codebase-mapper/SKILL.md +226 -0
- package/.agent/skills/context-compressor/SKILL.md +201 -0
- package/.agent/skills/context-fetch/SKILL.md +184 -0
- package/.agent/skills/context-health-monitor/SKILL.md +105 -0
- package/.agent/skills/debugger/SKILL.md +273 -0
- package/.agent/skills/empirical-validation/SKILL.md +97 -0
- package/.agent/skills/executor/SKILL.md +465 -0
- package/.agent/skills/plan-checker/SKILL.md +283 -0
- package/.agent/skills/planner/SKILL.md +485 -0
- package/.agent/skills/token-budget/SKILL.md +166 -0
- package/.agent/skills/verifier/SKILL.md +421 -0
- package/.agent/workflows/add-phase.md +96 -0
- package/.agent/workflows/add-todo.md +69 -0
- package/.agent/workflows/audit-milestone.md +107 -0
- package/.agent/workflows/check-todos.md +80 -0
- package/.agent/workflows/complete-milestone.md +135 -0
- package/.agent/workflows/debug.md +235 -0
- package/.agent/workflows/discuss-phase.md +103 -0
- package/.agent/workflows/execute.md +325 -0
- package/.agent/workflows/health.md +122 -0
- package/.agent/workflows/help.md +96 -0
- package/.agent/workflows/insert-phase.md +109 -0
- package/.agent/workflows/install.md +152 -0
- package/.agent/workflows/list-phase-assumptions.md +82 -0
- package/.agent/workflows/map.md +394 -0
- package/.agent/workflows/new-milestone.md +126 -0
- package/.agent/workflows/new-project.md +368 -0
- package/.agent/workflows/pause.md +176 -0
- package/.agent/workflows/plan-milestone-gaps.md +116 -0
- package/.agent/workflows/plan.md +380 -0
- package/.agent/workflows/progress.md +90 -0
- package/.agent/workflows/quick.md +128 -0
- package/.agent/workflows/remove-phase.md +139 -0
- package/.agent/workflows/research-phase.md +160 -0
- package/.agent/workflows/resume.md +131 -0
- package/.agent/workflows/update.md +203 -0
- package/.agent/workflows/verify.md +263 -0
- package/.agent/workflows/web-search.md +121 -0
- package/.agent/workflows/whats-new.md +80 -0
- package/.gemini/GEMINI.md +67 -0
- package/.gsd/DEBUG.md +26 -0
- package/.gsd/GSD-STYLE.md +272 -0
- package/.gsd/PROJECT_RULES.md +256 -0
- package/.gsd/ROADMAP.md +38 -0
- package/.gsd/SPEC.md +16 -0
- package/.gsd/STATE.md +10 -0
- package/.gsd/adapters/CLAUDE.md +77 -0
- package/.gsd/adapters/GEMINI.md +92 -0
- package/.gsd/adapters/GPT_OSS.md +130 -0
- package/.gsd/docs/model-selection-playbook.md +128 -0
- package/.gsd/docs/runbook.md +296 -0
- package/.gsd/docs/token-optimization-guide.md +207 -0
- package/.gsd/model_capabilities.yaml +108 -0
- package/.gsd/phases/1/1-PLAN.md +44 -0
- package/.gsd/phases/1/2-PLAN.md +54 -0
- package/.gsd/phases/1/3-PLAN.md +46 -0
- package/.gsd/phases/1/4-PLAN.md +39 -0
- package/.gsd/phases/2/2-1-SUMMARY.md +8 -0
- package/.gsd/phases/2/2-PLAN.md +47 -0
- package/.gsd/phases/3/3-1-SUMMARY.md +8 -0
- package/.gsd/phases/3/3-PLAN.md +43 -0
- package/.gsd/phases/4/4-1-PLAN.md +44 -0
- package/.gsd/phases/4/4-1-SUMMARY.md +8 -0
- package/.gsd/phases/4/4-2-PLAN.md +59 -0
- package/.gsd/phases/4/4-2-SUMMARY.md +8 -0
- package/.gsd/phases/4/4-3-PLAN.md +42 -0
- package/.gsd/phases/4/4-3-SUMMARY.md +8 -0
- package/.gsd/phases/4/VERIFICATION.md +8 -0
- package/.gsd/phases/5/1-SUMMARY.md +5 -0
- package/.gsd/phases/5/5-PLAN.md +47 -0
- package/.gsd/phases/5/RESEARCH.md +24 -0
- package/.gsd/phases/5/VERIFICATION.md +8 -0
- package/.gsd/phases/6/1-SUMMARY.md +6 -0
- package/.gsd/phases/6/6-PLAN.md +46 -0
- package/.gsd/phases/6/RESEARCH.md +33 -0
- package/.gsd/phases/6/VERIFICATION.md +7 -0
- package/.gsd/phases/7/1-SUMMARY.md +12 -0
- package/.gsd/phases/7/7-PLAN.md +78 -0
- package/.gsd/phases/7/VERIFICATION.md +7 -0
- package/.gsd/templates/DEBUG.md +123 -0
- package/.gsd/templates/PLAN.md +90 -0
- package/.gsd/templates/RESEARCH.md +75 -0
- package/.gsd/templates/SUMMARY.md +103 -0
- package/.gsd/templates/UAT.md +168 -0
- package/.gsd/templates/VERIFICATION.md +70 -0
- package/.gsd/templates/architecture.md +67 -0
- package/.gsd/templates/context.md +91 -0
- package/.gsd/templates/decisions.md +37 -0
- package/.gsd/templates/discovery.md +122 -0
- package/.gsd/templates/journal.md +46 -0
- package/.gsd/templates/milestone.md +91 -0
- package/.gsd/templates/phase-summary.md +52 -0
- package/.gsd/templates/project.md +124 -0
- package/.gsd/templates/requirements.md +92 -0
- package/.gsd/templates/roadmap.md +103 -0
- package/.gsd/templates/spec.md +51 -0
- package/.gsd/templates/sprint.md +57 -0
- package/.gsd/templates/stack.md +62 -0
- package/.gsd/templates/state.md +92 -0
- package/.gsd/templates/state_snapshot.md +132 -0
- package/.gsd/templates/todo.md +32 -0
- package/.gsd/templates/token_report.md +79 -0
- package/.gsd/templates/user-setup.md +116 -0
- package/.husky/commit-msg +1 -0
- package/.husky/pre-commit +1 -0
- package/LICENSE +21 -21
- package/README.MD +1280 -1230
- package/commitlint.config.js +3 -0
- package/dist/index.d.mts +1397 -908
- package/dist/index.d.ts +1397 -908
- package/dist/index.js +29 -28
- package/dist/index.mjs +29 -28
- package/package.json +11 -27
- package/tsconfig.json +19 -19
|
@@ -0,0 +1,272 @@
|
|
|
1
|
+
# GSD-STYLE.md
|
|
2
|
+
|
|
3
|
+
> **Comprehensive reference.** Core rules auto-load from `.gemini/GEMINI.md`. This document provides deep explanations and examples for when you need the full picture.
|
|
4
|
+
|
|
5
|
+
This document explains how GSD is written so future AI instances can contribute consistently.
|
|
6
|
+
|
|
7
|
+
## Core Philosophy
|
|
8
|
+
|
|
9
|
+
GSD is a **meta-prompting system** where every file is both implementation and specification. Files teach the AI how to build software systematically. The system optimizes for:
|
|
10
|
+
|
|
11
|
+
- **Solo developer + AI workflow** (no enterprise patterns)
|
|
12
|
+
- **Context engineering** (manage the context window deliberately)
|
|
13
|
+
- **Plans as prompts** (PLAN.md files are executable, not documents to transform)
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## File Structure Conventions
|
|
18
|
+
|
|
19
|
+
### Workflows (`.agent/workflows/*.md`)
|
|
20
|
+
|
|
21
|
+
Slash commands the user invokes. Each workflow:
|
|
22
|
+
- Has YAML frontmatter with `description`
|
|
23
|
+
- Contains XML-structured process blocks
|
|
24
|
+
- Ends with "Next Steps" routing
|
|
25
|
+
|
|
26
|
+
### Skills (`.agent/skills/*/SKILL.md`)
|
|
27
|
+
|
|
28
|
+
Specialized agent behaviors. Each skill:
|
|
29
|
+
- Has YAML frontmatter with `name` and `description`
|
|
30
|
+
- Contains detailed methodology
|
|
31
|
+
- Is referenced by parent workflows
|
|
32
|
+
|
|
33
|
+
### Templates (`.gsd/templates/*.md`)
|
|
34
|
+
|
|
35
|
+
Reusable document structures. Copy, don't reference.
|
|
36
|
+
|
|
37
|
+
### References (`.gsd/examples/*.md`)
|
|
38
|
+
|
|
39
|
+
Read-only documentation and examples.
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## XML Tag Conventions
|
|
44
|
+
|
|
45
|
+
### Semantic Containers Only
|
|
46
|
+
|
|
47
|
+
Use XML tags for semantic meaning, not formatting:
|
|
48
|
+
|
|
49
|
+
```markdown
|
|
50
|
+
<role>
|
|
51
|
+
You are a GSD executor...
|
|
52
|
+
</role>
|
|
53
|
+
|
|
54
|
+
<objective>
|
|
55
|
+
Execute all plans in a phase...
|
|
56
|
+
</objective>
|
|
57
|
+
|
|
58
|
+
<process>
|
|
59
|
+
## 1. First Step
|
|
60
|
+
...
|
|
61
|
+
</process>
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
### Task Structure
|
|
65
|
+
|
|
66
|
+
```xml
|
|
67
|
+
<task type="auto" effort="medium">
|
|
68
|
+
<name>Clear descriptive name</name>
|
|
69
|
+
<files>exact/path/to/file.ts</files>
|
|
70
|
+
<action>
|
|
71
|
+
Specific implementation instructions.
|
|
72
|
+
AVOID: common mistake (reason)
|
|
73
|
+
USE: preferred approach (reason)
|
|
74
|
+
</action>
|
|
75
|
+
<verify>executable command that proves completion</verify>
|
|
76
|
+
<done>measurable acceptance criteria</done>
|
|
77
|
+
</task>
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
### Effort Attribute (Optional)
|
|
81
|
+
|
|
82
|
+
The `effort` attribute hints at task complexity for model selection:
|
|
83
|
+
|
|
84
|
+
| Value | Use Case | Model Hint |
|
|
85
|
+
|-------|----------|------------|
|
|
86
|
+
| `low` | Simple edits, formatting | Fast models |
|
|
87
|
+
| `medium` | Standard implementation (default) | Standard models |
|
|
88
|
+
| `high` | Complex logic, refactoring | Reasoning models |
|
|
89
|
+
| `max` | Architecture, security-critical | Deep reasoning |
|
|
90
|
+
|
|
91
|
+
**Default:** `medium` if omitted. No workflow should fail if this attribute is absent.
|
|
92
|
+
|
|
93
|
+
See [docs/model-selection-playbook.md](docs/model-selection-playbook.md) for model selection guidance.
|
|
94
|
+
|
|
95
|
+
|
|
96
|
+
### Checkpoint Structure
|
|
97
|
+
|
|
98
|
+
```xml
|
|
99
|
+
<task type="checkpoint:human-verify">
|
|
100
|
+
<name>Verify UI renders correctly</name>
|
|
101
|
+
<action>User reviews the rendered component</action>
|
|
102
|
+
<verify>User confirms visual correctness</verify>
|
|
103
|
+
</task>
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
|
|
108
|
+
## Language & Tone
|
|
109
|
+
|
|
110
|
+
### Imperative Voice
|
|
111
|
+
- ✅ "Create the file"
|
|
112
|
+
- ❌ "You should create the file"
|
|
113
|
+
- ❌ "We will create the file"
|
|
114
|
+
|
|
115
|
+
### No Filler
|
|
116
|
+
- ✅ "Run `npm test`"
|
|
117
|
+
- ❌ "Now let's go ahead and run `npm test`"
|
|
118
|
+
|
|
119
|
+
### No Sycophancy
|
|
120
|
+
- ✅ "Phase complete."
|
|
121
|
+
- ❌ "Great job! Phase complete!"
|
|
122
|
+
|
|
123
|
+
### Brevity with Substance
|
|
124
|
+
Every sentence should convey information. Remove words that don't add meaning.
|
|
125
|
+
|
|
126
|
+
---
|
|
127
|
+
|
|
128
|
+
## Context Engineering
|
|
129
|
+
|
|
130
|
+
### Size Constraints
|
|
131
|
+
|
|
132
|
+
| Context Usage | Quality |
|
|
133
|
+
|---------------|---------|
|
|
134
|
+
| 0-30% | PEAK — Thorough, comprehensive |
|
|
135
|
+
| 30-50% | GOOD — Confident, solid work |
|
|
136
|
+
| 50-70% | DEGRADING — Efficiency mode begins |
|
|
137
|
+
| 70%+ | POOR — Rushed, minimal |
|
|
138
|
+
|
|
139
|
+
**Rule:** Plans should complete within ~50% context.
|
|
140
|
+
|
|
141
|
+
### Fresh Context Pattern
|
|
142
|
+
|
|
143
|
+
When spawning subprocesses (plans, tasks), they get:
|
|
144
|
+
- The specific plan being executed
|
|
145
|
+
- Minimal necessary context from parent files
|
|
146
|
+
- NO accumulated orchestrator state
|
|
147
|
+
|
|
148
|
+
### State Preservation
|
|
149
|
+
|
|
150
|
+
STATE.md exists because context windows are temporary.
|
|
151
|
+
Everything important goes in STATE.md so the next session can continue.
|
|
152
|
+
|
|
153
|
+
---
|
|
154
|
+
|
|
155
|
+
## Anti-Patterns to Avoid
|
|
156
|
+
|
|
157
|
+
### Enterprise Patterns (Banned)
|
|
158
|
+
|
|
159
|
+
❌ Stakeholder communication
|
|
160
|
+
❌ Team coordination
|
|
161
|
+
❌ Sprint ceremonies
|
|
162
|
+
❌ Multiple approval levels
|
|
163
|
+
❌ Separate environments requiring explicit promotion
|
|
164
|
+
|
|
165
|
+
### Temporal Language (Banned in Implementation Docs)
|
|
166
|
+
|
|
167
|
+
❌ "First, we'll..."
|
|
168
|
+
❌ "Next, we should..."
|
|
169
|
+
❌ "Finally, we'll..."
|
|
170
|
+
|
|
171
|
+
### Generic XML (Banned)
|
|
172
|
+
|
|
173
|
+
```xml
|
|
174
|
+
<!-- DON'T -->
|
|
175
|
+
<section>
|
|
176
|
+
<title>Authentication</title>
|
|
177
|
+
<content>...</content>
|
|
178
|
+
</section>
|
|
179
|
+
|
|
180
|
+
<!-- DO -->
|
|
181
|
+
<task type="auto">
|
|
182
|
+
<name>Create login endpoint</name>
|
|
183
|
+
...
|
|
184
|
+
</task>
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
### Vague Tasks (Banned)
|
|
188
|
+
|
|
189
|
+
```xml
|
|
190
|
+
<!-- DON'T -->
|
|
191
|
+
<action>Implement authentication</action>
|
|
192
|
+
|
|
193
|
+
<!-- DO -->
|
|
194
|
+
<action>
|
|
195
|
+
Create POST /api/auth/login endpoint.
|
|
196
|
+
Accept {email, password} JSON body.
|
|
197
|
+
Query User by email, compare with bcrypt.
|
|
198
|
+
Return JWT in httpOnly cookie on success.
|
|
199
|
+
Return 401 on failure.
|
|
200
|
+
</action>
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
---
|
|
204
|
+
|
|
205
|
+
## Commit Conventions
|
|
206
|
+
|
|
207
|
+
### Format
|
|
208
|
+
```
|
|
209
|
+
type(scope): description
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
### Types
|
|
213
|
+
| Type | Use For |
|
|
214
|
+
|------|---------|
|
|
215
|
+
| `feat` | New feature |
|
|
216
|
+
| `fix` | Bug fix |
|
|
217
|
+
| `docs` | Documentation |
|
|
218
|
+
| `refactor` | Code restructure |
|
|
219
|
+
| `test` | Add tests |
|
|
220
|
+
| `chore` | Maintenance |
|
|
221
|
+
|
|
222
|
+
### Rules
|
|
223
|
+
- One task = one commit
|
|
224
|
+
- Scope is phase number for phase work
|
|
225
|
+
- No commit before verification passes
|
|
226
|
+
|
|
227
|
+
---
|
|
228
|
+
|
|
229
|
+
## UX Patterns
|
|
230
|
+
|
|
231
|
+
### Banners
|
|
232
|
+
|
|
233
|
+
```
|
|
234
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
235
|
+
GSD ► STATUS MESSAGE
|
|
236
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
237
|
+
```
|
|
238
|
+
|
|
239
|
+
### "Next Up" Format
|
|
240
|
+
|
|
241
|
+
```
|
|
242
|
+
───────────────────────────────────────────────────────
|
|
243
|
+
|
|
244
|
+
▶ NEXT
|
|
245
|
+
|
|
246
|
+
/command — description
|
|
247
|
+
|
|
248
|
+
───────────────────────────────────────────────────────
|
|
249
|
+
```
|
|
250
|
+
|
|
251
|
+
### Decision Gates
|
|
252
|
+
|
|
253
|
+
When user input needed:
|
|
254
|
+
```
|
|
255
|
+
⚠️ DECISION REQUIRED
|
|
256
|
+
|
|
257
|
+
Option A: {description}
|
|
258
|
+
Option B: {description}
|
|
259
|
+
|
|
260
|
+
Which do you prefer?
|
|
261
|
+
```
|
|
262
|
+
|
|
263
|
+
---
|
|
264
|
+
|
|
265
|
+
## Summary: Core Meta-Patterns
|
|
266
|
+
|
|
267
|
+
1. **Plans are prompts** — PLAN.md is read and executed directly
|
|
268
|
+
2. **Fresh context for execution** — Each plan runs in clean context
|
|
269
|
+
3. **STATE.md is memory** — Everything important persists there
|
|
270
|
+
4. **Verify before done** — No "trust me, it works"
|
|
271
|
+
5. **Aggressive atomicity** — Small tasks, atomic commits
|
|
272
|
+
6. **No enterprise theater** — Solo dev + AI workflow only
|
|
@@ -0,0 +1,256 @@
|
|
|
1
|
+
# PROJECT_RULES.md — GSD Canonical Rules
|
|
2
|
+
|
|
3
|
+
> **Single Source of Truth** for the Get Shit Done methodology.
|
|
4
|
+
>
|
|
5
|
+
> Model-agnostic. All adapters and extensions reference this file.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Core Protocol
|
|
10
|
+
|
|
11
|
+
**SPEC → PLAN → EXECUTE → VERIFY → COMMIT**
|
|
12
|
+
|
|
13
|
+
1. **SPEC**: Define requirements in `.gsd/SPEC.md` until status is `FINALIZED`
|
|
14
|
+
2. **PLAN**: Decompose into phases in `.gsd/ROADMAP.md`, then detailed plans
|
|
15
|
+
3. **EXECUTE**: Implement with atomic commits per task
|
|
16
|
+
4. **VERIFY**: Prove completion with empirical evidence
|
|
17
|
+
5. **COMMIT**: One task = one commit, message format: `type(scope): description`
|
|
18
|
+
|
|
19
|
+
**Planning Lock**: No implementation code until SPEC.md contains "Status: FINALIZED".
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Proof Requirements
|
|
24
|
+
|
|
25
|
+
Every change requires verification evidence:
|
|
26
|
+
|
|
27
|
+
| Change Type | Required Proof |
|
|
28
|
+
|-------------|----------------|
|
|
29
|
+
| API endpoint | curl/HTTP response |
|
|
30
|
+
| UI change | Screenshot |
|
|
31
|
+
| Build/compile | Command output |
|
|
32
|
+
| Test | Test runner output |
|
|
33
|
+
| Config | Verification command |
|
|
34
|
+
|
|
35
|
+
**Never accept**: "It looks correct", "This should work", "I've done similar before".
|
|
36
|
+
|
|
37
|
+
**Always require**: Captured output, screenshot, or test result.
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## Search-First Discipline
|
|
42
|
+
|
|
43
|
+
**Before reading any file completely:**
|
|
44
|
+
|
|
45
|
+
1. **Search first** — Use grep, ripgrep, or IDE search to find relevant snippets
|
|
46
|
+
2. **Evaluate snippets** — Determine if full file read is justified
|
|
47
|
+
3. **Targeted reads** — Only read specific line ranges when needed
|
|
48
|
+
|
|
49
|
+
**Benefits:**
|
|
50
|
+
- Reduces context pollution
|
|
51
|
+
- Faster understanding of large codebases
|
|
52
|
+
- Prevents reading irrelevant code
|
|
53
|
+
|
|
54
|
+
**Anti-pattern**: Reading entire files "to understand the context" without searching first.
|
|
55
|
+
|
|
56
|
+
---
|
|
57
|
+
|
|
58
|
+
## Wave Execution
|
|
59
|
+
|
|
60
|
+
Plans are grouped into **waves** based on dependencies:
|
|
61
|
+
|
|
62
|
+
| Wave | Characteristic | Execution |
|
|
63
|
+
|------|----------------|-----------|
|
|
64
|
+
| 1 | Foundation tasks, no dependencies | Run in parallel |
|
|
65
|
+
| 2 | Depends on Wave 1 | Wait for Wave 1, then parallel |
|
|
66
|
+
| 3 | Depends on Wave 2 | Wait for Wave 2, then parallel |
|
|
67
|
+
|
|
68
|
+
**Wave Completion Protocol:**
|
|
69
|
+
1. All tasks in wave verified
|
|
70
|
+
2. State snapshot created
|
|
71
|
+
3. Commit all wave work
|
|
72
|
+
4. Update STATE.md with position
|
|
73
|
+
|
|
74
|
+
---
|
|
75
|
+
|
|
76
|
+
## State Snapshots
|
|
77
|
+
|
|
78
|
+
At the end of each wave or significant work block, create a state snapshot:
|
|
79
|
+
|
|
80
|
+
```markdown
|
|
81
|
+
## Wave N Summary
|
|
82
|
+
|
|
83
|
+
**Objective:** {what this wave aimed to accomplish}
|
|
84
|
+
|
|
85
|
+
**Changes:**
|
|
86
|
+
- {change 1}
|
|
87
|
+
- {change 2}
|
|
88
|
+
|
|
89
|
+
**Files Touched:**
|
|
90
|
+
- {file1}
|
|
91
|
+
- {file2}
|
|
92
|
+
|
|
93
|
+
**Verification:**
|
|
94
|
+
- {command}: {result}
|
|
95
|
+
|
|
96
|
+
**Risks/Debt:**
|
|
97
|
+
- {any concerns}
|
|
98
|
+
|
|
99
|
+
**Next Wave TODO:**
|
|
100
|
+
- {item 1}
|
|
101
|
+
- {item 2}
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
---
|
|
105
|
+
|
|
106
|
+
## Model Independence
|
|
107
|
+
|
|
108
|
+
**Absolute Rule**: No rule, workflow, or skill may require a specific model provider.
|
|
109
|
+
|
|
110
|
+
**Allowed:**
|
|
111
|
+
- Optional adapters with provider-specific enhancements
|
|
112
|
+
- Capability-based recommendations (e.g., "use a reasoning model for planning")
|
|
113
|
+
- Examples mentioning specific models as illustrations
|
|
114
|
+
|
|
115
|
+
**Forbidden:**
|
|
116
|
+
- Hard dependencies on provider features
|
|
117
|
+
- Breaking behavior when a specific model is unavailable
|
|
118
|
+
- Duplicating canonical rules in adapters
|
|
119
|
+
|
|
120
|
+
**Adapter Pattern:**
|
|
121
|
+
```
|
|
122
|
+
.gsd/adapters/
|
|
123
|
+
├── CLAUDE.md # Optional Claude enhancements
|
|
124
|
+
├── GEMINI.md # Optional Gemini enhancements
|
|
125
|
+
└── GPT_OSS.md # Optional GPT/OSS enhancements
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
Each adapter must begin with:
|
|
129
|
+
> "Everything in this file is optional. For canonical rules, see PROJECT_RULES.md."
|
|
130
|
+
|
|
131
|
+
---
|
|
132
|
+
|
|
133
|
+
## Commit Conventions
|
|
134
|
+
|
|
135
|
+
**Format:**
|
|
136
|
+
```
|
|
137
|
+
type(scope): description
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
**Types:**
|
|
141
|
+
| Type | Usage |
|
|
142
|
+
|------|-------|
|
|
143
|
+
| `feat` | New feature |
|
|
144
|
+
| `fix` | Bug fix |
|
|
145
|
+
| `docs` | Documentation only |
|
|
146
|
+
| `refactor` | Code restructure (no behavior change) |
|
|
147
|
+
| `test` | Adding/updating tests |
|
|
148
|
+
| `chore` | Maintenance, dependencies |
|
|
149
|
+
|
|
150
|
+
**Rules:**
|
|
151
|
+
- One task = one commit
|
|
152
|
+
- Verify before commit
|
|
153
|
+
- Scope = phase number for phase work (e.g., `feat(phase-1): ...`)
|
|
154
|
+
|
|
155
|
+
---
|
|
156
|
+
|
|
157
|
+
## Repository Structure
|
|
158
|
+
|
|
159
|
+
```
|
|
160
|
+
.agent/
|
|
161
|
+
├── workflows/ # Slash commands (/plan, /execute, etc.)
|
|
162
|
+
└── skills/ # Agent specializations
|
|
163
|
+
|
|
164
|
+
.gemini/ # Gemini-specific configuration
|
|
165
|
+
.gsd/ # Project state and artifacts
|
|
166
|
+
├── PROJECT_RULES.md # ← This file (canonical rules)
|
|
167
|
+
├── GSD-STYLE.md # Style and conventions
|
|
168
|
+
├── SPEC.md # Requirements (must be FINALIZED)
|
|
169
|
+
├── ROADMAP.md # Phases and progress
|
|
170
|
+
├── STATE.md # Session memory
|
|
171
|
+
├── templates/ # Document templates
|
|
172
|
+
├── examples/ # Usage examples
|
|
173
|
+
├── adapters/ # Optional model-specific enhancements
|
|
174
|
+
├── docs/ # Operational documentation
|
|
175
|
+
└── scripts/ # Utility scripts
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
---
|
|
179
|
+
|
|
180
|
+
## Context Management
|
|
181
|
+
|
|
182
|
+
**Context Quality Thresholds:**
|
|
183
|
+
|
|
184
|
+
| Usage | Quality |
|
|
185
|
+
|-------|---------|
|
|
186
|
+
| 0-30% | **PEAK** — Comprehensive, thorough work |
|
|
187
|
+
| 30-50% | **GOOD** — Solid, confident output |
|
|
188
|
+
| 50-70% | **DEGRADING** — Efficiency mode |
|
|
189
|
+
| 70%+ | **POOR** — Rushed, incomplete |
|
|
190
|
+
|
|
191
|
+
**Context Hygiene Rules:**
|
|
192
|
+
- Keep plans under 50% context usage
|
|
193
|
+
- Fresh context for each plan execution
|
|
194
|
+
- After 3 debugging failures → state dump → fresh session
|
|
195
|
+
- STATE.md = memory across sessions
|
|
196
|
+
|
|
197
|
+
---
|
|
198
|
+
|
|
199
|
+
## Token Efficiency Rules
|
|
200
|
+
|
|
201
|
+
**Goal:** Minimize token consumption while maintaining output quality.
|
|
202
|
+
|
|
203
|
+
### Loading Rules
|
|
204
|
+
|
|
205
|
+
| Action | Rule |
|
|
206
|
+
|--------|------|
|
|
207
|
+
| Before reading file | Search first (grep, ripgrep) |
|
|
208
|
+
| File >200 lines | Use outline, not full file |
|
|
209
|
+
| File already understood | Reference summary, don't reload |
|
|
210
|
+
| >5 files needed | Stop, reconsider approach |
|
|
211
|
+
|
|
212
|
+
### Budget Thresholds
|
|
213
|
+
|
|
214
|
+
| Usage | Action Required |
|
|
215
|
+
|-------|-----------------|
|
|
216
|
+
| 0-50% | Proceed normally |
|
|
217
|
+
| 50-70% | Switch to outline mode, compress context |
|
|
218
|
+
| 70%+ | State dump required, recommend fresh session |
|
|
219
|
+
|
|
220
|
+
### Compression Protocol
|
|
221
|
+
|
|
222
|
+
After understanding a file:
|
|
223
|
+
1. Create summary in STATE.md or task notes
|
|
224
|
+
2. Reference summary instead of re-reading
|
|
225
|
+
3. Only reload specific sections if needed
|
|
226
|
+
|
|
227
|
+
### Per-Wave Efficiency
|
|
228
|
+
|
|
229
|
+
- Start each wave with minimal context
|
|
230
|
+
- Load files just-in-time (when task requires)
|
|
231
|
+
- Compress/summarize before moving to next wave
|
|
232
|
+
- Document token usage in state snapshots (optional)
|
|
233
|
+
|
|
234
|
+
**Anti-patterns:**
|
|
235
|
+
- Loading files "just in case"
|
|
236
|
+
- Re-reading files already understood
|
|
237
|
+
- Full file reads when snippets suffice
|
|
238
|
+
- Ignoring budget warnings
|
|
239
|
+
|
|
240
|
+
---
|
|
241
|
+
|
|
242
|
+
## Quick Reference
|
|
243
|
+
|
|
244
|
+
```
|
|
245
|
+
Before coding → SPEC.md must be FINALIZED
|
|
246
|
+
Before file read → Search first, then targeted read
|
|
247
|
+
After each task → Commit + update STATE.md
|
|
248
|
+
After each wave → State snapshot
|
|
249
|
+
After 3 failures → State dump + fresh session
|
|
250
|
+
Before "Done" → Empirical proof captured
|
|
251
|
+
```
|
|
252
|
+
|
|
253
|
+
---
|
|
254
|
+
|
|
255
|
+
*GSD Methodology — Model-Agnostic Edition*
|
|
256
|
+
*Reference implementation for multi-LLM environments*
|
package/.gsd/ROADMAP.md
ADDED
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
# ROADMAP.md
|
|
2
|
+
|
|
3
|
+
> **Current Phase**: 1
|
|
4
|
+
> **Milestone**: v1.0
|
|
5
|
+
|
|
6
|
+
## Must-Haves (from SPEC)
|
|
7
|
+
- [ ] Replace jetdb with lmdb
|
|
8
|
+
- [ ] Ensure project compiles successfully
|
|
9
|
+
|
|
10
|
+
## Phases
|
|
11
|
+
|
|
12
|
+
### Phase 1: Database Migration
|
|
13
|
+
**Status**: ✅ Completed
|
|
14
|
+
**Objective**: Drop jetdb entirely and replace with direct LMDB integration across Config, Auth, Client, Health, and Listeners.
|
|
15
|
+
|
|
16
|
+
### Phase 2: Utility Modernization (Radashi Migration)
|
|
17
|
+
**Status**: ✅ Completed
|
|
18
|
+
**Objective**: Replace `lodash` completely and refactor complex native javascript abstractions (chunking, deep nesting, validation) into elegant `radashi` utility functional equivalents to reduce boilerplate and complexity.
|
|
19
|
+
|
|
20
|
+
### Phase 3: Unorm Elimination
|
|
21
|
+
**Status**: ✅ Completed
|
|
22
|
+
**Objective**: Remove the heavy `unorm` library dependency and replace all Unicode formatting functionalities (e.g., `unorm.nfkc`) with modern Native V8 equivalents like `String.prototype.normalize()`.
|
|
23
|
+
|
|
24
|
+
### Phase 4: Validation Migration (Zod -> Valibot)
|
|
25
|
+
**Status**: ✅ Completed
|
|
26
|
+
**Objective**: Drop `zod` and `zod-validation-error` completely. Migrate the entire codebase schema definition and validation engine to `valibot` for a drastically smaller bundle size and purely functional APIs.
|
|
27
|
+
|
|
28
|
+
### Phase 5: Media Processing Mega Refactor (FFmpeg Core)
|
|
29
|
+
**Status**: ✅ Completed
|
|
30
|
+
**Objective**: Overhaul `audio.ts`, `video.ts`, `document.ts`, `core.ts`, and `index.ts` to implement best-practice WhatsApp media processing, strict format conversions (Opus OGGs, H264 MP4s), and improve error handling/efficiency.
|
|
31
|
+
|
|
32
|
+
### Phase 6: Media Processing DX Overhaul
|
|
33
|
+
**Status**: ✅ Completed
|
|
34
|
+
**Objective**: Redesign the structural export logic and Developer Experience (DX) for `media-modifier.ts` and underlying FFmpeg wrappers. Abstract everything into a seamless, unified Builder/Facade API that simplifies end-user code and encapsulates buffer streams smoothly.
|
|
35
|
+
|
|
36
|
+
### Phase 7: Extracting Media Handler to NPM
|
|
37
|
+
**Status**: ✅ Completed
|
|
38
|
+
**Objective**: Extract the `ffmpeg` library and `media-modifier.ts` to a standalone local NPM package `@zaadevofc/media-process` using `pnpm` workspaces. This uncouples heavy media bindings from the core WhatsApp connector matrix.
|
package/.gsd/SPEC.md
ADDED
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
# SPEC.md — Project Specification
|
|
2
|
+
|
|
3
|
+
> **Status**: `FINALIZED`
|
|
4
|
+
|
|
5
|
+
## Vision
|
|
6
|
+
Replace `jetdb` with `lmdb` across the zaileys codebase to ensure a more efficient, powerful, fast, and reliable database system without relying on abstract wrappers.
|
|
7
|
+
|
|
8
|
+
## Goals
|
|
9
|
+
1. Remove `jetdb` dependency completely.
|
|
10
|
+
2. Integrate `lmdb` natively into the configuration.
|
|
11
|
+
3. Rewrite consumers (Auth, Health, Client, Listeners) to leverage native key-value API and range operations.
|
|
12
|
+
|
|
13
|
+
## Success Criteria
|
|
14
|
+
- [ ] `jetdb` is removed from `package.json`
|
|
15
|
+
- [ ] `lmdb` is added to `package.json`
|
|
16
|
+
- [ ] Project builds successfully without type errors (`npm run build`).
|
package/.gsd/STATE.md
ADDED
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
## Current Position
|
|
2
|
+
- **Phase**: 7 (completed)
|
|
3
|
+
- **Task**: All tasks complete
|
|
4
|
+
- **Status**: Verified
|
|
5
|
+
|
|
6
|
+
## Last Session Summary
|
|
7
|
+
Phase 7 executed successfully. 1 plans, 3 tasks completed.
|
|
8
|
+
|
|
9
|
+
## Next Steps
|
|
10
|
+
All phases complete. The Milestone is attained!
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
# Claude Adapter
|
|
2
|
+
|
|
3
|
+
> **Everything in this file is optional.**
|
|
4
|
+
> For canonical rules, see [PROJECT_RULES.md](../PROJECT_RULES.md).
|
|
5
|
+
|
|
6
|
+
This adapter provides optional enhancements for Claude models in Antigravity.
|
|
7
|
+
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
## Extended Thinking Mode
|
|
11
|
+
|
|
12
|
+
When available, activate extended thinking for:
|
|
13
|
+
|
|
14
|
+
| Task Type | Recommended |
|
|
15
|
+
|-----------|-------------|
|
|
16
|
+
| Architecture planning | ✅ High effort |
|
|
17
|
+
| Complex debugging | ✅ High effort |
|
|
18
|
+
| Security analysis | ✅ High effort |
|
|
19
|
+
| Simple edits | ❌ Not needed |
|
|
20
|
+
| Quick iterations | ❌ Overhead too high |
|
|
21
|
+
|
|
22
|
+
### Effort Levels
|
|
23
|
+
|
|
24
|
+
If the model supports effort/budget levels:
|
|
25
|
+
|
|
26
|
+
| Level | Use Case |
|
|
27
|
+
|-------|----------|
|
|
28
|
+
| `low` | Simple edits, formatting, comments |
|
|
29
|
+
| `medium` | Standard implementation (default) |
|
|
30
|
+
| `high` | Complex logic, refactoring, debugging |
|
|
31
|
+
| `max` | Architecture, security, critical decisions |
|
|
32
|
+
|
|
33
|
+
**Default:** `medium` if not specified.
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## Artifacts Mode
|
|
38
|
+
|
|
39
|
+
When artifacts are supported:
|
|
40
|
+
|
|
41
|
+
- Use for code generation that needs preview
|
|
42
|
+
- Use for documentation with formatting
|
|
43
|
+
- Avoid for small inline edits
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
## Context Optimization
|
|
48
|
+
|
|
49
|
+
Claude-specific context tips:
|
|
50
|
+
|
|
51
|
+
1. **System prompt loading**: Core rules in system prompt, task details in user message
|
|
52
|
+
2. **XML structure**: Claude parses XML well — use task XML format from GSD-STYLE.md
|
|
53
|
+
3. **Conversation history**: Minimal history preferred; use STATE.md for continuity
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## File Conventions
|
|
58
|
+
|
|
59
|
+
Not required, but if organizing Claude-specific files:
|
|
60
|
+
|
|
61
|
+
```
|
|
62
|
+
.claude/
|
|
63
|
+
├── CLAUDE.md # This adapter (if using)
|
|
64
|
+
└── settings.json # IDE-specific settings
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## Anti-Patterns
|
|
70
|
+
|
|
71
|
+
❌ **Using max effort for everything** — Slow and expensive
|
|
72
|
+
❌ **Skipping verification** — Thinking mode doesn't guarantee correctness
|
|
73
|
+
❌ **Depending on artifacts** — Not all Claude interfaces support them
|
|
74
|
+
|
|
75
|
+
---
|
|
76
|
+
|
|
77
|
+
*See PROJECT_RULES.md for canonical requirements.*
|