ralphctl 0.15.1 → 0.16.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/dist/agent-definitions/ralphctl-evaluator.md +32 -0
- package/dist/agent-definitions/ralphctl-generator.md +33 -0
- package/dist/{cli-2XQNS26Z.mjs → cli-KZ4IYDKB.mjs} +1978 -806
- package/dist/cli.mjs +1 -1
- package/dist/manifest.json +5 -2
- package/dist/prompts/evaluate/template.md +2 -0
- package/dist/prompts/implement/template.md +2 -0
- package/dist/skills/ralphctl-minimal-scaffolding/SKILL.md +33 -32
- package/package.json +12 -12
package/dist/cli.mjs
CHANGED
package/dist/manifest.json
CHANGED
|
@@ -1,7 +1,10 @@
|
|
|
1
1
|
{
|
|
2
|
-
"
|
|
3
|
-
"
|
|
2
|
+
"schemaVersion": 1,
|
|
3
|
+
"packageVersion": "0.16.0",
|
|
4
|
+
"generatedAt": "2026-07-18T13:59:00.834Z",
|
|
4
5
|
"assets": [
|
|
6
|
+
"agent-definitions/ralphctl-evaluator.md",
|
|
7
|
+
"agent-definitions/ralphctl-generator.md",
|
|
5
8
|
"prompts/_partials/conventions-agents-md.md",
|
|
6
9
|
"prompts/_partials/conventions-claude-md.md",
|
|
7
10
|
"prompts/_partials/conventions-copilot-instructions.md",
|
|
@@ -1,58 +1,59 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ralphctl-minimal-scaffolding
|
|
3
|
-
description: Cross-phase skill — question every
|
|
3
|
+
description: Cross-phase skill — question every piece of AI-workflow scaffolding on every model upgrade; remove non-load-bearing pieces one at a time with measurement. Complexity drifts upward by default; subtraction requires discipline. Governs scaffolding built around AI usage (prompts, wrapper scripts, guardrails, validation steps), not the task's application code — for code-level minimalism defer to the ralphctl-ponytail, ralphctl-surgical-simplicity, and ralphctl-karpathy-guidelines skills when installed in this session.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Minimal Scaffolding
|
|
7
7
|
|
|
8
8
|
> "Find the simplest solution possible, and only increase complexity when needed. Every component encodes
|
|
9
9
|
> assumptions about model limitations. Stress-test assumptions; they can go stale quickly as models improve.
|
|
10
|
-
> Remove one component at a time when simplifying. Re-examine
|
|
11
|
-
> non-load-bearing pieces."
|
|
10
|
+
> Remove one component at a time when simplifying. Re-examine the whole system when a new model releases;
|
|
11
|
+
> strip non-load-bearing pieces."
|
|
12
12
|
>
|
|
13
13
|
> — Anthropic, [_Harness Design for Long-Running Application Development_](https://www.anthropic.com/engineering/harness-design-long-running-apps)
|
|
14
14
|
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
15
|
+
Scaffolding built around AI usage — prompts, wrapper scripts, extra validation steps, guardrails — drifts
|
|
16
|
+
upward in complexity by default. Each piece that solves a real problem at the time of its addition becomes a
|
|
17
|
+
permanent fixture, even after the model capability that made it necessary has improved past the threshold.
|
|
18
|
+
Without an active counter-pressure, the scaffolding grows into a weight that slows iteration and obscures the
|
|
19
|
+
actual design signal. Minimal scaffolding is not a one-time decision at design time; it is a discipline
|
|
20
|
+
applied on every model upgrade and on every proposed addition.
|
|
20
21
|
|
|
21
22
|
## When this applies
|
|
22
23
|
|
|
23
|
-
- **Refine** — before proposing that the
|
|
24
|
-
step, ask whether the model would produce the right output
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
24
|
+
- **Refine** — before proposing that the requirements need an extra review gate, an extra validation pass,
|
|
25
|
+
or an approval step to compensate for the model, ask whether the model would produce the right output
|
|
26
|
+
without it given a well-scoped prompt.
|
|
27
|
+
- **Plan** — before adding an extra AI-assisted review step or splitting the work into more stages, ask
|
|
28
|
+
whether the additional structure would improve output quality measurably, or whether it is defensive
|
|
29
|
+
scaffolding against a past model's limitations.
|
|
30
|
+
- **Execute** — before wiring a new wrapper, guard clause, or retry layer around an existing AI-assisted
|
|
31
|
+
check, ask which assumption about current model capability the addition encodes, and whether that
|
|
32
|
+
assumption is still valid.
|
|
31
33
|
|
|
32
34
|
## What to do
|
|
33
35
|
|
|
34
36
|
1. **Start with the simplest viable shape.** Draft the simplest version that could work given today's model
|
|
35
37
|
capability. Only add components when the simple version demonstrably fails.
|
|
36
|
-
2. **Question every component on every model
|
|
37
|
-
|
|
38
|
-
ask: "Would removing this component degrade output quality on the new model?" If the answer is
|
|
39
|
-
run the test.
|
|
40
|
-
3. **Remove one component at a time, measure.** Never
|
|
41
|
-
isolate the regression. Remove one; run the project's check gate; observe output quality; decide.
|
|
38
|
+
2. **Question every component on every model upgrade.** When a new model version ships, re-read the
|
|
39
|
+
project's own notes on why each piece of AI-workflow scaffolding exists, if the project keeps them. For
|
|
40
|
+
each one, ask: "Would removing this component degrade output quality on the new model?" If the answer is
|
|
41
|
+
uncertain, run the test.
|
|
42
|
+
3. **Remove one component at a time, measure.** Never remove two pieces of scaffolding simultaneously — you
|
|
43
|
+
cannot isolate the regression. Remove one; run the project's check gate; observe output quality; decide.
|
|
42
44
|
4. **Default toward subtraction over addition.** When in doubt, omit. Adding a component later when its
|
|
43
45
|
need is proven is cheaper than carrying a component whose need was assumed.
|
|
44
46
|
|
|
45
47
|
## Anti-patterns
|
|
46
48
|
|
|
47
|
-
- **Stacking
|
|
48
|
-
and a
|
|
49
|
-
encodes
|
|
50
|
-
- **Treating scaffolding as load-bearing without measurement.** "We've always had
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
- **Mass refactors that change more than one
|
|
54
|
-
|
|
55
|
-
at a time.
|
|
49
|
+
- **Stacking guardrails "just in case".** Adding a validation wrapper around a check, a retry loop around
|
|
50
|
+
the wrapper, and a review gate around the retry loop — each layer may have been justified at the time, but
|
|
51
|
+
the stack encodes several separate assumptions, each of which needs re-validation on every model upgrade.
|
|
52
|
+
- **Treating scaffolding as load-bearing without measurement.** "We've always had this check" is not a
|
|
53
|
+
reason to keep it — it is a reason to measure whether it still fires in practice. If it never fires on the
|
|
54
|
+
current model, it may be removable.
|
|
55
|
+
- **Mass refactors that change more than one piece of scaffolding at a time.** Removing two guardrails in
|
|
56
|
+
the same change makes it impossible to attribute a quality change to either. One piece at a time.
|
|
56
57
|
- **Never re-auditing existing scaffolding when models get better.** Capability improvements accrue quietly.
|
|
57
58
|
A component that was essential for an older model may be transparently handled by a newer one. Without an
|
|
58
|
-
explicit re-audit cadence,
|
|
59
|
+
explicit re-audit cadence, AI-workflow scaffolding ossifies around old assumptions.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "ralphctl",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.16.0",
|
|
4
4
|
"description": "Agent harness for long-running AI coding tasks — orchestrates Claude Code, GitHub Copilot, and OpenAI Codex across repositories",
|
|
5
5
|
"homepage": "https://github.com/lukas-grigis/ralphctl",
|
|
6
6
|
"type": "module",
|
|
@@ -45,34 +45,34 @@
|
|
|
45
45
|
"dependencies": {
|
|
46
46
|
"commander": "^15.0.0",
|
|
47
47
|
"cross-spawn": "^7.0.6",
|
|
48
|
-
"ink": "^7.
|
|
48
|
+
"ink": "^7.1.1",
|
|
49
49
|
"proper-lockfile": "^4.1.2",
|
|
50
|
-
"react": "^19.2.
|
|
50
|
+
"react": "^19.2.7",
|
|
51
51
|
"typescript-result": "^3.5.2",
|
|
52
52
|
"zod": "^4.4.3"
|
|
53
53
|
},
|
|
54
54
|
"devDependencies": {
|
|
55
55
|
"@eslint/js": "^10.0.1",
|
|
56
56
|
"@types/cross-spawn": "^6.0.6",
|
|
57
|
-
"@types/node": "^26.
|
|
57
|
+
"@types/node": "^26.1.1",
|
|
58
58
|
"@types/proper-lockfile": "^4.1.4",
|
|
59
|
-
"@types/react": "^19.2.
|
|
60
|
-
"@vitest/coverage-v8": "^4.1.
|
|
59
|
+
"@types/react": "^19.2.17",
|
|
60
|
+
"@vitest/coverage-v8": "^4.1.10",
|
|
61
61
|
"eslint": "^10.4.0",
|
|
62
62
|
"eslint-plugin-react-hooks": "^7.1.1",
|
|
63
63
|
"eslint-plugin-sonarjs": "^4.0.3",
|
|
64
|
-
"globals": "^17.
|
|
64
|
+
"globals": "^17.7.0",
|
|
65
65
|
"husky": "^9.1.7",
|
|
66
66
|
"ink-testing-library": "^4.0.0",
|
|
67
67
|
"jiti": "^2.7.0",
|
|
68
|
-
"knip": "^6.
|
|
69
|
-
"lint-staged": "^17.0.
|
|
70
|
-
"prettier": "^3.
|
|
68
|
+
"knip": "^6.27.0",
|
|
69
|
+
"lint-staged": "^17.0.8",
|
|
70
|
+
"prettier": "^3.9.5",
|
|
71
71
|
"tsup": "^8.5.1",
|
|
72
|
-
"tsx": "^4.
|
|
72
|
+
"tsx": "^4.23.1",
|
|
73
73
|
"typescript": "^6.0.3",
|
|
74
74
|
"typescript-eslint": "^8.59.3",
|
|
75
|
-
"vitest": "^4.1.
|
|
75
|
+
"vitest": "^4.1.10"
|
|
76
76
|
},
|
|
77
77
|
"lint-staged": {
|
|
78
78
|
"*.{ts,tsx}": [
|