← Claus Argos Skill OSCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Claus Argos Skill OS
Snapshot Sep 30, 2026 · 23:14 UTC · version 1.16.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Transform an existing codebase through a controlled refactor, framework or platform migration, architecture transition, dependency replacement, or legacy modernization while preserving explicit invariants, salvageable value, compatibility, evidence, and rollback. Use when structural transformation is the primary task. Do not use for a small feature, an isolated defect, routine cleanup, or speculative rewrite without an approved migration objective.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 320
}
],
"name": "refactor-and-migrate-codebases",
"skill_md_contents": "---\nname: refactor-and-migrate-codebases\ndescription: Transform an existing codebase through a controlled refactor, framework or platform migration, architecture transition, dependency replacement, or legacy modernization while preserving explicit invariants, salvageable value, compatibility, evidence, and rollback. Use when structural transformation is the primary task. Do not use for a small feature, an isolated defect, routine cleanup, or speculative rewrite without an approved migration objective.\n---\n\n# Refactor and Migrate Codebases\n\nTransform structure without blindly rebuilding valuable legacy behavior or carrying defects forward.\n\n## Establish migration authority\n\n1. Inspect the real repository, architecture, runtime, deployment, tests, data, interfaces, dependencies, operational constraints, and migration specification.\n2. Define the approved before/after boundary, invariants, compatibility obligations, downtime or rollout constraints, protected behavior, success metrics, and rollback point.\n3. Use the shared [decision-authority model](../../shared/expert-system/decision-authority-model.md). Framework, architecture, data semantics, public interfaces, security, product behavior, and deletion are Class 1 unless already authorized.\n4. Route architecture, domain, migration, data, testing, release, security, and independent review roles only as required.\n\nStop when the target architecture, migration scope, data authority, compatibility policy, or rollback path is unresolved.\n\n## Salvage matrix\n\nClassify every relevant element as:\n\n- `KEEP` — retain unchanged and protect with regression evidence.\n- `ADAPT` — preserve purpose while changing implementation.\n- `REPLACE` — substitute through an approved target and compatibility plan.\n- `DELETE` — remove only with explicit authority and dependency proof.\n- `HISTORICAL` — preserve for traceability but do not execute.\n\nFor each record reason, evidence, dependencies, consumers, compatibility, migration action, test, rollback, and owner. A weaker replacement must not win merely because it is newer.\n\n## Migration design and execution\n\n- Choose big-bang, strangler, parallel run, branch-by-abstraction, dual write/read, compatibility adapter, or another strategy from actual risk and constraints; label an unapproved choice as proposed.\n- Define phase entry/exit gates, data and schema migration, backfill, version skew, feature flags, observability, rollback, and old-path retirement.\n- Establish baseline behavior and performance before structural edits.\n- Execute in reversible slices with explicit checkpoints and source-control recovery.\n- Preserve public contracts unless the approved migration changes them.\n- Do not combine unrelated cleanup with migration work.\n\n## Verification\n\nProve required equivalence or intentional difference through unit, integration, contract, end-to-end, migration, data-integrity, performance, security, deployment, and rollback tests as applicable. Compare old and new paths using deterministic fixtures or shadow evidence when feasible. Run independent architecture and release review for material migrations.\n\nCorrect compliance with a defective target architecture is not success. Stop and escalate when the proposed target is demonstrably weaker, incompatible, or operationally unsafe.\n\n## Output\n\nReturn the salvage matrix, phased migration plan, implemented slices, compatibility and data evidence, test results, deviations, retired and preserved elements, rollback procedure, independent review, unresolved risks, and next gate.\n"
}SHA-256 of public snapshot: e57f5f02c88c5a01d75ecfc08c297b8f815636db5092c5c1c8fb6dbb19b595a0