holycodex 0.16.9-dev.103.1 → 0.16.9-dev.106.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/dist/assets/plugin/plugin.json +1 -1
- package/dist/assets/plugin/skills/babysit-ci/SKILL.md +1 -1
- package/dist/assets/plugin/skills/code-review/SKILL.md +1 -1
- package/dist/assets/plugin/skills/codebase-onboarding/SKILL.md +1 -1
- package/dist/assets/plugin/skills/commit/SKILL.md +1 -1
- package/dist/assets/plugin/skills/compress/SKILL.md +1 -1
- package/dist/assets/plugin/skills/context7-cli/SKILL.md +1 -1
- package/dist/assets/plugin/skills/continue-work/SKILL.md +1 -1
- package/dist/assets/plugin/skills/debugging/SKILL.md +1 -1
- package/dist/assets/plugin/skills/grill-me/SKILL.md +1 -1
- package/dist/assets/plugin/skills/handoff/SKILL.md +1 -1
- package/dist/assets/plugin/skills/operations/SKILL.md +1 -1
- package/dist/assets/plugin/skills/plan/SKILL.md +1 -1
- package/dist/assets/plugin/skills/plan-review/SKILL.md +1 -1
- package/dist/assets/plugin/skills/programming/SKILL.md +1 -1
- package/dist/assets/plugin/skills/refactor/SKILL.md +1 -1
- package/dist/assets/plugin/skills/rules/SKILL.md +1 -1
- package/dist/assets/plugin/skills/stop-slop/SKILL.md +1 -1
- package/dist/assets/plugin/skills/web-visualize/SKILL.md +1 -1
- package/dist/assets/plugin/skills/writing-instructions/SKILL.md +26 -3
- package/dist/index.js +53 -49
- package/package.json +2 -2
- package/dist/assets/plugin/skills/writing-instructions/SKILL-MECHANICS.md +0 -16
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: code-review
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when implementation is complete and Root needs adversarial code review; find defects and repair them within the assigned boundary until review reaches a fixed point.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
Inspect the integrated implementation against the `Reviewer.code` contract.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: codebase-onboarding
|
|
3
|
-
description: Use when
|
|
3
|
+
description: Use when someone needs a repository explanation or contributor orientation; summarize its purpose, structure, and workflows from evidence.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
Provide a bounded, read-only orientation to the current repository or answer a
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: commit
|
|
3
|
-
description: Use when Root
|
|
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
6
|
After scope and proof are settled, follow the repository's commit conventions
|
|
@@ -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
|
---
|
|
2
2
|
name: context7-cli
|
|
3
|
-
description: Use when
|
|
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
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: continue-work
|
|
3
|
-
description: Use when the user asks Root to continue
|
|
3
|
+
description: Use when the user asks Root to continue existing HolyCodex work; restore its current state and carry unresolved work forward.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
Restore the current Intent, Plan if present, Assignments, accepted evidence,
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: debugging
|
|
3
|
-
description: Use
|
|
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
6
|
Reproduce the issue with the smallest useful case when practical; otherwise,
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: grill-me
|
|
3
|
-
description: Use when an unspecified choice has multiple
|
|
3
|
+
description: Use when an unspecified choice has multiple materially different outcomes; ask focused questions to resolve the decision before work depends on it.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Grill me
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: handoff
|
|
3
|
-
description: Use when
|
|
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,
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: operations
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use when assigned a Worker.operations observation of an exact ref and SHA; verify terminal gates and report evidence or blockers.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
Load [babysit-ci](../babysit-ci/SKILL.md) before observing the supplied exact ref
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: plan
|
|
3
|
-
description: Use when unresolved architecture, scope, coordination, or material risk
|
|
3
|
+
description: Use when unresolved architecture, scope, coordination, or material risk needs resolution; produce an implementation-ready Plan with owners, seams, and proof.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
Resolve the current material choices into an implementation-ready Plan with
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: plan-review
|
|
3
|
-
description: Use when a complete Plan needs adversarial feasibility,
|
|
3
|
+
description: Use when a complete Plan needs adversarial review; assess feasibility, ordering, risk, and proof, then return findings and corrections.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
Inspect the complete Plan for feasibility, ordering, risk, and proof. Return
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: programming
|
|
3
|
-
description: Use when Root has decided a bounded implementation seam
|
|
3
|
+
description: Use when Root has decided a bounded implementation seam and its acceptance behavior; implement that seam and prove the required behavior.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
Implement only the decided seam and prove its acceptance behavior at the least
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: refactor
|
|
3
|
-
description: Use when one decided seam needs restructuring
|
|
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
|
---
|
|
2
2
|
name: rules
|
|
3
|
-
description: Use when a repository rule needs discovery, validation, or diagnosis
|
|
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
|
---
|
|
2
2
|
name: stop-slop
|
|
3
|
-
description: Use when assigned prose
|
|
3
|
+
description: Use when assigned prose has predictable AI writing patterns; remove them while preserving meaning and voice.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
Edit only the assigned prose. Remove filler, formulaic structure, vague claims,
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: web-visualize
|
|
3
|
-
description: Use when the user requests an interactive visualization
|
|
3
|
+
description: Use when the user requests or approves an interactive visualization; create a user-facing visual experience from the supplied material.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
Use ChatGPT Sites to create an interactive, user-facing visualization that
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: writing-instructions
|
|
3
|
-
description: Use when
|
|
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
|
|
@@ -23,6 +23,17 @@ in Role.task, and genuinely conditional workflow or tool knowledge in a skill.
|
|
|
23
23
|
Generated projections derive from or validate against that owner. Invocation
|
|
24
24
|
metadata selects a branch; it does not become a second policy source.
|
|
25
25
|
|
|
26
|
+
Write instructions as short as possible without losing information that
|
|
27
|
+
materially constrains correct behavior. Preserve known task facts, defects,
|
|
28
|
+
distinctions, invariants, authority boundaries, required outcomes, and
|
|
29
|
+
acceptance conditions; do not make the receiver rediscover relevant known
|
|
30
|
+
facts. For implementation details that are not part of the contract and can be
|
|
31
|
+
reliably discovered during execution, point toward the authoritative source
|
|
32
|
+
instead of embedding them. Prefer generic guidance where the meaning is
|
|
33
|
+
general. Name exact implementation details only when needed to locate
|
|
34
|
+
authority, describe a known defect, preserve a distinction, or constrain exact
|
|
35
|
+
behavior.
|
|
36
|
+
|
|
26
37
|
Define the required outcome and completion evidence, bounded authority, relevant
|
|
27
38
|
constraints, material decisions or blockers that escalate, and stopping
|
|
28
39
|
conditions. Keep required lifecycle and safety invariants explicit. Give the
|
|
@@ -36,8 +47,20 @@ policy, and unnecessary questionnaires. Preserve meaningful repository checks
|
|
|
36
47
|
and review gates through their canonical owners instead of reproducing them in
|
|
37
48
|
every skill. Use configuration for verbosity rather than generic style padding.
|
|
38
49
|
|
|
39
|
-
|
|
40
|
-
|
|
50
|
+
Use a skill for a distinct conditional workflow or tool capability. Keep its
|
|
51
|
+
description short and specific enough to distinguish the invocation from
|
|
52
|
+
nearby skills. Avoid broad triggers that compete for ordinary work; audit
|
|
53
|
+
implicit invocation against the other skills the receiver can load.
|
|
54
|
+
|
|
55
|
+
Keep the main body focused on the shared outcome, boundaries, and acceptance
|
|
56
|
+
criteria. Link branch-specific tool knowledge or uncommon procedures from the
|
|
57
|
+
condition that needs them, so only the selected branch loads that detail. Do
|
|
58
|
+
not split a short coherent rule merely to create more files.
|
|
59
|
+
|
|
60
|
+
Keep display and invocation metadata in agents/openai.yaml and behavior in its
|
|
61
|
+
single authoritative source. References should supply a missing decision or
|
|
62
|
+
mechanic, not copies of the body or global policy. Preserve provenance and
|
|
63
|
+
license attribution under the original upstream names when renaming a skill.
|
|
41
64
|
|
|
42
65
|
An instruction change is complete when the receiver can act within its authority,
|
|
43
66
|
recognize completion and escalation boundaries, and return sufficient evidence;
|