# Light User Confirmation in Cangjie-Skill: What It Validates Between Pipeline Stages

> Discover how light user confirmation validates candidate titles for skill files in Cangjie-Skill, ensuring user agreement before resource-intensive RIA++ construction.

- Repository: [kangarooking/cangjie-skill](https://github.com/kangarooking/cangjie-skill)
- Tags: internals
- Published: 2026-08-13

---

**Light user confirmation validates the final selection of verified candidate titles that will become skill files, ensuring user agreement before the pipeline enters the resource-intensive RIA++ construction phase.**

In the `kangarooking/cangjie-skill` repository, **light user confirmation** (Chinese: *用户轻确认*) serves as a critical quality gate within the skill generation pipeline. This brief interaction occurs after the triple-verification step (stage 1.5) and before the RIA++ construction step (stage 2), confirming which candidates proceed to become actual skill files.

## What Light User Confirmation Validates

The confirmation step validates **user agreement on which verified candidates will actually be turned into skill files**. This sanity check presents two distinct lists to the user:

- **The N candidate titles** that successfully passed all three verification criteria (cross-domain relevance, predictive power, and exclusivity).
- **The M rejected candidates** accompanied by specific elimination reasons.

According to the triple-verification methodology documented in [`methodology/03-stage1.5-triple-verify.md`](https://github.com/kangarooking/cangjie-skill/blob/main/methodology/03-stage1.5-triple-verify.md) at line 50, the system displays "通过的 N 个候选标题 + 淘汰的 M 个" (the N passed candidate titles plus the M eliminated ones) and waits for user input before proceeding.

### Preventing Costly Pipeline Rework

The validation occurs at this specific junction to prevent expensive refactoring later. As implemented in the source code and documented in [`SKILL.md`](https://github.com/kangarooking/cangjie-skill/blob/main/SKILL.md) at line 108, this checkpoint "prevents massive refactoring later" by catching selection errors before the pipeline enters stages 2-4, which represent the longest and most computationally expensive portions of the skill generation process.

## Implementation in the Source Code

The requirement appears across multiple documentation files in the repository:

- **[`methodology/03-stage1.5-triple-verify.md`](https://github.com/kangarooking/cangjie-skill/blob/main/methodology/03-stage1.5-triple-verify.md)** (line 50): Defines the display of passed and rejected candidates.
- **[`SKILL.md`](https://github.com/kangarooking/cangjie-skill/blob/main/SKILL.md)** (line 108): Reinforces that this step prevents massive refactoring in subsequent stages.
- **[`methodology/00-overview.md`](https://github.com/kangarooking/cangjie-skill/blob/main/methodology/00-overview.md)** (lines 82-83): Lists this as one of two mandatory user-participation checkpoints in the overall pipeline architecture.

## User Interaction Flow

During the confirmation phase, the system generates a prompt template that categorizes candidates into the two groups. The user receives a single question such as:

> "These N titles will become skills. Is there any you'd like to keep or drop?"

The user can rescue mistakenly rejected items or prune undesired candidates from the passed list. This "light" interaction costs only a quick yes/no response plus optional modifications, but safeguards against processing incorrect titles through the RIA++ construction step.

### Confirmation Prompt Structure

The prompt follows a standardized JSON format:

```json
{
  "prompt": "以下是通过三重验证的标题（N 个）以及被淘汰的标题（M 个）。请确认这些 N 个标题将被制作成 skill，若有想保留被淘汰的标题或剔除已通过的标题，请在回复中说明。",
  "type": "light_user_confirmation"
}

```

This template explicitly lists both the verified group and the eliminated group, asking for confirmation before committing to skill file creation.

## Summary

- **Light user confirmation** validates the final selection of verified candidate titles between stage 1.5 (triple-verification) and stage 2 (RIA++ construction).
- The checkpoint displays **N passed candidates** and **M rejected candidates**, allowing users to rescue or prune items.
- This validation prevents costly rework in stages 2-4, the most resource-intensive phases of the pipeline.
- Implementation resides in [`methodology/03-stage1.5-triple-verify.md`](https://github.com/kangarooking/cangjie-skill/blob/main/methodology/03-stage1.5-triple-verify.md), [`SKILL.md`](https://github.com/kangarooking/cangjie-skill/blob/main/SKILL.md), and [`methodology/00-overview.md`](https://github.com/kangarooking/cangjie-skill/blob/main/methodology/00-overview.md).

## Frequently Asked Questions

### What specific pipeline stages does light user confirmation sit between?

Light user confirmation occurs **after stage 1.5 (triple-verification)** and **before stage 2 (RIA++ construction)**. This placement ensures that only user-approved candidates enter the lengthy construction phase, preventing wasted computation on rejected titles.

### Can users modify the candidate lists during light user confirmation?

Yes. While the primary action is a yes/no confirmation, users have the opportunity to **rescue mistakenly rejected candidates** or **prune undesired candidates** from the passed list. This flexibility ensures the final skill set matches user intent without requiring pipeline restarts.

### Why is this confirmation called "light"?

The term "light" (轻确认) refers to the **minimal interaction cost**. Unlike earlier stages that might require detailed feedback or later stages that involve complex validation, this step requires only a quick review of two lists and a simple confirmation, yet it provides significant protection against costly errors in subsequent pipeline stages.

### Where is the light user confirmation documented in the cangjie-skill repository?

The requirement appears in three key files: [`methodology/03-stage1.5-triple-verify.md`](https://github.com/kangarooking/cangjie-skill/blob/main/methodology/03-stage1.5-triple-verify.md) at line 50 defines the display logic; [`SKILL.md`](https://github.com/kangarooking/cangjie-skill/blob/main/SKILL.md) at line 108 explains the rework prevention rationale; and [`methodology/00-overview.md`](https://github.com/kangarooking/cangjie-skill/blob/main/methodology/00-overview.md) at lines 82-83 identifies it as a mandatory checkpoint.