Knowledge Funnel Demo

From broad migration research to a measured reusable system

This page explains the full process as executed: research intake, risk narrowing, skill design, helper-script implementation, transfer packaging, evaluation design, eval harness delivery, and the final documentation step that produced this static website and its Markdown companion.

7funnel stages
4eval cases
3transfer bundles
HTML + MDfinal narrative outputs

Funnel view

Each layer condensed the available information into a more focused and reusable artifact. The result is a process that is human-readable, machine-usable, and easy to re-enter later.

1. Research intake The starting domain covered migration behavior, dependency semantics, build backends, private indexes, operational command replacement, and rollback needs.
HTML source
2. Risk extraction The broad topic was reduced to a stable risk set: backend choice, lock strategy, groups versus extras, source mapping, and parity-before-cleanup.
Decision set
3. Migration contract The decision set became a staged workflow: audit, dry-run, apply, review, validate, then remove Poetry only after parity is demonstrated.
Skill + script
4. Transfer packaging The workflow was wrapped for reuse by another agent through a manifest and zipped handoff bundles.
JSON + ZIP
5. Eval design pivot The problem narrowed again: measure whether the skill improves planning quality, not just whether the files exist.
Design shift
6. Eval harness The final harness used the shared runner model, fixture projects, and assertion-based grading focused on the highest-risk migration choices.
TOML + JSON + MD
7. Explainability close-out This final static website and its Markdown copy close the loop by turning the full execution trail into one self-contained narrative.
HTML + MD

Sequenced execution

The phases below preserve the actual order of work while removing user-, host-, session-, and secret-specific details.

Phase 1research intake

The migration domain was mapped from a research source

The process started with a local research document about moving Poetry-managed projects to uv. That source was mined for hazards rather than treated as a direct rewrite recipe.

  • Preview the migration before editing files.
  • Preserve the current build backend for higher-risk packaged projects.
  • Treat dependency groups and extras as different concepts.
  • Review private source mappings manually.
  • Replace operational Poetry commands across docs, CI, Docker, and scripts.
  • Keep Poetry artifacts until runtime parity is proven.
Source

poetry-to-uv-migration-research-2026.html

Initial migration research input.

Cleaned doc

poetry-to-uv-migration-session-record.cleaned.md

Sanitized summary of the implementation session.

Result

Condensed risk map

Backend strategy, lock strategy, source mapping, groups and extras, operational sweep, and rollback became the durable decision set.

Phase 2skill design

The research became a reusable migration contract

The broad findings were distilled into a safe, repeatable operating contract for one project at a time.

  • Classify the project before choosing a migration path.
  • Make backend strategy explicit instead of implicit.
  • Preserve lock intent first for low-risk cutovers.
  • Validate behavior, not just file diffs.
Skill

SKILL.md

The staged migration contract.

Guide

README.md

Usage guide for the migration workflow.

Registry

Workspace registration docs

The skill was added to discovery material so it can be found and reused.

Phase 3script implementation

The contract became a runnable helper with rollback and reports

The migration workflow was encoded into a companion script so the cutover becomes inspectable and reversible. 

.apocrypha/poetry-to-uv/<run-id>/
  before-report.txt
  after-report.txt
  dry-run-output.txt | apply-output.txt
  managed-files.txt
  created-files.txt
  changes.diff
  backup/
Shell

migrate.sh

Implements dry-run, apply, and rollback.

Contract

Before and after evidence

Reports and diffs allow the migration to be reviewed before cleanup.

Discipline

Rollback-first operation

The workflow snapshots managed files before mutation and can restore them later.

Phase 4transfer packaging

The migration system was packaged for agent-to-agent handoff

After the skill and script existed, they were wrapped into portable bundles with metadata and transfer instructions.

JSON

poetry-to-uv-migration-agent-bundle.json

Manifest for identity, outputs, checksums, and handoff steps.

ZIP

poetry-to-uv-migration-skill.zip

Portable archive of the full migration skill.

ZIP

poetry-to-uv-migration-scripts.zip

Lean archive containing the helper script only.

Phase 5evaluation design pivot

The eval approach moved from imitation to the shared runner model

The first draft mirrored a working example, but the final design pivoted to the shared runner model so the workflow matches the supported long-term interface.

Earlier idea

Bespoke runner scaffold

Useful for understanding the example, but not the intended final shape.

Final shape

Shared runner CLI

iterate, validate, run, and grade became the stable interface.

Cleaned doc

poetry-to-uv-migration-eval-handoff.cleaned.md

Sanitized explanation of the evaluation design and final harness.

Phase 6eval harness delivery

The skill gained a repeatable, assertion-based eval suite

The final harness uses synthetic Poetry fixtures and grades migration plans against the skill's highest-risk decision points.

simple-app-dev-group

Checks dry-run-before-apply sequencing, operational Poetry sweep, validation steps, and delayed cleanup.

packaged-cli-private-index

Checks backend preservation, extras and entry points, source mapping, operational rewrites, and packaging validation.

monorepo-multi-package

Checks one-project-at-a-time scope control and avoids a blanket root-wide migration.

library-groups-dynamic-deps

Checks groups-versus-extras safety, locked-version preservation, dependency source risk, and publish-path validation.

evals/workspace/
  iteration-N/
    benchmark.json
    eval-*/with_skill/outputs/MIGRATION_PLAN.md
    eval-*/with_skill/grading.json
    eval-*/without_skill/...
Config

skill-eval.toml

Shared runner configuration for the suite and output artifact.

Wrapper

Makefile

Convenience targets for check, iterate, validate, run, and grade.

Suite

evals.json

Case definitions and assertions for the evaluation run.

Phase 7final documentation step

The execution trail was condensed into a clean static handoff

This final step reviewed the session record and eval handoff together, then rebuilt the path as one static HTML page plus one Markdown mirror. This phase is included here intentionally so the narrative ends at the current deliverable.

  • The website is self-contained and static.
  • The Markdown copy preserves the same sequence without presentation markup.
  • User-, host-, session-, and secret-specific details have been removed.
HTML

poetry-to-uv-migration-process-journey.html

This static website.

MD

poetry-to-uv-migration-process-journey.md

Markdown copy of the same narrative.

Bundle

Clean export folder

The final deliverable groups the website and cleaned supporting documents into one portable demo package.

Bundle contents

The cleaned bundle includes the website and Markdown documents below. The remaining items in this section are referenced artifact types or transfer bundles described by the narrative, not files included in this folder.

Website

  • index.html
  • poetry-to-uv-migration-process-journey.html
  • poetry-to-uv-migration-research-2026.html

Markdown documents

Referenced artifact types

  • SKILL.md
  • migrate.sh
  • skill-eval.toml
  • Makefile
  • evals.json

Transfer artifacts described

  • poetry-to-uv-migration-agent-bundle.json
  • poetry-to-uv-migration-skill.zip
  • poetry-to-uv-migration-scripts.zip
  • poetry-to-uv-migration-skill-eval-bundle.zip

Net result

The journey moved in a strict sequence: broad migration knowledge became a safety-focused workflow; the workflow became runnable; the runnable workflow became transferable; the transfer became measurable; and the measured system is now documented in one clean handoff.