Deliberately high for now to avoid premature auto-switching while we
gather data on real pages.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Block-level conversion generates N independent blocks — own JS, CSS,
content model, no shared state. Phase 3 (B.5) now explicitly states
blocks can be generated in parallel if the host supports concurrent
work dispatch. The hint is intent-level (no specific tool prescribed),
matching the browser-intent pattern.
HOST-NOTES updated: replaced the "out of scope in v1" parallelism
disclaimers with per-host guidance — Slicc dispatches one scoop per
block via the cone, Claude Code dispatches one Agent subagent per block.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When an <a> contains authorable text alongside decorative non-authorable
children (inline SVGs, icon images), placing data-slot on the <a> causes
writeSlot to destroy the decorative content at runtime.
Adds:
- Learnings entry documenting the pattern and the general rule
- Phase 2 mixed-content detection: slots flagged with mixedContent=true
in decisions.json when <a> contains SVG/decorative-img/icon children
- Phase 3 span-wrapper rule: wrap only the authorable text in a
<span data-slot>, leaving decorative siblings as template chrome
- Self-check #7: DOM-based post-generate validation that no data-slot
element contains SVG or decorative image descendants
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Large pages with many sections or slottable elements risk silent content
loss during page-level conversion (context pressure, repetitive-structure
fatigue). Block-level processes one section at a time and is immune.
Phase 2 now checks: >8 sections or >100 slottable elements. When the gate
fires and level=page was the default (not explicitly requested), it
auto-switches to block-level and proceeds. When level=page was explicitly
passed, it warns but respects the user's choice. level=auto/block/check
are unaffected. The outcome is recorded in decisions.json as
complexityGate + sectionCount + slottableElementCount.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The slot-identification rules in Phase 2 and methodology.md said "Visible
text" which caused the agent to skip content inside hidden tab panels,
collapsed accordions, and inactive carousel slides. CSS visibility is
irrelevant during content extraction — the template's own JS/CSS handles
show/hide at render time. All DOM content is now treated as authorable.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The installer stamped "daRoot": "" into config, which the resolution logic
treated as "set" — so the branch-name fallback never triggered. Removing
daRoot from defaults entirely means the key is absent in a fresh config,
and the Phase 1 resolution correctly falls back to the current branch name.
Users who explicitly set daRoot in their config are unaffected.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Instead of hardcoding /marketing, the DA root now defaults to the current
git branch name — the same branch the skill uses for code. This matches
the common EDS convention where DA content lives under a path named after
the branch. The config daRoot key still overrides when set; the value is
always shown in the init summary for correction.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Page-level overlay is the safer, more common path. Making it the default
means /snowflake <url> proceeds directly to page-level conversion without
a feasibility-gate question. level=auto is still available for users who
want the analysis to decide.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
loadSections(element) queries div.section descendants. The overlay template
contains the original static page's <main> markup with plain design elements,
not EDS wrapper div.section nodes, so the call finds zero matches and returns
immediately. The old woven scripts.js guard was defensive but unnecessary; the
new hook-based approach omits it intentionally.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The installer's no-marker branch flagged every non-empty file that differed
from the bundled substrate as "custom content" and refused without --force.
But a vanilla aem-boilerplate clone always has non-empty stock files that
differ from the substrate — that's exactly what the skill replaces — so the
common case always tripped a redundant confirmation pause.
The no-marker case now installs directly: it reports which pre-existing files
it replaces (so a genuinely custom file is still surfaced) but does not block.
Originals are backed up unconditionally and the init summary already disclosed
the file count, so the install is reversible and pre-disclosed.
The drift case (marker present but files diverged from the bundled version)
still refuses without --force — there a prior snowflake substrate could carry
intentional customization, so a human decision is warranted.
Phase 0 docs collapse the former Clean/Custom-code cases into one no-pause
Fresh-install case; SKILL.md Initialization note updated to match. Also folds
a duplicate "After install" heading introduced in an earlier edit.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Phase 5 is now an explicit pass/fail gate rather than an advisory report.
Before the run may continue to Phase 6, the converted page must pass six
checks on both local and production preview:
1. Renders (not blank) — visible text, rendered height, section count
2. Overlay applied — main[data-overlay] and body.appear
3. Structure matches decisions.json
4. No console errors (font-CORS tolerated, must be recorded)
5. No network failures or broken images (about:error / naturalWidth 0)
6. 1:1 with the source via dom-equality.mjs (PASS, or only the known
wrapper-element deltas)
The previous consoleErrors check read window.__errors, which nothing ever
populates — it always returned 0. Replaced with real capture: the browser
tool's console/network logs, with an injectable in-page listener fallback
for tools that can't surface them. The evaluate payload now also reports
not-blank metrics and broken images.
dom-equality (check 6) is tightened from "FAIL with small deltas — move on"
to PASS-or-allowlisted-deltas-only. Results of all six checks are recorded
in state.json under healthGate so the pass is auditable.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The skill body no longer calls playwright-cli directly. Browser interactions
are now expressed as host-agnostic intents ("open this URL in a browser",
"evaluate this JavaScript", "take a screenshot") so the executing agent can
use whatever tool fits its environment — playwright-cli, cmux-browser, or
any other available primitive.
JavaScript payloads (what to evaluate and verify) are preserved unchanged;
only the tool invocation scaffolding is removed. HOST-NOTES.md updated to
map browser intents to tools per host and to list specific browser CLI calls
as a forbidden pattern in the skill body.
Also fixes the stale Quick start Phase 1 snippet that incorrectly showed
playwright-cli instead of curl.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Source URL is now the only required input; repo, daRoot, level, slug, and
template name are all resolved automatically. A parameter summary is always
displayed before Phase 0 begins (no confirmation needed — the skill proceeds
immediately after showing it). DA token status is surfaced early and
non-blocking; phases 1-4 do not need it.
Reading order is now just-in-time: only SKILL.md + methodology.md load at
startup; the four heavy knowledge files are deferred to the phases that use
them (Analyze, Generate, Round-trip).
HOST-NOTES.md updated to accurately describe the defaults source-of-truth
(now actually in MANIFEST.json), document the three-layer merge, and add
`gh` (GitHub CLI) to the allowed-primitives list — it was already used in
Phase 5 but missing from the list.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Phase 0 now branches by dry-run outcome: clean installs proceed without a
separate file-list confirmation (the init summary covers it); drift and
custom-code-detected cases still surface details and pause for explicit input.
Phase 1 auto-detects the target repo via `gh repo view` / `git remote` and
reads daRoot from .snowflake/config.json instead of always asking the user.
Slug and templateName derivation is shown in the init summary rather than
triggering mid-phase follow-up questions.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds a `defaults` object to MANIFEST.json with all five repo-level config
keys (projectsDir, daRoot, branchPrefix, trunkBranch, tagPrefix). The
installer now merges these into .snowflake/config.json using a three-layer
merge (defaults → existing config → substrateVersion/installedAt), so
user-edited values survive upgrades and a fresh install always has all keys
present. Bumps substrate to v1.0.6.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* feat(aem-workflow): rewrite workflow-debugging skill for AEM Cloud Service
- Add Audience, Variant Scope, and Dependencies sections
- Correct cq.workflow.job.max.procs myth: property does not exist on
WorkflowSessionFactory; real parallelism knob is queue.maxparallel
on the Granite Workflow Queue (org.apache.sling.event.jobs.QueueConfiguration)
- Fix lock contention guidance: reduce (not raise) queue.maxparallel
- Replace vague stale handling with StaleWorkflowServlet pattern
- Add concrete OSGi config file names and Git-based remediation paths
- Add AEMaaCS platform caveats: DefaultThreadPool may be reserved,
pod-restart requires Support ticket, IMS identity gotchas
- Add Routing back to dev skills table
- Update reference.md with JMX to CS translation table and diagnostic tools
* Feat/skill workflow debugging cs review fixes (#150)
* fix(aem-workflow): address review feedback and correct console URLs in workflow-debugging (Cloud Service)
reference.md
- Remove JMX to Cloud Service translation table; the skill should teach
CS-correct instructions directly rather than reference and translate
incorrect JMX-era content (review feedback)
- Remove Bundled runbooks and Bundled supplementary docs sections; those
references/* paths are not present in this skill folder
- Drop Cloud Service note preamble describing on-the-fly JMX translation
- Expand diagnostic tools table with Sling Thread Pools, Threads,
jstack thread dump, Sling Scheduler, and OSGi Configuration entries
- Replace broken overview-repoinit URL with overview#repoinit anchor
- Switch javadoc link from 6.5 reference to AEMaaCS cloud-service javadoc
- Add RejectedExecutionException and retrys-exceeded log patterns
SKILL.md
- Fix Sling Jobs page path: /system/console/slingjobs returns 404 on
AEMaaCS; the actual page is /system/console/slingevent (page title
is still "Jobs")
- Fix Threads status path: /system/console/status-Threads is case
sensitive; the lowercase variant returns 404
All console paths re-verified against the local AEMaaCS SDK.
* fix(aem-workflow): expert audit pass against live AEM 6.5 LTS for workflow-debugging (#148)
All claims re-validated against an OOTB AEM 6.5 LTS instance, Adobe's
official Workflows Best Practices documentation, and Granite Workflow
source on release/660 and prod/cq660.
SKILL.md
- Step 1: drop the dead 'Runbook' column; the runbook-*.md filenames it
pointed at do not exist in the repo (the 'First action' column already
carries the actionable command for each symptom)
- Step 3a: the default Sling thread pool runs Quartz schedulers; it does
not itself 'fire' com/adobe/granite/workflow/timeout/job — that is a
Sling Job topic dispatched by a JobConsumer. Reword to reflect the
scheduler -> Sling Job hand-off. Drop the bogus 'max pool size >= 20'
healthy threshold: OOTB on AEM 6.5 LTS the default pool is 5/5
(Apache Sling default), with a note that hardened environments
typically bump it to 20+
- Step 3d: the workflow timeout job is a Sling Job topic, not visible on
/system/console/status-slingscheduler. Reword to point at
/system/console/slingevent for the topic itself; only the periodic
WorkflowStatsMBean Quartz job is visible on the scheduler page on
OOTB 6.5 LTS
- Step 5: drop the duplicated queue.maxparallel row that also wrongly
said 'Default 1' (OOTB is 0.5). Correct the DefaultThreadPool max
pool size default from 20 to 5. Add four useful WorkflowSessionFactory
properties verified live and against source: inboxQuerySize,
maxPurgeSaveThreshold, maxPurgeQueryCount, and the OOTB superuser
group list. Add a Purge Scheduler row for the array-typed
scheduledpurge.workflowStatus. Reframe cq.workflow.job.max.procs as
an orphaned metatype label with no Java code path that reads it
(verified against release/660 and prod/cq660 source — the property
exists only in metatype.properties as an i18n UI label) and surface
Adobe's documented recommended range of half-to-three-quarters of
processor cores
- Step 7: complete the Maintenance MBean signatures to match the live
MBean — restartStaleWorkflows(model [optional], dryRun);
retryFailedWorkItems(dryRun, model [optional]);
terminateFailedInstances(restart, dryRun, model [optional]). Add the
three useful per-model ops present on the live MBean but not
documented: listRunningWorkflowsPerModel, listCompletedWorkflowsPerModel,
returnFailedWorkflowCountPerModel
- Step 8 Pattern A: replace 'All 20 threads consumed' with the accurate
OOTB number (5), with the same hardening caveat. Clarify the block-
policy behavior — OOTB is RUN, so the ABORT-driven silent drop only
occurs in environments where the policy has been changed
reference.md
- Drop the 'Runbook locations (relative to repo root)' table; those
aem-agent-marketplace-workflow-knowledge-base/runbooks/* paths are
not bundled with this repo, so the table was a dead pointer
- Drop the 'see also docs/error-patterns.md' hint for the same reason
- Fix the broken /system/console/slingjobs entry (404 on AEM 6.5 LTS;
the canonical Sling Jobs page is /system/console/slingevent)
- Add four diagnostic-tool rows that are referenced from the SKILL.md
but were not in this index: Sling Thread Pools, Threads, jstack
thread dump, Sling Scheduler
* fix(aem-workflow): expert audit pass and LTS parity for workflow-debugging (AEM Cloud Service)
All claims re-validated against the local AEMaaCS SDK on localhost:4517,
Adobe's Workflows Best Practices documentation, and Granite Workflow
source on the master branch. Also brings CS skill coverage in line with
the LTS audit landed in PR #148.
Accuracy fixes
- Step 3a: reword 'default pool fires com/adobe/granite/workflow/timeout/job'
to reflect the actual hand-off — the default pool runs the periodic
timeout-detection scheduler that emits the topic; the topic itself is
consumed by a Sling JobConsumer. Replace the bogus 'max pool size >= 20'
healthy threshold with the actual OOTB AEMaaCS SDK value of 10/10
(production environments may differ)
- Step 3c: correct the Granite Workflow Queue Max Parallel default —
on the AEMaaCS SDK the live OOTB value is queue.maxparallel = 0.5
(not 1 as previously stated). Add Adobe's documented recommended
range of half to three-quarters of processor cores. Name the
/system/console/slingevent URL explicitly (parity with LTS)
- Step 3d: the workflow timeout job is a Sling Job topic, not visible on
/system/console/status-slingscheduler. Reword to point at
/system/console/slingevent for the topic itself; only the periodic
WorkflowStatsMBean Quartz job is visible on the scheduler page
- Step 5: correct the DefaultThreadPool maxPoolSize OOTB from 20 to 10
(verified live on the AEMaaCS SDK; production environments may differ).
Reframe cq.workflow.job.max.procs as an orphaned metatype label with
no Java code path that reads it (verified against AEM source on
master — same orphan exists across release/660, prod/cq660 and master).
Surface Adobe's recommended range of half to three-quarters of
processor cores
- Step 6: same reframing for the increase-parallelism cell. Correct the
verification fallback value from 'usually 1' to '0.5 on the AEMaaCS SDK'.
Fix the Fix auto-advancement row to point at the Sling Jobs page (not
Sling Scheduler) for the timeout job topic
- Step 7 Pattern A: replace 'All 20 threads consumed' with the accurate
OOTB AEMaaCS SDK value (10). Clarify block-policy behavior — OOTB is
RUN, so the ABORT-driven silent drop only occurs in environments where
the policy has been changed
LTS parity (coverage gaps closed)
- Step 1: drop the dead 'Runbook' column; the runbook-*.md filenames
point to files that do not exist in this skill folder (same fix as
LTS PR #148). Rename heading to 'Map symptom to first action'
- Step 5: add three useful WorkflowSessionFactory properties documented
in the LTS skill and verified live on the CS SDK with the same OOTB
values — granite.workflow.inboxQuerySize (2000),
granite.workflow.maxPurgeSaveThreshold (20), and
granite.workflow.maxPurgeQueryCount (1000)
Integrates upstream changes from the snowflake-demos test worktree.
Adds a second conversion level alongside the original page-level
(overlay) path.
SKILL.md:
- Two modes documented: page-level (overlay template + [data-slot]
markers) and block-level (each section becomes an independent
EDS block with its own decorate() + CSS).
- New `level` parameter: auto | check | block | page.
- auto: feasibility runs, recommendation surfaced, user confirms
- check: feasibility scan only, stops before Phase 3 (batch scan)
- block / page: explicit override, analysis runs as validation
- Description updated to mention both modes; trigger terms expanded.
- Version bump 1.0.0 → 1.1.0.
phases/2-analyze.md:
- Adds block-level feasibility assessment (5 checks per section:
structure, CSS scope, content model, JS independence, visual
independence).
- decisions.json gains levelParam, conversionLevel, feasibility
fields with per-section pass/fail tables.
- Level-driven transition rules at the end (auto/check/block/page).
knowledge/block-level-feasibility.md (new):
- 301-line reference: the 5 checks in detail, hybrid option, source
signals (BEM/section-scoped → block; Tailwind/utility-first →
page), worked Frescopa example showing all 9 sections passing.
phases/3-generate.md:
- Adds a "Note on conversionLevel" callout explaining that this
phase currently implements only the page-level path. block-level
and hybrid are documented in SKILL.md and block-level-feasibility.md
but Phase 3 generation for them is a future enhancement. Until
then, fall back to page-level and surface a note to the user
rather than silently producing wrong output.
skills-ref validates clean. No XML tags in description.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tessl review feedback after the trim: actionability stayed at 2/3
because the Quick start showed how to read phase files, not the
actual conversion shape. Replaces it with a single compressed
end-to-end example walking all seven phases with real bash commands
(playwright-cli, curl to admin.da.live, curl to admin.hlx.page, git
push to the snowflake-NNN branch). Also collapses "What this skill
does NOT do" from 8 lines to 1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Addresses Tessl review feedback (Content score 55% → targeting 90%+):
- conciseness 1/3: SKILL.md was 333 lines of host adapter details,
path resolution mechanics, config schemas, and directory conventions
that belong in HOST-NOTES.md. Cut to 156 lines.
- actionability 2/3: entry point had no copy-paste-ready commands.
Added a Quick start section with the Phase 0 substrate-install
invocation and the phase walk-through pattern.
Moves to HOST-NOTES.md (in addition to what was already there):
- "Resolving paths inside this bundle" — per-host SKILL_DIR mapping
Removes from SKILL.md (was duplicative of HOST-NOTES.md or maintainer-
only):
- "How to invoke (host adapters)" section
- "Bundle assets" file tree (now just prose in Quick start)
- "The .snowflake/ directory convention" full section + JSON schema
- "Host-portable constraints (for skill maintainers)" — already in
HOST-NOTES.md
- "Loading knowledge in each phase" — collapsed into a 3-line note
on the seven-phases section
Preserves all 14 markdown links (orphan check stays green).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tessl deterministic validation rejects literal XML tags in the
description field. Reword `<div class="…">` and `<table>` as
"div-class" and "table" — the body of SKILL.md still uses the
literal tags in code-fenced examples, where they belong.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After moving fixtures/ → references/fixtures/, the link to
references/media.md needs to be ../media.md, not ../references/media.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Move snowflake/substrate/* → snowflake/assets/substrate/* and
snowflake/install-substrate.mjs → snowflake/scripts/install-substrate.mjs
so the bundle layout matches Tessl's expected spec dirs
(references/, assets/, scripts/). Updates the installer's path
resolution accordingly (SUBSTRATE_DIR derived via dirname(SCRIPT_DIR)).
- Move da-content/fixtures/* → da-content/references/fixtures/* for
the same reason.
- Add explicit markdown links in snowflake/SKILL.md to phases/*.md,
knowledge/*.md, HOST-NOTES.md, README.md, examples/README.md so
Tessl's orphan check finds them all. da-content/SKILL.md links to
references/fixtures/README.md.
- Rename plugin's .tileignore → .tesslignore (legacy filename
deprecated).
Updates every path mention in SKILL.md, HOST-NOTES.md, README.md,
phases/0-prereq.md to reflect the new layout. Smoke-tested the
installer against a vanilla temp repo — substrate self-locates
correctly.
The remaining "code-review SKILL.md too large" warning is on a
pre-existing skill not touched by this branch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Imports two skills from aemcoder/skills and wires them into the
plugin's release machinery.
- da-content (renamed from source eds-da-content): reference for DA +
EDS content rules — block HTML format, metadata, media handling, DA
Source API contract, IMS auth, and the 11 silent-failure rules.
Trimmed description from 922 → 709 chars and added a Related Skills
section pointing at da-auth, generate-import-html, page-import,
snowflake.
- snowflake: static-to-EDS overlay conversion that preserves the
original DOM byte-for-byte while making text and image content
authorable in DA. Description leads with the DOM-preservation
property and explicitly defers canonical block-rewrite migrations
to page-import. All internal references updated from eds-da-content
to da-content. SKILL_DIR resolution table rewritten for Claude Code
plugin distribution. DA token reads now consume $DA_TOKEN (set by
da-auth) with ~/.aem/da-token.json fallback.
Cross-skill integration:
- da-auth Related Skills now lists snowflake + da-content
- page-import description disambiguates against snowflake; "Do NOT
use" list points to snowflake for DOM-preservation use cases
- tile.json registers both new skills
- README.md adds a snowflake row to Migrating Content and a new
Content & Platform Reference subsection for da-content
- Each new skill ships package.json + .releaserc.json for
semantic-release
Evals:
- da-content-block-html-generation: 10-item weighted checklist on
silent-failure rule compliance when generating block HTML
- snowflake-overlay-vs-page-import-selection: 7-item checklist on
description-driven skill disambiguation given DOM-preservation
vocabulary
skills-ref validates all 94 skills in the repo.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(stardust): fix opening prototyped pages from browser plugin
Use `open <vfs-path>`, not `playwright-cli open`, for prototype
previews.
VFS-backed prototype files must be opened with the `open` shell
command so the preview service worker resolves the path.
`playwright-cli open` bypasses the worker and yields FILE NOT
FOUND. Update prototype and uplift SKILL.md to spell this out.
* chore: remove multiple files detail
Closes three low-risk Tessl skill-review orphan warnings.
- distill/SKILL.md: added a `## References` section listing the two
reference files (samples-brief-format.md, trait-matrix-schema.md).
distill was the only skill without a References section.
- prototype/SKILL.md References: added the four cinematic motion docs
(motion-registers.md, motion-stack.md, motion-attributes.md,
motion-runtime.md) alongside motion-validation.md.
- prototype/SKILL.md References: switched 7 cross-skill paths from
`skills/stardust/reference/X.md` (absolute-style, unresolvable by
Tessl) to `../stardust/reference/X.md` (the convention already
used by stardust/SKILL.md and uplift/SKILL.md).
No behavior changes — additive + path-correctness fixes.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Stacks three minor versions on the `redesign-adobecom` branch.
## 0.8.0 — Original `redesign-adobecom` changes
- NEW skill: `distill` — analyze HTML mockups + website URLs and produce a structured style guide; anchors `direct` under Mode B.
- Motion validation gate (Phase 2.8 on `prototype`) — clipped-container reveal timing, animation-range vs reading position, anim-enter trigger reachability, reduced-motion override completeness, no-JS fallback, multi-viewport scroll-driven checks.
- Surface forks formalized as parent-direction tuning under reimagined mode.
- Journal rule + recursive validate-and-fix loop promoted to master skill.
- HTTP/2 / Akamai bypass: route-fulfiller pattern in playwright-recipe.
## 0.9.0 — Cinematic motion feature
- `prototype --cinematic` (and `--cinematic=<register>`) — layers a brand-faithful motion register on the static prototype. Output is `<slug>-cinematic.html` alongside the static `<slug>-proposed.html`.
- Five motion registers as a closed catalog (`arrival`, `kinetic-display`, `live-systems`, `editorial`, `kinetic-grid`).
- Lenis bundled at `skills/prototype/assets/motion/` (MIT, ~17 KB). No GSAP / Framer / Theatre.js.
- Motion `data-*` vocabulary: `[data-anim]`, `[data-tile-anim]`, `[data-countup]`, `[data-flip]`, `[data-fill]`, `[data-split]`, `[data-parallax]`.
- Canonical inline runtime at `prototype/reference/motion-runtime.md`.
- Six cinematic-mode validation gates (Pass 6): Lenis bootstrap, reduced-motion fallback, scroll-jack check, three-position screenshot pass, register-match audit, motion C-cliff detector.
- `direct` writes `extensions.motion.register` from PRODUCT.md Brand Personality. For multi-variant runs the register lives in per-variant `DESIGN-<id>.json`.
## 0.10.0 — `/stardust:uplift <URL>` one-shot presales orchestrator
- NEW skill: `uplift` — produces three differentiated variants (A faithful + improvements, B "what if we amplified `<captured trait>`?", C "what if motion was part of the identity?" — fully cinematic) without further user coordination.
- Closed catalog of 8 "what if…" captured-trait amplification candidates with disqualification clauses.
- Load-bearing artifacts: `uplift-improvements.md` (5 specific weaknesses) and `uplift-questions.md` (catalog walk + picks + disqualifications).
- Delegates to extract → direct → prototype with no new flags on the underlying skills.
## Plugin metadata
- `tile.json` bumped 0.8.0 → 0.10.0; registers `uplift` + `prepare-migration` (the latter a pre-existing gap closed).
- `.claude-plugin/plugin.json` bumped 0.9.0 → 0.10.0.
## Backward compatibility
All existing sub-commands unchanged. Motion is opt-in via `--cinematic`. `uplift` is a new entry point with no parallel render path — it delegates to existing skills. Existing project trees gain new artifacts only when the new flags / skills are engaged.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
PR #139 wrapped commit-analyzer with path filtering but tried to fix
release-notes-generator with gitRawCommitsOpts: { path: '.' } -- a
no-op because the plugin reads context.commits from semantic-release,
never gitRawCommitsOpts. Result: every skill release body and CHANGELOG
included commits from the entire repo (see slicc-handoff-v1.0.0).
- Add scripts/path-filtered-notes-generator.cjs mirroring the analyzer
wrapper -- filters context.commits via git log -- . before delegating
to the real plugin.
- Wire it into release.config.cjs in place of the bare plugin entry;
drop the dead gitRawCommitsOpts config.
- Regenerate plugins/aem/edge-delivery-services/skills/slicc-handoff/
CHANGELOG.md (skipped by PR #140 because the tag did not exist yet).
Per review feedback: defer SLICC protocol detail to the maintainer-curated
https://www.sliccy.ai/llms.txt index rather than restating it in the
skill. Adds a pointer near the top of SKILL.md and trims "How It Works"
to a one-paragraph summary that links to llms.txt for the full rel URIs,
payload shape, and public API catalog. Activation guidance, verb-prefix
rules, and example commands are kept inline so the skill stays useful
without a network fetch.
Co-authored-by: Cursor <cursoragent@cursor.com>
Per review feedback: let semantic-release manage the changelog content.
Reverts the descriptive notes added in 6c75163.
Co-authored-by: Cursor <cursoragent@cursor.com>
Replaces the placeholder with an Initial Version entry that explains what
the skill is for, what's included (SKILL.md, the Node helper, package and
release config), the handoff/upskill verb prefixes, the SLICC_PORT env
var, and security notes about treating the instruction string as
untrusted input. Future semantic-release entries will be prepended above
this section.
Co-authored-by: Cursor <cursoragent@cursor.com>
Adds a new skill that lets an external coding agent hand off the current
task to the SLICC browser agent, or trigger installation of a skill into
SLICC from a GitHub repo. The skill ships a small Node helper that posts
to a local SLICC node-server on localhost and (optionally) opens the
sliccy.ai handoff URL so the SLICC extension can pick it up via its
RFC 8288 Link header observer. Either path results in a yes/no approval
card in the SLICC cone keyed by verb prefix (handoff: / upskill:).
Registers the skill in plugins/aem/edge-delivery-services/tile.json.
Co-authored-by: Cursor <cursoragent@cursor.com>
Hey @trieloff 👋
I ran your skills through `tessl skill review` at work and found some targeted improvements for the Cloud Service replication skill. Here's the before/after:
| Skill | Before | After | Change |
|-------|--------|-------|--------|
| replication (cloud-service) | 52% | 87% | +35% |
I picked this skill because it had the most room to grow across the repo — the baseline was 52%, lowest alongside `replication-orchestrator` (6.5 LTS). Since Cloud Service is the forward-looking runtime, it felt like the highest-signal place to contribute.
<details>
<summary>Changes made</summary>
**Description improvements (biggest impact — 40% → 100%):**
- Rewrote frontmatter description from a generic 2-line summary to a specific, action-oriented description listing concrete capabilities (publish, deactivate, delete, bulk activation, preview-tier targeting, sync/async, status checks, permissions, workflow steps, event handling)
- Added explicit "Use when..." clause with seven trigger scenarios covering natural language terms users would say ("publish pages", "activate content", "check replication status")
- Switched description from YAML block scalar to quoted string format
- Added metadata.category field
**Content improvements (42% → 73%):**
- Removed "Architecture: How Replication Works in Cloud Service" section — Claude already understands AEM's Sling Content Distribution pipeline
- Removed ReplicationActionType values table — these are self-evident from the linked Javadoc and the code examples
- Moved Common Patterns (auto-publish on Content Fragment save, external cache purge after publication) to references/patterns.md for progressive disclosure, reducing the main SKILL.md by ~100 lines
- Added a Service User setup pattern to the reference file for completeness
- Condensed Best Practices section — removed verbose exception handling example, consolidated service user guidance into a concise paragraph with a link to the reference file
- Net result: SKILL.md dropped from 744 to 592 lines with better structure
**Unchanged skills:**
- All other 88 skills left untouched — many are already scoring well (replicate-content at 100%, workflow-development at 99%, best-practices at 94%)
</details>
I also stress-tested your replication skill against a few real-world task evals and it held up really well on bulk content activation with automatic transactional bucketing above the 100-path threshold. Kudos for that.
Honest disclosure — I work at @tesslio where we build tooling around skills like these. Not a pitch — just saw room for improvement and wanted to contribute.
Want to self-improve your skills? Just point your agent (Claude Code, Codex, etc.) at this Tessl guide (https://docs.tessl.io/evaluate/optimize-a-skill-using-best-practices) and ask it to optimize your skill. Ping me — @yogesh-tessl (https://github.com/yogesh-tessl) — if you hit any snags.
Thanks in advance 🙏
Co-authored-by: Yogesh Rao <yogesh-tessl@users.noreply.github.com>
* fix(aem-workflow): correct cq.workflow.job.max.procs parallelism myth in workflow-debugging (AEM 6.5 LTS)
The skill instructed customers to increase cq.workflow.job.max.procs
for workflow throughput. While that property is shown in Felix Console
(its display name and description are defined in the WorkflowSession
Factory metatype), it has no effect at runtime — no code path reads
the value. Real workflow parallelism is controlled by queue.maxparallel
on the "Granite Workflow Queue" (an Apache Sling Job Queue
Configuration instance). The skill's own thread-pool section at
SKILL.md:105 already mentions Max Parallel correctly; the four
cq.workflow.job.max.procs references contradicted that and were
misleading customers.
- SKILL.md: 4 references to cq.workflow.job.max.procs replaced with
queue.maxparallel on the Granite Workflow Queue
- reference.md: parallelism row updated to point to the correct OSGi
config (Apache Sling Job Queue Configuration)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(aem-workflow): correct JMX MBean ObjectName for retry/queue-info ops in workflow-debugging (AEM 6.5 LTS)
The skill cited com.adobe.granite.workflow:type=Repository as the
MBean hosting retryFailedWorkItems, returnSystemJobInfo, and
returnWorkflowQueueInfo. That ObjectName does not exist on AEM 6.5 LTS
— a JMX lookup returns 404. All three operations actually live on
com.adobe.granite.workflow:type=Maintenance, the same MBean the skill
already used correctly for purgeCompleted/countStaleWorkflows/
restartStaleWorkflows. The real second workflow MBean is
:type=Statistics, which exposes time-series execution metrics.
Updates Step 7 (Key JMX MBeans) to:
- Consolidate every workflow maintenance operation under the
Maintenance MBean (matches what AEM actually exposes via JMX)
- Add Statistics MBean as a separate row with its read/write
accessors for DataLifeTime / DataFidelityTime / DataProcessRate /
DataRate plus getResults / clearRecords
- Add operation parameter signatures (model, days, dryRun) where
applicable
Verified on AEM 6.5 LTS localhost:4505:
- :type=Maintenance → HTTP 200
- :type=Statistics → HTTP 200
- :type=Repository → HTTP 404 (does not exist)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(aem-workflow): replace stale Config Status ZIP file refs with live Felix Console URLs in workflow-debugging (AEM 6.5 LTS)
The skill instructed customers to "check in 039_Sling_Thread_Pools.txt"
and similar numbered files from the Configuration Status ZIP for
thread pools, threads, Sling Jobs, and Sling Scheduler data. The
Config Status ZIP produced by AEM 6.5 LTS (/system/console/
status-Configurations.zip) does not contain those numbered files —
only 000_Configurations.txt and index.json. A customer following the
skill would search for files that do not exist on their AEM.
Updates all 9 references to point to the live Felix Console pages
that are the actual sources of this data:
- 039_Sling_Thread_Pools.txt -> /system/console/status-slingthreadpools
- 042_Threads.txt -> /system/console/status-Threads
- 043_Threads__via_JStack_.txt -> /system/console/status-jstack-threaddump
- 027_Sling_Jobs.txt -> /system/console/slingevent
- 034_Sling_Scheduler.txt -> /system/console/status-slingscheduler
- 003_Configurations.txt -> /system/console/configMgr
Each URL verified to return HTTP 200 on AEM 6.5 LTS localhost:4505.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(aem-workflow): correct Granite Workflow Queue Max Parallel default value in workflow-debugging (AEM 6.5 LTS)
The skill stated that the Granite Workflow Queue ships with
queue.maxparallel = 1. The actual OOTB value on AEM 6.5 LTS is 0.5,
which the Sling Job Queue interprets as "50% of available CPU cores"
(fractional values in 0..1 are CPU-relative; integers >= 1 are
absolute worker counts). A customer following the previous skill
would plan throughput tuning against the wrong starting point.
Updated in two places:
- Step 3c Granite Workflow Queue config bullet list
- Step 5 Configuration checklist table row
Both now cite the OOTB 0.5 value with a pointer to verify the running
value via the OSGi config endpoint at
/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration~workflow.
Verified on AEM 6.5 LTS localhost:4505: queue.maxparallel = 0.5.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
All existing CHANGELOG.md files contained commits from the entire repo
since the skill's last tag, making release notes meaningless. This
regenerates each one from scratch using git log filtered to the skill's
own directory, following up on #139 which fixed the root cause for
future releases.
Empty release sections (e.g. 1.0.0) indicate versions bumped solely by
docs/refactor commits, which is correct — the angular preset omits those
types from the CHANGELOG body.
Also adds scripts/regenerate-changelogs.cjs in case a manual re-run is
ever needed.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
david catalan