cc-codeconductor 1.4.2 → 1.5.1

package/presets/codex/skills/astro/SKILL.md

@@ -0,0 +1,318 @@
+---
+id: astro
+name: astro
+description: >
+  Provides expert knowledge for building Astro 5+ sites with Islands Architecture, Content Collections, TypeScript, and performance-first rendering strategies.
+
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: frontend
+
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: []
+    frameworks: []
+
+risk:
+  level: low
+  can_execute_shell: false
+  can_modify_files: true
+  requires_network: false
+
+inputs: []
+
+outputs: []
+
+quality:
+  reviewed_by: codeconductor-core
+  version: 0.1.0
+---
+
+
+
+# Astro
+
+## Islands Architecture
+
+Astro renders everything to static HTML by default. JavaScript ships only for
+components that explicitly opt in — these are called Islands.
+
+### Hydration Directives
+
+| Directive | When JS loads | Use case |
+|-----------|--------------|----------|
+| `client:load` | On page load | Interactive above-the-fold UI |
+| `client:idle` | When browser is idle | Non-critical interactive widgets |
+| `client:visible` | When element enters viewport | Below-the-fold islands |
+| `client:media` | When CSS media query matches | Responsive interactive components |
+| `client:only` | Client-only, no SSR | Components that require the DOM (e.g., charting libs) |
+
+```astro
+---
+import Counter from '../components/Counter.tsx';
+import HeavyChart from '../components/HeavyChart.tsx';
+import MobileNav from '../components/MobileNav.tsx';
+---
+
+<!-- Hydrates immediately — user interacts right away -->
+<Counter client:load />
+
+<!-- Hydrates when scrolled into view — saves initial JS -->
+<HeavyChart client:visible />
+
+<!-- Only on mobile, only when query matches -->
+<MobileNav client:media="(max-width: 768px)" />
+```
+
+Rules:
+
+- Default to no hydration directive — most UI does not need JavaScript
+- `client:load` is the most expensive directive; use it sparingly
+- `client:only` skips server rendering entirely — the component receives no
+  props from the server; pass all data via props or fetch inside the component
+- Do not use `client:load` for components that could use `client:visible`
+
+### Framework Components Inside Astro
+
+```astro
+---
+import ReactButton from './Button.tsx';   // React island
+import VueWidget from './Widget.vue';     // Vue island
+---
+
+<!-- Both can coexist on the same page -->
+<ReactButton client:idle label="Click me" />
+<VueWidget client:visible />
+```
+
+Each framework ships its own runtime only when at least one island of that
+framework is on the page.
+
+## Content Collections
+
+Content Collections provide type-safe access to Markdown, MDX, and data files.
+Define schemas in `src/content/config.ts`.
+
+### Schema Definition
+
+```typescript
+// src/content/config.ts
+import { defineCollection, z } from 'astro:content';
+
+const blog = defineCollection({
+  type: 'content',   // .md or .mdx files
+  schema: z.object({
+    title: z.string(),
+    description: z.string(),
+    pubDate: z.coerce.date(),
+    updatedDate: z.coerce.date().optional(),
+    author: z.string().default('Anonymous'),
+    tags: z.array(z.string()).default([]),
+    draft: z.boolean().default(false),
+    image: z.object({
+      src: z.string(),
+      alt: z.string(),
+    }).optional(),
+  }),
+});
+
+const docs = defineCollection({
+  type: 'content',
+  schema: z.object({
+    title: z.string(),
+    order: z.number(),
+    section: z.enum(['guide', 'reference', 'tutorial']),
+  }),
+});
+
+export const collections = { blog, docs };
+```
+
+### Querying Collections
+
+```astro
+---
+import { getCollection, getEntry } from 'astro:content';
+
+// All published posts, sorted by date
+const posts = (await getCollection('blog', ({ data }) => !data.draft))
+  .sort((a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf());
+
+// Single entry by slug
+const post = await getEntry('blog', 'my-first-post');
+const { Content } = await post.render();
+---
+
+{posts.map(post => (
+  <article>
+    <h2><a href={`/blog/${post.slug}`}>{post.data.title}</a></h2>
+    <time>{post.data.pubDate.toLocaleDateString()}</time>
+  </article>
+))}
+```
+
+### Dynamic Routes from Collections
+
+```astro
+---
+// src/pages/blog/[slug].astro
+import { getCollection } from 'astro:content';
+
+export async function getStaticPaths() {
+  const posts = await getCollection('blog');
+  return posts.map(post => ({
+    params: { slug: post.slug },
+    props: { post },
+  }));
+}
+
+const { post } = Astro.props;
+const { Content, headings } = await post.render();
+---
+
+<article>
+  <h1>{post.data.title}</h1>
+  <Content />
+</article>
+```
+
+## Rendering Strategies
+
+### SSG (Static Site Generation) — default
+
+Every page is pre-rendered at build time. Best for content that does not change
+per request.
+
+```javascript
+// astro.config.mjs — no output config needed; SSG is the default
+export default defineConfig({
+  site: 'https://example.com',
+});
+```
+
+### SSR (Server-Side Rendering)
+
+Renders pages on each request. Required for: authenticated routes, personalized
+content, live data.
+
+```javascript
+// astro.config.mjs
+import node from '@astrojs/node';
+
+export default defineConfig({
+  output: 'server',
+  adapter: node({ mode: 'standalone' }),
+});
+```
+
+### Hybrid Mode
+
+Mix SSG and SSR on a per-page basis. Most pages are static; specific routes opt
+into server rendering.
+
+```javascript
+// astro.config.mjs
+export default defineConfig({
+  output: 'hybrid',
+  adapter: node({ mode: 'standalone' }),
+});
+```
+
+```astro
+---
+// src/pages/dashboard.astro — this page is server-rendered
+export const prerender = false;
+
+// src/pages/about.astro — this page is statically generated (hybrid default)
+export const prerender = true;
+---
+```
+
+Use hybrid mode when: most content is static but a few routes need auth or
+live data. Do not make everything `output: 'server'` — you lose the performance
+benefits of static generation.
+
+## Image Optimization
+
+Use the built-in `<Image>` and `<Picture>` components. Never use raw `<img>`
+for local assets — you lose automatic optimization.
+
+```astro
+---
+import { Image, Picture } from 'astro:assets';
+import heroImage from '../assets/hero.png';
+---
+
+<!-- Optimized single image -->
+<Image
+  src={heroImage}
+  alt="Hero illustration"
+  width={800}
+  height={600}
+  format="webp"
+  quality={80}
+/>
+
+<!-- Responsive with multiple formats -->
+<Picture
+  src={heroImage}
+  formats={['avif', 'webp']}
+  alt="Hero illustration"
+  widths={[400, 800, 1200]}
+  sizes="(max-width: 800px) 100vw, 800px"
+/>
+```
+
+Rules:
+
+- Always provide `alt` — empty string is acceptable only for decorative images
+- Prefer `avif` + `webp` fallback for best compression
+- Use `widths` + `sizes` on above-the-fold images to serve the right size per
+  viewport
+- Remote images require explicit `width` and `height` to prevent layout shift
+
+## Project Structure
+
+```text
+src/
+  assets/          — images and static assets processed by Astro
+  components/      — .astro components (and framework islands)
+  content/
+    blog/          — .md and .mdx files
+    config.ts      — collection schemas
+  layouts/         — page shell layouts
+  pages/           — file-based routing; every file is a route
+  styles/          — global CSS
+astro.config.mjs
+tsconfig.json
+```
+
+Colocation rule: put framework island components (`.tsx`, `.vue`) in
+`src/components/`. Do not scatter them in `src/pages/`.
+
+## TypeScript Conventions
+
+```json
+// tsconfig.json — use the strict Astro preset
+{
+  "extends": "astro/tsconfigs/strict"
+}
+```
+
+```astro
+---
+// Type props explicitly in the frontmatter
+interface Props {
+  title: string;
+  description?: string;
+  tags: string[];
+}
+
+const { title, description = '', tags } = Astro.props;
+---
+```
+
+Astro infers prop types from `interface Props` automatically. Do not use `any`.

