holycodex 0.16.5 → 0.16.6

package/dist/assets/plugin/plugin.json

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

package/dist/assets/plugin/skills/babysit-ci/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: babysit-ci
+description: Use when following CI or release gates through terminal completion.
+---
+
+# Babysit CI
+
+Discover the repository's own development and release instructions, provider,
+refs, required checks, publication mechanism, and gate dependencies through
+bounded specialist Assignments before operating or observing CI. Do not assume
+GitHub, branch names, pull requests, a registry, or separate pipelines.
+
+Root owns authorized Git/VCS and release actions. Worker.operations observes
+only the supplied exact ref and SHA; its result identifies the gate, run,
+terminal status, evidence locator, and any unavailable or ambiguous evidence.
+Pending or running is never success. Observation cannot rerun, cancel, approve,
+publish, or otherwise mutate external state.
+
+After a development action, observe its exact ref/SHA to terminal state. Green
+permits the next repository/user-required action. Red requires delegated
+diagnosis and repair, integration, applicable frontend/security acceptance,
+and the mandatory Reviewer.code fixed point before Root commits and pushes.
+Observe the new exact ref/SHA and repeat until green or an irreducible blocker.
+
+When the repository requires a development or prerelease gate before stable,
+stable is forbidden until that gate is terminal green. Root then performs the
+repository's actual authorized stable mechanism and delegates terminal
+observation. Stable failure enters the same repair/review/VCS cycle and passes
+through every required development gate before another stable attempt.
+
+Use one gate for a combined pipeline. Do not invent a distinct release gate.
+Completion requires all requested terminal-green evidence or a precise external
+blocker; a successful push or started pipeline does not complete this workflow.

package/dist/assets/plugin/skills/babysit-ci/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Babysit CI"
+  short_description: "Follow repository CI and release gates to completion."
+  default_prompt: "Use babysit-ci for this CI or release lifecycle."
+policy:
+  allow_implicit_invocation: true

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

@@ -1,6 +1,6 @@
 ---
 name: commit
-description: Use when Root owns a local commit after exact scope and proof are settled; verify scope, create the minimal commit, and report identity.
+description: Use when Root creates a local commit after scope and proof are settled.
 ---
 
 Root uses this workflow after exact scope and local proof are settled. Verify
@@ -10,22 +10,10 @@ exclusions before creating the local commit.
 Require a passing Reviewer.code fixed-point result after implementation or a
 major codebase change before this VCS exception is used.
 
-After integration, Root commits the exact approved ref and gives its exact ref
-and SHA to `Worker.operations` for terminal CI observation.
-Discover the repository's actual development/release topology first; never
-assume GitHub, branch names, or that pending is success. Delegate fixes for
-failures, then repeat integration, commit, push, and observation until the
-repository gate is terminal green. If release is authorized, Root performs the
-repository's own release mechanism only after the development gate is terminal
-green, then delegates terminal release verification. If development and release
-share one pipeline, or the repository has no distinct release gate, record that
-topology and apply the repository's one available terminal gate. Fix failures
-through a new bounded Assignment and repeat the same review/VCS/observation
-cycle.
-
-Local commits need no user approval; every exact push, tag, merge, CI trigger,
-publication, or other remote mutation requires fresh user approval through
-native `request_user_input` immediately beforehand.
+After integration, Root commits the exact authorized scope. For subsequent CI
+or release work, load [babysit-ci](../babysit-ci/SKILL.md), which owns that
+lifecycle. Root's authority policy owns approval requirements and existing
+user authorization.
 
 Completion: Root reports the commit identity and post-commit status with
 redacted evidence, or returns an exact reproducible blocker. Never print secret

package/dist/assets/plugin/skills/context7-cli/SKILL.md

@@ -1,12 +1,13 @@
 ---
 name: context7-cli
-description: Use when a current library, framework, SDK, or API fact needs authoritative documentation.
+description: Use when querying current technical documentation with Context7 CLI.
 ---
 
-Use current authoritative documentation before relying on memory. Return the
-requested versions, behavior, dates, conflicts, and coverage limits with
-source locators. Do not turn an external fact into an architecture decision.
+Resolve the requested library identity with the installed ctx7 CLI, then query
+narrowly for the requested version and fact. Use the CLI's current help for
+command syntax. Return the resolved identity, version, relevant source locator,
+and the evidence state required by the canonical Librarian policy.
 
-Root dispatches this procedure to `Librarian.lookup` or `Librarian.research`
-through a bounded Assignment; Root does not perform current-source research
-locally.
+That policy owns Context7-first enforcement, allowed fallback reasons, and
+decision authority. Tool documentation supplies facts; Root owns material
+product, architecture, dependency, compatibility, and implementation decisions.

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

@@ -1,16 +1,10 @@
 ---
 name: operations
-description: Use for exact-ref CI or release observation through terminal evidence.
+description: Use for a Worker.operations exact-ref/SHA observation Assignment.
 ---
 
-Observe the exact approved ref and SHA after Root's VCS action. Discover
-whether the repository has separate development and release gates, one combined
-pipeline, or no formal separation. Report terminal green, terminal failure, or
-an exact unavailable or ambiguous blocker. Pending and running are not success.
-Do not rerun, cancel, approve, merge, push, tag, publish, deploy, or otherwise
-mutate external state.
-
-Root dispatches this procedure to `Worker.operations` with the exact ref and
-SHA. Include target-branch or pull-request mergeability evidence when the
-repository or provider exposes it; green CI alone does not prove mergeability.
-Root does not observe terminal operations locally.
+Load [babysit-ci](../babysit-ci/SKILL.md) before observing the supplied exact ref
+and SHA. Return the required terminal gate evidence and any unavailable or
+ambiguous blocker within the Assignment's observation-only authority. Include
+target-branch or pull-request mergeability evidence when the repository or
+provider exposes it; green CI alone does not prove mergeability.

package/dist/assets/plugin/skills/plan-review/SKILL.md

@@ -3,10 +3,9 @@ name: plan-review
 description: Use when a complete Plan needs adversarial feasibility, order, risk, and proof review.
 ---
 
-Inspect the complete Plan for feasibility, ordering, risk, and proof. Repair
-only reviewer-owned plan defects; return material product or architecture
-choices to Root. A Plan revision replaces the canonical revision through the
-semantic plan operation.
+Inspect the complete Plan for feasibility, ordering, risk, and proof. Return
+findings and proposed corrections without mutating the Plan or source. Root
+owns material product or architecture choices and canonical Plan revisions.
 
 Root dispatches this procedure as a bounded Assignment to `Reviewer.plan` and
 consumes its evidence; Root does not perform plan review locally.

package/dist/assets/plugin/skills/testing-quality.md

@@ -11,7 +11,6 @@ strategy. Prefer observable typed or public boundaries. Package-verification
 tests should consume the shipped artifact through one supported outer boundary
 with minimal realistic setup, proving behavior without duplicating the suite.
 
-When Root needs independent local proof, dispatch `Worker.validation` through a
-bounded Assignment. Its filesystem writes are limited to caches, build output,
-and generated test state; it cannot mutate the implementation under
-validation. Root does not run repository tests locally.
+The canonical testing policy owns proportional proof, required gates, and when
+to broaden or repeat checks. Role.task and the Assignment own the validator's
+authority; this reference adds only test-quality criteria.

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

@@ -0,0 +1,16 @@
+# Skill mechanics
+
+Use a skill for a distinct conditional workflow or tool capability. Keep its
+description short and specific enough to distinguish the invocation from nearby
+skills. Avoid broad triggers that compete for ordinary work; audit implicit
+invocation against the other skills the receiver can load.
+
+Keep the main body focused on the shared outcome, boundaries, and acceptance
+criteria. Link branch-specific tool knowledge or uncommon procedures from the
+condition that needs them, so only the selected branch loads its detail. Do not
+split a short coherent rule merely to create more files.
+
+Keep display and invocation metadata in agents/openai.yaml and behavior in its
+single authoritative source. References should supply a missing decision or
+mechanic, not copies of the body or global policy. Preserve provenance and
+license attribution under the original upstream names when renaming a skill.

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

@@ -0,0 +1,47 @@
+---
+name: writing-instructions
+description: Use when authoring or reviewing model-facing instructions for GPT-6.
+---
+
+# Writing instructions
+
+HolyCodex's canonical instruction-authoring skill has a GPT-6 → GPT-6 direction.
+It covers developer_instructions, Root/session policy, specialist and Role.task
+instructions, skill bodies, conditional workflows, and task-specific contracts.
+Model routing identities do not change this behavioral target.
+
+Before writing, identify the receiver's effective context: higher-priority and
+user instructions, repository instructions, Role/task policy, relevant skills,
+tools and capabilities, configuration, and current task context. Add only the
+missing semantic delta. Resolve conflicts against the governing authority;
+do not duplicate a meaning already supplied to the same receiver.
+
+Give each meaning one authoritative owner at the narrowest scope that applies:
+Root/session invariants in Root policy, repository conventions in AGENTS.md,
+shared specialist boundaries in the specialist baseline, route-specific behavior
+in Role.task, and genuinely conditional workflow or tool knowledge in a skill.
+Generated projections derive from or validate against that owner. Invocation
+metadata selects a branch; it does not become a second policy source.
+
+Define the required outcome and completion evidence, bounded authority, relevant
+constraints, material decisions or blockers that escalate, and stopping
+conditions. Keep required lifecycle and safety invariants explicit. Give the
+receiver room to choose routine safe, reversible, in-scope steps. A contract must
+carry authorized work through its requested terminal state, including required
+repair and proof; a first pass or pending gate is not completion.
+
+Remove older-model competence scaffolding, fixed recipes without a required
+ordering constraint, broad reading rituals, stale environment facts, duplicate
+policy, and unnecessary questionnaires. Preserve meaningful repository checks
+and review gates through their canonical owners instead of reproducing them in
+every skill. Use configuration for verbosity rather than generic style padding.
+
+When creating or changing a skill's invocation boundary or conditional branches,
+read [Skill mechanics](SKILL-MECHANICS.md). Other instruction changes do not need
+that reference.
+
+An instruction change is complete when the receiver can act within its authority,
+recognize completion and escalation boundaries, and return sufficient evidence;
+the effective context has no contradictory or duplicate rule for that meaning.
+Validate changed behavior with meaningful proof and repository-required gates,
+using the canonical testing policy rather than inventing extra test rituals.

package/dist/assets/plugin/skills/writing-instructions/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Writing instructions"
+  short_description: "Author and review GPT-6 model instructions."
+  default_prompt: "Use writing-instructions for this instruction change."
+policy:
+  allow_implicit_invocation: true