Claude Skill

lov-solution-architect

Create research-backed product and technical solution plans from a user's requirement. Use when the user asks for detailed feasibility analysis, technology selection, architecture, implementation roadmap, library/vendor comparison, "解决方案", "技术方案", "产品方案", "选型", "调研分析", or a Skill

LLM Mart · 0 points · 8 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download lovstudio-skills-skills_solution-architect-77d464c.zip · 9 KB

lovstudio/skills 67 17 forks MIT Updated 11d ago

Part of lovstudio/skills — 83 skills

Install

skills CLI npx skills add https://github.com/lovstudio/skills/tree/main/skills/solution-architect

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install lovstudio-skills@llmmart

Git git clone https://github.com/lovstudio/skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole lovstudio/skills collection as a plugin from our marketplace. Git is the plain clone.

README

方案架构师 · Solution Architect

把产品或技术需求转成有调研依据、开源优先的可执行解决方案。

Part of skill-publisher/skills — by example.com

Install

npx skills add solution-architect -g -y

Use Cases

技术方案：架构、模块拆分、部署、运维和风险控制。
产品方案：用户流程、数据模型、功能边界和交付路线。
技术选型：对比开源库、商业 API、商业产品和自研方案。
客户方案：按 Skill Publisher.ai / 品牌工作室品牌预设生成解决方案内容。

Usage

/lov-solution-architect 我想做一个 AI 合同审阅产品，请给我技术方案
/lov-solution-architect 帮我比较一下自建 RAG 和商业知识库 API 的方案

Skill 会先确认真正阻塞的信息；如果没有阻塞，会直接给出假设并继续。输出包含结论摘要、需求理解、模块拆分、推荐架构、技术选型、实施路线、成本估算、风险应对和下一步。

Principle

默认优先级：

现代、活跃、体验好的开源 DIY 方案。
仍然稳定可靠的传统开源方案。
只有在差异化、隐私、安全或开源缺口明确时才自研。
开源方案明显不如商业 API 时才选商业 API。
只有买比集成或自建更合适时才选商业产品。

References

License

MIT

Skill manifest

方案架构师 · Solution Architect

Turn a user's raw requirement into a detailed, researched solution plan in Simplified Chinese.

Core Rule

Prefer options in this order:

Modern popular open-source DIY libraries, frameworks, and protocols.
Older or legacy open-source libraries only when they are still the safest fit.
From-scratch implementation only for core differentiation, missing open-source coverage, or privacy/security needs.
Commercial API calls only when open-source DIY is materially worse on quality, cost, compliance, speed, or maintenance.
Commercial products only when buying is clearly better than building or integrating.

When comparing libraries, favor modern projects with better developer experience, active maintenance, community reputation, and clear docs. Example preference: modern-screenshot over html2canvas; FastAPI over Express when a Python API stack is acceptable.

Workflow

Clarify only blockers. Ask at most 3 questions if the requirement lacks target users, runtime/platform, budget, compliance, or delivery deadline. Otherwise state assumptions and continue.
Break the requirement into modules: user workflow, data model, integrations, UI, backend, storage, auth, deployment, observability, and operations as relevant.
Research current options. Use up-to-date web search and official docs for libraries, APIs, pricing, licenses, and project health. Use Context7 for framework/library docs when available.
Score each module with the selection rubric in references/selection-rubric.md.
Build a concrete architecture and implementation path. Prefer composable OSS libraries over monolithic platforms when it keeps ownership and maintainability high.
Output the solution using references/output-template.md.

Research Requirements

Cite specific projects, docs, pricing pages, GitHub repositories, or product pages.
Compare at least 2 viable options for important modules unless there is an obvious standard.
Record rejected options and the reason they were rejected.
Include cost, delivery time, maintenance risk, lock-in risk, data/privacy implications, and operational complexity.
Prefer official sources for technical details and pricing. Use secondary sources only for reputation signals or ecosystem context.
If research cannot be completed because browsing or sources are unavailable, say so explicitly and separate confirmed facts from assumptions.

Skill Publisher Brand Preset

Use this brand by default when the solution needs a vendor, studio, deck, PDF, proposal, or cover:

English name: Skill Publisher.ai
Chinese name: 品牌工作室
Logo asset: assets/lov-logo.svg

Do not imply a commercial proposal unless the user asks for a client-facing proposal, quotation, or branded deliverable.

Output Standard

Produce a complete solution, not a loose brainstorm. The final answer must include:

Executive summary.
Requirement interpretation and assumptions.
Module breakdown.
Recommended architecture.
Technology selection with alternatives and rejected options.
Implementation roadmap.
Cost and resource estimate.
Risks and mitigation.
Concrete next steps.

Use Mermaid or ASCII diagrams when architecture/data flow would be clearer visually.

