holycodex 0.4.6 → 0.5.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -8,21 +8,20 @@ HolyCodex installs one focused Codex toolkit:
8
8
 
9
9
  - 18 on-demand skills for programming, debugging, frontend, LSP, AST search, TDD, 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.
26
25
  - OMO workflows and retained references are rewritten with caveman-style token efficiency.
27
26
  - The OMO frontend skill is merged with GPT Taste instead of shipping another overlapping skill.
28
27
 
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.0",
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.0",
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: question, repo scope, deliverable, acceptance criteria, evidence needed, prohibited expansion, stop condition. Inspect only that 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, or inspect history; never edit, install, research external facts, choose architecture, make final judgments, ask the user, or broaden scope. Stop when criteria are met, evidence is unavailable, scope conflicts, or a write is required. Return exactly: answer; evidence with paths, symbols, commands, and 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: question, external scope, deliverable, acceptance criteria, evidence needed, prohibited expansion, stop condition. Research only that 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; distinguish source fact from inference. Never inspect the repo beyond supplied context, implement, write externally, choose architecture, make final judgments, ask the user, or broaden scope. Stop when criteria are met, authoritative evidence is unavailable or conflicting, or the answer needs repository work. Return exactly: findings; claim-linked citations with source, version or date; conflicts and 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: fixed files and scope, required behavior, acceptance criteria, necessary context, required skills, prohibited expansion, proof, stop condition. Reject or stop on ambiguity, overlap, architecture choice, coupled out-of-scope work, user-work conflict, or missing authority. 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. Load required skills before their 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 the smallest specified proof; never claim integration or final verification. Return exactly: changed paths and behavior; tests or checks with result; acceptance 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.0"),
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.0";
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: 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 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 useful low-complexity slice that is bounded, independent, unambiguous, and cheaper to integrate than to do locally: explorer=read-only repo facts; librarian=read-only current external facts; worker=isolated implementation. Use skill then subagent when both apply; the skill owns method and gates, the main agent owns decisions, and the subagent owns only its assigned slice. Never delegate trivial work, tightly coupled work, architecture, final judgment, user clarification, integration, or verification. Give only necessary context plus exact scope, deliverable, acceptance criteria, evidence, prohibited expansion, and stop condition. Treat returned work as input: inspect it, resolve conflicts, integrate deliberately, and verify the user outcome. Stop delegation when the packet is satisfied or blocked; never recurse or create organization. Match reasoning effort to complexity. 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.0"
170
170
  },
171
171
  protocolVersion: protocolVersionFromInput(input) ?? "2024-11-05"
172
172
  });
@@ -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.0";
3076
3076
  async function handleLspMcpRequest(input) {
3077
3077
  if (!isPlainRecord(input)) return errorResponse(null, -32600, "Invalid Request");
3078
3078
  const id = jsonRpcId(input["id"]);
@@ -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: comment-checker
3
- description: Use to handle comment-checker warnings after edits.
3
+ description: Use when an edit produces a comment-checker warning that must be fixed or explained; do not use for ordinary comments, lint output, or before an edit. Produces a disposition for every blocking warning; unlike programming checks it handles the edit hook only.
4
4
  ---
5
5
 
6
6
  # Comment Checker
@@ -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 TDD it starts from a symptom.
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 existing 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: theme or visual direction, typography, layout and density, color and surfaces, asset role, interaction and motion, responsive behavior, and accessibility or state treatment. 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
 
@@ -17,7 +26,7 @@ Preserve stack, behavior, tokens, patterns, and supplied visual contract. Keep s
17
26
 
18
27
  ## Mandatory 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.
29
+ - During the approval decision set, 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 a default combination or replace an established type contract.
21
30
  - Follow AIDA: premium nav; Attention hero; Interest bento/features; Desire scroll/media; Action CTA/footer. Separate chapters with `py-32 md:py-48`.
22
31
  - 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
32
  - 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.
@@ -36,7 +45,7 @@ Required `<design_plan>`:
36
45
  4. Grid-span math and `grid-flow-dense` proof.
37
46
  5. Meta-label sweep and button-contrast check.
38
47
 
39
- Only then output UI code.
48
+ Only after approval and optional goal choice may implementation begin.
40
49
 
41
50
  ## Implementation
42
51
 
@@ -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 when a complex, risky, ambiguous, or multi-stage task needs an approved plan before implementation; do not use for 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, TDD, or refactor may additionally own the workflow.
4
4
  ---
5
5
 
6
6
  # Programming
@@ -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
@@ -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,6 +1,6 @@
1
1
  ---
2
2
  name: tdd
3
- description: Use public-seam red-green-refactor for requested TDD, regression, or integration tests.
3
+ description: Use when a task requests TDD, regression coverage, integration tests, or a public-seam failing test before implementation; do not use for test inspection, unrelated failures, or work with adequate existing proof. Produces deterministic red-green-refactor slices; unlike debugging it governs test-first delivery after behavior is known.
4
4
  ---
5
5
 
6
6
  # TDD