Commit Graph

6 Commits

Author SHA1 Message Date
Abhishek Garg 42bc5b0120 feat(aem-6.5-lts): add Java 21 migration skill
Add a new skill for migrating AEM 6.5 LTS Maven projects from
Java 8/11 to Java 21. The skill uses OpenRewrite recipes for
automated code transformation, Python POM manipulation scripts
for changes OpenRewrite cannot handle, and agent-assisted build
fixing with strict guardrails.

12-step migration workflow covering: project validation, Java
version detection, initial build, OpenRewrite Java migration,
POM manipulations, CloudManager config, pre-Mockito build,
Mockito migration, final build, jakarta/workaround cleanup,
migration reporting, and diff review with local commit.

Includes:
- OpenRewrite recipes for Java 8/11→21 and Mockito 1.x→5.x
- Python scripts for compiler config, SCR removal, classifier
  migration, and FileVault groupId fixes
- JSON configs for plugin, dependency, and classifier rules
- Maven settings.xml and toolchains.xml for multi-JDK builds
- Reference docs: prerequisites, build-fix constraints,
  OpenRewrite commands, POM manipulation rules, validation report
- tile.json for 6.5-lts plugin (enables tessl evals)

Guardrails: javax-not-jakarta enforcement, 8 unsupported package
hard stops, enforcer version monotonicity, POM indentation
preservation, temp workaround cleanup, change attribution.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-05-28 13:53:01 +05:30
Akanksha Jain f51cac86af fix(aem-workflow): correct workflow-debugging skill in workflow-debugging (#138)
* 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>
2026-05-21 14:55:50 +05:30
Akanksha Jain 3e71c25e36 Feat/skill workflow launchers 65 lts (#135)
* fix(aem-workflow): update workflow-launchers content for AEM 6.5 LTS

Updates the workflow-launchers skill for AEM 6.5 LTS with validated
content covering launcher configuration, condition patterns, and
JCR-event-driven workflow triggering. SKILL.md now references the
canonical foundation refs hosted under workflow-orchestrator instead
of local duplicates.

- SKILL.md: expanded launcher configuration guidance; loop-prevention
  guardrail clarified (WorkflowSession vs JCR Session disambiguation);
  IDE-LLM consumability improvements; foundation ref links re-pointed
  to workflow-orchestrator canonical copies
- condition-patterns.md: ECMAScript (Rhino) terminology corrected;
  pattern coverage tightened
- launcher-config-reference.md: cq:WorkflowLauncher property
  reference expanded; consumability improvements

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore(aem-workflow): remove duplicated foundation refs from workflow-launchers (AEM 6.5 LTS)

The 6 foundation reference files under workflow-launchers/references/
workflow-foundation/ duplicated the canonical copies hosted in
workflow-orchestrator/references/workflow-foundation/. SKILL.md links
were re-pointed to the canonical copies in the previous commit, so
the local duplicates are now orphaned.

Deletes:
- 65-lts-guardrails.md
- README.md
- api-reference.md
- architecture-overview.md
- jcr-paths-reference.md
- quick-start-guide.md

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(aem-workflow): correct loop-prevention setUserData value in workflow-launchers (AEM 6.5 LTS)

The skill instructed setUserData("workflowmanager") for loop prevention.
AEM's WorkflowLauncherListener does not recognize that string. The
correct value is "changedByWorkflowProcess", which matches
HandlerBase.WORKFLOW_SESSION_USERDATA in
com.adobe.granite.workflow.core and is the default member of the OSGi
config property granite.workflow.launcher.globally.exluded.event.user.data
that the launcher reads at startup.

- SKILL.md: setUserData("workflowmanager") -> "changedByWorkflowProcess"
  in the loop-prevention guardrail (2 occurrences in same line)
- condition-patterns.md: setUserData("workflowmanager") ->
  "changedByWorkflowProcess" in the Java snippet; rewrote the comment
  to correctly distinguish the OSGi config-property name from the
  userData value

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(aem-workflow): correct OOTB launcher names, excludeList format, and condition shorthand in workflow-launchers (AEM 6.5 LTS)

Audit findings verified against AEM 6.5 LTS localhost:4505 OOTB
launchers under /libs/settings/workflow/launcher/config/:

- SKILL.md "Common OOTB Launchers" table: dam_update_asset_create
  does not exist (actual: update_asset_create); dam_update_asset_modify
  does not exist (actual: update_asset_mod); dam_xmp_writeback trigger
  description corrected to PROPERTY_CHANGED (eventType=16) on
  nt:unstructured at /jcr:content/metadata; update_page_version_*
  removed (not present in /libs, /conf, or /apps on a baseline 6.5 LTS
  install). Table expanded with eventType, nodetype, glob, and
  workflow columns
- SKILL.md and launcher-config-reference.md: excludeList type
  corrected from String[] to String (single comma-separated value);
  description expanded to document the two entry formats — bare JCR
  property names and the event-user-data:<value> prefix that excludes
  events tagged with a specific JCR observation userData
- launcher-config-reference.md: document the singular `condition`
  shorthand alongside the plural `conditions` array; both forms are
  accepted at startup
- condition-patterns.md: loop-prevention comment rewritten to explain
  the changedByWorkflowProcess value via the customer-visible OSGi
  config property granite.workflow.launcher.globally.exluded.event.
  user.data (visible in Felix Console)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-19 11:26:38 +05:30
Akanksha Jain 15563e127a Feat/skill workflow model design 65 lts (#122)
* fix(aem-workflow): correct workflow-model-design XML format for /conf design-time (AEM 6.5 LTS)

The workflow-model-design skill incorrectly showed cq:WorkflowModel /
cq:WorkflowNode / cq:WorkflowTransition (runtime /var format) under the
/conf design-time path. The Workflow Model Editor expects cq:Page +
jcr:content/flow/<step-component> with nt:unstructured step nodes and
sling:resourceType identifiers. A developer following the previous
content would deploy a model the editor cannot open and Sync cannot
process.

Verified against AEM 6.5 LTS localhost:4505 OOTB models at
/libs/settings/workflow/models/ and source at
WorkflowSessionFactory.java:94 (MODELS_RUNTIME_LOCATION = "/var/workflow/models").

- model-xml-reference.md: full rewrite to cq:Page + flow/parsys
  format; design-time vs runtime table; cq:template fix to
  /libs/cq/workflow/templates/model; rewritten pitfalls section;
  runtime /var shape documented for reference
- step-types-catalog.md: every step snippet converted to
  nt:unstructured + sling:resourceType; sling:resourceType reference
  table added; initiatorparticipant documented; transition XML
  removed (Sync derives transitions from step order)
- model-design-patterns.md: Pattern 5 Task Manager XML corrected to
  flow-layer format; Pattern 6 variables annotated as runtime-only
- SKILL.md: Sync verification added to checklist; /conf vs /var
  distinction note; filter.xml guidance updated

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(aem-workflow): correct AND_SPLIT/AND_JOIN/END resourceTypes in workflow-model-design (AEM 6.5 LTS)

The step-types-catalog incorrectly listed sling:resourceType values for
AND_SPLIT, AND_JOIN, and END that do not exist as design-time
components on AEM 6.5 LTS. Verified against
/libs/cq/workflow/components/model/ on localhost:4505.

- sling:resourceType table: AND_split -> and (the actual OOTB
  component is named and, not AND_split); AND_join and end rows
  removed (no such components exist)
- AND_SPLIT example: corrected sling:resourceType to
  cq/workflow/components/model/and; AND_JOIN inline example removed
- AND_JOIN section: replaced manual <synchronize> example with a note
  that AEM Sync derives AND_JOIN nodes automatically at /var
- END Node section: replaced manual <workflowend> example with a note
  that Sync derives both START and END automatically

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-12 10:44:47 +02:00
Abhishek Garg 962fd1dbee fix(replicate-content): condense SKILL.md to pass tessl-review (#119)
* fix(replicate-content): condense SKILL.md to pass tessl-review (#117)

Rewrites replicate-content/SKILL.md from 840 lines to ~150 lines and
adds three reference files so the skill passes the 50% tessl-review
threshold.

Changes:
- Description: add explicit "Use when..." clause and trigger terms
  (publish, unpublish, replicate, content activation, dispatcher flush,
  AEM publish instance) to improve specificity and completeness scores
- Body: condense all seven replication methods to 3-5 lines each with
  explicit ✓ Verify checkpoints; remove generic Best Practices,
  Security Considerations, and Success Criteria sections
- Split detailed walkthroughs into references/ bundle files:
  - references/TREE_ACTIVATION.md (dry-run steps, performance guidance)
  - references/PACKAGE_REPLICATION.md (full package build/replicate flow)
  - references/REPLICATION_API.md (Java API, ReplicationOptions,
    curl with error handling, service user setup)

Fixes #117

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix(replicate-content): address quality review findings

- CRITICAL: replace invalid XML service-user mapping with correct OSGi
  JSON config format (.cfg.json) in REPLICATION_API.md
- HIGH: add REVERSE to ReplicationActionType table (was missing)
- HIGH: add replication-api to Related Skills in SKILL.md
- MEDIUM: add Only Activated option to Tree Activation summary to match
  TREE_ACTIVATION.md reference file
- MEDIUM: fix head -n1 → sed '$d' in production curl script to handle
  multiline JSON responses without truncation
- MEDIUM: add brief Asset Replication (DAM) section to SKILL.md
- LOW: add Additional Resources section with official Adobe docs links

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Abhishek Garg <abhigarg+adobe@adobe.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-11 10:20:39 +02:00
solimant fcba900bc5 refactor: rename the skills directory to plugins 2026-04-16 18:12:10 +00:00