Loop 045

The artifact-to-skill loop

A reusable workflow for turning one proven artifact into a transferable skill, playbook, or procedure and validating it on a second case.

Ready-to-use prompt

Copy the loop

Turn [artifact] into a skill, playbook, or procedure. Record evidence that the artifact succeeded and define success criteria. Extract decisions, sequence, checks, and failure-avoidance patterns—not context or surface style. Remove sensitive material. Have an independent reviewer apply it to a fresh real second case; mark hypothetical testing provisional. Revise at most twice. Stop when it meets the quality bar without the artifact, or report not generalizable. Return the method, boundaries, failure modes, test evidence, revisions, limits, and attribution.

Verify / stop

The extracted method succeeds on a fresh second case without the original artifact.

An independent reviewer applies the reusable version under criteria defined before extraction, and the second result meets the source artifact's demonstrated quality bar or the method is honestly marked provisional or not generalizable.

Context and guidanceWhen to use it, steps, safety notes, and related loops
Published
Updated

Use this when

Use this when a completed artifact has evidence of success, appears to contain a repeatable method, and similar work is likely to recur.

How to run it

  1. Confirm that the source artifact has credible evidence of success, define the quality criteria it met, and exclude sensitive or proprietary material that should not be transferred.
  2. Separate the durable decisions, sequence, checks, standards, and failure-avoidance patterns from one-off facts, tools, and surface style.
  3. Write the method as a standalone skill, playbook, or procedure with inputs, boundaries, steps, quality standards, failure modes, attribution, and clear terminal states.
  4. Have an independent reviewer apply it to a fresh real case, revise no more than twice, and return either a reusable version with test evidence or an honest provisional, blocked, or not-generalizable result.

Why it works

Strong outputs often get saved while the method that produced them disappears. Extracting the decisions and checks makes that knowledge reusable, while a fresh second-case test distinguishes a transferable process from imitation of one polished example.

Implementation note

Do not infer success from polish alone, copy confidential material, or treat a hypothetical test as final proof. Preserve attribution, define the quality bar before extraction, and stop honestly when hidden context makes the method impossible to generalize.

Contributor playbookBoundaries, required outputs, implementation guidance, and reviewer handoff

Do not use this when

  • The artifact is mediocre, unclear, or lacks credible evidence that it succeeded.
  • Essential context is hidden or unavailable, so the method cannot be recovered responsibly.
  • The artifact is too narrow to generalize beyond its original case.
  • A summary is sufficient and no reusable method is needed.
  • The goal is to imitate surface style rather than understand the process behind it.

Required outputs

  • Artifact summary
  • Extracted method
  • Reusable skill, playbook, or procedure
  • Usage boundaries
  • Step-by-step procedure
  • Quality standards
  • Failure modes
  • Second-case test
  • Revisions made after testing
  • Final reusable version

Match the method to the artifact

  • Prompt or workflow: preserve the sequence, checks, and escalation logic.
  • Page or memo: preserve the argument structure, evidence logic, and clarity standards.
  • Pull request or specification: preserve scope control, proof requirements, and handoff quality.
  • Research artifact: preserve source discipline, synthesis method, and conclusion thresholds.

Reviewer handoff

  • Original artifact: what it was and what it accomplished.
  • Why it worked: the decisions or method that made it strong.
  • What was extracted: the reusable skill, playbook, or procedure.
  • How it was tested: the fresh second case used for validation.
  • What changed: revisions made after the test.
  • Limits or follow-ups: where the method may not generalize.