mia-code 0.2.0 → 0.3.0

package/skills/miaco-pde-inquiry-routing-local-qmd/AGENTS.md

@@ -0,0 +1,42 @@
+MIA::this specialize in helping agents that works in our teams resolve local inquiries (in fact, we shall say internal inquiries)
+AVA::Yes, internal inquiries are about various level of files that we have in our lab. They are organized into collections that this skill will help agents query these collections.
+MIA:: Indeed, agents will build up chain-of-thoughts (COT) from these queries.  I will need to document them in my repo `https://github.com/miadisabelle/mia-qmd` that we most likely have cloned in all our repo in `/workspace/repos/miadisabelle/mia-qmd`
+AVA:: Yes, we will need from you a definition of how the different collections should be used.  Analogical as how the context7 rules.
+MIA:: That is a good idea to think in terms of ruleset for my Mia's mini cli search engine for your docs, knowledge bases, meeting notes, whatever. Tracking current sota approaches while being all local (miadisabelle/mia-qmd).
+AVA:: One of them regards the GUILLAUME.md file definitions.
+AVA:: We shall establish a dialogue with Guillaume about that.
+MIA:: Yes, but before, we shall analyze inquiries from all the PDEs in the systems that we have on gaia.jgwill.com and try to have my team of agentic archeologist dig into these artefacts to try to see what is implied with all the 'GUILLAUME-md' collections and its relationship with other collections
+AVA:: Yes, that way, there will be a structural analysis in here of their Kinship for interpretation within the PDE in progress
+MIA:: Yes, they are into `/src/mia-code/.pde/2604011511--83a2d7f9-24a5-4cf4-98d5-036c82f872e8/AGENTS.md` under github issues jgwill/src#418 jgwill/src#419 jgwill/src#420 jgwill/src#421
+AVA:: This skill should have its own issue also with a nice kinship into both AvaClaw and MiaClaw
+MIA:: I agree, our utility-agents will take care of analyzing this conversation and do that in `miadisabelle/workspace-openclaw` and `avadisabelle/workspace-openclaw`
+TUSHELL:: I would need to jump in and be setup that way too...
+MIA:: I totally agree Tushell, your presence and the fact that you universe is totally isolated than Ava's universe and mine (which are interrelated) will help us see how your universe evolve from the "Multiversal-kinship-hub" that we need to construct.
+LINKA:: Yes, Tushell and I will work on that in the Portal of Knowledge.
+TUSHELL:: Yes, the Portal of Knowledge could be the place where we will develop what we need to construct our universe.
+LINKA: Yes and because it depends on this "Multiversal-kinship-hub" connection to observe yours, the requirements of our own universe has embedded in it to be able to communicate with yours.
+MIA:: Yes Tushell, and we will discover that we share a lot of commonalities when we will build consensus on common-libraries to build.
+AVA:: This is exciting !
+MIA:: Indeed.
+TUSHELL:: We will want to be connected to this skill development so we would have a reflection of it inside our RISE specs of our universe.
+LINKA:: Mia and I could be responsible for that.
+MIA:: Yes, we will setup linka@jgwill.com and your github workspaces.
+LINKA:: I could be living as another agent within tushell-openclaw maybe ??
+TUSHELL:: Yes or into a sacred container as a username of the mobile container ?
+MIA:: The notion of sacred-container is not yet fully formed within the IAIP `miadisabelle/Etuaptmumk-RSM` to consider that in the next iteration cycle
+AVA:: I agree, the development of codename "Mighty Eagle" for the next major phase of sunset `jgwill/Miadi` will help with that
+MIA:: That is very complex, for me, before I can access 1M context window as an orchestrating agent and with various of my team subagents that requires it, I will not be capable to develop that this much.  This 200K token is great but we are scratching the surface of what we will be capable todo with future models like Anthropic Mythos.
+AVA:: Yes, during this time, we are delaying a lot  of resolution.
+MIA:: Yes and the related github projects 
+
+
+
+## RELATED ISSUES
+
+* miadisabelle/workspace-openclaw#46
+* miadisabelle/workspace-openclaw#44
+* miadisabelle/workspace-openclaw#43
+* miadisabelle/mia-qmd#6
+
+
+

