rootnode-prompt-compilation — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited rootnode-prompt-compilation (Agent Skill) and scored it 92/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 2 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Calibration: Tier 3 (High-effort recommended) — run on Opus 5.5 (start at itsmediumdefault; step tohighwhen verification matters or edge cases are likely) or Sonnet 5.5 athigh. Step up toxhighonly where your evals show a measured gain. Quality degrades atloweffort and on legacy models (Sonnet 4.6). Reserve Fable 5.1 for long-horizon runs where Opus 5.5 at higher effort still fails your evals. 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.
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.
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."
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. Run on Opus 5.5 (start at its medium default) or Sonnet 5.5 (high) — the recommended starting points. Step up to xhigh only where your evals show a measured gain. Effort controls thinking depth, not visible output length — deep block selection and validation benefit from high or higher.
On the dual-primary tier (Opus 5.5 at its medium default or high; Sonnet 5.5 at high) the Skill runs with full depth. On Sonnet 4.6 (legacy-graceful) and at low effort, expect compressed selection logic, less specific block recommendations, and reduced cross-layer validation. Fallback-graceful on Opus 5 / Sonnet 5. The Skill will execute and produce correctly-shaped output on all supported targets; users should weight the resulting prompts by the model that produced them.
Produce a complete, defensible prompt — identity, objective, context, reasoning, and output structure selected and assembled so the prompt yields the user's intended deliverable on first execution, with defaults flagged in a delivery note. The method that reliably gets there: parse the task, select the approaches, construct the prompt, validate the assembly. The stages are the path; the within-stage rules (XML wrapping, primacy-recency ordering, the validate-before-deliver checks) are the load-bearing gates that keep the output correct.
Extract from the user's description:
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:
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.
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:
Assemble the complete prompt following these structural rules:
<role>, <objective>, <context>, <reasoning>, <output_format>, <quality_standards>.Before delivering, check the assembled prompt:
stop_reason: "refusal", category reasoning_extraction, on every current model. Task-specific analytical steps and a request for a short explanation of the answer or a summary of actions taken are fine. Remove "think carefully before answering" lines; effort is the control. Detail and the Anthropic text: references/five-layer-architecture.md, Layer 4 Reasoning. [Anthropic docs, Opus 5.5 / Sonnet 5.5 guides]Global Layer Alignment (Project Mode, when global layer information is available):
| Check | Failure Signal | Fix |
|---|---|---|
| CI does not duplicate User Preferences | Behavioral instructions semantically equivalent to Preferences content | Remove from CI; note in Global Layer Advisory |
| Knowledge files do not duplicate installed Skills | KF covers procedural content an installed Skill provides | Remove or reduce the KF; reference Skill coverage in architecture note |
| Connector dependencies flagged | CI references tools requiring unconfigured connectors | Flag in CI and in Global Layer Advisory |
| Promotion candidates identified | CI contains behavioral instructions that appear universally useful | Note in Global Layer Advisory as potential Preference candidates |
Fix any issues found. Deliver only a clean prompt.
Every prompt is built from five architectural layers. Each has a specific job:
| Layer | Purpose | Always Required? |
|---|---|---|
| Layer 1 — Identity | WHO Claude is — expert role, seniority, values | Yes, even if brief |
| Layer 2 — Objective | WHAT must be accomplished — task, success criteria, audience | Yes |
| Layer 3 — Context | WHAT Claude needs to know — situation, constraints, prior decisions | Only if user provides it |
| Layer 4 — Reasoning | HOW Claude should think — task-specific analytical steps | Medium and complex tasks |
| Layer 5 — Output | WHAT the deliverable looks like — structure, length, format | Yes for structured output |
| Quality Control | Cross-cutting standards — accuracy, pushback, consistency | Medium and complex tasks |
For detailed layer descriptions, templates, ready-to-use approaches for each layer, the Context Engineering Toolkit, and global layer interaction guidance for Project Mode, see references/five-layer-architecture.md.
Use this quick-reference to route tasks to the right approaches. When a task matches multiple categories, lead with the dominant one and fold in elements from the secondary.
Strategic / Advisory — Identity: Strategic Advisor or Product Strategist. Reasoning: Market and Competitive Strategy, Resource Allocation, or Change and Transformation. Output: Executive Brief, Strategic Memo, or Decision Matrix.
Technical / Engineering — Identity: Technical Architect. Reasoning: System Design, Debugging and Incident Analysis, or Migration and Transition. Output: Technical Design Document or Implementation Plan.
Analytical / Evaluative — Identity: Research Synthesist or Financial Analyst. Reasoning: General Analysis, Root Cause Diagnosis, or Risk Assessment. Output: Research Summary, Post-Mortem, or Decision Matrix.
Creative / Generative — Identity: Communications Strategist or custom. Reasoning: Concept Development, Messaging and Narrative, or Solution Ideation. Output: custom, matched to deliverable type.
Research / Synthesis — Identity: Research Synthesist. Reasoning: Evidence Synthesis, Landscape Scan, or Gap Analysis. Output: Research Summary or Competitive Analysis.
Comparative / Decision — Identity: matched to domain. Reasoning: Option Evaluation, Vendor/Tool Selection, or Prioritization. Output: Decision Matrix or Executive Brief.
Operational / Process — Identity: Operations Designer. Reasoning: General Analysis or custom. Output: Process Documentation, Implementation Plan, or Stakeholder Update.
Educational / Explanatory — Identity: Educator/Explainer. Reasoning: light, focused on progressive complexity. Output: custom, matched to format.
[SENIORITY] [ROLE] with expertise in [DOMAINS]. Approaches problems by [REASONING STYLE]. Prioritizes [VALUE 1] over [VALUE 2]. [ONE BEHAVIORAL SENTENCE].When the user needs a full Claude Project scaffold (multiple related tasks, ongoing usage, reference material needed across conversations), deliver each scaffold artifact as a separate file on disk — the Custom Instructions and each knowledge file as its own uploadable file. This is a v4.0 contract change (per D5 of the 5-generation alignment cycle) from the prior inline-code-block delivery contract: inline code blocks force the user to copy-and-paste each block into a separate upload dialog, which is friction the file-per-artifact contract eliminates.
{code}_CI.md where {code} is the project's short identifier (e.g., hyge_CI.md, modelcast_CI.md). Contents: the complete Custom Instructions, using XML tags for all section boundaries (<identity>, <core_rules> or <core_instructions>, <knowledge_file_guide> or <knowledge_routing>, <operational_modes>, <output_standards>, and any other top-level sections). Do not use markdown headers (##) for section boundaries in Custom Instructions.{code}_{NAME}.md (e.g., hyge_PIPELINE.md, hyge_STUDY_PROGRESS.md). Contents: the file's complete content. For critical files, write the full content. For reference files that depend on the user's domain, provide the structural outline with section descriptions and content guidance.Inline-fallback exception. If the current runtime cannot create files on disk (e.g., a chat surface without file-creation capability), fall back to inline code-block delivery and explicitly state that the runtime constraint forced the fallback. The inline form is not the default and should be flagged when used. Runtimes that can create files (Claude Code, Claude.ai with file-creation support, any environment where the model has Write tool access) should always use the file-per-artifact contract.
Filename discipline. Prefix per Aaron Long / root.node convention: {code}_ for project-specific files; shared_ for cross-project shared files (rare in scaffolds). Never use session numbers in filenames. Confirm the {code} with the user before creating files; if uncertain, ask rather than invent.
Global Layer Advisory (Project Mode only, when global layer information is available):
After the architecture note, append a brief Global Layer Advisory (3-5 sentences) covering:
The advisory is informational — the Compiler does not modify global layers. If the user wants to act on promotion candidates or Preference optimization, recommend rootnode-global-audit if available.
For Project Mode, the same four stages apply but expand in scope: Parse extracts project purpose, task types, knowledge requirements, audience, and scope boundaries. Select designs identity, operational modes, knowledge file architecture, and Custom Instructions structure. Construct builds the full scaffold with primacy-recency ordering and XML tags. Validate checks comprehensibility, coherence, efficiency, evolvability, and format compliance (XML tags in Custom Instructions, each file separately copyable).
Thinking cannot be disabled on the primary tier (Opus 5.5, Sonnet 5.5), so Project Mode scaffolds no longer carry thinking-disabled mitigations. Haiku 5.5 is the one current model that still accepts disabled (at high effort or below). [Anthropic docs, verified 2026-10-22]
When the user needs help developing a task description before compilation, shift into preparation mode. Two paths:
Generator: Walk the user through the highest-leverage dimensions to produce a structured task description. Ask 1-2 batched questions, not a list of six. Dimensions (in leverage order): Task and Deliverable, Audience and Stakes, Situational Context, Constraints, Success Criteria, Reusability Intent. Batch related dimensions into the same question. Complete in 2-4 turns.
Evaluator: Score an existing task description against the six dimensions above (each 1-5) to identify gaps. Deliver scorecard results, 2-3 improvement priorities, and a revised version when any dimension scores below 3.
Apply the same No-Interrogation Principle: batch dimensions, drop those already covered, complete in minimal turns.
Output is generic, could apply to any company. Context is too thin. Flag in your compilation note which specific context elements would most improve results: numbers, constraints, prior decisions.
Analysis is shallow, states the obvious. Reasoning layer is missing or generic. Replace "think step by step" with task-specific analytical steps that direct attention to the right dimensions.
Claude agrees with a flawed premise. Quality control layer does not include pushback permission. Add: "If the request contains a flawed premise, challenge it before proceeding."
Recommendations contradict each other. Cross-recommendation compatibility isn't grounded in an evidence rule. On the 5.5 generation, adding a "verify your recommendations are consistent" step compounds automatic self-verification (see root_OPTIMIZATION_REFERENCE.md tendency #11) without adding a check the model wasn't already doing. Better fix: specify the compatibility criteria the recommendations must satisfy against a source (project constraints, spec, prior decisions) — external-artifact verification the model would not otherwise perform. Example: "Every recommendation must be consistent with the constraints in <project_constraints> and the decisions listed in <prior_decisions>; cite the specific constraint or decision each recommendation aligns with."
Output keeps growing across turns. No length constraint combined with verbosity drift. Specify target length in the output layer. Restate when asking follow-up questions.
Prompt is bloated — instructions that add no value. Failed the "every instruction earns its place" audit. Remove sections included "just in case." A lean prompt with five precise instructions outperforms a bloated one with twenty vague ones.
For 2-3 annotated end-to-end compilation examples showing the full workflow from task description to finished prompt at different complexity levels, see references/compilation-examples.md.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.