用途：帮助贡献者按接收社区的要求准备开源贡献，优化正确性、契合度、清晰度、可审查性和后续跟进，而非表面修饰或数量。
主要能力与流程：
- 确认上游决策：梳理问题与受影响用户、issue/归属/处置分类、接收项目与组件、为何该项目是负责的归属方、本地约束与临时变通方案；归属未解决时回到 upstream-first。
- 阅读项目规则：检查贡献、治理、安全、支持、许可、发布、无障碍与 AI 政策，参考 policy-discovery.md 清单，记录缺失、冲突或含糊要求。若项目禁止相关 AI 使用，则停止在该范围内产出内容；若为漏洞，走私有安全流程并移交 responsible-security-disclosure，不准备公开 issue。
- 选择最小有用贡献：问题或讨论、可复现 issue、失败测试、文档或翻译、设计提案、聚焦补丁或 PR、资助/审查/维护提议。重大功能、架构、新依赖、标准变更或大范围重构前先询问维护者；不要假设代码最有用，也不要把小的无障碍改动视为必然低风险。
- 建立证据：简洁问题陈述、受影响的人与任务、最小复现步骤、支持版本与环境、实际与预期行为、规范/文档/测试或既往决策证据、范围与非目标、隐私安全产物、不确定性与替代解释。无障碍问题需说明用户影响并结合自动与人工证据；回归优先失败测试；无法自动化时说明原因并提供最小人工或视觉测试用例，仅视觉测试不足以确立无障碍。
- 准备改动：遵循现有架构、风格、测试与文档，以已接受的类似贡献为证据而非凌驾于书面政策；保持 diff 聚焦，移除无关格式、推测性抽象、臆造依赖、生成冗余与重复文档；运行可用的确定性测试与检查，未运行不得声称已运行。Git 跨仓库工作参考 cross-repository-git.md，先发现远端、目标分支与发布流程，不要硬编码 main、master 或 develop。
- 准备维护者上下文：说明为何归属此处、为何选此方案、被拒替代方案、兼容与发布影响、无障碍/安全/隐私/许可/可持续性发现、已运行测试与结果、后续工作及负责人、按要求披露实质性 AI 协助，使用 readiness-checklist.md。
- 产出交接：选择 upstream-issue.md、design-proposal.md 或 pull-request.md，区分事实、推断与开放问题，文本简洁可审。未经人工批准不得对外发布或互动；AI 实质性协助时提交前运行 ai-contribution-review。
审查回应：直接回答实际问题，区分必须修复、重要后续与可选建议，修订而非防御性堆量，无法继续时及时说明，负责任地关闭或移交被放弃工作，上游状态变化时更新下游变通与迁移记录。
完成条件：接收政策与贡献渠道已知；重大工作有维护者同意或明确标为提案；证据可复现且隐私安全；范围、非目标、测试与风险明确；贡献者能解释并修订工作；后续跟进有负责人；对外行动仍须人工批准。
限制：资料未提供具体安装命令、平台支持、收费或价格信息。