@se-studio/skills 1.5.0 → 1.5.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/CHANGELOG.md CHANGED
@@ -1,5 +1,43 @@
1
1
  # @se-studio/skills
2
2
 
3
+ ## 1.5.1
4
+
5
+ ### Patch Changes
6
+
7
+ - aa6f11b: Breaking cms-edit CLI prune (2.6.0):
8
+
9
+ **Removed**
10
+
11
+ - `ensure` — use `create … --if-not-exists`
12
+ - `skill` command (including `skill install`) — use `npx skills add @se-studio/skills`
13
+ - `contentful-cms` bin alias — use `cms-edit` only
14
+ - top-level `audit` (`images`, `tree`) — use `asset review --include-usage` and `list`/`open`/`peek`
15
+ - `backup`, `restore`, `revert` — use `diff` + `discard` + Contentful UI
16
+ - top-level `run` — use `batch run --file`
17
+ - top-level `colours`, `types` — use `schema colours`, `schema types <content-type>`
18
+ - `contentful-cms-image-guide` skill — merged into `contentful-cms-media-review`
19
+
20
+ **Added**
21
+
22
+ - `create from-json --if-not-exists`
23
+ - `asset review --include-usage` (slug-bearing usage ancestry)
24
+ - `batch run` subcommand
25
+
26
+ **Migration**
27
+
28
+ | Old | New |
29
+ | ---------------------------------------- | ---------------------------------------------- |
30
+ | `cms-edit ensure tag-type …` | `cms-edit create tag-type … --if-not-exists` |
31
+ | `cms-edit run --file x.json` | `cms-edit batch run --file x.json` |
32
+ | `cms-edit colours` | `cms-edit schema colours` |
33
+ | `cms-edit types component` | `cms-edit schema types component` |
34
+ | `cms-edit audit images` | `cms-edit --json asset review --include-usage` |
35
+ | `cms-edit backup` / `restore` / `revert` | `diff` + `discard`; Contentful UI |
36
+ | `cms-edit skill install` | `npx skills add @se-studio/skills` |
37
+
38
+ - db737d9: Add `site-workflows-deps-update` skill for updating dependencies across se-core-product and consumer repos with Next 15 / Node 24 pins, unified no-pnpm-patches enforcement, and pnpm 11.x updates.
39
+ - 1262175: Remove `cms-edit sitemap` command. Use `list --type <type>` for content discovery. Update skills, MCP prompts, and editor task playbooks.
40
+
3
41
  ## 1.5.0
4
42
 
5
43
  ### Minor Changes
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@se-studio/skills",
3
- "version": "1.5.0",
3
+ "version": "1.5.1",
4
4
  "description": "SE Studio agent skills for marketing site development with Contentful CMS",
