From development
Non-interactive design workflow for autonomous contexts (e.g., namespaced `ado-work-on` / `gh-work-on` flows such as `ado:ado-work-on` or `gh:gh-work-on`). Mirrors brainstorming methodology but auto-selects the best approach instead of requiring user approval. Use when designing features/tasks without interactive user feedback — requirements come from tracked work items/issues, specs, or task descriptions rather than live conversation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/development:autonomous-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Design a solution without interactive user approval. Requirements come from
Design a solution without interactive user approval. Requirements come from structured sources (tracked work items/issues, specs, acceptance criteria) rather than live conversation.
This is the autonomous counterpart to development:brainstorming. Use
brainstorming when a user is in the loop; use this skill when operating
autonomously inside a namespaced workflow (e.g., ado:ado-work-on or
gh:gh-work-on).
When similarly named workflows exist in multiple plugins, keep the namespace so the target system stays explicit.
`development:brainstorming` has a HARD-GATE requiring user approval. This skill auto-selects the best approach based on simplicity and pattern consistency. There is no interactive approval step.List all functional requirements from the available context:
code-reviewer:pr-context-gatherer to extract context from related work items, PRs, or issues.Note any ambiguities — these become assumptions to document.
Use Grep/Glob/Read to understand the relevant code area. Identify:
Propose 2-3 approaches. For each:
Choose the approach that best balances:
Document the reasoning for the selection.
Append to the decision log (if one exists):
## Design Decision
- **Chosen approach**: <approach description>
- **Rationale**: <why this over alternatives>
- **Alternatives rejected:**
- <alternative>: <why rejected>
- **Assumptions**: <any ambiguities resolved by assumption>
Dispatch sub-agents in parallel to pressure-test the design decision before handoff. Use whichever apply to the change being designed:
code-reviewer:architecture-review — layer boundaries, dependency
direction, SOLID, coupling, DI patterns; flags structural risks earlycode-reviewer:feature-flag-reviewer — assesses blast radius,
reversibility, and change type to recommend whether the change should
ship behind a feature flagcode-reviewer:over-engineering-review — compares the proposed scope
against the stated intent; flags speculative abstractions, unrequested
features, premature optimization, and other YAGNI violationscode-reviewer:schema-compatibility-review — when the design touches
schemas, DTOs, migrations, queue payloads, or any wire-contract surface;
catches forward/backward compat breaks and rollout-sequencing risksNote: there is no dedicated design-time security reviewer in the
code-reviewer plugin — security concerns are evaluated at code-review time
via the pr-review skill's OWASP checklist. If the design has obvious
security implications (authentication, authorization, crypto, payment, PII
handling), surface them explicitly in the design decision so they're not
discovered late.
Apply the comments, refine the design decision if needed, and then hand off to the implementation skill (e.g., ado:ado-implement or gh:gh-implement) with a clear design decision and implementation plan.
The output of this skill is a design decision ready to feed into an
implementation plan. The calling skill (e.g., ado:ado-work-on or
gh:gh-work-on) takes this output and proceeds to plan creation.
npx claudepluginhub gautam-achieveai/claudeplugins --plugin developmentCreates bite-sized, testable implementation plans from specs or requirements, with file structure and task decomposition. Activates before coding multi-step tasks.