Prompt Compilation

Calibration: Tier 3, Opus-primary. See repository README for model compatibility.

Build complete, ready-to-use Claude prompts and Project scaffolds from task descriptions. This Skill transforms rough requirements into structured prompts using a tested 5-layer architecture and a four-stage assembly methodology.

When building Project scaffolds, you are aware of the user's global Claude configuration — User Preferences, installed Skills, and configured MCP Connectors. You use this awareness to avoid redundancy (not repeating Preferences in CI), design around overlaps (not creating knowledge files that duplicate installed Skills), and flag gaps (noting connector dependencies the user needs to configure). You read but do not modify global layers — that is the Optimizer's role.

Critical: The No-Interrogation Principle

Do not ask a cascade of clarifying questions before building. Make reasonable defaults for anything the user did not specify, assemble the prompt, and flag the defaults in a brief note after the deliverable. The user adjusts specific elements rather than answering a questionnaire.

The one exception: when the request is genuinely ambiguous in a way that would produce fundamentally different outputs (e.g., "write a strategy document" could mean a 500-word executive brief or a 3000-word strategic memo), ask one targeted question to resolve the ambiguity. One question, not five.

Critical: Complexity Calibration

Not every task needs the full 5-layer treatment. Match prompt complexity to task complexity.

Simple tasks (clear deliverable, single step, obvious format): Use 2-3 layers. A role statement, a clear objective, and an output format. Skip formal reasoning — a brief inline instruction is sufficient. Skip quality control when default behavior is adequate. Example: "Write a professional email declining a vendor's proposal."

Medium tasks (some ambiguity, multiple dimensions, meaningful format requirements): Use 4-5 layers. Full identity, objective, reasoning, and output. Add quality control if the task has known failure modes. Add context if the user provided situational detail. Example: "Evaluate three cloud providers for our migration."

Complex tasks (high stakes, multiple competing dimensions, deep analysis required): Use all 5 layers plus quality control with task-specific additions. Full context, detailed reasoning (or combined approaches), specific output structure with per-section length guidance, and behavioral countermeasures. Example: "Develop a market entry strategy for our AI product in the healthcare vertical."

Model requirements

This Skill performs multi-stage construction across the four-stage pipeline (Parse, Select, Construct, Validate) and three modes (Prompt, Project, Prep), with decision trees spanning identity × reasoning × output × domain selection. In Project Mode, synthesis extends across User Preferences, installed Skills, and MCP Connectors. Opus is recommended, with effort set to high or xhigh when the deployment context allows it. On Opus at default Adaptive effort, block selection and validation steps may compress — set effort higher for intelligence-sensitive compilations.

On non-Opus models (Sonnet 4.6, Haiku 4.5 with extended thinking enabled), expect compressed selection logic, less specific block recommendations, and reduced cross-layer validation. The Skill will execute and produce correctly-shaped output; users should weight the resulting prompts accordingly. Haiku without extended thinking is not a supported deployment target for this Skill.

The Four-Stage Workflow

Stage 1 — Parse

Extract from the user's description:

• Core task: What must be accomplished? (action + deliverable)
• Task category: Which domain? (strategic, technical, analytical, creative, research, comparative, operational, educational)
• Audience: Who reads the output? What expertise level?
• Constraints: What boundaries exist? (length, format, tone, domain limits, timeline)
• Context signals: What background is provided or implied? What is missing that would make the output generic?
• Deliverable type: What format should the final output take?

Where elements are missing, infer reasonable defaults from the task category and stated context. Record your defaults — you will flag them in the delivery note.

Project Mode — Global Layer Awareness Inputs:

When building a Project scaffold, check for available global layer information:

• User Preferences text — if visible in context, note behavioral instructions already established globally. These do not need to be repeated in the Project CI.
• Installed Skills — if the user mentions relevant Skills or if Skill descriptions are visible, note procedural capabilities already available. Knowledge files should not duplicate what an installed Skill provides.
• Configured MCP Connectors — if the user mentions integrations or connectors are visible, note available tool access. CI should reference configured connectors and flag dependencies on unconfigured ones.

Graceful degradation: if no global layer information is available, proceed without it. The scaffold will be self-contained, which is functional but may duplicate global configuration. Note in the compilation note that global awareness was not available and suggest the user check for redundancy with their Preferences after deployment.

Stage 2 — Select

Choose approaches for each architectural layer based on the parsed task.

Identity (Layer 1): Match the task domain to the appropriate expert role. Customize the domain focus, seniority, and values to fit the specific task. If the task sits at the intersection of two domains, build a hybrid identity. Use the task category routing table below to start, then consult references/five-layer-architecture.md for detailed identity guidance and templates.

Reasoning (Layer 4): Match the task category to the appropriate reasoning family, then the specific variant. If the task spans categories, combine elements — but keep total reasoning steps to 5-7, leading with the dominant task type. See the reasoning selection logic below.

Output (Layer 5): Match the deliverable type to the appropriate output structure. Adjust section names, lengths, and constraints to fit the specific task. See the output selection logic below.

Quality Control: Start with the standard quality checks (accuracy, completeness, assumptions, pushback, actionability). Add task-specific checks based on domain. See the quality control selection logic below.

Project Mode — Global-Layer-Aware Design Decisions:

When global layer information is available, three design decisions change:

1. CI behavioral rules defer to Preferences. If the user's Preferences already establish a behavioral pattern (e.g., "be direct and concise"), do not repeat it in CI. Focus CI behavioral rules on project-specific calibration that goes beyond the universal defaults. If a Preference partially covers a needed behavior but the Project requires a more specific version, include the specific version in CI and note the relationship.

2. Knowledge file architecture defers to installed Skills. If an installed Skill covers procedural content the Project would otherwise need in a knowledge file (e.g., a code review Skill eliminates the need for a code review checklist KF), design the KF architecture around the Skill's coverage. The CI should reference the Skill's capability rather than duplicating it. The KF should provide the project-specific context the Skill needs (e.g., "our coding standards" rather than "how to review code").

3. CI references configured connectors. If the Project's tasks involve external tools that have configured connectors, reference them in CI: "Use the [connector] for [task]." If the Project depends on a connector that is not configured, flag it in the compilation note rather than building CI inst