5
5
  "repository": {
6
6
  "type": "git",
@@ -0,0 +1,67 @@
1
+ {
2
+ "canonicalPatchesScript": "~/source/se/se-core-product/scripts/check-no-pnpm-patches.mjs",
3
+ "pinOverrides": {
4
+ "next": "^15.5.19",
5
+ "@types/node": "^24.13.2"
6
+ },
7
+ "pnpm": {
8
+ "major": 11,
9
+ "engines": "11.x"
10
+ },
11
+ "projects": [
12
+ {
13
+ "key": "se-core-product",
14
+ "displayName": "SE Core Product",
15
+ "path": "~/source/se/se-core-product",
16
+ "branch": "dev",
17
+ "validate": "bash scripts/check-circular-imports.sh && pnpm skills:validate && pnpm format; pnpm type-check",
18
+ "workspace": true,
19
+ "hasPinOverrides": true
20
+ },
21
+ {
22
+ "key": "se2026",
23
+ "displayName": "SE Studio Site",
24
+ "path": "~/source/se/se-website-2026",
25
+ "branch": "develop",
26
+ "validate": "pnpm check && pnpm type-check",
27
+ "workspace": true,
28
+ "hasPinOverrides": false
29
+ },
30
+ {
31
+ "key": "brightline",
32
+ "displayName": "Brightline Sites",
33
+ "path": "~/source/customers/brightline/brightline-sites",
34
+ "branch": "develop",
35
+ "validate": "pnpm -r validate",
36
+ "workspace": true,
37
+ "hasPinOverrides": false
38
+ },
39
+ {
40
+ "key": "om1",
41
+ "displayName": "OM1 Website",
42
+ "path": "~/source/customers/om1/om1-website",
43
+ "branch": "develop",
44
+ "validate": "pnpm check && pnpm type-check && pnpm validate:routes",
45
+ "workspace": true,
46
+ "hasPinOverrides": false
47
+ },
48
+ {
49
+ "key": "pointme",
50
+ "displayName": "PointMe Marketing Site",
51
+ "path": "~/source/customers/pointme/develop-marketing-site",
52
+ "branch": "develop",
53
+ "validate": "pnpm check && pnpm type-check",
54
+ "workspace": true,
55
+ "hasPinOverrides": false
56
+ },
57
+ {
58
+ "key": "pedestal",
59
+ "displayName": "Pedestal Sites",
60
+ "path": "~/source/customers/pedestal/pedestal-sites",
61
+ "branch": "develop",
62
+ "validate": "pnpm -r validate",
63
+ "workspace": true,
64
+ "hasPinOverrides": false
65
+ }
66
+ ]
67
+ }
@@ -15,7 +15,7 @@ If no brand context is available, ask the user about any brand-specific terms be
15
15
 
16
16
  ## Workflow
17
17
 
18
- 1. **Get all pages**: `cms-edit sitemap`
18
+ 1. **Get all pages**: `cms-edit list --type page`
19
19
  2. **For each page** (or a specific page if the user specified one):
20
20
  a. `cms-edit open --page-slug /<slug>` (or `--article-slug` for articles)
21
21
  b. `cms-edit snapshot` — identify components with visual/image/media fields
@@ -279,8 +279,8 @@ cms-edit add CTA --content-type component --existing-id 4xKj2abcDef
279
279
 
280
280
  Discover available types first:
281
281
  ```bash
282
- cms-edit types component
283
- cms-edit types collection
282
+ cms-edit schema types component
283
+ cms-edit schema types collection
284
284
  ```
285
285
 
286
286
  ### Remove a component
@@ -436,9 +436,9 @@ cms-edit create tag --json-file tag.json --tag-type presentation-type --if-not-e
436
436
  cms-edit create taxonomy-from-json --file taxonomy.json --if-not-exists
437
437
 
438
438
  # Idempotent single-entry creates
439
- cms-edit ensure tag-type --slug conference-venue --name "Conference Venue"
440
- cms-edit ensure tag --slug asco-2025 --name "ASCO 2025" --tag-type conference-venue \
441
- --description "Annual ASCO conference." --featured-image <logoAssetId>
439
+ cms-edit create tag-type --slug conference-venue --name "Conference Venue" --if-not-exists
440
+ cms-edit create tag --slug asco-2025 --name "ASCO 2025" --tag-type conference-venue \
441
+ --description "Annual ASCO conference." --featured-image <logoAssetId> --if-not-exists
442
442
  ```
443
443
 
444
444
  See `cms-edit help fields-taxonomy` and `cms-edit help taxonomy-from-json` for field reference and batch schema.
@@ -463,7 +463,7 @@ cms-edit read @c0 bio
463
463
 
464
464
  **Site/runtime:** Resolved **person links** (`IPersonLink` from the REST API — article authors, collection contents, `contentfulAllPersonLinks`, related-people helpers) include **`bio`** when set in CMS. Use for team cards, related-people collections, and markdown/search export — not only full person detail pages.
465
465
 
466
- **Idempotent taxonomy:** `--if-not-exists` / `ensure` are check-then-create — safe for sequential imports, not for parallel creates on the same slug.
466
+ **Idempotent taxonomy:** `--if-not-exists` is check-then-create — safe for sequential imports, not for parallel creates on the same slug.
467
467
 
468
468
  ```bash
469
469
  # Resolve taxonomy IDs without a session
@@ -481,8 +481,8 @@ cms-edit search "pricing page"
481
481
  cms-edit search "hero" --type component
482
482
 
483
483
  # List valid type values
484
- cms-edit types component
485
- cms-edit types collection
484
+ cms-edit schema types component
485
+ cms-edit schema types collection
486
486
 
487
487
  # List entries with filters
488
488
  cms-edit list --type article --sort date -n 10 # recent articles by publication date
@@ -491,7 +491,7 @@ cms-edit list --type article --slug my-article # article with a specific slug
491
491
  cms-edit list --type article --has-field tags # articles where tags field is non-empty
492
492
 
493
493
  # Find draft articles, then peek/open (both support drafts via CMA)
494
- cms-edit sitemap --include article --status draft
494
+ cms-edit list --type article --sort date
495
495
  cms-edit peek --article-slug resources/blog/my-post
496
496
  # Only list --published / resolve --published are published-only
497
497
 
@@ -566,7 +566,7 @@ cms-edit save
566
566
  ### Add a new section to a page
567
567
  ```bash
568
568
  cms-edit open --page-slug /products
569
- cms-edit types component # discover what's available
569
+ cms-edit schema types component # discover what's available
570
570
  cms-edit add CTA --after @c3
571
571
  cms-edit set @c4 heading "Ready to get started?"
572
572
  cms-edit rtf @c4 body --markdown "Join thousands of teams who trust us."
@@ -611,17 +611,11 @@ cms-edit preview showcase --collection CardGrid --param backgroundColour=Navy
611
611
 
612
612
  For CMS guidelines batch PNG capture, use `cms-capture-screenshots` from `@se-studio/project-build` (separate from cms-edit; requires agent-browser).
613
613
 
614
- ## Revert
614
+ ## Undo changes
615
615
 
616
- Field-level undo — restore fields to their original values from when the session was opened.
616
+ There is no field-level revert command. To abandon unsaved edits: `cms-edit diff` to review, then `cms-edit discard` (or `discard --all`). To roll back saved drafts, use the Contentful web app version history.
617
617
 
618
- ```bash
619
- cms-edit revert @c0 heading # Revert a single field to its original value
620
- cms-edit revert @c0 # Revert all fields on an entry
621
- cms-edit revert --all # Revert all modified entries (session stays open)
622
- ```
623
-
624
- Note: Entries created via `add` cannot be reverted — use `remove` instead.
618
+ Note: Entries created via `add` that you have not saved can be removed with `cms-edit remove <ref>`.
625
619
 
626
620
  ## Health Check
627
621
 
@@ -633,25 +627,27 @@ cms-edit health # Check config file, space config, Contentful connectivity
633
627
 
634
628
  ## Schema Inspection
635
629
 
636
- Inspect field definitions for a content type. Prefer this over `cms-edit types <ct>` when you need full field info.
630
+ Inspect field definitions for a content type. Use `cms-edit schema types <ct>` for type-discriminator values only.
637
631
 
638
632
  ```bash
639
633
  cms-edit schema component # Show all fields, types, enum values, link targets
640
634
  cms-edit schema component --json # Full JSON output
641
635
  ```
642
636
 
643
- ## Sitemap
637
+ ## Content catalog (`list`)
644
638
 
645
- Browse all pages in the space.
639
+ Browse entries by content type (index-backed for catalog types). Run `cms-edit index sync` once per space, or let commands auto-sync.
646
640
 
647
641
  ```bash
648
- cms-edit sitemap # All pages, sorted by slug
649
- cms-edit sitemap --prefix /blog # Filter by slug prefix
650
- cms-edit sitemap --status draft # Draft pages only
651
- cms-edit sitemap --sort updated # Most recently updated first
652
- cms-edit sitemap --include article --sort date # Articles by publication date
653
- cms-edit sitemap --tree # Tree rendering
654
- cms-edit sitemap --include page,article # Include articles too
642
+ cms-edit list --type page # All pages (label sort)
643
+ cms-edit list --type page --sort updated # Most recently updated first
644
+ cms-edit list --type article --sort date # Articles by publication date
645
+ cms-edit list --type pageVariant # A/B or variant pages
646
+ cms-edit list --type tag --tag-type-name "Topic" # Tags under a tag type
647
+ cms-edit list --type tagType # Tag types
648
+ cms-edit list --type articleType # Article types
649
+ cms-edit list --type navigation # Navigations
650
+ cms-edit list --type person --force-cma # People (not in catalog index)
655
651
  ```
656
652
 
657
653
  ## Peek
@@ -663,14 +659,14 @@ cms-edit peek --page-slug /pricing # Show snapshot of /pricing; your active se
663
659
  cms-edit peek --id <entryId> # Look up by entry ID
664
660
  ```
665
661
 
666
- ## Batch Operations (run)
662
+ ## Batch Operations (batch run)
667
663
 
668
664
  Run a sequence of operations from a JSON file or stdin.
669
665
 
670
666
  ```bash
671
- cms-edit run --file ops.json # Run batch ops from file
672
- echo '[...]' | cms-edit run # Pipe from stdin
673
- cms-edit run --file ops.json --dry-run # Validate without saving
667
+ cms-edit batch run --file ops.json # Run batch ops from file
668
+ echo '[...]' | cms-edit batch run # Pipe from stdin
669
+ cms-edit batch run --file ops.json --dry-run # Validate without saving
674
670
  ```
675
671
 
676
672
  Supported ops: `open`, `set`, `rtf`, `rtf-replace`, `save`, `add`, `links-add`.
@@ -823,15 +819,12 @@ cms-edit resolve 4xKj2abcDef
823
819
 
824
820
  ## Inventory & Status
825
821
 
826
- Use `sitemap` to see all pages in a space with their publication status:
822
+ Use `list --type <type>` for inventory. Catalog types (page, article, pageVariant, template, taxonomy, navigation) use the local index. Use `--force-cma` for other types (person, customType, pageTest) or published-only with `--published`.
827
823
 
828
824
  ```bash
829
- cms-edit sitemap # All pages
830
- cms-edit sitemap --prefix /parent-coaching # Filter by slug prefix
831
- cms-edit sitemap --status draft # Draft pages only
832
- cms-edit sitemap --sort updated # Most recently updated first
833
- cms-edit sitemap --tree # Tree view
834
- cms-edit sitemap --include page,article # Include articles
825
+ cms-edit list --type page
826
+ cms-edit list --type article --sort date -n 20
827
+ cms-edit index dump --reference-only # Full catalog snapshot in terminal
835
828
  ```
836
829
 
837
830
  **Note on bulk publish:** The tool cannot publish entries — all saves create drafts only. This is intentional. Review and publish drafts from the Contentful web app.
@@ -115,9 +115,56 @@ Space key: `brightline` (space ID `96gdpqkm7elu`).
115
115
 
116
116
  Production page URLs and definitive unused-asset detection need CMA `links_to_asset` or a production crawl. When available, add columns `prodUrls` and `cmsUsages` to the spreadsheet.
117
117
 
118
+ ## Image guide (optional)
119
+
120
+ Use this extension when the client wants a **reference guide** for all CMS images (Markdown + HTML), not just a quality spreadsheet.
121
+
122
+ ### Gather structural data
123
+
124
+ ```bash
125
+ cms-edit index sync --space <space-key>
126
+ cms-edit --json asset review --include-usage --include-passing --space <space-key> > /tmp/image-inventory.json
127
+ ```
128
+
129
+ Each asset in JSON includes `usages[]`: slug-bearing ancestors (page, article, tag, person, etc.) that ultimately use the asset.
130
+
131
+ To inspect how images relate to a specific page, use `cms-edit open --page-slug /<slug>` + `snapshot`, or `cms-edit peek --page-slug /<slug>` without affecting your session.
132
+
133
+ ### Description cache
134
+
135
+ Store AI-generated visual descriptions per asset (avoids re-inspecting on reruns):
136
+
137
+ ```
138
+ docs/descriptions/{assetId}.json
139
+ ```
140
+
141
+ Per-image format:
142
+
143
+ ```json
144
+ {
145
+ "subjects": "...",
146
+ "setting": "...",
147
+ "composition": "...",
148
+ "colours": "...",
149
+ "mood": "...",
150
+ "style": "...",
151
+ "constraints": "...",
152
+ "whenToUse": "...",
153
+ "inspectedAt": "2026-04-15T10:00:00Z"
154
+ }
155
+ ```
156
+
157
+ **Write-through caching:** After inspecting each new image, write `docs/descriptions/{assetId}.json` before moving to the next. Skip vision calls when the cache file exists.
158
+
159
+ ### Output files
160
+
161
+ - `docs/image-guide.md` — AI-consumable Markdown (chunk writes: ~35 images per append)
162
+ - `docs/image-guide.html` — self-contained human reference (chunk writes: ~15–20 cards per append)
163
+
164
+ Use CDN URLs with `?w=800&q=85` for previews. Group entries by page using `usages[]` from the review JSON.
165
+
118
166
  ## Related
119
167
 
120
168
  - `contentful-cms-alt-text-audit` — per-page alt text fixes
121
- - `contentful-cms-image-guide` — full image inventory with AI descriptions
122
169
  - `cms-edit asset audit` — missing alt only (narrower, faster)
123
170
  - `cms-edit asset set-description <id> "alt"` — fix alt text on an asset
@@ -15,7 +15,7 @@ If no brand context is available, ask the user for these details.
15
15
 
16
16
  ## Phase 1: Analyse Site Structure
17
17
 
18
- 1. `cms-edit sitemap` to get all pages and articles
18
+ 1. `cms-edit list --type page` and `cms-edit list --type article` for inventory
19
19
  2. For each page, use `fetch_page_markdown` (from site-workflows MCP server) to read content
20
20
  3. Categorise each page by Schema.org type:
21
21
 
@@ -15,7 +15,7 @@ If no brand context is available, ask the user about their brand voice and targe
15
15
 
16
16
  ## Workflow
17
17
 
18
- 1. **Get all pages**: `cms-edit sitemap`
18
+ 1. **Get all pages**: `cms-edit list --type page`
19
19
  2. **For each page** (or a specific page):
20
20
  a. **Read page content** using `fetch_page_markdown` (from the site-workflows MCP server) to understand what the page covers
21
21
  b. **Check current SEO**:
@@ -41,7 +41,7 @@ For engineering work in a site repo (Cursor, Grok, terminal):
41
41
 
42
42
  1. Configure `.contentful-cms.json` in the project (or `~/.contentful-cms.json`) with space credentials
43
43
  2. Run `npx skills add @se-studio/skills` or `pnpm skills:sync` in the monorepo
44
- 3. Optionally `cms-edit skill install` for bundled cms-edit skills
44
+ 3. Bundled cms-edit skills (`core`, `setup`, etc.) are included when you run `npx skills add @se-studio/skills`
45
45
  4. Read `cms-edit/<site>/editor-pack/tasks-index.md` before editing content
46
46
 
47
47
  Do **not** register a local `mcpServers.cms-edit` entry in Claude Desktop — use the hosted connector URL instead.
@@ -0,0 +1,185 @@
1
+ ---
2
+ name: site-workflows-deps-update
3
+ description: "Update npm dependencies to latest across se-core-product and consumer SE Studio sites, one repo at a time. Pins Next.js 15 and Node 24, updates pnpm to latest 11.x, enforces no pnpm patches everywhere. Validates, commits, and pushes to dev/develop. Use when asked to update outdated packages or bump dependencies."
4
+ ---
5
+
6
+ # SE dependency update (one project at a time)
7
+
8
+ Update npm dependencies to **latest** in se-core-product and consumer repos that use `@se-studio/*` packages.
9
+
10
+ **Registry:** [`packages/skills/references/deps-update/projects.registry.json`](../../references/deps-update/projects.registry.json) — paths, branches, validate commands.
11
+
12
+ **Default:** Process **one repo per invocation**. At the end, summarize changes and offer the next project.
13
+
14
+ **Never:** push to `main`/`master`; bump Next to 16; bump Node to 25+; use `pnpm patch` / `patchedDependencies` / `patches/`.
15
+
16
+ ---
17
+
18
+ ## Projects
19
+
20
+ | key | displayName | branch |
21
+ |-----|-------------|--------|
22
+ | `se-core-product` | SE Core Product | `dev` |
23
+ | `se2026` | SE Studio Site | `develop` |
24
+ | `brightline` | Brightline Sites | `develop` |
25
+ | `om1` | OM1 Website | `develop` |
26
+ | `pointme` | PointMe Marketing Site | `develop` |
27
+ | `pedestal` | Pedestal Sites | `develop` |
28
+
29
+ User may name a key (`update deps in om1`) or ask to run through all projects sequentially.
30
+
31
+ ---
32
+
33
+ ## Step 1 — Preflight
34
+
35
+ ```bash
36
+ node -v # must be v24.x
37
+ pnpm -v # must be v11.x
38
+ ```
39
+
40
+ In the target repo:
41
+
42
+ 1. Confirm the path from the registry exists; abort if missing.
43
+ 2. `git fetch origin && git checkout <branch> && git pull`
44
+ 3. Working tree must be clean (or user explicitly approves stash).
45
+ 4. Record `pnpm outdated -r` output for the commit summary.
46
+
47
+ ---
48
+
49
+ ## Step 2 — Bootstrap no-pnpm-patches check (all repos)
50
+
51
+ Pedestal already ships `scripts/check-no-pnpm-patches.mjs`; other consumer repos may not. **Every project** must run this check — do not rely on only pedestal's custom validate script.
52
+
53
+ If `scripts/check-no-pnpm-patches.mjs` is missing, copy the canonical script:
54
+
55
+ ```bash
56
+ mkdir -p scripts
57
+ cp ~/source/se/se-core-product/scripts/check-no-pnpm-patches.mjs scripts/check-no-pnpm-patches.mjs
58
+ ```
59
+
60
+ Commit the bootstrap copy as part of the deps update commit when you add it.
61
+
62
+ ---
63
+
64
+ ## Step 3 — Pin overrides (before `--latest`)
65
+
66
+ `pnpm update -r --latest` would bump `next` → 16 and `@types/node` → 26. Add or verify this block in `pnpm-workspace.yaml` (values from registry `pinOverrides`):
67
+
68
+ ```yaml
69
+ overrides:
70
+ next: ^15.5.19
71
+ '@types/node': ^24.13.2
72
+ ```
73
+
74
+ Skip if `hasPinOverrides` is already true and values match. Idempotent — merge into existing `pnpm-workspace.yaml` without removing other keys (`minimumReleaseAge`, `allowBuilds`, etc.).
75
+
76
+ ---
77
+
78
+ ## Step 4 — Update pnpm (all repos)
79
+
80
+ Bump the package manager to the **latest pnpm 11.x** in root `package.json`:
81
+
82
+ ```bash
83
+ LATEST_PNPM=$(npm view pnpm@11 version)
84
+ # Set "packageManager": "pnpm@<LATEST_PNPM>" in package.json
85
+ corepack use pnpm@${LATEST_PNPM}
86
+ pnpm -v # confirm matches packageManager
87
+ ```
88
+
89
+ Keep `engines.pnpm` at `11.x` (do not jump to pnpm 12). If `engines.pnpm` is missing, add `"pnpm": "11.x"` alongside `"node": "24.x"`.
90
+
91
+ ---
92
+
93
+ ## Step 5 — Update dependencies
94
+
95
+ ```bash
96
+ pnpm update -r --latest
97
+ ```
98
+
99
+ If brightline or pedestal repos block fresh packages (`minimumReleaseAge: 1440`), retry with:
100
+
101
+ ```bash
102
+ pnpm update -r --latest --no-minimum-release-age
103
+ ```
104
+
105
+ Safety re-pin after update:
106
+
107
+ ```bash
108
+ pnpm update -r next@^15 @types/node@^24
109
+ pnpm install
110
+ ```
111
+
112
+ Verify pins held:
113
+
114
+ ```bash
115
+ pnpm outdated -r | rg '^(next|@types/node)' || true
116
+ rg '"node"' package.json apps/*/package.json packages/*/package.json 2>/dev/null | rg -v '24' || true
117
+ ```
118
+
119
+ `engines.node` must stay `24.x` or `>=24.0.0 <25` — revert any accidental bump to 25+.
120
+
121
+ ---
122
+
123
+ ## Step 6 — Validate (unified for all repos)
124
+
125
+ Always run the patches check **once**, then the project validate from the registry:
126
+
127
+ ```bash
128
+ node scripts/check-no-pnpm-patches.mjs && <validate from registry>
129
+ ```
130
+
131
+ Registry `validate` commands intentionally **exclude** the patches check so every project uses the same enforcement. Do not skip this step for repos that lack it in their `package.json` scripts today.
132
+
133
+ On failure: fix if trivial; otherwise `git checkout -- .` and stop **without** pushing.
134
+
135
+ ---
136
+
137
+ ## Step 7 — Commit and push
138
+
139
+ ```bash
140
+ git add -A
141
+ git commit -m "chore(deps): update dependencies (<displayName>)"
142
+ git push origin <branch>
143
+ ```
144
+
145
+ - se-core-product → `dev`
146
+ - All consumer repos → `develop`
147
+ - **Never** push to `main`/`master`
148
+
149
+ ---
150
+
151
+ ## Step 8 — Report
152
+
153
+ Include in the summary:
154
+
155
+ - Major dependency bumps (from the Step 1 audit diff)
156
+ - pnpm version: before → after
157
+ - Confirmed pins: Next 15.x, Node 24, `@types/node` ^24
158
+ - Patches check bootstrapped (yes/no)
159
+ - Remaining projects not yet updated
160
+
161
+ Offer to continue with the next project.
162
+
163
+ ---
164
+
165
+ ## Optional: align `package.json` validate scripts
166
+
167
+ After a successful update, you may add the patches check to the root `validate` script in consumer repos that lack it:
168
+
169
+ ```json
170
+ "validate": "node scripts/check-no-pnpm-patches.mjs && pnpm check && pnpm type-check"
171
+ ```
172
+
173
+ This is optional follow-up — the skill workflow always runs the check regardless.
174
+
175
+ ---
176
+
177
+ ## Troubleshooting
178
+
179
+ | Issue | Action |
180
+ |-------|--------|
181
+ | `next` or `@types/node` still outdated to wrong major | Re-run overrides + safety re-pin; check `pnpm-workspace.yaml` overrides |
182
+ | `corepack use` fails | Run `corepack enable` once, retry |
183
+ | Validate fails after major bump | Check breaking-change release notes; fix or revert |
184
+ | Repo path missing | Skip; note in report — see `docs/RELATED_PROJECTS.md` |
185
+ | Patches check fails | Remove `patchedDependencies` / `patches/` — patches are forbidden in all SE repos |
@@ -1,239 +0,0 @@
1
- ---
2
- name: contentful-cms-image-guide
3
- description: "Generate a comprehensive image guide (both Markdown and HTML) for a site's CMS image assets, with rich AI-generated visual descriptions and content relationship trees."
4
- ---
5
-
6
- # Skill: contentful-cms — Image Guide
7
-
8
- Use this skill to generate a **fully enriched image guide** for a site. The guide documents every image in the CMS with:
9
- - Rich visual descriptions generated by inspecting each image
10
- - Content relationship tree showing which pages/components use each image
11
- - Two output formats: Markdown (AI-consumable) and HTML (human reference)
12
-
13
- The output files are written to the app's `docs/` directory (or a path you specify).
14
-
15
- ## When to use
16
-
17
- - Client or team wants a reference guide for all images in the CMS
18
- - Need to know where a specific image is used across the site
19
- - Preparing image guidance for AI agents that will be choosing images
20
- - Auditing image coverage or identifying unused assets
21
-
22
- ## Prerequisites
23
-
24
- - `cms-edit` is configured for the target space (run `cms-edit health` to verify)
25
- - You have read access to the image URLs (standard Contentful CDN URLs work)
26
- - The app directory is known (e.g. `apps/example-brightlifekids/`)
27
-
28
- ## Brand Context
29
-
30
- Before starting, check if a brand context skill is available (e.g., "BrightLife Kids Brand Context"). If so, incorporate brand terminology in the descriptions and "When to use" guidance.
31
-
32
- ---
33
-
34
- ## Workflow
35
-
36
- ### Step 0 — Load description cache
37
-
38
- Each image's description is stored as its own small file to avoid token-limit issues when reading or writing:
39
-
40
- ```
41
- docs/descriptions/{assetId}.json
42
- ```
43
-
44
- **To check if an image is already cached:**
45
- ```bash
46
- ls docs/descriptions/{assetId}.json 2>/dev/null && echo "cached" || echo "not cached"
47
- ```
48
-
49
- **Per-image file format:**
50
- ```json
51
- {
52
- "subjects": "...",
53
- "setting": "...",
54
- "composition": "...",
55
- "colours": "...",
56
- "mood": "...",
57
- "style": "...",
58
- "constraints": "...",
59
- "whenToUse": "...",
60
- "inspectedAt": "2026-04-15T10:00:00Z"
61
- }
62
- ```
63
-
64
- **Write-through caching — CRITICAL:** After visually inspecting each NEW image, immediately write its description to `docs/descriptions/{assetId}.json` using the Write tool BEFORE inspecting the next image. One image → one Write call → next image. Each file is tiny (~1KB), so no token limits apply.
65
-
66
- If `docs/descriptions/{assetId}.json` already exists, read it and use the cached data — **skip the vision call entirely**.
67
-
68
- At the end of the run, report: `N from cache, M newly inspected`.
69
-
70
- **Phase discipline — cache first, guides second:** Complete ALL image inspections and per-image cache writes before starting any guide file. Do not interleave inspection with guide writing.
71
-
72
- > **Note:** If a legacy `docs/image-descriptions-cache.json` file exists, ignore it. The per-file cache supersedes it.
73
-
74
- ### Step 1 — Gather structural data
75
-
76
- Run the audit command to get all images and their page/component usages:
77
-
78
- ```bash
79
- cms-edit --json audit images
80
- ```
81
-
82
- This outputs JSON with every image asset including:
83
- - Asset ID, title, filename, dimensions, MIME type, CDN URL
84
- - `usages[]`: the slug-bearing ancestors (page, article, articleType, pageVariant, tag, person) that ultimately use this asset. Intermediate wrapper entries (media, visual, component, etc.) are walked through transparently and not included. Each usage has `{ id, contentType, label, slug }`.
85
-
86
- Save the output to a temporary file or keep it in context.
87
-
88
- If the output is large, focus on images grouped by page. Use `cms-edit audit tree --page /<slug>` to see the relationship tree for a specific page:
89
-
90
- ```bash
91
- cms-edit audit tree --page /
92
- cms-edit audit tree --page /families
93
- ```
94
-
95
- ### Step 2 — Inspect each image visually
96
-
97
- For each image in the JSON output, fetch the image URL and inspect it carefully. The CDN URL supports resize parameters — use `?w=800&q=85` for a good preview:
98
-
99
- ```
100
- https://images.ctfassets.net/{spaceId}/{assetId}/{hash}/{filename}?w=800&q=85
101
- ```
102
-
103
- For each image generate a **visual description** covering ALL of these fields:
104
-
105
- | Field | What to capture |
106
- |-------|----------------|
107
- | **Subjects** | Count of people, apparent ages, genders (if relevant), expressions, what they are doing |
108
- | **Setting** | Indoor/outdoor, room type or environment, background detail level, time of day |
109
- | **Composition** | Landscape or portrait, crop tightness (headshot / mid-shot / wide / full-bleed), focal point position, negative space |
110
- | **Colours** | 3–5 dominant colours with approximate descriptions (e.g. "warm cream, sage green, muted terracotta"), warm vs cool tone, contrast level |
111
- | **Mood** | One or two words: playful, warm, clinical, energetic, calm, aspirational, inclusive, serious |
112
- | **Style** | Photography (stock / custom-produced), illustration, icon, UI mockup, logo |
113
- | **Constraints** | What the image does NOT have — e.g. "no text overlay space", "subject fills frame", "no negative space for overlay", "transparent background" |
114
-
115
- For icons, logos, and UI mockups, the description can be shorter and focus on what the graphic represents and its visual style.
116
-
117
- ### Step 3 — Determine "When to use" guidance
118
-
119
- Based on the image's current usages and its visual content, write a concise "When to use" paragraph covering:
120
- - Component types it suits (Hero, CtaCard, wide-format, etc.)
121
- - Content topics or page contexts where it fits
122
- - What NOT to use it for (age group constraints, format constraints, etc.)
123
- - Any reuse notes (e.g. "also used as /partners hero — suitable for both card and full-width formats")
124
-
125
- ### Step 4 — Write the Markdown guide
126
-
127
- Output path: `docs/image-guide.md` inside the app directory (e.g. `apps/example-brightlifekids/docs/image-guide.md`).
128
-
129
- **IMPORTANT — chunked writing to avoid output token limits:** The guide file will be large (many KB). Never try to write the entire file in a single Write tool call. Instead, use bash heredoc append operations in batches:
130
-
131
- ```bash
132
- # First call — write file header + first ~35 images (use actual app path)
133
- cat > apps/example-brightlifekids/docs/image-guide.md << 'MDEOF'
134
- # BrightLife Kids — Image Guide
135
-
136
- > Generated 2026-04-15. Space: blk. 202 images documented.
137
- ...
138
- ## Image 1 · filename.jpg
139
- ...
140
- MDEOF
141
-
142
- # Subsequent calls — APPEND next batch (note >>)
143
- cat >> apps/example-brightlifekids/docs/image-guide.md << 'MDEOF'
144
- ## Image 36 · filename.jpg
145
- ...
146
- MDEOF
147
- ```
148
-
149
- Keep each bash call to **35 images maximum** (~18,000 tokens of content per call). Use as many `cat >>` append calls as needed. For descriptions, read from the cached `docs/descriptions/{assetId}.json` files rather than re-inspecting.
150
-
151
- Use this structure:
152
-
153
- ```markdown
154
- # {Brand} — Image Guide
155
-
156
- > Generated {date}. Space: {spaceKey}. {N} images documented.
157
- >
158
- > **AI usage note**: Each entry below has consistent fields for programmatic selection.
159
- > Match `Subjects`, `Setting`, and `Mood` to the content context. Use `Constraints` to
160
- > rule out images that won't work for a given layout. `Used on` shows exact page/component context.
161
-
162
- ---
163
-
164
- ## {image title} · {filename}
165
-
166
- **Asset ID**: `{id}`
167
- **Dimensions**: {width}×{height} · {contentType}
168
- **CDN URL**: `{url}?w=800&q=85`
169
-
170
- **Used on**:
171
- - {slug} — {contentType} "{label}"
172
- - _(repeat for each usage; omit if usages array is empty — mark as "Unused / unattached")_
173
-
174
- **Subjects**: {description}
175
- **Setting**: {description}
176
- **Composition**: {description}
177
- **Colours**: {description}
178
- **Mood**: {description}
179
- **Style**: {description}
180
- **Constraints**: {description}
181
-
182
- **When to use**: {paragraph}
183
-
184
- ---
185
- ```
186
-
187
- Repeat for every image. Group images by page/section using `## Section: {page title}` headings before each page's images, matching the structure the `audit images` output provides.
188
-
189
- ### Step 5 — Write the HTML guide
190
-
191
- Output path: `docs/image-guide.html` inside the app directory.
192
-
193
- **IMPORTANT — chunked writing:** HTML files are much larger than Markdown. Use the same bash heredoc append strategy, but with **smaller batches of 15–20 image cards** per operation. Start with the full `<html>`, `<head>`, CSS, and opening body tags, then append cards in batches, then append the closing tags last.
194
-
195
- The HTML guide is a self-contained human reference (no server needed). Model it on the existing `tmp/blk-image-guide.html` style but with the following enhancements:
196
-
197
- 1. **Visual detail block**: Add a new `<div class="visual-detail-box">` section in each card containing the structured visual fields (Subjects, Setting, Composition, Colours, Mood, Style, Constraints) as a compact `<table>`.
198
-
199
- 2. **Usage tree**: In the metadata table, expand the `Pages` row to show the full chain: `{pageSlug} → {componentType} "{label}" (field: {fieldName})`.
200
-
201
- 3. **Site tree section**: Add a collapsible `<details>` section at the top of the page titled "Full Site Content Tree" that shows the inverse view — for each page, what images appear on it.
202
-
203
- 4. **LLM note**: Update the LLM usage note at the top to reference the structured visual fields.
204
-
205
- The HTML must:
206
- - Be fully self-contained (inline CSS, no external dependencies)
207
- - Work without a web server (file:// protocol)
208
- - Match the brand colours of the target site
209
- - Show thumbnail images with lazy loading
210
-
211
- ### Step 6 — Verify and report
212
-
213
- After writing both files, confirm:
214
- 1. Every image from the `audit images` output has an entry in both files
215
- 2. The "Used on" relationships match what `audit tree` shows
216
- 3. The Markdown file is clean and can be read without a browser
217
-
218
- Present a summary:
219
-
220
- | Image | Pages used on | Visual description added | Notes |
221
- |-------|--------------|--------------------------|-------|
222
- | ... | ... | ✓ | ... |
223
-
224
- Report the output paths and any images that had no usages (potential orphans).
225
-
226
- ---
227
-
228
- ## Tips
229
-
230
- - **Efficient image inspection**: Fetch images in batches. Process all images for a page together before moving to the next page.
231
- - **Orphaned assets**: Images with no usages (`usages: []` in the JSON) are likely unused. Flag them but still document them — they may be intentionally held in reserve.
232
- - **SVG icons**: For SVG assets, use the direct URL (no resize params needed). Describe the graphic shape and colour precisely.
233
- - **Stock vs custom**: Check the filename for patterns like `AdobeStock_`, `pexels-`, `unsplash-` to identify stock images. Custom-produced images typically have branded filenames.
234
- - **Mobile variants**: Some components have both `visual` and `mobileVisual` fields. If the same image appears in both, note the dual-use in the description.
235
-
236
- ## Related skills
237
-
238
- - **core**: Full cms-edit workflow; use `preview url` / `preview showcase` for visual checks via browser MCP
239
- - **alt-text-audit**: Audit and improve alt text on existing images