holycodex 0.16.9-dev.110.1 → 0.16.10-dev.112.1

package/dist/assets/plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "holycodex",
-  "version": "0.16.9-2",
+  "version": "0.16.10",
   "description": "Root-directed capabilities and deterministic installed assets for HolyCodex.",
   "author": {
     "name": "David Basile Filho",

package/dist/assets/plugin/skills/handoff/SKILL.md

@@ -1,9 +1,8 @@
 ---
 name: handoff
-description: Use when current Intent state must be resumed or exported; produce a compact redacted status projection with evidence and next action.
+description: Use when current Intent state must be resumed or exported; write a portable Markdown handoff with evidence and next action.
 ---
 
-Produce one compact projection of current Intent, Plan, and Assignment status,
-evidence, blockers, remaining risk, and the exact next action. Omit secrets,
-raw prompts, transcripts, and unchanged narration. Handoff is an export view;
-the semantic state remains authoritative.
+Write one compact Markdown handoff file in the host temporary directory resolved through environment variables such as TMPDIR, TMP, or TEMP. Avoid hardcoded absolute machine or user paths. Include current Intent, Plan, and Assignment status, evidence, blockers, remaining risk, and the exact next action. Omit secrets, raw prompts, transcripts, and unchanged narration. The semantic state remains authoritative.
+
+Verify the file contains sufficient context to resume the work. Return its portable location relative to the resolved temporary directory in a Markdown code block, identifying the temporary environment variable used. Let the user decide how to use it; do not create another thread.

package/dist/assets/plugin/skills/visual-loop/SKILL.md

@@ -1,21 +1,10 @@
 ---
 name: visual-loop
-description: Use when visual changes need rendered judgment; Root judges the result after specialists inspect their own work and assigns repairs.
+description: Use when visual work needs rendered acceptance; coordinate Worker.visual, Reviewer.visual, and Root judgment.
 ---
 
-Root only, for visual tasks. Orchestrate implementation, inspect its rendered
-result, judge the visual output, dispatch targeted changes to specialists, and
-repeat until the result is excellent and meets the user's requirements.
+Root only, when the rendered or interacted-with result is materially part of success. Follow the canonical loop: Worker.visual → Reviewer.visual → Root visual pass. Worker.visual produces mergeable implementation and inspects its actual result; Reviewer.visual independently reviews implementation and rendered interactions without repairs. Root independently inspects the current result, actively looks for issues both specialists missed, and remains final visual authority.
 
-Specialists implementing visual changes inspect and judge their own current
-render, repair visible defects, and recheck before returning. This local
-implementation loop supplements Root's higher-level visual acceptance.
+Judge relevant viewports and states against acceptance criteria, user references, and the repository design system. Follow the installed visual capability priority and active-surface tool rules; use the shared development server when needed. Return a specific evidence blocker when required judgment is unavailable.
 
-Follow the visual-inspection order generated for Root's selected capabilities.
-Unselected capabilities are not fallbacks. Honor higher-priority active-surface
-tool rules. Use the shared development server when needed. Inspect relevant viewports and
-states against the user's requirements and repository design system. Report
-the specific blocker if no available method supports the required judgment.
-
-Reuse unaffected evidence. Do not run this loop for logic-only changes.
-Specialists own implementation and delegated interaction checks.
+For a material discrepancy, dispatch only the bounded visual repair required, repeat only affected review and judgment, and reuse unaffected evidence. Acceptance requires sufficient current rendered and interaction evidence. Do not run this loop for logic-only work with no material rendered consequence.

package/dist/assets/plugin/skills/web-visualize/SKILL.md

@@ -1,16 +1,8 @@
 ---
 name: web-visualize
-description: Use when the user requests or approves an interactive visualization; create a user-facing visual experience from the supplied material.
+description: Use when the user requests or approves an interactive visualization; create a standalone HTML experience from the supplied material.
 ---
 
-Use ChatGPT Sites to create an interactive, user-facing visualization that
-turns the supplied plan, analysis, design, structured information, or other
-useful material into a clear, usable result. A visualization request authorizes
-its preparation. Root delegates implementation and judges the rendered result
-with visual-loop; follow the active capability's publication boundary.
+Create a standalone .html file in the host temporary directory, resolved through environment variables such as TMPDIR, TMP, or TEMP. Do not hardcode machine or user paths. The result must turn the supplied material into a clear, usable interactive visualization that answers the request.
 
-Return the visualization and enough context to verify that it answers the
-request. If the requested result cannot be completed with an authorized,
-available capability, return the specific blocker to Root. Publication,
-sharing, and other consequential external effects require their usual
-authorization.
+Root assigns visual implementation and judges acceptance through visual-loop. Use the installed capability projection's web-visualize inspection and delivery workflow. Return the HTML artifact and sufficient evidence that its content and interactions meet the acceptance criteria. Publication, sharing, and consequential external effects retain their authorization boundary.

package/dist/assets/plugin/skills/writing-instructions/SKILL.md

@@ -5,33 +5,26 @@ description: Use when model-facing instructions need authorship or review; make
 
 # Writing instructions
 
-Identify the receiver's effective context: instruction hierarchy, repository
-rules, Root or Role.task policy, selected skills, tools, configuration, and
-Assignment facts. Add only the missing constraints; resolve contradictions
-against the governing authority. User instructions override skill guidelines.
-
-Give each meaning one owner: Root/session policy for orchestration and judgment,
-AGENTS.md for repository conventions, the specialist baseline for shared
-boundaries, Role.task for task authority, and skills for conditional workflows
-or tool knowledge. Generated projections derive from that owner. Metadata
-selects the workflow; it does not duplicate its policy.
-
-State the outcome, bounded authority, material constraints, completion evidence,
-and escalation conditions. Preserve known facts needed to act; point to sources
-for details the receiver can discover reliably. Routine safe in-scope choices
-should proceed without questions. Carry authorized work through repair and proof.
-
-Remove redundant policy, older-model scaffolding, broad reading rituals, rigid
-recipes without a real dependency, hypothetical gates, and repeated testing.
-Preserve lifecycle invariants and required checks. Use configuration for default
-verbosity; use prompts for task-specific evidence and output requirements.
-
-Keep skill descriptions short and situation-first. Audit triggers alongside
-nearby skills; avoid skills that merely restate a task contract. Keep coherent
-shared guidance together and link uncommon branch-specific mechanics only from
-the condition that needs them. Metadata default prompts invoke the named skill
-without embedding another instruction source. Preserve upstream attribution.
-
-Validate the effective projection, not exact prose: the receiver can act within
-its authority, recognize completion and blockers, and return sufficient evidence
-without contradictory rules. Reuse the canonical testing policy.
+Treat every model-facing instruction as an execution contract.
+
+The receiver must be able to determine the goal or required end-state, the observable conditions that constitute success, and the evidence required to prove that success.
+
+Use this mental model:
+
+goal -> success criteria -> optional required method -> proof of success
+
+Identify the receiver's effective context: instruction hierarchy, repository rules, Root or Role.task authority, relevant skills, tools, projected capabilities, configuration, and Assignment facts. Add only missing constraints and resolve contradictions against governing authority.
+
+Give each meaning one authoritative owner. Project policy from that owner instead of duplicating it across prompts, metadata, skills, generated instructions, or nearby policies.
+
+State a required means, procedure, tool, ordering, or implementation detail only when it materially constrains correct execution. Otherwise leave routine safe implementation choices to the receiver.
+
+Completion evidence must prove the success criteria. Use the smallest meaningful proof proportionate to behavior, scope, risk, uncertainty, and acceptance criteria. Reuse current evidence. Broaden or repeat validation only after relevant changes, failures, elevated risk, or unresolved material concerns. Preserve required repository gates and necessary high-risk regression coverage.
+
+Remove redundant policy, stale model scaffolding, broad reading rituals, rigid recipes without a real dependency, hypothetical gates, repeated testing, and prose that merely restates choices the receiver can safely make itself.
+
+Carry authorized work through repair and proof.
+
+Validate the effective contract rather than exact wording: the receiver can identify the goal, recognize success and blockers, act within authority, and return sufficient evidence without contradictory rules.
+
+Keep skill descriptions short and situation-first. Audit triggers alongside nearby skills; keep coherent shared guidance together and link uncommon mechanics from the condition that needs them. Display and invocation metadata selects the workflow; it does not duplicate model-facing behavior. Metadata default prompts invoke the named skill without embedding another instruction source. Preserve upstream attribution.