feat(skills): give Moxn and Temporal each a skill their own people can PR #999

Merged
coilysiren merged 1 commit from task/moxn-and-temporal-skills into main 2026-08-19 00:48:07 +00:00
Member

Kai's reason, and it is a better one than prompt weight: a skill each of those
people can open a pull request against to add their own info.

Both were sections inside sirens-dowel/references/, which is a poor home for a
description of somebody else's product. It is not discoverable by the people who
could keep it right, and an outside description of a moving product is the
arrangement most likely to go quietly stale. Both repositories are public, so the
invitation in each file is real rather than a gesture.

The seam is ownership, not weight

I originally split these the wrong way, by what could be deferred. That was
wrong, and reading them showed why: they are standing instructions almost end to
end, and the two sections that look like subject matter are the guards.

Ownership cuts cleanly where deferral did not:

theirs to correct ours to keep honest
what Moxn is, the name collision, moxn.dev the owl-glass workspace, the glass filesystem, four read tools, the expiring credential
durable execution, docs.temporal.io that Temporal observes our turn and never runs it, metadata-only mirror, whose room the stream is

Neither new file names a workspace, a credential, a tool grant, or what this
service does with the product. None of that is theirs to correct and all of it is
ours to keep honest, so it stays in sirens-dowel.

Inert on purpose

Nothing loads these yet and no running prompt changes. A root reaches an
agent only when a definition's local_skill_roots names it, and that lives in
deploy's ConfigMap. sirens-dowel keeps its existing references untouched, so
its behaviour is byte-identical.

That sequencing is deliberate. coilyco-bridge/deploy#666 named a root the image
did not carry and crashlooped the lane for ninety minutes today. The image
ships a root before a definition may name it, never the other way.

Follow-up, after the stream

  1. Deploy names .agents/skills/moxn and .agents/skills/temporal in the dowel
    definition's local_skill_roots, on an image that already carries them.
  2. The duplicated halves come out of sirens-dowel/references/.

Until then the duplication is intentional and costs nothing, because only the
sirens-dowel copies are loaded.

On the inline question

Both new files are entrypoints, and an entrypoint is always inline. That is the
right answer here anyway: the material that survived the ownership split is the
part that stops Dowel naming the wrong Moxn or describing its own Temporal
integration backwards, and neither can sit behind a fetch the model chooses to
make.

So this buys contribution surface rather than prompt weight, and #993's weight
question is unaffected either way.

Verification

go test ./... and pre-commit pass. Nothing else in the tree changed.

Refs #993, #968, coilyco-bridge/deploy#666

Kai's reason, and it is a better one than prompt weight: **a skill each of those people can open a pull request against to add their own info.** Both were sections inside `sirens-dowel/references/`, which is a poor home for a description of somebody else's product. It is not discoverable by the people who could keep it right, and an outside description of a moving product is the arrangement most likely to go quietly stale. Both repositories are public, so the invitation in each file is real rather than a gesture. ## The seam is ownership, not weight I originally split these the wrong way, by what could be deferred. That was wrong, and reading them showed why: they are standing instructions almost end to end, and the two sections that look like subject matter are the guards. Ownership cuts cleanly where deferral did not: | theirs to correct | ours to keep honest | |---|---| | what Moxn is, the name collision, moxn.dev | the `owl-glass` workspace, the `glass` filesystem, four read tools, the expiring credential | | durable execution, docs.temporal.io | that Temporal **observes** our turn and never runs it, metadata-only mirror, whose room the stream is | Neither new file names a workspace, a credential, a tool grant, or what this service does with the product. None of that is theirs to correct and all of it is ours to keep honest, so it stays in `sirens-dowel`. ## Inert on purpose **Nothing loads these yet and no running prompt changes.** A root reaches an agent only when a definition's `local_skill_roots` names it, and that lives in deploy's ConfigMap. `sirens-dowel` keeps its existing references untouched, so its behaviour is byte-identical. That sequencing is deliberate. coilyco-bridge/deploy#666 named a root the image did not carry and **crashlooped the lane for ninety minutes today**. The image ships a root before a definition may name it, never the other way. ## Follow-up, after the stream 1. Deploy names `.agents/skills/moxn` and `.agents/skills/temporal` in the dowel definition's `local_skill_roots`, on an image that already carries them. 2. The duplicated halves come out of `sirens-dowel/references/`. Until then the duplication is intentional and costs nothing, because only the `sirens-dowel` copies are loaded. ## On the inline question Both new files are entrypoints, and an entrypoint is always inline. That is the right answer here anyway: the material that survived the ownership split is the part that stops Dowel naming the wrong Moxn or describing its own Temporal integration backwards, and neither can sit behind a fetch the model chooses to make. So this buys contribution surface rather than prompt weight, and #993's weight question is unaffected either way. ## Verification `go test ./...` and `pre-commit` pass. Nothing else in the tree changed. Refs #993, #968, coilyco-bridge/deploy#666
feat(skills): give Moxn and Temporal each a skill their own people can PR
All checks were successful
ci / image-build (pull_request) Successful in 32s
ci / test (pull_request) Successful in 59s
ci / publish-echo-image (pull_request) Has been skipped
ci / publish-observed (pull_request) Has been skipped
b3944c1d0a
Both were sections inside sirens-dowel's references, which is a poor home for a
description of somebody else's product: it is not discoverable by the people who
could keep it right, and an outside description of a moving product is the
arrangement most likely to go quietly stale.

Each is now its own skill, and each says plainly that its subject's people are
invited to correct it by pull request. Both repositories are public, so that is
a real invitation rather than a gesture.

THE SEAM IS OWNERSHIP, NOT WEIGHT. What Moxn's people can speak to is what Moxn
is, how to name it against a bad collision, and where to read it. What Temporal's
people can speak to is durable execution and where the current documentation
lives. Neither file names a workspace, a credential, a tool grant, or what this
service does with the product, because none of that is theirs to correct and all
of it is ours to keep honest.

INERT ON PURPOSE. Nothing loads these yet. A root reaches an agent only when a
definition's local_skill_roots names it, and that is deploy's ConfigMap, so this
changes no running prompt. sirens-dowel keeps its existing references untouched
and its behaviour is byte-identical.

That sequencing is deliberate rather than incidental. deploy#666 named a root the
image did not carry and crashlooped the lane for ninety minutes today, so the
image ships a root before a definition may name it, never the other way. Removing
the duplicated halves from sirens-dowel and naming these two in local_skill_roots
is the follow-up, and it belongs after the 2026-08-19 stream.

Refs #993, #968, coilyco-bridge/deploy#666

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Author
Member

Kai asked whether these can ever trigger. Two answers, and the second one matters more than this PR.

These two, specifically: correct, they cannot, because nothing loads them. A root reaches an agent only when local_skill_roots names it. That is the deliberate sequencing described above and it resolves when deploy names them.

Nothing in this harness triggers, ever. stripFrontmatter discards name and description, and loadSkills inlines every entrypoint body unconditionally. There is no index, no matching, and no activation step. #971 is open on exactly that and calls it the skill contract backwards.

So the "Triggers - ..." tails I put in both descriptions did nothing, and no other skill in this repository uses that phrasing either. It was an agentic-os catalogue convention imported into a harness that has no equivalent. Fixed in 760d28b: the descriptions now say what each skill is for, in the shape coilyco-org and sirens-dowel already use. The field stays because it is correct metadata and #971 aims to make it load-bearing.

The consequence for this PR is worth stating plainly. Because every entrypoint is always inline, naming these two in local_skill_roots adds roughly 3.8KB per turn, and only step 2 of the follow-up takes the duplicated halves back out of sirens-dowel. So the sequence is not two optional steps in a preferred order. Stopping after step 1 leaves the lane strictly heavier than it is today, for no benefit the agent can see.

Either both land or neither does. I would rather that be written here than discovered from a prompt-size graph later.

Kai asked whether these can ever trigger. Two answers, and the second one matters more than this PR. **These two, specifically:** correct, they cannot, because nothing loads them. A root reaches an agent only when `local_skill_roots` names it. That is the deliberate sequencing described above and it resolves when deploy names them. **Nothing in this harness triggers, ever.** `stripFrontmatter` discards `name` and `description`, and `loadSkills` inlines every entrypoint body unconditionally. There is no index, no matching, and no activation step. #971 is open on exactly that and calls it the skill contract backwards. So the "Triggers - ..." tails I put in both descriptions did nothing, and no other skill in this repository uses that phrasing either. It was an agentic-os catalogue convention imported into a harness that has no equivalent. Fixed in `760d28b`: the descriptions now say what each skill is for, in the shape `coilyco-org` and `sirens-dowel` already use. The field stays because it is correct metadata and #971 aims to make it load-bearing. **The consequence for this PR is worth stating plainly.** Because every entrypoint is always inline, naming these two in `local_skill_roots` adds roughly **3.8KB per turn**, and only step 2 of the follow-up takes the duplicated halves back out of `sirens-dowel`. So the sequence is not two optional steps in a preferred order. Stopping after step 1 leaves the lane strictly heavier than it is today, for no benefit the agent can see. Either both land or neither does. I would rather that be written here than discovered from a prompt-size graph later.
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/sirens-echo!999
No description provided.