菜单
Backend technology stack evaluation — choose boring technology scaled by project context. Use when selecting languages, databases, async infra, or API styles for new or existing backends.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Architecture inconsistency detection via deterministic tools, research fallback, and AI heuristic
AI-generated code quality detection via AST, regex, and heuristic analysis
Competitive intelligence research methodology for source code and public information comparison
Improvement-discovery methodology for current-state, LBP, and external landscape analysis
Backlog reconciliation, bug priority assignment, and ROADMAP.md regeneration methodology
Codebase reconnaissance skill for mapping structure, hotspots, and risks
| name | adv-backend-stack-eval |
| description | Backend technology stack evaluation — choose boring technology scaled by project context. Use when selecting languages, databases, async infra, or API styles for new or existing backends. |
| keywords | ["backend","stack","backend stack","tech stack","architecture","database","postgres","data store","queue","kafka","temporal","async","message queue","graphql","rpc","rest","api","rust","go","python","typescript","language","runtime","choose boring technology","technology choice","innovation budget","boring technology","stack evaluation","architecture decision"] |
| license | MIT |
| metadata | {"review_status":"reviewed","source":"agent-created","trigger_change":"createbackendstackevaluationsk","created_at":"2026-05-08"} |
Load when evaluating backend language/runtime, database/data layer, async/workflow infrastructure, or API style.
Load when starting a backend/API, adding/replacing a data store/queue/runtime, or comparing stack options.
Skip when stack is already mandated, decision is trivial/reversible, only one viable option exists, or user already chose and wants implementation help.
Prefer boring, well-understood technology when evidence is comparable. Scale novelty tolerance by project context: personal projects can experiment; platforms need strong evidence for change.
"Every company gets about three innovation tokens." — Dan McKinley, Choose Boring Technology
| Type | Context | Innovation Budget | Evidence Bar |
|---|---|---|---|
| Personal / scratch | usually greenfield | high | Light |
| Internal tool | greenfield or brownfield | medium | Standard |
| Published product / SaaS | hybrid | low | Standard |
| Platform / library | brownfield-sensitive | very low | Rigorous |
For brownfield work, existing-stack integration is first-class. Do not treat greenfield appeal as automatic migration fit.
Ask 2–3, weighted by project type:
| Doc | Use |
|---|---|
LANGUAGE.md | Language/runtime criteria and prompts |
DATABASE.md | Database/data layer criteria and prompts |
ASYNC.md | Queue/event/workflow criteria and prompts |
API.md | REST/RPC/GraphQL/API contract criteria and prompts |
| Tier | Requirement |
|---|---|
| Light | Docs checked, active maintenance, gut check passes |
| Standard | Light + production examples, maintenance health, primary failure mode, migration path |
| Rigorous | Standard + migration plan, runbooks, ops capability, alternatives, capacity estimate |
Before recommending, state tier, evidence present, missing evidence, and risks. Do not invent certainty.
prioritizer when 2+ options remain viable and tradeoffs depend on values.adv-user-intuit when concrete candidates need user taste/preference.sharperflow-web-standards.mcp-selection.