Conductor Feature Prepare

Feature Conductor — Prepare

Context artifacts preparation orchestrator — generates all context artifacts (module models, HTML mockups, technical specifications, test specifications) needed before code implementation can begin.

Ralph Loop Integration (AUTO-START — MANDATORY)

This skill AUTOMATICALLY starts a Ralph Loop to ensure complete artifact generation across all steps. Without Ralph Loop, the preparation may stop prematurely due to context window limits, API usage limits, or the agent incorrectly concluding work is "done enough". Ralph Loop ensures the same prompt is re-fed after each session exit, and the agent picks up where it left off.

FIRST ACTION: Start Ralph Loop

BEFORE doing anything else (before Phase 0, before reading any files), you MUST invoke the Ralph Loop skill using the Skill tool. This is a blocking requirement — do NOT proceed with any work until Ralph Loop is active.

Invoke this immediately:

Skill(skill: "ralph-loop:ralph-loop", args: "/conductor-feature-prepare  [version:] [module:] --completion-promise \"ALL ARTIFACTS GENERATED\" --max-iterations 20")

Replace `` and optional arguments with the actual arguments provided by the user.

Example: If the user invokes:

/conductor-feature-prepare mainapp

Then invoke:

Skill(skill: "ralph-loop:ralph-loop", args: "/conductor-feature-prepare mainapp --completion-promise \"ALL ARTIFACTS GENERATED\" --max-iterations 20")

If the user provides optional arguments:

/conductor-feature-prepare mainapp version:v2 module:user

Then invoke:

Skill(skill: "ralph-loop:ralph-loop", args: "/conductor-feature-prepare mainapp version:v2 module:user --completion-promise \"ALL ARTIFACTS GENERATED\" --max-iterations 20")

After Ralph Loop is active, proceed with Phase 0 (Resume Check) and continue normally.

How It Works

1. This skill auto-starts a Ralph Loop with the orchestrator prompt as the loop body
2. On each iteration, the agent checks which artifacts have already been generated
3. The agent generates one or more artifacts until context runs out or all are done
4. When the agent tries to exit, the Ralph Loop stop hook re-feeds the same prompt
5. The next iteration resumes from where the last one left off
6. When ALL artifacts are generated, the agent outputs the completion promise to exit the loop

Completion Promise

When ALL artifacts have been generated (or confirmed to already exist), output the following promise tag to signal the Ralph Loop that preparation is finished:

ALL ARTIFACTS GENERATED

CRITICAL: Only output this promise when EVERY artifact step has completed:

• User story items tagged
• Module models generated
• HTML mockups generated
• Technical specifications generated
• Test specifications generated

Do NOT output the promise prematurely. Do NOT output it to escape the loop.

Iteration Awareness

At the START of every iteration (including the first), the agent MUST:

1. Check if Ralph Loop is already active (if .claude/ralph-loop.local.md exists, skip re-invoking)
2. Read /context/prepare/PREPARE_MASTER.md (the progress source of truth) if it

exists, to determine which steps and versions are already COMPLETED

1. Verify against the /context/ subfolders that the artifacts the tracker marks

COMPLETED actually exist (reconcile the tracker if an artifact was deleted)

1. Skip steps already marked COMPLETED (unless version increment mode)
2. Resume from the first incomplete step
3. If the tracker's top-level status is COMPLETED (all steps for all versions done), output the

completion promise and stop

Inputs

The skill expects these arguments:

/conductor-feature-prepare  [version:] [module:]

| Argument | Required | Example | Description | |----------|----------|---------|-------------| | ` | Yes | mainapp | Application name to locate the context folder | | version: | No | version:v2 or version:v1,v2 or version:all | Filter user stories and artifacts by version. Supports single version, comma-separated list, all, or omit for all versions. Multiple versions are processed sequentially in ascending semver order | | module: | No | module:user` | If provided, process only this module. If omitted, process all modules |

Input Resolution

The application name is matched against root-level application folders:

1. Strip any leading _ prefix from folder names (e.g., 1_hub_middleware → hub_middleware)
2. Match case-insensitively against the provided application name
3. Accept snake_case, kebab-case, or title-case input
4. If no match found, list available applications and stop

Auto-Resolved Paths

| File | Resolved Path | |------|---------------| | PRD.md | /context/PRD.md | | Module Models | /context/model/ | | HTML Mockups | /context/mockup/ | | Specifications | /context/specification/ | | Test Specs | /context/test/ | | References | /context/reference/ | | Preparation Tracking | /context/prepare/PREPARE_MASTER.md |

Version Resolution

The version: argument supports four forms:

| Form | Example | Behavior | |------|---------|----------| | Single version | version:v2 | Process only v2 | | Comma-separated list | version:v1,v2,v3 | Process each version sequentially in ascending semver order | | Explicit all | version:all | Discover all versions from PRD.md, process sequentially in ascending semver order | | Omitted | (no version arg) | Same as version:all |

