the-frame-ai 0.2.1 → 0.3.1
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.de.md +335 -0
- package/README.es.md +335 -0
- package/README.hi.md +335 -0
- package/README.ja.md +335 -0
- package/README.md +1 -1
- package/README.ru.md +1 -1
- package/README.zh.md +335 -0
- package/package.json +1 -1
- package/src/cli.js +5 -1
- package/src/init.js +18 -1
- package/src/languages.js +11 -0
- package/src/update.js +30 -9
- package/src/utils.js +10 -0
package/README.de.md
ADDED
|
@@ -0,0 +1,335 @@
|
|
|
1
|
+
# THE Frame
|
|
2
|
+
|
|
3
|
+
FRAME — Framework für KI-gestützte Solo-Entwicklung
|
|
4
|
+
|
|
5
|
+
[🇺🇸 English](README.md) | [🇨🇳 中文](README.zh.md) | [🇮🇳 हिंदी](README.hi.md) | [🇯🇵 日本語](README.ja.md) | [🇩🇪 Deutsch](README.de.md) | [🇪🇸 Español](README.es.md) | [🇷🇺 Русский](README.ru.md)
|
|
6
|
+
|
|
7
|
+
## Was ist FRAME?
|
|
8
|
+
|
|
9
|
+
**FRAME (Framework for AI-Assisted Solo Development)** ist ein Framework für Solo-Entwickler, die Produkte mit Claude Code erstellen. Es verwandelt chaotische KI-gestützte Entwicklung in einen vorhersehbaren Prozess — von der Idee bis zum Deploy — mit Gedächtnis, Struktur und Schutz vor Fehlern.
|
|
10
|
+
|
|
11
|
+
Wenn du alleine mit Claude Code ein Produkt baust und wie ein Team arbeiten möchtest — FRAME ist für dich.
|
|
12
|
+
|
|
13
|
+
## Welche Probleme löst FRAME?
|
|
14
|
+
|
|
15
|
+
| Problem | Was FRAME bietet |
|
|
16
|
+
|---------|-----------------|
|
|
17
|
+
| Kontextverlust zwischen Sitzungen | Projektgedächtnis und automatischer Statusdump beim Sitzungsstart |
|
|
18
|
+
| Chaos bei Aufgaben und Prioritäten | 6-Phasen-Workflow: Recherche → Plan → Build → Review → Ship → Reflect |
|
|
19
|
+
| Angst, etwas Wichtiges zu zerstören | Safety-Hooks blockieren destruktive Befehle vor der Ausführung |
|
|
20
|
+
| Sich wiederholende Routineaufgaben | 34 fertige Befehle für den vollständigen Entwicklungszyklus |
|
|
21
|
+
| Komplexe Features mit Abhängigkeiten | Parallele Subagenten für unabhängige Aufgaben |
|
|
22
|
+
| Keine Struktur für Solo-Arbeit | Roadmap, STATE.md, MAP.md — immer wissen, wo du bist und was als nächstes kommt |
|
|
23
|
+
|
|
24
|
+
## Wie man mit FRAME arbeitet
|
|
25
|
+
|
|
26
|
+
```
|
|
27
|
+
Recherche → Plan → Build → Review → Ship → Reflect
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
Jede Sitzung ist ein Zyklus. Beginne mit `/frame:daily`, ende mit `/frame:ship`.
|
|
31
|
+
|
|
32
|
+
**Recherche** — verstehen, bevor du baust
|
|
33
|
+
Führe `/frame:research <Thema>` aus — Claude erkundet die Codebasis, externe Quellen und baut Kontext für den nächsten Schritt auf.
|
|
34
|
+
|
|
35
|
+
**Plan** — in Aufgaben aufteilen
|
|
36
|
+
`/frame:plan <Feature>` verwandelt Recherche in eine konkrete Aufgabenliste mit Schätzungen.
|
|
37
|
+
|
|
38
|
+
**Build** — implementieren
|
|
39
|
+
`/frame:build` führt Aufgaben sequenziell aus (1–3 auf einmal) mit TDD. Für viele unabhängige Aufgaben — `/frame:wave` führt sie in parallelen Batches aus. Feststeckend — `/frame:unstuck`. Bug gefunden — `/frame:debug`.
|
|
40
|
+
|
|
41
|
+
**Review** — vor dem Deployment prüfen
|
|
42
|
+
`/frame:review` führt automatisierte Prüfungen durch und gibt eine Checkliste: Tests, Typen, Sicherheit, Performance.
|
|
43
|
+
|
|
44
|
+
**Ship** — deployen und aufzeichnen
|
|
45
|
+
`/frame:ship` committet, optionaler Push/PR und aktualisiert das Projektgedächtnis.
|
|
46
|
+
|
|
47
|
+
**Reflect** — lernen und verbessern
|
|
48
|
+
`/frame:retrospective` nach dem Deploy aktualisiert Metriken und erfasst Muster für zukünftige Sitzungen.
|
|
49
|
+
|
|
50
|
+
## Beispiele
|
|
51
|
+
|
|
52
|
+
### Neues Feature: Google-Authentifizierung hinzufügen
|
|
53
|
+
|
|
54
|
+
```
|
|
55
|
+
/frame:daily
|
|
56
|
+
# → aktuellen Projektstatus und Geplantes sehen
|
|
57
|
+
|
|
58
|
+
/frame:research "Google OAuth"
|
|
59
|
+
# → Claude untersucht die Codebasis: wie aktuelle Auth funktioniert,
|
|
60
|
+
# welche Muster bereits verwendet werden, was hinzugefügt werden muss
|
|
61
|
+
|
|
62
|
+
/frame:plan "Google OAuth"
|
|
63
|
+
# → konkrete Aufgabenliste erhalten:
|
|
64
|
+
# 1. Google OAuth-Credentials konfigurieren
|
|
65
|
+
# 2. Callback-Route hinzufügen
|
|
66
|
+
# 3. Mit Sessions verbinden
|
|
67
|
+
# 4. Button zur UI hinzufügen
|
|
68
|
+
|
|
69
|
+
/frame:checkpoint
|
|
70
|
+
# → Wiederherstellungspunkt speichern — falls etwas schiefgeht, kann man zurückrollen
|
|
71
|
+
|
|
72
|
+
/frame:wave
|
|
73
|
+
# → Aufgaben 1–4 sind unabhängig, Claude führt sie parallel aus
|
|
74
|
+
|
|
75
|
+
/frame:review
|
|
76
|
+
# → automatisierte Prüfungen: Tests, Typen, Sicherheit
|
|
77
|
+
|
|
78
|
+
/frame:ship
|
|
79
|
+
# → commit, optionaler Push/PR, Projektgedächtnis aktualisiert
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
### Bug: Benutzer können sich nach dem Passwort-Reset nicht einloggen
|
|
83
|
+
|
|
84
|
+
```
|
|
85
|
+
/frame:daily
|
|
86
|
+
# → Kontext wiederherstellen, prüfen ob der Bug bereits im Plan ist oder hinzufügen
|
|
87
|
+
|
|
88
|
+
/frame:debug "login after reset"
|
|
89
|
+
# → Claude prüft systematisch: Logs, Reset-Flow, Sessions, Tokens
|
|
90
|
+
# → du erhältst eine Hypothese mit einer konkreten Stelle im Code
|
|
91
|
+
|
|
92
|
+
# Wenn die Ursache sofort gefunden wird:
|
|
93
|
+
/frame:checkpoint # Wiederherstellungspunkt vor dem Fix
|
|
94
|
+
/frame:fast "fix: invalidate old session after password reset"
|
|
95
|
+
# → Claude macht einen gezielten Fix, schreibt einen Regressionstest
|
|
96
|
+
|
|
97
|
+
# Wenn die Ursache unklar ist — tiefer gehen:
|
|
98
|
+
/frame:forensics
|
|
99
|
+
# → analysiert die Git-Historie der Änderungen in diesem Bereich,
|
|
100
|
+
# findet den Commit, der das Verhalten gebrochen hat
|
|
101
|
+
|
|
102
|
+
/frame:checkpoint
|
|
103
|
+
/frame:fast "fix: ..." # gefundene Ursache beheben
|
|
104
|
+
|
|
105
|
+
/frame:review
|
|
106
|
+
# → bestätigen, dass der Fix keine anderen Login-Szenarien gebrochen hat
|
|
107
|
+
|
|
108
|
+
/frame:ship
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
### Verbesserung: Dashboard-Laden beschleunigen
|
|
112
|
+
|
|
113
|
+
```
|
|
114
|
+
/frame:daily
|
|
115
|
+
|
|
116
|
+
/frame:performance
|
|
117
|
+
# → Baseline ermitteln: Bundle-Größe, Ladezeit, Lighthouse-Score
|
|
118
|
+
# Zahlen merken — am Ende für den Vergleich benötigt
|
|
119
|
+
|
|
120
|
+
/frame:research "dashboard performance"
|
|
121
|
+
# → Claude analysiert Dashboard-Code: schwere Komponenten,
|
|
122
|
+
# redundante Anfragen, was gecacht oder lazy-geladen werden kann
|
|
123
|
+
|
|
124
|
+
/frame:plan "dashboard optimization"
|
|
125
|
+
# → Aufgabenliste mit Impact-Schätzungen:
|
|
126
|
+
# 1. schwere Charts lazy laden
|
|
127
|
+
# 2. API-Anfragen cachen
|
|
128
|
+
# 3. doppelte Anfragen beim Mount entfernen
|
|
129
|
+
|
|
130
|
+
/frame:build
|
|
131
|
+
# → sequenziell, jede Aufgabe mit einem Test
|
|
132
|
+
|
|
133
|
+
/frame:performance
|
|
134
|
+
# → mit Baseline vergleichen: echte Verbesserung sehen
|
|
135
|
+
|
|
136
|
+
/frame:ship
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
## Was drin ist
|
|
140
|
+
|
|
141
|
+
FRAME bietet:
|
|
142
|
+
|
|
143
|
+
- **6-Phasen-Workflow**: Recherche → Plan → Build → Review → Ship → Reflect
|
|
144
|
+
- **34 Befehle**: von schnellen Aufgaben bis zum vollständigen Feature-Entwicklungszyklus
|
|
145
|
+
- **5 KI-Agenten**: Researcher, Planner, Builder, Reviewer, Devil's Advocate
|
|
146
|
+
- **Safety-Hooks**: blockieren destruktive Operationen, erzwingen Quality-Gates
|
|
147
|
+
- **Git-Sicherheit**: Checkpoints, Rollback, Worktrees, Pause/Resume
|
|
148
|
+
|
|
149
|
+
## Voraussetzungen
|
|
150
|
+
|
|
151
|
+
- Node.js >= 18
|
|
152
|
+
- Git (Projekt muss ein Git-Repository sein)
|
|
153
|
+
|
|
154
|
+
## Schnellstart
|
|
155
|
+
|
|
156
|
+
```bash
|
|
157
|
+
# Git-Repo initialisieren falls nötig
|
|
158
|
+
git init && git commit --allow-empty -m "init"
|
|
159
|
+
|
|
160
|
+
# FRAME installieren
|
|
161
|
+
npx the-frame-ai init
|
|
162
|
+
|
|
163
|
+
# Claude Code in diesem Projekt öffnen und ausführen:
|
|
164
|
+
/frame:init # Codebasis scannen, MAP.md befüllen
|
|
165
|
+
/frame:daily # dein täglicher Einstiegspunkt
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
## Befehle
|
|
169
|
+
|
|
170
|
+
### Kern — hier anfangen
|
|
171
|
+
|
|
172
|
+
Diese 7 Befehle decken 90% der Solo-Dev-Arbeit ab:
|
|
173
|
+
|
|
174
|
+
| Befehl | Wann verwenden |
|
|
175
|
+
|--------|---------------|
|
|
176
|
+
| `/frame:daily` | **Hier anfangen** nach jeder Pause — was wurde gemacht, was kommt als nächstes |
|
|
177
|
+
| `/frame:research <Thema>` | Vor der Planung eines neuen Features |
|
|
178
|
+
| `/frame:plan <Feature>` | Recherche in eine umsetzbare Aufgabenliste umwandeln |
|
|
179
|
+
| `/frame:build` | 1–3 Aufgaben mit TDD implementieren (sequenziell) |
|
|
180
|
+
| `/frame:wave` | 4+ unabhängige Aufgaben implementieren (parallele Subagenten) |
|
|
181
|
+
| `/frame:review` | Vor dem Deployment — automatisierte Prüfungen + Checkliste |
|
|
182
|
+
| `/frame:ship` | Commit, optionaler Push/PR, Gedächtnis aktualisieren |
|
|
183
|
+
|
|
184
|
+
### Alle Befehle nach Phase
|
|
185
|
+
|
|
186
|
+
<details>
|
|
187
|
+
<summary>Recherche</summary>
|
|
188
|
+
|
|
189
|
+
| Befehl | Wann verwenden |
|
|
190
|
+
|--------|---------------|
|
|
191
|
+
| `/frame:research <Thema>` | Vor der Planung eines neuen Features |
|
|
192
|
+
| `/frame:explain <Datei>` | Warum sieht dieser Code so aus? |
|
|
193
|
+
| `/frame:why <Thema>` | Entscheidungshistorie durchsuchen |
|
|
194
|
+
</details>
|
|
195
|
+
|
|
196
|
+
<details>
|
|
197
|
+
<summary>Plan</summary>
|
|
198
|
+
|
|
199
|
+
| Befehl | Wann verwenden |
|
|
200
|
+
|--------|---------------|
|
|
201
|
+
| `/frame:plan <Feature>` | Recherche in eine umsetzbare Aufgabenliste umwandeln |
|
|
202
|
+
| `/frame:add-task` | Aufgabe zum Plan hinzufügen ohne die Arbeit zu unterbrechen |
|
|
203
|
+
</details>
|
|
204
|
+
|
|
205
|
+
<details>
|
|
206
|
+
<summary>Build</summary>
|
|
207
|
+
|
|
208
|
+
| Befehl | Wann verwenden |
|
|
209
|
+
|--------|---------------|
|
|
210
|
+
| `/frame:build` | Plan mit TDD implementieren (1–3 Aufgaben, sequenziell) |
|
|
211
|
+
| `/frame:wave` | 4+ unabhängige Aufgaben in parallelen Batches implementieren |
|
|
212
|
+
| `/frame:fast <Aufgabe>` | Schnelle Aufgabe unter 30 Minuten |
|
|
213
|
+
| `/frame:debug <Problem>` | Systematische Bug-Untersuchung |
|
|
214
|
+
| `/frame:forensics` | Tiefenanalyse warum etwas kaputt gegangen ist |
|
|
215
|
+
| `/frame:refactor` | Refactoring mit TDD-Sicherheitsnetz |
|
|
216
|
+
| `/frame:migrate` | DB/API/Deps-Migration mit Rollback-Plan |
|
|
217
|
+
</details>
|
|
218
|
+
|
|
219
|
+
<details>
|
|
220
|
+
<summary>Review</summary>
|
|
221
|
+
|
|
222
|
+
| Befehl | Wann verwenden |
|
|
223
|
+
|--------|---------------|
|
|
224
|
+
| `/frame:review` | Vor dem Deployment — automatisierte Prüfungen + Checkliste |
|
|
225
|
+
| `/frame:health` | Vollständiger Projekt-Gesundheitscheck |
|
|
226
|
+
| `/frame:check-deps` | Sicherheitsaudit + veraltete Pakete |
|
|
227
|
+
| `/frame:performance` | Bundle-Größe und Lighthouse-Audit |
|
|
228
|
+
</details>
|
|
229
|
+
|
|
230
|
+
<details>
|
|
231
|
+
<summary>Ship</summary>
|
|
232
|
+
|
|
233
|
+
| Befehl | Wann verwenden |
|
|
234
|
+
|--------|---------------|
|
|
235
|
+
| `/frame:ship` | Commit, optionaler Push/PR, Gedächtnis aktualisieren |
|
|
236
|
+
| `/frame:checkpoint` | Git-Tag vor einer riskanten Änderung speichern |
|
|
237
|
+
| `/frame:rollback` | Zu einem Checkpoint zurückrollen |
|
|
238
|
+
</details>
|
|
239
|
+
|
|
240
|
+
<details>
|
|
241
|
+
<summary>Reflect</summary>
|
|
242
|
+
|
|
243
|
+
| Befehl | Wann verwenden |
|
|
244
|
+
|--------|---------------|
|
|
245
|
+
| `/frame:retrospective` | Nach dem Deploy — Gedächtnis und Metriken aktualisieren |
|
|
246
|
+
| `/frame:sprint-check` | Wöchentlicher Fortschritt vs. Roadmap |
|
|
247
|
+
| `/frame:cleanup-memory` | Veraltetes Gedächtnis kürzen und archivieren |
|
|
248
|
+
</details>
|
|
249
|
+
|
|
250
|
+
<details>
|
|
251
|
+
<summary>Täglich & Hilfsprogramme</summary>
|
|
252
|
+
|
|
253
|
+
| Befehl | Wann verwenden |
|
|
254
|
+
|--------|---------------|
|
|
255
|
+
| `/frame:daily` | Tagesbeginn — was wurde gemacht, was kommt als nächstes |
|
|
256
|
+
| `/frame:status` | Vollständiger Statusdump (Git, Gedächtnis, Blocker) |
|
|
257
|
+
| `/frame:note` | Muster, Entscheidung oder Anti-Pattern festhalten |
|
|
258
|
+
| `/frame:unstuck` | Feststeckend? 3 konkrete Optionen zum Entsperren erhalten |
|
|
259
|
+
| `/frame:context` | Aktuellen Arbeitskontext anzeigen |
|
|
260
|
+
| `/frame:init` | Erster Start — Codebasis scannen, MAP.md befüllen |
|
|
261
|
+
| `/frame:doctor` | FRAME-Installation überprüfen |
|
|
262
|
+
| `/frame:pause` / `/frame:resume` | Zustand mitten in einer Aufgabe speichern und wiederherstellen |
|
|
263
|
+
</details>
|
|
264
|
+
|
|
265
|
+
<details>
|
|
266
|
+
<summary>Erweitert</summary>
|
|
267
|
+
|
|
268
|
+
| Befehl | Wann verwenden |
|
|
269
|
+
|--------|---------------|
|
|
270
|
+
| `/frame:worktree` | Isolierter Git-Worktree für parallele Experimente |
|
|
271
|
+
| `/frame:headless` | Autonomer CI-Modus (keine Interaktion) |
|
|
272
|
+
| `/frame:estimate <Aufgabe>` | Umfang- und Zeitschätzung vor dem Start |
|
|
273
|
+
</details>
|
|
274
|
+
|
|
275
|
+
## Hooks
|
|
276
|
+
|
|
277
|
+
FRAME installiert 4 Hooks in `.claude/hooks/`. Sie laufen automatisch.
|
|
278
|
+
|
|
279
|
+
| Hook | Auslöser | Was er tut | Zum Deaktivieren |
|
|
280
|
+
|------|---------|------------|-----------------|
|
|
281
|
+
| `safety-net.sh` | Vor Bash | Blockiert `rm -rf` und `DROP TABLE/DATABASE` | Aus `.claude/settings.local.json` entfernen |
|
|
282
|
+
| `git-safety.sh` | Vor Bash | Blockiert Force-Push, `reset --hard`, warnt bei `git add -A` | Aus `.claude/settings.local.json` entfernen |
|
|
283
|
+
| `quality-gate.sh` | Nach Datei-Schreiben | Führt Typecheck + Lint auf geänderter Datei aus | Aus `.claude/settings.local.json` entfernen |
|
|
284
|
+
| `session-init.sh` | Sitzungsstart | Zeigt aktuelle Phase/Aufgabe; vollständiger Kontextdump bei > 24h Abwesenheit | Aus `.claude/settings.local.json` entfernen |
|
|
285
|
+
|
|
286
|
+
## Konfiguration
|
|
287
|
+
|
|
288
|
+
FRAME wird über `.frame/config.json` konfiguriert. Wichtige Einstellungen:
|
|
289
|
+
|
|
290
|
+
```json
|
|
291
|
+
{
|
|
292
|
+
"quality": {
|
|
293
|
+
"commands": {
|
|
294
|
+
"typecheck": "npx tsc --noEmit",
|
|
295
|
+
"test": "npx vitest run",
|
|
296
|
+
"lint": "npx eslint .",
|
|
297
|
+
"build": "npm run build"
|
|
298
|
+
}
|
|
299
|
+
}
|
|
300
|
+
}
|
|
301
|
+
```
|
|
302
|
+
|
|
303
|
+
## CLI
|
|
304
|
+
|
|
305
|
+
```bash
|
|
306
|
+
npx the-frame-ai init [target-dir] # FRAME installieren
|
|
307
|
+
npx the-frame-ai update [target-dir] # Befehle, Agenten, Hooks aktualisieren
|
|
308
|
+
npx the-frame-ai doctor [target-dir] # Installationsgesundheit prüfen
|
|
309
|
+
npx the-frame-ai version # CLI-Version anzeigen
|
|
310
|
+
```
|
|
311
|
+
|
|
312
|
+
`update` aktualisiert nur Befehle, Agenten und Hooks. Projektdateien (STATE.md, MAP.md, memory/ usw.) werden nie überschrieben.
|
|
313
|
+
|
|
314
|
+
## Projektstruktur (nach der Installation)
|
|
315
|
+
|
|
316
|
+
```
|
|
317
|
+
.claude/
|
|
318
|
+
commands/ # 34 FRAME-Befehle
|
|
319
|
+
agents/ # 5 KI-Agenten
|
|
320
|
+
hooks/ # 4 Safety-Hooks
|
|
321
|
+
.frame/
|
|
322
|
+
config.json # FRAME-Konfiguration
|
|
323
|
+
.planning/
|
|
324
|
+
STATE.md # Aktuelle Position
|
|
325
|
+
MAP.md # Projektkarte
|
|
326
|
+
ROADMAP.md # Roadmap
|
|
327
|
+
memory/ # Projektgedächtnis
|
|
328
|
+
specs/ # Feature-Spezifikationen
|
|
329
|
+
reviews/ # Review-Ergebnisse
|
|
330
|
+
reports/ # Berichte (täglich, Deps, Qualität, Sprint)
|
|
331
|
+
```
|
|
332
|
+
|
|
333
|
+
## Lizenz
|
|
334
|
+
|
|
335
|
+
MIT
|
package/README.es.md
ADDED
|
@@ -0,0 +1,335 @@
|
|
|
1
|
+
# THE Frame
|
|
2
|
+
|
|
3
|
+
FRAME — Framework para el Desarrollo en Solitario Asistido por IA
|
|
4
|
+
|
|
5
|
+
[🇺🇸 English](README.md) | [🇨🇳 中文](README.zh.md) | [🇮🇳 हिंदी](README.hi.md) | [🇯🇵 日本語](README.ja.md) | [🇩🇪 Deutsch](README.de.md) | [🇪🇸 Español](README.es.md) | [🇷🇺 Русский](README.ru.md)
|
|
6
|
+
|
|
7
|
+
## ¿Qué es FRAME?
|
|
8
|
+
|
|
9
|
+
**FRAME (Framework for AI-Assisted Solo Development)** es un framework para desarrolladores en solitario que construyen productos con Claude Code. Convierte el caótico desarrollo asistido por IA en un proceso predecible — desde la idea hasta el despliegue — con memoria, estructura y protección contra errores.
|
|
10
|
+
|
|
11
|
+
Si estás construyendo un producto solo con Claude Code y quieres trabajar como un equipo — FRAME es para ti.
|
|
12
|
+
|
|
13
|
+
## ¿Qué problemas resuelve FRAME?
|
|
14
|
+
|
|
15
|
+
| Problema | Lo que FRAME proporciona |
|
|
16
|
+
|----------|------------------------|
|
|
17
|
+
| Perder contexto entre sesiones | Memoria del proyecto y volcado automático de estado al inicio de sesión |
|
|
18
|
+
| Caos en tareas y prioridades | Flujo de trabajo de 6 fases: Investigar → Planificar → Construir → Revisar → Publicar → Reflexionar |
|
|
19
|
+
| Miedo a romper algo importante | Los safety hooks bloquean comandos destructivos antes de ejecutarse |
|
|
20
|
+
| Tareas rutinarias repetitivas | 34 comandos listos para usar para el ciclo completo de desarrollo |
|
|
21
|
+
| Funcionalidades complejas con dependencias | Subagentes paralelos para tareas independientes |
|
|
22
|
+
| Sin estructura para el trabajo en solitario | Roadmap, STATE.md, MAP.md — siempre saber dónde estás y qué sigue |
|
|
23
|
+
|
|
24
|
+
## Cómo trabajar con FRAME
|
|
25
|
+
|
|
26
|
+
```
|
|
27
|
+
Investigar → Planificar → Construir → Revisar → Publicar → Reflexionar
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
Cada sesión es un ciclo. Empieza con `/frame:daily`, termina con `/frame:ship`.
|
|
31
|
+
|
|
32
|
+
**Investigar** — entender antes de construir
|
|
33
|
+
Ejecuta `/frame:research <tema>` — Claude explora la base de código, fuentes externas y construye contexto para el siguiente paso.
|
|
34
|
+
|
|
35
|
+
**Planificar** — dividir en tareas
|
|
36
|
+
`/frame:plan <funcionalidad>` convierte la investigación en una lista de tareas concreta con estimaciones.
|
|
37
|
+
|
|
38
|
+
**Construir** — implementar
|
|
39
|
+
`/frame:build` ejecuta tareas secuencialmente (1–3 a la vez) con TDD. Para muchas tareas independientes — `/frame:wave` las ejecuta en lotes paralelos. Atascado — `/frame:unstuck`. Encontraste un bug — `/frame:debug`.
|
|
40
|
+
|
|
41
|
+
**Revisar** — verificar antes de desplegar
|
|
42
|
+
`/frame:review` ejecuta verificaciones automatizadas y proporciona una lista de comprobación: pruebas, tipos, seguridad, rendimiento.
|
|
43
|
+
|
|
44
|
+
**Publicar** — desplegar y registrar
|
|
45
|
+
`/frame:ship` hace commit, push/PR opcional y actualiza la memoria del proyecto.
|
|
46
|
+
|
|
47
|
+
**Reflexionar** — aprender y mejorar
|
|
48
|
+
`/frame:retrospective` después del despliegue actualiza métricas y captura patrones para sesiones futuras.
|
|
49
|
+
|
|
50
|
+
## Ejemplos
|
|
51
|
+
|
|
52
|
+
### Nueva funcionalidad: añadir autenticación con Google
|
|
53
|
+
|
|
54
|
+
```
|
|
55
|
+
/frame:daily
|
|
56
|
+
# → ver el estado actual del proyecto y lo que está planificado
|
|
57
|
+
|
|
58
|
+
/frame:research "Google OAuth"
|
|
59
|
+
# → Claude estudia la base de código: cómo funciona la auth actual,
|
|
60
|
+
# qué patrones ya se usan, qué hay que añadir
|
|
61
|
+
|
|
62
|
+
/frame:plan "Google OAuth"
|
|
63
|
+
# → obtener una lista de tareas concreta:
|
|
64
|
+
# 1. configurar credenciales de Google OAuth
|
|
65
|
+
# 2. añadir ruta de callback
|
|
66
|
+
# 3. conectar a sesiones
|
|
67
|
+
# 4. añadir botón a la UI
|
|
68
|
+
|
|
69
|
+
/frame:checkpoint
|
|
70
|
+
# → guardar un punto de restauración — si algo sale mal, puedes hacer rollback
|
|
71
|
+
|
|
72
|
+
/frame:wave
|
|
73
|
+
# → las tareas 1–4 son independientes, Claude las ejecuta en paralelo
|
|
74
|
+
|
|
75
|
+
/frame:review
|
|
76
|
+
# → verificaciones automatizadas: pruebas, tipos, seguridad
|
|
77
|
+
|
|
78
|
+
/frame:ship
|
|
79
|
+
# → commit, push/PR opcional, memoria del proyecto actualizada
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
### Bug: los usuarios no pueden iniciar sesión después de restablecer la contraseña
|
|
83
|
+
|
|
84
|
+
```
|
|
85
|
+
/frame:daily
|
|
86
|
+
# → restaurar contexto, ver si el bug ya está en el plan o añadirlo
|
|
87
|
+
|
|
88
|
+
/frame:debug "login after reset"
|
|
89
|
+
# → Claude verifica sistemáticamente: logs, flujo de reset, sesiones, tokens
|
|
90
|
+
# → obtienes una hipótesis con una ubicación concreta en el código
|
|
91
|
+
|
|
92
|
+
# Si la causa se encuentra de inmediato:
|
|
93
|
+
/frame:checkpoint # punto de restauración antes del fix
|
|
94
|
+
/frame:fast "fix: invalidate old session after password reset"
|
|
95
|
+
# → Claude hace un fix dirigido, escribe una prueba de regresión
|
|
96
|
+
|
|
97
|
+
# Si la causa no está clara — profundizar:
|
|
98
|
+
/frame:forensics
|
|
99
|
+
# → analiza el historial de git de cambios en esta área,
|
|
100
|
+
# encuentra el commit que rompió el comportamiento
|
|
101
|
+
|
|
102
|
+
/frame:checkpoint
|
|
103
|
+
/frame:fast "fix: ..." # corregir la causa encontrada
|
|
104
|
+
|
|
105
|
+
/frame:review
|
|
106
|
+
# → confirmar que el fix no rompió otros escenarios de inicio de sesión
|
|
107
|
+
|
|
108
|
+
/frame:ship
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
### Mejora: acelerar la carga del dashboard
|
|
112
|
+
|
|
113
|
+
```
|
|
114
|
+
/frame:daily
|
|
115
|
+
|
|
116
|
+
/frame:performance
|
|
117
|
+
# → obtener línea base: tamaño del bundle, tiempo de carga, puntuación Lighthouse
|
|
118
|
+
# recordar los números — los necesitarás para comparar al final
|
|
119
|
+
|
|
120
|
+
/frame:research "dashboard performance"
|
|
121
|
+
# → Claude analiza el código del dashboard: componentes pesados,
|
|
122
|
+
# solicitudes redundantes, qué se puede cachear o cargar de forma diferida
|
|
123
|
+
|
|
124
|
+
/frame:plan "dashboard optimization"
|
|
125
|
+
# → lista de tareas con estimaciones de impacto:
|
|
126
|
+
# 1. carga diferida de gráficos pesados
|
|
127
|
+
# 2. cachear solicitudes de API
|
|
128
|
+
# 3. eliminar solicitudes duplicadas al montar
|
|
129
|
+
|
|
130
|
+
/frame:build
|
|
131
|
+
# → secuencial, cada tarea con una prueba
|
|
132
|
+
|
|
133
|
+
/frame:performance
|
|
134
|
+
# → comparar con la línea base: ver la mejora real
|
|
135
|
+
|
|
136
|
+
/frame:ship
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
## Qué incluye
|
|
140
|
+
|
|
141
|
+
FRAME proporciona:
|
|
142
|
+
|
|
143
|
+
- **Flujo de trabajo de 6 fases**: Investigar → Planificar → Construir → Revisar → Publicar → Reflexionar
|
|
144
|
+
- **34 comandos**: desde tareas rápidas hasta el ciclo completo de desarrollo de funcionalidades
|
|
145
|
+
- **5 agentes de IA**: Investigador, Planificador, Constructor, Revisor, Abogado del Diablo
|
|
146
|
+
- **Safety Hooks**: bloquean operaciones destructivas, aplican quality gates
|
|
147
|
+
- **Git Safety**: checkpoints, rollback, worktrees, pausa/reanudación
|
|
148
|
+
|
|
149
|
+
## Requisitos previos
|
|
150
|
+
|
|
151
|
+
- Node.js >= 18
|
|
152
|
+
- Git (el proyecto debe ser un repositorio git)
|
|
153
|
+
|
|
154
|
+
## Inicio rápido
|
|
155
|
+
|
|
156
|
+
```bash
|
|
157
|
+
# Inicializar repositorio git si es necesario
|
|
158
|
+
git init && git commit --allow-empty -m "init"
|
|
159
|
+
|
|
160
|
+
# Instalar FRAME
|
|
161
|
+
npx the-frame-ai init
|
|
162
|
+
|
|
163
|
+
# Abrir Claude Code en este proyecto y ejecutar:
|
|
164
|
+
/frame:init # escanea la base de código, rellena MAP.md
|
|
165
|
+
/frame:daily # tu punto de entrada cada día
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
## Comandos
|
|
169
|
+
|
|
170
|
+
### Núcleo — empieza aquí
|
|
171
|
+
|
|
172
|
+
Estos 7 comandos cubren el 90% del trabajo de desarrollo en solitario:
|
|
173
|
+
|
|
174
|
+
| Comando | Cuándo usarlo |
|
|
175
|
+
|---------|--------------|
|
|
176
|
+
| `/frame:daily` | **Empieza aquí** después de cualquier pausa — qué se hizo, qué sigue |
|
|
177
|
+
| `/frame:research <tema>` | Antes de planificar una nueva funcionalidad |
|
|
178
|
+
| `/frame:plan <funcionalidad>` | Convertir la investigación en una lista de tareas accionable |
|
|
179
|
+
| `/frame:build` | Implementar 1–3 tareas con TDD (secuencial) |
|
|
180
|
+
| `/frame:wave` | Implementar 4+ tareas independientes (subagentes paralelos) |
|
|
181
|
+
| `/frame:review` | Antes de desplegar — verificaciones automatizadas + lista de comprobación |
|
|
182
|
+
| `/frame:ship` | Commit, push/PR opcional, actualizar memoria |
|
|
183
|
+
|
|
184
|
+
### Todos los comandos por fase
|
|
185
|
+
|
|
186
|
+
<details>
|
|
187
|
+
<summary>Investigar</summary>
|
|
188
|
+
|
|
189
|
+
| Comando | Cuándo usarlo |
|
|
190
|
+
|---------|--------------|
|
|
191
|
+
| `/frame:research <tema>` | Antes de planificar una nueva funcionalidad |
|
|
192
|
+
| `/frame:explain <archivo>` | ¿Por qué este código tiene este aspecto? |
|
|
193
|
+
| `/frame:why <tema>` | Buscar historial de decisiones |
|
|
194
|
+
</details>
|
|
195
|
+
|
|
196
|
+
<details>
|
|
197
|
+
<summary>Planificar</summary>
|
|
198
|
+
|
|
199
|
+
| Comando | Cuándo usarlo |
|
|
200
|
+
|---------|--------------|
|
|
201
|
+
| `/frame:plan <funcionalidad>` | Convertir la investigación en una lista de tareas accionable |
|
|
202
|
+
| `/frame:add-task` | Añadir una tarea al plan sin interrumpir el trabajo |
|
|
203
|
+
</details>
|
|
204
|
+
|
|
205
|
+
<details>
|
|
206
|
+
<summary>Construir</summary>
|
|
207
|
+
|
|
208
|
+
| Comando | Cuándo usarlo |
|
|
209
|
+
|---------|--------------|
|
|
210
|
+
| `/frame:build` | Implementar el plan con TDD (1–3 tareas, secuencial) |
|
|
211
|
+
| `/frame:wave` | Implementar 4+ tareas independientes en lotes paralelos |
|
|
212
|
+
| `/frame:fast <tarea>` | Tarea rápida de menos de 30 minutos |
|
|
213
|
+
| `/frame:debug <problema>` | Investigación sistemática de bugs |
|
|
214
|
+
| `/frame:forensics` | Análisis profundo de por qué algo se rompió |
|
|
215
|
+
| `/frame:refactor` | Refactorizar con red de seguridad TDD |
|
|
216
|
+
| `/frame:migrate` | Migración de DB/API/deps con plan de rollback |
|
|
217
|
+
</details>
|
|
218
|
+
|
|
219
|
+
<details>
|
|
220
|
+
<summary>Revisar</summary>
|
|
221
|
+
|
|
222
|
+
| Comando | Cuándo usarlo |
|
|
223
|
+
|---------|--------------|
|
|
224
|
+
| `/frame:review` | Antes de desplegar — verificaciones automatizadas + lista de comprobación |
|
|
225
|
+
| `/frame:health` | Verificación completa del estado del proyecto |
|
|
226
|
+
| `/frame:check-deps` | Auditoría de seguridad + paquetes desactualizados |
|
|
227
|
+
| `/frame:performance` | Auditoría de tamaño de bundle y Lighthouse |
|
|
228
|
+
</details>
|
|
229
|
+
|
|
230
|
+
<details>
|
|
231
|
+
<summary>Publicar</summary>
|
|
232
|
+
|
|
233
|
+
| Comando | Cuándo usarlo |
|
|
234
|
+
|---------|--------------|
|
|
235
|
+
| `/frame:ship` | Commit, push/PR opcional, actualizar memoria |
|
|
236
|
+
| `/frame:checkpoint` | Guardar una etiqueta git antes de un cambio arriesgado |
|
|
237
|
+
| `/frame:rollback` | Volver a un checkpoint |
|
|
238
|
+
</details>
|
|
239
|
+
|
|
240
|
+
<details>
|
|
241
|
+
<summary>Reflexionar</summary>
|
|
242
|
+
|
|
243
|
+
| Comando | Cuándo usarlo |
|
|
244
|
+
|---------|--------------|
|
|
245
|
+
| `/frame:retrospective` | Después del despliegue — actualizar memoria y métricas |
|
|
246
|
+
| `/frame:sprint-check` | Progreso semanal vs. roadmap |
|
|
247
|
+
| `/frame:cleanup-memory` | Recortar y archivar memoria obsoleta |
|
|
248
|
+
</details>
|
|
249
|
+
|
|
250
|
+
<details>
|
|
251
|
+
<summary>Diario y Utilidades</summary>
|
|
252
|
+
|
|
253
|
+
| Comando | Cuándo usarlo |
|
|
254
|
+
|---------|--------------|
|
|
255
|
+
| `/frame:daily` | Inicio del día — qué se hizo, qué sigue |
|
|
256
|
+
| `/frame:status` | Volcado completo de estado (git, memoria, bloqueadores) |
|
|
257
|
+
| `/frame:note` | Capturar un patrón, decisión o anti-patrón |
|
|
258
|
+
| `/frame:unstuck` | ¿Atascado? Obtener 3 opciones concretas para desbloquear |
|
|
259
|
+
| `/frame:context` | Mostrar el contexto de trabajo actual |
|
|
260
|
+
| `/frame:init` | Primera ejecución — escanear base de código, rellenar MAP.md |
|
|
261
|
+
| `/frame:doctor` | Verificar la instalación de FRAME |
|
|
262
|
+
| `/frame:pause` / `/frame:resume` | Guardar y restaurar el estado a mitad de tarea |
|
|
263
|
+
</details>
|
|
264
|
+
|
|
265
|
+
<details>
|
|
266
|
+
<summary>Avanzado</summary>
|
|
267
|
+
|
|
268
|
+
| Comando | Cuándo usarlo |
|
|
269
|
+
|---------|--------------|
|
|
270
|
+
| `/frame:worktree` | Worktree git aislado para experimentos paralelos |
|
|
271
|
+
| `/frame:headless` | Modo CI autónomo (sin interacción) |
|
|
272
|
+
| `/frame:estimate <tarea>` | Estimación de alcance y tiempo antes de empezar |
|
|
273
|
+
</details>
|
|
274
|
+
|
|
275
|
+
## Hooks
|
|
276
|
+
|
|
277
|
+
FRAME instala 4 hooks en `.claude/hooks/`. Se ejecutan automáticamente.
|
|
278
|
+
|
|
279
|
+
| Hook | Disparador | Qué hace | Para desactivar |
|
|
280
|
+
|------|-----------|----------|----------------|
|
|
281
|
+
| `safety-net.sh` | Antes de Bash | Bloquea `rm -rf` y `DROP TABLE/DATABASE` | Eliminar de `.claude/settings.local.json` |
|
|
282
|
+
| `git-safety.sh` | Antes de Bash | Bloquea force push, `reset --hard`, advierte sobre `git add -A` | Eliminar de `.claude/settings.local.json` |
|
|
283
|
+
| `quality-gate.sh` | Después de escribir archivo | Ejecuta typecheck + lint en el archivo modificado | Eliminar de `.claude/settings.local.json` |
|
|
284
|
+
| `session-init.sh` | Inicio de sesión | Muestra la fase/tarea actual; volcado completo de contexto si ausente > 24h | Eliminar de `.claude/settings.local.json` |
|
|
285
|
+
|
|
286
|
+
## Configuración
|
|
287
|
+
|
|
288
|
+
FRAME se configura mediante `.frame/config.json`. Configuraciones clave:
|
|
289
|
+
|
|
290
|
+
```json
|
|
291
|
+
{
|
|
292
|
+
"quality": {
|
|
293
|
+
"commands": {
|
|
294
|
+
"typecheck": "npx tsc --noEmit",
|
|
295
|
+
"test": "npx vitest run",
|
|
296
|
+
"lint": "npx eslint .",
|
|
297
|
+
"build": "npm run build"
|
|
298
|
+
}
|
|
299
|
+
}
|
|
300
|
+
}
|
|
301
|
+
```
|
|
302
|
+
|
|
303
|
+
## CLI
|
|
304
|
+
|
|
305
|
+
```bash
|
|
306
|
+
npx the-frame-ai init [target-dir] # Instalar FRAME
|
|
307
|
+
npx the-frame-ai update [target-dir] # Actualizar comandos, agentes, hooks
|
|
308
|
+
npx the-frame-ai doctor [target-dir] # Verificar el estado de la instalación
|
|
309
|
+
npx the-frame-ai version # Mostrar versión del CLI
|
|
310
|
+
```
|
|
311
|
+
|
|
312
|
+
`update` solo actualiza comandos, agentes y hooks. Los archivos del proyecto (STATE.md, MAP.md, memory/, etc.) nunca se sobreescriben.
|
|
313
|
+
|
|
314
|
+
## Estructura del proyecto (después de la instalación)
|
|
315
|
+
|
|
316
|
+
```
|
|
317
|
+
.claude/
|
|
318
|
+
commands/ # 34 comandos FRAME
|
|
319
|
+
agents/ # 5 agentes de IA
|
|
320
|
+
hooks/ # 4 safety hooks
|
|
321
|
+
.frame/
|
|
322
|
+
config.json # Configuración de FRAME
|
|
323
|
+
.planning/
|
|
324
|
+
STATE.md # Posición actual
|
|
325
|
+
MAP.md # Mapa del proyecto
|
|
326
|
+
ROADMAP.md # Hoja de ruta
|
|
327
|
+
memory/ # Memoria del proyecto
|
|
328
|
+
specs/ # Especificaciones de funcionalidades
|
|
329
|
+
reviews/ # Resultados de revisiones
|
|
330
|
+
reports/ # Informes (diario, deps, calidad, sprint)
|
|
331
|
+
```
|
|
332
|
+
|
|
333
|
+
## Licencia
|
|
334
|
+
|
|
335
|
+
MIT
|