@ai-content-space/loopx 0.1.0
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/README.md +110 -0
- package/package.json +32 -0
- package/plugins/loopx/.codex-plugin/plugin.json +13 -0
- package/plugins/loopx/scripts/plugin-install.mjs +56 -0
- package/plugins/loopx/scripts/plugin-install.test.mjs +94 -0
- package/plugins/loopx/skills/loopx-autopilot/SKILL.md +30 -0
- package/plugins/loopx/skills/loopx-build/SKILL.md +25 -0
- package/plugins/loopx/skills/loopx-clarify/SKILL.md +25 -0
- package/plugins/loopx/skills/loopx-plan/SKILL.md +25 -0
- package/plugins/loopx/skills/loopx-review/SKILL.md +25 -0
- package/scripts/install-skills.mjs +18 -0
- package/skills/loopx-autopilot/SKILL.md +30 -0
- package/skills/loopx-build/SKILL.md +25 -0
- package/skills/loopx-clarify/SKILL.md +25 -0
- package/skills/loopx-plan/SKILL.md +25 -0
- package/skills/loopx-review/SKILL.md +25 -0
- package/src/cli.mjs +167 -0
- package/src/install-discovery.mjs +367 -0
- package/src/runtime-maintenance.mjs +68 -0
- package/src/workflow.mjs +1008 -0
- package/templates/architecture.md +31 -0
- package/templates/development-plan.md +27 -0
- package/templates/execution-record.md +35 -0
- package/templates/plan.md +34 -0
- package/templates/review-report.md +31 -0
- package/templates/spec.md +33 -0
- package/templates/test-plan.md +23 -0
package/README.md
ADDED
|
@@ -0,0 +1,110 @@
|
|
|
1
|
+
# LoopX
|
|
2
|
+
|
|
3
|
+
`LoopX` is a skill-first workflow product for Codex. It supports two first-class distribution shells:
|
|
4
|
+
|
|
5
|
+
- npm/global install
|
|
6
|
+
- Codex plugin install
|
|
7
|
+
|
|
8
|
+
Both shells converge on one shared LoopX core and one visible LoopX skill set.
|
|
9
|
+
|
|
10
|
+
## Release Contract
|
|
11
|
+
|
|
12
|
+
The active LoopX release flow is:
|
|
13
|
+
|
|
14
|
+
`clarify -> plan -> build -> review`
|
|
15
|
+
|
|
16
|
+
Bundled skill surfaces:
|
|
17
|
+
|
|
18
|
+
- `loopx-clarify`
|
|
19
|
+
- `loopx-plan`
|
|
20
|
+
- `loopx-build`
|
|
21
|
+
- `loopx-review`
|
|
22
|
+
- `loopx-autopilot`
|
|
23
|
+
|
|
24
|
+
There is no public `team` surface in this release.
|
|
25
|
+
|
|
26
|
+
## Product Positioning
|
|
27
|
+
|
|
28
|
+
- skill-first for normal use
|
|
29
|
+
- retained CLI/runtime/debug substrate for maintenance and inspection
|
|
30
|
+
- explicit local artifacts and state under `.LoopX/`
|
|
31
|
+
- bounded migration from legacy `.codex-helper/`
|
|
32
|
+
|
|
33
|
+
## Runtime Namespace
|
|
34
|
+
|
|
35
|
+
LoopX user-facing runtime state is stored under:
|
|
36
|
+
|
|
37
|
+
```text
|
|
38
|
+
.LoopX/
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
Key subtrees:
|
|
42
|
+
|
|
43
|
+
- `.LoopX/specs/`
|
|
44
|
+
- `.LoopX/plans/`
|
|
45
|
+
- `.LoopX/workflows/<slug>/`
|
|
46
|
+
- `.LoopX/autopilot/<slug>/`
|
|
47
|
+
|
|
48
|
+
The `.omx/` tree remains orchestration/planning metadata and is not part of the LoopX runtime rename.
|
|
49
|
+
|
|
50
|
+
## CLI Surface
|
|
51
|
+
|
|
52
|
+
Primary runtime/debug commands:
|
|
53
|
+
|
|
54
|
+
```bash
|
|
55
|
+
loopx init [--slug <slug>]
|
|
56
|
+
loopx clarify <slug>
|
|
57
|
+
loopx approve <slug> --from <stage> --to <stage>
|
|
58
|
+
loopx plan <slug>
|
|
59
|
+
loopx build <slug>
|
|
60
|
+
loopx review <slug> [--reviewer <name>]
|
|
61
|
+
loopx autopilot <slug> [--reviewer <name>]
|
|
62
|
+
loopx status [slug] [--json]
|
|
63
|
+
loopx doctor
|
|
64
|
+
loopx migrate
|
|
65
|
+
loopx repair-install
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
The CLI is supporting runtime/debug tooling. The intended user-facing product surface is the bundled LoopX skills.
|
|
69
|
+
|
|
70
|
+
## Install and Discovery
|
|
71
|
+
|
|
72
|
+
LoopX supports two install paths that both reuse the same shared install/discovery core:
|
|
73
|
+
|
|
74
|
+
- npm/global install:
|
|
75
|
+
- `npm install -g @ai-content-space/loopx`
|
|
76
|
+
- followed by `postinstall -> node scripts/install-skills.mjs`
|
|
77
|
+
- plugin install:
|
|
78
|
+
- `plugins/loopx/scripts/plugin-install.mjs`
|
|
79
|
+
|
|
80
|
+
Bootstrap behavior:
|
|
81
|
+
|
|
82
|
+
- materializes LoopX-owned skills under `~/.agents/skills/`
|
|
83
|
+
- updates LoopX-owned `local` rows in `~/.agents/.skill-lock.json`
|
|
84
|
+
- keeps install idempotent
|
|
85
|
+
- supports repair through `loopx repair-install`
|
|
86
|
+
- converges npm and plugin installs onto one `installationIdentity=loopx`
|
|
87
|
+
|
|
88
|
+
Discovery is valid only when both are true:
|
|
89
|
+
|
|
90
|
+
- the installed LoopX skill directory exists
|
|
91
|
+
- the matching LoopX-owned registry row exists
|
|
92
|
+
|
|
93
|
+
If both npm and plugin installs are present, Codex should still expose one LoopX skill set rather than duplicates.
|
|
94
|
+
|
|
95
|
+
## Legacy Migration
|
|
96
|
+
|
|
97
|
+
- legacy `.codex-helper/` runtime state is migrated through `loopx migrate`
|
|
98
|
+
- mixed `.LoopX/` and `.codex-helper/` roots are treated as a repairable error
|
|
99
|
+
- public docs, package, CLI, and skill names use `LoopX`
|
|
100
|
+
|
|
101
|
+
## Verification
|
|
102
|
+
|
|
103
|
+
```bash
|
|
104
|
+
node --test test/*.test.mjs
|
|
105
|
+
node scripts/install-skills.mjs --check
|
|
106
|
+
node --test plugins/loopx/scripts/plugin-install.test.mjs
|
|
107
|
+
node src/cli.mjs --help
|
|
108
|
+
node src/cli.mjs doctor
|
|
109
|
+
node src/cli.mjs status --json
|
|
110
|
+
```
|
package/package.json
ADDED
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@ai-content-space/loopx",
|
|
3
|
+
"type": "module",
|
|
4
|
+
"version": "0.1.0",
|
|
5
|
+
"description": "Skill-first LoopX workflow product for Codex",
|
|
6
|
+
"keywords": [
|
|
7
|
+
"codex",
|
|
8
|
+
"loopx",
|
|
9
|
+
"skills",
|
|
10
|
+
"workflow",
|
|
11
|
+
"plugin"
|
|
12
|
+
],
|
|
13
|
+
"bin": {
|
|
14
|
+
"loopx": "src/cli.mjs"
|
|
15
|
+
},
|
|
16
|
+
"files": [
|
|
17
|
+
"README.md",
|
|
18
|
+
"package.json",
|
|
19
|
+
"scripts/install-skills.mjs",
|
|
20
|
+
"src/",
|
|
21
|
+
"skills/",
|
|
22
|
+
"templates/",
|
|
23
|
+
"plugins/loopx/"
|
|
24
|
+
],
|
|
25
|
+
"publishConfig": {
|
|
26
|
+
"access": "public"
|
|
27
|
+
},
|
|
28
|
+
"scripts": {
|
|
29
|
+
"postinstall": "node scripts/install-skills.mjs",
|
|
30
|
+
"test": "node --test test/*.test.mjs"
|
|
31
|
+
}
|
|
32
|
+
}
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "loopx",
|
|
3
|
+
"version": "0.1.0",
|
|
4
|
+
"description": "Skill-first LoopX workflow product for Codex",
|
|
5
|
+
"skills": "./skills/",
|
|
6
|
+
"interface": {
|
|
7
|
+
"displayName": "LoopX",
|
|
8
|
+
"shortDescription": "Thin plugin shell for the LoopX skill bundle.",
|
|
9
|
+
"longDescription": "This plugin mirrors the canonical LoopX skills and routes plugin installs through the shared LoopX install/discovery core. It stays plugin-root-relative at the manifest boundary and does not define a second LoopX implementation.",
|
|
10
|
+
"developerName": "LoopX",
|
|
11
|
+
"category": "Developer Tools"
|
|
12
|
+
}
|
|
13
|
+
}
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
|
|
3
|
+
import { dirname, join, resolve } from 'node:path';
|
|
4
|
+
import { fileURLToPath } from 'node:url';
|
|
5
|
+
|
|
6
|
+
import { installBundledSkills, verifyInstallState } from '../../../src/install-discovery.mjs';
|
|
7
|
+
|
|
8
|
+
const MODULE_DIR = dirname(fileURLToPath(import.meta.url));
|
|
9
|
+
const PLUGIN_ROOT = resolve(MODULE_DIR, '..');
|
|
10
|
+
const REPO_ROOT = resolve(PLUGIN_ROOT, '..', '..');
|
|
11
|
+
const PLUGIN_SKILLS_ROOT = join(PLUGIN_ROOT, 'skills');
|
|
12
|
+
const DISTRIBUTION_CHANNEL = 'plugin';
|
|
13
|
+
|
|
14
|
+
function buildPluginEnv() {
|
|
15
|
+
return {
|
|
16
|
+
...process.env,
|
|
17
|
+
LOOPX_PROJECT_ROOT: REPO_ROOT,
|
|
18
|
+
LOOPX_SKILL_SOURCE_ROOT: PLUGIN_SKILLS_ROOT,
|
|
19
|
+
LOOPX_DISTRIBUTION_CHANNEL: DISTRIBUTION_CHANNEL,
|
|
20
|
+
LOOPX_INSTALLATION_IDENTITY: 'loopx',
|
|
21
|
+
LOOPX_SOURCE_URL: PLUGIN_ROOT,
|
|
22
|
+
};
|
|
23
|
+
}
|
|
24
|
+
|
|
25
|
+
async function main() {
|
|
26
|
+
const checkOnly = process.argv.includes('--check');
|
|
27
|
+
const env = buildPluginEnv();
|
|
28
|
+
const result = checkOnly
|
|
29
|
+
? await verifyInstallState(env)
|
|
30
|
+
: await installBundledSkills(env);
|
|
31
|
+
const ok = checkOnly ? result.ok : result.ok !== false;
|
|
32
|
+
const payload = checkOnly
|
|
33
|
+
? {
|
|
34
|
+
...result,
|
|
35
|
+
distributionChannel: DISTRIBUTION_CHANNEL,
|
|
36
|
+
pluginRoot: PLUGIN_ROOT,
|
|
37
|
+
}
|
|
38
|
+
: {
|
|
39
|
+
ok,
|
|
40
|
+
installed: result.installed,
|
|
41
|
+
conflicts: result.conflicts ?? [],
|
|
42
|
+
inspection: result.inspection,
|
|
43
|
+
distributionChannel: DISTRIBUTION_CHANNEL,
|
|
44
|
+
pluginRoot: PLUGIN_ROOT,
|
|
45
|
+
};
|
|
46
|
+
|
|
47
|
+
if (!ok) {
|
|
48
|
+
console.error(JSON.stringify(payload, null, 2));
|
|
49
|
+
process.exitCode = 1;
|
|
50
|
+
return;
|
|
51
|
+
}
|
|
52
|
+
|
|
53
|
+
console.log(JSON.stringify(payload, null, 2));
|
|
54
|
+
}
|
|
55
|
+
|
|
56
|
+
await main();
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
import { describe, it } from 'node:test';
|
|
2
|
+
import assert from 'node:assert/strict';
|
|
3
|
+
import { execFile } from 'node:child_process';
|
|
4
|
+
import { mkdtemp, readdir, readFile } from 'node:fs/promises';
|
|
5
|
+
import { promisify } from 'node:util';
|
|
6
|
+
import { tmpdir } from 'node:os';
|
|
7
|
+
import { dirname, join, resolve } from 'node:path';
|
|
8
|
+
import { fileURLToPath } from 'node:url';
|
|
9
|
+
|
|
10
|
+
import { verifyInstallState } from '../../../src/install-discovery.mjs';
|
|
11
|
+
|
|
12
|
+
const execFileAsync = promisify(execFile);
|
|
13
|
+
const MODULE_DIR = dirname(fileURLToPath(import.meta.url));
|
|
14
|
+
const PLUGIN_ROOT = resolve(MODULE_DIR, '..');
|
|
15
|
+
const REPO_ROOT = resolve(PLUGIN_ROOT, '..', '..');
|
|
16
|
+
const MANIFEST_PATH = join(PLUGIN_ROOT, '.codex-plugin', 'plugin.json');
|
|
17
|
+
const INSTALL_SCRIPT = join(MODULE_DIR, 'plugin-install.mjs');
|
|
18
|
+
const ROOT_SKILLS_DIR = join(REPO_ROOT, 'skills');
|
|
19
|
+
const PLUGIN_SKILLS_DIR = join(PLUGIN_ROOT, 'skills');
|
|
20
|
+
const LOOPX_SKILLS = [
|
|
21
|
+
'loopx-clarify',
|
|
22
|
+
'loopx-plan',
|
|
23
|
+
'loopx-build',
|
|
24
|
+
'loopx-review',
|
|
25
|
+
'loopx-autopilot',
|
|
26
|
+
];
|
|
27
|
+
|
|
28
|
+
function loopxEnv(home) {
|
|
29
|
+
return {
|
|
30
|
+
...process.env,
|
|
31
|
+
HOME: home,
|
|
32
|
+
LOOPX_HOME: home,
|
|
33
|
+
LOOPX_AGENTS_ROOT: join(home, '.agents'),
|
|
34
|
+
LOOPX_SKILLS_ROOT: join(home, '.agents', 'skills'),
|
|
35
|
+
LOOPX_SKILL_LOCK_PATH: join(home, '.agents', '.skill-lock.json'),
|
|
36
|
+
LOOPX_PROJECT_ROOT: REPO_ROOT,
|
|
37
|
+
LOOPX_SKILL_SOURCE_ROOT: PLUGIN_SKILLS_DIR,
|
|
38
|
+
};
|
|
39
|
+
}
|
|
40
|
+
|
|
41
|
+
describe('LoopX plugin shell', () => {
|
|
42
|
+
it('defines a plugin manifest that only references plugin-root-relative assets', async () => {
|
|
43
|
+
const manifest = JSON.parse(await readFile(MANIFEST_PATH, 'utf8'));
|
|
44
|
+
const packageJson = JSON.parse(await readFile(join(REPO_ROOT, 'package.json'), 'utf8'));
|
|
45
|
+
const codexPluginEntries = await readdir(join(PLUGIN_ROOT, '.codex-plugin'));
|
|
46
|
+
|
|
47
|
+
assert.deepEqual(codexPluginEntries.sort(), ['plugin.json']);
|
|
48
|
+
assert.equal(manifest.name, 'loopx');
|
|
49
|
+
assert.equal(manifest.version, packageJson.version);
|
|
50
|
+
assert.equal(manifest.skills, './skills/');
|
|
51
|
+
assert.equal(manifest.interface.displayName, 'LoopX');
|
|
52
|
+
|
|
53
|
+
for (const key of ['skills', 'mcpServers', 'apps']) {
|
|
54
|
+
if (typeof manifest[key] === 'string') {
|
|
55
|
+
assert.equal(manifest[key].startsWith('./'), true, `${key} must stay plugin-root-relative`);
|
|
56
|
+
}
|
|
57
|
+
}
|
|
58
|
+
});
|
|
59
|
+
|
|
60
|
+
it('mirrors the canonical LoopX skill payload into the plugin shell', async () => {
|
|
61
|
+
for (const skillName of LOOPX_SKILLS) {
|
|
62
|
+
const rootSkill = await readFile(join(ROOT_SKILLS_DIR, skillName, 'SKILL.md'), 'utf8');
|
|
63
|
+
const pluginSkill = await readFile(join(PLUGIN_SKILLS_DIR, skillName, 'SKILL.md'), 'utf8');
|
|
64
|
+
assert.equal(pluginSkill, rootSkill, skillName);
|
|
65
|
+
}
|
|
66
|
+
});
|
|
67
|
+
|
|
68
|
+
it('reuses the shared install core while materializing skills from the plugin shell', async () => {
|
|
69
|
+
const home = await mkdtemp(join(tmpdir(), 'loopx-plugin-home-'));
|
|
70
|
+
const env = loopxEnv(home);
|
|
71
|
+
|
|
72
|
+
await execFileAsync(process.execPath, [INSTALL_SCRIPT], {
|
|
73
|
+
cwd: REPO_ROOT,
|
|
74
|
+
env,
|
|
75
|
+
});
|
|
76
|
+
|
|
77
|
+
const inspection = await verifyInstallState(env);
|
|
78
|
+
assert.equal(inspection.ok, true);
|
|
79
|
+
for (const skillName of LOOPX_SKILLS) {
|
|
80
|
+
const installedSkill = await readFile(join(home, '.agents', 'skills', skillName, 'SKILL.md'), 'utf8');
|
|
81
|
+
const pluginSkill = await readFile(join(PLUGIN_SKILLS_DIR, skillName, 'SKILL.md'), 'utf8');
|
|
82
|
+
assert.equal(installedSkill, pluginSkill, skillName);
|
|
83
|
+
assert.equal(inspection.inspection.skills[skillName].registryRow.installationIdentity, 'loopx');
|
|
84
|
+
assert.equal(inspection.inspection.skills[skillName].registryRow.distributionChannel, 'plugin');
|
|
85
|
+
assert.equal(inspection.inspection.skills[skillName].registryRow.sourceUrl, PLUGIN_ROOT);
|
|
86
|
+
assert.equal(
|
|
87
|
+
inspection.inspection.skills[skillName].registryRow.provenance.some(
|
|
88
|
+
(entry) => entry.distributionChannel === 'plugin' && entry.sourceUrl === PLUGIN_ROOT,
|
|
89
|
+
),
|
|
90
|
+
true,
|
|
91
|
+
);
|
|
92
|
+
}
|
|
93
|
+
});
|
|
94
|
+
});
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# LoopX Autopilot
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Repo-local bounded composition surface for LoopX. Use it when one owner wants the workflow to run end-to-end through clarify, plan, build, and review with the same stage gates still enforced.
|
|
6
|
+
|
|
7
|
+
## Composition
|
|
8
|
+
|
|
9
|
+
`loopx-autopilot` is a wrapper over:
|
|
10
|
+
|
|
11
|
+
- `loopx-clarify`
|
|
12
|
+
- `loopx-plan`
|
|
13
|
+
- `loopx-build`
|
|
14
|
+
- `loopx-review`
|
|
15
|
+
|
|
16
|
+
## Decision Boundary
|
|
17
|
+
|
|
18
|
+
- Use this when the task should stay on the repo-local LoopX path from ambiguity reduction through acceptance.
|
|
19
|
+
- Stop at the first blocked stage. `loopx-autopilot` does not bypass approvals or continue past failed verification.
|
|
20
|
+
|
|
21
|
+
## Must Not Decide Automatically
|
|
22
|
+
|
|
23
|
+
- skipping a stage gate because the downstream task looks obvious
|
|
24
|
+
- switching into a `team` lane or any parallel multi-agent dependency
|
|
25
|
+
- treating CLI helpers as the primary product surface
|
|
26
|
+
|
|
27
|
+
## Notes
|
|
28
|
+
|
|
29
|
+
- `loopx-autopilot` is intentionally bounded. It documents composition over the four repo-local LoopX stages only.
|
|
30
|
+
- The CLI remains supporting runtime and debug tooling, not the main release surface.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# LoopX Build
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Repo-local execution surface for LoopX. Use it to implement an approved plan and capture fresh verification evidence for the current run.
|
|
6
|
+
|
|
7
|
+
## Expected Outputs
|
|
8
|
+
|
|
9
|
+
- execution artifacts for the active LoopX run
|
|
10
|
+
- verification evidence tied to the implementation run
|
|
11
|
+
- stage status that shows readiness or blockers for review
|
|
12
|
+
|
|
13
|
+
## Decision Boundary
|
|
14
|
+
|
|
15
|
+
- Use this only after planning is complete and approved.
|
|
16
|
+
- Stop here if execution or verification is incomplete. `loopx-build` can recommend follow-up work, but it does not self-approve review.
|
|
17
|
+
|
|
18
|
+
## Must Not Decide Automatically
|
|
19
|
+
|
|
20
|
+
- review approval
|
|
21
|
+
- rollback or completion decisions
|
|
22
|
+
|
|
23
|
+
## Notes
|
|
24
|
+
|
|
25
|
+
- `loopx-build` is the active release execution surface. There is no public `team` execution lane in this repo-local skill set.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# LoopX Clarify
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Repo-local clarify surface for LoopX. Use it to turn a vague request into an execution-ready spec before planning or build work starts.
|
|
6
|
+
|
|
7
|
+
## Expected Outputs
|
|
8
|
+
|
|
9
|
+
- a clarify spec under the LoopX workspace
|
|
10
|
+
- an explicit ambiguity list with unresolved items called out
|
|
11
|
+
- stage status that makes the next action visible
|
|
12
|
+
|
|
13
|
+
## Decision Boundary
|
|
14
|
+
|
|
15
|
+
- Use this first when scope, acceptance, constraints, or verification are still unclear.
|
|
16
|
+
- Stop here if unresolved ambiguity remains. `loopx-clarify` does not advance into planning on its own.
|
|
17
|
+
|
|
18
|
+
## Must Not Decide Automatically
|
|
19
|
+
|
|
20
|
+
- approval to move from clarify into plan
|
|
21
|
+
- implementation details that were not established in the clarify output
|
|
22
|
+
|
|
23
|
+
## Notes
|
|
24
|
+
|
|
25
|
+
- This is a skill-first surface. Any CLI entrypoints are supporting runtime or debug helpers, not the primary product surface.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# LoopX Plan
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Repo-local planning surface for LoopX. Use it to turn an approved clarify result into a concrete execution package.
|
|
6
|
+
|
|
7
|
+
## Expected Outputs
|
|
8
|
+
|
|
9
|
+
- a plan package under the LoopX workspace
|
|
10
|
+
- explicit architecture, execution, and verification guidance
|
|
11
|
+
- stage status that shows whether build is unblocked
|
|
12
|
+
|
|
13
|
+
## Decision Boundary
|
|
14
|
+
|
|
15
|
+
- Use this only after clarify has produced a usable spec.
|
|
16
|
+
- Stop here if the plan package is incomplete or still awaiting approval. `loopx-plan` does not start execution on its own.
|
|
17
|
+
|
|
18
|
+
## Must Not Decide Automatically
|
|
19
|
+
|
|
20
|
+
- whether to skip straight to implementation without a complete plan
|
|
21
|
+
- whether execution is approved
|
|
22
|
+
|
|
23
|
+
## Notes
|
|
24
|
+
|
|
25
|
+
- Keep the output artifact-bound and implementation-grounded. The plan should feed `loopx-build` or `loopx-autopilot`, not invent a separate workflow surface.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# LoopX Review
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Repo-local acceptance surface for LoopX. Use it to evaluate the execution package from `loopx-build` and return an explicit go / no-go result.
|
|
6
|
+
|
|
7
|
+
## Expected Outputs
|
|
8
|
+
|
|
9
|
+
- a review artifact tied to the run being evaluated
|
|
10
|
+
- verdict and rationale
|
|
11
|
+
- rollback guidance when execution is incomplete or unstable
|
|
12
|
+
|
|
13
|
+
## Decision Boundary
|
|
14
|
+
|
|
15
|
+
- Use this only after build has produced execution and verification evidence for a specific run.
|
|
16
|
+
- Stop here if review evidence is incomplete. `loopx-review` remains an independent gate and does not auto-complete the workflow.
|
|
17
|
+
|
|
18
|
+
## Must Not Decide Automatically
|
|
19
|
+
|
|
20
|
+
- final completion without an explicit approval step
|
|
21
|
+
- re-running build work inside the review surface
|
|
22
|
+
|
|
23
|
+
## Notes
|
|
24
|
+
|
|
25
|
+
- Review consumes structured outputs from the active LoopX run. It should reject thin or placeholder-only evidence.
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
|
|
3
|
+
import { installBundledSkills, verifyInstallState } from '../src/install-discovery.mjs';
|
|
4
|
+
|
|
5
|
+
async function main() {
|
|
6
|
+
const checkOnly = process.argv.includes('--check');
|
|
7
|
+
const result = checkOnly ? await verifyInstallState(process.env) : await installBundledSkills(process.env);
|
|
8
|
+
const ok = checkOnly ? result.ok : result.ok !== false;
|
|
9
|
+
const payload = checkOnly ? result : { ok, installed: result.installed, conflicts: result.conflicts ?? [], inspection: result.inspection };
|
|
10
|
+
if (!ok) {
|
|
11
|
+
console.error(JSON.stringify(payload, null, 2));
|
|
12
|
+
process.exitCode = 1;
|
|
13
|
+
return;
|
|
14
|
+
}
|
|
15
|
+
console.log(JSON.stringify(payload, null, 2));
|
|
16
|
+
}
|
|
17
|
+
|
|
18
|
+
await main();
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# LoopX Autopilot
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Repo-local bounded composition surface for LoopX. Use it when one owner wants the workflow to run end-to-end through clarify, plan, build, and review with the same stage gates still enforced.
|
|
6
|
+
|
|
7
|
+
## Composition
|
|
8
|
+
|
|
9
|
+
`loopx-autopilot` is a wrapper over:
|
|
10
|
+
|
|
11
|
+
- `loopx-clarify`
|
|
12
|
+
- `loopx-plan`
|
|
13
|
+
- `loopx-build`
|
|
14
|
+
- `loopx-review`
|
|
15
|
+
|
|
16
|
+
## Decision Boundary
|
|
17
|
+
|
|
18
|
+
- Use this when the task should stay on the repo-local LoopX path from ambiguity reduction through acceptance.
|
|
19
|
+
- Stop at the first blocked stage. `loopx-autopilot` does not bypass approvals or continue past failed verification.
|
|
20
|
+
|
|
21
|
+
## Must Not Decide Automatically
|
|
22
|
+
|
|
23
|
+
- skipping a stage gate because the downstream task looks obvious
|
|
24
|
+
- switching into a `team` lane or any parallel multi-agent dependency
|
|
25
|
+
- treating CLI helpers as the primary product surface
|
|
26
|
+
|
|
27
|
+
## Notes
|
|
28
|
+
|
|
29
|
+
- `loopx-autopilot` is intentionally bounded. It documents composition over the four repo-local LoopX stages only.
|
|
30
|
+
- The CLI remains supporting runtime and debug tooling, not the main release surface.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# LoopX Build
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Repo-local execution surface for LoopX. Use it to implement an approved plan and capture fresh verification evidence for the current run.
|
|
6
|
+
|
|
7
|
+
## Expected Outputs
|
|
8
|
+
|
|
9
|
+
- execution artifacts for the active LoopX run
|
|
10
|
+
- verification evidence tied to the implementation run
|
|
11
|
+
- stage status that shows readiness or blockers for review
|
|
12
|
+
|
|
13
|
+
## Decision Boundary
|
|
14
|
+
|
|
15
|
+
- Use this only after planning is complete and approved.
|
|
16
|
+
- Stop here if execution or verification is incomplete. `loopx-build` can recommend follow-up work, but it does not self-approve review.
|
|
17
|
+
|
|
18
|
+
## Must Not Decide Automatically
|
|
19
|
+
|
|
20
|
+
- review approval
|
|
21
|
+
- rollback or completion decisions
|
|
22
|
+
|
|
23
|
+
## Notes
|
|
24
|
+
|
|
25
|
+
- `loopx-build` is the active release execution surface. There is no public `team` execution lane in this repo-local skill set.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# LoopX Clarify
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Repo-local clarify surface for LoopX. Use it to turn a vague request into an execution-ready spec before planning or build work starts.
|
|
6
|
+
|
|
7
|
+
## Expected Outputs
|
|
8
|
+
|
|
9
|
+
- a clarify spec under the LoopX workspace
|
|
10
|
+
- an explicit ambiguity list with unresolved items called out
|
|
11
|
+
- stage status that makes the next action visible
|
|
12
|
+
|
|
13
|
+
## Decision Boundary
|
|
14
|
+
|
|
15
|
+
- Use this first when scope, acceptance, constraints, or verification are still unclear.
|
|
16
|
+
- Stop here if unresolved ambiguity remains. `loopx-clarify` does not advance into planning on its own.
|
|
17
|
+
|
|
18
|
+
## Must Not Decide Automatically
|
|
19
|
+
|
|
20
|
+
- approval to move from clarify into plan
|
|
21
|
+
- implementation details that were not established in the clarify output
|
|
22
|
+
|
|
23
|
+
## Notes
|
|
24
|
+
|
|
25
|
+
- This is a skill-first surface. Any CLI entrypoints are supporting runtime or debug helpers, not the primary product surface.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# LoopX Plan
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Repo-local planning surface for LoopX. Use it to turn an approved clarify result into a concrete execution package.
|
|
6
|
+
|
|
7
|
+
## Expected Outputs
|
|
8
|
+
|
|
9
|
+
- a plan package under the LoopX workspace
|
|
10
|
+
- explicit architecture, execution, and verification guidance
|
|
11
|
+
- stage status that shows whether build is unblocked
|
|
12
|
+
|
|
13
|
+
## Decision Boundary
|
|
14
|
+
|
|
15
|
+
- Use this only after clarify has produced a usable spec.
|
|
16
|
+
- Stop here if the plan package is incomplete or still awaiting approval. `loopx-plan` does not start execution on its own.
|
|
17
|
+
|
|
18
|
+
## Must Not Decide Automatically
|
|
19
|
+
|
|
20
|
+
- whether to skip straight to implementation without a complete plan
|
|
21
|
+
- whether execution is approved
|
|
22
|
+
|
|
23
|
+
## Notes
|
|
24
|
+
|
|
25
|
+
- Keep the output artifact-bound and implementation-grounded. The plan should feed `loopx-build` or `loopx-autopilot`, not invent a separate workflow surface.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# LoopX Review
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Repo-local acceptance surface for LoopX. Use it to evaluate the execution package from `loopx-build` and return an explicit go / no-go result.
|
|
6
|
+
|
|
7
|
+
## Expected Outputs
|
|
8
|
+
|
|
9
|
+
- a review artifact tied to the run being evaluated
|
|
10
|
+
- verdict and rationale
|
|
11
|
+
- rollback guidance when execution is incomplete or unstable
|
|
12
|
+
|
|
13
|
+
## Decision Boundary
|
|
14
|
+
|
|
15
|
+
- Use this only after build has produced execution and verification evidence for a specific run.
|
|
16
|
+
- Stop here if review evidence is incomplete. `loopx-review` remains an independent gate and does not auto-complete the workflow.
|
|
17
|
+
|
|
18
|
+
## Must Not Decide Automatically
|
|
19
|
+
|
|
20
|
+
- final completion without an explicit approval step
|
|
21
|
+
- re-running build work inside the review surface
|
|
22
|
+
|
|
23
|
+
## Notes
|
|
24
|
+
|
|
25
|
+
- Review consumes structured outputs from the active LoopX run. It should reject thin or placeholder-only evidence.
|