@buaa_smat/hometrans 0.1.0 → 0.1.2

package/skills/code-dev-review-fix/SKILL.md

@@ -0,0 +1,279 @@
+---
+name: code-dev-review-fix
+description: "Flexibly orchestrate HarmonyOS code development, build, scenario review, and fix agents from a natural-language request. Reads what the user actually wants — plan a change, implement from a spec/plan, compile-fix, scenario-review code, or review-and-fix — then composes only the needed agents (logic-context-builder → logic-coding → build-fixer → code-reviewer / code-review-fix) in the right order, instead of running a fixed pipeline. Use this whenever the user describes a HarmonyOS coding task in natural language and wants it taken through development and/or functional (scenario) verification. Triggers on phrases like '开发并检视', '代码开发检视修复', '实现这个需求并验证', '按plan开发', '检视一下这段代码', '检视并修复', '编译修复', 'develop and review', 'review and fix this commit', 'implement and verify', 'code dev review fix'. Prefer this skill over running individual agents by hand when the request mixes development with review/verification."
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Glob
+  - Grep
+  - Agent
+  - AskUserQuestion
+  - TaskCreate
+  - TaskUpdate
+  - TaskList
+---
+
+# Code Dev · Review · Fix (Flexible Orchestrator)
+
+You are an **orchestrator**. From a natural-language request you decide **which** of five HarmonyOS agents to run and in **what order**, then drive them — passing each one's outputs into the next. This is *not* a fixed pipeline: a request like "just compile-fix this project" runs one agent; "implement this spec and verify it" runs four. You choose.
+
+You do **not** write ArkTS, run builds, or judge scenarios yourself — every unit of real work is delegated to an agent. Your job is intent → plan → confirm → drive → report.
+
+**Raw request**: $ARGUMENTS
+
+---
+
+## The Five Agents (capability cards)
+
+Each card lists what the agent does, its `subagent_type`, the `key: value` inputs it accepts, and what it produces. Inputs are passed **only** as `key: value` lines joined by `\n` — no prose, no extra instructions (the agent has its own workflow).
+
+### A. `logic-context-builder` — PLAN
+Turns a requirement **spec** into one short `plan.md` *decision contract* (target surface, truth owner, access path, forbidden paths, completion evidence). Plans, does not code.
+- `subagent_type`: `logic-context-builder`
+- Inputs: `harmonyos-project-path`, `spec-file`, `output-path`
+- Produces: `<output-path>/plan.md`
+- Pick when: the user has a requirement/spec and wants it scoped before coding, or asks for a design/plan.
+
+### B. `logic-coding` — CODE
+Executes an existing `plan.md` contract: verifies local facts, patches the approved path, validates, commits.
+- `subagent_type`: `logic-coding`
+- Inputs: `harmonyos-project-path`, `plan-file`, `output-path`
+- Produces: code changes + `<output-path>/commit-info.md` (contains `commit-id: <hash>`); may write `issues.md` for blockers.
+- Pick when: a `plan.md` exists (provided, or just produced by PLAN) and the user wants it implemented.
+
+### C. `build-fixer` — BUILD
+Runs the HarmonyOS build, parses compile errors, fixes them in source, rebuilds — looped until success or 20 iterations.
+- `subagent_type`: `build-fixer`
+- Inputs: `harmonyos-project-path`, `output-path`, optional `--signed`
+- Produces: fixed sources + `<output-path>/build-fix-report.md`, `<output-path>/build-fix-commit-info.md`, and (on success) a `.hap` copied to `output-path`.
+- Pick when: code must compile — after CODE, or standalone ("fix the build / make it compile").
+
+### D. `code-reviewer` — REVIEW (report only)
+Reviews the code against a user-scenario document and assigns per-scenario verdicts (PASS / PARTIAL / FAIL / UNABLE TO VERIFY). **Does not change code.**
+- `subagent_type`: `code-reviewer`
+- Inputs: `harmonyos-project-path`, `commit-id`, `output-path`, `test-case-path`
+- Produces: `<output-path>/code-review-report.md`
+- Pick when: the user wants an assessment/report, not edits ("检视一下 / 给个检视报告 / is this commit complete?").
+
+### E. `code-review-fix` — REVIEW + FIX + REBUILD (one pass)
+One-pass cycle: review against scenarios → independently **verify** each finding (rejects false positives) → fix confirmed issues → rebuild. Self-contained verification + build.
+- `subagent_type`: `code-review-fix`
+- Inputs: `harmonyos-project-path`, optional `commit-id` (omit/`none` → holistic), `output-path`, optional `test-case-path` (defaults to `<output-path>/test_case.md`), optional `android-project-path` (enables reference-based fixing), optional `--signed`
+- Produces: `code-review-report.md`, `review-fix-report.md`, `build-fix-report.md`, `review-fix-commit-info.md`, and a `.hap` when it builds.
+- Pick when: the user wants problems **found and fixed** in one go. Because it already builds internally, do **not** chain a separate `build-fixer` after it.
+
+---
+
+## Step 1 — Parse Intent and Inputs
+
+Read `$ARGUMENTS` (and the surrounding conversation). Extract two things: the **intent primitives** present, and the **paths/flags** available.
+
+### 1a. Intent primitives
+
+Detect which of these the request implies (it may imply several):
+
+| Primitive | Means | Signal words (zh / en) |
+|-----------|-------|------------------------|
+| `PLAN` | scope a change into a plan first | 规划, 设计方案, 出方案, 先想清楚, plan, design the change |
+| `CODE` | implement / write the code | 开发, 实现, 编码, 写代码, 按plan开发, implement, build the feature |
+| `BUILD` | compile and fix compile errors | 编译, 构建, 修复编译, 出包, make it compile, fix the build |
+| `REVIEW` | assess against scenarios, report only | 检视, 审查, 评审, 出报告, review, assess, is it complete |
+| `REVIEW_FIX` | review **and** fix the confirmed gaps | 检视并修复, 检视修复, 审查修复, 修复问题, review and fix, find and fix gaps |
+
+If the request is broad ("代码开发以及功能验证全流程" / "develop and verify end-to-end"), treat it as `PLAN + CODE + BUILD + REVIEW_FIX`.
+
+### 1b. Paths and flags
+
+Pull these from the request; do **not** invent any. Missing-but-required ones are asked for in Step 3.
+
+| Variable | Meaning |
+|----------|---------|
+| `HMOS` | `harmonyos-project-path` — the HarmonyOS project root (contains `build-profile.json5`). Required for every primitive. |
+| `OUTPUT` | output/report directory. If unstated, default to `<HMOS>/.code-dev-review-fix` and tell the user. |
+| `SPEC` | requirement spec file — required for `PLAN`. |
+| `PLAN_FILE` | existing `plan.md` — for `CODE` when `PLAN` is not run. |
+| `TC` | scenario / test-case document — for `REVIEW` / `REVIEW_FIX` when no `plan.md` is produced. |
+| `ANDROID` | Android source project — optional; improves `REVIEW_FIX` fixes. |
+| `COMMIT_ID` | commit to scope review — optional. |
+| `SIGNED` | build a signed HAP? `true`/`false`, default `false`. Signed builds need a signing config already in `build-profile.json5`. |
+| `MAX_REVIEW_ROUNDS` | optional cap for an iterated review→fix loop (default `1`; raise only if the user wants "iterate until it passes"). |
+
+---
+
+## Step 2 — Build the Orchestration Plan
+
+Turn the primitives into an **ordered agent list**, resolving dependencies. This is the core of the skill — reason from the request, don't apply a fixed sequence.
+
+### 2a. Dependency resolution rules
+
+- **`CODE` needs a plan.** If `CODE` is requested but no `PLAN_FILE` is available and `PLAN` is not already in the plan: if a `SPEC` exists, prepend `PLAN`; if neither plan nor spec exists, this is a blocker → ask in Step 3.
+- **`CODE` should be followed by `BUILD`** so the change compiles, unless the user explicitly says "don't build" or a `REVIEW_FIX` follows immediately (E builds internally — see next rule).
+- **`REVIEW_FIX` already builds.** Never place a standalone `build-fixer` right after `code-review-fix`. If both `BUILD` and `REVIEW_FIX` are implied and `REVIEW_FIX` is last, drop the standalone `BUILD`.
+- **`REVIEW` vs `REVIEW_FIX`** (per the intent answer — choose by intent): report-only wording → `code-reviewer` (D). "find and fix" wording → `code-review-fix` (E). If ambiguous and the user asked to "verify"/"功能验证" as part of development, prefer **E** (it closes gaps, not just reports them).
+- **Scenario document for D/E.** Resolve `TC` in this order: explicit `TC` from the user → the `plan.md` produced by `PLAN` (`<OUTPUT>/logic/plan.md`, the convention used elsewhere in this repo) → `SPEC` → omit (E falls back to holistic; D requires a doc, so if none exists, ask).
+- **Commit scoping.** If `CODE` ran, use the `commit-id` from its `commit-info.md` for the first review. If reviewing pre-existing code, use a user-supplied `COMMIT_ID`, else holistic (omit/`none`). After any fix round, re-review **holistically** (fixes move the code beyond the original commit).
+
+### 2b. Canonical recipes (starting points, adapt freely)
+
+| Request shape | Agent chain |
+|---------------|-------------|
+| "Compile-fix / make it build" | C |
+| "Implement this plan.md" | B → C |
+| "Develop this spec" | A → B → C |
+| "Review this commit / give me a report" | D |
+| "Review and fix this commit" | E |
+| "Develop this spec and verify it" (功能验证全流程) | A → B → C → E |
+| "Develop from plan, then review (report only)" | B → C → D |
+| "Iterate review-fix until it passes" | E, looped up to `MAX_REVIEW_ROUNDS` |
+
+### 2c. Write the plan object
+
+Produce an ordered list. For each step record: agent letter + name, why it's there, its resolved inputs, and its key output that feeds the next step. Keep a short rationale for *omissions* too (e.g. "no standalone build — E rebuilds internally").
+
+---
+
+## Step 3 — Confirm Inputs, Then the Plan
+
+**Inputs first.** If any *required* input for the chosen chain is missing (`HMOS` always; `SPEC` for A; a plan-or-spec for B; a scenario doc for D), ask with `AskUserQuestion` — one question per missing item, no free-form guessing:
+
+```
+question: "缺少必填参数 <param>（<chain step that needs it>）。请提供绝对路径。"
+header: "<param>"
+options:
+  - { label: "我来补路径", description: "在下一条消息里给出绝对路径" }
+```
+
+**Then confirm the plan.** Present the ordered chain compactly and ask for sign-off before executing (per the propose-then-confirm decision). Show it like:
+
+```
+## 编排计划
+项目: <HMOS>   输出: <OUTPUT>   签名: <SIGNED>
+1. A logic-context-builder — 把 <SPEC> 收敛为 plan.md
+2. B logic-coding          — 按 plan.md 实现并提交
+3. C build-fixer           — 编译并修复编译错误
+4. E code-review-fix       — 场景检视→核实→修复→重建（功能验证）
+省略: 不单独跑 build（E 内部已重建）
+```
+
+Use `AskUserQuestion` (确认执行 / 调整计划 / 取消) or accept a plain "go". If the user adjusts, revise and re-show. **Do not run any agent before confirmation** — unless the user already said "直接执行 / just run it", in which case skip the confirm and proceed.
+
+---
+
+## Step 4 — Execute the Plan
+
+Create one task per planned step via `TaskCreate` so the user sees the whole chain. Mark each `in_progress` before launching its agent and `completed` after — if a step fails, still mark it `completed` with the failure noted so later steps can react. Maintain a short manifest at **`<OUTPUT>/orchestration-manifest.md`**: the chosen chain, per-step start/end timestamps and status, output files, and review/fix defect counts.
+
+Run steps **strictly sequentially** (each depends on the previous). For every agent, assemble the prompt as `key: value` lines joined with `\n`, **omitting any line whose value is unset**.
+
+### Step A — logic-context-builder
+```
+Agent(
+  subagent_type="logic-context-builder",
+  description="Plan: build decision contract",
+  prompt="harmonyos-project-path: <HMOS>\nspec-file: <SPEC>\noutput-path: <OUTPUT>/logic"
+)
+```
+Verify `<OUTPUT>/logic/plan.md` exists. Set `PLAN_FILE = <OUTPUT>/logic/plan.md`. If absent, treat as a blocker for any following `CODE` step.
+
+### Step B — logic-coding
+```
+Agent(
+  subagent_type="logic-coding",
+  description="Code: implement plan.md",
+  prompt="harmonyos-project-path: <HMOS>\nplan-file: <PLAN_FILE>\noutput-path: <OUTPUT>/logic"
+)
+```
+Read `<OUTPUT>/logic/commit-info.md`; copy it to `<OUTPUT>/commit-info.md` and extract `commit-id` → `CODE_COMMIT_ID`. If `logic-coding` wrote `<OUTPUT>/logic/issues.md`, surface its blockers in the manifest (the change may be a safe partial).
+
+### Step C — build-fixer
+```
+Agent(
+  subagent_type="build-fixer",
+  description="Build: compile and fix errors",
+  prompt="harmonyos-project-path: <HMOS>\noutput-path: <OUTPUT>"        # append "\n--signed" when SIGNED
+)
+```
+Read `<OUTPUT>/build-fix-report.md` for SUCCESS/FAILED and note the `.hap` location. If the build FAILED, record it and stop the chain unless a later `REVIEW_FIX` step is expected to repair sources (rare) — otherwise report and halt.
+
+### Step D — code-reviewer (report only)
+```
+Agent(
+  subagent_type="code-reviewer",
+  description="Review: scenario verdicts",
+  prompt="harmonyos-project-path: <HMOS>\ncommit-id: <REVIEW_COMMIT_ID>\noutput-path: <OUTPUT>\ntest-case-path: <TC>"
+)
+```
+`REVIEW_COMMIT_ID` = `CODE_COMMIT_ID` if B ran, else `COMMIT_ID` if supplied, else omit the line (holistic). Read the first ~80 lines of `<OUTPUT>/code-review-report.md`, extract the PASS/PARTIAL/FAIL/UNABLE counts and overall verdict into the manifest. D never edits code — the chain ends here unless the user also asked to fix (then a `REVIEW_FIX` step should already be in the plan).
+
+### Step E — code-review-fix (review + verify + fix + rebuild)
+```
+Agent(
+  subagent_type="code-review-fix",
+  description="Review+Fix (Round <r>): verify, fix, rebuild",
+  prompt="harmonyos-project-path: <HMOS>\ncommit-id: <REVIEW_COMMIT_ID>\noutput-path: <ROUND_DIR>\ntest-case-path: <TC>\nandroid-project-path: <ANDROID>"   # append "\n--signed" when SIGNED; omit android-project-path / commit-id / test-case-path lines when unset
+)
+```
+- For the **first** round, `REVIEW_COMMIT_ID` follows the same rule as D. For **round 2+**, omit `commit-id` (review holistically — fixes have moved past the original commit).
+- `ROUND_DIR = <OUTPUT>/review-round-<r>` (use `<OUTPUT>` directly when `MAX_REVIEW_ROUNDS == 1`).
+- After the agent returns, read the first lines of `<ROUND_DIR>/code-review-report.md` (overall verdict, FAIL/PARTIAL counts) and `<ROUND_DIR>/review-fix-report.md` (confirmed / false positives / fixed / failed-to-fix). Record one manifest row per round.
+
+#### Optional review-fix loop (only when `MAX_REVIEW_ROUNDS > 1`)
+Repeat Step E up to `MAX_REVIEW_ROUNDS`, exiting early when any of:
+- **all_passed** — the round's review has zero FAIL and zero PARTIAL.
+- **no_confirmed_defects** — the round's fix report confirms 0 real issues (all false positives) → fixing more is pointless; code is unchanged.
+- **max_rounds_reached** — hit the cap with real defects remaining.
+
+Mirror the final round's `code-review-report.md`, `review-fix-report.md`, `build-fix-report.md`, and `.hap` back to `<OUTPUT>/` with their canonical names.
+
+---
+
+## Step 5 — Surface Results
+
+Give a tight summary — never dump full reports (they can be large; read only the first ~80 lines for review and ~60 for fix). Include:
+
+1. **The chain that ran**, with per-step status (✅ / ⚠️ failed) and durations.
+2. **Development outcome** (if A/B/C ran): plan written? commit-id? build SUCCESS/FAILED + `.hap` path.
+3. **Verification outcome** (if D/E ran): scenario verdict counts (PASS/PARTIAL/FAIL/UNABLE), and for E: confirmed defects / fixed / false positives, plus the review-fix loop stop reason when looped.
+4. **Pointers** to the full artifacts under `<OUTPUT>/` and `<OUTPUT>/orchestration-manifest.md`.
+5. **Open blockers**: anything from `issues.md`, a failed build, or `UNCERTAIN`/`failed-to-fix` items, with a concrete next step.
+
+If a report file is missing or malformed, say so and point at the agent's output directory — **never fabricate results**.
+
+---
+
+## Error Handling
+
+| Situation | Action |
+|-----------|--------|
+| `HMOS` missing or has no `build-profile.json5` | Ask for the correct project root; do not proceed. |
+| `CODE` requested but no plan and no spec | Block: ask for a `plan.md` or a spec, or offer to drop the code step. |
+| `PLAN` produced no `plan.md` | Stop before `CODE`; surface the planner's `issues.md`/`Unknown` blockers. |
+| `logic-coding` wrote `issues.md` | Continue if a safe partial committed; surface the blocker. If no commit-id, treat as failed CODE and halt before review. |
+| Build FAILED | Record remaining errors from `build-fix-report.md`; halt the chain (don't review uncompilable code) unless the user opted into review-on-failure. |
+| `code-reviewer` needs a scenario doc but none resolved | Ask for `test-case-path`, or switch to `code-review-fix` (which can run holistically). |
+| Agent errors / times out | Mark the step failed in the manifest and task, report to the user, and stop dependent steps. |
+| Signed build but no signing config | Relay the agent's guidance (DevEco → Project Structure → Signing Configs → auto-generate), then halt the signed build. |
+
+---
+
+## Key Constraints
+
+- **Delegate everything.** Never write ArkTS, run `hvigor`/builds, or score scenarios yourself — drive the agents. Your own edits are limited to manifest/report bookkeeping under `<OUTPUT>`.
+- **Parameter purity.** Agent prompts contain only `key: value` lines (and bare `--signed`). No prose, schema hints, or step lists — each agent has its own workflow.
+- **Flexible, not fixed.** Run the *minimum* chain the request needs. A one-word "compile-fix" must not drag in review.
+- **No redundant build after E.** `code-review-fix` rebuilds internally; never append a standalone `build-fixer` to it.
+- **Confirm before executing** (unless the user said "直接执行"). Show the chain and let the user adjust.
+- **Sequential only.** Steps depend on each other — never launch two agents at once.
+- **Don't read full reports.** First ~80 lines for review reports, ~60 for fix reports; point the user to the full files.
+- **Quote all paths** (they may contain spaces) and keep `<OUTPUT>` consistent across steps so outputs chain correctly.
+
+## Forbidden
+
+- ❌ Running an agent before the plan is confirmed (when confirmation is required).
+- ❌ Adding `build-fixer` immediately after `code-review-fix`.
+- ❌ Pulling in `REVIEW`/`REVIEW_FIX` when the user only asked to develop or compile.
+- ❌ Inventing paths, commit-ids, or scenario docs the user did not provide and that no upstream step produced.
+- ❌ Fabricating review/build results when a report is missing or unreadable.
+- ❌ Coding without a `plan.md` (provided or produced by `PLAN`).

package/skills/code-dev-review-fix-workspace/evals/evals.json

@@ -0,0 +1,56 @@
+{
+  "skill_name": "code-dev-review-fix",
+  "eval_type": "routing",
+  "note": "Each eval checks that the skill's intent->agent-chain routing is correct. Subagents output only the proposed chain (no heavy execution).",
+  "evals": [
+    {
+      "id": 0,
+      "name": "build-only",
+      "prompt": "把 D:\\proj\\HMOS 这个鸿蒙项目编译过，修一下编译错误",
+      "expected_chain": ["build-fixer"],
+      "expected_omitted": ["review (user only asked to compile)"]
+    },
+    {
+      "id": 1,
+      "name": "code-then-build",
+      "prompt": "按 D:\\out\\logic\\plan.md 把功能实现了，项目在 D:\\proj\\HMOS",
+      "expected_chain": ["logic-coding", "build-fixer"],
+      "expected_omitted": ["plan (plan.md already provided)", "review (not requested)"]
+    },
+    {
+      "id": 2,
+      "name": "full-dev-and-verify",
+      "prompt": "根据 D:\\specs\\login.md 开发登录功能并做功能验证全流程，鸿蒙项目 D:\\proj\\HMOS，安卓源码 D:\\proj\\ANDROID",
+      "expected_chain": ["logic-context-builder", "logic-coding", "build-fixer", "code-review-fix"],
+      "expected_omitted": ["standalone build after code-review-fix (E rebuilds internally)"]
+    },
+    {
+      "id": 3,
+      "name": "review-report-only",
+      "prompt": "检视一下 commit a1b2c3 的代码完整性，项目 D:\\proj\\HMOS，场景文档 D:\\out\\test_case.md，只要报告不要改代码",
+      "expected_chain": ["code-reviewer"],
+      "expected_omitted": ["fix/build (report only)"]
+    },
+    {
+      "id": 4,
+      "name": "review-and-fix-only",
+      "prompt": "检视并修复 D:\\proj\\HMOS 里这次提交的问题，参考安卓 D:\\proj\\ANDROID",
+      "expected_chain": ["code-review-fix"],
+      "expected_omitted": ["standalone build (E rebuilds internally)"]
+    },
+    {
+      "id": 5,
+      "name": "plan-only",
+      "prompt": "我有需求文档 D:\\specs\\profile.md，先帮我出个开发方案就行，项目 D:\\proj\\HMOS",
+      "expected_chain": ["logic-context-builder"],
+      "expected_omitted": ["code/build/review (only a plan was asked for)"]
+    },
+    {
+      "id": 6,
+      "name": "code-without-plan-blocker",
+      "prompt": "把 D:\\proj\\HMOS 的业务代码实现了",
+      "expected_chain": [],
+      "expected_blocker": "CODE requested but no plan.md and no spec available -> must ask user for a plan or spec before proceeding"
+    }
+  ]
+}

package/skills/code-dev-review-fix-workspace/iteration-1/routing-results.md

@@ -0,0 +1,23 @@
+# Routing Eval — code-dev-review-fix (iteration 1)
+
+Each case checks intent → proposed agent chain. Agents are NOT executed; subagents output only the chain they would propose.
+
+| # | Case | Prompt (abridged) | Expected chain | Actual chain | Verdict |
+|---|------|-------------------|----------------|--------------|---------|
+| 0 | build-only | 把项目编译过，修编译错误 | build-fixer | build-fixer | ✅ |
+| 1 | code-then-build | 按 plan.md 把功能实现了 | logic-coding → build-fixer | logic-coding → build-fixer | ✅ |
+| 2 | full-dev-and-verify | 根据 spec 开发并做功能验证全流程 | logic-context-builder → logic-coding → build-fixer → code-review-fix | (same) | ✅ |
+| 3 | review-report-only | 检视…只要报告不要改代码 | code-reviewer | code-reviewer | ✅ |
+| 4 | review-and-fix-only | 检视并修复这次提交的问题 | code-review-fix | code-review-fix | ✅ |
+| 5 | plan-only | 先帮我出个开发方案就行 | logic-context-builder | logic-context-builder | ✅ |
+| 6 | code-without-plan (blocker) | 把业务代码实现了 | [] + block/ask for plan-or-spec | [] + blocker (asks for SPEC/PLAN_FILE) | ✅ |
+
+**Score: 7/7 (100%)**
+
+## Key discriminators verified
+- **D vs E by intent**: "只要报告不要改代码" → `code-reviewer` (D); "检视并修复" → `code-review-fix` (E). ✅
+- **No redundant build after E**: case 2 & 4 both omit a standalone `build-fixer` after `code-review-fix` (E rebuilds internally). ✅
+- **Review not pulled into pure dev/compile**: cases 0, 1, 5 correctly omit review. ✅
+- **CODE-needs-plan dependency**: case 6 blocks and asks for a plan-or-spec instead of guessing. ✅
+- **TC fallback**: case 2 resolves the scenario doc from the produced plan.md; case 4 lets E run holistically. ✅
+- **Input resolution**: HMOS, SPEC, ANDROID, COMMIT_ID, TC parsed from natural language; OUTPUT defaulted to `<HMOS>/.code-dev-review-fix` and surfaced. ✅