Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 13 additions & 13 deletions packages/agents/content/skills/_data/complexity-classification.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,47 +11,47 @@ Classify the complexity of a task, finding, or change to determine how it should
| 3 | **Involved** | Requires understanding context. Touches multiple files or modules. May involve design decisions. |
| 4 | **Architectural** | Cross-cutting concerns, new patterns, dependency boundary changes, or far-reaching consequences. |

### Level 1 — trivial
### Level 1: Trivial

- Remove unused import
- Fix typo in error message or variable name
- Add missing return type that the compiler can infer
- Delete dead code already flagged by a linter

### Level 2 — mechanical
### Level 2: Mechanical

- Rename a local function or variable across its usages within a single module
- Add a missing test case that follows an existing test pattern
- Extract a repeated literal into a named constant
- Update a reference path after a file was moved

### Level 3 — involved
### Level 3: Involved

- Refactor retry logic to use a shared utility
- Add error handling for a new edge case that requires understanding the call chain
- Modify a data structure shared between modules
- Implement a feature that follows an established pattern but spans multiple files

### Level 4 — architectural
### Level 4: Architectural

- Introduce a new subsystem or module boundary
- Change how modules communicate (new interfaces, events, or protocols)
- Modify dependency boundaries (add/remove/replace libraries)
- Restructure control flow or state management across components

## Consumer thresholds
## Consumer levels

Each consuming skill defines its own threshold against this rubric. The threshold indicates which levels qualify for the consumer's "simple enough" decision.
Each consuming skill defines which complexity levels qualify for its "simple enough" decision against this rubric.

| Consumer | Threshold | Decision |
| ---------------------------------- | --------- | ------------------------------------------------------------------ |
| `wrap-up` drive-by pass | 1–2 | Apply immediately on the current branch; skip ticket creation |
| `next-steps-after-plan` | 1–2 | Recommend "implement directly" (no orchestration needed) |
| `next-steps-after-review` | 1–2 | Recommend "implement directly" (findings are simple enough to fix) |
| `orchestrated-architect` (planned) | 1–2 | Classify as `none`/`low` impact (minimal architectural guidance) |
| Consumer | Levels | Decision |
| ---------------------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `wrap-up` drive-by pass | 1–2 | Apply immediately on the current branch; skip ticket creation |
| `next-steps-after-plan` | 1–2 | Recommend "Implement directly with follow-up review". When a review pass would catch nothing meaningful (e.g., a typo or unused-import removal), recommend "Implement directly" instead. |
| `next-steps-after-review` | 1–2 | Recommend "implement directly" (findings are simple enough to fix without further review) |
| `orchestrated-architect` (planned) | 1–2 | Classify as `none`/`low` impact (minimal architectural guidance) |

When characteristics span two levels, prefer the higher level. This is consistent with the "when uncertain, recommend the more thorough option" pattern used by consuming skills.

Consumers above level 2 should use the level descriptions to inform their own routing logic rather than mapping mechanically to a single threshold.
Consumers above level 2 should use the level descriptions to inform their own routing logic rather than relying solely on this table.

The complexity rubric and the [ticket-creation-cost](ticket-creation-cost.md) model compose: complexity drives orchestration-routing decisions (which skill picks the work up next), while ticket-creation-cost drives ticket-creation decisions (whether the work needs its own ticket at all).
12 changes: 6 additions & 6 deletions packages/agents/content/skills/_data/next-steps-after-plan.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,11 +4,11 @@ Standard next-steps block for skills that produce or refine an implementation pl

## Options

| # | Emoji | Option | Description |
| --- | ----- | ------------------ | ------------------------------------------------- |
| 1 | 🧠 | Refine plan | Review the plan for completeness and correctness |
| 2 | 🎶 | Orchestrate | Run the full orchestrated development pipeline |
| 3 | 🚀 | Implement directly | Implement without orchestration (no review cycle) |
| # | Emoji | Option | Description |
| --- | ----- | ------------------ | ------------------------------------------------ |
| 1 | 🧠 | Refine plan | Review the plan for completeness and correctness |
| 2 | 🎶 | Orchestrate | Run the full orchestrated development pipeline |
| 3 | 🚀 | Implement directly | |

## Output format

Expand Down Expand Up @@ -57,7 +57,7 @@ Select the recommended option by checking these rules in order and stopping at t
- The plan has not been previously refined
- A prior iteration of `refine-plan` resulted in significant alteration of the plan or significant expansion of the scope of the changes required to implement the plan

2. **Implement directly** — recommend when the work falls at [complexity levels 1–2](complexity-classification.md) (trivial or mechanical — e.g., single module, no cross-cutting renames or shared convention changes), or follows an established pattern closely enough that the coder's first pass is sufficient
2. **Implement directly** — recommend when the work's verification surface fits a single end-of-work review pass: single module/package, the plan is precise (or follows an established pattern closely), and the implementation's consequences are bounded enough that compiler + tests + one review pass would catch the meaningful classes of mistake. Cross-cutting changes, novel patterns, or work whose consequences ripple beyond the immediate change site fall through to rule 3.
3. **Orchestrate** — all other cases (default)

Each skill supplies its own recommendation context (e.g., whether the plan was developed interactively, whether a review just completed). Apply these rules using that context.
Expand Down
2 changes: 1 addition & 1 deletion packages/agents/content/skills/refine-plan/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -211,7 +211,7 @@ Plan refined:
```

<HARD-GATE>
Read [next-steps-after-plan](../_data/next-steps-after-plan.md) and follow its options, output format, and recommendation rules exactly. Do not improvise the options. The plan was just reviewed. If the review surfaced significant scope changes or unresolved questions that led to a dramatic revision, the plan may warrant another refinement round; otherwise, orchestration is the typical recommendation. Use this as recommendation context. Include both `{revision_output_path}` (as the plan path) and `{ticket_source}` in each skill-invoking option line.
Read [next-steps-after-plan](../_data/next-steps-after-plan.md) and follow its options, output format, and recommendation rules exactly. Do not improvise the options. The plan was just reviewed. If the review surfaced significant scope changes or unresolved questions that led to a dramatic revision, the plan may warrant another refinement round; otherwise, either orchestration or direct implementation may apply depending on whether the work's consequences fit a single review pass. Use this as recommendation context. Include both `{revision_output_path}` (as the plan path) and `{ticket_source}` in each skill-invoking option line.
</HARD-GATE>

## Edge cases
Expand Down
Loading