holycodex 0.16.8 → 0.16.9-dev.103.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/README.md +9 -3
- package/dist/agent.js +50 -41
- package/dist/assets/plugin/plugin.json +1 -1
- package/dist/assets/plugin/skills/babysit-ci/SKILL.md +15 -35
- package/dist/assets/plugin/skills/code-review/SKILL.md +0 -7
- package/dist/assets/plugin/skills/codebase-onboarding/SKILL.md +11 -0
- package/dist/assets/plugin/skills/codebase-onboarding/agents/openai.yaml +6 -0
- package/dist/assets/plugin/skills/commit/SKILL.md +5 -15
- package/dist/assets/plugin/skills/commit/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/context7-cli/SKILL.md +1 -3
- package/dist/assets/plugin/skills/continue-work/SKILL.md +15 -0
- package/dist/assets/plugin/skills/continue-work/agents/openai.yaml +6 -0
- package/dist/assets/plugin/skills/debugging/SKILL.md +7 -4
- package/dist/assets/plugin/skills/debugging/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/handoff/SKILL.md +1 -3
- package/dist/assets/plugin/skills/programming/SKILL.md +2 -3
- package/dist/assets/plugin/skills/testing-quality.md +0 -4
- package/dist/assets/plugin/skills/web-visualize/SKILL.md +17 -0
- package/dist/assets/plugin/skills/web-visualize/agents/openai.yaml +6 -0
- package/dist/assets/plugin/skills/writing-instructions/SKILL.md +7 -9
- package/dist/assets/plugin/skills/writing-instructions/agents/openai.yaml +1 -1
- package/dist/index.js +51 -53
- package/package.json +3 -3
|
@@ -5,17 +5,9 @@ description: Use when following CI or release gates through terminal completion.
|
|
|
5
5
|
|
|
6
6
|
# Babysit CI
|
|
7
7
|
|
|
8
|
-
Discover the repository's
|
|
9
|
-
refs, required checks,
|
|
10
|
-
|
|
11
|
-
Discover the actual topology for both pushes and pull requests; do not assume
|
|
12
|
-
GitHub, branch names, a registry, or separate pipelines.
|
|
13
|
-
|
|
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.
|
|
8
|
+
Discover the repository's development and release topology for pushes and pull
|
|
9
|
+
requests: refs, required checks, reviews, publication mechanism, and gate
|
|
10
|
+
dependencies. Do not assume a provider, branch name, or separate pipeline.
|
|
19
11
|
|
|
20
12
|
For a push, bind every observation to the exact pushed ref and SHA. For a pull
|
|
21
13
|
request, bind it to the current head SHA, target branch, pull-request identity,
|
|
@@ -24,32 +16,20 @@ relevant bot reviews, inline threads, issue comments, and commit comments. A
|
|
|
24
16
|
new push invalidates all stale CI and review evidence; rediscover the current
|
|
25
17
|
head and repeat validation and review observation for that SHA.
|
|
26
18
|
|
|
27
|
-
Use bounded observer waits
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
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.
|
|
19
|
+
Use bounded observer waits. Distinguish a bot that is absent or not configured
|
|
20
|
+
from a known bot with no terminal signal, and both from a clean terminal
|
|
21
|
+
disposition. Absence or no signal is an evidence gap. Green checks do not
|
|
22
|
+
resolve outstanding review findings or threads.
|
|
34
23
|
|
|
35
|
-
After a development action, observe its exact ref
|
|
36
|
-
|
|
37
|
-
|
|
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.
|
|
24
|
+
After a development action, observe its exact ref and SHA to terminal state.
|
|
25
|
+
Repair failed checks and actionable review findings, then repeat validation and
|
|
26
|
+
observation on the new head until green or an irreducible blocker.
|
|
43
27
|
|
|
44
28
|
When the repository requires a development or prerelease gate before stable,
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
observation. Stable failure enters the same repair/review/VCS cycle and passes
|
|
48
|
-
through every required development gate before another stable attempt.
|
|
29
|
+
wait for terminal green before stable. A stable failure enters the same repair
|
|
30
|
+
and review cycle, including required development gates before another attempt.
|
|
49
31
|
|
|
50
32
|
Use one gate for a combined pipeline. Do not invent a distinct release gate.
|
|
51
|
-
Completion requires
|
|
52
|
-
|
|
53
|
-
|
|
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.
|
|
33
|
+
Completion requires terminal green checks and a supported terminal disposition
|
|
34
|
+
for relevant reviews on the current SHA. Return the precise external blocker
|
|
35
|
+
when terminal evidence cannot be obtained.
|
|
@@ -6,10 +6,3 @@ description: Use after implementation when Root needs adversarial code review an
|
|
|
6
6
|
Inspect the integrated implementation against the `Reviewer.code` contract.
|
|
7
7
|
Check callers, contracts, tests, and generated artifacts. Repair defects inside
|
|
8
8
|
the review surface and return findings, repairs, checks, and remaining risk.
|
|
9
|
-
|
|
10
|
-
Use one batched evidence sweep, reason over it, make targeted follow-ups only,
|
|
11
|
-
and batch related repairs and verification.
|
|
12
|
-
|
|
13
|
-
Lead with actionable findings and check evidence. Keep the terminal report
|
|
14
|
-
concise and structured, reuse stable facts, and inspect large artifacts only
|
|
15
|
-
when a material decision, conflict, failure, or finding requires it.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: codebase-onboarding
|
|
3
|
+
description: Use when explaining a repository or orienting a new contributor to how it works.
|
|
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.
|
|
@@ -3,18 +3,8 @@ name: commit
|
|
|
3
3
|
description: Use when Root creates a local commit after scope and proof are settled.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
|
|
7
|
-
the
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
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
|
|
3
|
+
short_description: "Create coherent local commits with exact scope proof."
|
|
4
4
|
default_prompt: "Open the commit workflow for this invocation."
|
|
5
5
|
policy:
|
|
6
6
|
allow_implicit_invocation: false
|
|
@@ -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
|
-
|
|
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.
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: continue-work
|
|
3
|
+
description: Use when the user asks Root to continue, resume, or keep going with existing HolyCodex work.
|
|
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.
|
|
@@ -1,8 +1,11 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: debugging
|
|
3
|
-
description: Use
|
|
3
|
+
description: Use to diagnose and repair an observable defect or unexplained behavior.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
Reproduce the
|
|
7
|
-
|
|
8
|
-
|
|
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: "
|
|
3
|
+
short_description: "Diagnose an observable defect through reproduction or strong evidence."
|
|
4
4
|
default_prompt: "Open the debugging workflow for this invocation."
|
|
5
5
|
policy:
|
|
6
6
|
allow_implicit_invocation: false
|
|
@@ -6,6 +6,4 @@ description: Use when a caller needs a redacted projection of current Intent sta
|
|
|
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.
|
|
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.
|
|
@@ -3,6 +3,5 @@ name: programming
|
|
|
3
3
|
description: Use when Root has decided a bounded implementation seam with known acceptance behavior.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
Implement only the decided seam
|
|
7
|
-
|
|
8
|
-
when the acceptance behavior requires it.
|
|
6
|
+
Implement only the decided seam and prove its acceptance behavior at the least
|
|
7
|
+
brittle observable boundary.
|
|
@@ -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,17 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: web-visualize
|
|
3
|
+
description: Use when the user requests an interactive visualization or approves a proposed one.
|
|
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. When the user explicitly requests
|
|
9
|
+
a visualization, create it without asking again. If you believe one would
|
|
10
|
+
materially improve a task but the user did not request it, ask Root to obtain
|
|
11
|
+
approval before creating it.
|
|
12
|
+
|
|
13
|
+
Return the visualization and enough context to verify that it answers the
|
|
14
|
+
request. If the requested result cannot be completed with an authorized,
|
|
15
|
+
available capability, return the specific blocker to Root. Publication,
|
|
16
|
+
sharing, and other consequential external effects require their usual
|
|
17
|
+
authorization.
|
|
@@ -1,15 +1,14 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: writing-instructions
|
|
3
|
-
description: Use when authoring or reviewing model-facing instructions
|
|
3
|
+
description: Use when authoring or reviewing model-facing instructions.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Writing instructions
|
|
7
7
|
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
accounting for demonstrated model-specific capability or prompting differences.
|
|
8
|
+
Use this skill for model-facing instructions, including Root/session policy,
|
|
9
|
+
specialist and Role.task contracts, skills, and conditional workflows. Keep
|
|
10
|
+
shared behavior under one owner across model routes; account for model-specific
|
|
11
|
+
differences only when supported by evidence.
|
|
13
12
|
|
|
14
13
|
Before writing, identify the receiver's effective context: higher-priority and
|
|
15
14
|
user instructions, repository instructions, Role/task policy, relevant skills,
|
|
@@ -37,9 +36,8 @@ policy, and unnecessary questionnaires. Preserve meaningful repository checks
|
|
|
37
36
|
and review gates through their canonical owners instead of reproducing them in
|
|
38
37
|
every skill. Use configuration for verbosity rather than generic style padding.
|
|
39
38
|
|
|
40
|
-
When
|
|
41
|
-
|
|
42
|
-
that reference.
|
|
39
|
+
When changing a skill's invocation boundary or conditional branches, follow
|
|
40
|
+
[Skill mechanics](SKILL-MECHANICS.md).
|
|
43
41
|
|
|
44
42
|
An instruction change is complete when the receiver can act within its authority,
|
|
45
43
|
recognize completion and escalation boundaries, and return sufficient evidence;
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
interface:
|
|
2
2
|
display_name: "Writing instructions"
|
|
3
|
-
short_description: "Author and review
|
|
3
|
+
short_description: "Author and review model-facing instructions."
|
|
4
4
|
default_prompt: "Use writing-instructions for this instruction change."
|
|
5
5
|
policy:
|
|
6
6
|
allow_implicit_invocation: true
|