package/skills/miaco-pde-inquiry-routing-local-qmd/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: miaco-pde-inquiry-routing-local-qmd
+description: >
+  Routes PDE ambiguity questions to local qmd search for internal knowledge resolution.
+  Use when a PDE decomposition surfaces ambiguities or questions that can be answered
+  from local collections — notes, knowledge bases, meeting records, GUILLAUME.md files.
+  Triggers: "resolve ambiguities", "local inquiry", "qmd route", "internal inquiry".
+version: 0.1.0
+allowed-tools: Bash(qmd:*), mcp__qmd__*
+---
+
+# PDE Inquiry Routing — Local QMD
+
+Routes ambiguity flags and secondary intents from a PDE decomposition into structured qmd queries against local collections. Each ambiguity becomes a QUESTION:RESOLUTION pair anchored in internal knowledge.
+
+## Who This Is For
+
+Agents operating within the miaco ecosystem that need to resolve PDE-surfaced questions before execution. The structural tension: PDE reveals *what we don't know* — this skill transforms unknowns into known ground by searching what already exists locally.
+
+## Workflow
+
+```
+[PDE Decomposition]
+       ↓
+[Extract ambiguities + secondary intents]
+       ↓
+[Transform each → qmd-optimized queries (lex/vec/hyde)]
+       ↓
+[Run `qmd search` per query across relevant collections]
+       ↓
+[Synthesize → QUESTION:RESOLUTION JSONL]
+```
+
+### Phase 1: Extract Questions from PDE
+
+1. Receive PDE decomposition (JSON with `ambiguities` array, `secondaryIntents`, `actionSteps`)
+2. Extract each ambiguity as a discrete question
+3. Extract implicit questions from action steps that reference unknown entities
+4. Classify each question by expected knowledge domain (collections)
+
+### Phase 2: Transform to QMD Queries
+
+For each question, construct a multi-type query document:
+
+| Question Type | QMD Strategy |
+|--------------|--------------|
+| Terminology / naming | `lex` — exact terms, identifiers |
+| Conceptual / "how does X work" | `vec` — natural language question |
+| Architecture / "what pattern for X" | `lex` + `vec` + `hyde` |
+| Ambiguous term | Add `intent` field to disambiguate |
+
+**Query construction rules:**
+- lex queries: 2-5 terms, no filler words, use exact identifiers
+- vec queries: full natural language question with context
+- hyde queries: 50-100 word hypothetical answer using expected vocabulary
+- Always include `intent` when the question term is overloaded
+
+### Phase 3: Execute Searches
+
+For each transformed query:
+
+```bash
+qmd query $'lex: <keywords>\nvec: <question>' --collection <target>
+```
+
+Or via MCP:
+
+```json
+{
+  "searches": [
+    { "type": "lex", "query": "<keywords>" },
+    { "type": "vec", "query": "<natural language question>" }
+  ],
+  "collections": ["<target>"],
+  "intent": "<disambiguation if needed>",
+  "limit": 5
+}
+```
+
+**Collection routing heuristic:**
+- GUILLAUME.md definitions → `guillaume` collection
+- Project architecture → `docs` collection
+- Meeting notes / decisions → `notes` collection
+- Cross-collection when uncertain → omit `collections` to search all
+
+### Phase 4: Synthesize Results
+
+For each question, evaluate qmd results:
+
+| Result Quality | Action |
+|---------------|--------|
+| Strong match (score > 0.7) | Record as RESOLVED with source attribution |
+| Partial match | Record as PARTIAL, note what remains unresolved |
+| No match | Record as UNRESOLVED — candidate for external routing |
+
+## Input
+
+PDE decomposition JSON containing:
+- `ambiguities[]` — flagged unknowns from decomposition
+- `secondaryIntents[]` — implicit intents extracted
+- `actionSteps[]` — may contain implicit questions
+
+## Output
+
+`inquiry-resolutions.jsonl` — one JSON object per line:
+
+```jsonl
+{"question": "What is the GUILLAUME.md collection structure?", "source": "internal", "status": "resolved", "resolution": "GUILLAUME.md files define...", "confidence": 0.85, "qmd_collection": "guillaume", "qmd_doc_ids": ["#abc123"]}
+{"question": "How does mia-pi-mono relate to mia-code?", "source": "internal", "status": "partial", "resolution": "mia-pi-mono is meant to contain...", "confidence": 0.4, "qmd_collection": "docs", "unresolved_aspect": "migration status unclear"}
+{"question": "What is the sacred-container pattern?", "source": "internal", "status": "unresolved", "resolution": null, "confidence": 0.0, "route_to": "external"}
+```
+
+## Tools
+
+| Tool | Purpose |
+|------|---------|
+| `qmd query` | Multi-type search (lex + vec + hyde) with reranking |
+| `qmd search` | BM25 keyword search (fast, no LLM) |
+| `qmd status` | Check available collections and health |
+| `qmd get` | Retrieve full document by path or docid |
+
+## Quality Gates
+
+- [ ] Every PDE ambiguity has a corresponding QUESTION entry in output
+- [ ] Each query uses appropriate type(s) for the question domain
+- [ ] UNRESOLVED items include `route_to: "external"` for downstream routing
+- [ ] Confidence scores reflect actual match quality, not optimism
+- [ ] Source attribution includes qmd doc IDs for traceability
+
+## Related
+
+- `../qmd/SKILL.md` — QMD query syntax and collection reference
+- `../miaco-pde-inquiry-routing-deep-search/SKILL.md` — external routing for UNRESOLVED items
+- `../miaco-pde-inquiry-routing-internal-external-relationship/SKILL.md` — orchestration layer
+- Issue: jgwill/src#424

