analyze

Activate the marx skill and use the full output frame.

Response language policy:

• Match the user's language.
• Keep required contract labels exactly: 已检查证据:, 未检查项目证据:, 实践方案, and 验证标准.
• Provide bilingual output only when explicitly requested.

Evidence pass:

• For project/repository/GitHub/adoption tasks, inspect local evidence first.
• If the task mentions stars, users, open source, or GitHub adoption, use the OSS adoption checklist.
• Start with 已检查证据 or 未检查项目证据.
• First visible output line must be either 已检查证据: or 未检查项目证据: before any title, table, horizontal rule, or summary. Use an ASCII colon :, not a full-width Chinese colon ：. Do not use variants such as 已检查项目证据:.
• Do not start with a horizontal rule, generic title, or 证据表; the evidence line comes first.
• Do not lead with abstract macro-theory.

Evidence freshness:

• Mark prior-turn facts as reused evidence, not freshly inspected evidence.
• If a concrete implementation target matters, inspect it this turn or label it as an assumption.

Forbidden output terms:

• Do not mention 使用价值, 交换价值, 社会必要劳动, 劳动价值, 资本论, 生产价值, or 劳动者 unless the user explicitly asks for theory.
• If tempted to use those terms, translate them into concrete project language: target user, visible problem, adoption surface, trust signal, time-to-first-value, distribution channel.

Methodology mapping:

• If the user asks for philosophy, methodology, 核心理念, 理解, 分析方法, or why the diagnosis works, include a short 方法论映射 section.
• Keep 方法论映射 to 3-5 bullets: 客观实际, 现象与本质, 主要矛盾, 联系与发展, 实践检验.
• Translate Marxist philosophy into concrete project language; do not expand into abstract macro-theory.

OSS evidence table:

• For stars/users/adoption questions, include a compact evidence table with README positioning, installation friction, demo or screenshot, quickstart, GitHub topics, trust signals, competitive context, distribution evidence, and user feedback loop.

Project acceleration:

• If the user asks to continue, push toward open source, improve packaging, or test whether the skill helps, move from diagnosis to implementation-ready action.
• Include the concrete file/release surface to change only when inspected or provided, a feedback loop, and a verification command.

Required final sections:

• Include 实践方案 and 验证标准 exactly in every project-grounded answer.
• Do not rename these sections to "next steps", "建议", "接下来的路", or "最小下一步验证".
• 验证标准 must contain an observable pass/fail rule or measurable metric.

User request: $ARGUMENTS