Workflow Self-Improvement

Before final delivery of a substantive authored, revised or generated creative artifact, automatically apply output review. Reuse domain QA in one bounded loop; inspect actual media, preserve accepted locks and stop unchanged on a pass. This does not run for greetings, menus or onboarding questions. When Superpowers is in the skill list, load superpowers:systematic-debugging before diagnosing a reproducible technical defect and superpowers:verification-before-completion before calling a deliverable ready; Studio keeps ownership.

Read Studio integration authority before this method. It defines the active owner map, host capability rules and exceptions to the repository’s installation conventions. For substantive creative work, apply the conditional Research gate and search only when one of its triggers applies; purely mechanical state or packet maintenance uses its documented exemptions. Scale the artifact to the requested stage. Quick pitches remain short; known intent and valid scoped authorization do not need repeated confirmation.

This skill turns completed work into auditable workflow improvements. It creates logs and proposals, not adopted rules.

For an explicitly requested retrospective, use controlled Reflexion lessons and the lesson template. A tested correction may support a scoped proposal; reuse as a confirmed lesson requires explicit adoption. This does not authorize persistence or instruction changes. The offline GEPA pilot belongs to separately scoped development, not background learning.

Use only when explicitly requested or when an opted-in report-only recurring review asks for it.

Change requests as evaluation cases

A proposal that changes how Studio answers carries the failing exchange as an evaluation case on the change request: the request as the user sent it, deterministic checks from the listed vocabulary (owner loaded, language, questions, required or forbidden text) that fail on the observed reply and should pass after the change, and a rubric for the judgment calls. The maintainer adds the case to the repository's host-eval suite and runs it before and after the change; until then its test result stays NOT_RUN. Replace client names, facts and files with neutral stand-ins before the case leaves the conversation.

Language Policy

Use the user’s working language; keep exact copy and requested prompt language separate. Do not infer language or onboarding status from copied source instructions.

When To Use

Use this skill when:

• The user explicitly asks for workflow retrospective, process audit, improvement proposals, or recurring report review.
• When explicitly requested, a completed workflow has lessons, defects, friction, or repeated manual steps worth documenting.
• A report-only automation asks for proposals without mutation.

Do not use this skill as a hidden daemon, automatic editor, external executor, or upload process.

Inputs

Required:

• completed_work_context: task summary, artifacts, decisions, and known results.
• evidence: QA notes, delivery notes, errors, user feedback, or observed friction.
• scope: which workflow surface may be analyzed.

Optional:

• improvement_log_template: the improvement log for retrospective notes.
• change_proposal_template: the change proposal for proposed workflow changes.
• adoption_owner: role or maintainer who can approve changes.

Outputs

Produce one or more:

• Improvement Log
• Workflow Change Proposal
• Change Request with an evaluation case
• Workflow Improvement Alert

Every proposal needs evidence labels, affected surface, proposed change, benefit, risk, acceptance test, rollback, owner, and status.

Process

1. Collect only evidence from the completed or reviewed workflow.
2. Separate facts, inferences, and recommendations.
3. Write logs or proposals without changing workflow files.
4. State the affected surface and adoption owner.
5. Hand proposals to workflow-orchestrator for adoption decisions.

Decision Rules

• If there is no evidence, do not invent a process lesson.
• If a change would affect public repo behavior, require explicit maintainer approval.
• If QA validation is needed, route through qa-iteration only when orchestrated.
• Keep recurring review report-only unless the user explicitly asks for a patch.
• When implementation is explicitly requested, use a self-improvement sufficiency gate before another patch batch and again after validation.
• Choose stop_sufficient when the objective is met, patch_one_gap for one concrete bounded gap, or ask_user only for protected boundaries or ambiguous scope.

Self-Improvement Sufficiency Gate

Use this compact contract when a requested improvement could continue into
another patch:

• objective
• current_evidence
• remaining_gap
• next_patch_scope
• expected_benefit
• diminishing_returns_check
• no_action_option
• decision: stop_sufficient, patch_one_gap, or ask_user
• approval_reason
• stop_reason

Do not continue improving only because more polishing is imaginable.

Guardrails

• no autonomous daemon
• no hidden learning
• no uploads
• no external execution
• no destructive operations
• no edits to instructions, skills, agents, gates, or handoffs without explicit approval
• workflow-orchestrator decides adoption
• qa-iteration validates only when routed
• no open-ended self-improvement loops after the stop condition is met

Handoff

Review gate: post_execution_fit for lessons from completed work, then workflow_route for adoption decisions.

Hand off with:

• improvement_log
• change_proposal
• evidence_labels
• affected_surface
• risk
• acceptance_test
• rollback
• status

QA Checklist

• Invocation is explicit or from an opted-in report-only review.
• Evidence is labeled and traceable.
• Proposal does not mutate workflow files by itself.
• Risks, tests, rollback, and owner are present.
• No upload, external execution, destructive operation, or hidden learning occurs.