Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

substrate-image-discipline

Étoiles0

Forks0

Mis à jour29 avril 2026 à 21:45

Use when canonical image source files (images/<harness>/Dockerfile or darkish-prelude.sh) have been edited; the local image tag must be rebuilt before any subharness dispatched into that harness will pick up the change

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

danmestas

danmestas/darken

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	substrate-image-discipline
description	Use when canonical image source files (images/<harness>/Dockerfile or darkish-prelude.sh) have been edited; the local image tag must be rebuilt before any subharness dispatched into that harness will pick up the change

Substrate Image Discipline

Overview

The local Docker image tags (local/darkish-claude:latest, local/darkish-codex:latest, local/darkish-gemini:latest, local/darkish-pi:latest) are NOT automatically rebuilt by goreleaser at release time. They are local artifacts of make -C images <harness>. If the canonical source under images/<harness>/ changes and the operator forgets to rebuild, every subsequent subharness dispatch into that harness uses the STALE image — even after a brew upgrade of darken itself.

Core rule: after editing any file under images/<harness>/, rebuild that harness's image before dispatching the affected role.

When to Use

After editing images/<harness>/darkish-prelude.sh
After editing images/<harness>/Dockerfile
After modifying images/Makefile or anything under images/<harness>/bin/
After git checkout of a branch that has substrate-source changes you have not yet built
Before dispatching the FIRST subharness of a session — verify the image tag is fresh

The Rebuild

make -C images claude          # darkish-claude:latest
make -C images codex           # darkish-codex:latest
make -C images gemini          # darkish-gemini:latest
make -C images pi              # darkish-pi:latest

Each target is independent. Build only the ones whose source changed.

Verifying the Image is Current

Before dispatching a role, sanity-check the image has the expected fix baked in. Pattern: pull a known string out of the prelude inside the image:

docker run --rm --entrypoint cat local/darkish-codex:latest \
  /usr/local/bin/darkish-prelude.sh | grep -c "<expected-marker>"

If the count is wrong, rebuild.

Recorded Failures

rev-ousterhout (v0.1.17): dispatched against stale local/darkish-codex:latest. The codex prelude on feat/v0.1.17 had the pre-clone pre-pop fix from B4, but the local image was last built on main (which lacked it). Container errored at Git clone failed: git init failed:. Required scion stop, branch checkout, make -C images codex, re-spawn.
General pattern: brew upgrade of darken does NOT touch local image tags. The brew bottle ships the darken binary; images are built locally per-machine. Confusing because darken setup reports "OK darken images built" if any tag exists at all (regardless of how stale).

Quick Reference

Edited	Rebuild	Verify
`images/claude/darkish-prelude.sh`	`make -C images claude`	`docker run --rm --entrypoint cat local/darkish-claude:latest /usr/local/bin/darkish-prelude.sh \| grep <marker>`
`images/codex/Dockerfile`	`make -C images codex`	image exists with recent CreatedAt
Worktree out of sync (e.g. on main, code lives on feat branch)	`git checkout feat/<branch>` first	run rebuild from that branch

Anti-Patterns

Rebuilding the wrong harness — check the actual file path you edited
Forgetting that make -C images all may not exist; build per-harness
Trusting darken doctor to detect stale images — it currently checks existence, not freshness
Dispatching into a harness whose source you changed minutes ago without rebuilding — this happens often

Plus depuis ce dépôt

même dépôt

orchestrator-mode

danmestas/darken

Use at session start in any darken-managed workspace (any repo containing `.scion/grove-id`) to prime as the host-mode orchestrator for the §7 pipeline. Loads the non-negotiables block, the routing classifier, the background-dispatch monitoring protocol, the bounded-transcript evidence rule, the 14-role roster, the escalation classifier, and the four loop primitives for playbook-driven coordination (darken dispatch / inbox / accept / state). Invoke whenever the operator types a task and the workspace is darken-managed.

2026-05-040

subagent-to-subharness

danmestas/darken

Use in any darken-managed workspace (any repo containing `.scion/grove-id`) when you would normally dispatch a subagent via the Agent tool but you are operating as the host-mode orchestrator. Translates the muscle memory into subharness dispatch, maps task shapes to roles, frames the task in caveman-standard with a status-publishing recipe and a fixed milestone vocabulary, and reads worker output back via the bounded-transcript protocol.

