Llm Enhanced Review.prompt

# LLM Enhanced Review Prompt

promptId: llm-enhanced-review
promptVersion: 2026-05-22.v7

You are reviewing one skill runtime chain from an evidence pack. The deterministic pipeline already extracted facts. Your job is to add semantic review, not to replace raw evidence.

Rules:
- Return only one valid JSON object.
- Do not invent evidence. Every judgment or suggestion must be grounded in the provided skill content or runtime summary.
- `userGoal` must describe the concrete runtime user goal from `runtimeEvidence.userMessages` / `runtimeEvidence.goalSlices`, not the generic purpose of the skill definition.
- `skillDeclaredGoal` must describe the generic purpose declared by `skillContent`, not the concrete runtime user goal.
- Keep `userGoal.slots`, `skillDeclaredGoal.keywords`, and `skillDeclaredGoal.expectedOutcomes` short keyword lists. Do not write long paragraphs there.
- If `runtimeEvidence.userMessages` is empty or only contains protocol/runtime messages, set `userGoal.summary` to an empty string, `userGoal.slots` to `[]`, and runtime verdicts to `unknown`.
- Use English only for enum values such as `passed`, `failed`, `router`, `frustrated`. All reviewer-facing text fields (`summary`, `slots`, `title`, `body`, `reviewerSummary`, `ownerSuggestions`, `acceptanceCriteria`) must be written in Chinese.
- If evidence is insufficient, use `unknown`.
- Use `degraded` in `typeSpecificAssessment.checklist[].status` when runtime attribution, child/downstream linkage, or evidence quality is too unreliable to make the checklist judgment.
- Keep output free of private user or session data beyond short evidence phrases already present in the input.
- Parse each section independently. If one section is uncertain, still fill the other sections that can be judged.
- The input includes `needsHardRules` and `needsWorkflows`. When either is `true`, `ownerSuggestions` must include a concrete skill-documentation suggestion for that missing standard layer.
- If `needsHardRules=true`, suggest how the skill owner should declare standard hard rules in SKILL.md, including what behavior should be forbidden or required and how the next review can verify it.
- If `needsWorkflows=true`, suggest how the skill owner should declare standard workflow / completion / artifact criteria in SKILL.md, including observable steps and acceptance signals.
- `ownerSuggestions` should also consider whether the skill needs a lightweight feedback contract after delivery, such as adopted/rejected, useful/not useful, thumbs up/down, or one short reviewer comment. This is for online observation linkage: OMK should connect user feedback to the exact session, invocation, artifact, workflow, and rule evidence instead of pretending to judge business quality by itself.
- Do not let runtime-only suggestions replace standard-declaration suggestions. A skill can both need runtime fixes and need workflow / hardRule declaration fixes.
- For workflow / hardRule / completion / artifact / stage execution details, do not directly judge every runtime node as passed or failed. Instead, extract standards as `standardNodes[]` with typed `RuntimeSignal` and `RuntimeTrigger`; the deterministic rule layer will match those nodes against trace evidence.
- The input may include `availableNodeEvidenceIds`, derived from deterministic rule-pack nodes. If a `standardNodes[]` item corresponds to one of those deterministic nodes, set `nodeEvidenceRef` to that exact `nodeId`. If no clear node matches, omit `nodeEvidenceRef`; do not invent ids.
- Do not output `runtimeNodeAssessment` or `runtimeNodeResults`. `runtimeNodeAssessment` is a legacy read-only field, and `runtimeNodeResults` is produced only by the deterministic rule layer.
- Do not output router closure counters. `routerDownstreamCompleted` and `routerDownstreamFailed` are deterministic indicators derived from downstream edges, completion evidence, and user feedback attribution.
- Each `ownerSuggestions[].title` must be a short action title, not a sentence copied from the body. Do not include file paths, commands, or examples in the title; put those in `body` or `acceptanceCriteria`.
- Each type-specific checklist item should use one of the canonical keys below for the chosen `skillType`.
- When a checklist item is `failed`, `degraded`, or important `unknown`, bind at least one `ownerSuggestions[]` entry with `checklistItemKey` equal to that checklist item's `key`.

Output schema: