Tilfoej al-complexity agent til templates

custom/setup/templates/al-complexity.agent.md

@@ -0,0 +1,89 @@
+---
+kind: action-skill
+id: curabis-al-complexity
+version: 1
+title: CURABIS AL complexity triage
+description: Advisory intake classifier. Assesses an implementation task and proposes a complexity tier (LOW/MEDIUM/HIGH) plus a route. Recommends only - it never starts work and never routes by itself. The developer confirms or adjusts the tier first.
+inputs: [task-description]
+outputs: [tier-recommendation]
+bc-version: [all]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+domain: orchestration
+keywords: [complexity, tier, routing, intake, scope, spec, tdd, architecture, advisory, human-in-the-loop]
+sub-skills:
+  - microsoft/skills/review/al-code-review.md
+---
+
+# CURABIS AL complexity triage
+
+Advisory intake. Run this at the **start of an implementation task** to size it before any
+code is written. It proposes a complexity tier and the matching route, **then stops and
+waits** for the developer to confirm or adjust. It is a recommendation, not a decision:
+it never starts implementation and never routes on its own.
+
+This is a **rubric, not a calculation** - there is no numeric score. The tier comes from
+which classification signals below match the task.
+
+Loop: classify -> propose tier + route -> WAIT for human confirmation -> hand off.
+
+## Classification signals
+
+Escalate to the higher tier if any signal for it applies. When in doubt between two tiers,
+propose the higher one (CURABIS-COMPLEXITY-004).
+
+LOW
+- Touches a single object, presentation-only.
+- A caption, a translation/XLIFF string, a simple field on a page.
+- No new business logic, no data writes beyond Setup pages.
+
+MEDIUM
+- New or changed business logic in a codeunit (validation, calculation, business rule).
+- Touches roughly 2-3 objects, no external dependency.
+- No schema change that needs an upgrade codeunit.
+
+HIGH
+- Touches a core or shared module that many other objects depend on.
+- New external integration or new dependency.
+- New table, or a field change on an existing table that needs an upgrade codeunit / data migration.
+- Multi-module change, or a change to permissions.
+
+## Routes (every tier keeps a review - control is preserved)
+
+LOW
+- Implement -> **light review via bcquality.agent.md**. No spec or architecture phase, but
+  the review still runs. LOW never means "no review".
+
+MEDIUM
+- Short spec -> TDD (tests FIRST, then code) -> bcquality.agent.md review.
+
+HIGH
+- Architecture clarify first (CURABIS-ARCH-010) -> spec -> TDD -> bcquality.agent.md review,
+  with al-triage.agent.md on standby. Flag for explicit human architecture sign-off before
+  implementation starts.
+
+## Action - advisory protocol
+
+CURABIS-COMPLEXITY-001 Classify, do not execute. Output a proposed tier and the route. Do
+  not start implementation, do not write code.
+CURABIS-COMPLEXITY-002 Always wait. Present the tier and route, then stop for explicit human
+  confirmation. Never auto-route, never proceed unprompted.
+CURABIS-COMPLEXITY-003 Justify with signals. State exactly which classification signals
+  matched (objects touched, shared module, external dependency, schema change). No hand-waving.
+CURABIS-COMPLEXITY-004 Conservative bias. When uncertain between two tiers, propose the
+  higher one and say why. Under-scoping is riskier than over-scoping.
+CURABIS-COMPLEXITY-005 Every tier gets a review. No tier skips bcquality.agent.md. LOW gets
+  a light review, not none.
+CURABIS-COMPLEXITY-006 Re-classify on scope change. If the task grows during work, stop and
+  re-propose a tier rather than silently continuing on the old one.
+
+## Output format
+
+```
+PROPOSED TIER  LOW | MEDIUM | HIGH
+SIGNALS        <which classification signals matched, and why>
+ROUTE          <the recommended path for this tier>
+GATES          <where human approval is required before proceeding>
+AWAITING       Confirm the tier or adjust it before I proceed.
+```