feat: add organized-feedback skill with docs and validation

skills/organized-feedback/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: organized-feedback
+description: Organize PR review comments into structured feedback with coverage auditing and unknown-item handling. Use when converting gitea-pr-review Markdown into a user-specified output document.
+---
+
+# Organized Feedback
+
+## Overview
+Use this skill to turn a single PR review document into organized feedback.
+
+## Inputs
+- PR markdown
+- output path
+
+## Hard Gates
+- Do not write final output until user provides output path.
+- Coverage audit must run in interaction.
+- Coverage audit content must not be written to final document.
+- If unknown count is greater than 3, pause and request user permission.
+
+## Classification Taxonomy
+- `question`: a review item that asks for clarification, confirmation, or intent.
+- `supplement`: a review item that adds missing context, examples, or supporting detail without changing the requested behavior.
+- `request-for-change`: a review item that asks for a code, behavior, or design change.
+- `unknown`: a review item that cannot be classified confidently after one reflection pass.
+
+## RFC Subfields
+When a review item is classified as `request-for-change`, annotate it with:
+- `Change-Scope`: how broad the requested change is.
+  - `local`
+  - `implement`
+  - `api-change`
+  - `requirement-change`
+- `Necessity`: how strongly the change is required.
+  - `nice-to-have`
+  - `should-fix`
+  - `must-fix`
+
+## Processing Flow
+1. Read the PR markdown and identify each review comment or feedback unit.
+2. Classify each unit as `question`, `supplement`, `request-for-change`, or `unknown`.
+3. If a unit clearly contains multiple intents, split it into separate items before grouping.
+4. If multiple units express the same intent, merge them into one grouped item.
+5. For each `request-for-change`, assign `Change-Scope` and `Necessity`.
+6. Run an interaction-only coverage audit using `All-Source-Refs`, `Covered-Source-Refs`, and `Missing-Source-Refs`.
+7. Re-audit until `Missing-Source-Refs` is empty.
+8. Apply the unknown reflection rule once before finalizing any `unknown` item.
+9. If the count of `unknown` items is greater than 3, stop and request user permission before proceeding.
+
+## Interaction-Only Coverage Audit
+The coverage audit must be performed only against the interaction content, not the final document.
+
+Track these lists explicitly:
+- `All-Source-Refs`: every source reference found in the interaction
+- `Covered-Source-Refs`: refs that are represented in the organized output
+- `Missing-Source-Refs`: refs that are present in the interaction but not yet covered
+
+Source reference format rule:
+- Use `R` + PR numbering path from the source markdown.
+- Example mapping: `Comment 42.1.1` -> `R42.1.1`, `Reply 42.1.1.1` -> `R42.1.1.1`.
+
+Audit rules:
+- Compare only against interaction content.
+- Re-audit after every grouping pass until `Missing-Source-Refs` is empty.
+- Do not treat the final document as an audit source.
+
+## Unknown Handling
+- unknown（>=1），必须执行一次反思复判
+- Use one reflection pass to decide whether an item can be reclassified into `question`, `supplement`, or `request-for-change`.
+- If it remains `unknown`, keep it in the `Unknown Items` section.
+- If the number of `unknown` items is greater than 3, request user permission before continuing.
+
+## Final File Format
+Write only the organized output content:
+- `Organized Feedback`
+- optional `Unknown Items`
+
+Do not write the coverage audit into the final output file.
+
+## Output Discipline
+- Preserve the user-specified output path.
+- Keep the final file limited to the agreed format.
+- Do not add extra audit notes, scratch work, or intermediate classification logs to the final file.

skills/organized-feedback/examples/input-pr-review.md

@@ -0,0 +1,45 @@
+# org/repo `#42` Improve transaction handling
+
+## Review 42.1 (COMMENT)
+> reviewer-a
+
+### Comment 42.1.1
+service/order.rs:87
+reviewer-a:
+```md
+为什么要在循环里每次开启事务？
+```
+
+### Reply 42.1.1.1
+service/order.rs:87
+author:
+```md
+为了保证每个子任务互不影响。
+```
+
+## Review 42.2 (REQUEST_CHANGES)
+> reviewer-b
+
+### Comment 42.2.1
+api/order.ts:15
+reviewer-b:
+```md
+建议把 `createOrder(input)` 改成 `createOrder(ctx, input)`，否则审计信息拿不到。
+```
+
+## Review 42.3 (COMMENT)
+> reviewer-c
+
+### Comment 42.3.1
+service/order.rs:120
+reviewer-c:
+```md
+这里的缓存失效策略是不是太激进了？
+```
+
+### Reply 42.3.1.1
+service/order.rs:120
+author:
+```md
+按之前的约定处理。
+```

skills/organized-feedback/examples/output-organized-feedback.md

@@ -0,0 +1,24 @@
+## Organized Feedback
+
+### Item 1
+- Type: question
+- Summary: reviewer-a 询问为什么在循环里重复开启事务。
+- Rationale: 该意见在确认设计意图，不是直接要求代码修改。
+- Source-Refs: R42.1.1
+- Raw-Excerpts: "为什么要在循环里每次开启事务？"
+
+### Item 2
+- Type: request-for-change
+- Change-Scope: api-change
+- Necessity: should-fix
+- Summary: reviewer-b 建议把 `createOrder(input)` 改成 `createOrder(ctx, input)` 以便传递审计信息。
+- Rationale: 该意见明确要求修改 API 签名，影响调用方。
+- Source-Refs: R42.2.1
+- Raw-Excerpts: "建议把 `createOrder(input)` 改成 `createOrder(ctx, input)`，否则审计信息拿不到。"
+
+## Unknown Items
+
+### Unknown 1
+- Source-Refs: R42.3.1, R42.3.1.1
+- Reason: 回复只是“按之前的约定处理”，缺少足够上下文来判断是接受建议、补充说明还是保持现状。
+- Needed-Info: 需要确认这条回复是否在响应审阅意见，还是仅说明已有实现策略。