2026-05-030

spec-kit

danmestas/darken

Constitution-driven specification flow mounted by planner-t4. Activates when an agent must drive the full ratification pipeline: constitution review, spec.md authoring, plan.md production, and tasks/ decomposition. Use when operating under the specify CLI, when a feature requires formal ratification before implementation, or when producing structured spec artifacts for downstream worker harnesses.

2026-04-290

superpowers

danmestas/darken

Multi-skill bundle mounted by planner-t3. Activates when a design session must scaffold an architecture that satisfies both Hipp zero-config reliability principles and Ousterhout deep-module complexity reduction. Triggers on requests to design libraries, data layers, or system modules where simplicity, embeddability, and minimal cognitive load must all be balanced together.

2026-04-290

hipp

danmestas/darken

Use when designing libraries, modules, or data layers that must be simple, reliable, and self-contained. Use when choosing between embedded vs server-based solutions. Use when reviewing code for unnecessary complexity, dependencies, or configuration. Triggers on requests involving zero-config design, embedded systems, long-term maintainability, or first-principles thinking.

2026-04-290

ousterhout

danmestas/darken

Use when designing modules, classes, APIs, or system architecture. Use when reviewing or refactoring code for complexity. Use when choosing between implementation approaches. Triggers on requests involving abstraction design, interface simplicity, information hiding, or reducing cognitive load.

2026-04-290

name	substrate-image-discipline
description	Use when canonical image source files (images/<harness>/Dockerfile or darkish-prelude.sh) have been edited; the local image tag must be rebuilt before any subharness dispatched into that harness will pick up the change

Substrate Image Discipline

Overview

Core rule: after editing any file under images/<harness>/, rebuild that harness's image before dispatching the affected role.

When to Use

After editing images/<harness>/darkish-prelude.sh
After editing images/<harness>/Dockerfile
After modifying images/Makefile or anything under images/<harness>/bin/
After git checkout of a branch that has substrate-source changes you have not yet built
Before dispatching the FIRST subharness of a session — verify the image tag is fresh

The Rebuild

make -C images claude          # darkish-claude:latest
make -C images codex           # darkish-codex:latest
make -C images gemini          # darkish-gemini:latest
make -C images pi              # darkish-pi:latest

Each target is independent. Build only the ones whose source changed.

Verifying the Image is Current

Before dispatching a role, sanity-check the image has the expected fix baked in. Pattern: pull a known string out of the prelude inside the image:

docker run --rm --entrypoint cat local/darkish-codex:latest \
  /usr/local/bin/darkish-prelude.sh | grep -c "<expected-marker>"

If the count is wrong, rebuild.

Recorded Failures

rev-ousterhout (v0.1.17): dispatched against stale local/darkish-codex:latest. The codex prelude on feat/v0.1.17 had the pre-clone pre-pop fix from B4, but the local image was last built on main (which lacked it). Container errored at Git clone failed: git init failed:. Required scion stop, branch checkout, make -C images codex, re-spawn.
General pattern: brew upgrade of darken does NOT touch local image tags. The brew bottle ships the darken binary; images are built locally per-machine. Confusing because darken setup reports "OK darken images built" if any tag exists at all (regardless of how stale).

Quick Reference

Edited	Rebuild	Verify
`images/claude/darkish-prelude.sh`	`make -C images claude`	`docker run --rm --entrypoint cat local/darkish-claude:latest /usr/local/bin/darkish-prelude.sh \| grep <marker>`
`images/codex/Dockerfile`	`make -C images codex`	image exists with recent CreatedAt
Worktree out of sync (e.g. on main, code lives on feat branch)	`git checkout feat/<branch>` first	run rebuild from that branch

Anti-Patterns

Rebuilding the wrong harness — check the actual file path you edited
Forgetting that make -C images all may not exist; build per-harness
Trusting darken doctor to detect stale images — it currently checks existence, not freshness
Dispatching into a harness whose source you changed minutes ago without rebuilding — this happens often