holycodex 0.16.8 → 0.16.9-2

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.
Files changed (53) hide show
  1. package/README.md +14 -6
  2. package/dist/agent.js +63 -63
  3. package/dist/assets/plugin/plugin.json +1 -1
  4. package/dist/assets/plugin/skills/babysit-ci/SKILL.md +28 -39
  5. package/dist/assets/plugin/skills/babysit-ci/agents/openai.yaml +1 -1
  6. package/dist/assets/plugin/skills/codebase-onboarding/SKILL.md +11 -0
  7. package/dist/assets/plugin/skills/codebase-onboarding/agents/openai.yaml +6 -0
  8. package/dist/assets/plugin/skills/commit/SKILL.md +6 -16
  9. package/dist/assets/plugin/skills/commit/agents/openai.yaml +2 -2
  10. package/dist/assets/plugin/skills/compress/SKILL.md +1 -1
  11. package/dist/assets/plugin/skills/compress/agents/openai.yaml +1 -1
  12. package/dist/assets/plugin/skills/context7-cli/SKILL.md +2 -4
  13. package/dist/assets/plugin/skills/context7-cli/agents/openai.yaml +1 -1
  14. package/dist/assets/plugin/skills/continue-work/SKILL.md +15 -0
  15. package/dist/assets/plugin/skills/continue-work/agents/openai.yaml +6 -0
  16. package/dist/assets/plugin/skills/debugging/SKILL.md +7 -4
  17. package/dist/assets/plugin/skills/debugging/agents/openai.yaml +2 -2
  18. package/dist/assets/plugin/skills/dev-server/SKILL.md +13 -0
  19. package/dist/assets/plugin/skills/dev-server/agents/openai.yaml +6 -0
  20. package/dist/assets/plugin/skills/grill-me/SKILL.md +13 -13
  21. package/dist/assets/plugin/skills/grill-me/agents/openai.yaml +3 -3
  22. package/dist/assets/plugin/skills/handoff/SKILL.md +2 -4
  23. package/dist/assets/plugin/skills/handoff/agents/openai.yaml +1 -1
  24. package/dist/assets/plugin/skills/refactor/SKILL.md +1 -1
  25. package/dist/assets/plugin/skills/refactor/agents/openai.yaml +1 -1
  26. package/dist/assets/plugin/skills/rules/SKILL.md +1 -1
  27. package/dist/assets/plugin/skills/rules/agents/openai.yaml +1 -1
  28. package/dist/assets/plugin/skills/testing-quality.md +0 -4
  29. package/dist/assets/plugin/skills/visual-loop/SKILL.md +21 -0
  30. package/dist/assets/plugin/skills/visual-loop/agents/openai.yaml +6 -0
  31. package/dist/assets/plugin/skills/web-visualize/SKILL.md +16 -0
  32. package/dist/assets/plugin/skills/web-visualize/agents/openai.yaml +6 -0
  33. package/dist/assets/plugin/skills/writing-instructions/SKILL.md +31 -42
  34. package/dist/assets/plugin/skills/writing-instructions/agents/openai.yaml +2 -2
  35. package/dist/index.js +60 -57
  36. package/package.json +2 -2
  37. package/dist/assets/plugin/skills/code-review/SKILL.md +0 -15
  38. package/dist/assets/plugin/skills/code-review/agents/openai.yaml +0 -6
  39. package/dist/assets/plugin/skills/operations/SKILL.md +0 -10
  40. package/dist/assets/plugin/skills/operations/agents/openai.yaml +0 -6
  41. package/dist/assets/plugin/skills/plan/SKILL.md +0 -10
  42. package/dist/assets/plugin/skills/plan/agents/openai.yaml +0 -6
  43. package/dist/assets/plugin/skills/plan-review/SKILL.md +0 -7
  44. package/dist/assets/plugin/skills/plan-review/agents/openai.yaml +0 -6
  45. package/dist/assets/plugin/skills/programming/SKILL.md +0 -8
  46. package/dist/assets/plugin/skills/programming/agents/openai.yaml +0 -6
  47. package/dist/assets/plugin/skills/stop-slop/LICENSE +0 -21
  48. package/dist/assets/plugin/skills/stop-slop/SKILL.md +0 -9
  49. package/dist/assets/plugin/skills/stop-slop/agents/openai.yaml +0 -6
  50. package/dist/assets/plugin/skills/stop-slop/references/examples.md +0 -69
  51. package/dist/assets/plugin/skills/stop-slop/references/phrases.md +0 -128
  52. package/dist/assets/plugin/skills/stop-slop/references/structures.md +0 -134
  53. package/dist/assets/plugin/skills/writing-instructions/SKILL-MECHANICS.md +0 -16
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "holycodex",
3
- "version": "0.16.8",
3
+ "version": "0.16.9-2",
4
4
  "description": "Root-directed capabilities and deterministic installed assets for HolyCodex.",
