mirror of
https://github.com/magnus919/agent-skills.git
synced 2026-09-15 05:26:28 +03:00
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>
48 lines
6.7 KiB
Markdown
48 lines
6.7 KiB
Markdown
# Specialist Route Selection
|
|
|
|
The stage lists in `manifest.yaml` are candidate routes, not an instruction to
|
|
load every listed skill. Load one primary specialist when its entry condition is
|
|
true. Add a secondary specialist only for a named blocker, risk, or handoff. If
|
|
one specialist fully owns the request, leave the FDE lifecycle and route the
|
|
bounded task directly.
|
|
|
|
| Stage | Candidate | Load only when | Do not load when |
|
|
|---|---|---|---|
|
|
| Discover | [product-discovery](../../product-discovery/SKILL.md) | The user, workflow, problem, outcome, or stakeholder interpretation is unvalidated | The problem and acceptance boundary are already explicit |
|
|
| Discover | [data-engineering](../../data-engineering/SKILL.md) | Discovery depends on data sources, contracts, quality, lineage, or pipeline feasibility | Data is incidental to the workflow question |
|
|
| Discover | [remote-systems-administration](../../remote-systems-administration/SKILL.md) | Relevant evidence or action sits behind remote access, privilege, egress, bastion, or recovery constraints | No remote or constrained system is involved |
|
|
| Frame | [product-design-and-ux](../../product-design-and-ux/SKILL.md) | The frame depends on user journeys, interaction behavior, service experience, or usability constraints | The work has no user-facing or workflow-experience question |
|
|
| Frame | [privacy-engineering](../../privacy-engineering/SKILL.md) | The frame includes personal data, consent, retention, disclosure, or privacy rights | No privacy-relevant data or processing is in scope |
|
|
| Frame | [secure-software-engineering](../../secure-software-engineering/SKILL.md) | The frame requires threat, trust-boundary, authentication, authorization, or secure-design decisions | Security is not a material part of the proposed intervention |
|
|
| Hypothesize | [product-experimentation](../../product-experimentation/SKILL.md) | The intervention needs a causal or comparative product/workflow experiment | The hypothesis is verified through engineering acceptance rather than an experiment |
|
|
| Hypothesize | [agent-evals-and-observability](../../agent-evals-and-observability/SKILL.md) | An agent, LLM, model, or nondeterministic workflow needs a decision/risk contract and evaluation plan | The capability is deterministic and ordinary test methods are sufficient |
|
|
| Build | [implementation-planning](../../implementation-planning/SKILL.md) | An authorized decision-maker has approved the requirement or specification and a dependency-aware delivery plan is needed | The requirement is not approved; stop and return upstream |
|
|
| Build | [backend-engineering](../../backend-engineering/SKILL.md) | The approved slice requires backend service or API implementation | No backend component is in scope |
|
|
| Build | [frontend-engineering](../../frontend-engineering/SKILL.md) | The approved slice requires a web frontend or client implementation | No frontend component is in scope |
|
|
| Build | [data-engineering](../../data-engineering/SKILL.md) | The approved slice requires data pipelines, contracts, storage, or transformation | Data work is not part of the implementation |
|
|
| Evaluate | [agent-evals-and-observability](../../agent-evals-and-observability/SKILL.md) | Agent, LLM, model, or nondeterministic behavior needs representative, adversarial, trajectory, or production-feedback evaluation | Ordinary deterministic verification is sufficient |
|
|
| Evaluate | [qa-methodology](../../qa-methodology/SKILL.md) | A risk-scaled test strategy or coverage model is needed | Acceptance criteria can be verified directly without a broader QA design |
|
|
| Evaluate | [verification-methodology](../../verification-methodology/SKILL.md) | Explicit acceptance criteria need direct pass/fail evidence | Criteria are not yet defined; return to framing or hypothesis work |
|
|
| Deploy | [production-readiness](../../production-readiness/SKILL.md) | A production or high-impact release needs a risk-scaled readiness verdict | The change is not crossing a production-like boundary |
|
|
| Deploy | [release-engineering](../../release-engineering/SKILL.md) | Release mechanics, versioning, promotion, rollback, or delivery automation are needed | No release artifact or promotion path exists |
|
|
| Deploy | [platform-engineering](../../platform-engineering/SKILL.md) | Deployment is blocked on an internal platform capability or platform-owned interface | The engagement itself is ongoing platform ownership; route directly instead |
|
|
| Deploy | [remote-systems-administration](../../remote-systems-administration/SKILL.md) | Deployment occurs through a constrained remote access or recovery path | The environment is local and unconstrained |
|
|
| Adopt | [product-adoption](../../product-adoption/SKILL.md) | Activation, onboarding, feature discovery, behavior change, or sustained use is below the decision rule | Intended workflow adoption is already evidenced |
|
|
| Adopt | [product-design-and-ux](../../product-design-and-ux/SKILL.md) | Adoption evidence points to usability or workflow-experience friction | The barrier is access, support, incentive, or ownership rather than UX |
|
|
| Measure | [product-analytics-and-measurement](../../product-analytics-and-measurement/SKILL.md) | Outcome metrics, instrumentation, events, funnels, cohorts, or governance are needed | Existing measurement evidence already answers the decision rule |
|
|
| Measure | [agent-evals-and-observability](../../agent-evals-and-observability/SKILL.md) | Model or agent quality needs production feedback and evaluation drift evidence | No agentic or nondeterministic component exists |
|
|
| Measure | [site-reliability-engineering](../../site-reliability-engineering/SKILL.md) | Reliability is an agreed outcome or a blocker to workflow impact | The request is ongoing SRE ownership; route directly instead |
|
|
| Generalize | [product-lifecycle-learning](../../product-lifecycle-learning/SKILL.md) | Expected and observed outcomes must be compared to choose continue, improve, pivot, pause, or retire | There is no post-launch evidence to compare |
|
|
| Generalize | [product-methodology](../../product-methodology/SKILL.md) | A bounded classification, prioritization, or decision log is needed for the local pattern | The question is portfolio investment or full product lifecycle governance |
|
|
|
|
## Approval boundaries
|
|
|
|
- `implementation-planning` is never a pre-approval route. A hypothesis,
|
|
prototype, or promising field pattern is not an approved requirement.
|
|
- `product-operations-and-governance` is not a Frame-stage route for a single
|
|
engagement decision. Load it only outside this bundle when the request is to
|
|
design a recurring governance system.
|
|
- A Generalize-stage classification may hand an approved requirement to
|
|
`implementation-planning` as the next owner's work. The planning skill is not
|
|
part of the Generalize decision itself.
|