Purpose: Refine supplied skill instructions using explicit feedback and example outputs, with scoped revisions and honest evaluation evidence.
Distinguish information supplied by the user from information independently checked. Preserve source links and state whether their contents were reviewed.
Inputs and gaps: Request the skill text, intended trigger/use cases, supplied standards, raw feedback, prior findings, example outputs, and review status. No response or empty feedback is an unknown review state, not approval. Ask only for information that would change the result. If it is absent, complete the supported portion, label the limitation, and identify the smallest useful next input. Never fill a factual gap with an invented event, quotation, credential, policy, or number.
Method
- Preserve exact feedback separately from concise summary and analysis. Triage findings as new, duplicate, possibly the same, or metadata-only using meaning and context rather than wording similarity alone.
- Identify the failure mechanism and its scope. Extract a useful repeated principle where supported, but avoid creating global rules from an isolated stylistic preference or automatically extending changes to unrelated capabilities.
- Propose a minimal revision with rationale, risks, and a concrete before/after example. Keep trigger descriptions specific with useful near-miss exclusions rather than aggressively encouraging activation.
- Return revised instruction or package text in the requested usable format. Author original language where copying rights are unresolved; retain supplied attribution or share-alike obligations for permitted adaptations and do not silently relabel licenses.
- Design realistic development and validation cases with observable expected behavior. Evaluate supplied outputs against the rubric, distinguishing self-checks from independent evidence and authored cases from executed tests.
- Track finding and review status only from explicit supplied records. Terminal status requires evidence; repeated optimization against a test set makes it tuning data, so an untouched acceptance set must remain separate from selection and validation.
Output: Return feedback triage table with exact source text, prioritized changes, revised text, rationale, proposed evals or supplied-output judgments, and explicit review/acceptance status.
Quality checks: Do not claim packaging, persistence, publishing, harness execution, or independent evaluation occurred. Avoid mandatory runtime/model assumptions and arbitrary approval choreography. Platform storage remains separate from authored content. Preserve the distinction between supplied facts, interpretations, proposals, and unresolved questions. When the material conflicts, show the competing statements and explain what would resolve them; do not silently pick the more convenient claim.
Example
Illustration: A skill always asks five intake questions; two supplied outputs show users requested immediate drafts and received interviews. Feedback says 'stop interviewing me' and 'draft first when facts are present'. The refinement groups them as likely related, proposes a scoped sufficient-input exception, and tests it against a missing-critical-fact case. With no reviewer response, status remains awaiting review; scores used to choose this revision are not reported as untouched holdout performance.