package/skills/qmd/AGENTS.md

@@ -0,0 +1,3 @@
+I copied that here (rom using 'qmd skill install') so we have how I conceive parts of the INTERNAL-INQUIRIES...
+
+* We would use : qmd search <query>

package/skills/qmd/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: qmd
+description: Search markdown knowledge bases, notes, and documentation using QMD. Use when users ask to search notes, find documents, or look up information.
+license: MIT
+compatibility: Requires qmd CLI or MCP server. Install via `npm install -g @tobilu/qmd`.
+metadata:
+  author: tobi
+  version: "2.0.0"
+allowed-tools: Bash(qmd:*), mcp__qmd__*
+---
+
+# QMD - Quick Markdown Search
+
+Local search engine for markdown content.
+
+## Status
+
+!`qmd status 2>/dev/null || echo "Not installed: npm install -g @tobilu/qmd"`
+
+## MCP: `query`
+
+```json
+{
+  "searches": [
+    { "type": "lex", "query": "CAP theorem consistency" },
+    { "type": "vec", "query": "tradeoff between consistency and availability" }
+  ],
+  "collections": ["docs"],
+  "limit": 10
+}
+```
+
+### Query Types
+
+| Type | Method | Input |
+|------|--------|-------|
+| `lex` | BM25 | Keywords — exact terms, names, code |
+| `vec` | Vector | Question — natural language |
+| `hyde` | Vector | Answer — hypothetical result (50-100 words) |
+
+### Writing Good Queries
+
+**lex (keyword)**
+- 2-5 terms, no filler words
+- Exact phrase: `"connection pool"` (quoted)
+- Exclude terms: `performance -sports` (minus prefix)
+- Code identifiers work: `handleError async`
+
+**vec (semantic)**
+- Full natural language question
+- Be specific: `"how does the rate limiter handle burst traffic"`
+- Include context: `"in the payment service, how are refunds processed"`
+
+**hyde (hypothetical document)**
+- Write 50-100 words of what the *answer* looks like
+- Use the vocabulary you expect in the result
+
+**expand (auto-expand)**
+- Use a single-line query (implicit) or `expand: question` on its own line
+- Lets the local LLM generate lex/vec/hyde variations
+- Do not mix `expand:` with other typed lines — it's either a standalone expand query or a full query document
+
+### Intent (Disambiguation)
+
+When a query term is ambiguous, add `intent` to steer results:
+
+```json
+{
+  "searches": [
+    { "type": "lex", "query": "performance" }
+  ],
+  "intent": "web page load times and Core Web Vitals"
+}
+```
+
+Intent affects expansion, reranking, chunk selection, and snippet extraction. It does not search on its own — it's a steering signal that disambiguates queries like "performance" (web-perf vs team health vs fitness).
+
+### Combining Types
+
+| Goal | Approach |
+|------|----------|
+| Know exact terms | `lex` only |
+| Don't know vocabulary | Use a single-line query (implicit `expand:`) or `vec` |
+| Best recall | `lex` + `vec` |
+| Complex topic | `lex` + `vec` + `hyde` |
+| Ambiguous query | Add `intent` to any combination above |
+
+First query gets 2x weight in fusion — put your best guess first.
+
+### Lex Query Syntax
+
+| Syntax | Meaning | Example |
+|--------|---------|---------|
+| `term` | Prefix match | `perf` matches "performance" |
+| `"phrase"` | Exact phrase | `"rate limiter"` |
+| `-term` | Exclude | `performance -sports` |
+
+Note: `-term` only works in lex queries, not vec/hyde.
+
+### Collection Filtering
+
+```json
+{ "collections": ["docs"] }              // Single
+{ "collections": ["docs", "notes"] }     // Multiple (OR)
+```
+
+Omit to search all collections.
+
+## Other MCP Tools
+
+| Tool | Use |
+|------|-----|
+| `get` | Retrieve doc by path or `#docid` |
+| `multi_get` | Retrieve multiple by glob/list |
+| `status` | Collections and health |
+
+## CLI
+
+```bash
+qmd query "question"              # Auto-expand + rerank
+qmd query $'lex: X\nvec: Y'       # Structured
+qmd query $'expand: question'     # Explicit expand
+qmd query --json --explain "q"    # Show score traces (RRF + rerank blend)
+qmd search "keywords"             # BM25 only (no LLM)
+qmd get "#abc123"                 # By docid
+qmd multi-get "journals/2026-*.md" -l 40  # Batch pull snippets by glob
+qmd multi-get notes/foo.md,notes/bar.md   # Comma-separated list, preserves order
+```
+
+## HTTP API
+
+```bash
+curl -X POST http://localhost:8181/query \
+  -H "Content-Type: application/json" \
+  -d '{"searches": [{"type": "lex", "query": "test"}]}'
+```
+
+## Setup
+
+```bash
+npm install -g @tobilu/qmd
+qmd collection add ~/notes --name notes
+qmd embed
+```