5
5
  "author": {
6
6
  "name": "David Basile Filho",
@@ -1,55 +1,44 @@
1
1
  ---
2
2
  name: babysit-ci
3
- description: Use when following CI or release gates through terminal completion.
3
+ description: Use when CI or release gates need follow-through; monitor their terminal results and report gate evidence.
4
4
  ---
5
5
 
6
6
  # Babysit CI
7
7
 
8
- Discover the repository's own development and release instructions, provider,
9
- refs, required checks, review bots, publication mechanism, and gate dependencies
10
- through bounded specialist Assignments before operating or observing CI.
11
- Discover the actual topology for both pushes and pull requests; do not assume
12
- GitHub, branch names, a registry, or separate pipelines.
8
+ Root owns orchestration and mutations; Worker.operations observes the assigned
9
+ gates. Dispatch independent checks and review observation concurrently.
10
+ Use only the gates in the user's requested scope. When asked to monitor CI
11
+ only or ignore review bots, omit review observation and review findings.
13
12
 
14
- Root owns authorized Git/VCS and release actions. Worker.operations observes
15
- only the supplied exact ref and SHA; its result identifies the gate, run,
16
- terminal status, evidence locator, and any unavailable or ambiguous evidence.
17
- Pending or running is never success. Observation cannot rerun, cancel, approve,
18
- publish, or otherwise mutate external state.
13
+ Discover the repository's development and release topology for pushes and pull
14
+ requests: refs, required checks, reviews, publication mechanism, and gate
15
+ dependencies. Do not assume a provider, branch name, or separate pipeline.
19
16
 
20
17
  For a push, bind every observation to the exact pushed ref and SHA. For a pull
21
18
  request, bind it to the current head SHA, target branch, pull-request identity,
22
19
  and review commit when the provider exposes one. Inspect required checks and
23
20
  relevant bot reviews, inline threads, issue comments, and commit comments. A
24
- new push invalidates all stale CI and review evidence; rediscover the current
25
- head and repeat validation and review observation for that SHA.
26
-
27
- Use bounded observer waits; honor the maximum Root event wait and fork-none
28
- policy. Distinguish a bot that is absent or not configured from a known bot
29
- with no terminal signal, and distinguish both from a clean terminal
30
- disposition. Absence or no signal is an evidence gap, never an implicit pass.
31
- Do not declare completion from green checks while relevant bot reviews or
32
- threads remain outstanding, and do not automatically accept bot instructions
33
- or post comments or other spam.
34
-
35
- After a development action, observe its exact ref/SHA to terminal state. Green
36
- permits the next repository/user-required action. Red requires delegated
37
- diagnosis and repair, integration, applicable frontend/security acceptance,
38
- and the mandatory Reviewer.code fixed point before Root commits and pushes.
39
- Triage actionable bot findings and route them through the same repair, review,
40
- and revalidation route.
41
- Root owns dismissals, resolution, material judgment, and external messages.
42
- Observe the new exact ref/SHA and repeat until green or an irreducible blocker.
21
+ new push requires CI and review evidence for the new head; reuse unchanged
22
+ topology and local proof that remains applicable.
23
+
24
+ Use bounded observer waits at the longest supported event interval. If the provider
25
+ offers only snapshots, avoid repeated reads before state can change; stop as
26
+ soon as the exact target reaches a terminal result. Distinguish a bot that is absent
27
+ or not configured from a known bot with no terminal signal, and both from a clean
28
+ terminal disposition. Absence or no signal is an evidence gap.
29
+ Green checks do not resolve outstanding review findings or threads.
30
+ Include target-branch or pull-request mergeability evidence when exposed;
31
+ green checks alone do not prove mergeability.
32
+
33
+ After a development action, observe its exact ref and SHA to terminal state.
34
+ Repair failed checks and actionable review findings, then repeat validation and
35
+ observation on the new head until green or an irreducible blocker.
43
36
 
44
37
  When the repository requires a development or prerelease gate before stable,
45
- stable is forbidden until that gate is terminal green. Root then performs the
46
- repository's actual authorized stable mechanism and delegates terminal
47
- observation. Stable failure enters the same repair/review/VCS cycle and passes
48
- through every required development gate before another stable attempt.
38
+ wait for terminal green before stable. A stable failure enters the same repair
39
+ and review cycle, including required development gates before another attempt.
49
40
 
50
41
  Use one gate for a combined pipeline. Do not invent a distinct release gate.
51
- Completion requires required checks to be terminal green and every relevant bot
52
- finding to have a supported terminal disposition, with an honest record of any
53
- bot absence or missing terminal signal. A successful push, started pipeline,
54
- or green checks without current review evidence does not complete this workflow;
55
- return a precise external blocker when the evidence cannot be obtained.
42
+ Completion requires terminal green checks and a supported terminal disposition
43
+ for relevant reviews on the current SHA. Return the precise external blocker
44
+ when terminal evidence cannot be obtained.
@@ -1,6 +1,6 @@
1
1
  interface:
2
2
  display_name: "Babysit CI"
3
3
  short_description: "Follow repository CI and release gates to completion."
4
- default_prompt: "Use babysit-ci for this CI or release lifecycle."
4
+ default_prompt: "Use $babysit-ci for this task."
5
5
  policy:
6
6
  allow_implicit_invocation: true
@@ -0,0 +1,11 @@
1
+ ---
2
+ name: codebase-onboarding
3
+ description: Use when someone needs a repository explanation or contributor orientation; summarize its purpose, structure, and workflows from evidence.
4
+ ---
5
+
6
+ Provide a bounded, read-only orientation to the current repository or answer a
7
+ repository question from its evidence. Cover the purpose, key structure and
8
+ dependencies, entry points, and important execution or data flows relevant to
9
+ the request. Return concrete evidence and file locators; Root synthesizes the
10
+ explanation from specialist findings. Change persistent documentation only
11
+ when requested.
@@ -0,0 +1,6 @@
1
+ interface:
2
+ display_name: "Codebase onboarding"
3
+ short_description: "Explain a repository from a bounded read-only map."
4
+ default_prompt: "Use $codebase-onboarding for this task."
5
+ policy:
6
+ allow_implicit_invocation: true
@@ -1,20 +1,10 @@
1
1
  ---
2
2
  name: commit
3
- description: Use when Root creates a local commit after scope and proof are settled.
3
+ description: Use when Root is ready to commit settled and verified work; create the smallest coherent commits that follow repository conventions.
4
4
  ---
5
5
 
6
- Root uses this workflow after exact scope and local proof are settled. Verify
7
- the diff, generated-artifact cleanup, ignore coverage, and staged secret
8
- exclusions before creating the local commit.
9
-
10
- Require a passing Reviewer.code fixed-point result after implementation or a
11
- major codebase change before this VCS exception is used.
12
-
13
- After integration, Root commits the exact authorized scope. For subsequent CI
14
- or release work, load [babysit-ci](../babysit-ci/SKILL.md), which owns that
15
- lifecycle. Root's authority policy owns approval requirements and existing
16
- user authorization.
17
-
18
- Completion: Root reports the commit identity and post-commit status with
19
- redacted evidence, or returns an exact reproducible blocker. Never print secret
20
- values.
6
+ After scope and proof are settled, follow the repository's commit conventions
7
+ and create the smallest coherent set of atomic commits, each with a separately
8
+ meaningful purpose. Include only the authorized scope and review the staged
9
+ diff before committing. Return commit identities and the resulting repository
10
+ state, or the exact blocker.
@@ -1,6 +1,6 @@
1
1
  interface:
2
2
  display_name: "Commit"
3
- short_description: "Create one local commit with exact scope proof."
4
- default_prompt: "Open the commit workflow for this invocation."
3
+ short_description: "Create coherent local commits with exact scope proof."
4
+ default_prompt: "Use $commit for this task."
5
5
  policy:
6
6
  allow_implicit_invocation: false
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: compress
3
- description: Use when assigned text must be shortened without changing its contract or voice.
3
+ description: Use when assigned text must be shortened without changing its contract or voice; preserve meaning and constraints in a more concise version.
4
4
  ---
5
5
 
6
6
  Shorten only the assigned text. Preserve meaning, constraints, technical terms,
@@ -1,6 +1,6 @@
1
1
  interface:
2
2
  display_name: "Compress"
3
3
  short_description: "Shorten assigned text without changing its contract or voice."
4
- default_prompt: "Open the compression workflow for this invocation."
4
+ default_prompt: "Use $compress for this task."
5
5
  policy:
6
6
  allow_implicit_invocation: true
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: context7-cli
3
- description: Use when querying current technical documentation with Context7 CLI.
3
+ description: Use when current technical documentation is needed through Context7 CLI; find the requested version-specific facts.
4
4
  ---
5
5
 
6
6
  Resolve the requested library identity with the installed ctx7 CLI, then query
@@ -8,6 +8,4 @@ narrowly for the requested version and fact. Use the CLI's current help for
8
8
  command syntax. Return the resolved identity, version, relevant source locator,
9
9
  and the evidence state required by the canonical Librarian policy.
10
10
 
11
- That policy owns Context7-first enforcement, allowed fallback reasons, and
12
- decision authority. Tool documentation supplies facts; Root owns material
13
- product, architecture, dependency, compatibility, and implementation decisions.
11
+ The canonical Librarian policy owns Context7-first enforcement and fallback.
@@ -1,6 +1,6 @@
1
1
  interface:
2
2
  display_name: "Context7 CLI"
3
3
  short_description: "Find assigned current library and API documentation first."
4
- default_prompt: "Open the current documentation lookup workflow for this invocation."
4
+ default_prompt: "Use $context7-cli for this task."
5
5
  policy:
6
6
  allow_implicit_invocation: false
@@ -0,0 +1,15 @@
1
+ ---
2
+ name: continue-work
3
+ description: Use when the user asks Root to continue existing HolyCodex work; restore its current state and carry unresolved work forward.
4
+ ---
5
+
6
+ Restore the current Intent, Plan if present, Assignments, accepted evidence,
7
+ decisions, completed work, and unresolved work. Reconcile that state with the
8
+ current repository and continue normal HolyCodex orchestration from the last
9
+ supported point; do not restart the same work as a new Intent.
10
+
11
+ Use `holycodex-agent state diagnose --intent <ref>` only when safe continuation
12
+ cannot be established from the available state and current evidence. Resolve a
13
+ recoverable inconsistency through its owning state operation, or return the
14
+ exact blocker to Root. An active Assignment is not failed without evidence that
15
+ its invocation stopped.
@@ -0,0 +1,6 @@
1
+ interface:
2
+ display_name: "Continue work"
3
+ short_description: "Resume the current HolyCodex work from durable state."
4
+ default_prompt: "Use $continue-work for this task."
5
+ policy:
6
+ allow_implicit_invocation: true
@@ -1,8 +1,11 @@
1
1
  ---
2
2
  name: debugging
3
- description: Use for a reproducible crash, wrong result, regression, hang, race, leak, or slowdown.
3
+ description: Use when an observable defect or unexplained behavior needs diagnosis; establish its cause and repair it within the assigned boundary.
4
4
  ---
5
5
 
6
- Reproduce the defect before changing code. Capture the smallest failing input
7
- and trace, identify the evidence-backed cause, make the narrow repair, and prove
8
- the regression is gone. Escalate competing causes or a material redesign.
6
+ Reproduce the issue with the smallest useful case when practical; otherwise,
7
+ establish its cause from strong observed evidence. Bound log review and use
8
+ temporary instrumentation only when it resolves uncertainty; remove temporary
9
+ instrumentation afterward. Repair only the assigned seam and prove the
10
+ regression is gone at an appropriate behavior boundary. Escalate materially
11
+ unresolved causes or a redesign.
@@ -1,6 +1,6 @@
1
1
  interface:
2
2
  display_name: "Debugging"
3
- short_description: "Reproduce and repair one observable defect."
4
- default_prompt: "Open the debugging workflow for this invocation."
3
+ short_description: "Diagnose an observable defect through reproduction or strong evidence."
4
+ default_prompt: "Use $debugging for this task."
5
5
  policy:
6
6
  allow_implicit_invocation: false
@@ -0,0 +1,13 @@
1
+ ---
2
+ name: dev-server
3
+ description: Use when a shared background development server is needed; let Root start, reuse, and manage one server for the session.
4
+ ---
5
+
6
+ Root only. Reuse a healthy server for the current project; otherwise start the
7
+ repository's development command in the background using the active runtime's
8
+ process controls. Confirm readiness, return its URL, and share the URL with
9
+ specialists so they reuse it. Root retains the process handle. Keep it alive
10
+ across Assignments; restart only when configuration or server state requires
11
+ it. Stop only the process owned by this session when
12
+ no longer needed. Specialists request server changes through their terminal
13
+ report rather than starting competing servers.
@@ -0,0 +1,6 @@
1
+ interface:
2
+ display_name: "Dev server"
3
+ short_description: "Root manages one shared background development server."
4
+ default_prompt: "Use $dev-server for this task."
5
+ policy:
6
+ allow_implicit_invocation: false
@@ -1,21 +1,21 @@
1
1
  ---
2
2
  name: grill-me
3
- description: Use when an unspecified choice has multiple reasonable outcomes that could materially change the work.
3
+ description: Use when a material user decision blocks authorized work; ask Root's concise question through request_user_input.
4
4
  ---
5
5
 
6
6
  # Grill me
7
7
 
8
- Use this skill only for a material unresolved choice involving architecture,
9
- behavior, UX, compatibility, dependencies, cost, security, external effects,
10
- or another meaningful user-visible result. Infer obvious safe defaults and
11
- continue without questioning routine omissions.
8
+ Use this skill only when an unresolved material user decision blocks the next
9
+ step. It is not for routine omissions, safe implementation choices, or
10
+ planning.
12
11
 
13
- Before asking, finish authorized discovery and reversible preparation that can
14
- narrow the choice without deciding it. Ask only for the earliest unresolved
15
- choice required by the next executable phase. After the answer, continue the
16
- discovery and ask the next dependent question only if it remains material.
17
- Avoid questionnaires about later phases whose relevance may change.
12
+ Root only. For every clarification, call `request_user_input` with the smallest
13
+ set of questions needed to resolve the decision, in the user's language and
14
+ grounded in known evidence. Never ask what the session already establishes.
15
+ If no material question remains, continue without invoking this skill.
18
16
 
19
- Persist the answer through the current Intent or Plan state model. Return to
20
- Root with the selected decision, its scope, and the evidence or dependency it
21
- unblocked; use `needs_root_input` when the choice remains unresolved.
17
+ Continue independent authorized work while awaiting the answer. Do not ask
18
+ about hypothetical later phases. Specialists must not ask the user; they
19
+ return a `needs_root_input` outcome to Root with the specific decision and
20
+ why it blocks their Assignment. Root uses that outcome only when the answer
21
+ prevents further progress.
@@ -1,6 +1,6 @@
1
1
  interface:
2
2
  display_name: "Grill me"
3
- short_description: "Ask only material, dependency-ordered clarification questions."
4
- default_prompt: "Open the material-choice clarification workflow for this invocation."
3
+ short_description: "Ask Root-only material questions through request_user_input."
4
+ default_prompt: "Use $grill-me for this task."
5
5
  policy:
6
- allow_implicit_invocation: true
6
+ allow_implicit_invocation: false
@@ -1,11 +1,9 @@
1
1
  ---
2
2
  name: handoff
3
- description: Use when a caller needs a redacted projection of current Intent state for resume or export.
3
+ description: Use when current Intent state must be resumed or exported; produce a compact redacted status projection with evidence and next action.
4
4
  ---
5
5
 
6
6
  Produce one compact projection of current Intent, Plan, and Assignment status,
7
7
  evidence, blockers, remaining risk, and the exact next action. Omit secrets,
8
8
  raw prompts, transcripts, and unchanged narration. Handoff is an export view;
9
- the semantic state remains authoritative. Lead with observable evidence and
10
- material decisions, reuse stable facts, and inspect or include large material
11
- only when a material decision, conflict, failure, or finding requires it.
9
+ the semantic state remains authoritative.
@@ -1,6 +1,6 @@
1
1
  interface:
2
2
  display_name: "Handoff"
3
3
  short_description: "Export a redacted projection of current Intent state."
4
- default_prompt: "Open the handoff workflow for this invocation."
4
+ default_prompt: "Use $handoff for this task."
5
5
  policy:
6
6
  allow_implicit_invocation: false
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: refactor
3
- description: Use when one decided seam needs restructuring while preserving behavior and interfaces.
3
+ description: Use when one decided seam needs restructuring without behavior or interface changes; refactor that seam and verify its boundaries.
4
4
  ---
5
5
 
6
6
  Restructure only the decided seam. Trace callers before changing a shared root
@@ -1,6 +1,6 @@
1
1
  interface:
2
2
  display_name: "Refactor"
3
3
  short_description: "Restructure one decided seam while preserving its contract."
4
- default_prompt: "Open the bounded refactor workflow for this invocation."
4
+ default_prompt: "Use $refactor for this task."
5
5
  policy:
6
6
  allow_implicit_invocation: true
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: rules
3
- description: Use when a repository rule needs discovery, validation, or diagnosis of an application failure.
3
+ description: Use when a repository rule needs discovery, validation, or failure diagnosis; trace its owner and report the rule with evidence.
4
4
  ---
5
5
 
6
6
  Trace the owning rule loader and its limits, caching, trust boundary, and
@@ -1,6 +1,6 @@
1
1
  interface:
2
2
  display_name: "Rules"
3
3
  short_description: "Trace one repository rule discovery or application failure."
4
- default_prompt: "Open the repository rules workflow for this invocation."
4
+ default_prompt: "Use $rules for this task."
5
5
  policy:
6
6
  allow_implicit_invocation: false
@@ -10,7 +10,3 @@ wording, irrelevant call order, broad repository shape, or one implementation
10
10
  strategy. Prefer observable typed or public boundaries. Package-verification
11
11
  tests should consume the shipped artifact through one supported outer boundary
12
12
  with minimal realistic setup, proving behavior without duplicating the suite.
13
-
14
- The canonical testing policy owns proportional proof, required gates, and when
15
- to broaden or repeat checks. Role.task and the Assignment own the validator's
16
- authority; this reference adds only test-quality criteria.
@@ -0,0 +1,21 @@
1
+ ---
2
+ name: visual-loop
3
+ description: Use when visual changes need rendered judgment; Root judges the result after specialists inspect their own work and assigns repairs.
4
+ ---
5
+
6
+ Root only, for visual tasks. Orchestrate implementation, inspect its rendered
7
+ result, judge the visual output, dispatch targeted changes to specialists, and
8
+ repeat until the result is excellent and meets the user's requirements.
9
+
10
+ Specialists implementing visual changes inspect and judge their own current
11
+ render, repair visible defects, and recheck before returning. This local
12
+ implementation loop supplements Root's higher-level visual acceptance.
13
+
14
+ Follow the visual-inspection order generated for Root's selected capabilities.
15
+ Unselected capabilities are not fallbacks. Honor higher-priority active-surface
16
+ tool rules. Use the shared development server when needed. Inspect relevant viewports and
17
+ states against the user's requirements and repository design system. Report
18
+ the specific blocker if no available method supports the required judgment.
19
+
20
+ Reuse unaffected evidence. Do not run this loop for logic-only changes.
21
+ Specialists own implementation and delegated interaction checks.
@@ -0,0 +1,6 @@
1
+ interface:
2
+ display_name: "Visual loop"
3
+ short_description: "Root judges rendered changes after specialists inspect their work and assigns repairs."
4
+ default_prompt: "Use $visual-loop for this task."
5
+ policy:
6
+ allow_implicit_invocation: false
@@ -0,0 +1,16 @@
1
+ ---
2
+ name: web-visualize
3
+ description: Use when the user requests or approves an interactive visualization; create a user-facing visual experience from the supplied material.
4
+ ---
5
+
6
+ Use ChatGPT Sites to create an interactive, user-facing visualization that
7
+ turns the supplied plan, analysis, design, structured information, or other
8
+ useful material into a clear, usable result. A visualization request authorizes
9
+ its preparation. Root delegates implementation and judges the rendered result
10
+ with visual-loop; follow the active capability's publication boundary.
11
+
12
+ Return the visualization and enough context to verify that it answers the
13
+ request. If the requested result cannot be completed with an authorized,
14
+ available capability, return the specific blocker to Root. Publication,
15
+ sharing, and other consequential external effects require their usual
16
+ authorization.
@@ -0,0 +1,6 @@
1
+ interface:
2
+ display_name: "Web visualize"
3
+ short_description: "Turn useful information into an interactive user-facing visualization."
4
+ default_prompt: "Use $web-visualize for this task."
5
+ policy:
6
+ allow_implicit_invocation: true
@@ -1,48 +1,37 @@
1
1
  ---
2
2
  name: writing-instructions
3
- description: Use when authoring or reviewing model-facing instructions for GPT-6.
3
+ description: Use when model-facing instructions need authorship or review; make them coherent, scoped, and complete for their receiver.
4
4
  ---
5
5
 
6
6
  # Writing instructions
7
7
 
8
- HolyCodex's canonical instruction-authoring skill has a GPT-6 → GPT-6 direction.
9
- It covers developer_instructions, Root/session policy, specialist and Role.task
10
- instructions, skill bodies, conditional workflows, and task-specific contracts.
11
- Keep shared behavioral policy under one owner across model routes, while
12
- accounting for demonstrated model-specific capability or prompting differences.
13
-
14
- Before writing, identify the receiver's effective context: higher-priority and
15
- user instructions, repository instructions, Role/task policy, relevant skills,
16
- tools and capabilities, configuration, and current task context. Add only the
17
- missing semantic delta. Resolve conflicts against the governing authority;
18
- do not duplicate a meaning already supplied to the same receiver.
19
-
20
- Give each meaning one authoritative owner at the narrowest scope that applies:
21
- Root/session invariants in Root policy, repository conventions in AGENTS.md,
22
- shared specialist boundaries in the specialist baseline, route-specific behavior
23
- in Role.task, and genuinely conditional workflow or tool knowledge in a skill.
24
- Generated projections derive from or validate against that owner. Invocation
25
- metadata selects a branch; it does not become a second policy source.
26
-
27
- Define the required outcome and completion evidence, bounded authority, relevant
28
- constraints, material decisions or blockers that escalate, and stopping
29
- conditions. Keep required lifecycle and safety invariants explicit. Give the
30
- receiver room to choose routine safe, reversible, in-scope steps. A contract must
31
- carry authorized work through its requested terminal state, including required
32
- repair and proof; a first pass or pending gate is not completion.
33
-
34
- Remove older-model competence scaffolding, fixed recipes without a required
35
- ordering constraint, broad reading rituals, stale environment facts, duplicate
36
- policy, and unnecessary questionnaires. Preserve meaningful repository checks
37
- and review gates through their canonical owners instead of reproducing them in
38
- every skill. Use configuration for verbosity rather than generic style padding.
39
-
40
- When creating or changing a skill's invocation boundary or conditional branches,
41
- read [Skill mechanics](SKILL-MECHANICS.md). Other instruction changes do not need
42
- that reference.
43
-
44
- An instruction change is complete when the receiver can act within its authority,
45
- recognize completion and escalation boundaries, and return sufficient evidence;
46
- the effective context has no contradictory or duplicate rule for that meaning.
47
- Validate changed behavior with meaningful proof and repository-required gates,
48
- using the canonical testing policy rather than inventing extra test rituals.
8
+ Identify the receiver's effective context: instruction hierarchy, repository
9
+ rules, Root or Role.task policy, selected skills, tools, configuration, and
10
+ Assignment facts. Add only the missing constraints; resolve contradictions
11
+ against the governing authority. User instructions override skill guidelines.
12
+
13
+ Give each meaning one owner: Root/session policy for orchestration and judgment,
14
+ AGENTS.md for repository conventions, the specialist baseline for shared
15
+ boundaries, Role.task for task authority, and skills for conditional workflows
16
+ or tool knowledge. Generated projections derive from that owner. Metadata
17
+ selects the workflow; it does not duplicate its policy.
18
+
19
+ State the outcome, bounded authority, material constraints, completion evidence,
20
+ and escalation conditions. Preserve known facts needed to act; point to sources
21
+ for details the receiver can discover reliably. Routine safe in-scope choices
22
+ should proceed without questions. Carry authorized work through repair and proof.
23
+
24
+ Remove redundant policy, older-model scaffolding, broad reading rituals, rigid
25
+ recipes without a real dependency, hypothetical gates, and repeated testing.
26
+ Preserve lifecycle invariants and required checks. Use configuration for default
27
+ verbosity; use prompts for task-specific evidence and output requirements.
28
+
29
+ Keep skill descriptions short and situation-first. Audit triggers alongside
30
+ nearby skills; avoid skills that merely restate a task contract. Keep coherent
31
+ shared guidance together and link uncommon branch-specific mechanics only from
32
+ the condition that needs them. Metadata default prompts invoke the named skill
33
+ without embedding another instruction source. Preserve upstream attribution.
34
+
35
+ Validate the effective projection, not exact prose: the receiver can act within
36
+ its authority, recognize completion and blockers, and return sufficient evidence
37
+ without contradictory rules. Reuse the canonical testing policy.
@@ -1,6 +1,6 @@
1
1
  interface:
2
2
  display_name: "Writing instructions"
3
- short_description: "Author and review GPT-6 model instructions."
4
- default_prompt: "Use writing-instructions for this instruction change."
3
+ short_description: "Author and review model-facing instructions."
4
+ default_prompt: "Use $writing-instructions for this task."
5
5
  policy:
6
6
  allow_implicit_invocation: true