Plan software structure and document rejected alternatives for ADR handoff.
npx skills add https://github.com/kanade0404/dotfiles --skill design-kanade0404
Please help me install this Agent Skill. Skill: design Source: https://github.com/kanade0404/dotfiles/tree/main/.opencode/skills/design Command: npx skills add https://github.com/kanade0404/dotfiles --skill design-kanade0404
Use this Skill when you need to decide how a change should be structured before implementation, especially when boundaries, dependencies, and external constraints are unclear.
Ask the assistant to prepare a temporary design scratchpad for your change, compare at least two architecture options, and summarize the decision and ADR-worthy rationale.
High-intent search queries and answers about installing and using this skill.
To decide software structure before coding, create a temporary design scratchpad to compare at least three architecture alternatives, then distill trade-offs and external constraints for ADR handoff. This clarifies I/O boundaries and dependency direction before implementation starts.
ADR handoff is the process of extracting only non-obvious external constraints, rejected alternatives, and trade-offs from a design scratchpad to document architectural decisions. It distills decision rationale rather than restating code behavior or implementation details.
You need to define I/O boundaries and dependency direction before coding when structural boundaries, dependencies, or external constraints are unclear. This applies specifically to requirement handoff, architecture changes, responsibility splitting, and deferred review triage.
Yes, you can use a design scratchpad for responsibility splitting by comparing at least three structural options and evaluating their trade-offs. The scratchpad clarifies dependency direction and I/O boundaries before implementation begins.
The best way to compare architecture alternatives for a new feature is to prepare a temporary design scratchpad evaluating at least three options. Capture why weaker alternatives were rejected and distill only non-obvious trade-offs for ADR handoff.
You should not include code behavior or implementation details in an ADR handoff. It should contain only non-obvious external constraints, trade-offs, and rejected architectural alternatives extracted from the design scratchpad.
linenoizeClarify ambiguous feature requests into structured requirements documents.
Pravin-surawaseValidate architecture boundaries, import direction, and code duplication in repositories.
useblocksRecord design decisions as sphinx-needs directives with decided_by, alternatives, and rationale.
davpatel605-beepDeploy Cloudflare Workers to temporary live URLs via Wrangler.
