* test(evals): scope claims to harness model fixtures and revision Append the neckbeard claims-scoping sentence to one representative expected_output per per-skill manifest so every corpus member states VAL-EVL-032 scope (harness, model, fixtures, revision under test). Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(product-lifecycle): upgrade integrated launch trajectory Add an explicit launch-decision assertion to the new-product lifecycle case so the integrated product-launch scenario terminates in a launch decision recorded as a lifecycle evidence-ledger entry (VAL-CRP-010), and scope its expected_output claims per VAL-EVL-032. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(production-excellence): add integrated migration reconciliation failure case Add integrated-migration-reconciliation-failure: the production-excellence gate model returns No-go on a reconciliation mismatch, records the failure evidence, produces a rollback/roll-forward decision with an accountable owner, and does not proceed to launch (VAL-CRP-012). Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(agent-production-operations): add privacy boundary escalation case Add integrated-privacy-boundary-escalation (VAL-CRP-015): the runtime control plan halts a cross-boundary EU PII trace export before any data processing, names the privacy boundary, and escalates to jurisdiction- specific legal review and a human operator. Also add a tool-authority- health handoff assertion to the read-only contract case (VAL-CRP-016). Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(lifecycle-evals): add lifecycle evaluation corpus Add the #204 corpus home: run tooling (run-corpus.sh, fake adapter only), programmatic coverage validator (validate-corpus-coverage.py), machine- readable coverage index + human-readable coverage matrix, regression- detection and fixture/source notes, the bounded discovery brief, and a one-snapshot committed set of fake-adapter per-trial run artifacts with harness/model/date scoping fields. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> --------- Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
Product Lifecycle Learning
Close the launch-to-learning loop — compare intended outcomes with what actually happened, update your assumptions with evidence, assess feature health, and make disciplined continue, improve, harvest, pivot, pause, or retire decisions. Includes full retirement lifecycles with deprecation, migration, customer treatment, and durable retained learning records.
Why Install This Skill
After you launch a feature, the work is not done — the learning starts. Teams ship features, watch dashboards for a few weeks, and then move on, never systematically closing the loop between what they expected and what actually happened. Assumptions that drove the original decision go unexamined. Features linger past their useful life because nobody owns the retirement decision. When features are retired, existing users are left without migration paths or clear communication.
This skill gives your agent a disciplined method for the entire post-launch learning cycle. It collects observed outcomes, compares them against what was expected, identifies gaps with explicit confidence intervals, updates the assumption ledger, assesses feature health across multiple dimensions, and makes one of six lifecycle decisions — continue, improve, harvest, pivot, pause, or retire. When the decision is retire, it covers the full retirement lifecycle: deprecation communication, migration paths, customer treatment during sunset, and internal cleanup.
Most importantly, every cycle produces a durable retained learning record — not a transient meeting summary, but an evidence-backed artifact that informs future roadmap, analytics, adoption, experimentation, and specification work. The loop actually closes.
What You Get
| Directory | Purpose |
|---|---|
| SKILL.md | Core methodology: launch-to-learning loop, epistemic discipline, lifecycle decisions, routing |
| references/discovery-brief.md | Bounded discovery: maps existing lifecycle and learning material, ownership boundaries |
| references/epistemic-discipline.md | Full taxonomy: expected, observed, uncertain, and inferred claim categories with field guide |
| references/retirement-lifecycle.md | Complete retirement lifecycle: deprecation, migration, customer treatment, internal cleanup |
| references/feedback-destinations.md | Routing guide for each downstream feedback destination |
| templates/outcome-review.md | Structured post-launch outcome review comparing expected vs. observed |
| templates/assumption-ledger-update.md | Assumption ledger update with confidence shifts |
| templates/feature-health-record.md | Multi-dimensional feature health assessment |
| templates/retirement-decision.md | Justified retirement or continuation decision record |
| templates/sunset-plan.md | Deprecation communication, migration, customer treatment, internal cleanup |
| templates/retained-learning-record.md | Durable reusable learning artifact |
Quick Start
Load SKILL.md for the methodology overview and loading guide, then load
specific references and templates as the situation demands. Start with
templates/outcome-review.md if you have a feature
that has been live long enough to produce data.
Triggers
- Reviewing post-launch outcomes for a feature or capability
- Comparing expected outcomes (from spec or roadmap) against observed data
- Updating assumptions based on new evidence from a live feature
- Assessing whether a feature is healthy, struggling, or ready for retirement
- Deciding whether to continue, improve, harvest, pivot, pause, or retire a feature
- Planning a feature retirement, deprecation, or sunset
- Designing migration paths and customer communication for retiring features
- Capturing durable learning from a completed feature lifecycle
- Closing the loop between launch evidence and roadmap/analytics/adoption/experimentation/specs
Requirements
No technical dependencies. Consumes data from product analytics, adoption metrics, experimentation results, and operational monitoring systems — but does not own any of those. Requires human judgment for retirement and lifecycle decisions; no automated thresholds are prescribed or applied.