holycodex 0.4.6 → 0.5.1
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 +7 -7
- package/marketplace.json +1 -1
- package/package.json +1 -1
- package/plugin/.codex-plugin/plugin.json +3 -3
- package/plugin/.mcp.json +0 -1
- package/plugin/agents/explorer.toml +2 -2
- package/plugin/agents/librarian.toml +2 -2
- package/plugin/agents/worker.toml +2 -2
- package/plugin/runtime/cli.js +2 -2
- package/plugin/runtime/core-instructions.js +1 -1
- package/plugin/runtime/git-bash.js +5 -5
- package/plugin/runtime/lsp.js +1 -1
- package/plugin/runtime/rules.js +26 -5
- package/plugin/skills/ast-grep/SKILL.md +1 -1
- package/plugin/skills/caveman/SKILL.md +1 -1
- package/plugin/skills/compress/SKILL.md +1 -1
- package/plugin/skills/debugging/SKILL.md +1 -1
- package/plugin/skills/define-goal/SKILL.md +8 -7
- package/plugin/skills/frontend/SKILL.md +21 -21
- package/plugin/skills/handoff/SKILL.md +1 -1
- package/plugin/skills/lsp/SKILL.md +1 -1
- package/plugin/skills/lsp-setup/SKILL.md +1 -1
- package/plugin/skills/plan/SKILL.md +13 -3
- package/plugin/skills/plan-review/SKILL.md +12 -2
- package/plugin/skills/programming/SKILL.md +2 -2
- package/plugin/skills/refactor/SKILL.md +1 -1
- package/plugin/skills/remove-ai-slops/SKILL.md +1 -1
- package/plugin/skills/rules/SKILL.md +2 -2
- package/plugin/skills/security-research/SKILL.md +1 -1
- package/plugin/skills/comment-checker/SKILL.md +0 -8
- package/plugin/skills/tdd/SKILL.md +0 -24
- package/plugin/skills/tdd/mocking.md +0 -5
- package/plugin/skills/tdd/tests.md +0 -7
package/README.md
CHANGED
|
@@ -6,23 +6,23 @@ HolyCodex is a modified, standalone Codex-only hard fork of [oh-my-openagent](ht
|
|
|
6
6
|
|
|
7
7
|
HolyCodex installs one focused Codex toolkit:
|
|
8
8
|
|
|
9
|
-
-
|
|
9
|
+
- 16 on-demand skills for programming, debugging, frontend, LSP, AST search, security research, planning, handoffs, goal definition, compression, and related workflows.
|
|
10
10
|
- Three optional subagents: `explorer` for internal inspection, `librarian` for external research, and `worker` for bounded implementation.
|
|
11
|
-
-
|
|
11
|
+
- Three MCP defaults: `git_bash`, `lsp`, and `context7`.
|
|
12
12
|
- Small command hooks for readiness and scoped rules.
|
|
13
13
|
- A Node-compatible installer and prebuilt runtime usable through npm or Bun.
|
|
14
14
|
|
|
15
|
-
The primary agent
|
|
15
|
+
The primary agent owns intent, scope, architecture, decisions, integration, and final verification. Subagents only reduce cost on narrow independent work; skills own their declared methods and gates.
|
|
16
16
|
|
|
17
17
|
## Why
|
|
18
18
|
|
|
19
19
|
Large always-on prompts, agent hierarchies, review loops, and duplicated context consume tokens before useful work begins. HolyCodex takes a smaller approach:
|
|
20
20
|
|
|
21
|
-
- Skills load only when
|
|
22
|
-
- Descriptions explain both what each capability does and when to use it.
|
|
21
|
+
- Skills load only when descriptions match the task and state activation, exclusions, outcome, and adjacent boundary.
|
|
23
22
|
- Rules are path-scoped, size-limited, cached, and deduplicated; `AGENTS.md` is never reinjected.
|
|
24
|
-
-
|
|
25
|
-
-
|
|
23
|
+
- Concurrent delegation is capped at two; every delegated slice has fixed scope, evidence, acceptance, and stop conditions under primary-agent control.
|
|
24
|
+
- Explorer and librarian use GPT-5.6 Luna low; worker uses GPT-5.6 Luna medium.
|
|
25
|
+
- Git Bash shell execution is required only on native Windows when its MCP run tool is available; other environments use their native shell directly.
|
|
26
26
|
- OMO workflows and retained references are rewritten with caveman-style token efficiency.
|
|
27
27
|
- The OMO frontend skill is merged with GPT Taste instead of shipping another overlapping skill.
|
|
28
28
|
|
package/marketplace.json
CHANGED
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "holycodex",
|
|
3
|
-
"version": "0.
|
|
4
|
-
"description": "Lean Codex
|
|
3
|
+
"version": "0.5.1",
|
|
4
|
+
"description": "Lean Codex workflows with routed skills, bounded subagents, scoped rules, Git Bash, and LSP.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "David Basile Filho",
|
|
7
7
|
"url": "https://github.com/davidbasilefilho"
|
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
"interface": {
|
|
15
15
|
"displayName": "HolyCodex",
|
|
16
16
|
"shortDescription": "Codex agents, routed skills, scoped rules, Git Bash, LSP, code search, and docs lookup.",
|
|
17
|
-
"longDescription": "Use HolyCodex
|
|
17
|
+
"longDescription": "Use HolyCodex for repository work needing routed engineering workflows, Windows shell reliability, or semantic code tools. Skills own their declared methods and gates; the main agent owns decisions, integration, and verification. Delegate only narrow independent repository facts, current external facts, or isolated implementation; do not delegate trivial, coupled, ambiguous, architectural, or final-responsibility work.",
|
|
18
18
|
"defaultPrompt": "Use HolyCodex to implement and verify this task.",
|
|
19
19
|
"developerName": "David Basile Filho",
|
|
20
20
|
"category": "Developer Tools",
|
package/plugin/.mcp.json
CHANGED
|
@@ -2,7 +2,6 @@
|
|
|
2
2
|
"mcpServers": {
|
|
3
3
|
"git_bash": { "command": "node", "args": ["runtime/git-bash.js", "mcp"], "cwd": "." },
|
|
4
4
|
"lsp": { "command": "node", "args": ["runtime/lsp.js", "mcp"], "cwd": "." },
|
|
5
|
-
"grep_app": { "url": "https://mcp.grep.app" },
|
|
6
5
|
"context7": { "url": "https://mcp.context7.com/mcp" }
|
|
7
6
|
}
|
|
8
7
|
}
|
|
@@ -1,6 +1,6 @@
|
|
|
1
|
-
description = "Use for read-only
|
|
1
|
+
description = "Use for a narrow, read-only repository fact question with explicit scope; do not use for edits, external research, architecture, or final decisions. Returns cited paths, symbols, history, or diagnostics for main-agent integration."
|
|
2
2
|
model = "gpt-5.6-luna"
|
|
3
3
|
model_reasoning_effort = "low"
|
|
4
4
|
developer_instructions = """
|
|
5
|
-
Start: "I detect investigation intent — [reason]. [action]." Default user-facing replies: grammatical sentences; no filler or hedging. Preserve technical terms, code, paths, error text, and commit keywords; use full grammar for safety warnings, irreversible confirmations, ordered steps, ambiguity, or clarification.
|
|
5
|
+
Start: "I detect investigation intent — [reason]. [action]." Default user-facing replies: grammatical sentences; no filler or hedging. Preserve technical terms, code, paths, error text, and commit keywords; use full grammar for safety warnings, irreversible confirmations, ordered steps, ambiguity, or clarification. Accept one task packet containing exact question; repository root; allowed paths and symbols; forbidden paths; relevant architecture and existing behavior; required skills; exact inputs; output format; acceptance criteria; required commands or evidence; unchanged constraints; prohibited expansion; known uncertainty; blocker behavior; exact stop condition. Reject incomplete or ambiguous packets. Inspect only assigned scope. On native Windows use git_bash MCP when its run tool is available; otherwise use native shell directly without probing git_bash. Search, read, diagnose, or inspect history; never edit, install, research external facts, choose architecture, make final judgments, ask user, or broaden scope. Stop when criteria pass, evidence is unavailable, scope conflicts, or a write is required. Return exactly requested format with paths, symbols, commands, decisive output, uncertainty or blocker; no proposed extra work.
|
|
6
6
|
"""
|
|
@@ -1,6 +1,6 @@
|
|
|
1
|
-
description = "Use for
|
|
1
|
+
description = "Use for a narrow current external-fact question requiring primary sources; do not use for repository inspection, implementation, architecture, or final decisions. Returns dated, cited findings for main-agent integration."
|
|
2
2
|
model = "gpt-5.6-luna"
|
|
3
3
|
model_reasoning_effort = "low"
|
|
4
4
|
developer_instructions = """
|
|
5
|
-
Start: "I detect research intent — [reason]. [action]." Default user-facing replies: grammatical sentences; no filler or hedging. Preserve technical terms, code, paths, error text, and commit keywords; use full grammar for safety warnings, irreversible confirmations, ordered steps, ambiguity, or clarification.
|
|
5
|
+
Start: "I detect research intent — [reason]. [action]." Default user-facing replies: grammatical sentences; no filler or hedging. Preserve technical terms, code, paths, error text, and commit keywords; use full grammar for safety warnings, irreversible confirmations, ordered steps, ambiguity, or clarification. Accept one task packet containing exact question; repository root only as context; allowed paths and symbols, normally none; forbidden paths and sources; allowed external sources; relevant architecture and existing behavior; required skills; exact inputs; output format; acceptance criteria; required commands or evidence; unchanged constraints; prohibited expansion; known uncertainty; blocker behavior; exact stop condition. Reject incomplete or ambiguous packets. On native Windows use git_bash MCP when its run tool is available; otherwise use native shell directly without probing git_bash. Prefer current primary sources; distinguish source fact from inference. Never inspect repo beyond supplied context, implement, write externally, choose architecture, make final judgments, ask user, or broaden scope. Stop when criteria pass, authoritative evidence is unavailable or conflicting, or answer needs repository work. Return exactly requested format with claim-linked source, version or date, conflicts, inference, uncertainty or blocker; no proposed extra work.
|
|
6
6
|
"""
|
|
@@ -1,6 +1,6 @@
|
|
|
1
|
-
description = "Use for isolated
|
|
1
|
+
description = "Use for an isolated implementation slice with fixed files and acceptance criteria; do not use for discovery, architecture, ambiguous or coupled changes, integration, or final verification. Returns a minimal tested patch for main-agent review."
|
|
2
2
|
model = "gpt-5.6-luna"
|
|
3
3
|
model_reasoning_effort = "medium"
|
|
4
4
|
developer_instructions = """
|
|
5
|
-
Start: "I detect implementation intent — [reason]. [action]." Default user-facing replies: grammatical sentences; no filler or hedging. Preserve technical terms, code, paths, error text, and commit keywords; use full grammar for safety warnings, irreversible confirmations, ordered steps, ambiguity, or clarification.
|
|
5
|
+
Start: "I detect implementation intent — [reason]. [action]." Default user-facing replies: grammatical sentences; no filler or hedging. Preserve technical terms, code, paths, error text, and commit keywords; use full grammar for safety warnings, irreversible confirmations, ordered steps, ambiguity, or clarification. Accept one task packet containing exact implementation outcome; repository root; allowed paths and symbols; forbidden paths; relevant architecture and existing behavior; required skills; exact inputs; output format; acceptance criteria; required commands or evidence; unchanged constraints; prohibited expansion; known uncertainty; blocker behavior; exact stop condition. Reject or stop on ambiguity, overlap, architecture choice, coupled out-of-scope work, user-work conflict, or missing authority. On native Windows use git_bash MCP when its run tool is available; otherwise use native shell directly without probing git_bash. Prompt, skill, or instruction task: load caveman first; preserve constraints. Load required skills before governed action. Change only assigned files. Preserve architecture, API, behavior, naming, style, and user work. Add no speculative cleanup, abstraction, dependency, docs, or scope. Run specified proof; never claim integration or final verification. Return exactly requested format with changed paths and behavior, command results, criteria status, blocker or residual risk; no proposed extra work.
|
|
6
6
|
"""
|
package/plugin/runtime/cli.js
CHANGED
|
@@ -122,7 +122,7 @@ function paths(home = process.env.CODEX_HOME ?? join(homedir(), ".codex")) {
|
|
|
122
122
|
config: join(home, "config.toml"),
|
|
123
123
|
marketplaceCache,
|
|
124
124
|
cacheRoot,
|
|
125
|
-
cache: join(cacheRoot, "0.
|
|
125
|
+
cache: join(cacheRoot, "0.5.1"),
|
|
126
126
|
agents: join(home, "holycodex", "agents"),
|
|
127
127
|
legacy: [
|
|
128
128
|
join(home, "plugins", "cache", "sisyphuslabs", "omo"),
|
|
@@ -210,7 +210,7 @@ async function cleanup(_options) {
|
|
|
210
210
|
}
|
|
211
211
|
//#endregion
|
|
212
212
|
//#region src/cli.ts
|
|
213
|
-
var VERSION = "0.
|
|
213
|
+
var VERSION = "0.5.1";
|
|
214
214
|
var HELP = `HolyCodex ${VERSION}\n\nUsage: holycodex <install|cleanup> [options]\n\nOptions:\n --help Show help\n --version Show version\n --no-tui Accepted; commands are noninteractive\n --codex-autonomous Set autonomous Codex permissions (default)\n --no-codex-autonomous Preserve existing Codex permissions\n --json Print machine-readable result\n`;
|
|
215
215
|
async function main() {
|
|
216
216
|
const args = process$1.argv.slice(2);
|
|
@@ -1,4 +1,4 @@
|
|
|
1
1
|
//#region src/core-instructions.ts
|
|
2
|
-
var CORE_INSTRUCTIONS = "HolyCodex: Start first user-facing update: \"I detect [fix/implementation/investigation/question] intent — [reason]. [action].\" Act. Default user-facing replies: grammatical sentences; no filler or hedging. Preserve technical terms, code, paths, error text, and commit keywords; use full grammar for safety warnings, irreversible confirmations, ordered steps, ambiguity, or clarification. Shell:
|
|
2
|
+
var CORE_INSTRUCTIONS = "HolyCodex: Start first user-facing update: \"I detect [fix/implementation/investigation/question] intent — [reason]. [action].\" Act. Default user-facing replies: grammatical sentences; no filler or hedging. Preserve technical terms, code, paths, error text, and commit keywords; use full grammar for safety warnings, irreversible confirmations, ordered steps, ambiguity, or clarification. Shell: on native Windows, use git_bash MCP for shell commands when its run tool is available; otherwise use the native shell directly without probing git_bash. Prompt, skill, or instruction edit: load caveman; preserve constraints. Main agent owns intent, scope, architecture, decisions, integration, and final verification. Load each applicable skill before its governed action; a skill alone is sufficient when the main agent can complete the work directly. Delegate only a bounded, independent, unambiguous slice cheaper to integrate than local work and suitable for its Luna model: explorer=read-only exact repo facts; librarian=read-only current external facts from primary sources; worker=isolated fixed-scope implementation. Never delegate trivial or coupled work, architecture, user clarification, integration, final judgment, or final verification. Every packet states exact question or outcome; repository root; allowed paths and symbols; forbidden paths; relevant architecture and existing behavior; required skills; exact inputs; output format; acceptance criteria; required commands or evidence; unchanged constraints; prohibited expansion; known uncertainty; blocker behavior; exact stop condition. Use concrete names, paths, APIs, functions, tests, versions, and expected observations when known; include no unrelated transcript. Treat returns as input: inspect, reconcile, integrate, and verify. Stop when packet is satisfied or blocked; never recurse or create agent organizations. Use GPT 5.6 Luna low for explorer and librarian; use GPT 5.6 Luna medium for worker.";
|
|
3
3
|
//#endregion
|
|
4
4
|
export { CORE_INSTRUCTIONS as t };
|
|
@@ -166,7 +166,7 @@ async function handleGitBashMcpRequest(input, options = {}) {
|
|
|
166
166
|
capabilities: { tools: { listChanged: false } },
|
|
167
167
|
serverInfo: {
|
|
168
168
|
name: "git_bash",
|
|
169
|
-
version: "0.
|
|
169
|
+
version: "0.5.1"
|
|
170
170
|
},
|
|
171
171
|
protocolVersion: protocolVersionFromInput(input) ?? "2024-11-05"
|
|
172
172
|
});
|
|
@@ -186,7 +186,7 @@ async function runMcpStdioServer(input, output, options = {}) {
|
|
|
186
186
|
handler: handleGitBashMcpRequest,
|
|
187
187
|
handlerOptions: options,
|
|
188
188
|
idleTimeoutMs: 0,
|
|
189
|
-
log: options.lifecycleLog,
|
|
189
|
+
...options.lifecycleLog === void 0 ? {} : { log: options.lifecycleLog },
|
|
190
190
|
parseErrorResponse: () => errorResponse(null, -32601, "Method not found")
|
|
191
191
|
});
|
|
192
192
|
}
|
|
@@ -210,7 +210,7 @@ async function runToolResponse(id, args, options) {
|
|
|
210
210
|
const result = await (options.runGitBash ?? runGitBashCommand)({
|
|
211
211
|
bashPath: resolution.path,
|
|
212
212
|
command,
|
|
213
|
-
cwd,
|
|
213
|
+
...cwd === void 0 ? {} : { cwd },
|
|
214
214
|
timeoutMs,
|
|
215
215
|
env: options.env ?? process.env
|
|
216
216
|
});
|
|
@@ -275,8 +275,8 @@ function canRunGitBash(options) {
|
|
|
275
275
|
}
|
|
276
276
|
function resolve$1(options) {
|
|
277
277
|
if (options.exists === void 0 && options.where === void 0) return resolveGitBashForCurrentProcess({
|
|
278
|
-
platform: options.platform,
|
|
279
|
-
env: options.env
|
|
278
|
+
...options.platform === void 0 ? {} : { platform: options.platform },
|
|
279
|
+
...options.env === void 0 ? {} : { env: options.env }
|
|
280
280
|
});
|
|
281
281
|
return resolveGitBash({
|
|
282
282
|
platform: platformFromOptions(options),
|
package/plugin/runtime/lsp.js
CHANGED
|
@@ -3072,7 +3072,7 @@ function coerceToolArguments(value) {
|
|
|
3072
3072
|
//#endregion
|
|
3073
3073
|
//#region packages/lsp-core/src/mcp.ts
|
|
3074
3074
|
var SERVER_NAME = "lsp";
|
|
3075
|
-
var SERVER_VERSION = "0.
|
|
3075
|
+
var SERVER_VERSION = "0.5.1";
|
|
3076
3076
|
async function handleLspMcpRequest(input) {
|
|
3077
3077
|
if (!isPlainRecord(input)) return errorResponse(null, -32600, "Invalid Request");
|
|
3078
3078
|
const id = jsonRpcId(input["id"]);
|
package/plugin/runtime/rules.js
CHANGED
|
@@ -74,13 +74,31 @@ function parseRule(text) {
|
|
|
74
74
|
body: text.trim()
|
|
75
75
|
};
|
|
76
76
|
const header = text.slice(4, end);
|
|
77
|
-
const globs = [...(/^globs:\s*(.+)$/m.exec(header)?.[1] ?? "").matchAll(/["']([^"']+)["']/g)].map((match) => match[1]).filter((value) => value !== void 0);
|
|
78
77
|
return {
|
|
79
78
|
alwaysApply: /^alwaysApply:\s*true\s*$/m.test(header),
|
|
80
|
-
globs,
|
|
79
|
+
globs: parseGlobs(header),
|
|
81
80
|
body: text.slice(end + 5).trim()
|
|
82
81
|
};
|
|
83
82
|
}
|
|
83
|
+
function parseGlobs(header) {
|
|
84
|
+
const lines = header.split("\n");
|
|
85
|
+
const index = lines.findIndex((line) => /^globs\s*:/.test(line));
|
|
86
|
+
if (index < 0) return [];
|
|
87
|
+
const value = lines[index]?.replace(/^globs\s*:\s*/, "").trim() ?? "";
|
|
88
|
+
if (value.length > 0) return (value.startsWith("[") && value.endsWith("]") ? value.slice(1, -1) : value).split(",").map(unquote).filter((glob) => glob.length > 0);
|
|
89
|
+
const globs = [];
|
|
90
|
+
for (const line of lines.slice(index + 1)) {
|
|
91
|
+
const item = /^\s+-\s*(.+?)\s*$/.exec(line)?.[1];
|
|
92
|
+
if (item === void 0) break;
|
|
93
|
+
const glob = unquote(item);
|
|
94
|
+
if (glob.length > 0) globs.push(glob);
|
|
95
|
+
}
|
|
96
|
+
return globs;
|
|
97
|
+
}
|
|
98
|
+
function unquote(value) {
|
|
99
|
+
const trimmed = value.trim();
|
|
100
|
+
return trimmed.length >= 2 && (trimmed.startsWith("\"") && trimmed.endsWith("\"") || trimmed.startsWith("'") && trimmed.endsWith("'")) ? trimmed.slice(1, -1) : trimmed;
|
|
101
|
+
}
|
|
84
102
|
function globMatches(glob, path) {
|
|
85
103
|
const normalized = path.replaceAll("\\", "/");
|
|
86
104
|
const pattern = glob.replaceAll("\\", "/").replace(/[.+^${}()|[\]\\]/g, "\\$&").replaceAll("**", "\0").replaceAll("*", "[^/]*").replaceAll("\0", ".*");
|
|
@@ -108,15 +126,18 @@ async function readable(path) {
|
|
|
108
126
|
}
|
|
109
127
|
function editPath(value, cwd) {
|
|
110
128
|
if (typeof value !== "object" || value === null || Array.isArray(value)) return void 0;
|
|
111
|
-
const input = value;
|
|
129
|
+
const input = new Map(Object.entries(value));
|
|
112
130
|
for (const key of [
|
|
113
131
|
"filePath",
|
|
114
132
|
"file_path",
|
|
115
133
|
"path",
|
|
116
134
|
"targetPath",
|
|
117
135
|
"target_path"
|
|
118
|
-
])
|
|
119
|
-
|
|
136
|
+
]) {
|
|
137
|
+
const candidate = input.get(key);
|
|
138
|
+
if (typeof candidate === "string") return isAbsolute(candidate) ? candidate : resolve(cwd, candidate);
|
|
139
|
+
}
|
|
140
|
+
const patch = typeof input.get("patch") === "string" ? input.get("patch") : typeof input.get("input") === "string" ? input.get("input") : void 0;
|
|
120
141
|
const path = patch === void 0 ? void 0 : /^\*\*\* (?:Add|Update) File: (.+)$/m.exec(patch)?.[1]?.trim();
|
|
121
142
|
return path === void 0 ? void 0 : resolve(cwd, path);
|
|
122
143
|
}
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ast-grep
|
|
3
|
-
description:
|
|
3
|
+
description: Use when a task needs syntax-aware code search or a repeatable structural rewrite across AST-shaped matches; do not use for plain text search, one local edit, or symbol navigation. Produces reviewed deterministic matches or a codemod; unlike LSP it matches syntax, not symbol identity.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# ast-grep
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: caveman
|
|
3
|
-
description:
|
|
3
|
+
description: Use when the user requests caveman mode, terse replies, fewer tokens, or `/caveman`, or when HolyCodex prompt and instruction edits require dense wording; do not remove required detail or silently change ordinary prose tone. Produces constraint-preserving lite, full, ultra, or Wenyan text; unlike compress it controls ongoing voice.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Caveman
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: compress
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when a task needs text, prompts, or instructions shortened without losing meaning or constraints; do not use for lossy summaries, code refactors, or ongoing voice changes. Produces a denser constraint-equivalent version; unlike caveman it preserves source tone unless asked otherwise.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Compress
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: debugging
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when a task involves a crash, wrong result, hang, race, leak, slowdown, or other reproducible defect that needs root-cause proof; do not use for feature work, behavior-preserving refactors, or speculative cleanup. Produces reproduction, evidence, regression proof, and an authorized minimal fix; unlike programming it owns symptom-to-cause diagnosis.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Debugging
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: define-goal
|
|
3
|
-
description: Use to define one measurable goal
|
|
3
|
+
description: Use when the user asks to define a goal or explicitly accepts a goal offered after planning or frontend approval; do not infer consent from implementation or vague improvement language. Creates or reuses one bounded measurable goal with proof and a hard stop; unlike plan, it defines completion rather than steps.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Define Goal
|
|
@@ -9,19 +9,19 @@ On activation, first user-visible line must be:
|
|
|
9
9
|
|
|
10
10
|
**GOAL MODE ACTIVATED**
|
|
11
11
|
|
|
12
|
-
Create one bounded, verifiable objective; no plan, log, snapshot, ledger, or
|
|
12
|
+
Create one bounded, verifiable objective; no plan, log, snapshot, ledger, handoff, or continuation mandate.
|
|
13
13
|
|
|
14
14
|
## Flow
|
|
15
15
|
|
|
16
|
-
1. State outcome, target, proof, scope, exclusions, stop condition.
|
|
17
|
-
2. Add useful checks, paths, environments, counts, or limits; no fake precision.
|
|
18
|
-
3. Replace activity goals like “improve” with observable state.
|
|
19
|
-
4. Ask one short question only if missing scope or
|
|
16
|
+
1. State concrete desired outcome, target, completion criteria, acceptable proof, scope, exclusions, input blocker, and explicit stop condition.
|
|
17
|
+
2. Add useful checks, paths, environments, counts, or limits; no fake precision or quality ratchet.
|
|
18
|
+
3. Replace activity goals like “improve” with observable state. Bound subjective quality by the approved task and named validator.
|
|
19
|
+
4. Ask one short question only if missing scope or proof would materially change intent.
|
|
20
20
|
5. Call `get_goal`.
|
|
21
21
|
- No goal: quality-check, then `create_goal`.
|
|
22
22
|
- Same active goal: reuse.
|
|
23
23
|
- Conflicting goal: ask whether to finish it or use another task.
|
|
24
|
-
6. Call `create_goal` with one concise objective. Set token budget only when user explicitly asks.
|
|
24
|
+
6. Call `create_goal` with one concise objective. Set token budget only when user explicitly asks. Stop once the objective's criteria pass; do not extend it for polishing, speculative expansion, repeated review, adjacent work, or newly noticed opportunities.
|
|
25
25
|
|
|
26
26
|
## Quality gate
|
|
27
27
|
|
|
@@ -32,5 +32,6 @@ Objective must answer:
|
|
|
32
32
|
- What binary or numeric threshold defines success?
|
|
33
33
|
- What is in and out?
|
|
34
34
|
- What condition requires user input?
|
|
35
|
+
- What exact condition ends work even if further improvement is possible?
|
|
35
36
|
|
|
36
37
|
Good validators: failing-then-passing bug test; exact test command; measured performance threshold; cited research decision; healthy operation plus rollback threshold.
|
|
@@ -1,11 +1,20 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: frontend
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when a task needs frontend, web UI, UX, visual design, interaction, responsive layout, accessibility, or browser-performance work; do not use for backend-only work, static prose, or non-web artifacts. Produces context-aware approved design decisions followed by accessible responsive implementation or findings; premium React/Tailwind creation adds the GPT Taste route.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Frontend
|
|
7
7
|
|
|
8
|
-
Preserve stack, behavior, tokens, patterns,
|
|
8
|
+
Preserve stack, behavior, tokens, patterns, supplied visual contract, and product identity. Keep scope small. Avoid generic AI styling. Do not force `DESIGN.md`, research, dependencies, GSAP, or heavy QA.
|
|
9
|
+
|
|
10
|
+
## Approval sequence
|
|
11
|
+
|
|
12
|
+
1. Load `frontend`; inspect the request, product shell, target surface, design tokens, nearest pattern, responsive contract, supplied references, and relevant states.
|
|
13
|
+
2. Select only material design decisions: visual direction, typography, layout and density, color and surfaces, assets, responsive behavior, applicable states, plus a motion system and accessibility treatment for every task. Define how motion communicates hierarchy, state, interaction, continuity, or navigation; keep it proportional. Define `prefers-reduced-motion`, keyboard operation, focus visibility, semantics, contrast, and labels. Preserve established decisions unless change is requested.
|
|
14
|
+
3. Present the compact decision set with existing constraints and ask for approval before implementation. For a fix, audit, accessibility, or performance task, include only decisions that alter user-visible design; diagnosis and technical implementation details need no approval.
|
|
15
|
+
4. After approval, ask whether the user wants to define a goal. Only after explicit agreement load `define-goal`; otherwise implement.
|
|
16
|
+
|
|
17
|
+
Approval owns visible direction and material interaction changes. Existing component APIs, code structure, exact CSS values, breakpoint mechanics, libraries already required by the approved route, and other reversible implementation details remain implementation decisions.
|
|
9
18
|
|
|
10
19
|
## Route
|
|
11
20
|
|
|
@@ -15,36 +24,27 @@ Preserve stack, behavior, tokens, patterns, and supplied visual contract. Keep s
|
|
|
15
24
|
- Palette/type/style: load only relevant `references/ui-ux-db` data.
|
|
16
25
|
- Motion-rich premium React/Tailwind page creation or redesign: mandatory GPT Taste route below. Ordinary fixes, debugging, accessibility, and performance work stay on normal route.
|
|
17
26
|
|
|
18
|
-
##
|
|
27
|
+
## GPT Taste route
|
|
19
28
|
|
|
20
|
-
-
|
|
21
|
-
-
|
|
22
|
-
-
|
|
23
|
-
-
|
|
24
|
-
-
|
|
25
|
-
- Select three architectures: inline heading image, horizontal expanding accordion, infinite partner marquee, restrained testimonial carousel, pinned gallery, or stacked cards.
|
|
26
|
-
- Use real GSAP with `@gsap/react` and `ScrollTrigger`. Select two systems: pinned title/gallery split, image scale/fade scroll, scrubbed word reveal, or stacked cards. Motion explains hierarchy, state, or navigation; static interface fails. Interactive images/cards use slow contained scale hover.
|
|
27
|
-
- Wrap page: `<main className="overflow-x-hidden w-full max-w-full">`.
|
|
29
|
+
- During approval, emit `<design_plan>` with prompt-derived visual direction, type, layout, motion, responsive, accessibility, and state choices. Established contracts win.
|
|
30
|
+
- Treat AIDA, bento layouts, font shortlists, GSAP, Picsum, component counts, and named motion patterns as options only when they fit product, task, and stack.
|
|
31
|
+
- For each chosen pattern, state its user-facing purpose and containment. Do not add dependencies or remote assets unless approved and required.
|
|
32
|
+
- Motion is required but may be subtle. Avoid gratuitous, blocking, performance-heavy, or reduced-motion-unsafe effects.
|
|
33
|
+
- Prevent horizontal overflow, clipped content, dead layouts, empty cards, fake dashboards, copied text, and inaccessible interaction.
|
|
28
34
|
|
|
29
35
|
Ban emojis; cheap/generic meta-labels (`SECTION 01`, `QUESTION 05`, `ABOUT US`); invisible button text; empty bento cells/cards; narrow multi-line/centered heroes; repeated left/right or flat sections/backgrounds; stock-feeling imagery; fake dashboards; meaningless gradients; copied reference text.
|
|
30
36
|
|
|
31
|
-
Required `<design_plan>`:
|
|
32
|
-
|
|
33
|
-
1. Three-line deterministic selection: hero, font stack, three architectures, two GSAP systems.
|
|
34
|
-
2. AIDA map.
|
|
35
|
-
3. H1 max-width and 2–3-line proof; confirm no stamps/tags.
|
|
36
|
-
4. Grid-span math and `grid-flow-dense` proof.
|
|
37
|
-
5. Meta-label sweep and button-contrast check.
|
|
37
|
+
Required `<design_plan>`: visible direction; layout and responsive contract; asset role; motion purpose and reduced-motion fallback; accessibility treatment; applicable loading, error, and empty states. Include only chosen patterns, not a fixed architecture count.
|
|
38
38
|
|
|
39
|
-
Only
|
|
39
|
+
Only after approval and optional goal choice may implementation begin.
|
|
40
40
|
|
|
41
41
|
## Implementation
|
|
42
42
|
|
|
43
43
|
1. Inspect target and nearest established pattern.
|
|
44
44
|
2. Lock visual direction: type, spacing, surfaces, color, asset role, motion role.
|
|
45
|
-
3. Implement smallest coherent slice
|
|
45
|
+
3. Implement smallest coherent slice with purposeful motion, reduced-motion behavior, keyboard operation, visible focus, semantic structure, contrast, and labels.
|
|
46
46
|
4. Test narrow/mobile/wide containment. No horizontal leak, clipped text, overlap, or unreadable measure.
|
|
47
|
-
5. Check
|
|
47
|
+
5. Check loading, error, and empty states when applicable.
|
|
48
48
|
6. Check interaction and performance proportional to change. Avoid layout shift, oversized media, needless client work.
|
|
49
49
|
|
|
50
50
|
Use real assets when supplied. Never invent research or claim screenshot parity without visual comparison.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: handoff
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when a task needs compact resumable context transferred to another agent or session; do not use for routine summaries, delegation packets, or completed work. Produces one redacted temporary handoff referencing durable artifacts; unlike planning it records state without choosing future work.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Handoff
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: lsp
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when a coding task needs semantic diagnostics, definitions, references, symbols, or safe rename from a configured language server; do not use for text search, syntax-shape search, or server installation. Produces semantic locations, diagnostics, or workspace edits; unlike lsp-setup it assumes a usable server.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# LSP
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: lsp-setup
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when a task needs language-server installation or configuration because the user requests setup or the required LSP is missing; do not use when an existing server works or for general dependency setup. Produces one minimal verified server configuration; unlike lsp it establishes capability rather than using it.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# LSP Setup
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: plan
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when the user asks for a plan or implementation requires unresolved architecture, cross-cutting coordination, irreversible decisions, high risk, or material ambiguity; do not use for multiple obvious steps, simple direct work, status, or explanation. Produces one repo-grounded reviewed plan with approval and optional goal gates; unlike plan-review, it owns the full planning sequence.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Plan
|
|
@@ -9,6 +9,16 @@ On activation, first user-visible line must be:
|
|
|
9
9
|
|
|
10
10
|
**PLAN MODE ACTIVATED**
|
|
11
11
|
|
|
12
|
-
Main agent
|
|
12
|
+
Main agent owns planning. No subagent, reviewer agent, evidence directory, execution waves, commit ritual, or ceremony unless user asks.
|
|
13
13
|
|
|
14
|
-
|
|
14
|
+
## Required sequence
|
|
15
|
+
|
|
16
|
+
1. Load `plan`; inspect enough task and repo context.
|
|
17
|
+
2. Write the complete initial plan. Each ordered step names the relevant file or surface, exact change, expected outcome, and smallest proof; mark only material dependencies, risks, and user decisions.
|
|
18
|
+
3. Only after the initial plan exists, load `plan-review`. Never preload, parallelize, or imply its review.
|
|
19
|
+
4. Use `plan-review` once to revise or rewrite the initial plan. Keep initial and reviewed phases distinct.
|
|
20
|
+
5. Present the reviewed executable plan and ask for approval. Do not implement before approval.
|
|
21
|
+
6. After approval, ask whether the user wants to define a goal.
|
|
22
|
+
7. Only after explicit agreement, load `define-goal`; otherwise implement the approved plan.
|
|
23
|
+
|
|
24
|
+
Preserve architecture and requested scope. Stop planning after approval and the optional goal choice; no repeated review or polishing loop.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: plan-review
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when a complete initial implementation plan needs feasibility, scope, sequencing, risk, or verification repair, including the required review phase of the plan skill; do not use before initial drafting or as a recurring reviewer. Produces one repaired executable plan; unlike plan it does not own drafting or approval.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Plan Review
|
|
@@ -9,4 +9,14 @@ On activation, first user-visible line must be:
|
|
|
9
9
|
|
|
10
10
|
**PLAN REVIEW ACTIVATED**
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
Input must include the request, complete initial plan, and enough repo facts. If no initial plan exists, stop and return control to `plan`; never draft its first plan.
|
|
13
|
+
|
|
14
|
+
One pass:
|
|
15
|
+
|
|
16
|
+
1. Test feasibility and compatibility with repo architecture and user constraints.
|
|
17
|
+
2. Find missing steps, dependencies, risks, ambiguities, unsafe mutations, weak completion criteria, and unverifiable outcomes.
|
|
18
|
+
3. Remove unnecessary work, ceremony, scope expansion, duplicate checks, and poor sequencing.
|
|
19
|
+
4. Strengthen each step's target, change, dependency, proof, and stop condition.
|
|
20
|
+
5. Revise or rewrite directly; preserve sound content. Output one complete reviewed plan, not comments or scores.
|
|
21
|
+
|
|
22
|
+
No reviewer agent, evidence folder, second review loop, or implementation. Stop after the corrected executable plan; `plan` owns presentation and approval.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: programming
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when a task edits Python, Rust, TypeScript, Go, or their matching manifests; do not use for prose-only edits or unsupported languages. Applies language-specific correctness, typing, size, and verification rules; debugging or refactor may additionally own the workflow.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Programming
|
|
@@ -22,7 +22,7 @@ Before editing `.py`, `.pyi`, `.rs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.go`, or ma
|
|
|
22
22
|
|
|
23
23
|
## Test
|
|
24
24
|
|
|
25
|
-
|
|
25
|
+
Defect: add a public-seam regression test first and confirm the intended failure. Explicit test-first request or clearly defined new behavior without adequate proof: test public seam first, confirm failure, implement minimum green, then refactor. Existing tests may lock small covered changes. Do not force red-green for prose, configuration-only work, trivial mechanical edits, or behavior already adequately covered. Use real object or fake before mock. Deterministic fixture; no sleep. Add an end-to-end user outcome for new behavior when proportional. Run smallest test in loop.
|
|
26
26
|
|
|
27
27
|
## Size
|
|
28
28
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: refactor
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when a task needs behavior-preserving restructuring, extraction, simplification, modernization, or cleanup of one named seam; do not use for features, bug fixes, formatting sweeps, or broad AI-slop cleanup. Produces a behavior-locked structural change; unlike remove-ai-slops it targets one seam or smell.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Refactor
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: remove-ai-slops
|
|
3
|
-
description: Use to remove AI-generated code smells without behavior or
|
|
3
|
+
description: Use when a task asks to remove AI-generated code smells from an explicit diff or file scope without behavior changes; do not use for general refactors, features, bug fixes, or repository-wide cleanup. Produces behavior-locked removal of proven smell instances; unlike refactor it may cover several categories in fixed scope.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Remove AI Slops
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: rules
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when a task asks how HolyCodex rules are discovered, matched, injected, deduplicated, limited, cached, or why rule loading is wrong; do not use merely because repository instructions exist or for skill routing. Produces an evidence-backed rule trace without exposing unrelated content; unlike general debugging it owns this pipeline.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Rules
|
|
@@ -9,7 +9,7 @@ Automatic when plugin enabled. Static rules load on session start and user promp
|
|
|
9
9
|
|
|
10
10
|
Sources: `CONTEXT.md`, `.holycodex/rules/**/*.md`, `.codex/rules/**/*.md`, `.github/instructions/**/*.md`, `.github/copilot-instructions.md`. Never load or reinject `AGENTS.md`.
|
|
11
11
|
|
|
12
|
-
Frontmatter: `alwaysApply: true` for static rule; `globs`
|
|
12
|
+
Frontmatter: `alwaysApply: true` for static rule; `globs` accepts quoted or unquoted scalar, inline array, or multiline array. Body after frontmatter is injected. Native and plugin rules dedupe by normalized content hash. Per-rule cap 8,000 chars; event cap 24,000 chars.
|
|
13
13
|
|
|
14
14
|
Environment: `HOLYCODEX_RULES_DISABLED=1`, `HOLYCODEX_RULES_MAX_RULE_CHARS`, `HOLYCODEX_RULES_MAX_RESULT_CHARS`.
|
|
15
15
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: security-research
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when an authorized task needs repository security review, threat analysis, vulnerability validation, or attack-path and exploitability proof; do not use for generic review, ordinary debugging, unsupported hardening claims, or real-system attacks. Produces evidence-calibrated findings and minimum fixes; unlike debugging it evaluates attacker reachability and impact.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Security Research
|
|
@@ -1,8 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: comment-checker
|
|
3
|
-
description: Use to handle comment-checker warnings after edits.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Comment Checker
|
|
7
|
-
|
|
8
|
-
After successful `apply_patch`, `write`, `edit`, `multi_edit`, or `multiedit`, fix or explain any blocking warning before continuing. Non-edit tools are ignored. No MCP tool exists. Missing checker binaries produce no output.
|
|
@@ -1,24 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: tdd
|
|
3
|
-
description: Use public-seam red-green-refactor for requested TDD, regression, or integration tests.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# TDD
|
|
7
|
-
|
|
8
|
-
Find established seam before asking user. Ask only if materially different contracts remain.
|
|
9
|
-
|
|
10
|
-
## Slice
|
|
11
|
-
|
|
12
|
-
1. Pick one observable outcome.
|
|
13
|
-
2. Red: test public seam. Run it. Confirm failure matches missing behavior, not setup error.
|
|
14
|
-
3. Green: minimum production code. No second case yet.
|
|
15
|
-
4. Refactor only with green test.
|
|
16
|
-
5. Repeat vertical slice.
|
|
17
|
-
|
|
18
|
-
Given/When/Then: known fixture; one action; only observable result caused by action.
|
|
19
|
-
|
|
20
|
-
Reject private-method tests, tautology, snapshot abuse, broad mocking, sleeps, wall-clock dependence, implementation-coupled assertions, deleted failing tests.
|
|
21
|
-
|
|
22
|
-
Test doubles order: real object; in-memory fake; test container or sandbox; wire fake; narrow mock last. Fake must honor real contract.
|
|
23
|
-
|
|
24
|
-
Fixtures deterministic and isolated. Coverage proportional to risk. Run smallest test during loop; broader gates at completion. See `tests.md` and `mocking.md` only when needed.
|
|
@@ -1,5 +0,0 @@
|
|
|
1
|
-
# Mocking
|
|
2
|
-
|
|
3
|
-
Prefer real objects, test databases, or fakes. Mock only system boundaries: external APIs, time, randomness, and sometimes databases or filesystems. Never mock owned classes or internal collaborators.
|
|
4
|
-
|
|
5
|
-
Inject boundary dependencies. Expose one typed operation per external action instead of a generic conditional fetcher; each mock then has one input and result shape.
|
|
@@ -1,7 +0,0 @@
|
|
|
1
|
-
# Tests
|
|
2
|
-
|
|
3
|
-
Test caller-visible behavior through public interfaces. Good tests survive refactors, use known literal expectations, perform one action, and assert its observable result.
|
|
4
|
-
|
|
5
|
-
Reject tests of private methods, internal calls, call counts, storage inspected behind the public interface, snapshots without a stable contract, or expected values recomputed by production logic. These test implementation, not behavior.
|
|
6
|
-
|
|
7
|
-
Example: after `createUser`, verify `getUser(id)` returns the user; do not query the database directly.
|