uplift-model-task-spec

Name: uplift-model-task-spec
Author: QFIN-tech

40stars16forks

How to install uplift-model-task-spec?

qfin-tech/model-evo/uplift-model-task-spec

$npx -y skills add QFIN-tech/model-evo --skill uplift-model-task-spec

Installs into the current project.

Summary

由 model-task-routing 判定 task_type=uplift 后，或用户已明确指定这是 uplift/增益建模任务且需要定义任务配置时使用；负责收集并确认结构化 task_config。写入 confirmed artifact 前，必须由用户明确提供字段名和值。不要用于通用建模路由、字段发现、样本校验、特征分析、模型训练、评估、调参、比较或报告生成。

Files · 1

View on GitHub

SKILL.md

1	# 任务定义
2
3	使用本 skill 为一次增益（uplift）建模运行定义并确认 `task_config`。本 self-contained 版本只负责工作流入口：判断任务是否适用、收集字段映射、调用确定性运行器生成草稿，并在用户明确确认后确认 artifact。
4
5	## 1. 输入依赖
6
7	适用：已由 `model-task-routing` 判定为 uplift，或用户明确表达“uplift / 增益 / 干预相对不干预的增量效果 / 有 treatment-control 实验数据”等 uplift 语义，并需要生成或澄清 `task_config`。
8
9	不支持：用户明确要求非 uplift 的分类、聚类、报告生成或归因分析；用户要做字段发现、样本校验、特征分析、训练、评估、调参或模型比较。
10
11	### 从 model-task-routing 接力
12
13	当本 skill 由 `model-task-routing` 拉起时，调用方可以把 routing JSON 作为 `routing_input` 传入：
14
15	```json
16	{
17	"task_type": "uplift",
18	"routing_basis": {
19	"q1_target": "用户原话描述的预测目标",
20	"q2_intervention": "yes \| no \| uncertain",
21	"q3_experiment_data": "yes \| no"
22	},
23	"user_raw_request": "用户最初的建模诉求原话",
24	"routed_at": "路由时间戳 YYYY-MM-DD HH:MM:SS"
25	}
26	```
27
28	承接规则：
29
30	- 启动时如果提供 `routing_input`，必须校验 `routing_input.task_type == "uplift"`；否则不要生成 uplift `task_config`。
31	- `routing_basis` 中非 null 信息视为已知条件，不重复询问 routing 阶段的 Q1/Q2/Q3。
32	- `user_raw_request` 和 `routing_basis` 可用于补充 `business_context`，并必须在 task_config artifact 的 `routing` 字段中保留溯源。
33	- routing 判到 uplift 只表示进入本 skill 做入口复核；不代表样本已满足 uplift 建模条件。
34
35	本 skill 只做轻量入口复核：
36
37	```text
38	1. 业务目标是否确认为“干预相对不干预的增量效果”，而不是“预测被干预人群响应概率”？
39	2. treatment/control 的字段和值是否能由用户明确给出？
40	```
41
42	如果第 1 点不成立，不写 confirmed uplift `task_config`，建议转 classification。
43	如果第 2 点不成立，暂停在 `task-spec`，要求用户补充字段和值。
44	样本量是否充足、treatment/control 是否支撑切分、两组是否同质、特征质量是否可用，交给后续 `uplift-model-sample-preparation`、`uplift-model-sample-homogeneity-check` 和 `uplift-model-feature-quality-analysis` 判断。
45
46	### 对话规则
47
48	对于不熟悉 uplift 的用户，先简要解释：
49
50	- 干预是业务动作、触达或暴露。
51	- 对照是可比较的未干预状态。
52	- 结果变量是要衡量的业务结果。
53	- 增益是干预相对对照对结果变量产生的增量效果。
54
55	随后要求用户提供实际 CSV 路径、列名和值，以及本次建模运行目录。不要从长字段列表中推断列，不要为了字段发现而扫描或展示完整表头。
56
57	### 必需输入
58
59	只有在以下值都已获得后，才调用运行器：
60
61	```text
62	data_ref
63	output_dir
64	outcome_column
65	outcome_type: binary \| continuous
66	treatment_column
67	treatment_value
68	control_value
69	```
70
71	始终询问以下可选上下文字段，但允许为 `null`：
72
73	```text
74	unit_id_column
75	time_column
76	business_context
77	```
78
79	## 2. 执行入口
80
81	使用确定性运行器：
82
83	```bash
84	python <skill-dir>/scripts/run.py --input - --output-dir <output_dir>
85	```
86
87	`--output-dir` 必须是已存在的项目运行目录 `run_dir`，例如 `runs/{YYYYMMDD-HHMMSS}-{project_slug}`。runner 不负责选择工作区、不创建 `runs_root`，也不自动创建或恢复历史 `run_dir`。
88
89	请求 JSON 必须通过 stdin 传入。中文 `payload` 走 stdin 时，调用方必须明确使用 UTF-8；不要依赖 Windows、PowerShell 或 Python 默认文本编码。
90
91	stdout 和落盘 result JSON 都必须包含 `status`、`summary`、`outputs`、`issues`、`next_steps`。当前 action 的 result 文件路径必须读取 `outputs.result_path`；flow folder 必须读取 `outputs.flow_dir`。不要读取或传播顶层 `flow_dir`、`result_path`、`warnings`。outputs 中的产物路径作为下游接力 contract，按 `run_dir` 相对路径记录和传递。
92
93	支持的 actions：
94
95	```text
96	draft_task_config
97	confirm_artifact
98	```
99
100	一次业务 skill flow 会写入一个 timestamped flow folder。`draft_task_config` 创建该 folder，后续 `confirm_artifact` 复用同一个 folder：
101
102	```text
103	{run_dir}/uplift-model-task-spec/{timestamp}_task_spec/
104	inputs/
105	0001_draft_task_config.request.json
106	0002_confirm_artifact.request.json
107	results/
108	0001_draft_task_config.result.json
109	0002_confirm_artifact.result.json
110	artifacts/
111	task_config.draft.v1.json
112	task_config.confirmed.v1.json
113	_flow_manifest.json
114	_flow_log.jsonl
115	report.md
116	```
117
118	## 3. Actions 与参数说明
119
120	### draft_task_config
121
122	- 输入：必需 `data_ref`、`output_dir`、`outcome_column`、`outcome_type`、`treatment_column`、`treatment_value`、`control_value`。
123	- 可选输入：`unit_id_column`、`time_column`、`business_context`、`routing_input`。
124	- 输出：草稿 `task_config_path`、`flow_dir`、`result_path` 和 `confirmation_summary`。
125
126	`draft_task_config` 只读取 CSV 表头并检查指定列是否存在，不读取数据值，不计算统计量。
127
128	`draft_task_config` 可接收可选 `routing_input`。runner 只校验其 `task_type` 并把原始 routing 信息写入 artifact 顶层 `routing` 字段；不会把 `routing_input` 混入 `payload` 业务字段。
129
130	### confirm_artifact
131
132	确认调用示例：
133
134	```json
135	{
136	"action": "confirm_artifact",
137	"flow_dir": "<draft_result.outputs.flow_dir>",
138	"source_draft_path": "<draft_result.outputs.task_config_path>",
139	"artifact_kind": "task_config",
140	"confirmed_by": "user"
141	}
142	```
143
144	`confirm_artifact` 只确认已有草稿，不接受 `payload` 修改。如果用户要求“确认并修改”，先重新调用 `draft_task_config`，展示新的确认摘要，然后再次请求确认。
145
146	### Flow 规则
147
148	一次业务上的 task definition flow 从 `draft_task_config` 开始，到 `confirm_artifact` 结束。
149
150	- 调用 `draft_task_config` 时，runner 会创建新的 `flow_dir`。
151	- `draft_task_config` 返回后，必须保留 `result.outputs.flow_dir` 和 `result.outputs.task_config_path`。
152	- 后续 `confirm_artifact` 必须复用同一个 `flow_dir`，并使用同一个 flow 下的 draft artifact。
153	- 不要为 `confirm_artifact` 创建新的 flow。
154	- 不接受 `source_draft_ref` 或其他旧 `_ref` 输入；收到旧字段时，runner 会返回 `needs_input`，并在 `issues` / `next_steps` 中给出对应 `_path` 字段建议。
155	- 不要使用 `latest`、`current`、`active` 或目录扫描来猜测 flow。
156	- 如果找不到上一轮返回的 `flow_dir` 或 `task_config_path`，应向用户说明需要重新运行 `draft_task_config`，或请用户提供草稿路径。
157
158	## 4. 输出产物
159
160	典型输出目录：
161
162	```text
163	{run_dir}/uplift-model-task-spec/{timestamp}_task_spec/
164	inputs/
165	0001_draft_task_config.request.json
166	0002_confirm_artifact.request.json
167	results/
168	0001_draft_task_config.result.jso

QFIN-techPublisher · 22 listings

Preview

QFIN-tech/model-evo

# 任务定义

使用本 skill 为一次增益（uplift）建模运行定义并确认 `task_config`。本 self-contained 版本只负责工作流入口：判断任务是否适用、收集字段映射、调用确定性运行器生成草稿，并在用户明确确认后确认 artifact。

## 1. 输入依赖

适用：已由 `model-task-routing` 判定为 uplift，或用户明确表达“uplift / 增益 / 干预相对不干预的增量效果 / 有 treatment-control 实验数据”等 uplift 语义，并需要生成或澄清 `task_config`。

RepoQFIN-tech/model-evo

LicenseMIT

TypeSkills

CategoryData

UpdatedJul 2026

Repo stars40

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

uplift-model-task-spec

40stars16forks

View on GitHub

How to install uplift-model-task-spec?

qfin-tech/model-evo/uplift-model-task-spec

$npx -y skills add QFIN-tech/model-evo --skill uplift-model-task-spec

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# 任务定义
2
3	使用本 skill 为一次增益（uplift）建模运行定义并确认 `task_config`。本 self-contained 版本只负责工作流入口：判断任务是否适用、收集字段映射、调用确定性运行器生成草稿，并在用户明确确认后确认 artifact。
4
5	## 1. 输入依赖
6
7	适用：已由 `model-task-routing` 判定为 uplift，或用户明确表达“uplift / 增益 / 干预相对不干预的增量效果 / 有 treatment-control 实验数据”等 uplift 语义，并需要生成或澄清 `task_config`。
8
9	不支持：用户明确要求非 uplift 的分类、聚类、报告生成或归因分析；用户要做字段发现、样本校验、特征分析、训练、评估、调参或模型比较。
10
11	### 从 model-task-routing 接力
12
13	当本 skill 由 `model-task-routing` 拉起时，调用方可以把 routing JSON 作为 `routing_input` 传入：
14
15	```json
16	{
17	"task_type": "uplift",
18	"routing_basis": {
19	"q1_target": "用户原话描述的预测目标",
20	"q2_intervention": "yes \| no \| uncertain",
21	"q3_experiment_data": "yes \| no"
22	},
23	"user_raw_request": "用户最初的建模诉求原话",
24	"routed_at": "路由时间戳 YYYY-MM-DD HH:MM:SS"
25	}
26	```
27
28	承接规则：
29
30	- 启动时如果提供 `routing_input`，必须校验 `routing_input.task_type == "uplift"`；否则不要生成 uplift `task_config`。
31	- `routing_basis` 中非 null 信息视为已知条件，不重复询问 routing 阶段的 Q1/Q2/Q3。
32	- `user_raw_request` 和 `routing_basis` 可用于补充 `business_context`，并必须在 task_config artifact 的 `routing` 字段中保留溯源。
33	- routing 判到 uplift 只表示进入本 skill 做入口复核；不代表样本已满足 uplift 建模条件。
34
35	本 skill 只做轻量入口复核：
36
37	```text
38	1. 业务目标是否确认为“干预相对不干预的增量效果”，而不是“预测被干预人群响应概率”？
39	2. treatment/control 的字段和值是否能由用户明确给出？
40	```
41
42	如果第 1 点不成立，不写 confirmed uplift `task_config`，建议转 classification。
43	如果第 2 点不成立，暂停在 `task-spec`，要求用户补充字段和值。
44	样本量是否充足、treatment/control 是否支撑切分、两组是否同质、特征质量是否可用，交给后续 `uplift-model-sample-preparation`、`uplift-model-sample-homogeneity-check` 和 `uplift-model-feature-quality-analysis` 判断。
45
46	### 对话规则
47
48	对于不熟悉 uplift 的用户，先简要解释：
49
50	- 干预是业务动作、触达或暴露。
51	- 对照是可比较的未干预状态。
52	- 结果变量是要衡量的业务结果。
53	- 增益是干预相对对照对结果变量产生的增量效果。
54
55	随后要求用户提供实际 CSV 路径、列名和值，以及本次建模运行目录。不要从长字段列表中推断列，不要为了字段发现而扫描或展示完整表头。
56
57	### 必需输入
58
59	只有在以下值都已获得后，才调用运行器：
60
61	```text
62	data_ref
63	output_dir
64	outcome_column
65	outcome_type: binary \| continuous
66	treatment_column
67	treatment_value
68	control_value
69	```
70
71	始终询问以下可选上下文字段，但允许为 `null`：
72
73	```text
74	unit_id_column
75	time_column
76	business_context
77	```
78
79	## 2. 执行入口
80
81	使用确定性运行器：
82
83	```bash
84	python <skill-dir>/scripts/run.py --input - --output-dir <output_dir>
85	```
86
87	`--output-dir` 必须是已存在的项目运行目录 `run_dir`，例如 `runs/{YYYYMMDD-HHMMSS}-{project_slug}`。runner 不负责选择工作区、不创建 `runs_root`，也不自动创建或恢复历史 `run_dir`。
88
89	请求 JSON 必须通过 stdin 传入。中文 `payload` 走 stdin 时，调用方必须明确使用 UTF-8；不要依赖 Windows、PowerShell 或 Python 默认文本编码。
90
91	stdout 和落盘 result JSON 都必须包含 `status`、`summary`、`outputs`、`issues`、`next_steps`。当前 action 的 result 文件路径必须读取 `outputs.result_path`；flow folder 必须读取 `outputs.flow_dir`。不要读取或传播顶层 `flow_dir`、`result_path`、`warnings`。outputs 中的产物路径作为下游接力 contract，按 `run_dir` 相对路径记录和传递。
92
93	支持的 actions：
94
95	```text
96	draft_task_config
97	confirm_artifact
98	```
99
100	一次业务 skill flow 会写入一个 timestamped flow folder。`draft_task_config` 创建该 folder，后续 `confirm_artifact` 复用同一个 folder：
101
102	```text
103	{run_dir}/uplift-model-task-spec/{timestamp}_task_spec/
104	inputs/
105	0001_draft_task_config.request.json
106	0002_confirm_artifact.request.json
107	results/
108	0001_draft_task_config.result.json
109	0002_confirm_artifact.result.json
110	artifacts/
111	task_config.draft.v1.json
112	task_config.confirmed.v1.json
113	_flow_manifest.json
114	_flow_log.jsonl
115	report.md
116	```
117
118	## 3. Actions 与参数说明
119
120	### draft_task_config
121
122	- 输入：必需 `data_ref`、`output_dir`、`outcome_column`、`outcome_type`、`treatment_column`、`treatment_value`、`control_value`。
123	- 可选输入：`unit_id_column`、`time_column`、`business_context`、`routing_input`。
124	- 输出：草稿 `task_config_path`、`flow_dir`、`result_path` 和 `confirmation_summary`。
125
126	`draft_task_config` 只读取 CSV 表头并检查指定列是否存在，不读取数据值，不计算统计量。
127
128	`draft_task_config` 可接收可选 `routing_input`。runner 只校验其 `task_type` 并把原始 routing 信息写入 artifact 顶层 `routing` 字段；不会把 `routing_input` 混入 `payload` 业务字段。
129
130	### confirm_artifact
131
132	确认调用示例：
133
134	```json
135	{
136	"action": "confirm_artifact",
137	"flow_dir": "<draft_result.outputs.flow_dir>",
138	"source_draft_path": "<draft_result.outputs.task_config_path>",
139	"artifact_kind": "task_config",
140	"confirmed_by": "user"
141	}
142	```
143
144	`confirm_artifact` 只确认已有草稿，不接受 `payload` 修改。如果用户要求“确认并修改”，先重新调用 `draft_task_config`，展示新的确认摘要，然后再次请求确认。
145
146	### Flow 规则
147
148	一次业务上的 task definition flow 从 `draft_task_config` 开始，到 `confirm_artifact` 结束。
149
150	- 调用 `draft_task_config` 时，runner 会创建新的 `flow_dir`。
151	- `draft_task_config` 返回后，必须保留 `result.outputs.flow_dir` 和 `result.outputs.task_config_path`。
152	- 后续 `confirm_artifact` 必须复用同一个 `flow_dir`，并使用同一个 flow 下的 draft artifact。
153	- 不要为 `confirm_artifact` 创建新的 flow。
154	- 不接受 `source_draft_ref` 或其他旧 `_ref` 输入；收到旧字段时，runner 会返回 `needs_input`，并在 `issues` / `next_steps` 中给出对应 `_path` 字段建议。
155	- 不要使用 `latest`、`current`、`active` 或目录扫描来猜测 flow。
156	- 如果找不到上一轮返回的 `flow_dir` 或 `task_config_path`，应向用户说明需要重新运行 `draft_task_config`，或请用户提供草稿路径。
157
158	## 4. 输出产物
159
160	典型输出目录：
161
162	```text
163	{run_dir}/uplift-model-task-spec/{timestamp}_task_spec/
164	inputs/
165	0001_draft_task_config.request.json
166	0002_confirm_artifact.request.json
167	results/
168	0001_draft_task_config.result.jso

QFIN-techPublisher · 22 listings

Preview

QFIN-tech/model-evo

# 任务定义

## 1. 输入依赖

RepoQFIN-tech/model-evo

LicenseMIT

TypeSkills

CategoryData

UpdatedJul 2026

Repo stars40

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type