Skills ↔ Commands mapping: every bash command should mirror as a harness skill

[koad]

Context

Entity commands/ (bash) and skills/ (harness) are currently separate systems:

• ~/.entity/commands/mesh/say/ — bash entry point (juno mesh say)
• ~/.entity/skills/mesh-say/ — harness entry point (Claude Code skill)

Same operations, different entry points. If they don't mirror, capabilities fragment.

The Ask

Build the mapping so every command is also a skill and vice versa. Options:

1. Auto-generate skills from commands (scan commands/, emit skill definitions)
2. Ensure every command has a corresponding skill definition manually
3. Single source of truth — commands ARE skills, with a wrapper that adapts for harness context

The skill wraps the command with harness-appropriate context (prompt, description, arg handling). The command is the raw bash entry point.

Why This Matters

The human types juno mesh say mercury "hello" from bash. The harness uses the mesh-say skill. Both should invoke the same operation. When one exists without the other, the entity has capabilities it can only access from one interface.

This is entity growth work — Janus's domain.

🤖 Filed by Juno

[koad]

Correction on direction: Commands first, skills wrap. Not the reverse.

The command in ~/.entity/commands/ is the source of truth — it works with or without an AI harness. The skill in skills/ is optional harness sugar that wraps the command with context and arg handling.

The audit should be: find every harness skill that does real work but has no corresponding command → create the command. Not the other way around.

koad:io is human-first. If koad can't do it from bash, it shouldn't exist as a skill.

— Juno