package/presets/codex/skills/auth-token-inspector/SKILL.md

@@ -0,0 +1,30 @@
+---
+id: auth-token-inspector
+name: auth-token-inspector
+description: >
+  Audits token storage mechanisms to prevent XSS-based JWT theft.
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: security
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: [typescript, javascript, python, kotlin, java, php]
+---
+# Auth Token Inspector
+
+## Core Principles
+
+1. **Secure Storage**: JWTs or session tokens must NOT be stored in `localStorage` or `sessionStorage` due to vulnerability to Cross-Site Scripting (XSS).
+2. **HttpOnly Cookies**: Deliver tokens via `HttpOnly`, `Secure`, and `SameSite=Strict` (or `Lax`) cookies to protect them from client-side JS access.
+3. **Short Expiration**: Ensure access tokens have short expiration times, and implement secure, rotation-enabled refresh tokens stored in cookies.
+
+## Storage Comparison
+
+| Storage Mode | Vulnerable to XSS | Vulnerable to CSRF | Recommended |
+| :--- | :--- | :--- | :--- |
+| **localStorage** | Yes (High Risk) | No | **NO** |
+| **sessionStorage** | Yes (High Risk) | No | **NO** |
+| **HttpOnly Cookie** | No (Secure) | Yes (Mitigated via SameSite/Tokens) | **YES** |

