dev2-design

Generate 2–4 architecture design alternatives with trade-offs for browseros-agent features.

Updated Apr 12, 2026
One-click install
npx skills add https://github.com/Srajangpt1/dataeye --skill dev2-design-srajangpt1
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dev2-design
Source: https://github.com/Srajangpt1/dataeye/tree/main/packages/browseros-agent/.claude/skills/dev2-design
Command: npx skills add https://github.com/Srajangpt1/dataeye --skill dev2-design-srajangpt1

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill produces clear, actionable high-level design options when a feature request needs architectural alternatives and trade-offs, reducing time in design reviews and avoiding ad-hoc decisions that cause rework.

Core Features & Use Cases

  • Design Alternatives: Generates 2–4 high-level implementation or architecture options with an overview, advantages, disadvantages, complexity, and risk for each.
  • Grounded in the repo: Reads exploration artifacts from .llm/$ARGUMENTS/tmp_context.md and .llm/$ARGUMENTS/tmp_exploration.md and references real modules and patterns in packages/browseros-agent such as apps/server, apps/agent, and packages/agent-sdk.
  • Workflow handoff: Saves the chosen design to .llm/$ARGUMENTS/design.md and invokes the next step in the dev workflow to lock decisions and proceed to production design.

Quick Start

Use dev2-design to generate three high-level design options for the feature "secure clipboard handling" based on the repository exploration files.

Frequently Asked Questions about dev2-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate architecture design options for a new software feature?▼

To generate architecture design options for a software feature, you need an automated workflow that reads exploration artifacts and outputs 2 to 4 alternatives. Each alternative should detail the overview, advantages, disadvantages, complexity, and risk to facilitate design review.

What is the best way to evaluate trade-offs in a monorepo architecture?▼

Evaluating trade-offs in a monorepo architecture involves generating grounded feature design options that compare advantages and disadvantages across components. This reduces design review time and prevents ad-hoc decisions that cause rework across extension, server, and SDK packages.

How do I create design alternatives grounded in real repository modules?▼

Creating design alternatives grounded in real modules requires reading exploration artifacts from temporary context files. The generated options must reference actual patterns within monorepo packages, such as apps/server, apps/agent, and agent-sdk, ensuring realistic architectural choices.

Can I use design options to plan browser extension and server component features?▼

Yes, you can generate high-level design options to plan features spanning browser extension and server components. The process evaluates architectural alternatives and risks specifically within a monorepo environment covering extension, server, and SDK components during design planning.

How do I save design decisions and proceed to production design?▼

To save design decisions and proceed to production design, the workflow must save the chosen architecture alternative to a design markdown file. This action locks the decisions and automatically invokes the next step in the development workflow.