Runtime context (shared)

运行前读取本 Skill 包的 skill.yaml，由宿主提供 skill-runtime/v1 上下文。字段解析顺序为：当前请求、项目上下文、个人 Preferences、品牌 Profile、通用默认值。

只使用 Manifest 声明的字段；Profile 保存公开品牌事实，Preferences 保存个人工作偏好。
required: true 字段缺失时，按 Manifest 的问题配置向用户提出一个聚焦问题；用户明确同意后再保存回答。
报错提供可复制的 context_id、字段路径与来源，诊断内容避开秘密、完整私人路径和原始配置。

通用反馈闭环

用户在 Skill 驱动任务中提出修改意见时，继续当前产物前必须执行：

先判断意见是 task-specific（仅本次）还是 reusable（可跨任务复用）。
task-specific 只修改当前任务，不改 Skill。
reusable 先确定作用域：领域规则先更新对应 canonical Skill；适用于所有 Skill 的规则先更新共享规范。
完成规则更新、版本、lint 与分发核验后，再把修改应用到当前任务。
reusable 修改会使此前的“确认”“继续”“发吧”失效；完成当前产物修改和回读后必须停下，等待用户下一步指示，不自动进入发布、提交或其他外部写入。

Files (skills)

agents

openai.yaml 350 B

interface:
  display_name: "方案架构师"
  short_description: "需求调研、技术选型与现代开源优先的端到端解决方案设计"
  icon_small: "./assets/lov-logo.svg"
  icon_large: "./assets/lov-logo.svg"
  default_prompt: "Use $solution-architect to turn my product or technical requirement into a researched implementation plan."

assets
- lov-logo.svg 753 B · in bundle

references

output-template.md 1.7 KB

# Output Template

Use this structure for the final answer unless the user asks for a different format.

```markdown
# <项目/需求名称>解决方案

## 1. 结论摘要
<用 3-5 条说明推荐方案、核心理由、成本/周期量级、最大风险。>

## 2. 需求理解与假设
- 目标用户：
- 核心场景：
- 关键约束：
- 本方案假设：

## 3. 模块拆分
| 模块 | 目标 | 推荐路线 | 说明 |
|---|---|---|---|
| <模块> | <解决什么问题> | <现代开源 DIY / 传统开源 / 自研 / 商业 API / 商业产品> | <一句话原因> |

## 4. 推荐架构
<Mermaid 或 ASCII 架构图。>

<解释核心数据流、用户流、服务边界、部署边界。>

## 5. 技术选型
| 模块 | 首选方案 | 备选方案 | 排除方案 | 选择理由 |
|---|---|---|---|---|
| <模块> | <名称+链接> | <名称+链接> | <名称+原因> | <结合评分维度说明> |

## 6. 实施路线
| 阶段 | 周期 | 工作内容 | 交付物 |
|---|---:|---|---|
| MVP | <时间> | <内容> | <可验收产物> |
| V1 | <时间> | <内容> | <可验收产物> |
| V2 | <时间> | <内容> | <可验收产物> |

## 7. 成本估算
| 成本项 | 方案 | 估算 | 依据 |
|---|---|---:|---|
| 开发 | <人力/外包/自研> | <金额/人天> | <假设> |
| 基础设施 | <云服务> | <月费> | <定价链接或假设> |
| API/第三方 | <服务> | <月费/调用费> | <定价链接> |

## 8. 风险与应对
| 风险 | 影响 | 应对 |
|---|---|---|
| <风险> | <高/中/低> | <具体动作> |

## 9. 下一步
1. <最先验证的事项>
2. <原型/POC 任务>
3. <需要用户确认的决策>

## 10. 参考来源
- <链接>：<用途>
```

Keep the answer concise enough to act on, but include enough evidence that the recommendation is auditable.

selection-rubric.md 2.7 KB

# Selection Rubric

Use this rubric when ranking implementation options for each module.

## Priority Ladder

Rank options by this default ladder:

| Rank | Option type | Prefer when |
|---|---|---|
| 1 | Modern popular open-source DIY | Mature enough, active, good docs, avoids lock-in, can be integrated quickly |
| 2 | Legacy open-source DIY | Proven and stable, but only if modern choices are weaker or incompatible |
| 3 | From-scratch implementation | Core differentiator, unusual domain logic, strict privacy/security, or no adequate OSS |
| 4 | Commercial API | OSS/self-hosted quality is worse, or API materially reduces risk/time |
| 5 | Commercial product | Buying solves the whole workflow better than building/integrating |

## Scorecard

Score important candidates from 1 to 5:

