--- name: demand-triage description: Use immediately after codebase discovery to classify task scale and determine which workflow steps are required vs. optional. depends_on: - repo-exploration # codebase evidence is required before classification commonly_followed_by: - feature-planning # Medium/Large tasks require a plan - application-implementation # Small tasks may go directly to implementation - memory-and-state # DECISIONS.md check always follows triage --- # Demand Triage Use this skill to classify a task's scale and adapt the workflow intensity accordingly. This prevents over-processing small tasks while maintaining full rigor for complex work. ## When to run triage Run triage **after** codebase discovery (the `repo-exploration` skill) but **before** planning or implementation. Triage requires evidence from reading the codebase — do not classify based on the request text alone. ## Classification criteria After reading the relevant files, classify the task using observable criteria: ### Small All of the following must be true: - Affects **a single file** (or a single file plus its direct test file) - No contract changes (API request/response shapes, event schemas, public interfaces) - No schema or migration changes - No cross-module import changes (does not add or remove dependencies between modules) - No auth, permission, or security logic changes - No breaking changes to existing consumers - The change is **well-understood** — you can describe exactly what to do before starting Examples: typo fix, copy/label change, simple validation rule, single-function bug fix, adding a log line, updating a config value. ### Medium Any of the following: - Affects **2–5 files** within the same module - Requires minor design adjustment but no architectural change - Adds a new function or small feature within an existing pattern - No breaking changes, no schema migration, no auth changes Examples: adding a new API field with validation, refactoring a function and updating callers, adding a new UI component following existing patterns. ### Large Any of the following: - Affects **multiple modules** or crosses module boundaries - Requires architectural change or new patterns - Involves schema migration, contract breaking changes, or permission model changes - Touches auth, security, payment, or audit logic - Requires coordination between multiple agent roles Examples: new feature spanning API + service + UI, database migration, permission system change, new integration with external service. ## Uncertainty rule If classification is uncertain, **default to Medium**. Never default to Small when unsure — the cost of under-processing a Medium task is higher than the cost of slightly over-processing a Small one. ## Hard blockers (force non-Small) The following characteristics **always** force Medium or Large, regardless of file count: - Auth or permission logic changes → Medium minimum - Security-sensitive code changes → Medium minimum - Schema or migration changes → Large - Contract or API breaking changes → Large - Cross-service or cross-deployment changes → Large ## Output format After classification, state: ```text [SCALE: SMALL | MEDIUM | LARGE] Reason: [1–2 sentences explaining why, based on evidence from codebase discovery] Files affected: [list] ``` ## Workflow adaptation by scale Workflow adaptation depends on both task scale and the active trust level (see `docs/operating-rules.md` → Trust level). The rules below describe what can be simplified at each scale. Trust level further relaxes or tightens the ceremony. ### Small tasks — conditional simplifications When a task is classified as Small, the following workflow steps are **skippable** (may be skipped unless the task specifically requires them): - **Full planning agent** — replace with a 1–2 sentence inline plan stating what will change and why - **Critic review** — skip unless the change touches a pattern used across the codebase - **Risk-reviewer** — skip unless the change is in a sensitive area (even if file count is small) - **Context anchor** — skip (single-step tasks do not need drift prevention) - **Compliance block** — required at `supervised` trust level; optional at `semi-auto` and `autonomous` - **Deliverable structure** — required at `supervised`; at `semi-auto`/`autonomous`, a brief summary of what changed is sufficient The following steps **remain mandatory at all trust levels** even for Small tasks: - **Codebase discovery** — at minimum, read the file being changed and its direct dependents - **DECISIONS.md check** — verify no contradiction with existing decisions - **Validation loop** — run at least the targeted tests for the changed file (runs autonomously; no human approval needed between iterations) - **Error recovery** — follow the standard protocol if tests fail - **Security check** — do not skip even for trivial-looking changes in sensitive areas Small path means explicit simplification, not implicit skipping. At `supervised` trust level, if required fields are omitted the task is non-conformant even if the code change itself is correct. ### Medium and Large tasks At **`minimal` profile**: output `[SCALE: MEDIUM]` or `[SCALE: LARGE]` and escalate to the user. Recommend switching to `standard` or `full` profile. Do not attempt the workflow at minimal. For **`standard` and `full` profiles**: follow `docs/agent-playbook.md` → Workflow chains for the full procedure. Large tasks additionally require `feature-planner` (mandatory), `critic` (mandatory), `risk-reviewer` (mandatory), and context anchor at each major step. ## Scale labeling Include the scale classification in your output so humans reviewing the work can quickly understand which path was taken: - In agent output: include `[SCALE: SMALL]`, `[SCALE: MEDIUM]`, or `[SCALE: LARGE]` near the top - In commit messages (if applicable): prefix with `[small]`, `[medium]`, or `[large]` ## Project-specific overrides Teams may customize the Small/Medium/Large thresholds in `project/project-manifest.md`. For example: - A security-focused project might define: "All changes default to Medium minimum" - A documentation-only repo might define: "Single-file doc changes are always Small" - A team might adjust: "Small threshold is 2 files instead of 1" If project-specific overrides exist, they take precedence over the defaults above. ## Reclassification If during implementation you discover the task is larger than initially classified (e.g., a "Small" fix actually requires cross-module changes), **stop and reclassify**. If the new classification is higher, switch to the appropriate workflow path. If switching from Small to Medium/Large, this counts as scope expansion and requires user approval per the checkpoint gates. ## Use this skill when - Starting any new task (after codebase discovery) - Receiving a request and needing to decide how much process is appropriate - A task in progress turns out to be larger or smaller than expected ## Conformance self-check - [ ] Classification is based on codebase evidence (files read), not request text alone; uncertain → Medium - [ ] Hard blockers checked: auth/security/schema/breaking changes force non-Small - [ ] Output includes `[SCALE: ...]`, reason, files affected; scope growth triggers reclassification ## Common misuses - **Classifying by request text instead of codebase evidence** — a request that sounds simple may touch a security-critical module. Always read the affected files before classifying. - **Defaulting every ambiguous task to Small** — when in doubt, classify as Medium. The cost of unnecessary planning is lower than the cost of missing required checkpoints. - **Not reclassifying when scope grows** — if implementation reveals the change requires touching 6 files instead of 1, the task must be reclassified and the checkpoint gate triggered. - **Skipping triage for repeated similar tasks** — a task that looks identical to a previous one may have different risk in the current codebase state (e.g., a function was made security-critical since the last similar task). Always triage independently.