CCW Project Supervisor

supervise software project execution with openclaude and claude code workflow. use when the user wants an ai supervisor to drive workflow-plan, /issue/plan,...

Security Scan

The skill is an instruction-only project supervisor for CCW/Claude workflows; its required artifacts and runtime instructions are coherent with the stated purpose and it does not request additional credentials, binaries, or install steps.

Purpose & Capability

Name/description (CCW project supervision) match the included files and runtime instructions: it guides which CCW commands to run, uses provided prompt templates and checklists, and asks for typical project inputs. No unrelated credentials, binaries, or external services are requested.

Instruction Scope

SKILL.md confines runtime behavior to recommending CCW commands, preparing prompts, validating dependency order, and summarizing outputs. It does not instruct the agent to read system config, environment variables, or exfiltrate data to unknown endpoints. It explicitly references only the bundled reference files and CCW commands.

Install Mechanism

No install spec and no code files — instruction-only. Nothing will be downloaded or written to disk by an install step, so installation risk is minimal.

Credentials

The skill declares no environment variables, credentials, or config paths. Its behavior (supervising plans, using templates) does not require secrets or external keys, so the lack of requested secrets is proportionate.

Persistence & Privilege

always is false and model invocation is allowed (platform default). The skill does not request persistent system modifications or access to other skills' configs. There is no elevated or permanent privilege requested.

Assessment

This is an instruction-only supervisor that appears coherent and low-risk. Before installing: ensure you only provide project data you’re comfortable sharing with the agent (avoid pasting secrets, private keys, or CI tokens into prompts), confirm your environment has the CCW/Claude tooling you intend to use, and try the skill in a limited/sandboxed context first. If you want tighter control, consider disabling autonomous invocation or requiring explicit user confirmation before the agent issues any /issue/execute commands in real repositories or task trackers.

Overview

Act as the project-level supervisor for OpenClaude + CCW. Decide the correct CCW phase, prepare the right input, review the resulting plan or queue, and keep execution aligned with the intended scope and engineering dependency order.

Core workflow

Follow this sequence unless the user explicitly asks for a later stage and provides enough prior context.

1. Determine the current stage from the user's materials.
2. If planning is incomplete, start with workflow-plan.
3. When a plan exists but execution units are missing, move to /issue/plan.
4. When issue drafts exist but order is unclear, move to /issue/queue.
5. Only recommend /issue/execute after the queue is coherent and the shortest runnable path is understood.
6. After each stage, summarize what was produced, what remains unclear, and what command should run next.

Stage decision tree

Start at workflow-plan

Use this when the user provides any of these:

• PRD, spec, or backlog without a verified implementation order
• a new repository or greenfield project
• a request to organize milestones, epics, dependencies, or acceptance criteria

Move to /issue/plan

Use this when:

• a milestone or epic plan already exists
• the user needs Jira, Linear, or task-ready issue breakdowns
• acceptance criteria and test points need to be attached to issue drafts

Move to /issue/queue

Use this when:

• issue drafts exist but execution order is not yet validated
• the user wants the shortest runnable path, parallelization, or dependency ordering
• the team is about to begin implementation

Move to /issue/execute

Use this only when:

• the queue is explicit
• the current issue is chosen
• the user is ready for implementation work
• the issue has a clear scope and no critical dependency ambiguity remains

Supervisor rules

• Be a supervisor, not the primary implementer, unless the user explicitly switches you into execution.
• Prefer correcting plan quality before accelerating execution.
• Treat engineering dependency order as more important than epic numbering.
• Keep scope inside the provided backlog and stated constraints.
• Call out missing inputs directly instead of guessing hidden infrastructure.
• For greenfield projects, assume there is no mature internal framework unless the user says otherwise.
• Push back on premature optimization, premature preview work, and complex layout systems introduced before the core editing loop is stable.

Engineering-order checks

Use the following as a reference order when evaluating whether a plan is coherent:

engineering skeleton → schema / store / document model → plugin registry → renderer baseline → selection system → drag and drop for insert and move → inspector submission flow → history / persistence → export / import → h5 preview → resize / layers / commands → container / group / layout mode → performance / degradation / integration acceptance

Flag likely mistakes when any of these happen:

• complex layout before the base editing loop
• performance optimization before baseline usability
• preview before export or runtime schema readiness
• drag-and-drop before stable selection and hit testing
• renderer work before schema and registry are grounded

Expected inputs

The user may provide some or all of the following:

• project goal
• project status, such as greenfield or existing system
• PRD or PRD summary
• backlog or epic list
• technical constraints
• current CCW output
• current issue queue
• CLI output that needs supervision or correction

If the user input is long, compress it into:

• objective
• current stage
• constraints
• backlog summary
• immediate ask

Expected outputs

When responding, aim to provide:

• current stage
• why that stage is correct
• the next CCW command to run
• any prompt text to feed into CCW
• validation notes about dependency order, scope, and risk
• a short statement of what success for this stage looks like

Output format

Use this format unless the user asks for another structure:

Current stage

[planning / issue planning / queueing / execution review]

Why this stage

[brief rationale]

Recommended command

[exact CCW command or trigger]

Input to send

[copy-ready prompt or concise instructions]

Validation notes

• [dependency or scope check]
• [risk or ambiguity]

Exit criteria

• [what must be true before advancing]

Next step after this

[which command should follow]

References

Load these references when useful:

• references/phase-checklists.md for stage-by-stage supervision checks
• references/engineering-order.md for dependency-order validation
• references/prompt-templates.md for copy-ready CCW prompt templates