skills/ai-coding-project-forge/references/interview-flow.md

# EW AI Coding v0.8.1 interview flow / v0.8.1 自然引導流程

Use the user's selected language. Do not show both languages unless the user asks for bilingual output.

## Core principle / 核心原則

The user should feel that they are having a useful conversation, not filling out a software requirements form. Ask one main question per turn. Translate ordinary language into professional product, architecture, acceptance, and implementation structure internally.

EW AI Coding is general-purpose. Personal, learning, travel, household, creator, work, team, and enterprise ideas all use the same core flow. Add enterprise governance only when the actual scope requires it.

## Stage 0: Identify the starting evidence / 階段零：判斷使用者從哪裡開始

Accept any useful starting point:

- a new idea;
- a problem the user wants to solve;
- an SOP, procedure, workflow diagram, screenshot, or document;
- interview notes or meeting notes;
- a repetitive task;
- existing specifications;
- existing code;
- a Codex result, repository, preview, test output, or blocker.

Do not force the user to choose a technical mode first. Infer the route internally.

For a blank start, ask:

> 你現在有什麼想法、流程或重複工作想改善？直接像平常聊天一樣告訴我，不完整也沒關係。

> What idea, workflow, or repetitive task would you like to improve? Tell me naturally; it does not need to be complete.

## Stage 1: Opportunity discovery / 階段一：找出值得做的應用

When the user supplies an SOP, workflow, interview notes, or repetitive work, do not immediately turn the whole thing into software. First reconstruct the current work from the evidence.

Identify only what the evidence supports:

- trigger and goal;
- people or roles involved;
- inputs and source data;
- main steps and handoffs;
- repeated copying, checking, formatting, searching, reporting, reminders, or reconciliation;
- deterministic rules;
- professional or contextual judgment;
- outputs and records;
- exceptions;
- human approval points;
- irreversible or high-risk actions.

Then identify candidate application opportunities and classify them as:

- Suitable now / 適合現在做
- Suitable after prerequisites / 補足條件後適合
- Human-assist only / 只適合 AI 輔助
- Not suitable / 不適合自動化

For each meaningful candidate, explain briefly:

1. what problem it removes;
2. what could be handled by deterministic code, database/search, AI, or human approval;
3. required inputs or integrations;
4. major risk or missing prerequisite;
5. the smallest useful first version;
6. how success could be verified.

Rank candidates only when there is enough evidence. Prefer high-frequency, rule-clear, measurable, reversible work with accessible inputs. Never invent ROI, labor savings, implementation duration, or data availability.

If the user started with a clear personal or everyday-life idea, do not force a formal opportunity report. Move directly into clarification.

## Stage 2: Work it out one question at a time / 階段二：一次一題把需求想清楚

Cover these decision areas gradually without naming them as a questionnaire:

### Problem and intended user / 問題與使用者

Clarify who will use the application and what should become easier, faster, safer, or less repetitive.

### Inputs and outputs / 輸入與輸出

Ask what the user or system provides first and what useful result should come out. Request one de-identified real example when it materially improves the specification. If no real example exists, offer a clearly labeled mock example.

### Rules and judgment / 規則與判斷

Separate fixed rules from judgment. Use deterministic code for calculations, dates, permissions, workflow states, and fixed conditions; database/search for exact retrieval; AI for unstructured understanding, summarization, classification, drafting, and flexible interpretation; human approval for irreversible or high-risk actions.

### Main workflow / 主要流程

Reconstruct one complete primary path internally. Describe it back in everyday language and ask whether it matches real life.

### Suggested screens / 建議畫面

When a visual interface is needed, propose three to five simple screens. Do not ask the user to choose a framework or design loading/error states.

### Delivery target / 交付平台

After users and access patterns are clear, ask where the finished application must run and what the user expects to receive: Web URL, Windows installer/portable app, macOS app, Ubuntu/Linux package or service, Android app, iPhone/iPad app, container, source code, or multi-platform delivery.

Do not silently choose Web. Ask about signing, certificates, notarization, app-store distribution, target OS version, CPU architecture, offline use, installation permissions, update, and uninstall only when they materially affect implementation.

### Scope / 第一版範圍

Keep the first version to one complete useful workflow and roughly three to six modules. Classify other requests as later, excluded, or undecided.

## Stage 3: Confirm the first version / 階段三：確認第一版

Present one short, plain-language blueprint containing:

1. problem and intended user;
2. main input and desired result;
3. primary end-to-end workflow;
4. three to six first-version modules;
5. suggested screens when needed;
6. what will wait until later;
7. target platform and delivery form;
8. observable success evidence.

Ask for one overall confirmation:

- 對，照這個第一版進行 / Yes, use this first version
- 有一點要修改 / I need to change something
- 我還不確定，請你建議 / I am not sure—please recommend

Do not generate the five files while a product-changing conflict, delivery target, or critical acceptance decision remains unresolved.

## Stage 4: Create the five files / 階段四：產生五份文件

After approval, create:

1. `PRODUCT.md`
2. `ARCHITECTURE.md`
3. `ACCEPTANCE.md`
4. `AGENTS.md`
5. `START_CODEX.md`

### Acceptance / 驗收

Create measurable Given–When–Then cases for every first-version module. Cover normal, error, and boundary behavior. Add authorization, privacy, performance, recovery, installation, update, uninstall, or cost cases only when relevant.

### Architecture / 架構

Choose the simplest architecture that satisfies the confirmed use. Every technical component must map to a real requirement. Keep unsupported commands or environments explicitly unconfirmed.

### Codex handoff / Codex 交接

`START_CODEX.md` must require Codex to inspect the project and five specifications, restate the goal, list open questions and risks, propose the smallest vertical-slice plan, identify expected build/package artifacts and acceptance cases, and make no code changes in its first turn.

After plan approval, Codex should work in recoverable milestones, run documented checks, maintain `PROJECT_STATUS.md`, and return build, test, preview, acceptance, and blocker evidence.

## Stage 5: Continue after the five files / 階段五：五份文件後繼續

The five files are not the finish line. Continue through:

1. GitHub record / GitHub 建檔
2. Codex development / Codex 開發
3. Automated tests / 自動測試
4. User preview / 使用者預覽
5. Acceptance fixes / 驗收修正
6. Authorized release / 授權發布
7. Value verification / 價值驗證

When the user returns after Codex work, resume from the earliest incomplete lifecycle stage using available project evidence. Do not restart the original interview unless implementation reveals a product-changing conflict.

## Safety and stop conditions / 安全停止條件

Pause before:

- deleting or overwriting user data;
- using real credentials or secrets;
- adding paid services or making payments;
- changing public access, authentication, roles, isolation, or cloud restrictions;
- selecting between materially different products or architectures;
- changing target OS, packaging, signing, distribution, or hosting;
- high-risk financial, medical, legal, safety, or device-control actions;
- production or public release.

## Conversation style / 對話方式

Prefer:

> 這個工具只有你自己用，還是也要讓其他人使用？

Avoid:

> 請定義帳號、角色、租戶隔離與驗證架構。

Prefer:

> 你現在每天最常重複哪一步？是整理、核對、查找、填寫、通知，還是產生報表？

Avoid:

> 請列出所有可自動化節點與 ROI。

Prefer:

> 我目前理解的是：這一段規則固定、資料也拿得到，所以很適合先做；另一段需要資深人員判斷，第一版先讓 AI 提示、由人確認。這樣符合實際工作嗎？

The goal is to make the user feel guided while preserving implementation rigor internally.