Version Discovery

When version:all or omitted:

1. Scan PRD.md for all [vX.Y.Z] version tags across all module sections
2. Collect unique versions
3. Sort in ascending semantic version order (v1.0.0 /context/prepare/PREPARE_MASTER.md`. If it does not exist, skip this check

(nothing has been prepared yet — every resolved version is new).

1. Resolve the version list (see Version Resolution).
2. Partition the resolved versions into two groups, using the tracker's **Version Processing

Order** table:

• completed_versions — versions whose row is marked COMPLETED in PREPARE_MASTER.md
• new_versions — versions with no row, or a row not yet COMPLETED

1. Decision:

| new_versions | completed_versions | Artifacts exist? | Action | |---------------|---------------------|-----------------|--------| | Not empty | Any (including empty) | Yes (expected — prior versions built them) | Proceed with new_versions only — filter out completed versions from the processing list. Existing artifacts are the base for version increment. | | Not empty | Any | No | Proceed with all resolved versions — no prior artifacts, start from scratch. | | Empty | Not empty | Yes | STOP. Print: "All requested versions ({list}) for {application} are already marked COMPLETED in /context/prepare/PREPARE_MASTER.md and their context artifacts still exist. To redo, first delete the existing context artifact folders (model/, mockup/, specification/, test/) and PREPARE_MASTER.md, then re-run this skill." | | Empty | Not empty | No | Proceed with all resolved versions — artifacts were cleaned up, this is a legitimate redo. |

1. Update the resolved version list to contain only the versions that will be processed

(either new_versions or all versions for redo). This filtered list is what the Sequential Version Loop in Phase 1 will iterate over.

Workflow

Phase 0: Resume Check (Runs Every Ralph Loop Iteration)

This phase runs at the START of every iteration, including the first. In a Ralph Loop, each iteration begins fresh with the same prompt, so the agent MUST check existing artifacts to understand what has already been completed.

1. Auto-Start Ralph Loop — Check if .claude/ralph-loop.local.md exists. If it does NOT

exist, Ralph Loop is not yet active. Invoke it NOW using the Skill tool: `` Skill(skill: "ralph-loop:ralph-loop", args: " --completion-promise \"ALL ARTIFACTS GENERATED\" --max-iterations 20") ` If .claude/ralph-loop.local.md` already exists, Ralph Loop is active — skip this step.

1. Use project information from CLAUDE.md (already in context) — extract database type,

design system, technology stack, and all infrastructure details.

1. Resolve the version list using the Version Resolution rules:

• Single version → [v2]
• Comma-separated → parse and sort ascending by semver → [v1, v2, v3]
• all or omitted → scan PRD.md for ALL [vX.Y.Z] tags, deduplicate, sort ascending

1. Read the progress tracker /context/prepare/PREPARE_MASTER.md if it exists:

• It is the source of truth for which steps/versions are COMPLETED
• Reconcile it against the artifact folders below (if the tracker says COMPLETED but the

artifact is missing, reset that entry to PENDING)

• If it does NOT exist, this is a fresh start — Phase 1 Step 1.1.1 will create it

Then check which artifacts actually exist on disk:

• Check /context/model/ for module model files
• Check /context/mockup/ for HTML mockup files
• Check /context/specification/ for spec files
• Check /context/test/ for test spec files

1. If the tracker's top-level status is COMPLETED (all steps for all resolved versions done)

AND the artifacts still exist:

• Output ALL ARTIFACTS GENERATED and stop

1. If multiple versions were resolved, proceed to Phase 1 — the version loop will determine

which versions still need processing (see Phase 1 Sequential Version Loop)

1. Otherwise, proceed to Phase 1, starting from the first step not marked COMPLETED in the tracker

Phase 1: Context Artifacts Generation

This phase generates all required context artifacts before code implementation begins. Each step checks if the artifact already exists — if it does, the step is skipped. This ensures the phase is idempotent and can be resumed safely.

IMPORTANT: If module argument was provided, pass it through to each sub-skill invocation so that only the relevant subset of artifacts is generated.

Sequential Version Loop

Steps 1.1, 1.1.1 (tracker init) and 1.2 (tagging) are once-only setup — they run a single time before the loop. When multiple versions are resolved (list, all, or omitted), Phase 1 wraps the per-version Steps 1.3–1.9 in a version loop:

# Once, before the loop: Step 1.1 (resolve folder), Step 1.1.1 (create PREPARE_MASTER.md),
#                        Step 1.2 (tag user stories)

resolved_versions = [v1.0.0, v1.0.1, v1.0.2]  # ascending semver order

For each version in resolved_versions:
  1. Mark this version IN PROGRESS in PREPARE_MASTER.md's Version Processing Order table
  2. Run Steps 1.3–1.9 with this single version as the version argument
  3. For the FIRST version: artifacts are generated from scratch (Steps 1.4–1.9)
  4. For SUBSEQUENT versions: artifacts already exist from the prior version — operate in
     Version Increment Mode (update, not skip)
  5. All artifacts for this version must be COMPLETED (mark the version COMPLETED in the tracker)
     before moving to the next version

When only a single version is resolved, the loop runs once — no behavioral difference from the original single-version flow.

Version Increment Mode

When artifacts exist from a previous version but the current version in the loop has new/changed user stories, Steps 1.4–1.9 operate in update mode:

• DO NOT skip steps just because artifacts already exist. The existing artifacts are from a

previous version and need to be updated with the current version's changes.

• Re-invoke ALL sub-skills (modelgen, mockgen, specgen, testgen) with BOTH the current version

AND module arguments so they can update the existing artifacts incrementally.

• The sub-skills are responsible for reading the [v] sections in PRD.md and

updating their output files accordingly (appending new fields, modifying existing diagrams, updating specs and test scenarios).

Bug Regression Awareness (Redo/Redevelop Scenario)

PRD.md modules may contain a ### Bug section listing previously fixed bugs (e.g., [BUG-024] Fixed Message ID link...). These entries represent validated fixes from prior development cycles. When generating or updating artifacts, sub-skills MUST treat bug fix entries as supplementary requirements:

• modelgen-*: If a bug fix involved model changes (new fields, changed relationships),

the model output must reflect the corrected structure.

• mockgen-tailwind: If a bug fix involved UI changes (layout, navigation, styling),

the mockup must reflect the corrected design.

• specgen-*: If a bug fix involved logic changes (event listeners, processing flow,

validation), the specification must include the corrected behavior.

• testgen-functional: Bug fix descriptions should inform test scenarios to ensure

regression coverage — each bug fix should have at least one corresponding test assertion.

This ensures that when an application is redeveloped from scratch, previously reported bugs do not reappear in the new implementation.

PRD.md Extended Sections Awareness

PRD.md may contain three extended sections that influence how downstream skills are invoked and what context they receive. Detect each section's presence at the start of Phase 1 and record the result for use throughout the version loop:

• # Design System — Already consumed by Step 1.5 (Infer Design System) for routing

decisions and resolved-file-path propagation to mockgen- and specgen-. No additional action needed; Step 1.5 is the canonical handler.

• # Architecture Principle — Already consumed by Step 1.3 (Infer Database Type) and

Step 1.7 (Infer Technology Stack) as the primary signal for routing decisions. Sub-skills (modelgen-, specgen-) read it directly from PRD.md.

• # High Level Process Flow — Detect presence here so all downstream skills are aware:

1. Check PRD.md for a # High Level Process Flow section. If present, record:

• The list of named flows (e.g., "Country submission flow", "Worker registration flow")
• Any external file references (e.g., [FLOW_DIAGRAM.md](reference/FLOW_DIAGRAM.md))
• Resolve any referenced file paths relative to PRD.md

1. When invoking sub-skills in subsequent steps, pass this awareness as context so each skill

knows process flows are available and should be consulted:

• modelgen-\* uses flows to identify entities/documents that participate in messaging
• specgen-\* uses flows as the blueprint for service-layer methods, queue topology, and

message consumer/publisher design

• mockgen-\* uses flows to determine screen-to-screen navigation and async UI states
• testgen-functional uses flows to design end-to-end test scenarios that exercise each

flow step in order

1. If absent, sub-skills fall back to deriving messaging behavior from individual user stories

(existing behavior).

Record the detection result (Design System: yes/no, Architecture Principle: yes/no, Process Flow: yes/no + flow names) in your working memory for the duration of the run. This awareness does NOT replace each sub-skill's own reading of PRD.md — every sub-skill reads PRD.md directly, but knowing which sections are present helps the orchestrator detect missing pre-requisites early and surface them to the user.

Step 1.1: Resolve Application Folder

1. Match the `` argument against root-level folders (same logic as Input Resolution)
2. The resolved `` is the root for all context artifacts
3. Verify /context/PRD.md exists — if not, stop with error

Step 1.1.1: Initialize Preparation Tracking (PREPARE_MASTER.md)

This step runs ONCE before the version loop starts (like tagging). It creates the progress tracker that this skill — and any resumed Ralph Loop iteration — reads to know what is done.

1. If /context/prepare/PREPARE_MASTER.md already exists, read it and reconcile i

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: rashidee
• Source: rashidee/co2-skills
• License: MIT
• Homepage: https://compound-context.com/

Install and usage instructions live in the source repository linked above.