Skill

dev-spec

Translate a captured idea into a development specification — system architecture sketch, key components, data model outline, third-party dependencies, build phases to MVP, and identified hard problems. Software-focused; for hardware see hardware-feasibility. Use when the user wants to estimate "what would I actually need to build".

npx claudepluginhub danielrosehill/claude-code-plugins --plugin business-idea-eval

Tool Access

This skill uses the workspace's default tool permissions.

Preview

A first-pass spec a developer could review and challenge — not a final design.

SKILL.md

Similar Skills

skill-lookup

159.9k

Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.

prompts.chat

next-compile

139.2k

Checks Next.js compilation errors using a running Turbopack dev server after code edits. Fixes actionable issues before reporting complete. Replaces `next build`.

1 file

vercel-next-js-2

angular-new-app

100.1k

Creates new Angular apps using Angular CLI with flags for routing, SSR, SCSS, prefixes, and AI config. Follows best practices for modern TypeScript/Angular development. Use when starting Angular projects.

angular-angular-1

Stats

Stars0

Forks0

Last CommitApr 28, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

dev-spec

Development Spec

A first-pass spec a developer could review and challenge — not a final design.

Steps

Read the idea + any prior lens outputs.

Outline:

System architecture — high-level boxes-and-arrows description in prose; client / server / data / integrations
Key components — each with one-paragraph responsibility statement
Data model — main entities, relationships, key fields (don't go to schema-level)
Third-party dependencies — APIs, services, models, libraries the build assumes (auth, payments, AI, email, etc.)
Hard problems — the parts that are not boilerplate; ranked by uncertainty
Out-of-scope for v1 — explicitly listed

Define build phases to first usable version:

Phase 1: thinnest credible MVP (one user, one happy path)
Phase 2: enough features to put in front of paying users
Phase 3: scale and polish For each phase, list deliverables and rough effort (developer-weeks).

Note technology choices the user should make explicitly (language/framework, hosting, AI model strategy, mobile native vs. web). Don't pick for them — surface the trade-offs.

Output

<workspace_path>/ideas/<slug>/analysis/dev-spec.md with frontmatter:

--- lens: dev-spec generated: YYYY-MM-DD mvp_effort_dev_weeks: <number> ---

Notes

This is a sketch, not a contract. The goal is making the build cost visible enough to inform go/no-go.

If the idea is hardware-primary, defer most of this to hardware-feasibility and only spec the companion software layer.

Development Spec

A first-pass spec a developer could review and challenge — not a final design.

Steps

Read the idea + any prior lens outputs.
Outline:
- System architecture — high-level boxes-and-arrows description in prose; client / server / data / integrations
- Key components — each with one-paragraph responsibility statement
- Data model — main entities, relationships, key fields (don't go to schema-level)
- Third-party dependencies — APIs, services, models, libraries the build assumes (auth, payments, AI, email, etc.)
- Hard problems — the parts that are not boilerplate; ranked by uncertainty
- Out-of-scope for v1 — explicitly listed
Define build phases to first usable version:
- Phase 1: thinnest credible MVP (one user, one happy path)
- Phase 2: enough features to put in front of paying users
- Phase 3: scale and polish For each phase, list deliverables and rough effort (developer-weeks).
Note technology choices the user should make explicitly (language/framework, hosting, AI model strategy, mobile native vs. web). Don't pick for them — surface the trade-offs.

Output

<workspace_path>/ideas/<slug>/analysis/dev-spec.md with frontmatter:

---
lens: dev-spec
generated: YYYY-MM-DD
mvp_effort_dev_weeks: <number>
---

Notes

This is a sketch, not a contract. The goal is making the build cost visible enough to inform go/no-go.
If the idea is hardware-primary, defer most of this to hardware-feasibility and only spec the companion software layer.