feat(aem-workflow): improve cloud-service workflow-triaging skill - #197
Conversation
Refine AEM Cloud Service workflow triaging skill with clearer AEMaaCS-specific guidance: audience scoping, no-JMX constraint, Developer Console equivalents, new symptom rows (auto-advance failure, transient retry exhaustion, thread pool full), lock-contention remediation note, Splunk query fixes, and updated references to workflow-debugging and cloud-service-guardrails.
Tessl Skill Lint
|
|
|
||
| ## Audience | ||
|
|
||
| AEMaaCS support and operations engineers (and the IDE LLM acting on their behalf) classifying workflow incidents across environments — environment ID + time-range + Cloud Manager Logs / Splunk context, before drilling into one instance. Use this skill for cross-environment log mining and symptom classification; switch to `workflow-debugging` once the instance and root cause are identified. |
There was a problem hiding this comment.
Is this skill supposed to be Adobe-internal? This audience statement seems to indicate that.
For this repository we aim to have customer-facing skills of general applicability. This skill should be usable to (developer) users of AEM as a Cloud Service as long as it's public.
Additionally, I find the instructions to deploy a custom StaleWorkflowServlet problematic as there is absolutely no guidance on how to securely write and deploy it.
There was a problem hiding this comment.
1. Audience / customer-facing scope
The original wording ("support and operations engineers … Splunk context")
did read as Adobe-internal. Reworded the audience to target AEMaaCS customer
developers and operators, and reframed the log source so Cloud Manager Logs is
the primary path — Splunk is now presented as an optional customer-side setup
("a log aggregator such as Splunk, if you forward AEMaaCS logs there") rather
than an assumed internal tool. Everything the skill relies on (Cloud Manager
Logs, Developer Console, Git + pipeline) is available to any AEMaaCS customer.
2. StaleWorkflowServlet security guidance
checklist to workflow-debugging Step 6
(author-only path, in-code group with 403, dedicated service user — never
loginAdministrative(), dry-run default, model scoping + audit), and referenced it
from every StaleWorkflowServlet deploy instruction so none appears without it.
…skills - workflow-triaging: reword audience to customer-facing AEMaaCS developers and operators; present Splunk as optional customer-side log aggregation with Cloud Manager Logs as the primary source - workflow-debugging: add secure-write/deploy checklist for custom support servlets in Step 6 and reference it from every StaleWorkflowServlet deploy instruction (Step 1, Step 2 decision tree, Step 6 table, Pattern C)
|
🎉 This PR is included in version 1.0.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 1.2.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 1.2.2 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This branch was previously deployed
2 participants
Refine AEM Cloud Service workflow triaging skill with clearer AEMaaCS-specific guidance: audience scoping, no-JMX constraint, Developer Console equivalents, new symptom rows (auto-advance failure, transient retry exhaustion, thread pool full), lock-contention remediation note, Splunk query fixes, and updated references to workflow-debugging and cloud-service-guardrails.
Description
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: