feat(skills): give Moxn and Temporal each a skill their own people can PR #999
No reviewers
Labels
No labels
move-to-repo
coilyco-bridge-deploy
move-to-repo
coilyco-flight-deck-agent-compose
move-to-repo
coilyco-gaming-eco-app
move-to-repo
coilysiren-inbox
move-to-repo
unknown
🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
c#
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
role/ai
role/creator
role/design
role/director
role/engineer
role/exec
role/human
role/ops
role/qa
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
coilyco-gaming/sirens-echo!999
Loading…
Reference in a new issue
No description provided.
Delete branch "task/moxn-and-temporal-skills"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 adescription 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:
owl-glassworkspace, theglassfilesystem, four read tools, the expiring credentialNeither 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_rootsnames it, and that lives indeploy's ConfigMap.
sirens-dowelkeeps its existing references untouched, soits 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
.agents/skills/moxnand.agents/skills/temporalin the doweldefinition's
local_skill_roots, on an image that already carries them.sirens-dowel/references/.Until then the duplication is intentional and costs nothing, because only the
sirens-dowelcopies 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 ./...andpre-commitpass. Nothing else in the tree changed.Refs #993, #968, coilyco-bridge/deploy#666
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_rootsnames it. That is the deliberate sequencing described above and it resolves when deploy names them.Nothing in this harness triggers, ever.
stripFrontmatterdiscardsnameanddescription, andloadSkillsinlines 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 shapecoilyco-organdsirens-dowelalready 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_rootsadds roughly 3.8KB per turn, and only step 2 of the follow-up takes the duplicated halves back out ofsirens-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.