lov-solution-architect

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)

Before running, read this Skill package's skill.yaml, with the host providing the skill-runtime/v1 context. The field resolution order is: current request, project context, personal Preferences, brand Profile, general defaults.

• Use only the fields declared in the Manifest; the Profile stores public brand facts, and the Preferences store personal work preferences.
• required: true When a field is missing, ask the user one focused question according to the Manifest's question configuration; save the answer only after the user explicitly agrees.
• Errors provide a copyable context_id, field path, and source; diagnostic content avoids secrets, full private paths, and raw configuration.

General feedback loop

When the user gives modification feedback during a Skill-driven task, before continuing with the current artifact you must do the following:

1. First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
2. task-specific Modify only the current task, do not change the Skill.
3. reusable First determine the scope: for domain rules, first update the corresponding canonical Skill; for rules that apply to all Skills, first update the shared specification.
4. After completing rule updates, versioning, lint, and distribution verification, then apply the changes to the current task.
5. reusable A modification invalidates prior "confirm," "continue," and "send it" responses; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, without automatically proceeding to publishing, committing, or other external writes.