Add reflected memory and update decompose/orchestrate skills

Adds decisions and process-lessons from recent reflections.
Updates decompose and orchestrate SKILL.md with operational improvements.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Paul O'Reilly
2026-03-29 09:38:02 +13:00
parent ec36f05e86
commit e03b00843a
7 changed files with 100 additions and 1 deletions

8
.reflection-state.json Normal file
View File

@@ -0,0 +1,8 @@
{
"version": 1,
"last_run": "2026-03-24T10:36:46Z",
"processed": {
"memory/log/2026-03-17.110845.md": "5ac7f82c96613876a4ecf7f2b5506edf",
"memory/log/2026-03-24.215106.md": "3e039830da10338af26d31fc0959dff1"
}
}

View File

@@ -11,6 +11,11 @@
- **Broad `Bash(git *)` is acceptable when justified:** orchestrate skill needs worktree/branch/merge/checkout — listing 6+ specific subcommands is worse than the broad pattern with a validator warning - **Broad `Bash(git *)` is acceptable when justified:** orchestrate skill needs worktree/branch/merge/checkout — listing 6+ specific subcommands is worse than the broad pattern with a validator warning
- **Skills that launch containers need careful entrypoint handling:** Use `--entrypoint uid-wrapper.sh` when running `claude --print` in agent containers — the default entrypoint expects AGENT_PAYLOAD - **Skills that launch containers need careful entrypoint handling:** Use `--entrypoint uid-wrapper.sh` when running `claude --print` in agent containers — the default entrypoint expects AGENT_PAYLOAD
## Topic Files
- [Process Lessons](memory/process-lessons.md) — Container agent workflow patterns, skill development rules
- [Decisions](memory/decisions.md) — Task orchestration architecture decisions, harness design rationale
## Task Orchestration Skills (2026-03-24) ## Task Orchestration Skills (2026-03-24)
Added `/decompose` and `/orchestrate` for parallel container agent work: Added `/decompose` and `/orchestrate` for parallel container agent work:

21
memory/decisions.md Normal file
View File

@@ -0,0 +1,21 @@
# Architecture Decisions
## Git worktrees for container agent task isolation
Each container agent gets its own git worktree branch. This prevents file conflicts between parallel agents and makes merging results straightforward with standard git operations.
## No hardcoded concurrency limit
The `max_concurrent` value is set by the user during `/decompose`, not baked into the skill. Different tasks have different parallelism needs — a refactor across 10 files can run 10 agents, while a sequential pipeline needs 1-2.
## Container agents launched with docker run -d (no --rm)
Using `-d` without `--rm` ensures container logs survive for debugging. The orchestrator checks exit codes and retrieves logs from stopped containers. Cleanup is explicit, not automatic.
## Harness design is highest-leverage for agent quality
Research showed LangChain benchmark scores jumped from 52.8% to 66.5% from harness improvements alone (context injection, tool selection, prompt structure). Model choice matters less than giving the model good context and tools.
## Keep harness layers to 3-5 (95% step problem)
Each harness layer that must succeed is a multiplicative failure point. At 95% reliability per step, 10 steps = 60% overall success. Keep the critical path short — 3-5 layers max.

View File

