@adobe/data-ai 0.9.83 → 0.9.86
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/.claude/rules/README.md +42 -0
- package/.claude/rules/archetypes.md +60 -0
- package/.claude/rules/cohesion.md +66 -0
- package/.claude/rules/data-modelling.md +71 -0
- package/.claude/rules/element.md +130 -0
- package/.claude/rules/features/data/index.md +35 -0
- package/.claude/rules/features/data/state.md +56 -0
- package/.claude/rules/features/ecs/actions.md +32 -0
- package/.claude/rules/features/ecs/archetypes.md +46 -0
- package/.claude/rules/features/ecs/components.md +41 -0
- package/.claude/rules/features/ecs/computed.md +26 -0
- package/.claude/rules/features/ecs/conformance.md +71 -0
- package/.claude/rules/features/ecs/index.md +179 -0
- package/.claude/rules/features/ecs/indexes.md +63 -0
- package/.claude/rules/features/ecs/resources.md +28 -0
- package/.claude/rules/features/ecs/services.md +24 -0
- package/.claude/rules/features/ecs/systems.md +132 -0
- package/.claude/rules/features/ecs/transactions.md +45 -0
- package/.claude/rules/features/index.md +95 -0
- package/.claude/rules/features/services/index.md +34 -0
- package/.claude/rules/features/ui/index.md +31 -0
- package/.claude/rules/function-references.md +35 -0
- package/.claude/rules/lazy-element.md +127 -0
- package/.claude/rules/namespace.md +179 -0
- package/.claude/rules/plugin-modelling.md +170 -0
- package/.claude/rules/presentation.md +83 -0
- package/.claude/rules/type-casts.md +94 -0
- package/.claude-plugin/plugin.json +1 -1
- package/README.md +54 -76
- package/bin/cli.mjs +81 -26
- package/package.json +9 -2
- package/skills/build-actions/SKILL.md +16 -0
- package/skills/build-app-entry/SKILL.md +15 -0
- package/skills/build-application/SKILL.md +12 -0
- package/skills/build-computed/SKILL.md +16 -0
- package/skills/build-core-database/SKILL.md +24 -0
- package/skills/build-data/SKILL.md +22 -0
- package/skills/build-feature/SKILL.md +18 -0
- package/skills/build-game/SKILL.md +21 -0
- package/skills/build-indexes/SKILL.md +16 -0
- package/skills/build-service-database/SKILL.md +16 -0
- package/skills/build-services/SKILL.md +16 -0
- package/skills/build-systems/SKILL.md +24 -0
- package/skills/build-transactions/SKILL.md +15 -0
- package/skills/build-ui/SKILL.md +13 -0
- package/skills/graph-execute/SKILL.md +13 -0
- package/skills/meta-build/SKILL.md +43 -0
- package/skills/review/SKILL.md +25 -0
- package/skills/structure/SKILL.md +7 -0
- package/skills/x-alpha/SKILL.md +7 -0
- package/skills/x-beta/SKILL.md +7 -0
- package/skills/x-double/SKILL.md +7 -0
- package/skills/x-execute/SKILL.md +16 -0
- package/skills/x-log/SKILL.md +12 -0
- package/skills/x-pow/SKILL.md +9 -0
- package/skills/x-subagent/SKILL.md +8 -0
- package/skills/x-trace/SKILL.md +11 -0
- package/skills/x-validate/SKILL.md +67 -0
- package/skills/bar/SKILL.md +0 -8
- package/skills/foo/SKILL.md +0 -8
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: build-services
|
|
3
|
+
description: Build a feature's services/ layer — async capability contracts (ports to the outside world). Optional.
|
|
4
|
+
input: feature
|
|
5
|
+
output: feature
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Skip if this feature doesn't contain or require services.
|
|
9
|
+
|
|
10
|
+
Create the feature's `services/` layer: one `<name>-service/` namespace folder per async
|
|
11
|
+
contract — an `interface` (validated with `AsyncDataService.IsValid`), async-only members,
|
|
12
|
+
and `create*` factories.
|
|
13
|
+
|
|
14
|
+
Only if the feature talks to the outside world. Comes after `data/`, before `ecs/`.
|
|
15
|
+
|
|
16
|
+
The how is in the auto-loading `features/services/index.md` rule (and `namespace.md`).
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: build-systems
|
|
3
|
+
description: Build a feature's ecs system-database — the real-time tick loop (systems the scheduler runs each frame). For real-time features only.
|
|
4
|
+
input: feature
|
|
5
|
+
output: feature
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Skip if this feature doesn't contain or require systems.
|
|
9
|
+
Most games that use a canvas will use systems but most applications will not.
|
|
10
|
+
|
|
11
|
+
Create `ecs/system-database/system-database.ts`: `Database.Plugin.create({ extends:
|
|
12
|
+
Database.Plugin.combine(ComputedDatabase.plugin, scheduler), systems })` where the `systems`
|
|
13
|
+
map is declared **inline** (see `features/ecs/systems.md` — inline is required for `db` to be
|
|
14
|
+
typed and for system-name inference; a `systems/` folder is optional, only for extracted
|
|
15
|
+
per-frame body helpers).
|
|
16
|
+
|
|
17
|
+
- A system is a `SystemDeclaration`: `{ create, schedule?: { before?, after?, during? } }`.
|
|
18
|
+
`create(db)` runs once (capture queries / index handles / closures); the returned function
|
|
19
|
+
advances the world one tick. Return `void` for an init-only system (seeding entities).
|
|
20
|
+
- Order under `schedule` (mirror the `data/` step's internal sequence); drive the loop by
|
|
21
|
+
combining `scheduler` (rAF), gated by the `schedulerState` resource.
|
|
22
|
+
|
|
23
|
+
**Only for real-time features** (games, sims) — turn-based features skip this phase entirely.
|
|
24
|
+
Comes after `build-computed`. The how is in the auto-loading `features/ecs/systems.md` rule.
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: build-transactions
|
|
3
|
+
description: Build a feature's ecs transaction-database — atomic mutations over the store.
|
|
4
|
+
input: feature
|
|
5
|
+
output: feature
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Create `ecs/transaction-database/`: `transaction-database.ts` (extends `IndexDatabase`, adds
|
|
9
|
+
`transactions` from `./transactions/index.js`) plus a `transactions/` folder — one mutation per
|
|
10
|
+
file + barrel. Type the store param `CoreDatabase.Store` (entities/resources/archetypes) or
|
|
11
|
+
`IndexDatabase.Store` (reads an index).
|
|
12
|
+
|
|
13
|
+
Comes after `index-database` (or `core-database` if no indexes).
|
|
14
|
+
|
|
15
|
+
The how is in the auto-loading `features/ecs/transactions.md` rule.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: build-ui
|
|
3
|
+
description: Build a feature's ui/ layer — presentation bound to the ecs database. The final, top layer.
|
|
4
|
+
input: feature
|
|
5
|
+
output: feature
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Create `ui/`: one folder per UI unit —
|
|
9
|
+
`<name>/{<name>.ts (lazy wrapper), <name>-element.ts (container), <name>-presentation.ts (pure render), <name>.css.ts}`.
|
|
10
|
+
The element subscribes to state and delegates to the pure presentation; no business logic here.
|
|
11
|
+
|
|
12
|
+
Comes last. The how is in the auto-loading `features/ui/index.md` rule (and `element.md`,
|
|
13
|
+
`lazy-element.md`, `presentation.md`).
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: graph-execute
|
|
3
|
+
description: executes a graph of steps
|
|
4
|
+
input: piped function calls
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
The input is a set of piped function calls where each call is represented by a slash skill invocation.
|
|
8
|
+
|
|
9
|
+
Each step must be completed independently before moving on to the next.
|
|
10
|
+
|
|
11
|
+
The output of each phase is generally either a returned result or written to the file system. You can pass some context including any previous result to the next phase, but you must never read the subsequent phases in advance.
|
|
12
|
+
|
|
13
|
+
Call each of these phases in a subagent so that they are not even aware that future phases will take place.
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: meta-build
|
|
3
|
+
description: Iteratively build an application or game phase-by-phase in clean subagents, reviewing each phase and refining the build-* skills / rules until each is optimal, then summarizing.
|
|
4
|
+
input: a prompt describing the application or game to build
|
|
5
|
+
options:
|
|
6
|
+
target = build-application # build command to exercise: build-application | build-game | build-feature | a single build-<phase>
|
|
7
|
+
maxIterations = 4 # attempts per phase before moving on
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
Purpose: exercise and **polish the build-* skills and the rules they reference**, using
|
|
11
|
+
a concrete app/game prompt as the test case. You are improving the *general* guidance,
|
|
12
|
+
not the one-off output.
|
|
13
|
+
|
|
14
|
+
## Procedure
|
|
15
|
+
|
|
16
|
+
1. Resolve `target` to its **ordered phases**. A composite target expands to its pipe —
|
|
17
|
+
`build-feature` → its `/build-*` layer steps; `build-application` / `build-game` →
|
|
18
|
+
`build-feature` for the base and each peer, then `build-app-entry`. A single
|
|
19
|
+
`build-<phase>` target is just that one phase.
|
|
20
|
+
|
|
21
|
+
2. For each phase, in order:
|
|
22
|
+
a. **Run it in a fresh subagent** with constrained context (`/x-subagent`): give the
|
|
23
|
+
subagent only the phase skill (`/<phase>`), the app/game prompt, and the files on
|
|
24
|
+
disk from prior phases — nothing about this loop or earlier attempts, so every
|
|
25
|
+
re-run differs only by any edits you made to the guidance.
|
|
26
|
+
b. **Review** the phase output in a subagent with `/review`.
|
|
27
|
+
c. If `/review` is not OPTIMAL: fix the **root cause in the guidance** — edit the
|
|
28
|
+
phase skill or a rule it references. Keep every edit **concise and general**:
|
|
29
|
+
improve it for all apps, never encode anything specific to this prompt. (For a
|
|
30
|
+
pure `code` slip with sound guidance, just re-run.) Do **not** hand-patch the
|
|
31
|
+
generated code.
|
|
32
|
+
d. Re-run from (a), up to `maxIterations` (default 4) attempts. Move to the next
|
|
33
|
+
phase once it reviews OPTIMAL — or the cap is hit (record that it did not converge).
|
|
34
|
+
e. Record: the phase, its iteration count, and every skill/rule file you edited.
|
|
35
|
+
|
|
36
|
+
3. **Final review** (read-only): run `/review` over the whole product. **Change nothing.**
|
|
37
|
+
Then summarize:
|
|
38
|
+
- per-phase iteration counts,
|
|
39
|
+
- which phase skills and which rules were edited, and why,
|
|
40
|
+
- overall outcome (which phases converged, which hit the cap).
|
|
41
|
+
|
|
42
|
+
Every phase runs in its own constrained subagent so re-executions during polishing stay
|
|
43
|
+
consistent — the edited skill/rule is the only variable between a phase's attempts.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review
|
|
3
|
+
description: Review built feature/application output against the @adobe/data feature rules; report whether it is optimal and where any fix belongs. Read-only.
|
|
4
|
+
input: a path to built output (a layer, a feature, or a whole app)
|
|
5
|
+
output: a review — OPTIMAL, or a list of issues each tagged code | skill | rule
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Read the files under the given path and assess them against the relevant `features/`
|
|
9
|
+
rules (each layer's rule and the cross-cutting rules — `namespace`, `data-modelling`,
|
|
10
|
+
`type-casts`, `cohesion`, …):
|
|
11
|
+
|
|
12
|
+
- **Correctness** — does it typecheck and follow the layer's required shape?
|
|
13
|
+
- **Adherence** — single public export per file, naming, the scope helpers
|
|
14
|
+
(`Database.components` / `resources` / `archetypes`), `satisfies` targets, barrels,
|
|
15
|
+
store-layer typing, etc.
|
|
16
|
+
- **Generality** — no leaked type identities; follows the cross-cutting patterns.
|
|
17
|
+
|
|
18
|
+
Report either **OPTIMAL**, or a short list of issues. Tag each issue with where the
|
|
19
|
+
root-cause fix belongs:
|
|
20
|
+
|
|
21
|
+
- `code` — a one-off slip in the generated files (guidance is fine),
|
|
22
|
+
- `skill` — the phase skill's instructions are unclear, wrong, or incomplete,
|
|
23
|
+
- `rule` — a referenced rule is unclear, wrong, or missing guidance.
|
|
24
|
+
|
|
25
|
+
Do not edit anything — assessment only.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: x-execute
|
|
3
|
+
description: executes an input optionally with validate first
|
|
4
|
+
input: piped function calls
|
|
5
|
+
options:
|
|
6
|
+
validate = true
|
|
7
|
+
output: input.output
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
if options.validate && not /x-validate input {
|
|
11
|
+
return "Invalid not executed"
|
|
12
|
+
}
|
|
13
|
+
else {
|
|
14
|
+
return evaluate input
|
|
15
|
+
}
|
|
16
|
+
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: x-trace
|
|
3
|
+
description: inserts a /x-log call right after every non log piped function
|
|
4
|
+
input: piped function calls
|
|
5
|
+
output: piped function calls
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
insert a /x-log call after each piped function call
|
|
9
|
+
|
|
10
|
+
return the resulting piped function calls
|
|
11
|
+
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: x-validate
|
|
3
|
+
description: validates nested or piped function calls to determine if output types match all required input types
|
|
4
|
+
input: piped function calls
|
|
5
|
+
options:
|
|
6
|
+
log = true
|
|
7
|
+
output: boolean
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
for each nested or piped function pair {
|
|
11
|
+
check that the output type matches the required input types of the next
|
|
12
|
+
}
|
|
13
|
+
|
|
14
|
+
if options.log then {
|
|
15
|
+
log results to chat
|
|
16
|
+
}
|
|
17
|
+
|
|
18
|
+
return true if they all validate or false if they don't
|
|
19
|
+
|
|
20
|
+
# Log
|
|
21
|
+
|
|
22
|
+
If `options.log`, print the pipeline **in source order**: initial value, then each `/skill` **exactly as many times as it appears** in the expression. **Never** add or omit a `/skill` that is not in the source.
|
|
23
|
+
|
|
24
|
+
**Between steps:** After a literal or `/skill`, before the next `/skill`, print **one** indented line:
|
|
25
|
+
|
|
26
|
+
- **OK** — the type leaving the producer toward the next step.
|
|
27
|
+
- **Fail** — only `<output> != <input>` (what the producer emitted vs what the next step requires). **No** separate line for the output type alone; the mismatch line is the whole message between that pair.
|
|
28
|
+
|
|
29
|
+
Put that line **after** the producer (literal or `/skill`) and **before** the consumer’s `/skill`. Never put the failure summary under the consumer.
|
|
30
|
+
|
|
31
|
+
After the first rejection, list remaining `/skill` lines from the source; each gets `—` as its only indented line (unreachable).
|
|
32
|
+
|
|
33
|
+
## Examples
|
|
34
|
+
|
|
35
|
+
2 | /x-double |> /x-double |> /x-log
|
|
36
|
+
|
|
37
|
+
2
|
|
38
|
+
number
|
|
39
|
+
/x-double
|
|
40
|
+
number
|
|
41
|
+
/x-double
|
|
42
|
+
number
|
|
43
|
+
/x-log
|
|
44
|
+
|
|
45
|
+
"foo" | /x-double |> /x-double |> /x-log
|
|
46
|
+
|
|
47
|
+
"foo"
|
|
48
|
+
string != number
|
|
49
|
+
/x-double
|
|
50
|
+
—
|
|
51
|
+
/x-double
|
|
52
|
+
—
|
|
53
|
+
/x-log
|
|
54
|
+
—
|
|
55
|
+
|
|
56
|
+
12 | /x-double |> /x-alpha |> /x-double |> /x-log
|
|
57
|
+
|
|
58
|
+
12
|
|
59
|
+
number
|
|
60
|
+
/x-double
|
|
61
|
+
number
|
|
62
|
+
/x-alpha
|
|
63
|
+
string != number
|
|
64
|
+
/x-double
|
|
65
|
+
—
|
|
66
|
+
/x-log
|
|
67
|
+
—
|
package/skills/bar/SKILL.md
DELETED