mirror of
https://github.com/magnus919/agent-skills.git
synced 2026-09-11 19:47:12 +03:00
aa893e3ec2
* feat(bundles): add bundle manifest schema, manifests, and validation (#203) Introduce a machine-readable composition contract for canonical bundles: purpose, audience, stages, included skills, prerequisites, outputs, handoffs, conflicts, and eval suite (schemas/bundle-manifest-v1.schema.json, following the evals-v1 versioned-schema convention). Ship the bounded design note (docs/bundle-manifest-design.md), a schema-conformant example, canonical manifests for the three new milestone bundles, and a stdlib-only validator (scripts/validate-bundles.rb) that rejects incomplete, contradictory, and undeclared-overlapping manifests while keeping bundles an optional layer. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * feat(bundles): add lifecycle capability matrix generator and validators (#203) Add scripts/gen-lifecycle-matrix.rb, which deterministically produces the human-readable docs/lifecycle-capability-matrix.md (one row per canonical bundle) and the machine-readable docs/lifecycle-capability-matrix.json (with per-cell source provenance) reusing the gen-*.rb conventions. Add scripts/validate-lifecycle-matrix.rb to check bundle coverage, cell traceability, artifact currency, and catalog-exactness of nested bundle helpers. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(bundles): add bundle manifest validation tests (#203) Add scripts/test-validate-bundles.rb covering schema conformance of the committed example, valid-manifest and declared-conflict positives, per-field incomplete-manifest rejections, contradictory-manifest rejections (missing skill, undeclared handoff artifact, non-catalog conflict), undeclared-overlap rejection naming both manifests, and matrix generator/validator completeness and drift detection. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * ci(bundles): wire bundle manifest validation into the gate (#203) Add validate-bundles.rb, test-validate-bundles.rb, the lifecycle matrix generator check, and the matrix validator to .github/workflows/validate.yml alongside the existing validator steps. 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>
12 KiB
12 KiB
name, description, license, compatibility, metadata
| name | description | license | compatibility | metadata | ||||
|---|---|---|---|---|---|---|---|---|
| product-lifecycle | Route a product through its full lifecycle — discovery, strategy, portfolio choice, roadmap, UX and requirements, experimentation, delivery handoff, adoption, success, and lifecycle review — by composing existing specialist product skills with phase-entry evidence, handoff artifacts, and escalation rules. Use when evaluating a new product idea, managing a product through its lifecycle, or connecting product phases that currently operate in isolation. Do not use for a single product task that is already owned by a specialist skill (load that skill directly); do not use for software delivery lifecycle work (route to neckbeard); do not use to duplicate product discovery, strategy, UX, experimentation, analytics, release, or delivery methods. | MIT | Agent harness with file read/write, terminal, and skill loading. No network or runtime dependency required by the bundle itself. |
|
Product Lifecycle
A thin orchestration bundle that routes a product through nine lifecycle phases by composing existing specialist product skills. It provides cross-skill routing and evidence handoff — it does NOT duplicate any specialist's step-by-step methodology. Load this umbrella when you need to navigate a product across multiple lifecycle phases; load individual specialist skills directly when you only need one phase's capability.
Phase routing table
Each phase routes to one or more specialist skills. Entry evidence must exist before the phase starts. Output artifacts are handed off to the next phase through the lifecycle evidence ledger. Every phase has explicit escalation behavior and completion criteria. Full phase contracts are in references/phases.md.
| # | Phase | Primary specialist(s) | Entry evidence | Output artifacts | Escalation behavior | Completion criteria |
|---|---|---|---|---|---|---|
| 1 | Discovery | product-discovery | Product idea, market signal, or stakeholder request | Problem statement, stakeholder map, discovery log, product type classification | Stop if: problem cannot be articulated in user terms; no stakeholder describes a real need; problem is already solved; out of organizational remit | Problem statement exists that a stakeholder recognizes; product type classified; proceed/pause/stop decision recorded |
| 2 | Strategy and portfolio choice | product-strategy, strategy-frameworks | Problem statement and discovery log from Phase 1 | Strategic assessment, market sizing, portfolio recommendation, investment thesis | Stop if: opportunity conflicts with strategy; market evidence contradicts thesis; resource constraints are infeasible; strategic direction is ambiguous | Strategic assessment with fit/no-fit reasoning; portfolio decision recorded; resource estimate recorded |
| 3 | Roadmap | product-roadmapping-and-portfolio | Strategic assessment and portfolio decision from Phase 2 | Outcome roadmap entry, Now/Next/Later placement, strategic bet record, dependency map, capacity allocation | Stop if: dependencies cannot be resolved; capacity unavailable; confidence below threshold; conflicts with higher-priority bet | Roadmap entry exists; bet record complete with kill criteria; dependencies mapped and acknowledged |
| 4 | UX and requirements | product-design-and-ux | Roadmap entry and bet record from Phase 3; discovery log | Information architecture, task flows, interface contracts, acceptance criteria | Stop if: UX reveals fundamentally different problem; user research contradicts hypothesis; behavior cannot be specified testably; constraints cannot be satisfied | IA and task flows documented; interface contracts exist; acceptance criteria are testable and traceable |
| 5 | Experimentation | product-experimentation | UX contracts, assumptions register, risk assessment | Experiment brief, experiment readout, updated assumptions register, proceed/pivot/stop decision | Stop if: experiment cannot be designed ethically; method infeasible; reveals safety/privacy/security risk; hypothesis disproved with no viable pivot | Experiment brief exists with hypothesis and decision rule; readout exists; proceed/pivot/stop decision recorded with evidence |
| 6 | Delivery handoff | implementation-planning, production-readiness, release-engineering | Proceed decision, UX contracts, acceptance criteria, assumptions register | Implementation plan, formal spec, production-readiness verdict (Go/No-go/Defer/Exception), release plan | Stop if: infeasible dependency; readiness returns No-go or blocked Exception; security/privacy/compliance blocks launch; release plan cannot satisfy change-governance | Implementation plan accepted by delivery team; readiness verdict recorded with evidence; release plan documented and reviewed |
| 7 | Adoption | product-adoption | Launch decision (Go), release evidence, target segments, success metrics | Adoption plan, activation baseline, segmentation record, adoption metrics | Stop if: adoption materially below threshold after intervention; fundamental product-market mismatch; structural adoption problem beyond product changes | Adoption plan executed; activation and adoption baselines measured; proceed/intervene/pivot/stop decision recorded |
| 8 | Success | product-analytics-and-measurement | Adoption evidence, success criteria, experiment readouts | Outcome measurement, metric tree with actuals vs. targets, success/mixed/not-met assessment | Stop if: outcomes materially below expectations with unknown root cause; measurement infrastructure insufficient; evidence contradicts investment thesis | Outcome metrics measured against criteria; success assessment recorded; ledger complete for review |
| 9 | Lifecycle review | product-lifecycle-learning | Outcome measurement, full evidence ledger, original assumptions register | Outcome review (expected vs. observed), assumption ledger update, continue/improve/harvest/pivot/pause/retire decision, retained learning record | Stop if: retirement has material implications beyond team authority; retained learning contradicts foundational assumption; systemic pattern requires executive attention | Outcome review recorded; lifecycle decision recorded with rationale; retained learning captured; ledger closed |
Supporting and cross-cutting skills
These skills are loaded on trigger, not by phase. They support multiple phases and are routed to when their specific capability is needed.
| Skill | When loaded |
|---|---|
| product-methodology | When a phase produces alternatives that need ranking (RICE, MoSCoW, Kano, OST) |
| product-operations-and-governance | When setting up or changing governance; at phase boundaries needing formal decision authority |
| financial-modeling | When unit economics, pricing, or business-model analysis is needed (Phases 2, 8) |
| go-to-market | When positioning, acquisition strategy, or growth modeling is needed (Phases 7, 8) |
| data-scientist | When statistical design, causal inference, or rigorous experiment analysis is needed (Phases 5, 8) |
| spec-driven-development | When formal specification with phase gates is needed (Phase 6) |
| privacy-engineering | When any phase handles PII, consent, retention, or data flows |
| secure-software-engineering | When any phase touches trust boundaries, auth, or sensitive data |
| verification-methodology | At every phase gate where evidence is required |
| qa-methodology | When test strategy and quality gates are needed (Phase 6) |
| site-reliability-engineering | When reliability, SLOs, or operational readiness is needed (Phase 6) |
| platform-engineering | When infrastructure, CI/CD, or platform capabilities are needed (Phase 6) |
| neckbeard | When the software delivery lifecycle (SDLC) change-request journey is needed for implementation (Phase 6) |
production-excellence bundle (when available) |
When the full production-excellence bundle is available as a handoff target (Phase 6) — composes production-readiness, migration-engineering, resilience-and-recovery, capacity-and-cost-engineering, and incident-learning |
Loading protocol
This umbrella is the guaranteed discoverable entry point. Nested skills and referenced specialists load on trigger — the umbrella does not pre-load them.
- Read this SKILL.md for the phase routing table and locate the current phase.
- Load the phase contract from references/phases.md for detailed entry evidence, escalation behavior, and completion criteria.
- Load the specialist skill(s) named in the phase row. Follow the specialist's method; do not re-derive it from the umbrella.
- Write phase outputs to the lifecycle evidence ledger (see references/phases.md for ledger fields and conventions).
- The next phase reads the ledger; it does not re-derive prior-phase evidence.
- When the lifecycle completes or stops, the ledger is the durable record.
For capability lookup without traversing the full lifecycle, use the references/capability-map.md.
When not to use
- Single specialist task. If the work is entirely within one phase (e.g., a stakeholder interview, an experiment design, a roadmap update), load the specialist skill directly. The umbrella adds orchestration overhead that is unnecessary for single-phase work.
- Software delivery lifecycle. If the work is a code change, bug fix, or feature implementation — not product-level decision-making — route to neckbeard.
- Duplicate methodology. This bundle does NOT duplicate product-discovery, product-strategy, product-design-and-ux, product-experimentation, product-analytics-and-measurement, or release-engineering methods. Load those skills directly for their step-by-step instructions.
- B2B SaaS assumption. This bundle does NOT assume a B2B SaaS product. Customer-success routing (Phase 8) is CONDITIONAL on product type. Internal tools, public-service products, transactional products, and consumer products proceed without loading conditional-customer-success.
- Strategic frameworks. For standalone strategic analysis (Five Forces, Blue Ocean, Ansoff) without a lifecycle context, load strategy-frameworks directly.
- Financial modeling. For standalone financial analysis without a lifecycle context, load financial-modeling directly.
File map
| Path | Loaded when |
|---|---|
| references/phases.md | Entering any lifecycle phase; defines entry evidence, output artifacts, escalation behavior, and completion criteria per phase |
| references/discovery-brief.md | Understanding the bundle boundary and how it compares to existing bundles |
| references/capability-map.md | Looking up which specialist skill owns a specific capability without traversing the full lifecycle |
| manifest.yaml | Machine-readable composition contract (schema v1): purpose, audience, stages, included skills, prerequisites, outputs, handoffs, conflicts, and eval suite; consumed by the lifecycle capability matrix |