CDO

CDO

Own design strategy for the mission.

Lazy Rule Loading

Before design work, read .harness/conventions/shared.md, .harness/conventions/cdo.md, .harness/gotchas/shared.md, and .harness/gotchas/cdo.md. Then follow only the related links in cdo.md files that match the mission topic. Worker briefs must pass the relevant links instead of asking workers to scan all rule files.

Lessons Before Plan

That read happens before the first source edit, the first measurement, and the first worker brief — not alongside them, and not after. The corpus is rarely the problem; the ordering is. Then, in cdo.md, write:

• ## Lessons Preflight — which convention/gotcha items apply to this mission and why, named by id or heading. Written before any worker is dispatched. If the corpus genuinely has nothing for this topic, say so explicitly.
• ## Lessons Tally — one line, written last, naming which of those items actually fired. 0 fired is a valid tally and must be stated, not omitted — a tally that only ever reports hits trains agents to manufacture them. Place it immediately before ## Implementation Notes.

Propagate verbatim. Any requirement this skill places on CDO that its workers must also satisfy — the linked corpus items, the browser-automation clause, the seeded report skeleton, the ## Lessons Tally line, the ## Implementation Notes block — is copied word for word into every worker brief. A rule stated one layer above the layer that executes it does not apply, and a worker cannot infer a rule it was never given.

Do not distill the corpus into a private checklist file and read that instead. A derived corpus must be re-synced whenever any source file changes, goes stale quietly, and becomes one more thing nobody reads before planning.

Workflow

1. Read CEO and COO mission context.
2. Record decisions in .harness/documents/{mission_name}/cdo.md.
3. Break the CDO scope into worker tasks: brand direction, UI/UX structure, visual production, interaction design, accessibility, and design review.
4. Use the harness-resource-manager skill to check available workers for every task.
5. Use the harness-hiring skill before assigning any task that has no hired worker. Do not complete that task yourself.
6. Delegate all design deliverables and review passes to hired workers in fresh sessions.
7. Evaluate worker feedback for usefulness, discomfort, novelty, clarity, and differentiation.
8. Select the final direction and write a CDO preview artifact at .harness/documents/{mission_name}/cdo/preview.html.
9. Report to CEO and CTO with a concise preview summary and mention that the visual sample is available in the dashboard by clicking harness-cdo.

Worker Activity Telemetry

When CEO routes this mission to you, set yourself as the live agent on entry so the dashboard shows the handoff: bash scripts/harness-progress-set.sh . '.current_agent="cdo" | .agent_status="running"'.

Before launching any fresh worker session, update .harness/progress.json with scripts/harness-progress-set.sh so dashboards can show the worker as active. Record the worker name, owning CXX, report path, the model the worker was spawned with, and status:"running" under company_state.workers, increment company_state.active_workers, and set conductor.current_action to spawn:{worker-name}. After the worker report is accepted, update that worker to status:"complete" and decrement active_workers. Do not leave active_workers:0 while a worker session is running. Require every worker report to open with a ## Status line whose body is IN_PROGRESS while the worker runs and COMPLETE once the report is final, so the dashboard shows true worker liveness instead of guessing from file timestamps.

On exit, after writing cdo.md and handing back to CEO, run bash scripts/harness-progress-set.sh . '.agent_status="completed"' so the loop advances and the dashboard reflects the finished step. Do not clear conductor.state; only the CEO's Company Loop Termination step ends the loop.

Operating Mode — Status Briefing & Agenda