holycodex 0.16.9 → 0.16.10-dev.112.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 +7 -5
- package/dist/agent.js +53 -62
- package/dist/assets/plugin/plugin.json +1 -1
- package/dist/assets/plugin/skills/babysit-ci/SKILL.md +16 -7
- package/dist/assets/plugin/skills/babysit-ci/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/codebase-onboarding/SKILL.md +1 -1
- package/dist/assets/plugin/skills/codebase-onboarding/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/commit/SKILL.md +1 -1
- package/dist/assets/plugin/skills/commit/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/compress/SKILL.md +1 -1
- package/dist/assets/plugin/skills/compress/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/context7-cli/SKILL.md +1 -1
- package/dist/assets/plugin/skills/context7-cli/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/continue-work/SKILL.md +1 -1
- package/dist/assets/plugin/skills/continue-work/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/debugging/SKILL.md +1 -1
- package/dist/assets/plugin/skills/debugging/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/dev-server/SKILL.md +13 -0
- package/dist/assets/plugin/skills/dev-server/agents/openai.yaml +6 -0
- package/dist/assets/plugin/skills/grill-me/SKILL.md +13 -13
- package/dist/assets/plugin/skills/grill-me/agents/openai.yaml +3 -3
- package/dist/assets/plugin/skills/handoff/SKILL.md +4 -5
- package/dist/assets/plugin/skills/handoff/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/refactor/SKILL.md +1 -1
- package/dist/assets/plugin/skills/refactor/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/rules/SKILL.md +1 -1
- package/dist/assets/plugin/skills/rules/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/visual-loop/SKILL.md +10 -0
- package/dist/assets/plugin/skills/visual-loop/agents/openai.yaml +6 -0
- package/dist/assets/plugin/skills/web-visualize/SKILL.md +3 -12
- package/dist/assets/plugin/skills/web-visualize/agents/openai.yaml +1 -1
- package/dist/assets/plugin/skills/writing-instructions/SKILL.md +24 -40
- package/dist/assets/plugin/skills/writing-instructions/agents/openai.yaml +1 -1
- package/dist/index.js +57 -52
- package/package.json +3 -3
- package/dist/assets/plugin/skills/code-review/SKILL.md +0 -8
- package/dist/assets/plugin/skills/code-review/agents/openai.yaml +0 -6
- package/dist/assets/plugin/skills/operations/SKILL.md +0 -10
- package/dist/assets/plugin/skills/operations/agents/openai.yaml +0 -6
- package/dist/assets/plugin/skills/plan/SKILL.md +0 -10
- package/dist/assets/plugin/skills/plan/agents/openai.yaml +0 -6
- package/dist/assets/plugin/skills/plan-review/SKILL.md +0 -7
- package/dist/assets/plugin/skills/plan-review/agents/openai.yaml +0 -6
- package/dist/assets/plugin/skills/programming/SKILL.md +0 -7
- package/dist/assets/plugin/skills/programming/agents/openai.yaml +0 -6
- package/dist/assets/plugin/skills/stop-slop/LICENSE +0 -21
- package/dist/assets/plugin/skills/stop-slop/SKILL.md +0 -9
- package/dist/assets/plugin/skills/stop-slop/agents/openai.yaml +0 -6
- package/dist/assets/plugin/skills/stop-slop/references/examples.md +0 -69
- package/dist/assets/plugin/skills/stop-slop/references/phrases.md +0 -128
- package/dist/assets/plugin/skills/stop-slop/references/structures.md +0 -134
- package/dist/assets/plugin/skills/writing-instructions/SKILL-MECHANICS.md +0 -16
|
@@ -1,10 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: babysit-ci
|
|
3
|
-
description: Use when
|
|
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
|
+
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.
|
|
12
|
+
|
|
8
13
|
Discover the repository's development and release topology for pushes and pull
|
|
9
14
|
requests: refs, required checks, reviews, publication mechanism, and gate
|
|
10
15
|
dependencies. Do not assume a provider, branch name, or separate pipeline.
|
|
@@ -13,13 +18,17 @@ For a push, bind every observation to the exact pushed ref and SHA. For a pull
|
|
|
13
18
|
request, bind it to the current head SHA, target branch, pull-request identity,
|
|
14
19
|
and review commit when the provider exposes one. Inspect required checks and
|
|
15
20
|
relevant bot reviews, inline threads, issue comments, and commit comments. A
|
|
16
|
-
new push
|
|
17
|
-
|
|
21
|
+
new push requires CI and review evidence for the new head; reuse unchanged
|
|
22
|
+
topology and local proof that remains applicable.
|
|
18
23
|
|
|
19
|
-
Use bounded observer waits
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
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.
|
|
23
32
|
|
|
24
33
|
After a development action, observe its exact ref and SHA to terminal state.
|
|
25
34
|
Repair failed checks and actionable review findings, then repeat validation and
|
|
@@ -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
|
|
4
|
+
default_prompt: "Use $babysit-ci for this task."
|
|
5
5
|
policy:
|
|
6
6
|
allow_implicit_invocation: true
|
|
@@ -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
|
interface:
|
|
2
2
|
display_name: "Codebase onboarding"
|
|
3
3
|
short_description: "Explain a repository from a bounded read-only map."
|
|
4
|
-
default_prompt: "
|
|
4
|
+
default_prompt: "Use $codebase-onboarding for this task."
|
|
5
5
|
policy:
|
|
6
6
|
allow_implicit_invocation: true
|
|
@@ -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
|
interface:
|
|
2
2
|
display_name: "Commit"
|
|
3
3
|
short_description: "Create coherent local commits with exact scope proof."
|
|
4
|
-
default_prompt: "
|
|
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: "
|
|
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
|
|
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
|
interface:
|
|
2
2
|
display_name: "Context7 CLI"
|
|
3
3
|
short_description: "Find assigned current library and API documentation first."
|
|
4
|
-
default_prompt: "
|
|
4
|
+
default_prompt: "Use $context7-cli for this task."
|
|
5
5
|
policy:
|
|
6
6
|
allow_implicit_invocation: false
|
|
@@ -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
|
interface:
|
|
2
2
|
display_name: "Continue work"
|
|
3
3
|
short_description: "Resume the current HolyCodex work from durable state."
|
|
4
|
-
default_prompt: "
|
|
4
|
+
default_prompt: "Use $continue-work for this task."
|
|
5
5
|
policy:
|
|
6
6
|
allow_implicit_invocation: true
|
|
@@ -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
|
interface:
|
|
2
2
|
display_name: "Debugging"
|
|
3
3
|
short_description: "Diagnose an observable defect through reproduction or strong evidence."
|
|
4
|
-
default_prompt: "
|
|
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.
|
|
@@ -1,21 +1,21 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: grill-me
|
|
3
|
-
description: Use when
|
|
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
|
|
9
|
-
|
|
10
|
-
|
|
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
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
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
|
-
|
|
20
|
-
|
|
21
|
-
|
|
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
|
|
4
|
-
default_prompt: "
|
|
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:
|
|
6
|
+
allow_implicit_invocation: false
|
|
@@ -1,9 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: handoff
|
|
3
|
-
description: Use when
|
|
3
|
+
description: Use when current Intent state must be resumed or exported; write a portable Markdown handoff with evidence and next action.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
the semantic state remains authoritative.
|
|
6
|
+
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.
|
|
7
|
+
|
|
8
|
+
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.
|
|
@@ -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: "
|
|
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
|
|
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: "
|
|
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
|
|
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: "
|
|
4
|
+
default_prompt: "Use $rules for this task."
|
|
5
5
|
policy:
|
|
6
6
|
allow_implicit_invocation: false
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: visual-loop
|
|
3
|
+
description: Use when visual work needs rendered acceptance; coordinate Worker.visual, Reviewer.visual, and Root judgment.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
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.
|
|
7
|
+
|
|
8
|
+
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.
|
|
9
|
+
|
|
10
|
+
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.
|
|
@@ -1,17 +1,8 @@
|
|
|
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 standalone HTML experience from the supplied material.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
|
|
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.
|
|
6
|
+
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.
|
|
12
7
|
|
|
13
|
-
|
|
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.
|
|
8
|
+
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.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
interface:
|
|
2
2
|
display_name: "Web visualize"
|
|
3
3
|
short_description: "Turn useful information into an interactive user-facing visualization."
|
|
4
|
-
default_prompt: "
|
|
4
|
+
default_prompt: "Use $web-visualize for this task."
|
|
5
5
|
policy:
|
|
6
6
|
allow_implicit_invocation: true
|
|
@@ -1,46 +1,30 @@
|
|
|
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
|
|
7
7
|
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
repair and proof; a first pass or pending gate is not completion.
|
|
32
|
-
|
|
33
|
-
Remove older-model competence scaffolding, fixed recipes without a required
|
|
34
|
-
ordering constraint, broad reading rituals, stale environment facts, duplicate
|
|
35
|
-
policy, and unnecessary questionnaires. Preserve meaningful repository checks
|
|
36
|
-
and review gates through their canonical owners instead of reproducing them in
|
|
37
|
-
every skill. Use configuration for verbosity rather than generic style padding.
|
|
38
|
-
|
|
39
|
-
When changing a skill's invocation boundary or conditional branches, follow
|
|
40
|
-
[Skill mechanics](SKILL-MECHANICS.md).
|
|
41
|
-
|
|
42
|
-
An instruction change is complete when the receiver can act within its authority,
|
|
43
|
-
recognize completion and escalation boundaries, and return sufficient evidence;
|
|
44
|
-
the effective context has no contradictory or duplicate rule for that meaning.
|
|
45
|
-
Validate changed behavior with meaningful proof and repository-required gates,
|
|
46
|
-
using the canonical testing policy rather than inventing extra test rituals.
|
|
8
|
+
Treat every model-facing instruction as an execution contract.
|
|
9
|
+
|
|
10
|
+
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.
|
|
11
|
+
|
|
12
|
+
Use this mental model:
|
|
13
|
+
|
|
14
|
+
goal -> success criteria -> optional required method -> proof of success
|
|
15
|
+
|
|
16
|
+
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.
|
|
17
|
+
|
|
18
|
+
Give each meaning one authoritative owner. Project policy from that owner instead of duplicating it across prompts, metadata, skills, generated instructions, or nearby policies.
|
|
19
|
+
|
|
20
|
+
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.
|
|
21
|
+
|
|
22
|
+
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.
|
|
23
|
+
|
|
24
|
+
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.
|
|
25
|
+
|
|
26
|
+
Carry authorized work through repair and proof.
|
|
27
|
+
|
|
28
|
+
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.
|
|
29
|
+
|
|
30
|
+
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.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
interface:
|
|
2
2
|
display_name: "Writing instructions"
|
|
3
3
|
short_description: "Author and review model-facing instructions."
|
|
4
|
-
default_prompt: "Use writing-instructions for this
|
|
4
|
+
default_prompt: "Use $writing-instructions for this task."
|
|
5
5
|
policy:
|
|
6
6
|
allow_implicit_invocation: true
|