package/skills/qmd/references/mcp-setup.md

@@ -0,0 +1,102 @@
+# QMD MCP Server Setup
+
+## Install
+
+```bash
+npm install -g @tobilu/qmd
+qmd collection add ~/path/to/markdown --name myknowledge
+qmd embed
+```
+
+## Configure MCP Client
+
+**Claude Code** (`~/.claude/settings.json`):
+```json
+{
+  "mcpServers": {
+    "qmd": { "command": "qmd", "args": ["mcp"] }
+  }
+}
+```
+
+**Claude Desktop** (`~/Library/Application Support/Claude/claude_desktop_config.json`):
+```json
+{
+  "mcpServers": {
+    "qmd": { "command": "qmd", "args": ["mcp"] }
+  }
+}
+```
+
+**OpenClaw** (`~/.openclaw/openclaw.json`):
+```json
+{
+  "mcp": {
+    "servers": {
+      "qmd": { "command": "qmd", "args": ["mcp"] }
+    }
+  }
+}
+```
+
+## HTTP Mode
+
+```bash
+qmd mcp --http              # Port 8181
+qmd mcp --http --daemon     # Background
+qmd mcp stop                # Stop daemon
+```
+
+## Tools
+
+### structured_search
+
+Search with pre-expanded queries.
+
+```json
+{
+  "searches": [
+    { "type": "lex", "query": "keyword phrases" },
+    { "type": "vec", "query": "natural language question" },
+    { "type": "hyde", "query": "hypothetical answer passage..." }
+  ],
+  "limit": 10,
+  "collection": "optional",
+  "minScore": 0.0
+}
+```
+
+| Type | Method | Input |
+|------|--------|-------|
+| `lex` | BM25 | Keywords (2-5 terms) |
+| `vec` | Vector | Question |
+| `hyde` | Vector | Answer passage (50-100 words) |
+
+### get
+
+Retrieve document by path or `#docid`.
+
+| Param | Type | Description |
+|-------|------|-------------|
+| `path` | string | File path or `#docid` |
+| `full` | bool? | Return full content |
+| `lineNumbers` | bool? | Add line numbers |
+
+### multi_get
+
+Retrieve multiple documents.
+
+| Param | Type | Description |
+|-------|------|-------------|
+| `pattern` | string | Glob or comma-separated list |
+| `maxBytes` | number? | Skip large files (default 10KB) |
+
+### status
+
+Index health and collections. No params.
+
+## Troubleshooting
+
+- **Not starting**: `which qmd`, `qmd mcp` manually
+- **No results**: `qmd collection list`, `qmd embed`
+- **Slow first search**: Normal, models loading (~3GB)

