---
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.
```