用途：incu-way-po 位于开发流程上游，把原始需求转成一个或多个“可开发”的工单，并在真实代码库中验证哪些可行、哪些不可行、影响哪些模块、哪些仍需人工决策。目标是让开放问题在 incu-way-development 或 incu-way-bugs 启动前解决，而不是开发过程中才暴露。流程为：原始需求 → incu-way-po → TICKET.md（Ready）→ incu-way-development 或 incu-way-bugs。
主要能力：先做仓库资格检查，读取 ~/.ways/config.yaml 的黑名单，命中则询问用户是否例外放行。Phase 0 为只读的接收与可行性调研，梳理问题、期望结果、约束、非目标与成功度量，读取 PRD.md、docs/、既有工单与 PRD，确定受影响仓库（优先 hub 仓库 CLAUDE.md 的 repos: 段，其次 linkedRepos），逐仓库只读调研现状、受影响模块、入口、集成与既有模式，可行性结论须可追溯到 repo:path:line，未知项一律记为开放问题。Gate 1 提出范围与工单拆分并等待确认。之后询问隔离方式（当前检出分支或独立 worktree），工单写在拥有 docs/ 的 hub 仓库。Phase 2 按 docs/requirements/{ticket-slug}/TICKET.md 起草，slug 格式为 {零填充ID}-{kebab名称}，取号时用 git-common-dir 下的 incu-way-prd-slug.lock 加锁，扫描当前检出、其他 worktree 与默认分支后预留 ID。Gate 2 做 Definition of Ready 评审，开放问题未解决不得标记 Ready。Phase 3 交接，可选 Jira 同步仅在用户明确要求时执行，Gate 3 建议调用 incu-way-prepare-pr 开 PR。
限制：不写代码、PRD 或计划；不向被调研仓库写入；不直接写 develop 或 main；不编造需求、范围或验收标准；可行性声明必须可追溯；未获明确请求不得创建、更新或流转 Jira 工单。