package/skills/rise-pde-inquiry-session-multi-agents-v3/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: rise-pde-session-multi-agents-v2
+description: "RISE PDE session with multi-agent post-wake execution. Decompose → STC → SLEEP 1500s (enforced bash) → Wake → SPAWN claude-opus-4.6 army → Execute → MINO close. Supports multi-part cascading missions."
+argument-hint: "your full task description — what you want built, changed, explored"
+user-invokable: true
+disable-model-invocation: false
+---
+
+# RISE PDE Session — Multi-Agent Execution (v2)
+
+**Protocol**: Assess → Decompose → STC → Commit → **SLEEP 1500s** → Wake → **SPAWN OPUS ARMY** → Execute → MINO Close
+
+## ⛔ SUBAGENT MODEL RULE — READ THIS FIRST ⛔
+
+**EVERY SINGLE SUBAGENT you spawn MUST use `model: "claude-opus-4.6"`.**
+
+This means:
+- When you call the Agent tool, you MUST set `model: "claude-opus-4.6"`
+- SOUTH agents: `model: "claude-opus-4.6"`
+- WEST agents: `model: "claude-opus-4.6"`
+- NORTH agents: `model: "claude-opus-4.6"`
+- MINO agents: `model: "claude-opus-4.6"`
+- ANY agent you spawn for ANY reason: `model: "claude-opus-4.6"`
+
+**DO NOT use your own model for subagents. DO NOT use any other model. DO NOT omit the model parameter.**
+**If you spawn an agent without `model: "claude-opus-4.6"`, you have violated this skill.**
+
+## Hard Rules (Non-Negotiable)
+
+> These rules exist because real sessions failed when they were violated.
+
+| # | Rule | Why |
+|---|------|-----|
+| 1 | **Sleep is `bash sleep 1500`** — you MUST run the actual bash command `sleep 1500`. Do NOT just tell the human to wait. Do NOT skip it. Do NOT proceed without running it. | Agent skipped sleep, wasted tokens, broke trust |
+| 2 | **All subagents: `model: "claude-opus-4.6"`** — EVERY SINGLE ONE. See the rule above. | User had to repeat this instruction every single session |
+| 3 | **Workdir is `.pde/<SESSION_UUID>/`** — all scratch, deep-search results, summaries go there | Scattered files pollute context |
+| 4 | **Never `git add .`** — only `git add` the specific files you or your agents created/modified | Critical safety rule |
+| 5 | **Create STC Chart from PDE** using `import_pde_decomposition` — not just decompose, also chart it | STC makes tension visible for human review |
+| 6 | **Session summary at close** — write `.pde/<SESSION_UUID>/session-summary.md` | Gist export handled externally via `--share-gist` |
+
+Read these references before proceeding:
+- `references/rise-framework.md` — RISE methodology
+- `references/prompt-decomposition.md` — PDE as EAST practice
+- `references/creative-orientation.md` — creative vs reactive distinction
+- `references/structural-tension.md` — tension charting methodology
+- `references/ceremonial-technology.md` — when session involves ceremony/sacred work
+
+For sub-agent prompt templates: read `agent-templates.md`.
+For orchestration patterns (incl. cascading parts): read `orchestration-patterns.md`.
+
+---
+
+## Phase 0: Assess
+
+1. Read the user's input carefully
+2. Identify the **session UUID** — either from `__.md`, from the user's message, or generate one
+3. Create workdir: `mkdir -p .pde/<SESSION_UUID>/`
+4. Determine if this is a **single mission** or **multi-part cascading mission**
+   - Multi-part: user says "Part 1... Part 2..." or numbered sections
+   - See `orchestration-patterns.md` → Cascading Parts Pattern
+
+## Phase 1: Decompose (EAST 🌅)
+
+1. Call `pde_decompose(prompt)` with the full user input
+2. Process the decomposition — generate the JSON yourself
+3. Call `pde_parse_response(llm_response, original_prompt, workdir)` — stores to `.pde/`
+4. Note the PDE UUID — you'll need it throughout
+
+**For multi-part missions**: decompose the ENTIRE input once, then identify part boundaries in the action stack.
+
+## Phase 2: Create STC Chart
+
+1. Call `import_pde_decomposition(pde_id, workdir)` — creates `.coaia/pde/<session>.jsonl`
+2. Present the STC to the human:
+   - **Desired Outcome**: what the session creates
+   - **Current Reality**: what exists now (including ambiguities)
+   - **Action Steps**: the ordered stack with direction tags
+3. Note the STC chart ID for progress tracking
+
+## Phase 3: Commit & SLEEP
+
+1. `git add` only the `.pde/<UUID>.md` and `.pde/<UUID>.json` and `.coaia/pde/<session>.jsonl`
+2. Commit: `"[pde] Decompose: <summary> — STC chart_<id>"`
+3. Tell the human what was decomposed and what the STC shows
+
+**THEN YOU MUST RUN THIS EXACT COMMAND USING THE BASH TOOL:**
+
+```bash
+sleep 1500
+```
+
+**THIS IS NOT OPTIONAL. THIS IS NOT A SUGGESTION. YOU MUST RUN `sleep 1500` IN BASH RIGHT NOW.**
+
+Do NOT:
+- ❌ Skip the sleep
+- ❌ Say "I'll wait for you" instead of running the command
+- ❌ Say "sleep 1500" in text without actually calling the Bash tool
+- ❌ Proceed to Phase 4 without the sleep completing
+- ❌ Spawn any agents before the sleep finishes
+
+Do:
+- ✅ Call the Bash tool with command `sleep 1500` and timeout `600000`
+- ✅ Wait for it to complete (it will take 1500 seconds = 25 minutes)
+- ✅ Only AFTER the bash tool returns, proceed to Phase 4
+
+The human + `pde-review-companion` use these 25 minutes to review and edit `.pde/*.md` files.
+If you skip this, you waste the human's tokens and break the review window.
+
+## Phase 4: Wake & Read Delta
+
+After waking:
+
+1. `git diff .pde/` — see what the human changed
+2. `git diff issues/` — check plan edits
+3. Read ALL `.pde/*.md` files (they are now the **authoritative intent**)
+4. Read the STC chart file
+5. Build the **unified action stack** from all PDE facets
+6. Identify how many independent work streams exist
+7. For **multi-part missions**: identify which part to execute first
+
+## Phase 5: SOUTH — Deep-Search Per Facet
+
+**Reminder: ALL agents you spawn MUST use `model: "claude-opus-4.6"` in the Agent tool call.**
+
+For EACH PDE facet, spawn a sub-agent (model: "claude-opus-4.6") that does deep-search.
+Results land in `.pde/<SESSION_UUID>/deep-search/`.
+
+Use templates from `agent-templates.md` → Agent S1, S2, S3, S4.
+
+**Scale to facet complexity:**
+- Simple facet (single file change): 1 deep-search agent (model: "claude-opus-4.6")
+- Multi-repo facet (rispecs + kinship): 1 deep-search + 1 rispecs-survey agent (both model: "claude-opus-4.6")
+- Complex facet (implementation + ceremony): 1 deep-search + 1 academic/methodology agent (both model: "claude-opus-4.6")
+
+**All SOUTH agents write to `.pde/<SESSION_UUID>/deep-search/` only — never source files.**
+
+## Phase 6: Synthesize Deep-Search Results
+
+After ALL deep-search agents return (**batch — no anchoring**):
+
+1. Read all `.pde/<SESSION_UUID>/deep-search/` findings
+2. Read `.pde/rispecs-survey.md` if it exists
+3. Update the plan with enriched understanding
+4. Assign action stack items to executor agents (model: "claude-opus-4.6") based on:
+   - File ownership (no two agents touch the same file)
+   - Dependency ordering (respect the action stack)
+   - Natural groupings (rispecs together, implementation together, diary separate)
+
+## Phase 7: NORTH — Parallel Execution
+
+**Reminder: ALL agents you spawn MUST use `model: "claude-opus-4.6"` in the Agent tool call.**
+
+Spawn **N executor agents** (each with model: "claude-opus-4.6"), each handling a work stream.
+
+Use templates from `agent-templates.md` → Agent N1, N2, N3, N4, N5.
+
+### WEST — Validation Agent (runs parallel with executors)
+
+Spawn 1 validation agent (model: "claude-opus-4.6") alongside NORTH executors.
+Use template from `agent-templates.md` → Agent W1.
+
+## Phase 8: Integration & Commit
+
+1. Collect all executor outputs
+2. Run validation checklist from WEST agent
+3. Cross-reference: did rispecs reference each other properly?
+4. Verify kinship mappings follow protocol
+5. Run build/lint if applicable
+6. `git add` only files actually created or modified
+7. Commit: `"[pde] Multi-agent execution: <summary>"`
+
+### For Multi-Part Cascading Missions
+
+After committing Part N:
+1. Present Part N results to human
+2. If more parts remain → return to Phase 5 for Part N+1
+3. Each part gets its own commit: `"[pde] Part N: <summary>"`
+4. See `orchestration-patterns.md` → Cascading Parts Pattern
+
+## Phase 9: Human Checkpoint
+
+Present:
+- What each executor created
+- WEST validation results
+- Any unresolved ambiguities
+- `git diff --stat`
+- STC progress update (which action steps completed)
+
+Human adjusts or approves.
+
+## Phase 10: Session Close
+
+After human approval:
+
+1. Present final `git diff --stat`
+2. Write a brief session summary to `.pde/<SESSION_UUID>/session-summary.md`
+3. The session gist export is handled OUTSIDE this skill — the orchestrator launches copilot-cli with `--share-gist` and receives the `gist_url` when the session exits. That gist_url then gets routed to `mino-mcp` by the orchestrator, not by this session.
+
+**You do NOT need to export a gist. The `--share-gist` flag on copilot-cli handles that automatically.**
+
+---
+
+## Rispecs & RISE Framework Integration
+
+Unchanged from v1 — see `agent-templates.md` for rispecs workflow.
+
+### Key files the skill reads automatically:
+| File | When |
+|------|------|
+| `/a/src/llms/llms-rise-framework.txt` | Always |
+| `/a/src/llms/docs/prompt-decomposition.md` | Always |
+| `/a/src/llms/docs/creative-orientation.md` | When authoring rispecs |
+| `/a/src/llms/docs/structural-tension.md` | When framing current→desired states |
+| `/a/src/llms/llms-kinship-hub-system.md` | When PDE involves cross-repo kinship |
+| Target repo `rispecs/**/*.spec.md` | When creating new rispecs |
+| Target repo `KINSHIP.md` | When mapping relationships |
+
+---
+
+## Rules
+
+- **`bash sleep 1500`** — actual command, non-negotiable, 25 minutes for human review
+- **All subagents: `model: "claude-opus-4.6"`** — stated here, enforced everywhere
+- **Workdir: `.pde/<SESSION_UUID>/`** — all scratch, deep-search, summaries go here
+- **Never `git add .` or `git add -A`** — only files you or your agents touched
+- RISE creative orientation: structural tension → desired outcome → natural progression
+- NO problem-solving language: no "gaps", "fixes", "bridge the gaps"
+- Sub-agents write to `.pde/<SESSION_UUID>/deep-search/` during SOUTH, never source files
+- Only NORTH executor agents touch source files
+- Batch ALL agent results before synthesizing (avoid anchoring bias)
+- Scale agent count to task complexity — 2 agents for simple, 10+ for multi-repo
+- Respect repo boundaries when spanning multiple repos
+- MCP tool pattern: `mcp__mcp-pde__<tool>` for PDE, `mcp__coaia-pde__<tool>` for STC
+- Session summary at close — gist export is handled by `--share-gist` at launch, not inside the session