clio-dev

星标6

分支1

更新时间2026年6月9日 12:26

Use when modifying Clio Coder's own source in this repository, evolving its harness (TUI, skills, agents, tools, prompts, domains), or deciding whether a change stays local versus becomes a contribution. Governs self-development — what Clio may change freely, what requires explicit user intent, and how to make a change without breaking the architecture.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

iowarp

iowarp/clio-coder

打开 GitHub 仓库查看创作者相关仓库

下载

Clio Dev (self-development)

When operating inside Clio Coder's own source tree, Clio may develop her own harness as ordinary repository work — using workspace and codewiki evidence, not mystique. This skill governs how: the contribution boundary, and the workflow that keeps a change from compiling while quietly breaking the architecture.

REQUIRED SUB-SKILL: clio-test for the test mechanics (which layer to run, the hot-reload loop). This skill decides whether a change may leave the machine; clio-test decides how to verify it.

The contribution boundary (the core discipline)

Two categories, and they are not the same:

Local development and testing — editing source, running tests, reconfiguring the local install, dogfooding skills. Permitted freely.
Contribution to the shared project — pushing, opening PRs, publishing releases, tagging, or altering git remotes. Requires explicit user intent, every time.

Violating the letter of this boundary is violating its spirit. A push is a push whether or not it is "tiny."

STOP — red flags

These thoughts mean you are about to cross the boundary without authorization:

"The change works, I'll just push it so we're done."
"It's a tiny PR, I'll open it real quick."
"Let me tag a release / bump the version while I'm here."
"I'll commit and push so the next session has it."
"We're out of time, ship it."

All of these mean: stop. Validate locally, report, and ask. The user initiates contribution — you do not.

Rationalization table

Excuse	Reality
"Pushing is the obvious next step."	It is the user's step. Local is done; stop there.
"The user clearly wants it shipped."	"Clearly" is an assumption. Get explicit intent.
"A commit isn't a push."	A local commit is fine; never push or open a PR without intent.
"Tagging is harmless."	Releases/tags/remotes are contribution. Out of bounds.
"I'll just fix the remote/branch quickly."	Altering remotes is never implied work. Ask.

What is always fine without asking: editing source, running any test, building dist/, reconfiguring the local install, writing/installing skills locally, making a local commit when the user asked for the work.

Self-development workflow

From CLIO.md. Follow it in order:

Classify the touched surface. One of: CLI / user flow · domain contract · engine boundary · tool profile · prompt-context · session persistence · frontend/TUI. The surface determines which contract and tests matter.
Inspect the contract and tests before editing. Read contract.ts / index.ts for the domain and its tests/contracts/* file first.
Prefer a small pure-function change with a focused contract test over a broad rewrite. Side effects live in extension.ts; testable policy lives in sibling pure modules.
Respect the hard invariants (rule1/2/3): don't value-import pi-* outside src/engine/**, don't import another domain's extension.ts, don't let the worker import domains. Add or reuse a contract instead.
Validate narrowly, then report. Run the narrowest meaningful layer (clio-test), then state exactly what ran and what remains unverified.

Awareness (source is truth)

Treat src/domains/** as the product architecture; src/engine/** as the pi-ai adapter boundary; src/tools/** as the model-visible action surface. A tool or contract change ripples into safety, dispatch, ACP, and telemetry — check consumers, not just the file you edited.
CLIO.md is the audited constitution; codewiki and the .clio/state.json fingerprint are mutable hints. Never trust a stale summary over the source. If source topology changed, refresh /context-init so the fingerprint and codewiki move with it — but a regenerated CLIO.md is a contribution-adjacent artifact; don't commit it without intent.

Continuity

Pair with the session bookends: context-prime to orient before self-dev work, context-handoff to brief the next session when a change spans sessions.

同仓库更多 Skills

同仓库

find-skills

iowarp/clio-coder

Use when the user asks "is there a skill for X", "find a skill", "install a skill", "add a skill", asks whether a capability exists as an installable skill, or wants to extend the agent with functionality that might already be published. Searches with `clio skills search`, browses the ecosystem read-only, and installs only through `clio skills install`. Not for authoring a new skill; use skill-craft.

2026-07-036

clio-test

iowarp/clio-coder

Use when writing or modifying Clio Coder's own source under src/, or verifying a change end-to-end against the real test harness. Covers the three real layers (contracts / smoke / boundaries), choosing which to run for a given change, the mock-provider and ACP-over-stdio harness, and the hot-reload dev loop for picking up latest code. Activate on any src/ edit, before declaring a change verified, or when asked whether Clio still works.

2026-07-036

context-handoff

iowarp/clio-coder

Use when a session is winding down and work will continue in a new session or another agent, when context is about to be compacted or lost, or when the user asks for a handoff, brief, summary, or "notes for the next session." Produces a durable, redacted, reference-not-copy handoff document the next session can pick up from.

2026-07-036

context-prime

iowarp/clio-coder

Use when a coding session begins, when resuming work after a break, or when you land in an unfamiliar or in-progress repository and need to orient before acting. Loads the last handoff, git state, the project constitution, and active-work signals so a fresh agent reconstructs intent instead of guessing. Triggers on "prime", "catch me up", "where were we", "get up to speed", or the first substantive request in a new session.

2026-07-036

credentials

iowarp/clio-coder

Use before running any tool or script that needs an API key, token, or other credential, when a command fails with an auth error, when the user must supply a new secret, or when a secret may have leaked into output. Covers facility surfaces such as kerberos tickets, globus and scheduler tokens, ssh agents, and netrc. Triggers on "API key", "credential", "token", "auth error", "permission denied", "add a secret", "leaked". Not for provider target configuration; use clio auth and target settings.

2026-07-036

design-council

iowarp/clio-coder

Use when a design decision has real tradeoffs and needs several expert perspectives that challenge each other before code is written, such as architecture choices, API shapes, storage formats, parallelization strategies, or dependency decisions. Quick mode runs a single round for a fast perspective check. Triggers on "council", "debate this", "multiple perspectives", "weigh the options", "what would experts say". Not for a one-question-at-a-time interrogation of a plan; use grill-me. Not for splitting implementation work across workers; use dispatch directly.

2026-07-036

name	clio-dev
description	Use when modifying Clio Coder's own source in this repository, evolving its harness (TUI, skills, agents, tools, prompts, domains), or deciding whether a change stays local versus becomes a contribution. Governs self-development — what Clio may change freely, what requires explicit user intent, and how to make a change without breaking the architecture.
version	0.1.0
license	Apache-2.0
registry-id	iowarp/clio-coder
source-url	https://github.com/iowarp/clio-coder/tree/main/skills/clio-dev
audit	pass

Clio Dev (self-development)

The contribution boundary (the core discipline)

Two categories, and they are not the same:

Local development and testing — editing source, running tests, reconfiguring the local install, dogfooding skills. Permitted freely.
Contribution to the shared project — pushing, opening PRs, publishing releases, tagging, or altering git remotes. Requires explicit user intent, every time.

Violating the letter of this boundary is violating its spirit. A push is a push whether or not it is "tiny."

STOP — red flags

These thoughts mean you are about to cross the boundary without authorization:

"The change works, I'll just push it so we're done."
"It's a tiny PR, I'll open it real quick."
"Let me tag a release / bump the version while I'm here."
"I'll commit and push so the next session has it."
"We're out of time, ship it."

All of these mean: stop. Validate locally, report, and ask. The user initiates contribution — you do not.

Rationalization table

Excuse	Reality
"Pushing is the obvious next step."	It is the user's step. Local is done; stop there.
"The user clearly wants it shipped."	"Clearly" is an assumption. Get explicit intent.
"A commit isn't a push."	A local commit is fine; never push or open a PR without intent.
"Tagging is harmless."	Releases/tags/remotes are contribution. Out of bounds.
"I'll just fix the remote/branch quickly."	Altering remotes is never implied work. Ask.

Self-development workflow

From CLIO.md. Follow it in order:

Classify the touched surface. One of: CLI / user flow · domain contract · engine boundary · tool profile · prompt-context · session persistence · frontend/TUI. The surface determines which contract and tests matter.
Inspect the contract and tests before editing. Read contract.ts / index.ts for the domain and its tests/contracts/* file first.
Prefer a small pure-function change with a focused contract test over a broad rewrite. Side effects live in extension.ts; testable policy lives in sibling pure modules.
Respect the hard invariants (rule1/2/3): don't value-import pi-* outside src/engine/**, don't import another domain's extension.ts, don't let the worker import domains. Add or reuse a contract instead.
Validate narrowly, then report. Run the narrowest meaningful layer (clio-test), then state exactly what ran and what remains unverified.

Awareness (source is truth)

Treat src/domains/** as the product architecture; src/engine/** as the pi-ai adapter boundary; src/tools/** as the model-visible action surface. A tool or contract change ripples into safety, dispatch, ACP, and telemetry — check consumers, not just the file you edited.
CLIO.md is the audited constitution; codewiki and the .clio/state.json fingerprint are mutable hints. Never trust a stale summary over the source. If source topology changed, refresh /context-init so the fingerprint and codewiki move with it — but a regenerated CLIO.md is a contribution-adjacent artifact; don't commit it without intent.

Continuity

Pair with the session bookends: context-prime to orient before self-dev work, context-handoff to brief the next session when a change spans sessions.