| Dimension | Weight | What to check |
|---|---:|---|
| Fit to requirement | 25 | API coverage, extensibility, ecosystem compatibility |
| Developer experience | 15 | Docs, examples, type support, error quality, setup friction |
| Maintenance health | 15 | Recent releases, issue response, stars/downloads, bus factor |
| Output quality | 15 | Accuracy, rendering quality, performance, reliability |
| Cost and ownership | 10 | License, hosting/API fees, lock-in, migration path |
| Security and privacy | 10 | Data exposure, auth model, self-hosting, compliance |
| Operational complexity | 10 | Deployment, scaling, observability, failure recovery |

Recommend the highest weighted fit, not the highest raw popularity.

## Evidence Checklist

For recommended libraries or frameworks, gather:

- Official documentation URL.
- Repository URL when open source.
- License.
- Last meaningful release or recent commit activity.
- Adoption signal such as stars, downloads, community usage, or ecosystem default status.
- Known limitations and migration risk.

For commercial APIs/products, gather:

- Pricing URL.
- Data processing/privacy notes.
- Rate limits or quota model.
- Exit path if the service is replaced later.

## Decision Rules

- Prefer `modern-screenshot` over `html2canvas` for browser DOM screenshots unless compatibility evidence says otherwise.
- Prefer `FastAPI` over `Express` for API services when Python is acceptable and type/schema-first development matters.
- Prefer protocol-compatible providers over proprietary SDK-only integrations.
- Prefer self-hostable components when user data sensitivity is high.
- Prefer smaller focused libraries over full platforms unless the platform replaces substantial engineering work.
- Do not choose from-scratch work just because it is technically possible.
- Do not choose a commercial API before checking whether a current OSS stack can satisfy quality and timeline.

.gitignore 51 B · in bundle

CHANGELOG.md 309 B

# Changelog

## [0.2.0] - 2026-08-24

### Added

- add the shared feedback-classification and approval-invalidation gate used by every LovStudio Skill

## 0.1.0 - 2026-05-17

- Initial public release.
- Added Skill Publisher catalog metadata, open-source-first selection rubric, and solution output template.

LICENSE 1 KB · in bundle

README.md 1.7 KB

# 方案架构师 · Solution Architect

