@blockbite/agent-context 0.1.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/examples/README.md +23 -0
- package/examples/dynamic-template-reference/fields.yaml +61 -0
- package/examples/dynamic-template-reference/manifest.json +8 -0
- package/examples/dynamic-template-reference/module.ts +12 -0
- package/examples/dynamic-template-reference/recipe.json +5 -0
- package/examples/dynamic-template-reference/seeds.json +44 -0
- package/examples/dynamic-template-reference/style.css +156 -0
- package/examples/dynamic-template-reference/template.liquid +59 -0
- package/index.json +239 -0
- package/mcp-tools.json +222 -0
- package/package.json +24 -0
- package/references/block-dsl.md +257 -0
- package/references/islands.md +111 -0
- package/references/tailwind-utilities.md +108 -0
- package/skills/analyze-template/SKILL.md +20 -0
- package/skills/block-style/SKILL.md +101 -0
- package/skills/connect/SKILL.md +25 -0
- package/skills/connection-status/SKILL.md +38 -0
- package/skills/create-template-draft/SKILL.md +55 -0
- package/skills/design-tokens/SKILL.md +54 -0
- package/skills/document-blueprint/SKILL.md +166 -0
- package/skills/figma-design-to-code/SKILL.md +126 -0
- package/skills/figma-site-builder/SKILL.md +209 -0
- package/skills/frame-draft-link/SKILL.md +77 -0
- package/skills/islands-list/SKILL.md +24 -0
- package/skills/project-select/SKILL.md +19 -0
- package/skills/projects-list/SKILL.md +17 -0
- package/skills/render-preview/SKILL.md +20 -0
- package/skills/sandbox-status/SKILL.md +18 -0
- package/skills/site-motion-pass/SKILL.md +88 -0
- package/skills/site-reviewer/SKILL.md +107 -0
- package/skills/sync-plan/SKILL.md +20 -0
- package/skills/template-figma/SKILL.md +123 -0
- package/skills/template-new/SKILL.md +221 -0
- package/skills/template-preview/SKILL.md +115 -0
- package/skills/template-refine/SKILL.md +135 -0
- package/skills/update-template-draft/SKILL.md +36 -0
|
@@ -0,0 +1,126 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: figma-design-to-code
|
|
3
|
+
description: Implement one reusable BlockBite dynamic-template island from an exact Figma file key and node id with strong design matching, package contracts, seed data, registration, and blueprint wiring. Use for section-level Figma-to-BlockBite work inside a planned site build or when converting a single Figma section into a reusable BlockBite template.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Figma Design To Code
|
|
7
|
+
|
|
8
|
+
Use this skill to implement one reusable dynamic-template island at a time from Figma.
|
|
9
|
+
|
|
10
|
+
Start from an exact Figma file key and node id. If the request is for a full site or multiple pages, use `figma-site-builder` first to create the inventory and blueprint map.
|
|
11
|
+
|
|
12
|
+
## Before Coding
|
|
13
|
+
|
|
14
|
+
1. Discover and record the active `<prefix>` for WP-CLI commands. Do not hardcode `ddev`.
|
|
15
|
+
2. Read `dev/skills/template-figma/SKILL.md`.
|
|
16
|
+
3. Read `dev/skills/document-blueprint/SKILL.md` when wiring a page section or seed file.
|
|
17
|
+
4. Read `dev/skills/block-style/SKILL.md` when buttons, arrows, or repeated block variants are involved.
|
|
18
|
+
5. Read `dev/skills/references/block-dsl.md` before authoring DSL tags.
|
|
19
|
+
6. Read `dev/skills/references/tailwind-utilities.md` before custom CSS for grid placement, direct-child styling, container behavior, editor-only tweaks, or text masks.
|
|
20
|
+
7. Read `<workspace>/dev/plans/<site>/island-inventory.md` and `<workspace>/dev/plans/<site>/page-blueprint-map.md` when they exist.
|
|
21
|
+
|
|
22
|
+
## Figma Verification
|
|
23
|
+
|
|
24
|
+
Verify access before editing files:
|
|
25
|
+
|
|
26
|
+
- Load metadata/context for the exact node.
|
|
27
|
+
- Capture or inspect a screenshot.
|
|
28
|
+
- Record dimensions, breakpoints or responsive hints, spacing, typography, color, image ratios, overflow, repeated groups, hover states, and visible interaction states.
|
|
29
|
+
- If Figma is inaccessible, document the fallback and ask for the missing artifact before guessing design details.
|
|
30
|
+
|
|
31
|
+
## Reuse Check
|
|
32
|
+
|
|
33
|
+
Before creating a new slug, compare the node to the existing island inventory and templates:
|
|
34
|
+
|
|
35
|
+
- Reuse an existing template when layout, fields, and behavior can share one design contract.
|
|
36
|
+
- Add a page-specific section seed file when only the content differs.
|
|
37
|
+
- Create a new template only when the visual structure, behavior, or data contract genuinely differs.
|
|
38
|
+
|
|
39
|
+
Do not create page-specific duplicates such as `home-project-slider`, `services-project-slider`, and `profile-project-slider` when one `project-slider` template with different seeds fits.
|
|
40
|
+
|
|
41
|
+
## Implementation Contract
|
|
42
|
+
|
|
43
|
+
Implement or refine:
|
|
44
|
+
|
|
45
|
+
```text
|
|
46
|
+
<workspace>/templates/<slug>/
|
|
47
|
+
template.liquid
|
|
48
|
+
recipe.json
|
|
49
|
+
seeds.json
|
|
50
|
+
fields.yaml
|
|
51
|
+
manifest.json
|
|
52
|
+
style.css
|
|
53
|
+
module.ts
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
Use a dynamic template for every island. Choose the source type deliberately:
|
|
57
|
+
|
|
58
|
+
- Use `block_instance` for content owned by each page section instance.
|
|
59
|
+
- Use `post_type` when the template reads fields from the current post source.
|
|
60
|
+
- Use `collection` only for genuinely collection-backed content.
|
|
61
|
+
|
|
62
|
+
Preserve design facts:
|
|
63
|
+
|
|
64
|
+
- section order and section role
|
|
65
|
+
- exact content hierarchy
|
|
66
|
+
- desktop and mobile layout behavior
|
|
67
|
+
- image ratios and focal behavior
|
|
68
|
+
- overflow and clipped/masked content
|
|
69
|
+
- card heights and mixed-height carousel/card patterns
|
|
70
|
+
- hover/focus states visible in Figma
|
|
71
|
+
- typography, color, radius, and spacing mapped to tokens where possible
|
|
72
|
+
|
|
73
|
+
Use media fields for editor-selected images and SVG fields for editable icons/decorative SVGs. Do not model editable media as string URLs unless users must manually type external URLs.
|
|
74
|
+
|
|
75
|
+
## Authoring Rules
|
|
76
|
+
|
|
77
|
+
- Use Tailwind classes in `template.liquid`.
|
|
78
|
+
- Use `style.css` only for masks, keyframes, pseudo-elements, or layout details Tailwind cannot express cleanly.
|
|
79
|
+
- Do not put island styling or global `html`, `body`, `button`, `input`, typography, background, or reset rules in `app/styles-shared/*.css`; that directory is bundled into `app.bundle.css` and loaded in editor previews. Use `templates/<slug>/style.css` for island CSS and `app/styles-app/app.css` or the theme for frontend-only globals.
|
|
80
|
+
- Use Alpine for nav, FAQ, tabs, filters, and simple state.
|
|
81
|
+
- Use `module.ts` only for ESM libraries, Swiper, GSAP, ScrollTrigger, SplitText, or behavior Alpine cannot handle cleanly.
|
|
82
|
+
- Use shared block styles for repeated button/control variants instead of copying long Tailwind strings.
|
|
83
|
+
- Keep field handles identical across `fields.yaml`, `recipe.json`, `seeds.json`, Liquid access paths, and blueprint seed files.
|
|
84
|
+
|
|
85
|
+
## CLI Flow
|
|
86
|
+
|
|
87
|
+
Use the discovered command prefix:
|
|
88
|
+
|
|
89
|
+
```bash
|
|
90
|
+
<prefix> bb template patterns --type=<type>
|
|
91
|
+
<prefix> bb template scaffold --slug=<slug> --type=<type> --variant=<variant>
|
|
92
|
+
<prefix> bb dynamic-template package --slug=<slug> --overwrite
|
|
93
|
+
<prefix> bb doctor
|
|
94
|
+
<prefix> bb dynamic-template create --slug=<slug>
|
|
95
|
+
<prefix> bb dynamic-content create --slug=<slug> --source-type=<type> --fields=<slug>/fields.yaml
|
|
96
|
+
<prefix> bb source import-seeds --slug=<slug> --file=<absolute seeds path>
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
If rows already exist, use `dynamic-template update` and `dynamic-content sync`.
|
|
100
|
+
|
|
101
|
+
When the island is used in a page blueprint, create or update:
|
|
102
|
+
|
|
103
|
+
```text
|
|
104
|
+
<workspace>/document-blueprints/<page>/sections/<section-key>.seed.json
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
Then validate:
|
|
108
|
+
|
|
109
|
+
```bash
|
|
110
|
+
<prefix> bb validate
|
|
111
|
+
<prefix> bb document-blueprint validate --slug=<page>
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
Build according to the reported build mode before visual review.
|
|
115
|
+
|
|
116
|
+
## Finish
|
|
117
|
+
|
|
118
|
+
Update the inventory row status and report:
|
|
119
|
+
|
|
120
|
+
- template slug and source type
|
|
121
|
+
- Figma node id
|
|
122
|
+
- files changed
|
|
123
|
+
- section seed files changed
|
|
124
|
+
- commands run
|
|
125
|
+
- design details intentionally approximated or blocked
|
|
126
|
+
- next static review target
|
|
@@ -0,0 +1,209 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: figma-site-builder
|
|
3
|
+
description: Plan and orchestrate full BlockBite sites from Figma using reusable dynamic-template islands, document blueprints, design tokens, and workspace skill handoffs. Use when the user provides a Figma site or multi-page design and wants a site build plan, island inventory, page blueprint map, token setup, header/footer strategy, or coordinated Figma-to-BlockBite implementation workflow.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Figma Site Builder
|
|
7
|
+
|
|
8
|
+
Use this skill as the planning and orchestration layer for full-site builds from Figma.
|
|
9
|
+
|
|
10
|
+
Do not start coding individual islands until the site plan, reusable island inventory, and page blueprint map are understood. For individual section implementation, use `create-template-draft` for new sections and `update-template-draft` for existing sections. For preview-only review, use `render-preview`.
|
|
11
|
+
|
|
12
|
+
## Ground Rules
|
|
13
|
+
|
|
14
|
+
- Prefer MCP tools when a BlockBite MCP server is connected. Use local WP-CLI only when working directly inside a WordPress project without MCP.
|
|
15
|
+
- In MCP mode, call `blockbite-agent-onboarding` before any implementation planning or sandbox writes. In local CLI mode, discover the active WordPress command prefix and use the discovered `<prefix>` in all commands; do not hardcode `ddev`.
|
|
16
|
+
- In MCP-only assignments, do not read local filesystem paths, plugin internals, neighboring repos, WP-CLI output, or direct database state. Remote workspace reads through BlockBite MCP tools are allowed and are the intended authoring contract.
|
|
17
|
+
- Use workspace docs, workspace skills, MCP onboarding output, local `<prefix> bb learn` output, CLI help, and user-provided docs. Do not inspect BlockBite plugin internals while using this skill.
|
|
18
|
+
- Avoid direct database queries unless no CLI or documentation path exposes the needed state.
|
|
19
|
+
- Prefer dynamic templates for every island so fields, subcollections, assets, and package data stay explicit.
|
|
20
|
+
- Reuse dynamic templates when designs overlap. Vary page content through document-blueprint section seed files instead of creating page-specific duplicate templates.
|
|
21
|
+
- Header and footer are dynamic templates. Plan `site-header` as the theme header pattern and `site-footer` as the theme footer pattern.
|
|
22
|
+
- Use UI DSL tags so package data and dynamic-content contracts can be generated and synced cleanly.
|
|
23
|
+
- Use Tailwind in `template.liquid`; use `style.css` only for masks, keyframes, pseudo-elements, or layout details Tailwind cannot express cleanly.
|
|
24
|
+
- Do not plan or place page/global styling in `app/styles-shared/*.css` unless it is intentionally shared and selector-scoped. That folder is bundled into `app.bundle.css` and loaded in editor previews; frontend-only globals belong in `app/styles-app/app.css` or the theme, and island CSS belongs in `templates/<slug>/style.css`.
|
|
25
|
+
- Use Alpine for simple state. Use `module.ts` only for ESM libraries, Swiper, GSAP, ScrollTrigger, SplitText, or behavior Alpine cannot handle cleanly.
|
|
26
|
+
- Use BlockBite SVG fields/assets for icons and decorative SVGs.
|
|
27
|
+
- Use BlockBite block styles for shared button variants.
|
|
28
|
+
|
|
29
|
+
## Required Orientation
|
|
30
|
+
|
|
31
|
+
1. Run or read the current orientation output:
|
|
32
|
+
|
|
33
|
+
MCP mode:
|
|
34
|
+
|
|
35
|
+
```json
|
|
36
|
+
blockbite-agent-onboarding { "format": "codex", "topic": "site-builder" }
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
Local CLI mode:
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
<prefix> bb learn --format=codex
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
2. In MCP mode, inspect the onboarding `readiness` and `readBeforeEditing` payload:
|
|
46
|
+
- Read required files with `blockbite-workspace-read`, not local filesystem tools.
|
|
47
|
+
- Stop before planning implementation details if `readiness.requiredAuthoringDocsAvailable` is false.
|
|
48
|
+
- Report missing required authoring docs instead of guessing BlockBite behavior.
|
|
49
|
+
|
|
50
|
+
3. Read relevant workspace context before acting:
|
|
51
|
+
- `dev/skills/index.json` for the installed workflow index.
|
|
52
|
+
- `dev/skills/mcp-tools.json` for MCP tools and local fallbacks.
|
|
53
|
+
- `dev/skills/create-template-draft/SKILL.md` for new section packages.
|
|
54
|
+
- `dev/skills/update-template-draft/SKILL.md` for existing section packages.
|
|
55
|
+
- `dev/skills/render-preview/SKILL.md` for seed-backed review previews.
|
|
56
|
+
- `dev/skills/references/block-dsl.md` and `dev/skills/references/tailwind-utilities.md` when authoring or reviewing DSL/Tailwind.
|
|
57
|
+
|
|
58
|
+
4. If Figma access is needed, verify the file key, node ids, metadata/context access, and screenshots before planning implementation details.
|
|
59
|
+
|
|
60
|
+
5. Before creating or editing templates, report orientation evidence:
|
|
61
|
+
- working mode: MCP-only or local CLI
|
|
62
|
+
- selected BlockBite project and onboarding readiness
|
|
63
|
+
- required remote docs read or missing
|
|
64
|
+
- Figma file key, node ids, metadata/design context, and screenshots inspected
|
|
65
|
+
- reusable dynamic-template island inventory
|
|
66
|
+
- document-blueprint section order and seed files
|
|
67
|
+
- design-token map
|
|
68
|
+
- preview/build plan
|
|
69
|
+
|
|
70
|
+
## Planning Files
|
|
71
|
+
|
|
72
|
+
Create planning output under:
|
|
73
|
+
|
|
74
|
+
```text
|
|
75
|
+
<workspace>/dev/plans/<site>/
|
|
76
|
+
site-plan.md
|
|
77
|
+
island-inventory.md
|
|
78
|
+
page-blueprint-map.md
|
|
79
|
+
token-map.md
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
`site-plan.md` must include:
|
|
83
|
+
|
|
84
|
+
- working mode: MCP or local CLI
|
|
85
|
+
- MCP onboarding tool result or discovered local command prefix
|
|
86
|
+
- Figma file keys and relevant node ids
|
|
87
|
+
- build mode and build command/tool
|
|
88
|
+
- library/CDN setup requirements
|
|
89
|
+
- token setup status
|
|
90
|
+
- header/footer registration plan
|
|
91
|
+
- known blockers or inaccessible Figma nodes
|
|
92
|
+
|
|
93
|
+
`island-inventory.md` must list unique reusable dynamic templates, not every page occurrence. Each row must include:
|
|
94
|
+
|
|
95
|
+
- reusable template slug
|
|
96
|
+
- Figma node ids that map to this design
|
|
97
|
+
- pages using it
|
|
98
|
+
- behavior, such as static, Alpine accordion, logo marquee, GSAP reveal, or Swiper slider
|
|
99
|
+
- source type, usually `block_instance`; use `post_type` or `collection` only when content is genuinely data-backed
|
|
100
|
+
- fields and subcollections
|
|
101
|
+
- required media/SVG assets
|
|
102
|
+
- status: `planned`, `scaffolded`, `preview-built`, `reviewed`, `registered`, or `wired`
|
|
103
|
+
|
|
104
|
+
`page-blueprint-map.md` must lock each page section order before implementation. Map every section key to a reusable template slug and a seed file. Example order:
|
|
105
|
+
|
|
106
|
+
```text
|
|
107
|
+
site-header
|
|
108
|
+
banner
|
|
109
|
+
logo-slider
|
|
110
|
+
quote
|
|
111
|
+
usp-cards
|
|
112
|
+
project-slider
|
|
113
|
+
commitment
|
|
114
|
+
featured-blogs
|
|
115
|
+
shared-cta
|
|
116
|
+
faq
|
|
117
|
+
site-footer
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
`token-map.md` must map accessible Figma colors, type, radius, and spacing decisions to Tailwind v4 `@theme` variables in `<workspace>/dev/css/design-tokens.css`. Agents may add any valid `@theme` variables needed by the design; do not use `dev/design-tokens.yaml` or force tokens into the old normalized schema.
|
|
121
|
+
|
|
122
|
+
## Blueprint-First Page Composition
|
|
123
|
+
|
|
124
|
+
Use document blueprints for page assembly:
|
|
125
|
+
|
|
126
|
+
```text
|
|
127
|
+
<workspace>/document-blueprints/<page>/blueprint.json
|
|
128
|
+
<workspace>/document-blueprints/<page>/sections/<section-key>.seed.json
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
Use page-specific seed files for reused templates. For example, `home/project-slider.seed.json` and `services/project-slider.seed.json` can target the same `project-slider` template with different content.
|
|
132
|
+
|
|
133
|
+
Preview with `bb_document_blueprint`; do not create manually duplicated aggregate stacks for blueprint pages. Import only after approval, because document-blueprint import overwrites managed page content.
|
|
134
|
+
|
|
135
|
+
## MCP And CLI Flow
|
|
136
|
+
|
|
137
|
+
In MCP mode, use BlockBite MCP tools for workspace reads, sandbox writes, previews, validation, and builds:
|
|
138
|
+
|
|
139
|
+
```text
|
|
140
|
+
blockbite-workspace-status
|
|
141
|
+
blockbite-build-status
|
|
142
|
+
blockbite-workspace-list
|
|
143
|
+
blockbite-workspace-read
|
|
144
|
+
blockbite-workspace-search
|
|
145
|
+
blockbite-template-scaffold
|
|
146
|
+
blockbite-template-create-draft
|
|
147
|
+
blockbite-workspace-write
|
|
148
|
+
blockbite-workspace-patch
|
|
149
|
+
blockbite-template-render-preview
|
|
150
|
+
blockbite-validate-workspace
|
|
151
|
+
blockbite-sandbox-status
|
|
152
|
+
blockbite-build-run
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
MCP writes must stay in the sandbox until the user approves them in WordPress. MCP agents do not run Node.js, import BlockBite build chunks, or call local WP-CLI build commands.
|
|
156
|
+
|
|
157
|
+
In local CLI mode, use the discovered command prefix:
|
|
158
|
+
|
|
159
|
+
```bash
|
|
160
|
+
<prefix> bb template patterns --type=<type>
|
|
161
|
+
<prefix> bb template scaffold --slug=<slug> --type=<type> --variant=<variant>
|
|
162
|
+
<prefix> bb dynamic-template package --slug=<slug> --overwrite
|
|
163
|
+
<prefix> bb document-blueprint generate --file=<spec> --overwrite
|
|
164
|
+
<prefix> bb document-blueprint validate --slug=<page>
|
|
165
|
+
<prefix> bb dynamic-template create --slug=<slug>
|
|
166
|
+
<prefix> bb dynamic-template update --slug=<slug>
|
|
167
|
+
<prefix> bb dynamic-content create --slug=<slug> --source-type=<type> --fields=<slug>/fields.yaml
|
|
168
|
+
<prefix> bb dynamic-content sync --slug=<slug> --source-type=<type> --fields=<slug>/fields.yaml
|
|
169
|
+
<prefix> bb source import-seeds --slug=<slug> --file=<absolute seeds path>
|
|
170
|
+
```
|
|
171
|
+
|
|
172
|
+
For design tokens:
|
|
173
|
+
|
|
174
|
+
```bash
|
|
175
|
+
<prefix> bb design-tokens db-to-local
|
|
176
|
+
<prefix> bb design-tokens local-to-db
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
For validation and builds:
|
|
180
|
+
|
|
181
|
+
```bash
|
|
182
|
+
<prefix> bb doctor
|
|
183
|
+
<prefix> bb validate
|
|
184
|
+
<prefix> bb autobuild
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
## Shared Styles And Libraries
|
|
188
|
+
|
|
189
|
+
Plan shared `bb/button` block styles for:
|
|
190
|
+
|
|
191
|
+
- `primary`
|
|
192
|
+
- `secondary`
|
|
193
|
+
- `text-link`
|
|
194
|
+
- `slider-arrow`
|
|
195
|
+
|
|
196
|
+
Use the workspace block offload/build flow before relying on these variants.
|
|
197
|
+
|
|
198
|
+
Register Alpine, GSAP, ScrollTrigger, SplitText, Swiper, and Alpine collapse only when the site actually needs them. Register Alpine collapse when FAQ or other panels use `x-collapse`.
|
|
199
|
+
|
|
200
|
+
## Handoff
|
|
201
|
+
|
|
202
|
+
When planning is complete, give the next agent or pass:
|
|
203
|
+
|
|
204
|
+
- the planning folder path
|
|
205
|
+
- the Figma file key and node id for the next island
|
|
206
|
+
- the chosen reusable template slug
|
|
207
|
+
- source type, fields, subcollections, assets, and expected behavior
|
|
208
|
+
- the page blueprint section keys and seed files that will use the island
|
|
209
|
+
- the static acceptance criteria before motion work starts
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: frame-draft-link
|
|
3
|
+
description: Draft directly into a copied BlockBite frame draft link. Use when the user pastes a blockbite://frame-draft link from the BlockBite editor toolbar.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Draft into a BlockBite frame link
|
|
7
|
+
|
|
8
|
+
Use this workflow when the user gives a `blockbite://frame-draft?...` link from
|
|
9
|
+
the BlockBite editor. This is not a dynamic-template package workflow. The goal
|
|
10
|
+
is to let the editor poll, compile, and offer an explicit **Apply draft** action
|
|
11
|
+
without saving the WordPress post.
|
|
12
|
+
|
|
13
|
+
## Link contract
|
|
14
|
+
|
|
15
|
+
Parse the query string from the link:
|
|
16
|
+
|
|
17
|
+
- `id` - draft session id.
|
|
18
|
+
- `draft` - relative workspace path for the Liquid file, normally
|
|
19
|
+
`drafts/<id>/draft.liquid`.
|
|
20
|
+
- `manifest` - relative workspace path for the manifest, normally
|
|
21
|
+
`drafts/<id>/manifest.json`.
|
|
22
|
+
- `site` - originating WordPress site URL.
|
|
23
|
+
- `token` - editor session token. Preserve it in the manifest if useful, but do
|
|
24
|
+
not print it back unless the user asks.
|
|
25
|
+
|
|
26
|
+
If `draft` or `manifest` is missing, derive them from `id` using the normal
|
|
27
|
+
`drafts/<id>/...` paths.
|
|
28
|
+
|
|
29
|
+
## Steps
|
|
30
|
+
|
|
31
|
+
1. Ensure the BlockBite MCP project is selected and the workspace tools are
|
|
32
|
+
available. Use the connection-status or project-select skills if needed.
|
|
33
|
+
2. Create the draft folder through `blockbite-workspace-write` by writing a
|
|
34
|
+
small JSON manifest to `manifest`.
|
|
35
|
+
3. Write only BlockBite UI-DSL Liquid to `draft`.
|
|
36
|
+
4. Tell the user the editor toolbar should move through waiting/writing/compiled
|
|
37
|
+
states and that they can click **Apply draft** in the editor when ready.
|
|
38
|
+
|
|
39
|
+
## Manifest shape
|
|
40
|
+
|
|
41
|
+
Keep the manifest small and descriptive:
|
|
42
|
+
|
|
43
|
+
```json
|
|
44
|
+
{
|
|
45
|
+
"kind": "blockbite-frame-draft",
|
|
46
|
+
"version": 1,
|
|
47
|
+
"id": "<id>",
|
|
48
|
+
"site": "<site>",
|
|
49
|
+
"draft": "drafts/<id>/draft.liquid"
|
|
50
|
+
}
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
## Authoring rules
|
|
54
|
+
|
|
55
|
+
- Write `draft.liquid` only. Do not create `style.css`, `module.ts`,
|
|
56
|
+
`fields.yaml`, `seeds.json`, or `recipe.json`.
|
|
57
|
+
- Do not write under `templates/` or `islands/`.
|
|
58
|
+
- Do not edit `post_content`, call sync/apply tools, or save/publish the page.
|
|
59
|
+
- Use BlockBite UI-DSL Liquid only. The editor will compile it to serialized
|
|
60
|
+
block JSON/markup during polling.
|
|
61
|
+
- Prefer `bb/frame`, `bb/group`, `bb/richtext`, `bb/image`, `bb/button`, and
|
|
62
|
+
safe core blocks that the UI-DSL compiler already supports.
|
|
63
|
+
- Keep all styling in UI-DSL block attributes/classes. No free-standing CSS for
|
|
64
|
+
this V1 workflow.
|
|
65
|
+
- If the user asks for an iteration on the same draft, overwrite the same
|
|
66
|
+
`draft.liquid`; the editor will detect the changed file hash and recompile.
|
|
67
|
+
|
|
68
|
+
## Minimal Liquid example
|
|
69
|
+
|
|
70
|
+
```liquid
|
|
71
|
+
{% ui 'bb/frame', class: 'mx-auto max-w-5xl px-6 py-16 bg-white' %}
|
|
72
|
+
{% ui 'bb/group', class: 'grid gap-6 md:grid-cols-2 items-center' %}
|
|
73
|
+
{% ui 'bb/richtext', contentTag: 'h2', class: 'text-4xl font-semibold tracking-normal text-neutral-950', content: 'A focused draft section' /%}
|
|
74
|
+
{% ui 'bb/richtext', contentTag: 'p', class: 'text-base leading-7 text-neutral-600', content: 'This draft was written through the copied BlockBite frame link and can be applied from the editor toolbar.' /%}
|
|
75
|
+
{% endui %}
|
|
76
|
+
{% endui %}
|
|
77
|
+
```
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: islands-list
|
|
3
|
+
description: List the published BlockBite islands (id, nanoid, slug, title) on the selected project's WordPress site. Use when the user asks to list islands, see their islands, or find an island slug/id. Read-only.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# List BlockBite islands
|
|
7
|
+
|
|
8
|
+
## Steps
|
|
9
|
+
|
|
10
|
+
1. Ensure a project is selected (use the project-select skill if not).
|
|
11
|
+
2. Call the `blockbite-islands-list` MCP tool (no arguments).
|
|
12
|
+
3. Present each island with its `id`, `nanoid`, `slug`, and `title`.
|
|
13
|
+
|
|
14
|
+
## Notes
|
|
15
|
+
|
|
16
|
+
- This is the correct, supported way to list islands. **Never** read the site's
|
|
17
|
+
public WordPress REST API (e.g. `/wp-json/wp/v2/...`) to find islands — the
|
|
18
|
+
`island` content is not exposed there.
|
|
19
|
+
- If `blockbite-connection-status` shows `bearer_available: false`, that is
|
|
20
|
+
expected before the first Studio call. Just call `blockbite-islands-list`
|
|
21
|
+
anyway; it triggers the bearer exchange. Only a `studio_*` error means there is
|
|
22
|
+
a real connection problem.
|
|
23
|
+
- This tool is read-only: it never exports, imports, or modifies islands or any
|
|
24
|
+
WordPress content.
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: project-select
|
|
3
|
+
description: Select the active BlockBite project so subsequent Studio tools target the right WordPress site. Use when the user names a project/site to work on, or after listing projects.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Select a BlockBite project
|
|
7
|
+
|
|
8
|
+
## Steps
|
|
9
|
+
|
|
10
|
+
1. If you do not know the project `id`, call `blockbite-projects-list` first.
|
|
11
|
+
2. Call `blockbite-project-select` with `{ "projectId": "<id>" }`.
|
|
12
|
+
3. Confirm selection with `blockbite-connection-status`.
|
|
13
|
+
|
|
14
|
+
## Notes
|
|
15
|
+
|
|
16
|
+
- Selection is required before any `blockbite-template-*`, `blockbite-workspace-*`,
|
|
17
|
+
`blockbite-sync-plan-*`, or `blockbite-sandbox-*` tool will run.
|
|
18
|
+
- A single-project account is selected automatically; you can still re-select
|
|
19
|
+
explicitly to switch sites.
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: projects-list
|
|
3
|
+
description: List the BlockBite projects the connected Platform account can access. Use when the user asks which BlockBite projects or sites are available, or before selecting a project.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# List BlockBite projects
|
|
7
|
+
|
|
8
|
+
## Steps
|
|
9
|
+
|
|
10
|
+
1. Call the `blockbite-projects-list` MCP tool (no arguments).
|
|
11
|
+
2. Present each project with its `id`, `name`, `access` (owner or creator-seat),
|
|
12
|
+
and connected `studio_site_url`.
|
|
13
|
+
3. Highlight the currently selected project if `selected_project_id` is set.
|
|
14
|
+
|
|
15
|
+
## Next
|
|
16
|
+
|
|
17
|
+
- To act on a project, use the project-select skill with the project `id`.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: render-preview
|
|
3
|
+
description: Render a seed-backed preview of a BlockBite template so proposed pages can be inspected without touching live WordPress posts. Use when the user wants to see how a template looks.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Render a BlockBite template preview
|
|
7
|
+
|
|
8
|
+
## Steps
|
|
9
|
+
|
|
10
|
+
1. Ensure a project is selected.
|
|
11
|
+
2. Call `blockbite-template-render-preview` with `{ "slug": "<slug>" }` or
|
|
12
|
+
`{ "view": "templates/<slug>/template.liquid" }`. The preview uses seed data
|
|
13
|
+
only (`dataMode: "seed"`).
|
|
14
|
+
3. Return the preview URL to the user as the deliverable.
|
|
15
|
+
|
|
16
|
+
## Notes
|
|
17
|
+
|
|
18
|
+
- Previews never create or read live posts. They are safe to run repeatedly.
|
|
19
|
+
- The preview URL is the deliverable. Do **not** open a browser or use browser
|
|
20
|
+
automation to "verify" it — just return the link.
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: sandbox-status
|
|
3
|
+
description: Show the BlockBite sandbox readiness and the pending change ledger for the selected project. Use when the user asks what is staged, or before approving/promoting changes.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# BlockBite sandbox status
|
|
7
|
+
|
|
8
|
+
## Steps
|
|
9
|
+
|
|
10
|
+
1. Ensure a project is selected.
|
|
11
|
+
2. Call `blockbite-sandbox-status` (no arguments).
|
|
12
|
+
3. Report sandbox readiness, the active session, and pending packages from the
|
|
13
|
+
audit ledger.
|
|
14
|
+
|
|
15
|
+
## Notes
|
|
16
|
+
|
|
17
|
+
- This is read-only; it never modifies files or the ledger.
|
|
18
|
+
- Promotion/approval of the sandbox happens in WordPress by the site owner.
|
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: site-motion-pass
|
|
3
|
+
description: Add motion and interactivity to an already approved static BlockBite site or dynamic-template island, including Alpine state, GSAP/ScrollTrigger/SplitText, Swiper sliders, marquees, reduced-motion behavior, ESM/CDN registration, build validation, and frontend error checks.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Site Motion Pass
|
|
7
|
+
|
|
8
|
+
Use this skill only after the static layout has been reviewed and accepted. Do not use motion work to compensate for unfinished static design matching.
|
|
9
|
+
|
|
10
|
+
## Inputs
|
|
11
|
+
|
|
12
|
+
Require:
|
|
13
|
+
|
|
14
|
+
- approved static page or island target
|
|
15
|
+
- template slug or blueprint page slug
|
|
16
|
+
- intended interaction or animation behavior
|
|
17
|
+
- current build mode and command prefix, or enough context to discover them
|
|
18
|
+
|
|
19
|
+
If the static layout has not been approved, stop and request a static review first.
|
|
20
|
+
|
|
21
|
+
## Read First
|
|
22
|
+
|
|
23
|
+
- `dev/skills/template-figma/SKILL.md` or `dev/skills/template-new/SKILL.md` for the template package contract.
|
|
24
|
+
- `dev/skills/document-blueprint/SKILL.md` when working through a page blueprint preview.
|
|
25
|
+
- `dev/skills/references/tailwind-utilities.md` before adding CSS for masks, marquee tracks, or direct-child styling.
|
|
26
|
+
- The relevant template `template.liquid`, `style.css`, `module.ts`, `manifest.json`, and blueprint seed files.
|
|
27
|
+
|
|
28
|
+
## Implementation Rules
|
|
29
|
+
|
|
30
|
+
- Use Alpine first for nav menus, accordions, tabs, filters, toggles, and simple state.
|
|
31
|
+
- Use `x-collapse` only when Alpine collapse is registered.
|
|
32
|
+
- Use `module.ts` for Swiper, GSAP, ScrollTrigger, SplitText, custom timeline coordination, or behavior Alpine cannot express cleanly.
|
|
33
|
+
- Keep animations progressive: the content must remain usable if JavaScript fails.
|
|
34
|
+
- Add `motion-reduce:*` Tailwind classes or CSS `prefers-reduced-motion` handling for every meaningful motion effect.
|
|
35
|
+
- Do not rewrite static layout while adding motion unless a layout bug prevents the interaction from working.
|
|
36
|
+
- Keep motion scoped to the island or page. Avoid global selectors except for intentionally shared runtime hooks.
|
|
37
|
+
|
|
38
|
+
## Library Registration
|
|
39
|
+
|
|
40
|
+
Register only libraries that are actually used:
|
|
41
|
+
|
|
42
|
+
- Alpine for simple state.
|
|
43
|
+
- Alpine collapse for `x-collapse`.
|
|
44
|
+
- GSAP for timeline/reveal animation.
|
|
45
|
+
- ScrollTrigger for scroll-bound animation.
|
|
46
|
+
- SplitText for text-splitting effects.
|
|
47
|
+
- Swiper for sliders/carousels.
|
|
48
|
+
|
|
49
|
+
Use BlockBite CDN/ESM commands discovered from `<prefix> bb learn`, `<prefix> bb --help`, or relevant workspace docs. Do not hand-edit runtime internals.
|
|
50
|
+
|
|
51
|
+
## Common Patterns
|
|
52
|
+
|
|
53
|
+
- FAQ: Alpine state, `x-show`, `x-collapse`, keyboard/focus-safe buttons, collapse plugin registered.
|
|
54
|
+
- Header/nav: Alpine open state, escape/resize handling when needed, focusable controls, no hidden desktop nav on mobile.
|
|
55
|
+
- Logo marquee: CSS keyframes in `style.css`, duplicated track items in Liquid, pause on hover if expected, reduced-motion fallback.
|
|
56
|
+
- Slider: Swiper in `module.ts`, stable slide widths/heights, accessible buttons, shared `slider-arrow` block style when appropriate.
|
|
57
|
+
- Reveals: GSAP/ScrollTrigger in `module.ts`, no reveal that hides content permanently, reduced-motion immediate-visible fallback.
|
|
58
|
+
|
|
59
|
+
## Validation
|
|
60
|
+
|
|
61
|
+
After edits:
|
|
62
|
+
|
|
63
|
+
```bash
|
|
64
|
+
<prefix> bb validate
|
|
65
|
+
<prefix> bb autobuild
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
Open the page or blueprint preview and inspect:
|
|
69
|
+
|
|
70
|
+
- browser console errors
|
|
71
|
+
- failed network/module requests
|
|
72
|
+
- `window.BlockBiteDebug?.errors` when available
|
|
73
|
+
- desktop and mobile behavior
|
|
74
|
+
- reduced-motion behavior
|
|
75
|
+
- slider/marquee/reveal state after resize
|
|
76
|
+
|
|
77
|
+
If errors appear, use the concrete console/network/runtime failure to identify the path before changing code.
|
|
78
|
+
|
|
79
|
+
## Finish
|
|
80
|
+
|
|
81
|
+
Report:
|
|
82
|
+
|
|
83
|
+
- template or page target
|
|
84
|
+
- interactions added
|
|
85
|
+
- libraries registered or confirmed
|
|
86
|
+
- files changed
|
|
87
|
+
- validation/build/browser checks run
|
|
88
|
+
- remaining static mismatches, if any
|