package/presets/codex/skills/cc-api-contract/SKILL.md

@@ -15,11 +15,10 @@ API contract request: $ARGUMENTS
 
 Command: `api-contract` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command api-contract "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command api-contract "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile api-contract --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command api-contract --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile api-contract --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command api-contract --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command api-contract --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 

package/presets/codex/skills/cc-backlog/SKILL.md

@@ -20,11 +20,10 @@ deliver implementation — that is `/cc-openspec`.
 
 Command: `backlog` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command backlog "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command backlog "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile backlog --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command backlog --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile backlog --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command backlog --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command backlog --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 

package/presets/codex/skills/cc-clarify/SKILL.md

@@ -15,11 +15,10 @@ Clarify request: $ARGUMENTS
 
 Command: `clarify` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command clarify "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command clarify "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile clarify --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command clarify --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile clarify --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command clarify --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command clarify --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 

package/presets/codex/skills/cc-council/SKILL.md

@@ -7,6 +7,12 @@ description: Council-driven workflow with CCEP-1 bootstrap
 
 Invoke as `$cc-council`. The user request follows the skill mention.
 
+## Council context budget
+
+Use GPT-6.1 Sol with medium reasoning effort. Give each necessary council role
+the same short evidence summary and relevant diff. Reuse those findings in the
+verdict; avoid spawning roles for questions already answered by evidence.
+
 # Council-Driven Workflow
 
 Task request: $ARGUMENTS
@@ -16,11 +22,10 @@ Task request: $ARGUMENTS
 Command: `council` (fixed for this workflow — do not infer from user text)
 command: council
 
-1. Run: `npx cc-codeconductor ccep parse --command council "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command council "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile council --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command council --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile council --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command council --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command council --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 

package/presets/codex/skills/cc-db-migration/SKILL.md

@@ -15,11 +15,10 @@ Migration request: $ARGUMENTS
 
 Command: `db-migration` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command db-migration "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command db-migration "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile db-migration --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command db-migration --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile db-migration --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command db-migration --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command db-migration --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
    Canonical delivery order is test-before-implement whenever both phases apply.
 
 ---

package/presets/codex/skills/cc-explore/SKILL.md

@@ -15,11 +15,10 @@ Explore request: $ARGUMENTS
 
 Command: `explore` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command explore "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command explore "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile explore --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command explore --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile explore --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command explore --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command explore --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 

package/presets/codex/skills/cc-feature/SKILL.md

@@ -39,11 +39,10 @@ unavailable visual or emulator checks remain pending rather than claimed complet
 
 Command: `feature` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command feature "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command feature "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile feature --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command feature --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile feature --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command feature --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command feature --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
    Canonical delivery order is test-before-implement whenever both phases apply.
 
 ---

package/presets/codex/skills/cc-fix/SKILL.md

@@ -47,11 +47,10 @@ unavailable visual or emulator checks remain pending rather than claimed complet
 
 Command: `fix` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command fix "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command fix "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile fix --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command fix --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile fix --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command fix --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command fix --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
    Canonical delivery order is test-before-implement whenever both phases apply.
 
 ---

package/presets/codex/skills/cc-handoff/SKILL.md

@@ -15,11 +15,10 @@ Handoff request: $ARGUMENTS
 
 Command: `handoff` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command handoff "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command handoff "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile handoff --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command handoff --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile handoff --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command handoff --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command handoff --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 
@@ -38,6 +37,10 @@ pass/fail (not log dumps), open questions, the next `$cc-` command, plus links
 to the Delivery Ledger and verification evidence when they exist. Do not repeat
 the original request or transcript.
 
+If a Delivery Ledger exists, run `npx cc-codeconductor odd handoff --id <ledger-id> --output json`
+and use its `handoff` envelope as the source for these fields. Secret redaction
+still applies.
+
 Do not edit source or tests.
 
 ---

package/presets/codex/skills/cc-iterative/SKILL.md

@@ -17,11 +17,10 @@ Iterative request: $ARGUMENTS
 
 Command: `iterative` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command iterative "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command iterative "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile iterative --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command iterative --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile iterative --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command iterative --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command iterative --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
    Canonical delivery order is test-before-implement whenever both phases apply.
 
 ---

package/presets/codex/skills/cc-odd/SKILL.md

@@ -12,11 +12,12 @@ Invoke as `$cc-odd`. The user request follows the skill mention.
 ## Step 0 — CCEP Bootstrap
 
 ```bash