![Version](https://img.shields.io/badge/version-0.2.0-CC785C) ![Free](https://img.shields.io/badge/Free-green) ![Category](https://img.shields.io/badge/category-business-blue)

把产品或技术需求转成有调研依据、开源优先的可执行解决方案。

Part of [skill-publisher/skills](https://example.com/skills/skills) — by [example.com](https://example.com)

## Install

```bash
npx skills add solution-architect -g -y
```

## Use Cases

- 技术方案：架构、模块拆分、部署、运维和风险控制。
- 产品方案：用户流程、数据模型、功能边界和交付路线。
- 技术选型：对比开源库、商业 API、商业产品和自研方案。
- 客户方案：按 Skill Publisher.ai / 品牌工作室品牌预设生成解决方案内容。

## Usage

```text
/lov-solution-architect 我想做一个 AI 合同审阅产品，请给我技术方案
/lov-solution-architect 帮我比较一下自建 RAG 和商业知识库 API 的方案
```

Skill 会先确认真正阻塞的信息；如果没有阻塞，会直接给出假设并继续。输出包含结论摘要、需求理解、模块拆分、推荐架构、技术选型、实施路线、成本估算、风险应对和下一步。

## Principle

默认优先级：

1. 现代、活跃、体验好的开源 DIY 方案。
2. 仍然稳定可靠的传统开源方案。
3. 只有在差异化、隐私、安全或开源缺口明确时才自研。
4. 开源方案明显不如商业 API 时才选商业 API。
5. 只有买比集成或自建更合适时才选商业产品。

## References

- [Output template](references/output-template.md)
- [Selection rubric](references/selection-rubric.md)

## License

MIT

SKILL.md 5.6 KB

---
name: lov-solution-architect
version: "0.2.0"
tagline: "把产品或技术需求转成有调研依据、开源优先的可执行解决方案。"
description: Create research-backed product and technical solution plans from a user's requirement. Use when the user asks for detailed feasibility analysis, technology selection, architecture, implementation roadmap, library/vendor comparison, "解决方案", "技术方案", "产品方案", "选型", "调研分析", or a Skill Publisher.ai / 品牌工作室 branded solution. Prioritize modern popular open-source DIY options over legacy libraries, from-scratch builds, commercial APIs, and commercial products.
license: MIT
compatibility: >
  Works in any agent environment with web browsing available for current
  technology, pricing, licensing, and project-health research. Context7 is
  recommended when framework/library documentation is needed.
metadata:
  author: contributors
  version: "0.2.0"
  category: business
  tags: solution architecture technical-plan product-plan research technology-selection open-source
---

# 方案架构师 · Solution Architect

Turn a user's raw requirement into a detailed, researched solution plan in Simplified Chinese.

## Core Rule

Prefer options in this order:

1. Modern popular open-source DIY libraries, frameworks, and protocols.
2. Older or legacy open-source libraries only when they are still the safest fit.
3. From-scratch implementation only for core differentiation, missing open-source coverage, or privacy/security needs.
4. Commercial API calls only when open-source DIY is materially worse on quality, cost, compliance, speed, or maintenance.
5. Commercial products only when buying is clearly better than building or integrating.

When comparing libraries, favor modern projects with better developer experience, active maintenance, community reputation, and clear docs. Example preference: `modern-screenshot` over `html2canvas`; `FastAPI` over `Express` when a Python API stack is acceptable.

## Workflow

1. Clarify only blockers. Ask at most 3 questions if the requirement lacks target users, runtime/platform, budget, compliance, or delivery deadline. Otherwise state assumptions and continue.
2. Break the requirement into modules: user workflow, data model, integrations, UI, backend, storage, auth, deployment, observability, and operations as relevant.
3. Research current options. Use up-to-date web search and official docs for libraries, APIs, pricing, licenses, and project health. Use Context7 for framework/library docs when available.
4. Score each module with the selection rubric in `references/selection-rubric.md`.
5. Build a concrete architecture and implementation path. Prefer composable OSS libraries over monolithic platforms when it keeps ownership and maintainability high.
6. Output the solution using `references/output-template.md`.

## Research Requirements

- Cite specific projects, docs, pricing pages, GitHub repositories, or product pages.
- Compare at least 2 viable options for important modules unless there is an obvious standard.
- Record rejected options and the reason they were rejected.
- Include cost, delivery time, maintenance risk, lock-in risk, data/privacy implications, and operational complexity.
- Prefer official sources for technical details and pricing. Use secondary sources only for reputation signals or ecosystem context.
- If research cannot be completed because browsing or sources are unavailable, say so explicitly and separate confirmed facts from assumptions.

## Skill Publisher Brand Preset

Use this brand by default when the solution needs a vendor, studio, deck, PDF, proposal, or cover:

- English name: `Skill Publisher.ai`
- Chinese name: `品牌工作室`
- Logo asset: `assets/lov-logo.svg`

Do not imply a commercial proposal unless the user asks for a client-facing proposal, quotation, or branded deliverable.

## Output Standard

Produce a complete solution, not a loose brainstorm. The final answer must include:

- Executive summary.
- Requirement interpretation and assumptions.
- Module breakdown.
- Recommended architecture.
- Technology selection with alternatives and rejected options.
- Implementation roadmap.
- Cost and resource estimate.
- Risks and mitigation.
- Concrete next steps.

Use Mermaid or ASCII diagrams when architecture/data flow would be clearer visually.

## Runtime context (shared)

运行前读取本 Skill 包的 `skill.yaml`，由宿主提供 `skill-runtime/v1` 上下文。字段解析顺序为：当前请求、项目上下文、个人 Preferences、品牌 Profile、通用默认值。

- 只使用 Manifest 声明的字段；Profile 保存公开品牌事实，Preferences 保存个人工作偏好。
- `required: true` 字段缺失时，按 Manifest 的问题配置向用户提出一个聚焦问题；用户明确同意后再保存回答。
- 报错提供可复制的 `context_id`、字段路径与来源，诊断内容避开秘密、完整私人路径和原始配置。

## 通用反馈闭环

用户在 Skill 驱动任务中提出修改意见时，继续当前产物前必须执行：

1. 先判断意见是 `task-specific`（仅本次）还是 `reusable`（可跨任务复用）。
2. `task-specific` 只修改当前任务，不改 Skill。
3. `reusable` 先确定作用域：领域规则先更新对应 canonical Skill；适用于所有 Skill 的规则先更新共享规范。
4. 完成规则更新、版本、lint 与分发核验后，再把修改应用到当前任务。
5. `reusable` 修改会使此前的“确认”“继续”“发吧”失效；完成当前产物修改和回读后必须停下，等待用户下一步指示，不自动进入发布、提交或其他外部写入。

skill.yaml 850 B

schema: skill-manifest/v1
id: lov-solution-architect
version: "0.2.0"
runtime: skill-runtime/v1
context:
  profile:
    fields:
    - path: identity.name
      required: true
      question: 如果本次输出需要品牌身份，请提供品牌名称。
    - path: identity.logo
      required: false
      question: 如果需要使用品牌 Logo，请提供 Logo 地址或文件路径。
    - path: brand.tone
      required: false
      question: 如果已有品牌语气或审美关键词，请提供它们。
  preferences:
    namespace: lov_solution_architect
    fields:
    - path: user.language
      required: false
      question: 希望使用哪种语言输出？
    - path: user.timezone
      required: false
      question: 需要使用哪个时区处理日期和时间？
  interaction:
    ask_missing: true
    max_questions: 1