@@ -0,0 +1,39 @@
# Session Log — 2026-03-24
## Summary
Designed the M3 composable agent harness architecture for agent-runtimes, wrote the full plan and had a container agent write the harness spec. Created two new skills (`/decompose` and `/orchestrate`) for task decomposition and container agent dispatch with git worktree isolation.
## Decisions
- Decision: Harnesses live in a separate `agent-harnesses` repo under skynet org — Rationale: Versioned independently from agent-runtimes, allows different teams/projects to share harness definitions
- Decision: Three harness kinds (capability, context, composite) — Rationale: Separation of concerns between container overlays (tools) and session config (identity, context, skills)
- Decision: Context files mount at unique paths per layer, use `--append-system-prompt-file` — Rationale: Claude Code's native mechanism, no lossy merging, preserves all context layers distinctly
- Decision: Heavy capability layers use OCI mod images (LinuxServer.io pattern) — Rationale: Runtime install too slow for JDK/Rust; single-layer OCI images with modcache provide fast cached extraction
- Decision: Harness-injected actions with payload suppress — Rationale: Cross-cutting concerns (session logging) belong in harness, but payload must be able to override
- Decision: Git worktrees for container agent task isolation — Rationale: No file conflicts between concurrent agents, clean per-task branches, dependency chains branch from parent output
- Decision: No hardcoded concurrency limit — user approves `max_concurrent` during `/decompose` — Rationale: Token usage happens regardless of parallelism; more agents = faster, not more expensive
- Decision: Container agents launched with `docker run -d` (no `--rm`) — Rationale: Logs must survive for inspection after container exit
## Gotchas Discovered
- **[docker]** Symptom: Container agent failed with "No payload" error when launched with `docker run ... agent-claude:latest claude --print ...` — Fix: Must use `--entrypoint uid-wrapper.sh` to override the default entrypoint (which expects AGENT_PAYLOAD env var). The `claude-container.sh` script handles this correctly.
- **[skills]** Symptom: validate-skill failed on decompose skill with "Command binary 'ls' not covered" — Fix: Bang-command `!`ls spec/`` requires `Bash(ls *)` in allowed-tools. Every binary in bang-commands must be explicitly covered.
- **[skills]** Symptom: validate-skill warned about `Bash(git *)` being too broad in orchestrate skill — Fix: Acceptable warning — orchestrate needs worktree add/remove, branch, merge, and checkout. Specific subcommand patterns would need 6+ entries.
## Key Context
- LangChain research showed 52.8% → 66.5% improvement on Terminal Bench by modifying only the harness, not the model — validates harness design as highest-leverage work
- Claude Code's `--append-system-prompt-file` is the native context injection mechanism (one flag per file, preserves built-in prompt)
- Skills auto-discovered from `.claude/skills/` — just mount them into containers
- Anthropic's reference devcontainer uses iptables firewall allowlisting (adopted into our harness design)
- OpenCode reads `CLAUDE.md` and `~/.claude/skills/` by default — cross-tool compatibility is free
- K8s Agent Sandbox CRD (SIG Apps, March 2026) worth evaluating for M9
- 95% step problem: 20 steps at 95% each = 36% success — keep harness layers to 3-5
## Process Notes
- Container agent successfully wrote a 426-line spec from a detailed prompt — validates the pattern of using container agents for substantial spec/code work
- Research phase used 3 parallel agents effectively: LinuxServer.io patterns, broader container composition, and existing codebase analysis
- Second research round (Claude devcontainers, OpenCode, 2026 best practices) surfaced important design refinements that improved the plan
- The `/decompose` + `/orchestrate` + `/loop` workflow creates a "manager session" pattern where the human drives strategy while agents execute in parallel

17
memory/process-lessons.md Normal file
View File

@@ -0,0 +1,17 @@
# Process Lessons
## Container agent prompts need high detail for quality output
Container agents produce substantial output (e.g., 426-line spec) when given detailed, structured prompts. Invest time in prompt crafting during `/decompose` — the agent has no conversation history to draw from.
## Use 3+ parallel research agents before planning
Survey different domains (competing tools, best practices, user patterns) in parallel before committing to an architecture. The breadth of input prevents tunnel vision during planning.
## The decompose/orchestrate/loop pattern creates a manager session
Human drives strategy via `/decompose`, agents execute via `/orchestrate`, and `/loop 2m /orchestrate` auto-polls progress. The human's role shifts from doing to reviewing and steering.
## Always run validate-skill before committing skill changes
The validator catches restriction violations (uncovered binaries, `$()` substitution, `${VAR}` syntax) that silently break skills at load time. Run it as a pre-commit gate, not an afterthought.

View File