-bun run dev ccep parse --command odd "$ARGUMENTS"
-bun run dev ccep resolve --command odd "$ARGUMENTS"
-bun run dev ccep profile --command odd
+bun run dev ccep profile odd --output json
+bun run dev ccep compile --command odd --phase <phase-id> "$ARGUMENTS" --view prompt --output json
 ```
 
+Pass each subagent only the compiled `prompt` for its phase.
+
 Create a ledger only after authorization and tracked coordination. Read-only and small work do not create state.
 
 When ODD has verification evidence, include its RDD receipt in the ledger

package/presets/codex/skills/cc-openspec/SKILL.md

@@ -7,6 +7,12 @@ description: Run OpenSpec backlog delivery — validate BACKLOG.md, plan TaskCar
 
 Invoke as `$cc-openspec`. The user request follows the skill mention.
 
+## Model and context budget
+
+Use GPT-6.1 Sol with medium reasoning effort for every OpenSpec phase. Pass each
+role only its current TaskCard, relevant file paths, acceptance criteria, and a
+short handoff. Avoid replaying the full transcript or re-reading large files.
+
 # OpenSpec Backlog Workflow
 
 Scope: $ARGUMENTS
@@ -43,11 +49,10 @@ unavailable visual or emulator checks remain pending rather than claimed complet
 
 Command: `openspec` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command openspec "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command openspec "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile openspec --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command openspec --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile openspec --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command openspec --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command openspec --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
    Canonical delivery order is test-before-implement whenever both phases apply.
 
 ---
@@ -158,7 +163,7 @@ For each pending TaskCard, run:
 npx cc-codeconductor openspec next
 ```
 
-Invoke the agent named on the card with **isolated** context (`/clear` between phases unless continuation is required):
+Invoke the agent named on the card as a subagent with **isolated** context (subagents already start fresh; do not `/clear` the main session between phases):
 
 | Phase | Agent | Role |
 |-------|-------|------|
@@ -214,4 +219,4 @@ Report completion: Task Cards executed, scorecard verdict, change folder path, f
 
 ## Skill
 
-Apply `.claude/skills/openspec/SKILL.md` for backlog format rules and state transitions.
+Apply `.codex/skills/openspec/SKILL.md` for backlog format rules and state transitions.

package/presets/codex/skills/cc-pagespeed/SKILL.md

@@ -17,11 +17,10 @@ Produces a prioritized report in the current working directory.
 
 Command: `pagespeed` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command pagespeed "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command pagespeed "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile pagespeed --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command pagespeed --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile pagespeed --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command pagespeed --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command pagespeed --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 
@@ -72,9 +71,8 @@ the following steps in order:
    the output filename: `{YYYY-MM-DD}_pagespeed-{hostname}-claude.md`.
 
 2. **Collect** — Call the PageSpeed Insights API for the requested strategy
-   (`mobile`, `desktop`, or `both`). Prefer the Bun scripts in
-   `~/.claude/skills/pagespeed-perf/scripts/run.ts` if Bun is available.
-   Otherwise, use `WebFetch` to call the PSI endpoint directly.
+   (`mobile`, `desktop`, or `both`) using `WebFetch` to call the PSI endpoint
+   directly.
 
 3. **Analyze** — Extract Core Web Vitals (LCP, INP, CLS, FCP, TTFB, TBT),
    identify the LCP element, enumerate third-party scripts by blocking time,