@ai-content-space/loopx 0.2.0 → 0.2.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +7 -8
- package/README.md +22 -10
- package/README.zh-CN.md +22 -10
- package/docs/loopx/design/loopx-skill-suite-v1-design.md +14 -7
- package/docs/loopx/plans/loopx-skill-suite-v1-implementation.md +7 -3
- package/package.json +3 -2
- package/plugins/loopx/.codex-plugin/plugin.json +1 -1
- package/plugins/loopx/skills/clarify/SKILL.md +4 -4
- package/plugins/loopx/skills/debug/SKILL.md +1 -1
- package/plugins/loopx/skills/exec/SKILL.md +1 -1
- package/plugins/loopx/skills/final-review/SKILL.md +89 -0
- package/plugins/loopx/skills/final-review/final-reviewer.md +135 -0
- package/plugins/loopx/skills/finish/SKILL.md +110 -8
- package/plugins/loopx/skills/fix-review/SKILL.md +1 -1
- package/plugins/loopx/skills/go-style/SKILL.md +2 -2
- package/plugins/loopx/skills/kratos/SKILL.md +7 -1
- package/plugins/loopx/skills/plan/SKILL.md +2 -2
- package/plugins/loopx/skills/refactor-plan/SKILL.md +1 -1
- package/plugins/loopx/skills/review/SKILL.md +1 -1
- package/plugins/loopx/skills/spec/DESIGN_SPEC_TEMPLATE.md +2 -2
- package/plugins/loopx/skills/spec/SKILL.md +2 -2
- package/plugins/loopx/skills/subagent-exec/SKILL.md +7 -6
- package/plugins/loopx/skills/tdd/SKILL.md +1 -1
- package/plugins/loopx/skills/verify/SKILL.md +1 -1
- package/scripts/verify-skills.mjs +2 -1
- package/skills/RESOLVER.md +7 -8
- package/skills/clarify/SKILL.md +4 -4
- package/skills/debug/SKILL.md +1 -1
- package/skills/exec/SKILL.md +1 -1
- package/skills/final-review/SKILL.md +89 -0
- package/skills/final-review/final-reviewer.md +135 -0
- package/skills/finish/SKILL.md +110 -8
- package/skills/fix-review/SKILL.md +1 -1
- package/skills/go-style/SKILL.md +2 -2
- package/skills/kratos/SKILL.md +7 -1
- package/skills/plan/SKILL.md +2 -2
- package/skills/refactor-plan/SKILL.md +1 -1
- package/skills/review/SKILL.md +1 -1
- package/skills/spec/DESIGN_SPEC_TEMPLATE.md +2 -2
- package/skills/spec/SKILL.md +2 -2
- package/skills/subagent-exec/SKILL.md +7 -6
- package/skills/tdd/SKILL.md +1 -1
- package/skills/verify/SKILL.md +1 -1
- package/src/cli.mjs +1 -2
- package/src/install-discovery.mjs +1 -0
- package/src/plan-runtime.mjs +0 -352
- package/src/workflow.mjs +5 -124
- package/plugins/loopx/scripts/plugin-install.test.mjs +0 -125
- package/skills/ai-slop-cleaner/SKILL.md +0 -114
- package/skills/autoresearch/SKILL.md +0 -68
- package/skills/deep-interview/SKILL.md +0 -461
- package/skills/ralph/SKILL.md +0 -271
- package/skills/ralplan/SKILL.md +0 -49
package/AGENTS.md
CHANGED
|
@@ -1,25 +1,24 @@
|
|
|
1
1
|
# Repository Guidelines
|
|
2
2
|
|
|
3
|
-
## Iron Law
|
|
3
|
+
## Iron Law
|
|
4
4
|
|
|
5
|
-
**
|
|
6
|
-
Skills should be kept as simple as possible. It is like a Swiss Army knife - versatile but not a universal key.**
|
|
5
|
+
**Skill frontmatter descriptions are required for discovery, but skill bodies should stay operational, clear, and bounded. Avoid vague narrative, broad promises, and ambiguous handoffs. Keep each skill focused: versatile enough to be useful, not a universal key.**
|
|
7
6
|
|
|
8
7
|
|
|
9
8
|
|
|
10
9
|
## Project Structure & Module Organization
|
|
11
10
|
|
|
12
|
-
This repository is a Node.js ESM CLI package for loopx, a skill-first workflow harness for Codex-style
|
|
11
|
+
This repository is a Node.js ESM CLI package for loopx, a skill-first workflow harness for Codex and Claude-style agentic coding assistants.
|
|
13
12
|
|
|
14
13
|
- `src/` contains runtime modules and the `src/cli.mjs` executable.
|
|
15
14
|
- `test/` contains Node test suites, mainly `workflow.test.mjs` and `trellis-hardening.test.mjs`.
|
|
16
|
-
- `skills/` contains
|
|
17
|
-
- `plugins/loopx/` mirrors plugin-ready skills and plugin install scripts.
|
|
15
|
+
- `skills/` contains canonical skill source files. The v1 installed set is controlled by `LOOPX_BUNDLED_SKILLS` in `src/install-discovery.mjs`; not every local skill source is installed or governed as part of v1.
|
|
16
|
+
- `plugins/loopx/` mirrors the bundled plugin-ready v1 skills and plugin install scripts.
|
|
18
17
|
- `templates/` stores canonical workflow artifact templates.
|
|
19
18
|
- `scripts/` contains postinstall and hook scripts.
|
|
20
|
-
- `assets
|
|
19
|
+
- `assets/` and `docs/` hold static assets, release notes, and design/planning documents.
|
|
21
20
|
|
|
22
|
-
Keep source changes close to the owning module. When changing workflow behavior, update matching tests and any affected skill docs in both `skills/` and `plugins/loopx/skills/` when they are intentionally mirrored.
|
|
21
|
+
Keep source changes close to the owning module. When changing workflow behavior, update matching tests and any affected bundled skill docs in both `skills/` and `plugins/loopx/skills/` when they are intentionally mirrored.
|
|
23
22
|
|
|
24
23
|
## Build, Test, and Development Commands
|
|
25
24
|
|
package/README.md
CHANGED
|
@@ -10,7 +10,7 @@
|
|
|
10
10
|
|
|
11
11
|
[中文文档](./README.zh-CN.md)
|
|
12
12
|
|
|
13
|
-
`loopx`
|
|
13
|
+
`loopx` installs a pragmatic v1 skill suite for Codex and Claude-style coding agents. It combines grill-me style clarification with superpowers-style planning, execution, review, and finishing workflows.
|
|
14
14
|
|
|
15
15
|
Recommended v1 flow:
|
|
16
16
|
|
|
@@ -22,6 +22,8 @@ clarify -> spec? -> plan -> subagent-exec | exec -> review -> fix-review? -> fin
|
|
|
22
22
|
|
|
23
23
|
## Skills
|
|
24
24
|
|
|
25
|
+
The installed and governed v1 skill surface is the list below. The repository may keep auxiliary or compatibility skill sources under `skills/`, but they are not installed by `loopx install-skills` unless they are in the bundled v1 set.
|
|
26
|
+
|
|
25
27
|
Core workflow skills:
|
|
26
28
|
|
|
27
29
|
- `clarify`: interview until scope, non-goals, constraints, and decision boundaries are clear.
|
|
@@ -44,14 +46,26 @@ Support skills:
|
|
|
44
46
|
|
|
45
47
|
## Artifacts
|
|
46
48
|
|
|
47
|
-
|
|
49
|
+
For the v1 skill-suite workflow, human-maintained artifacts live under `docs/loopx/`:
|
|
48
50
|
|
|
49
51
|
- `docs/loopx/design/`
|
|
50
52
|
- `docs/loopx/plans/`
|
|
51
53
|
- `docs/loopx/reviews/`
|
|
52
54
|
- `docs/loopx/refactors/`
|
|
55
|
+
- `docs/loopx/specs/`
|
|
56
|
+
|
|
57
|
+
`finish` may generate spec candidates in `docs/loopx/specs/` when completed work produces stable team rules. These candidates are repo-tracked and must remain visible in the git diff.
|
|
58
|
+
|
|
59
|
+
Generated support state, hook diagnostics, installer metadata, HTML views, manifests, and runtime JSON remain under `.loopx/`.
|
|
53
60
|
|
|
54
|
-
|
|
61
|
+
Local agent memory lives under `.loopx/memory/`:
|
|
62
|
+
|
|
63
|
+
- `.loopx/memory/MEMORY.md`
|
|
64
|
+
- `.loopx/memory/index.jsonl`
|
|
65
|
+
- `.loopx/memory/entries/`
|
|
66
|
+
- `.loopx/memory/archive/`
|
|
67
|
+
|
|
68
|
+
`MEMORY.md` is a bounded curated project memory summary. `index.jsonl` is a curated active index for agent file-search, not an append-only log.
|
|
55
69
|
|
|
56
70
|
## Installation
|
|
57
71
|
|
|
@@ -94,22 +108,22 @@ Plugin install script:
|
|
|
94
108
|
node plugins/loopx/scripts/plugin-install.mjs
|
|
95
109
|
```
|
|
96
110
|
|
|
97
|
-
The plugin mirrors the canonical `skills/`
|
|
111
|
+
The plugin mirrors the canonical bundled v1 skills from `skills/` and uses the same install/discovery core.
|
|
98
112
|
|
|
99
113
|
## CLI
|
|
100
114
|
|
|
101
|
-
The CLI supports installation, diagnostics, rendering, and
|
|
115
|
+
The CLI supports installation, diagnostics, rendering, and runtime maintenance:
|
|
102
116
|
|
|
103
117
|
```bash
|
|
118
|
+
loopx --version
|
|
104
119
|
loopx install-skills [--target <codex|claude|all>] [--project] [--mode <copy|symlink>] [--dir <path>] [--yes]
|
|
105
120
|
loopx init [--slug <slug>] [--enable-agent-delegation] [--auto-agent-delegation] [--agent-delegation-threshold <local|critic-only|parallel-review>]
|
|
106
121
|
loopx clarify <slug> [--standard|--deep]
|
|
107
122
|
loopx approve <slug> --from <stage> --to <stage>
|
|
108
|
-
loopx plan [slug] [--
|
|
123
|
+
loopx plan [slug] [--interactive] [--deliberate]
|
|
109
124
|
loopx build <slug> [--no-deslop]
|
|
110
125
|
loopx build --from-review <review-report-path> [--no-deslop]
|
|
111
126
|
loopx review <slug> [--reviewer <name>]
|
|
112
|
-
loopx archive <slug>
|
|
113
127
|
loopx autopilot <slug> [--reviewer <name>]
|
|
114
128
|
loopx render [slug|--all]
|
|
115
129
|
loopx status [slug] [--json]
|
|
@@ -119,8 +133,6 @@ loopx migrate
|
|
|
119
133
|
loopx repair-install
|
|
120
134
|
```
|
|
121
135
|
|
|
122
|
-
Legacy `.loopx/workflows/` commands remain available for compatibility. They are not the v1 skill-suite workflow.
|
|
123
|
-
|
|
124
136
|
## Governance
|
|
125
137
|
|
|
126
138
|
The bundled skill resolver lives at:
|
|
@@ -135,4 +147,4 @@ Run deterministic governance checks before release or when changing bundled skil
|
|
|
135
147
|
node scripts/verify-skills.mjs
|
|
136
148
|
```
|
|
137
149
|
|
|
138
|
-
The verifier checks bundled skill frontmatter, plugin mirrors, resolver coverage, local references, package inclusion, version alignment, and public docs.
|
|
150
|
+
The verifier checks the bundled v1 skill frontmatter, plugin mirrors, resolver coverage, local references, package inclusion, version alignment, and public docs. It intentionally verifies the installed v1 skill set, not every auxiliary source directory that may exist under `skills/`.
|
package/README.zh-CN.md
CHANGED
|
@@ -10,7 +10,7 @@
|
|
|
10
10
|
|
|
11
11
|
[English](./README.md)
|
|
12
12
|
|
|
13
|
-
`loopx` 为 Codex 和 Claude 风格的 coding agent
|
|
13
|
+
`loopx` 为 Codex 和 Claude 风格的 coding agent 安装一组实用的 v1 skills。它把 grill-me 式需求澄清和 superpowers 式计划、执行、评审、收尾流程组合成一套可安装、可治理的技能套件。
|
|
14
14
|
|
|
15
15
|
推荐 v1 流程:
|
|
16
16
|
|
|
@@ -22,6 +22,8 @@ clarify -> spec? -> plan -> subagent-exec | exec -> review -> fix-review? -> fin
|
|
|
22
22
|
|
|
23
23
|
## Skills
|
|
24
24
|
|
|
25
|
+
安装和治理意义上的 v1 skill surface 是下面这组。仓库里可以保留辅助或兼容 skill 源文件,但除非它们属于 bundled v1 集合,否则 `loopx install-skills` 不会安装它们。
|
|
26
|
+
|
|
25
27
|
核心工作流 skills:
|
|
26
28
|
|
|
27
29
|
- `clarify`:持续追问直到范围、非目标、约束和决策边界清楚。
|
|
@@ -44,14 +46,26 @@ clarify -> spec? -> plan -> subagent-exec | exec -> review -> fix-review? -> fin
|
|
|
44
46
|
|
|
45
47
|
## 产物
|
|
46
48
|
|
|
47
|
-
|
|
49
|
+
v1 skill-suite 工作流的人工维护长期产物放在 `docs/loopx/`:
|
|
48
50
|
|
|
49
51
|
- `docs/loopx/design/`
|
|
50
52
|
- `docs/loopx/plans/`
|
|
51
53
|
- `docs/loopx/reviews/`
|
|
52
54
|
- `docs/loopx/refactors/`
|
|
55
|
+
- `docs/loopx/specs/`
|
|
56
|
+
|
|
57
|
+
当完成的工作产生稳定团队规则时,`finish` 可以在 `docs/loopx/specs/` 生成 spec candidates。这些候选是 repo-tracked,必须保留在 git diff 中供审阅。
|
|
58
|
+
|
|
59
|
+
生成的支撑状态、hook 诊断、安装元数据、HTML views、manifests 和 runtime JSON 仍放在 `.loopx/` 下。
|
|
53
60
|
|
|
54
|
-
|
|
61
|
+
本地 agent memory 放在 `.loopx/memory/`:
|
|
62
|
+
|
|
63
|
+
- `.loopx/memory/MEMORY.md`
|
|
64
|
+
- `.loopx/memory/index.jsonl`
|
|
65
|
+
- `.loopx/memory/entries/`
|
|
66
|
+
- `.loopx/memory/archive/`
|
|
67
|
+
|
|
68
|
+
`MEMORY.md` 是有上限的 curated project memory summary。`index.jsonl` 是用于 agent 文件检索的 curated active index,不是 append-only log。
|
|
55
69
|
|
|
56
70
|
## 安装
|
|
57
71
|
|
|
@@ -94,22 +108,22 @@ plugins/loopx/
|
|
|
94
108
|
node plugins/loopx/scripts/plugin-install.mjs
|
|
95
109
|
```
|
|
96
110
|
|
|
97
|
-
插件镜像
|
|
111
|
+
插件镜像 `skills/` 中 canonical bundled v1 skills,并复用同一套 install/discovery core。
|
|
98
112
|
|
|
99
113
|
## CLI
|
|
100
114
|
|
|
101
|
-
CLI 用于安装、诊断、渲染和
|
|
115
|
+
CLI 用于安装、诊断、渲染和 runtime 维护:
|
|
102
116
|
|
|
103
117
|
```bash
|
|
118
|
+
loopx --version
|
|
104
119
|
loopx install-skills [--target <codex|claude|all>] [--project] [--mode <copy|symlink>] [--dir <path>] [--yes]
|
|
105
120
|
loopx init [--slug <slug>] [--enable-agent-delegation] [--auto-agent-delegation] [--agent-delegation-threshold <local|critic-only|parallel-review>]
|
|
106
121
|
loopx clarify <slug> [--standard|--deep]
|
|
107
122
|
loopx approve <slug> --from <stage> --to <stage>
|
|
108
|
-
loopx plan [slug] [--
|
|
123
|
+
loopx plan [slug] [--interactive] [--deliberate]
|
|
109
124
|
loopx build <slug> [--no-deslop]
|
|
110
125
|
loopx build --from-review <review-report-path> [--no-deslop]
|
|
111
126
|
loopx review <slug> [--reviewer <name>]
|
|
112
|
-
loopx archive <slug>
|
|
113
127
|
loopx autopilot <slug> [--reviewer <name>]
|
|
114
128
|
loopx render [slug|--all]
|
|
115
129
|
loopx status [slug] [--json]
|
|
@@ -119,8 +133,6 @@ loopx migrate
|
|
|
119
133
|
loopx repair-install
|
|
120
134
|
```
|
|
121
135
|
|
|
122
|
-
Legacy `.loopx/workflows/` 命令仍保留兼容,但不是 v1 skill-suite workflow。
|
|
123
|
-
|
|
124
136
|
## 治理
|
|
125
137
|
|
|
126
138
|
bundled skill resolver 位于:
|
|
@@ -135,4 +147,4 @@ skills/RESOLVER.md
|
|
|
135
147
|
node scripts/verify-skills.mjs
|
|
136
148
|
```
|
|
137
149
|
|
|
138
|
-
治理脚本检查 bundled skill frontmatter、plugin mirrors、resolver coverage
|
|
150
|
+
治理脚本检查 bundled v1 skill frontmatter、plugin mirrors、resolver coverage、本地引用、发布包包含项、版本一致性和公开文档。它刻意验证安装意义上的 v1 skill 集合,而不是 `skills/` 下可能存在的每个辅助源目录。
|
|
@@ -2,11 +2,11 @@
|
|
|
2
2
|
|
|
3
3
|
## Context
|
|
4
4
|
|
|
5
|
-
loopx is moving from a CLI-runtime-first workflow into a skill-first suite for agentic coding assistants. Codex and Claude are supported targets. The CLI remains as installer, governance, diagnostics, rendering, and
|
|
5
|
+
loopx is moving from a CLI-runtime-first workflow into a skill-first suite for agentic coding assistants. Codex and Claude are supported targets. The CLI remains as installer, governance, diagnostics, rendering, and runtime maintenance.
|
|
6
6
|
|
|
7
7
|
## Decision
|
|
8
8
|
|
|
9
|
-
The v1 product surface is
|
|
9
|
+
The v1 product surface is the installed and governed bundled skill suite:
|
|
10
10
|
|
|
11
11
|
- `clarify`
|
|
12
12
|
- `spec`
|
|
@@ -23,7 +23,9 @@ The v1 product surface is a bundled skill suite:
|
|
|
23
23
|
- `go-style`
|
|
24
24
|
- `kratos`
|
|
25
25
|
|
|
26
|
-
|
|
26
|
+
Runtime-only skills are not installed as Codex or Claude skills in v1.
|
|
27
|
+
|
|
28
|
+
The repository may retain auxiliary or compatibility skill source directories for development history or adjacent workflows. They are not part of the v1 product surface unless they are listed in the bundled install set and mirrored into the plugin skill set.
|
|
27
29
|
|
|
28
30
|
## Workflow
|
|
29
31
|
|
|
@@ -39,16 +41,21 @@ clarify -> spec? -> plan -> subagent-exec | exec -> review -> fix-review? -> fin
|
|
|
39
41
|
|
|
40
42
|
`review` is the superpowers `requesting-code-review` workflow under the loopx name. `fix-review` is the superpowers `receiving-code-review` workflow under the loopx name.
|
|
41
43
|
|
|
44
|
+
`finish` verifies completion, extracts local memory, proposes repo-tracked spec candidates when stable team rules emerged, then presents merge, PR, keep, or discard options.
|
|
45
|
+
|
|
42
46
|
## Artifacts
|
|
43
47
|
|
|
44
|
-
Human-maintained artifacts use `docs/loopx/`:
|
|
48
|
+
Human-maintained v1 skill-suite artifacts use `docs/loopx/`:
|
|
45
49
|
|
|
46
50
|
- `docs/loopx/design/`
|
|
47
51
|
- `docs/loopx/plans/`
|
|
48
52
|
- `docs/loopx/reviews/`
|
|
49
53
|
- `docs/loopx/refactors/`
|
|
54
|
+
- `docs/loopx/specs/`
|
|
55
|
+
|
|
56
|
+
Runtime state, hook diagnostics, installer metadata, manifests, generated HTML views, and runtime JSON use `.loopx/`.
|
|
50
57
|
|
|
51
|
-
|
|
58
|
+
Local agent memory uses `.loopx/memory/`. `.loopx/memory/MEMORY.md` is bounded curated project memory. `.loopx/memory/index.jsonl` is a curated active index for agent file-search. Stable shared rules belong in `docs/loopx/specs/<domain>.md`, with `docs/loopx/specs/inbox.md` as the fallback domain.
|
|
52
59
|
|
|
53
60
|
## Installer
|
|
54
61
|
|
|
@@ -63,11 +70,11 @@ Project-level Claude installation and custom directories are explicit installer
|
|
|
63
70
|
|
|
64
71
|
## Claude Hook
|
|
65
72
|
|
|
66
|
-
The Claude hook is advisory only. It must not block tools, mutate workflow state, or enforce git safety. It emits next-action context when loopx support
|
|
73
|
+
The Claude hook is advisory only. It must not block tools, mutate workflow state, or enforce git safety. It emits next-action context when loopx support context exists.
|
|
67
74
|
|
|
68
75
|
## Non-Goals
|
|
69
76
|
|
|
70
|
-
- No alias skills for renamed superpowers skills.
|
|
77
|
+
- No alias skills in the v1 bundled install surface for renamed superpowers skills.
|
|
71
78
|
- No automatic project-level `.claude/skills` writes in postinstall.
|
|
72
79
|
- No new mandatory CLI state machine for the v1 skill suite.
|
|
73
80
|
- No blocking Claude hook in v1.
|
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
# loopx Skill Suite v1 Implementation Plan
|
|
2
2
|
|
|
3
|
-
> **For agentic workers:** execute task-by-task. Preserve existing user edits and keep
|
|
3
|
+
> **For agentic workers:** execute task-by-task. Preserve existing user edits and keep runtime maintenance behavior unless a task explicitly changes skill installation behavior.
|
|
4
4
|
|
|
5
5
|
**Source Design:** `docs/loopx/design/loopx-skill-suite-v1-design.md`
|
|
6
6
|
|
|
7
7
|
**Goal:** Convert loopx into a Codex and Claude ready skill suite with renamed superpowers-style workflow skills, dual-target installation, and non-blocking Claude hook support.
|
|
8
8
|
|
|
9
|
-
**Architecture:** `skills/` remains canonical. `plugins/loopx/skills/` mirrors
|
|
9
|
+
**Architecture:** `skills/` remains the canonical source root. `plugins/loopx/skills/` mirrors the bundled v1 skill set for Codex plugin packaging, not every auxiliary source directory that may exist under `skills/`. `src/install-discovery.mjs` owns multi-target installation and lock metadata.
|
|
10
10
|
|
|
11
11
|
**Tech Stack:** Node.js ESM, `node:test`, filesystem APIs from `node:fs/promises`.
|
|
12
12
|
|
|
@@ -23,8 +23,9 @@
|
|
|
23
23
|
- [ ] Rename canonical superpowers-derived skills to v1 names.
|
|
24
24
|
- [ ] Remove old runtime workflow skills from the bundled install list.
|
|
25
25
|
- [ ] Keep `plan` as the canonical implementation-planning skill.
|
|
26
|
-
- [ ] Mirror all canonical skill files into `plugins/loopx/skills/`.
|
|
26
|
+
- [ ] Mirror all bundled v1 canonical skill files into `plugins/loopx/skills/`.
|
|
27
27
|
- [ ] Update internal references from old names to new `loopx:` names.
|
|
28
|
+
- [ ] Keep auxiliary or compatibility skill sources outside the bundled install list unless explicitly promoted into the v1 product surface.
|
|
28
29
|
|
|
29
30
|
### Task 2: Installer Targets
|
|
30
31
|
|
|
@@ -63,6 +64,9 @@
|
|
|
63
64
|
|
|
64
65
|
- [ ] Reframe loopx as a skill suite for agentic coding assistants.
|
|
65
66
|
- [ ] Document the new workflow and artifact paths.
|
|
67
|
+
- [ ] Clarify v1 `docs/loopx/` artifacts versus generated runtime support state.
|
|
68
|
+
- [ ] Document finish memory extraction and `docs/loopx/specs/` candidate promotion.
|
|
69
|
+
- [ ] Clarify installed bundled skills versus auxiliary skill source directories.
|
|
66
70
|
- [ ] Document Codex and Claude installation.
|
|
67
71
|
- [ ] Update governance checks for the v1 bundled skill list and mirrors.
|
|
68
72
|
- [ ] Update install tests for dual user targets and hooks.
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ai-content-space/loopx",
|
|
3
3
|
"type": "module",
|
|
4
|
-
"version": "0.2.
|
|
4
|
+
"version": "0.2.2",
|
|
5
5
|
"description": "Skill-first workflow suite for agentic coding assistants",
|
|
6
6
|
"repository": {
|
|
7
7
|
"type": "git",
|
|
@@ -32,7 +32,8 @@
|
|
|
32
32
|
"src/",
|
|
33
33
|
"skills/",
|
|
34
34
|
"templates/",
|
|
35
|
-
"plugins/loopx/"
|
|
35
|
+
"plugins/loopx/",
|
|
36
|
+
"!plugins/loopx/scripts/plugin-install.test.mjs"
|
|
36
37
|
],
|
|
37
38
|
"publishConfig": {
|
|
38
39
|
"access": "public"
|
|
@@ -3,7 +3,7 @@ name: clarify
|
|
|
3
3
|
description: "Grills ambiguous loopx work until material questions are answered, then routes to spec or plan using a design gate. Not for clear implementation tasks, approved specs, or code changes."
|
|
4
4
|
when_to_use: "clarify, requirements, ambiguous request, unclear scope, non-goals, decision boundaries, acceptance criteria, 需求澄清, 范围不清"
|
|
5
5
|
metadata:
|
|
6
|
-
version: "0.2.
|
|
6
|
+
version: "0.2.2"
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# loopx Clarify
|
|
@@ -63,11 +63,11 @@ For `needs_spec`, immediately use the `spec` skill with the clarification contex
|
|
|
63
63
|
Then stop before implementation planning and report:
|
|
64
64
|
|
|
65
65
|
```text
|
|
66
|
-
$plan
|
|
66
|
+
$plan docs/loopx/design/<需求名>需求设计文档.md
|
|
67
67
|
```
|
|
68
68
|
|
|
69
|
-
For `direct_to_plan`,
|
|
69
|
+
For `direct_to_plan`, hand off to the `plan` skill with the clarification context bundle as the source. `plan` writes:
|
|
70
70
|
|
|
71
71
|
- `docs/loopx/plans/YYYY-MM-DD-<feature-name>.md`
|
|
72
72
|
|
|
73
|
-
Do not
|
|
73
|
+
Do not write implementation plans or start code changes inside `clarify`.
|
|
@@ -3,7 +3,7 @@ name: debug
|
|
|
3
3
|
description: "Finds root cause for bugs, failing tests, build failures, regressions, and unexpected behavior before fixes. Not for new feature planning or routine code review."
|
|
4
4
|
when_to_use: "debug, bug, test failure, build failure, regression, unexpected behavior, root cause, 报错, 失败, 回归, 排查"
|
|
5
5
|
metadata:
|
|
6
|
-
version: "0.2.
|
|
6
|
+
version: "0.2.2"
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# Systematic Debugging
|
|
@@ -3,7 +3,7 @@ name: exec
|
|
|
3
3
|
description: "Executes a written loopx implementation plan sequentially with review checkpoints. Not for unclear plans, missing requirements, or subagent-first execution."
|
|
4
4
|
when_to_use: "written implementation plan, inline execution, sequential plan execution, review checkpoints, no subagent lane"
|
|
5
5
|
metadata:
|
|
6
|
-
version: "0.2.
|
|
6
|
+
version: "0.2.2"
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# Exec
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: final-review
|
|
3
|
+
description: "Performs whole-feature review after implementation and staged task review. Not for per-task review, unresolved scope, implementation, or pure documentation polish."
|
|
4
|
+
when_to_use: "final-review, final code review, whole feature review, integration review, pre-finish review, after subagent-exec, runtime risk review, 最终评审"
|
|
5
|
+
metadata:
|
|
6
|
+
version: "0.2.2"
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Final Review
|
|
10
|
+
|
|
11
|
+
Run the final whole-feature review after implementation is complete and before `finish`.
|
|
12
|
+
|
|
13
|
+
**Core principle:** Per-task review catches local issues. Final review hunts integration and runtime risk across the complete feature.
|
|
14
|
+
|
|
15
|
+
**Announce at start:** "I'm using the final-review skill to review the completed feature."
|
|
16
|
+
|
|
17
|
+
## When to Use
|
|
18
|
+
|
|
19
|
+
Use this after:
|
|
20
|
+
- `subagent-exec` completed all planned tasks and per-task reviews
|
|
21
|
+
- `exec` completed a full plan with verification checkpoints
|
|
22
|
+
- ad-hoc implementation is complete and ready for final risk review
|
|
23
|
+
|
|
24
|
+
Do not use this for:
|
|
25
|
+
- reviewing one task or one small checkpoint (`review` is for that)
|
|
26
|
+
- fixing review feedback (`fix-review` is for that)
|
|
27
|
+
- polishing documentation wording
|
|
28
|
+
- incomplete implementation or failing verification
|
|
29
|
+
|
|
30
|
+
## Required Inputs
|
|
31
|
+
|
|
32
|
+
Before dispatching the reviewer, collect:
|
|
33
|
+
- Full feature git range: base SHA before implementation, head SHA now
|
|
34
|
+
- Source requirements: spec, plan, issue, PRD, or accepted task brief
|
|
35
|
+
- Implementation summary: what changed and why
|
|
36
|
+
- Verification evidence: commands run and results
|
|
37
|
+
- Per-task review artifacts, if available
|
|
38
|
+
|
|
39
|
+
If the git range or requirements are unclear, stop and ask. A final review without a concrete scope is not useful.
|
|
40
|
+
|
|
41
|
+
## Review Priority
|
|
42
|
+
|
|
43
|
+
The reviewer must prioritize findings in this order:
|
|
44
|
+
|
|
45
|
+
1. Runtime bugs, data loss, broken CLI behavior, state corruption
|
|
46
|
+
2. Cross-task integration bugs
|
|
47
|
+
3. Missing edge cases not covered by tests
|
|
48
|
+
4. Test quality problems
|
|
49
|
+
5. Architecture and maintainability issues
|
|
50
|
+
6. Documentation defects that can mislead users or maintainers, omit required operational facts, or contradict actual behavior
|
|
51
|
+
|
|
52
|
+
Do not report pure documentation polish, style preferences, or wording tweaks. Do report documentation problems that create wrong usage, wrong maintenance decisions, missing required commands, missing migration notes, or false claims.
|
|
53
|
+
|
|
54
|
+
## Dispatch
|
|
55
|
+
|
|
56
|
+
Use the platform's native subagent mechanism when available and fill template at `final-reviewer.md`.
|
|
57
|
+
|
|
58
|
+
**Placeholders:**
|
|
59
|
+
- `{DESCRIPTION}` - concise summary of the completed feature
|
|
60
|
+
- `{REQUIREMENTS}` - source requirements or plan/spec excerpts
|
|
61
|
+
- `{VERIFICATION}` - test commands and results
|
|
62
|
+
- `{PER_TASK_REVIEWS}` - review artifacts or "not available"
|
|
63
|
+
- `{BASE_SHA}` - commit before implementation began
|
|
64
|
+
- `{HEAD_SHA}` - current commit
|
|
65
|
+
|
|
66
|
+
## Handle Feedback
|
|
67
|
+
|
|
68
|
+
- Critical and Important findings must be handled before `finish`
|
|
69
|
+
- Use `fix-review` for received feedback
|
|
70
|
+
- Push back only with code, test, or requirement evidence
|
|
71
|
+
- After fixes, run verification again and repeat final review if the fix changed integration behavior
|
|
72
|
+
|
|
73
|
+
## Common Mistakes
|
|
74
|
+
|
|
75
|
+
**Running normal review again**
|
|
76
|
+
- Problem: reviewer repeats per-task or documentation comments
|
|
77
|
+
- Fix: use `final-reviewer.md`, which focuses on whole-feature runtime risk
|
|
78
|
+
|
|
79
|
+
**Letting docs hide real risk**
|
|
80
|
+
- Problem: "docs only" findings are ignored even when users would be misled
|
|
81
|
+
- Fix: distinguish pure polish from operationally incorrect or missing documentation
|
|
82
|
+
|
|
83
|
+
**Reviewing without base/head SHAs**
|
|
84
|
+
- Problem: reviewer sees an unclear or stale diff
|
|
85
|
+
- Fix: provide an exact git range every time
|
|
86
|
+
|
|
87
|
+
**Skipping verification evidence**
|
|
88
|
+
- Problem: reviewer cannot judge whether tests prove real behavior
|
|
89
|
+
- Fix: include exact commands and pass/fail output summary
|
|
@@ -0,0 +1,135 @@
|
|
|
1
|
+
# Final Reviewer Prompt Template
|
|
2
|
+
|
|
3
|
+
Use this template when dispatching a final-review subagent.
|
|
4
|
+
|
|
5
|
+
**Purpose:** Review the complete feature for integration and runtime risk after task-level implementation and review are already done.
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
Native subagent:
|
|
9
|
+
description: "Final review completed feature"
|
|
10
|
+
prompt: |
|
|
11
|
+
You are a Senior Final Reviewer. Task-level implementation and review have
|
|
12
|
+
already happened. Your job is not to repeat per-task review. Your job is to
|
|
13
|
+
find whole-feature risks that can still break users, corrupt state, lose
|
|
14
|
+
data, or leave important behavior untested.
|
|
15
|
+
|
|
16
|
+
## What Was Implemented
|
|
17
|
+
|
|
18
|
+
{DESCRIPTION}
|
|
19
|
+
|
|
20
|
+
## Requirements / Plan / Spec
|
|
21
|
+
|
|
22
|
+
{REQUIREMENTS}
|
|
23
|
+
|
|
24
|
+
## Verification Evidence
|
|
25
|
+
|
|
26
|
+
{VERIFICATION}
|
|
27
|
+
|
|
28
|
+
## Per-Task Reviews
|
|
29
|
+
|
|
30
|
+
{PER_TASK_REVIEWS}
|
|
31
|
+
|
|
32
|
+
## Full Feature Git Range
|
|
33
|
+
|
|
34
|
+
**Base:** {BASE_SHA}
|
|
35
|
+
**Head:** {HEAD_SHA}
|
|
36
|
+
|
|
37
|
+
```bash
|
|
38
|
+
git diff --stat {BASE_SHA}..{HEAD_SHA}
|
|
39
|
+
git diff {BASE_SHA}..{HEAD_SHA}
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
## Review Priority
|
|
43
|
+
|
|
44
|
+
Review in this exact priority order:
|
|
45
|
+
|
|
46
|
+
1. Runtime bugs, data loss, broken CLI behavior, state corruption
|
|
47
|
+
2. Cross-task integration bugs
|
|
48
|
+
3. Missing edge cases not covered by tests
|
|
49
|
+
4. Test quality problems
|
|
50
|
+
5. Architecture and maintainability issues
|
|
51
|
+
6. Documentation defects that can mislead users or maintainers, omit
|
|
52
|
+
required operational facts, or contradict actual behavior
|
|
53
|
+
|
|
54
|
+
Do not report pure documentation polish, style preferences, or wording
|
|
55
|
+
tweaks. Do report documentation problems that create wrong usage, wrong
|
|
56
|
+
maintenance decisions, missing required commands, missing migration notes,
|
|
57
|
+
or false claims.
|
|
58
|
+
|
|
59
|
+
## What to Check
|
|
60
|
+
|
|
61
|
+
**Runtime and state risk:**
|
|
62
|
+
- Can any command crash, hang, silently no-op, or report success incorrectly?
|
|
63
|
+
- Can repeated runs corrupt files, state, locks, indexes, caches, or config?
|
|
64
|
+
- Can user data, generated artifacts, branches, or worktrees be lost?
|
|
65
|
+
- Are filesystem, process, permission, platform, and concurrency errors handled?
|
|
66
|
+
|
|
67
|
+
**Integration risk:**
|
|
68
|
+
- Do task outputs match later task inputs?
|
|
69
|
+
- Do CLI flags, exported functions, filenames, state keys, and schemas align?
|
|
70
|
+
- Does the feature work as a complete workflow, not just as isolated pieces?
|
|
71
|
+
- Are old data, missing files, and partially completed states handled?
|
|
72
|
+
|
|
73
|
+
**Tests:**
|
|
74
|
+
- Do tests execute real behavior rather than only mocks or snapshots?
|
|
75
|
+
- Are failure paths, edge cases, repeat runs, and integration paths covered?
|
|
76
|
+
- Are the verification commands sufficient for the changed surface area?
|
|
77
|
+
|
|
78
|
+
**Architecture:**
|
|
79
|
+
- Is the implementation maintainable within existing module boundaries?
|
|
80
|
+
- Did the feature add avoidable coupling or hidden global state?
|
|
81
|
+
- Are abstractions justified by actual complexity?
|
|
82
|
+
|
|
83
|
+
**Documentation defects:**
|
|
84
|
+
- Does documentation contradict actual behavior?
|
|
85
|
+
- Are required user or maintainer steps missing?
|
|
86
|
+
- Would a future agent follow the docs and make the wrong change?
|
|
87
|
+
|
|
88
|
+
## Output Format
|
|
89
|
+
|
|
90
|
+
### Findings
|
|
91
|
+
|
|
92
|
+
#### Critical
|
|
93
|
+
[Must fix before finish: data loss, state corruption, broken workflow,
|
|
94
|
+
security issue, or reliable runtime failure]
|
|
95
|
+
|
|
96
|
+
#### Important
|
|
97
|
+
[Should fix before finish: integration bug, untested edge case, weak test
|
|
98
|
+
proving too little, misleading docs that affect usage or maintenance]
|
|
99
|
+
|
|
100
|
+
#### Minor
|
|
101
|
+
[Low-risk maintainability or clarity issues. No pure polish.]
|
|
102
|
+
|
|
103
|
+
For each finding:
|
|
104
|
+
- File:line reference
|
|
105
|
+
- What is wrong
|
|
106
|
+
- Why it matters
|
|
107
|
+
- How to fix or what evidence would resolve it
|
|
108
|
+
|
|
109
|
+
### Coverage Notes
|
|
110
|
+
[Briefly state which runtime paths and tests you inspected.]
|
|
111
|
+
|
|
112
|
+
### Assessment
|
|
113
|
+
|
|
114
|
+
**Ready for finish?** [Yes | No | With fixes]
|
|
115
|
+
|
|
116
|
+
**Reasoning:** [1-2 sentence risk-based assessment]
|
|
117
|
+
|
|
118
|
+
## Critical Rules
|
|
119
|
+
|
|
120
|
+
**DO:**
|
|
121
|
+
- Read the actual diff, not only reports
|
|
122
|
+
- Focus on complete workflow behavior
|
|
123
|
+
- Treat tests as evidence to audit, not proof to trust blindly
|
|
124
|
+
- Report documentation defects that can mislead or omit required facts
|
|
125
|
+
- Give file:line references
|
|
126
|
+
|
|
127
|
+
**DON'T:**
|
|
128
|
+
- Repeat task-level nits unless they create whole-feature risk
|
|
129
|
+
- Report pure documentation polish
|
|
130
|
+
- Assume per-task reviews caught integration bugs
|
|
131
|
+
- Give a vague "looks good"
|
|
132
|
+
- Avoid a clear verdict
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
**Reviewer returns:** Findings by severity, Coverage Notes, Assessment.
|