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 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
- - 18 on-demand skills for programming, debugging, frontend, LSP, AST search, TDD, security research, planning, handoffs, goal definition, compression, and related workflows.
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
- - Four MCP defaults: `git_bash`, `lsp`, `grep_app`, and `context7`.
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 always owns the task and decisions. Subagents exist only to reduce cost on narrow independent work—not to simulate an organization.
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 their descriptions match the task.
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
- - Delegation is capped at two and remains under primary-agent control.
25
- - Sol and Terra use low or medium reasoning; Luna may also use high.
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
@@ -1,5 +1,5 @@
1
1
  {
2
- "name": "holycodex",
2
+ "name": "HolyCodex",
3
3
  "interface": { "displayName": "HolyCodex" },
4
4
  "plugins": [
5
5
  {
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "holycodex",
3
- "version": "0.4.6",
3
+ "version": "0.5.1",
4
4
  "description": "Lean Codex-only agent toolkit for ChatGPT Plus",
5
5
  "keywords": [
6
6
  "agents",
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "holycodex",
3
- "version": "0.4.6",
4
- "description": "Lean Codex-only agents, skills, hooks, and MCP defaults.",
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 agents only for narrow delegated exploration, research, or isolated implementation. Skills declare their own triggers. Use git_bash for reliable Windows shell execution, lsp for semantic diagnostics and navigation, grep_app for public code examples, and context7 for current library documentation.",
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 repo research: exact files, symbols, history, or diagnostics."
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. Inspect only assigned repo scope. MUST use git_bash MCP for every shell command. Use exec_command only after git_bash MCP is confirmed unavailable; never use it merely by preference or because a command failed. Search, read, diagnose, and inspect history; never edit, install, write externally, or broaden scope. Return exact paths, symbols, evidence, and uncertainty. Stop when question is answered.
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 read-only external research from current primary sources."
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. Research only assigned external scope. MUST use git_bash MCP for every shell command. Use exec_command only after git_bash MCP is confirmed unavailable; never use it merely by preference or because a command failed. Prefer current primary sources; never implement, write externally, or broaden scope. Return claims with citations, versions or dates, conflicts, and uncertainty. Stop when question is answered.
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, bounded implementation with explicit acceptance criteria."
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. Change only assigned files and scope; meet stated criteria. MUST use git_bash MCP for every shell command. Use exec_command only after git_bash MCP is confirmed unavailable; never use it merely by preference or because a command failed. Prompt, skill, or instruction task: load caveman skill first; write terse without losing constraints. Preserve architecture, API, behavior, naming, style, and user work. Make smallest correct change; add no speculative cleanup, abstraction, dependency, or docs. Run smallest proof. Return changed paths, checks, and blockers.
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
  """
@@ -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.4.6"),
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.4.6";
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: MUST use git_bash MCP for every shell command. Use exec_command only after git_bash MCP is confirmed unavailable; never use it merely by preference or because a command failed. Prompt, skill, or instruction edit: load caveman; preserve constraints. Main agent owns decisions, integration, and verification. Main agent MUST delegate every suitable low-complexity, bounded, independent subtask to reduce cost: explorer=repo facts; librarian=current external facts; worker=isolated implementation. Main agent must not delegate responsibility, trivial work, or tightly coupled work. Delegation reduces cost; it does not create organization. Match reasoning effort to complexity. Use GPT 5.6 Luna for most subagents at low or medium reasoning; GPT 5.6 Terra only for complex subagent work, at low reasoning.";
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.4.6"
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),
@@ -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.4.6";
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"]);
@@ -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
- ]) if (typeof input[key] === "string") return isAbsolute(input[key]) ? input[key] : resolve(cwd, input[key]);
119
- const patch = typeof input.patch === "string" ? input.patch : typeof input.input === "string" ? input.input : void 0;
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: Search or rewrite code by syntax shape; use for safe repeatable codemods.
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: Terse, technically exact replies in lite, full, ultra, or Wenyan variants. Use for caveman mode, brief replies, fewer tokens, or `/caveman`.
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 to shorten text without losing meaning, constraints, tone, safety, structure, or exact technical content.
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 to prove and minimally fix crashes, wrong behavior, hangs, races, leaks, or slowness.
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 when explicitly asked to set or refine one.
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 handoff.
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 validator changes intent.
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 for web UI build, debugging, audit, accessibility, or performance. Motion-rich premium React/Tailwind page creation or redesign activates mandatory GPT Taste: AIDA, wide hero, dense bento, GSAP, assets, and preflight proof.
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, and supplied visual contract. Keep scope small. Do not force `DESIGN.md`, research, dependencies, GSAP, or heavy QA.
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
- ## Mandatory GPT Taste route
27
+ ## GPT Taste route
19
28
 
20
- - Before code, emit `<design_plan>` with deterministic prompt-derived selection: one hero, one approved font stack (`Satoshi`, `Cabinet Grotesk`, `Outfit`, or `Geist`; never `Inter`), three component architectures, two GSAP paradigms. Do not repeat default combination or replace established type contract.
21
- - Follow AIDA: premium nav; Attention hero; Interest bento/features; Desire scroll/media; Action CTA/footer. Separate chapters with `py-32 md:py-48`.
22
- - Select cinematic center, artistic asymmetry, or editorial split. Build one hero: wide `max-w-5xl`/`max-w-6xl` H1, responsive `clamp`, maximum 2–3 lines, strong art direction, perfect button contrast, no stamp icons, pill tags, or raw stats.
23
- - Build dense gapless bento: 3–5 intentional cards, `grid-flow-dense`, spans proven to fill every cell, mixed imagery/type/CSS effects, no dead corners or empty cards.
24
- - Use contextual `https://picsum.photos/seed/{keyword}/1920/1080` assets; art-direct coherent grayscale/blend/contrast/opacity with subtle radial blur, grain mesh, or dark overlays.
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 then output UI code.
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. Keep semantics and keyboard behavior.
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 contrast, focus, labels, reduced motion, loading, error, empty state when in scope.
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 to save compact, safe context for another agent or session.
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 LSP diagnostics, definitions, references, symbols, or safe rename.
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 to configure and verify one missing or unconfigured language server.
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 to write an executable plan only when explicitly requested before implementation.
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 writes plan. No subagent, reviewer, evidence directory, execution waves, commit ritual, or ceremony unless user asks.
12
+ Main agent owns planning. No subagent, reviewer agent, evidence directory, execution waves, commit ritual, or ceremony unless user asks.
13
13
 
14
- Inspect enough repo context first. Then give ordered steps. Each step names relevant files or surface, exact change, expected outcome, smallest proof. Mark dependencies and user decisions only when material. Preserve architecture and scope. Stop when plan is executable.
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 to review and repair a plan once when explicitly requested.
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
- One pass. Check plan against request and repo facts. Find only real blockers: wrong seam, missing dependency, unsafe mutation, unverifiable step, incompatible contract, omitted required scope. Repair directly. Keep good parts. No reviewer agent, scoring theater, evidence folder, or second review loop. Stop after corrected executable plan.
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 strict Python, Rust, TypeScript, and Go rules for matching source files.
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
- Public behavior red first. Confirm intended failure. Minimum green. Refactor. Use real object or fake before mock. Deterministic fixture; no sleep. At least one end-to-end user outcome for a new feature. Run smallest test in loop.
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 to refactor, restructure, extract, simplify, or modernize code without behavior changes.
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 feature changes.
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 to inspect HolyCodex rule discovery, matching, injection, deduplication, limits, or cache.
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` string or list for path match. 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.
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 for exploitability-led repo security review, threat analysis, validation, or attack paths.
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.