feat(code-assessment): add AEM as a Cloud Service code-quality skill

[mandeep294]

What

Adds code-assessment — a self-contained, local-only AEM as a Cloud Service code-quality skill. It detects and fixes code-quality issues entirely against the workspace. Name the files to fix, or ask it to scan the repo; it plans, applies surgical edits (git branch or in-place), and verifies with mvn compile.

Detection for the production-ready patterns is performed by a deterministic local analyzer rather than an LLM scan — the same finding can no longer drift run-to-run.

Fixing recipe is provided by Expert skills.

Structure

• SKILL.md — control plane: routing, classification, scope & limitations.
• references/runbook.md — the shared run procedure (preflight → resolve/discover → plan → confirm → apply → verify); git vs in-place edit modes; report-vs-apply intent; structured run log.
• references/ — git-workflow.md (branch lifecycle + run-log schema), shared-principles.md (design rationale), troubleshooting.md, patterns.md (the pattern catalog), _template.md (authoring standard).
• scripts/ — the deterministic analyzer:
  • analyze.sh — compile-cache + run wrapper. Requires a JDK (javac/java); compiles the analyzer once into a temp cache keyed by source hash and writes nothing to the project tree.
  • analyzer/ — a parse-once Corpus (PomUnit / JavaUnit) fed to a multi-detector Registry. Each detector emits a stable Finding ({pattern, file, line, snippet}). Detection is parse-level only: no network lookups, no classpath or symbol resolution.
  • test/ — 14 fixtures driven by a 51-case harness (run-tests.sh).
  • adding-a-pattern.md — how to add a detector + keep the wiring invariant.
• Expert skills (one self-contained subdirectory per pattern):
  • inject-in-sling-model — migrate @Inject in @Model classes to injector-specific annotations (@ValueMapValue / @OSGiService / @SlingObject), with per-field optional handling. Detection: analyzer.
  • outdated-dependencies — bump stale Maven versions (user-supplied targets); literal <version> and same-pom ${property} shapes. Detection: analyzer, scoped by default to a curated allowlist of actionable AEM CS coordinates (aem-sdk-api, org.mockito:*); --all for an explicit full audit.
• patterns.md catalogs 9 further high-value patterns as planned (LLM scan detection until a detector is built), drawn from CSO outage analysis and ordered by remediation value.

Design

• Detection and remediation are separable through the stable Finding shape — a pattern's detection method can be upgraded (LLM scan → deterministic analyzer) without touching its recipe. Both ready patterns have made that transition.
• Warn, don't gate: a dirty tree or failing baseline compile is surfaced, not blocked.
• Surgical edits only; one pattern per apply session; the skill never commits, pushes, or opens a PR — the developer reviews the diff.

Validation

• bash scripts/test/run-tests.sh → 51/51 pass.
• npm run validate passes for all skills.
• Manual smoke against real AEM projects recommended before broad adoption.

🤖 Generated with Claude Code

[rombert]

Thanks for the PR @mandeep294 . I think this generally goes in the right direction:

• single entry point for code assessment
• 'pluggable' recipes/patterns to fix

What I am still debating in my head is what to do with wide-reaching topics that already have (or are going to have) their own specialised skill, like workflow. We will want to run code assessments for these domains as well.

I am sort of leaning towards saying that we need a contract to be implemented for sub-skills, e.g.

aem-workflow/                        
    workflow-debugging/
    workflow-assessment/ [new]

where the aem-workflow would implement the contract (similar to each recipe in your PR) and the code-assessment workflow would reach out to the sub-skill of aem-workflow.

What is your take on that?

Can you also share some prompts that you used for testing? I am curious if you tried prompts that should hit individual recipes, e.g. Check that my Sling Models are implemented correcty. I am not sure if sub-skills are registered automatically and the prompt in the router skill (code-assessment) can't be relied on to expose all recipes.

As a low-level nitpick, there are several occurences of 'customer' which I think is not the ideal term for the coding agent to understand. Perhaps 'developer'?