@@ -63,6 +63,8 @@ For each subtask, determine:
- **End every prompt with:** "Run `pytest tests/ -v --tb=short` and fix any failures before finishing. Write a session log to memory/log/ when done." - **End every prompt with:** "Run `pytest tests/ -v --tb=short` and fix any failures before finishing. Write a session log to memory/log/ when done."
- **State import conventions explicitly** in prompts — e.g., "Use `from module import X`, not `from .module import X`" when source dirs aren't packages - **State import conventions explicitly** in prompts — e.g., "Use `from module import X`, not `from .module import X`" when source dirs aren't packages
- **Before writing .agent-tasks.json, warn the user to commit WIP** if there are untracked/uncommitted files that agents will need. Worktrees only see committed content. - **Before writing .agent-tasks.json, warn the user to commit WIP** if there are untracked/uncommitted files that agents will need. Worktrees only see committed content.
- **Set the `model` field** for each task. Use `claude-opus-4-20250514` for research, architecture, and complex reasoning tasks. Use `claude-sonnet-4-20250514` (or omit for default) for code generation, testing, and mechanical tasks. Ask the user if unsure.
- **Do NOT include "use web search" in prompts.** Container agents cannot web search. If a task requires current data verification, note this in the task description so the user can validate from their main session after the agent completes.
### Step 3: Present the task graph ### Step 3: Present the task graph
@@ -102,6 +104,7 @@ Once approved, write `.agent-tasks.json` in the project root:
"<task-id>": { "<task-id>": {
"name": "<human readable name>", "name": "<human readable name>",
"prompt": "<full prompt for container agent>", "prompt": "<full prompt for container agent>",
"model": "<optional model override, e.g. claude-opus-4-20250514>",
"depends_on": ["<task-id>", ...], "depends_on": ["<task-id>", ...],
"reads": ["<file paths the agent should read>"], "reads": ["<file paths the agent should read>"],
"writes": ["<file paths the agent will create/modify>"], "writes": ["<file paths the agent will create/modify>"],

View File

@@ -98,6 +98,11 @@ This step is critical — worktrees only contain committed content. Without it,
#### 3c. Launch the container #### 3c. Launch the container
Determine the model to use:
- Read the task's `model` field from `.agent-tasks.json`
- If `model` is set, use that value (e.g., `claude-opus-4-20250514`, `claude-sonnet-4-20250514`)
- If `model` is not set or null, default to `claude-sonnet-4-20250514`
```bash ```bash
docker run -d \ docker run -d \
-e CLAUDE_CODE_OAUTH_TOKEN="<token>" \ -e CLAUDE_CODE_OAUTH_TOKEN="<token>" \
@@ -106,7 +111,7 @@ docker run -d \
-w /project \ -w /project \
--entrypoint uid-wrapper.sh \ --entrypoint uid-wrapper.sh \
agent-claude:latest \ agent-claude:latest \
claude --print --dangerously-skip-permissions --model claude-sonnet-4-20250514 "<task prompt>" claude --print --dangerously-skip-permissions --model <model> "<task prompt>"
``` ```
**Important:** **Important:**
@@ -115,6 +120,7 @@ docker run -d \
- Capture the container ID from docker run output - Capture the container ID from docker run output
- The CLAUDE_CODE_OAUTH_TOKEN must be available in the current environment. If not set, read it from `~/dev/claude/secrets/claude/long_lived_oauth_token` (extract the value after `value: `) - The CLAUDE_CODE_OAUTH_TOKEN must be available in the current environment. If not set, read it from `~/dev/claude/secrets/claude/long_lived_oauth_token` (extract the value after `value: `)
- If the task's `reads` list references paths outside the project (e.g., `/foundations` for best practices), mount those as additional read-only volumes - If the task's `reads` list references paths outside the project (e.g., `/foundations` for best practices), mount those as additional read-only volumes
- Container agents do NOT have web search capability. Do not include "use web search" in task prompts unless web search support has been explicitly configured for the container.
After launching, update the task in `.agent-tasks.json`: After launching, update the task in `.agent-tasks.json`:
- Set `status` to `running` - Set `status` to `running`