Magnus Hedemarkandfactory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
a315b77bd8
Re-point relative references inside the six non-tailscale/workflow-architect
bundle dirs now that they live one level shallower at the repo root:
- bundle-root SKILL.md/manifest.yaml/README.md: ../../<target> -> ../<target>,
cross-bundle ../../bundles/<x> -> ../<x>
- forward-deployed-engineering references/: ../../../<target> -> ../../<target>
- product-lifecycle references cross-bundle ../../bundles/neckbeard -> ../../neckbeard
- product-lifecycle references/discovery-brief.md prose headings drop bundles/ prefix
- neckbeard eval shell commands bundles/neckbeard/eval -> neckbeard/eval
- production-excellence AGENTS.md depth note updated
- manifest header comments point at ../schemas/bundle-manifest-v1.schema.json
- regenerate docs/lifecycle-capability-matrix.{md,json}
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
1.9 KiB
Generalization and Productization
Local work earns a broader life through evidence, not novelty. At closeout, classify the result and name an owner, reuse boundary, evidence, next action, and review date.
| Classification | Use when | Required next action |
|---|---|---|
| Configuration | Existing capability and workflow are sufficient for one context | Document configuration, limits, and transfer notes |
| Reusable pattern | The workflow or implementation repeats with bounded adaptation | Package a playbook, template, or building block and test it elsewhere |
| Product capability | Multiple contexts share a stable need and supported contract | Product owner accepts scope, maintenance, support, and roadmap decision |
| Transfer/replacement | Another team or existing capability should own the outcome | Handoff owner, acceptance evidence, support boundary, and decommission plan |
| Retirement | Value, safety, feasibility, or ownership no longer justifies continuation | Communicate impact, preserve learning, and close or decommission safely |
Do not promote a local configuration to a product capability because it worked once. Look for repeated need, transferable constraints, support economics, security/privacy fit, measurable benefit, and a willing receiving owner. If those are absent, keep the work local or classify it for transfer or retirement.
The productization record must distinguish engagement observations from the inference that a pattern generalizes, the recommendation, the authorized decision, and the commitment to implement or transfer it. Return reusable patterns and negative learning to the appropriate product, platform, research, or deployment owner without bypassing their authority. A classification is not an implementation approval: route to implementation-planning only after the receiving owner approves a requirement or specification.