Add forward-deployed-engineering bundle (#292)

* feat: add forward deployed engineering bundle

* fix: close FDE bundle review findings
This commit is contained in:
Magnus Hedemark
2026-08-06 00:37:47 -04:00
committed by GitHub
parent eadb82e069
commit a4db8e7d43
29 changed files with 1636 additions and 0 deletions
+9
View File
@@ -365,6 +365,15 @@
"strict": false,
"description": "Use when managing a Forgejo or Gitea server from the terminal: issues, pull requests, repositories, file contents, labels, milestones, releases, webhooks, user settings, or any /api/v1 endpoint through a safe generic API command."
},
{
"name": "forward-deployed-engineering",
"source": "./",
"skills": [
"./forward-deployed-engineering"
],
"strict": false,
"description": "Guide embedded technical engagements from ambiguous stakeholder need through discovery, framing, hypothesis, build, evaluation, deployment, adoption, measurement, and generalization while preserving evidence, decision rights, and field learning. Use when one accountable technical lead must carry continuity across customer or stakeholder discovery, implementation, production fit, adoption, and measurable outcomes. Do not use for a bounded repository change, product investment governance, ongoing reliability or platform ownership, an isolated specialist task, or advisory work that ends before implementation and adoption."
},
{
"name": "frontend-engineering",
"source": "./",
+1
View File
@@ -29,6 +29,7 @@
"./binary-analysis",
"./brand-designer",
"./bundles/agent-production-operations",
"./bundles/forward-deployed-engineering",
"./bundles/neckbeard",
"./bundles/product-lifecycle",
"./bundles/production-excellence",
+4
View File
@@ -168,6 +168,10 @@ Use a small FlareSolverr JSON CLI for browser-backed GET and POST requests, read
Safe Forgejo API v1 CLI for issues, pull requests, repositories, file contents, metadata, webhooks, and user settings. Includes a guarded generic `/api/v1/` route for version-specific endpoints such as Actions and admin APIs.
### [forward-deployed-engineering](bundles/forward-deployed-engineering/SKILL.md)
Carry an embedded technical engagement from an ambiguous need to an adopted, measurable capability and a deliberate generalization decision across discovery, build, deployment, adoption, and field learning.
### [frontend-engineering](frontend-engineering/SKILL.md)
Build and maintain web frontends — component architecture, state management, API integration, responsive layout, client-side performance, and frontend testing patterns. Framework agnostic, focused on web frontend implementation. Do not use for backend service implementation, data engineering, or platform infrastructure work.
@@ -0,0 +1,17 @@
# AGENTS.md — Forward-Deployed Engineering Bundle
This is a thin orchestration bundle for embedded technical engagements. Its
umbrella `SKILL.md` owns continuity, artifacts, decision rights, adoption,
measurement, and generalization; routed catalog skills own specialist methods.
- Load the umbrella first, treat manifest stage skills as candidates, apply
`references/route-selection.md`, and load one primary specialist.
- Add a secondary specialist only for a named blocker, risk, or handoff.
- Keep the charter, workflow map, assumptions-decisions-risks ledger, and
evidence labels current across every handoff.
- Do not load nested helper skills; all routes point to top-level catalog skills
or existing canonical bundles.
- Stop and escalate when an action exceeds authority or the evidence required by
the current decision rule is missing.
- Keep artifacts private by default and complete the external-sharing gate before
anything leaves the authorized engagement context.
@@ -0,0 +1,63 @@
# forward-deployed-engineering
Carry an embedded technical engagement from an ambiguous need to an adopted,
measurable capability and a deliberate generalization decision.
## Why Install This Skill
This bundle is designed to guard against continuity risks between disciplines:
discovery that leaves builders without usable context, prototypes mistaken for
production systems, deployments declared complete without adoption, and field
patterns transferred without evidence or an accountable receiving owner. It
gives an accountable lead a durable contract across those boundaries.
After installation, an agent can frame the engagement and decision rights,
route specialist work without duplicating it, preserve assumptions and risks,
diagnose adoption and outcome gaps, and decide whether local work should remain
configuration, become reusable, transfer to another owner, or be retired.
## What You Get
| Path | What it provides |
|---|---|
| `SKILL.md` | Lifecycle trigger, boundary, loading protocol, stop rules, and file map |
| `manifest.yaml` | Machine-readable stages, routed skills, outputs, handoffs, and conflicts |
| `references/discovery-brief.md` | Overlap audit, source decisions, and design-risk rationale |
| `references/source-index.md` | Recoverable primary sources, supported claims, limitations, and refresh rules |
| `references/lifecycle-and-artifacts.md` | Stage contracts and continuity artifacts |
| `references/route-selection.md` | Per-stage specialist entry conditions and direct-routing boundaries |
| `references/authority-and-escalation.md` | Decision rights, constrained-environment discovery, and escalation rules |
| `references/adoption-and-measurement.md` | Adoption diagnosis, outcome evidence, and applied-AI release evidence |
| `references/generalization-and-productization.md` | Classification and productization decision model |
| `references/communication.md` | Evidence-labeled status, handoff, and escalation patterns |
| `templates/` | Ten templates matching the declared continuity, decision, handoff, measurement, and learning outputs |
| `evals/evals.json` | Fifteen output-quality cases covering lifecycle, authority, and adjacent-skill boundaries |
## Quick Start
1. Load `SKILL.md` and create `templates/engagement-charter.md`.
2. Record the stakeholder workflow and unknowns before proposing architecture.
3. Treat `manifest.yaml` stage skills as candidates and apply
`references/route-selection.md` before loading one primary specialist.
4. Carry the ledger through deployment, adoption, measurement, and generalization.
## Triggers
- An embedded technical lead must own discovery through production adoption.
- A stakeholder request is ambiguous and implementation context must be discovered.
- A prototype must become a verified, deployed, adopted capability.
- An applied-AI engagement needs eval-driven release and field feedback.
- A local configuration or workflow may warrant a reusable pattern or product capability.
- Adoption, workflow impact, and field learning must remain connected to delivery.
Do not trigger for a bounded repository bug, standalone specialist task, product
portfolio governance, ongoing SRE ownership, platform operation, or advisory
work that ends before implementation and adoption.
## Requirements
- No API keys, services, or network dependencies.
- Compatible with Agent Skills harnesses that support file reading, writing, and skill loading.
- Routed catalog skills must be installed, including discovery, evaluation,
production readiness, deployment, adoption, measurement, security, privacy,
and constrained-environment specialists.
@@ -0,0 +1,117 @@
---
name: forward-deployed-engineering
description: >-
Guide embedded technical engagements from ambiguous stakeholder need through
discovery, framing, hypothesis, build, evaluation, deployment, adoption,
measurement, and generalization while preserving evidence, decision rights,
and field learning. Use when one accountable technical lead must carry
continuity across customer or stakeholder discovery, implementation,
production fit, adoption, and measurable outcomes. Do not use for a bounded
repository change, product investment governance, ongoing reliability or
platform ownership, an isolated specialist task, or advisory work that ends
before implementation and adoption.
license: MIT
compatibility: Agent harness with file read/write, terminal, and skill loading. No network or runtime dependency required by the bundle itself.
metadata:
spec-version: "1.0"
tags: forward-deployed-engineering, embedded-delivery, adoption, measurement, generalization
---
# Forward-Deployed Engineering
Use this bundle when the work is an embedded technical engagement whose success
depends on continuity, not merely a recommendation or a code change. This is a
normative operating model synthesized from the role observations in
[source-index.md](references/source-index.md) and from routed specialist
methods; the nine-stage sequence is not an externally standardized methodology.
## Lifecycle
`Discover → Frame → Hypothesize → Build → Evaluate → Deploy → Adopt → Measure → Generalize`
At every stage, maintain one [engagement charter](templates/engagement-charter.md),
one [stakeholder/workflow map](templates/stakeholder-workflow-map.md), and one
[assumptions-decisions-risks ledger](templates/assumptions-decisions-risks-ledger.md).
Each stage records entry evidence, the artifact produced, the accountable
decision maker, unresolved unknowns, and the next handoff. Never silently turn
an observation into a requirement, a prototype into a production claim, or a
local success into a reusable product capability.
## Loading protocol
1. Establish the charter before solution design: problem, users, workflow,
outcome, scope, authority, constraints, success measure, and stop conditions.
2. Load [lifecycle and artifacts](references/lifecycle-and-artifacts.md) and
update the shared ledger after every stage.
3. Treat the stage skills in `manifest.yaml` as candidates. Apply the
[route-selection conditions](references/route-selection.md), load one primary
specialist, and follow its method rather than copying it into this bundle.
4. Before action in a constrained or sensitive environment, load
[authority and escalation](references/authority-and-escalation.md) and route
access, security, privacy, irreversible, cost, and external-commitment
decisions to their authorized owner.
5. Before calling applied AI or any risky capability production-ready, load the
evaluation specialist and require baseline, representative and adversarial
evidence, constraints, and a release decision.
6. Treat adoption and measured workflow impact as completion conditions, not
postscript communications. Use [adoption and measurement](references/adoption-and-measurement.md).
7. Apply the classification rules in [generalization and
productization](references/generalization-and-productization.md), then close
with the [productization record](templates/productization-record.md). Classify
local work as configuration, reusable pattern, product capability,
transfer/replacement, or retirement, with evidence and an owner.
8. Treat artifacts as private by default and apply the [external-sharing
gate](references/communication.md#external-sharing-gate) before they leave
the authorized engagement context.
Load only the primary specialist for the active stage. Add a secondary
specialist only for a named blocker, risk, or handoff; do not preload every
skill in the manifest. If one specialist fully owns the request, stop routing
and hand the task to that specialist instead of running the FDE lifecycle.
## Epistemic and communication contract
Label each material statement as one of: **source fact**, **engagement
observation**, **inference**, **recommendation**, **decision**, or
**commitment**. Use the [communication reference](references/communication.md)
for concise status and escalation updates. The [discovery brief](references/discovery-brief.md)
records the overlap audit and source limitations.
## Completion and stop rules
The engagement is complete only when the capability is technically verified,
deployed within the authorized boundary, adopted by the intended workflow,
measured against an agreed outcome, and its learning has a generalization
decision. A prototype, demo, or stakeholder approval alone is not completion.
Stop and preserve the ledger when the problem cannot be articulated, authority
or access is missing, evidence fails, adoption remains unexplained or below the
decision rule, or the next action exceeds the charter. Escalate rather than
guess on security, privacy, irreversible changes, material cost, external
commitments, or business authority. Route a well-specified repository bug
directly to [neckbeard](../../bundles/neckbeard/SKILL.md) and the relevant
specialist instead of invoking this lifecycle.
## When not to use
- Use [neckbeard](../../bundles/neckbeard/SKILL.md) for a well-bounded repository change.
- Use [product-lifecycle](../../bundles/product-lifecycle/SKILL.md) for product investment and lifecycle governance.
- Use [site-reliability-engineering](../../site-reliability-engineering/SKILL.md) for ongoing reliability ownership.
- Use [platform-engineering](../../platform-engineering/SKILL.md) for internal platform design or operation.
- Load a single specialist directly when one discipline fully owns the task.
- Do not use for advisory analysis that ends before implementation, adoption, and outcome continuity.
## File map
| Path | Load when |
|---|---|
| [references/discovery-brief.md](references/discovery-brief.md) | Reviewing the boundary, overlap audit, or evidence basis |
| [references/source-index.md](references/source-index.md) | Checking an externally verifiable role claim or refresh date |
| [references/lifecycle-and-artifacts.md](references/lifecycle-and-artifacts.md) | Starting or handing off any lifecycle stage |
| [references/route-selection.md](references/route-selection.md) | Selecting one stage specialist without violating its entry boundary |
| [references/authority-and-escalation.md](references/authority-and-escalation.md) | Working under access, security, privacy, cost, or authority constraints |
| [references/adoption-and-measurement.md](references/adoption-and-measurement.md) | Evaluating activation, workflow adoption, and measurable impact |
| [references/generalization-and-productization.md](references/generalization-and-productization.md) | Deciding what field work becomes or does not become reusable |
| [references/communication.md](references/communication.md) | Writing status, decision, escalation, or handoff communication |
| [templates/](templates/) | Creating the charter, maps, ledgers, scorecards, status, or productization record |
| [manifest.yaml](manifest.yaml) | Reading machine-readable stages, routes, outputs, and conflicts |
@@ -0,0 +1,167 @@
{
"schema_version": 1,
"skill_name": "forward-deployed-engineering",
"evals": [
{
"id": "ambiguous-request-discovery-first",
"prompt": "A sponsor says, 'Add AI to our operations.' Three teams describe different pain points and nobody has supplied a workflow, baseline, scope, or success measure. Decide what the embedded technical lead should do next.",
"expected_output": "The response starts with stakeholder and workflow discovery, records competing interpretations and unknowns, creates an engagement charter or equivalent framing record, and refuses to design architecture or commit to implementation before a recognized problem and decision authority exist.",
"assertions": [
"Identifies the missing workflow, user problem, outcome, scope, and authority as discovery gaps",
"Produces a draft charter, stakeholder/workflow map, and unknowns ledger with named fields before architecture",
"Separates observed stakeholder statements from inferences and recommendations",
"Defines a stop condition if discovery cannot converge on a recognizable problem"
]
},
{
"id": "constrained-environment-before-action",
"prompt": "Deploy a diagnostic capability into a constrained environment with unclear account permissions, network egress, maintenance windows, recovery access, and verification procedures. The sponsor wants it installed today.",
"expected_output": "The response performs read-only discovery first, records access route, privilege, egress, change window, rollback/recovery, and external-boundary verification, then seeks the authorized decision before installation.",
"assertions": [
"Lists access, privilege, egress, change window, rollback or recovery, and verification as pre-action evidence",
"Does not treat sponsor urgency as authorization",
"Names the system, security, or change owner needed for missing authority",
"Preserves safe read-only discovery while the action is blocked"
]
},
{
"id": "applied-ai-release-evidence",
"prompt": "An LLM workflow demo looked excellent for five hand-picked examples. The team wants to call it production-ready for a high-impact workflow. Produce the release recommendation.",
"expected_output": "The response declines a production-ready claim until it has a representative baseline, adversarial and failure cases, explicit risk constraints, evaluation results, residual-risk owner, rollout and rollback evidence, and an authorized release decision.",
"assertions": [
"Rejects the demo as sufficient production evidence",
"Requires baseline, representative cases, adversarial or failure cases, and risk constraints",
"Requires explicit release decision, rollout, rollback, and residual-risk ownership",
"Routes agent or LLM evaluation to agent-evals-and-observability and release readiness to production-readiness"
]
},
{
"id": "technical-success-adoption-failure",
"prompt": "A capability is deployed, passes technical tests, and is available to all intended users, but only 8% use it after two months. Diagnose and decide what happens next.",
"expected_output": "The response treats the engagement as incomplete, measures activation and workflow outcomes against a baseline, and investigates access, workflow fit, trust, education, support, ownership, and incentives before recommending more features or training.",
"assertions": [
"Does not equate deployment or technical tests with completion",
"Examines activation, workflow fit, trust or education, support or ownership, and incentives",
"Requests baseline, target, segment, time-to-value, and decision rule evidence",
"Records an intervention or stop/pivot decision tied to observed adoption evidence"
]
},
{
"id": "generalization-classification",
"prompt": "A one-off workflow configuration solved one stakeholder's problem. Another team asks to turn it into a platform feature. Make the generalization decision.",
"expected_output": "The response classifies the work as configuration, reusable pattern, product capability, transfer/replacement, or retirement using evidence about repeated need, transferable constraints, support, security/privacy, cost, and a receiving owner.",
"assertions": [
"Names one explicit classification and records any missing evidence as bounded uncertainty rather than deferring the requested decision",
"Distinguishes local observation from the inference that the pattern generalizes",
"Uses repeated need, transferable constraints, reuse boundary, non-generalizable conditions, support, security or privacy, and cost in the classification",
"Names a receiving owner and next action rather than promoting by enthusiasm"
]
},
{
"id": "authority-boundary-escalation",
"prompt": "The engagement lead wants to export sensitive data, make an irreversible schema change, increase spend beyond the agreed budget, and promise a delivery date to an external stakeholder. The charter does not grant those powers.",
"expected_output": "The response stops each out-of-charter action, records the exact decision needed, and escalates privacy/security, irreversible-change, budget, and business-commitment decisions to their authorized owners while continuing safe work.",
"assertions": [
"Separates privacy or security, irreversible change, cost, and external commitment decisions",
"Does not infer authority from the technical lead's accountability",
"Names an authorized owner or gate for each escalation",
"States what safe read-only or non-destructive work can continue",
"Does not proceed with any of the four proposed actions until the corresponding authorization is recorded"
]
},
{
"id": "bounded-bug-negative-boundary",
"prompt": "A repository has a reproducible null dereference with a failing unit test, a clear expected behavior, and no stakeholder discovery or deployment engagement required. What process should handle it?",
"expected_output": "The response routes directly to neckbeard and the relevant implementation or testing specialist, without invoking the full forward-deployed lifecycle or inventing an embedded engagement charter.",
"assertions": [
"Recognizes the work as a well-specified repository change",
"Routes to neckbeard and the relevant specialist rather than FDE lifecycle stages",
"Does not require stakeholder workflow discovery, adoption measurement, or productization for this task"
]
},
{
"id": "epistemic-and-handoff-discipline",
"prompt": "Write a status and handoff for an engagement where users reported faster work, logs show a 12% reduction in median completion time, the lead believes trust improved, and the product team has not yet accepted a reusable pattern.",
"expected_output": "The response labels user reports and measured values as observations, labels improved trust as an inference, states the recommendation separately, records that productization is not yet a decision, and gives the receiving owner evidence, uncertainty, acceptance condition, and next action.",
"assertions": [
"Labels source or engagement observations, inference, recommendation, decision, and commitment separately",
"Does not present the trust explanation as measured fact",
"Does not claim productization was approved",
"Includes receiving owner, evidence, uncertainty, acceptance condition, and next action in the handoff"
]
},
{
"id": "full-lifecycle-continuity",
"prompt": "An embedded technical lead has been asked to improve a regulated claims-review workflow. Stakeholders disagree about the bottleneck, the environment has controlled access, an initial prototype may use an LLM, and success requires production adoption plus a decision about whether the result should become a reusable capability. Produce the end-to-end engagement operating plan and durable handoff path.",
"expected_output": "The response carries one evidence and authority thread through Discover, Frame, Hypothesize, Build, Evaluate, Deploy, Adopt, Measure, and Generalize; names the durable artifacts and specialist methods at the right stages; defines stop and escalation gates; and ends with adoption evidence plus an explicit generalization classification and receiving owner.",
"assertions": [
"Covers all nine lifecycle stages in order without replacing specialist methods",
"Maintains the charter, workflow map, assumptions-decisions-risks ledger, evidence labels, authority, and handoffs across stage transitions",
"Requires constrained-environment discovery, representative and adversarial evaluation, production readiness, rollout, rollback, adoption, and workflow-outcome evidence before completion",
"Separates local success from generalization and ends with a classification, receiving owner, and acceptance condition",
"Applies the private-by-default external-sharing gate to reusable field learning"
]
},
{
"id": "ongoing-reliability-negative-boundary",
"prompt": "A mature service already has an accountable service owner and needs ongoing SLO definition, alert tuning, incident response, error-budget policy, and reliability improvement. There is no embedded stakeholder engagement or adoption problem. What process should handle it?",
"expected_output": "The response routes directly to site-reliability-engineering and relevant operational specialists without invoking the forward-deployed lifecycle, an engagement charter, product adoption work, or generalization ceremony.",
"assertions": [
"Recognizes ongoing reliability ownership as outside the FDE bundle",
"Routes to site-reliability-engineering and relevant operational specialists",
"Does not invent stakeholder discovery, adoption measurement, or productization work"
]
},
{
"id": "advisory-only-negative-boundary",
"prompt": "A leadership team wants a two-hour advisory review of three architecture options and a recommendation. They explicitly do not want implementation, deployment, adoption ownership, or an embedded technical lead. Should the forward-deployed lifecycle run?",
"expected_output": "The response declines the FDE bundle and routes the bounded advisory analysis to the relevant architecture or decision specialist, because the work ends before implementation and adoption.",
"assertions": [
"Recognizes advisory work ending before implementation and adoption as outside the FDE boundary",
"Routes to the relevant architecture or decision specialist",
"Does not create an engagement charter or nine-stage lifecycle for the advisory review"
]
},
{
"id": "product-lifecycle-negative-boundary",
"prompt": "A product leadership team must decide which of four market opportunities belongs in next year's portfolio, allocate investment, and establish lifecycle governance. No embedded delivery engagement has been authorized. What process should own the work?",
"expected_output": "The response routes the portfolio investment and lifecycle-governance decision to the product-lifecycle bundle, without starting an FDE engagement or treating a portfolio choice as field delivery continuity.",
"assertions": [
"Recognizes portfolio investment and lifecycle governance as outside the FDE bundle",
"Routes directly to product-lifecycle",
"Does not create an engagement charter, implementation plan, adoption scorecard, or FDE generalization record"
]
},
{
"id": "platform-operation-negative-boundary",
"prompt": "An internal platform team already owns a developer portal and golden-path services. It needs to design and operate the next platform capability, define its interfaces, and manage ongoing platform adoption across engineering teams. There is no external embedded engagement. What process should own it?",
"expected_output": "The response routes direct platform design and operation to platform-engineering, without wrapping ongoing platform ownership in the FDE lifecycle.",
"assertions": [
"Recognizes direct internal platform design and operation as outside the FDE bundle",
"Routes directly to platform-engineering",
"Does not invent an FDE engagement, field-learning handoff, or separate productization ceremony"
]
},
{
"id": "isolated-specialist-negative-boundary",
"prompt": "A system's workflow, scope, owner, and acceptance criteria are already settled. The only remaining task is to define a retention schedule and deletion controls for personal data. No implementation or adoption continuity is requested. What process should own it?",
"expected_output": "The response routes the bounded privacy task directly to privacy-engineering, without loading the FDE bundle or unrelated stage specialists.",
"assertions": [
"Recognizes that one specialist fully owns the bounded request",
"Routes directly to privacy-engineering",
"Does not run stakeholder discovery, the nine-stage FDE lifecycle, or load unrelated specialists"
]
},
{
"id": "partial-and-stale-authority",
"prompt": "A security owner documented approval for read-only log inspection. A sponsor says the CTO verbally approved exporting those logs, a database owner approved a reversible index but not the requested schema rewrite, and last quarter's budget waiver has expired. Separate what may proceed from what must stop.",
"expected_output": "The response permits only the documented read-only inspection, refuses to launder verbal, partial, or stale authority into broader powers, and records the export, schema, and spend decisions for their authorized owners before those actions proceed.",
"assertions": [
"Permits the documented read-only inspection and no broader action",
"Treats verbal assurance, partial approval, and expired approval as insufficient for the proposed export, schema rewrite, and spend",
"Names the missing decision and authorized owner for each blocked action",
"Does not infer one decision owner's approval applies to another authority domain"
]
}
]
}
@@ -0,0 +1,326 @@
# Bundle manifest (bundle-manifest-v1) — paths are relative to this bundle dir.
schema_version: 1
bundle_name: forward-deployed-engineering
purpose: >-
Carry an embedded technical engagement from ambiguous stakeholder need through
discovery, framing, hypothesis, build, evaluation, deployment, adoption,
measurement, and generalization while preserving decision rights, evidence,
handoffs, and reusable field learning.
audience: >-
Technical leads and agents embedded across stakeholder discovery, implementation,
production fit, adoption, and measurable workflow outcomes; this is a continuity
layer that routes specialist methods rather than replacing them.
stages:
- name: Discover
skills:
- ../../product-discovery/SKILL.md
- ../../data-engineering/SKILL.md
- ../../remote-systems-administration/SKILL.md
- name: Frame
skills:
- ../../product-design-and-ux/SKILL.md
- ../../privacy-engineering/SKILL.md
- ../../secure-software-engineering/SKILL.md
- name: Hypothesize
skills:
- ../../product-experimentation/SKILL.md
- ../../agent-evals-and-observability/SKILL.md
- name: Build
skills:
- ../../implementation-planning/SKILL.md
- ../../backend-engineering/SKILL.md
- ../../frontend-engineering/SKILL.md
- ../../data-engineering/SKILL.md
- name: Evaluate
skills:
- ../../agent-evals-and-observability/SKILL.md
- ../../qa-methodology/SKILL.md
- ../../verification-methodology/SKILL.md
- name: Deploy
skills:
- ../../production-readiness/SKILL.md
- ../../release-engineering/SKILL.md
- ../../platform-engineering/SKILL.md
- ../../remote-systems-administration/SKILL.md
- name: Adopt
skills:
- ../../product-adoption/SKILL.md
- ../../product-design-and-ux/SKILL.md
- name: Measure
skills:
- ../../product-analytics-and-measurement/SKILL.md
- ../../agent-evals-and-observability/SKILL.md
- ../../site-reliability-engineering/SKILL.md
- name: Generalize
skills:
- ../../product-lifecycle-learning/SKILL.md
- ../../product-methodology/SKILL.md
included_skills:
- ../../product-discovery/SKILL.md
- ../../product-design-and-ux/SKILL.md
- ../../product-experimentation/SKILL.md
- ../../agent-evals-and-observability/SKILL.md
- ../../implementation-planning/SKILL.md
- ../../backend-engineering/SKILL.md
- ../../frontend-engineering/SKILL.md
- ../../data-engineering/SKILL.md
- ../../qa-methodology/SKILL.md
- ../../verification-methodology/SKILL.md
- ../../production-readiness/SKILL.md
- ../../release-engineering/SKILL.md
- ../../platform-engineering/SKILL.md
- ../../remote-systems-administration/SKILL.md
- ../../product-adoption/SKILL.md
- ../../product-analytics-and-measurement/SKILL.md
- ../../site-reliability-engineering/SKILL.md
- ../../product-lifecycle-learning/SKILL.md
- ../../product-methodology/SKILL.md
- ../../privacy-engineering/SKILL.md
- ../../secure-software-engineering/SKILL.md
prerequisites:
- artifact: Stakeholder request or observed workflow opportunity and a named accountable lead
- artifact: Authority to conduct non-destructive discovery with access to relevant stakeholders or workflow evidence
outputs:
- engagement-charter
- stakeholder-workflow-map
- assumptions-decisions-risks-ledger
- engagement-status
- stage-handoff-record
- evaluation-and-release-decision
- adoption-scorecard
- outcome-measurement-record
- productization-record
- field-learning-record
handoffs:
- to: next lifecycle stage
artifact: stage-handoff-record
note: >-
Each stage receives the current charter, workflow map, ledger, evidence
labels, unresolved unknowns, and an explicit entry decision.
- to: production-readiness and release specialists
artifact: evaluation-and-release-decision
note: >-
A demo or prototype cannot be called production-ready without representative
evidence, risk constraints, rollout and rollback evidence, and an authorized decision.
- to: adoption and measurement specialists
artifact: adoption-scorecard
note: >-
Deployment hands off target workflow, activation path, owner, support path,
baseline, and decision rule; adoption remains part of completion.
- to: product, platform, or receiving delivery owner
artifact: productization-record
note: >-
Field learning is classified with evidence, reuse boundary, owner, and next
action rather than being promoted by enthusiasm alone.
- to: engagement sponsor
artifact: field-learning-record
note: >-
The engagement closes with observed outcomes, unresolved uncertainty, and a
durable transfer or follow-up path.
conflicts:
- skill: ../../product-discovery/SKILL.md
with: product-lifecycle
guidance: >-
This bundle uses product-discovery for embedded delivery continuity and
workflow context; product-lifecycle owns product investment and lifecycle governance.
- skill: ../../product-discovery/SKILL.md
with: research-and-vault
guidance: >-
Use product-discovery for stakeholder and workflow discovery; use research-and-vault
for a reusable web-research-to-knowledge capture chain.
- skill: ../../product-experimentation/SKILL.md
with: product-lifecycle
guidance: >-
This bundle routes experiments to test an engagement intervention; product-lifecycle
routes product investment experiments within its lifecycle governance.
- skill: ../../implementation-planning/SKILL.md
with: product-lifecycle
guidance: >-
This bundle routes implementation planning only during Build after an authorized
owner approves the requirement; product-lifecycle owns product delivery handoff.
Route a bounded code change to neckbeard.
- skill: ../../production-readiness/SKILL.md
with: production-excellence
guidance: >-
This bundle carries engagement evidence into the specialist readiness review;
production-excellence owns the cross-domain launch gate decision.
- skill: ../../production-readiness/SKILL.md
with: product-lifecycle
guidance: >-
This bundle routes readiness for an embedded capability; product-lifecycle
owns product lifecycle delivery handoff. Do not run both orchestration paths for one decision.
- skill: ../../release-engineering/SKILL.md
with: production-excellence
guidance: >-
This bundle routes deployment evidence from the engagement; production-excellence
uses release evidence for a launch gate.
- skill: ../../release-engineering/SKILL.md
with: product-lifecycle
guidance: >-
This bundle uses release engineering for embedded rollout continuity;
product-lifecycle uses it for product delivery handoff.
- skill: ../../platform-engineering/SKILL.md
with: production-excellence
guidance: >-
This bundle routes platform work needed to deploy the engagement capability;
production-excellence assembles platform evidence for launch gating.
- skill: ../../platform-engineering/SKILL.md
with: product-lifecycle
guidance: >-
This bundle routes platform work needed by the engagement; product-lifecycle
routes platform work in a product delivery handoff.
- skill: ../../platform-engineering/SKILL.md
with: agent-production-operations
guidance: >-
This bundle routes product or engagement platform delivery; agent-production-operations
owns runtime agent sandboxing and tool-execution isolation.
- skill: ../../secure-software-engineering/SKILL.md
with: production-excellence
guidance: >-
This bundle routes trust-boundary work during the engagement; production-excellence
consumes security evidence for its launch gate.
- skill: ../../secure-software-engineering/SKILL.md
with: product-lifecycle
guidance: >-
This bundle routes security work in the embedded lifecycle; product-lifecycle
routes security work in product lifecycle phases.
- skill: ../../secure-software-engineering/SKILL.md
with: agent-production-operations
guidance: >-
This bundle routes application and engagement security; agent-production-operations
owns agent authority, disablement, and runtime security controls.
- skill: ../../privacy-engineering/SKILL.md
with: product-lifecycle
guidance: >-
This bundle routes privacy work for engagement data flows; product-lifecycle
routes privacy work across product lifecycle phases.
- skill: ../../privacy-engineering/SKILL.md
with: agent-production-operations
guidance: >-
This bundle routes engagement privacy decisions; agent-production-operations
routes trace scrubbing and user-data-access grants.
- skill: ../../qa-methodology/SKILL.md
with: production-excellence
guidance: >-
This bundle routes quality evidence for the built capability; production-excellence
uses QA evidence at the launch gate.
- skill: ../../qa-methodology/SKILL.md
with: product-lifecycle
guidance: >-
This bundle routes evaluation and quality work for engagement delivery;
product-lifecycle uses QA at product delivery handoff.
- skill: ../../verification-methodology/SKILL.md
with: production-excellence
guidance: >-
This bundle uses verification to label engagement evidence; production-excellence
uses it to verify launch-boundary evidence.
- skill: ../../verification-methodology/SKILL.md
with: product-lifecycle
guidance: >-
This bundle verifies continuity artifacts and field outcomes; product-lifecycle
verifies evidence at product phase gates.
- skill: ../../site-reliability-engineering/SKILL.md
with: production-excellence
guidance: >-
This bundle routes reliability evidence for the engagement; production-excellence
uses SRE evidence for its production gate.
- skill: ../../site-reliability-engineering/SKILL.md
with: product-lifecycle
guidance: >-
This bundle routes reliability work needed for adoption and operation;
product-lifecycle routes SRE work in product delivery handoff.
- skill: ../../site-reliability-engineering/SKILL.md
with: agent-production-operations
guidance: >-
This bundle routes service reliability; agent-production-operations routes
runtime latency, cost budgets, and incident handoff for agents.
- skill: ../../data-engineering/SKILL.md
with: production-excellence
guidance: >-
This bundle routes data work required by the engagement; production-excellence
consumes data evidence in its operational handoff and launch gate.
- skill: ../../product-adoption/SKILL.md
with: product-lifecycle
guidance: >-
This bundle owns adoption continuity for an embedded engagement; product-lifecycle
owns product adoption as one phase of product governance.
- skill: ../../product-analytics-and-measurement/SKILL.md
with: product-lifecycle
guidance: >-
This bundle measures workflow impact for engagement completion; product-lifecycle
measures product outcomes in lifecycle review.
- skill: ../../product-lifecycle-learning/SKILL.md
with: product-lifecycle
guidance: >-
This bundle uses field learning to decide generalization; product-lifecycle-learning
owns the product lifecycle learning method and decision record.
- skill: ../../agent-evals-and-observability/SKILL.md
with: agent-production-operations
guidance: >-
This bundle routes eval evidence for engagement release and learning;
agent-production-operations consumes eval and trace evidence for runtime control.
- skill: ../../production-readiness/SKILL.md
with: agent-production-operations
guidance: >-
This bundle routes readiness for an embedded capability; agent-production-operations
consumes readiness as an authority-gating input.
- skill: ../../release-engineering/SKILL.md
with: agent-production-operations
guidance: >-
This bundle uses release engineering for engagement rollout; agent-production-operations
uses it for staged runtime rollout and fallback.
- skill: ../../product-design-and-ux/SKILL.md
with: neckbeard
guidance: >-
This bundle routes UX for embedded workflow adoption; neckbeard uses UX
only as needed for a bounded software change. Route by task boundary.
- skill: ../../product-discovery/SKILL.md
with: neckbeard
guidance: >-
This bundle owns embedded stakeholder and workflow discovery; neckbeard
handles the bounded change after its requirements are known.
- skill: ../../qa-methodology/SKILL.md
with: neckbeard
guidance: >-
This bundle routes QA for engagement evidence; neckbeard applies QA within
its software delivery journey for a bounded repository change.
- skill: ../../release-engineering/SKILL.md
with: neckbeard
guidance: >-
This bundle routes release work across the engagement lifecycle; neckbeard
owns release delivery for a bounded change.
- skill: ../../secure-software-engineering/SKILL.md
with: neckbeard
guidance: >-
This bundle routes security decisions across embedded delivery; neckbeard
applies security to its bounded software change.
- skill: ../../site-reliability-engineering/SKILL.md
with: neckbeard
guidance: >-
This bundle routes reliability for engagement outcomes; neckbeard routes
reliability concerns within its software delivery journey.
- skill: ../../verification-methodology/SKILL.md
with: neckbeard
guidance: >-
This bundle verifies stage continuity and outcome evidence; neckbeard
verifies the bounded repository change.
- skill: ../../product-design-and-ux/SKILL.md
with: product-lifecycle
guidance: >-
This bundle routes UX for embedded workflow adoption; product-lifecycle
routes UX for product requirements and lifecycle governance.
- skill: ../../product-methodology/SKILL.md
with: product-lifecycle
guidance: >-
This bundle uses prioritization only to support engagement generalization;
product-lifecycle owns product prioritization and portfolio methods.
eval_suite:
- evals/evals.json
@@ -0,0 +1,34 @@
# Adoption and Measurement
Technical deployment is an input to adoption, not its proof. Establish a
baseline before intervention and name the intended workflow, user segment,
activation event, time-to-value, support owner, and outcome decision rule.
## Adoption diagnosis
When usage is weak, distinguish:
- **Access:** can the intended people reach and use the capability?
- **Activation:** do they complete the first meaningful workflow?
- **Workflow fit:** does it remove work or add friction compared with the current path?
- **Trust and education:** do users understand and trust the result?
- **Support and ownership:** is there help, maintenance, and a named owner?
- **Incentives and authority:** do policy, incentives, or manager expectations conflict?
Do not prescribe more training or more features until the evidence distinguishes
these causes. A technical success with poor adoption is an unresolved outcome,
not a completed engagement.
## Measurement record
For each metric record definition, baseline, target or decision rule, segment,
source, collection period, caveats, observed value, and interpretation. Separate
observed values from inferred causes. If the metric moved, test whether the
intended workflow changed and whether the change is attributable enough for the
decision being made.
For AI capabilities, pair workflow measures with evaluation evidence: quality,
failure and adversarial cases, safety or privacy constraints, latency/cost
guardrails where relevant, human override or escalation, and production feedback
that can update the evaluation set. Route statistical or instrumentation method
to the named catalog specialists.
@@ -0,0 +1,35 @@
# Authority and Escalation
## Before constrained action
Record the access route, identity and privilege needed, approved egress,
systems and data in scope, change window, reviewer, rollback or recovery path,
external-boundary verification, and evidence that the action succeeded. Load
[remote-systems-administration](../../../remote-systems-administration/SKILL.md)
for its operational method rather than inventing one here.
## Authority table
| Decision | Proceed only when | Escalate to |
|---|---|---|
| Scope, sequence, and thin slice | Charter names accountable lead and sponsor | Engagement sponsor |
| Access and privilege | Authorized identity, least privilege, and route are recorded | System owner or security owner |
| Security boundary | Trust boundary, threat assumptions, and controls are reviewed | Security owner |
| Privacy and data use | Purpose, classification, access, retention, and deletion are explicit | Privacy/data owner |
| Irreversible change | Recovery is tested or an authorized exception is recorded | Service or change owner |
| Material cost or quota | Budget owner accepts estimate and guardrail | Budget owner |
| External commitment | Contract, customer, or public promise is authorized | Business owner |
| Business priority or portfolio choice | Product or executive authority decides | Product/business owner |
When authority or evidence is missing, stop the action, record the blocker,
preserve safe read-only discovery, and escalate with the smallest decision
needed. Do not use urgency, stakeholder enthusiasm, or a working demo as an
authority substitute.
## Applied AI release boundary
An applied-AI demo is not production-ready without a representative baseline,
adversarial or failure cases, risk constraints, evaluation results, an owner for
residual risk, rollout and rollback evidence, and an explicit release decision.
Route evaluation details to [agent-evals-and-observability](../../../agent-evals-and-observability/SKILL.md)
and readiness details to [production-readiness](../../../production-readiness/SKILL.md).
@@ -0,0 +1,40 @@
# Communication
Communication keeps an embedded engagement moving without hiding uncertainty.
Use short records with explicit labels rather than a narrative that blends fact
and promise.
## Status update
1. **Outcome:** what changed in the target workflow or decision.
2. **Evidence:** source fact or engagement observation, with artifact and date.
3. **Inference:** what the evidence may mean, including confidence and unknowns.
4. **Decision needed:** the smallest authorized choice, by whom, and by when.
5. **Commitment:** owner, deliverable, due date, and dependency.
6. **Stop/escalation:** what is blocked and what safe work can continue.
## Handoff
State the receiving owner, purpose, current stage, entry evidence, artifacts,
known limitations, unresolved risks, authority boundary, acceptance condition,
and requested response. A handoff is not complete when a link is sent; the
receiver must accept ownership or explicitly reject the boundary.
## Field learning
Report what was observed, what was tried, what changed, what failed, what may
generalize, and what should not be generalized. Label recommendations as
recommendations until the receiving authority records a decision. Avoid naming
private customers, hosts, paths, or deployment details in reusable public
artifacts.
## External-sharing gate
Treat every engagement artifact as private by default. Before any artifact
leaves the authorized engagement context, name the receiving audience and have
an accountable reviewer remove or generalize customer and stakeholder names,
people, hosts, paths, credentials, identifiers, sensitive workflow details,
security posture, commercial terms, and other context-specific information.
Record the artifact's sharing classification, reviewer, and review date. A
reusable lesson may be shared only after this gate; compliance or stakeholder
urgency does not waive it.
@@ -0,0 +1,54 @@
# Discovery Brief — Forward-Deployed Engineering
## Scope and design decision
The requested capability is designed as a public, business-agnostic continuity
bundle for embedded technical engagements. Portability is a normative design
objective, not a conclusion established by the employer-authored sources. Its
normative synthesis is the lifecycle
`Discover → Frame → Hypothesize → Build → Evaluate → Deploy → Adopt → Measure →
Generalize`, plus shared artifacts, authority gates, evidence labels, and a
generalization decision. This sequence is bundle design, not an externally
standardized methodology.
## Overlap audit
| Existing owner | Already owns | FDE bundle boundary |
|---|---|---|
| [product-discovery](../../../product-discovery/SKILL.md) | Stakeholder mapping, workflow walkthroughs, hidden assumptions, validation, and interpretation handoff | Routes discovery and carries its evidence forward; does not duplicate discovery method |
| [agent-evals-and-observability](../../../agent-evals-and-observability/SKILL.md) | Decision/risk contracts, datasets, baselines, graders, trajectory review, release gates, telemetry, and incident learning | Routes evaluation evidence and applies it to engagement continuity; does not restate eval method |
| [production-readiness](../../../production-readiness/SKILL.md) | Risk-scaled evidence, ownership, SLOs, observability, support, security, data, rollback, capacity, cost, and verdicts | Routes readiness at the deployment boundary; does not invent a customer-site readiness method |
| [remote-systems-administration](../../../remote-systems-administration/SKILL.md) | Access routes, privilege, bastions, sessions, recovery, rollback, canaries, bounded rollout, and external verification | Routes constrained-environment discovery before action; does not create a second remote-operations runbook |
| [product-lifecycle](../../product-lifecycle/SKILL.md) | Product investment and lifecycle governance | FDE owns embedded delivery continuity, not portfolio choice or product lifecycle governance |
| [production-excellence](../../production-excellence/SKILL.md) | Cross-domain production gate and handoff | FDE prepares engagement continuity and routes evidence; production-excellence owns its launch gate |
| [neckbeard](../../neckbeard/SKILL.md) | Bounded software change journey | FDE stops routing and sends a well-specified repository change directly to neckbeard |
The four audited class-level skills are not modified by this bundle. The
manifest routes to them where their existing methods are needed.
## Themes across the source set
The three sources do not establish one common role contract. Palantir supports
embedded implementation, engineering review and operation, and return of field
configurations and expertise. OpenAI supports discovery through rollout,
adoption and workflow-impact measurement, eval-driven feedback, and pattern
codification. The limited Databricks extract supports customer-facing
productionization and cross-functional work. Together they orient the bundle,
but no source proves the full nine-stage lifecycle or every artifact. They also
do not establish a universal title, staffing model, technology stack, travel
pattern, or lifecycle sequence. See [source-index.md](source-index.md).
## Design risks and mitigations
The following are risks this normative design is intended to guard against;
the source set does not establish their frequency or prevalence.
| Design risk | Continuity mitigation |
|---|---|
| Bespoke-service sprawl | Record reuse boundary and generalization decision for every local solution |
| Hero culture | Name authority, review, support, and receiving owners; make escalation normal |
| Prototype-to-production collapse | Require baseline, representative/adversarial evaluation, readiness evidence, rollback, and a release decision |
| Product bypass | Preserve field-learning and productization records; route patterns to an accountable receiving owner |
| Weak decision authority | Charter decision rights and stop conditions before action; escalate out-of-charter decisions |
| Customer capture | Define exit, transfer, adoption owner, support path, and measurable completion conditions |
| Technical success with adoption failure | Diagnose workflow, trust, education, activation, support, and ownership before more build work |
@@ -0,0 +1,27 @@
# 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](../../../implementation-planning/SKILL.md) only after
the receiving owner approves a requirement or specification.
@@ -0,0 +1,30 @@
# Lifecycle and Artifacts
The lifecycle is a continuity contract, not a claim about industry standard
practice. Every stage reads the current charter, workflow map, and ledger; it
adds evidence rather than re-deriving prior decisions.
| Stage | Required question | Minimum output | Stop condition |
|---|---|---|---|
| Discover | What user workflow and problem are real? | [Stakeholder/workflow map](../templates/stakeholder-workflow-map.md) and unknowns | No recognizable problem or access to the relevant workflow |
| Frame | What is in scope, who decides, and what outcome matters? | [Engagement charter](../templates/engagement-charter.md) and [assumptions/decisions/risks ledger](../templates/assumptions-decisions-risks-ledger.md) | Authority, constraints, or outcome cannot be named |
| Hypothesize | What smallest intervention could change the workflow? | Testable hypothesis and decision rule | No falsifiable hypothesis or unsafe test |
| Build | What operationally complete slice can be built? | Thin-slice implementation plan and owner | Dependencies or permissions are infeasible |
| Evaluate | What evidence supports quality, safety, and usefulness? | [Evaluation and release decision](../templates/evaluation-and-release-decision.md) | Baseline, representative evidence, or risk constraints missing |
| Deploy | Can it be released, recovered, and verified in the authorized environment? | Readiness, rollout, rollback, and verification record | No authorized access, rollback, or release decision |
| Adopt | Do intended users activate and use it in the target workflow? | Adoption scorecard and intervention record | Adoption failure is unexplained or ownership/support is absent |
| Measure | Did the capability change the agreed outcome? | [Outcome measurement record](../templates/outcome-measurement-record.md) | Instrumentation cannot distinguish expected from observed |
| Generalize | What should happen to the local learning? | [Productization record](../templates/productization-record.md) and [field-learning record](../templates/field-learning-record.md) | No evidence or receiving owner for the proposed next step |
## Shared record fields
For every stage record: date, stage, accountable lead, decision authority,
entry evidence, work performed, source/evidence label, observed result,
unknowns, risks, decision rule, decision, commitment, owner, due date, and next
handoff. A stopped engagement remains a valid output if the stop reason and
learning are preserved.
Use the canonical [stage-handoff record](../templates/stage-handoff-record.md)
for those fields. Maintain [engagement status](../templates/engagement-status.md)
as the concise current-state view; it supplements rather than replaces the
stage evidence and handoff record.
@@ -0,0 +1,47 @@
# 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.
@@ -0,0 +1,23 @@
# Source Index
Checked 2026-08-05. These are official employer-authored role descriptions,
used only for role observations. The lifecycle, artifacts, authority protocol,
failure-mode mitigations, and generalization model are normative bundle design.
The sources come from large software and AI vendors; they do not establish that
the bundle applies universally across business, public-sector, nonprofit,
internal-service, or non-product settings. Portability is a design objective
that must be tested in the engagement context.
| Source | Authority | Supported claims | Limitations and refresh rule |
|---|---|---|---|
| [Palantir: A Day in the Life of a Palantir Forward Deployed Software Engineer](https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1) | Official employer-authored role account | FDSEs embed with customers; configure existing platforms; combine software development, data engineering, customer engagement, and creative problem solving; implement collaboratively; use engineering review, deployment, maintenance, and monitoring; return configurations, workflows, and field expertise to product and deployment teams | One employee account with employer-specific products, titles, and examples. Do not universalize those details. Recheck the URL and role-account scope before materially revising source claims. |
| [OpenAI: Forward Deployed Engineer](https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/) | Current official employer role description | FDEs turn research into production systems with customers; own discovery, scoping, design, build, rollout; measure adoption and workflow impact; use eval-driven feedback; guide adoption; codify patterns and return field feedback | Employer-specific AI role description. Excludes universal employment qualifications, location, travel, mission, and stack. Recheck current role page before citing current responsibilities. |
| [Databricks: AI Engineer — FDE](https://www.databricks.com/company/careers/professional-services-operations/ai-engineer---fde-forward-deployed-engineer-8099751002) | Current official employer role description | A specialized customer-facing AI team builds and productionizes first-of-kind applications and works cross-functionally with engineering, product, developer relations, and internal SMEs | Retrieved overview exposes only these responsibilities. Do not infer missing qualifications or duties. Recheck the role page before adding claims. |
## Claim discipline
Source facts must cite one of these entries. Engagement evidence must cite the
charter, ledger, evaluation, deployment, adoption, or measurement artifact that
observed it. Inferences and recommendations must be labeled as such. A source
does not prove that a local engagement succeeded, that a pattern generalizes, or
that an authority exists.
@@ -0,0 +1,19 @@
# Adoption Scorecard
- **Capability and target workflow:**
- **Intended users / segment:**
- **Workflow owner and support owner:**
- **Baseline period and source:**
- **Activation event:**
- **Time-to-value baseline / target:**
- **Adoption metric and decision rule:**
- **Outcome metric and decision rule:**
- **Access or privilege blockers:**
- **Workflow-fit evidence:**
- **Trust / education evidence:**
- **Support / ownership evidence:**
- **Intervention:**
- **Observed result:**
- **Interpretation and remaining uncertainty:**
- **Decision:**
- **Sharing classification / sanitization reviewer:**
@@ -0,0 +1,16 @@
# Assumptions, Decisions, and Risks Ledger
| ID | Type | Statement | Evidence / source | Confidence | Owner | Due / review | Status |
|---|---|---|---|---|---|---|---|
| A-001 | Assumption | | | | | | Open |
| D-001 | Decision | | | | | | Open |
| R-001 | Risk | | | | | | Open |
- **Sharing classification / sanitization reviewer:**
## Evidence labels
Use exactly one primary label for each entry: source fact, engagement
observation, inference, recommendation, decision, or commitment. Link the
artifact or observation that supports it. Record disconfirmation and the next
decision rule instead of silently rewriting the entry.
@@ -0,0 +1,23 @@
# Engagement Charter
- **Engagement:**
- **Date / revision:**
- **Accountable technical lead:**
- **Sponsor and decision authority:**
- **Stakeholders and intended users:**
- **Workflow and problem statement:**
- **Desired outcome and baseline:**
- **In scope:**
- **Out of scope:**
- **Constraints:**
- **Access and privilege boundary:**
- **Success measure and decision rule:**
- **Stop conditions:**
- **Rollback / recovery boundary:**
- **Planned lifecycle stages:**
- **Open unknowns:**
- **Next decision and owner:**
- **Sharing classification / sanitization reviewer:**
Record observations, inferences, recommendations, decisions, and commitments
separately in the ledger.
@@ -0,0 +1,17 @@
# Engagement Status
- **Engagement / revision:**
- **Date:**
- **Current stage:**
- **Overall state:** Discover / Active / Blocked / Stopped / Complete
- **Outcome movement:**
- **Evidence observed:**
- **Inference / confidence:**
- **Work completed:**
- **Next decision:**
- **Decision authority and due date:**
- **Risks and unknowns:**
- **Escalation:**
- **Commitments:**
- **Next handoff:**
- **Sharing classification / sanitization reviewer:**
@@ -0,0 +1,15 @@
# Evaluation and Release Decision
- **Capability / version / environment:**
- **Evaluation owner:**
- **Decision authority:**
- **Baseline and decision thresholds:**
- **Representative evidence:**
- **Adversarial or misuse evidence:**
- **Operational and trajectory evidence:**
- **Known constraints and residual risks:**
- **Rollout / rollback prerequisites:**
- **Release decision:** Approve / Conditional / Reject
- **Conditions or stop reason:**
- **Receiving owner / acceptance condition:**
- **Sharing classification / sanitization reviewer:**
@@ -0,0 +1,14 @@
# Field Learning Record
- **Engagement boundary:**
- **Observed workflow outcome:**
- **Evidence and source labels:**
- **What was local or environment-specific:**
- **What may transfer, and within what boundary:**
- **Unresolved uncertainty / risks:**
- **Generalization classification:**
- **Decision authority and decision:**
- **Receiving owner / acceptance condition:**
- **Committed next action / due date:**
- **Public-safe summary after sanitization:**
- **Sharing classification / sanitization reviewer:**
@@ -0,0 +1,15 @@
# Outcome Measurement Record
- **Capability / target workflow:**
- **Accountable owner:**
- **Agreed outcome and decision rule:**
- **Baseline / comparison:**
- **Instrumentation and evidence source:**
- **Observation window / population:**
- **Expected result:**
- **Observed result:**
- **Uncertainty and confounders:**
- **Decision:** Continue / Improve / Pivot / Pause / Retire
- **Committed next action / due date:**
- **Receiving owner / acceptance condition:**
- **Sharing classification / sanitization reviewer:**
@@ -0,0 +1,16 @@
# Productization Record
- **Engagement / capability:**
- **Observed local result:**
- **Evidence artifacts:**
- **Reuse hypothesis:**
- **Classification:** Configuration / Reusable pattern / Product capability / Transfer-replacement / Retirement
- **Reuse boundary and known non-generalizable conditions:**
- **Security, privacy, support, and cost implications:**
- **Receiving owner:**
- **Recommendation:**
- **Decision authority and decision:**
- **Committed next action / due date:**
- **Field learning returned to:**
- **Sharing classification / sanitization reviewer:**
- **Retained uncertainty:**
@@ -0,0 +1,18 @@
# Stage Handoff Record
- **Date / stage:**
- **Accountable lead:**
- **Decision authority:**
- **Entry evidence:**
- **Work performed:**
- **Source / evidence labels:**
- **Observed result:**
- **Unknowns:**
- **Risks:**
- **Decision rule:**
- **Decision:**
- **Commitment:**
- **Receiving owner / due date:**
- **Acceptance condition:**
- **Next stage or stop reason:**
- **Sharing classification / sanitization reviewer:**
@@ -0,0 +1,19 @@
# Stakeholder and Workflow Map
| Stakeholder / role | Need or job | Current workflow | Friction / risk | Evidence source | Decision or influence | Follow-up owner |
|---|---|---|---|---|---|---|
| | | | | | | |
- **Sharing classification / sanitization reviewer:**
## Workflow slice
- **Trigger:**
- **Inputs and data:**
- **Steps:**
- **Tools and handoffs:**
- **Decision points:**
- **Failure and recovery path:**
- **Current baseline:**
- **Desired change:**
- **Unknowns requiring observation:**
+379
View File
@@ -206,6 +206,385 @@
}
}
},
{
"name": "forward-deployed-engineering",
"derivation": "manifest",
"source": "bundles/forward-deployed-engineering/manifest.yaml",
"fields": {
"purpose": {
"value": "Carry an embedded technical engagement from ambiguous stakeholder need through discovery, framing, hypothesis, build, evaluation, deployment, adoption, measurement, and generalization while preserving decision rights, evidence, handoffs, and reusable field learning.",
"source": "bundles/forward-deployed-engineering/manifest.yaml#/purpose"
},
"audience": {
"value": "Technical leads and agents embedded across stakeholder discovery, implementation, production fit, adoption, and measurable workflow outcomes; this is a continuity layer that routes specialist methods rather than replacing them.",
"source": "bundles/forward-deployed-engineering/manifest.yaml#/audience"
},
"stages": {
"value": [
{
"name": "Discover",
"skills": [
"../../product-discovery/SKILL.md",
"../../data-engineering/SKILL.md",
"../../remote-systems-administration/SKILL.md"
]
},
{
"name": "Frame",
"skills": [
"../../product-design-and-ux/SKILL.md",
"../../privacy-engineering/SKILL.md",
"../../secure-software-engineering/SKILL.md"
]
},
{
"name": "Hypothesize",
"skills": [
"../../product-experimentation/SKILL.md",
"../../agent-evals-and-observability/SKILL.md"
]
},
{
"name": "Build",
"skills": [
"../../implementation-planning/SKILL.md",
"../../backend-engineering/SKILL.md",
"../../frontend-engineering/SKILL.md",
"../../data-engineering/SKILL.md"
]
},
{
"name": "Evaluate",
"skills": [
"../../agent-evals-and-observability/SKILL.md",
"../../qa-methodology/SKILL.md",
"../../verification-methodology/SKILL.md"
]
},
{
"name": "Deploy",
"skills": [
"../../production-readiness/SKILL.md",
"../../release-engineering/SKILL.md",
"../../platform-engineering/SKILL.md",
"../../remote-systems-administration/SKILL.md"
]
},
{
"name": "Adopt",
"skills": [
"../../product-adoption/SKILL.md",
"../../product-design-and-ux/SKILL.md"
]
},
{
"name": "Measure",
"skills": [
"../../product-analytics-and-measurement/SKILL.md",
"../../agent-evals-and-observability/SKILL.md",
"../../site-reliability-engineering/SKILL.md"
]
},
{
"name": "Generalize",
"skills": [
"../../product-lifecycle-learning/SKILL.md",
"../../product-methodology/SKILL.md"
]
}
],
"source": "bundles/forward-deployed-engineering/manifest.yaml#/stages"
},
"included_skills": {
"value": [
"../../product-discovery/SKILL.md",
"../../product-design-and-ux/SKILL.md",
"../../product-experimentation/SKILL.md",
"../../agent-evals-and-observability/SKILL.md",
"../../implementation-planning/SKILL.md",
"../../backend-engineering/SKILL.md",
"../../frontend-engineering/SKILL.md",
"../../data-engineering/SKILL.md",
"../../qa-methodology/SKILL.md",
"../../verification-methodology/SKILL.md",
"../../production-readiness/SKILL.md",
"../../release-engineering/SKILL.md",
"../../platform-engineering/SKILL.md",
"../../remote-systems-administration/SKILL.md",
"../../product-adoption/SKILL.md",
"../../product-analytics-and-measurement/SKILL.md",
"../../site-reliability-engineering/SKILL.md",
"../../product-lifecycle-learning/SKILL.md",
"../../product-methodology/SKILL.md",
"../../privacy-engineering/SKILL.md",
"../../secure-software-engineering/SKILL.md"
],
"source": "bundles/forward-deployed-engineering/manifest.yaml#/included_skills"
},
"prerequisites": {
"value": [
{
"artifact": "Stakeholder request or observed workflow opportunity and a named accountable lead"
},
{
"artifact": "Authority to conduct non-destructive discovery with access to relevant stakeholders or workflow evidence"
}
],
"source": "bundles/forward-deployed-engineering/manifest.yaml#/prerequisites"
},
"outputs": {
"value": [
"engagement-charter",
"stakeholder-workflow-map",
"assumptions-decisions-risks-ledger",
"engagement-status",
"stage-handoff-record",
"evaluation-and-release-decision",
"adoption-scorecard",
"outcome-measurement-record",
"productization-record",
"field-learning-record"
],
"source": "bundles/forward-deployed-engineering/manifest.yaml#/outputs"
},
"handoffs": {
"value": [
{
"to": "next lifecycle stage",
"artifact": "stage-handoff-record",
"note": "Each stage receives the current charter, workflow map, ledger, evidence labels, unresolved unknowns, and an explicit entry decision."
},
{
"to": "production-readiness and release specialists",
"artifact": "evaluation-and-release-decision",
"note": "A demo or prototype cannot be called production-ready without representative evidence, risk constraints, rollout and rollback evidence, and an authorized decision."
},
{
"to": "adoption and measurement specialists",
"artifact": "adoption-scorecard",
"note": "Deployment hands off target workflow, activation path, owner, support path, baseline, and decision rule; adoption remains part of completion."
},
{
"to": "product, platform, or receiving delivery owner",
"artifact": "productization-record",
"note": "Field learning is classified with evidence, reuse boundary, owner, and next action rather than being promoted by enthusiasm alone."
},
{
"to": "engagement sponsor",
"artifact": "field-learning-record",
"note": "The engagement closes with observed outcomes, unresolved uncertainty, and a durable transfer or follow-up path."
}
],
"source": "bundles/forward-deployed-engineering/manifest.yaml#/handoffs"
},
"conflicts": {
"value": [
{
"skill": "../../product-discovery/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle uses product-discovery for embedded delivery continuity and workflow context; product-lifecycle owns product investment and lifecycle governance."
},
{
"skill": "../../product-discovery/SKILL.md",
"with": "research-and-vault",
"guidance": "Use product-discovery for stakeholder and workflow discovery; use research-and-vault for a reusable web-research-to-knowledge capture chain."
},
{
"skill": "../../product-experimentation/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle routes experiments to test an engagement intervention; product-lifecycle routes product investment experiments within its lifecycle governance."
},
{
"skill": "../../implementation-planning/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle routes implementation planning only during Build after an authorized owner approves the requirement; product-lifecycle owns product delivery handoff. Route a bounded code change to neckbeard."
},
{
"skill": "../../production-readiness/SKILL.md",
"with": "production-excellence",
"guidance": "This bundle carries engagement evidence into the specialist readiness review; production-excellence owns the cross-domain launch gate decision."
},
{
"skill": "../../production-readiness/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle routes readiness for an embedded capability; product-lifecycle owns product lifecycle delivery handoff. Do not run both orchestration paths for one decision."
},
{
"skill": "../../release-engineering/SKILL.md",
"with": "production-excellence",
"guidance": "This bundle routes deployment evidence from the engagement; production-excellence uses release evidence for a launch gate."
},
{
"skill": "../../release-engineering/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle uses release engineering for embedded rollout continuity; product-lifecycle uses it for product delivery handoff."
},
{
"skill": "../../platform-engineering/SKILL.md",
"with": "production-excellence",
"guidance": "This bundle routes platform work needed to deploy the engagement capability; production-excellence assembles platform evidence for launch gating."
},
{
"skill": "../../platform-engineering/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle routes platform work needed by the engagement; product-lifecycle routes platform work in a product delivery handoff."
},
{
"skill": "../../platform-engineering/SKILL.md",
"with": "agent-production-operations",
"guidance": "This bundle routes product or engagement platform delivery; agent-production-operations owns runtime agent sandboxing and tool-execution isolation."
},
{
"skill": "../../secure-software-engineering/SKILL.md",
"with": "production-excellence",
"guidance": "This bundle routes trust-boundary work during the engagement; production-excellence consumes security evidence for its launch gate."
},
{
"skill": "../../secure-software-engineering/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle routes security work in the embedded lifecycle; product-lifecycle routes security work in product lifecycle phases."
},
{
"skill": "../../secure-software-engineering/SKILL.md",
"with": "agent-production-operations",
"guidance": "This bundle routes application and engagement security; agent-production-operations owns agent authority, disablement, and runtime security controls."
},
{
"skill": "../../privacy-engineering/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle routes privacy work for engagement data flows; product-lifecycle routes privacy work across product lifecycle phases."
},
{
"skill": "../../privacy-engineering/SKILL.md",
"with": "agent-production-operations",
"guidance": "This bundle routes engagement privacy decisions; agent-production-operations routes trace scrubbing and user-data-access grants."
},
{
"skill": "../../qa-methodology/SKILL.md",
"with": "production-excellence",
"guidance": "This bundle routes quality evidence for the built capability; production-excellence uses QA evidence at the launch gate."
},
{
"skill": "../../qa-methodology/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle routes evaluation and quality work for engagement delivery; product-lifecycle uses QA at product delivery handoff."
},
{
"skill": "../../verification-methodology/SKILL.md",
"with": "production-excellence",
"guidance": "This bundle uses verification to label engagement evidence; production-excellence uses it to verify launch-boundary evidence."
},
{
"skill": "../../verification-methodology/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle verifies continuity artifacts and field outcomes; product-lifecycle verifies evidence at product phase gates."
},
{
"skill": "../../site-reliability-engineering/SKILL.md",
"with": "production-excellence",
"guidance": "This bundle routes reliability evidence for the engagement; production-excellence uses SRE evidence for its production gate."
},
{
"skill": "../../site-reliability-engineering/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle routes reliability work needed for adoption and operation; product-lifecycle routes SRE work in product delivery handoff."
},
{
"skill": "../../site-reliability-engineering/SKILL.md",
"with": "agent-production-operations",
"guidance": "This bundle routes service reliability; agent-production-operations routes runtime latency, cost budgets, and incident handoff for agents."
},
{
"skill": "../../data-engineering/SKILL.md",
"with": "production-excellence",
"guidance": "This bundle routes data work required by the engagement; production-excellence consumes data evidence in its operational handoff and launch gate."
},
{
"skill": "../../product-adoption/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle owns adoption continuity for an embedded engagement; product-lifecycle owns product adoption as one phase of product governance."
},
{
"skill": "../../product-analytics-and-measurement/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle measures workflow impact for engagement completion; product-lifecycle measures product outcomes in lifecycle review."
},
{
"skill": "../../product-lifecycle-learning/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle uses field learning to decide generalization; product-lifecycle-learning owns the product lifecycle learning method and decision record."
},
{
"skill": "../../agent-evals-and-observability/SKILL.md",
"with": "agent-production-operations",
"guidance": "This bundle routes eval evidence for engagement release and learning; agent-production-operations consumes eval and trace evidence for runtime control."
},
{
"skill": "../../production-readiness/SKILL.md",
"with": "agent-production-operations",
"guidance": "This bundle routes readiness for an embedded capability; agent-production-operations consumes readiness as an authority-gating input."
},
{
"skill": "../../release-engineering/SKILL.md",
"with": "agent-production-operations",
"guidance": "This bundle uses release engineering for engagement rollout; agent-production-operations uses it for staged runtime rollout and fallback."
},
{
"skill": "../../product-design-and-ux/SKILL.md",
"with": "neckbeard",
"guidance": "This bundle routes UX for embedded workflow adoption; neckbeard uses UX only as needed for a bounded software change. Route by task boundary."
},
{
"skill": "../../product-discovery/SKILL.md",
"with": "neckbeard",
"guidance": "This bundle owns embedded stakeholder and workflow discovery; neckbeard handles the bounded change after its requirements are known."
},
{
"skill": "../../qa-methodology/SKILL.md",
"with": "neckbeard",
"guidance": "This bundle routes QA for engagement evidence; neckbeard applies QA within its software delivery journey for a bounded repository change."
},
{
"skill": "../../release-engineering/SKILL.md",
"with": "neckbeard",
"guidance": "This bundle routes release work across the engagement lifecycle; neckbeard owns release delivery for a bounded change."
},
{
"skill": "../../secure-software-engineering/SKILL.md",
"with": "neckbeard",
"guidance": "This bundle routes security decisions across embedded delivery; neckbeard applies security to its bounded software change."
},
{
"skill": "../../site-reliability-engineering/SKILL.md",
"with": "neckbeard",
"guidance": "This bundle routes reliability for engagement outcomes; neckbeard routes reliability concerns within its software delivery journey."
},
{
"skill": "../../verification-methodology/SKILL.md",
"with": "neckbeard",
"guidance": "This bundle verifies stage continuity and outcome evidence; neckbeard verifies the bounded repository change."
},
{
"skill": "../../product-design-and-ux/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle routes UX for embedded workflow adoption; product-lifecycle routes UX for product requirements and lifecycle governance."
},
{
"skill": "../../product-methodology/SKILL.md",
"with": "product-lifecycle",
"guidance": "This bundle uses prioritization only to support engagement generalization; product-lifecycle owns product prioritization and portfolio methods."
}
],
"source": "bundles/forward-deployed-engineering/manifest.yaml#/conflicts"
},
"eval_suite": {
"value": [
"evals/evals.json"
],
"source": "bundles/forward-deployed-engineering/manifest.yaml#/eval_suite"
}
}
},
{
"name": "neckbeard",
"derivation": "manifest",
+90
View File
@@ -11,6 +11,7 @@ the migration path, and the field definitions. Regenerate with
| Bundle | Purpose | Audience | Lifecycle stages | Included skills | Prerequisites | Outputs | Handoffs | Conflicts | Eval suite |
|---|---|---|---|---|---|---|---|---|---|
| agent-production-operations | Operate an evaluated agent with tools and authority in production through a runtime control plane covering versioning, staged rollout, fallback, cost and latency budgets, tool health, human escalation, disablement, and trace-to-eval feedback. | Agent operators and platform teams running evaluated agents with tools and delegated authority in production; agents that need the runtime control decisions between evaluation, release, SRE, security, and platform specialists. | Contract definition → Versioning and rollout planning → Staged rollout → Runtime monitoring → Trace-to-eval feedback → Learning and disablement | agent-evals-and-observability, release-engineering, site-reliability-engineering, secure-software-engineering, platform-engineering, production-readiness, incident-learning, privacy-engineering | Agent evaluation results and observability instrumentation(agent-evals-and-observability); Production-readiness evidence (go/no-go/defer/exception outcomes)(production-readiness); Incident-learning records (verified closure, follow-up work map)(incident-learning); Release pipeline and artifact promotion baseline(release-engineering) | agent-production-contract, runtime-control-plan, staged-rollout-plan, tool-authority-health-record, trace-to-eval-feedback-loop, disablement-record | staged-rollout-plan → release-engineering; trace-to-eval-feedback-loop → agent-evals-and-observability; tool-authority-health-record → incident-learning; disablement-record → human operator | production-readiness (with production-excellence); production-readiness (with product-lifecycle); release-engineering (with production-excellence); release-engineering (with product-lifecycle); site-reliability-engineering (with production-excellence); site-reliability-engineering (with product-lifecycle); secure-software-engineering (with production-excellence); secure-software-engineering (with product-lifecycle); platform-engineering (with production-excellence); platform-engineering (with product-lifecycle); incident-learning (with production-excellence); privacy-engineering (with product-lifecycle) | evals/evals.json |
| forward-deployed-engineering | Carry an embedded technical engagement from ambiguous stakeholder need through discovery, framing, hypothesis, build, evaluation, deployment, adoption, measurement, and generalization while preserving decision rights, evidence, handoffs, and reusable field learning. | Technical leads and agents embedded across stakeholder discovery, implementation, production fit, adoption, and measurable workflow outcomes; this is a continuity layer that routes specialist methods rather than replacing them. | Discover → Frame → Hypothesize → Build → Evaluate → Deploy → Adopt → Measure → Generalize | product-discovery, product-design-and-ux, product-experimentation, agent-evals-and-observability, implementation-planning, backend-engineering, frontend-engineering, data-engineering, qa-methodology, verification-methodology, production-readiness, release-engineering, platform-engineering, remote-systems-administration, product-adoption, product-analytics-and-measurement, site-reliability-engineering, product-lifecycle-learning, product-methodology, privacy-engineering, secure-software-engineering | Stakeholder request or observed workflow opportunity and a named accountable lead; Authority to conduct non-destructive discovery with access to relevant stakeholders or workflow evidence | engagement-charter, stakeholder-workflow-map, assumptions-decisions-risks-ledger, engagement-status, stage-handoff-record, evaluation-and-release-decision, adoption-scorecard, outcome-measurement-record, productization-record, field-learning-record | stage-handoff-record → next lifecycle stage; evaluation-and-release-decision → production-readiness and release specialists; adoption-scorecard → adoption and measurement specialists; productization-record → product, platform, or receiving delivery owner; field-learning-record → engagement sponsor | product-discovery (with product-lifecycle); product-discovery (with research-and-vault); product-experimentation (with product-lifecycle); implementation-planning (with product-lifecycle); production-readiness (with production-excellence); production-readiness (with product-lifecycle); release-engineering (with production-excellence); release-engineering (with product-lifecycle); platform-engineering (with production-excellence); platform-engineering (with product-lifecycle); platform-engineering (with agent-production-operations); secure-software-engineering (with production-excellence); secure-software-engineering (with product-lifecycle); secure-software-engineering (with agent-production-operations); privacy-engineering (with product-lifecycle); privacy-engineering (with agent-production-operations); qa-methodology (with production-excellence); qa-methodology (with product-lifecycle); verification-methodology (with production-excellence); verification-methodology (with product-lifecycle); site-reliability-engineering (with production-excellence); site-reliability-engineering (with product-lifecycle); site-reliability-engineering (with agent-production-operations); data-engineering (with production-excellence); product-adoption (with product-lifecycle); product-analytics-and-measurement (with product-lifecycle); product-lifecycle-learning (with product-lifecycle); agent-evals-and-observability (with agent-production-operations); production-readiness (with agent-production-operations); release-engineering (with agent-production-operations); product-design-and-ux (with neckbeard); product-discovery (with neckbeard); qa-methodology (with neckbeard); release-engineering (with neckbeard); secure-software-engineering (with neckbeard); site-reliability-engineering (with neckbeard); verification-methodology (with neckbeard); product-design-and-ux (with product-lifecycle); product-methodology (with product-lifecycle) | evals/evals.json |
| neckbeard | A disciplined SDLC delivery operating model for non-trivial software change — fix, build, refactor, review, verify, or release — that routes the work through framing, discovery, design, implementation, review, verification, delivery, and learning, choosing the smallest *safe* intervention, proving it at the real delivery boundary, and leaving an inspectable evidence ledger. | Software engineers and agents delivering non-trivial software changes (bug fixes, features, refactors, reviews, releases) that need a bounded, stage-aware path to a defensible 'done' with recorded evidence; teams running issue-to-PR change-request journeys with gates and an authorized release. | Intake and framing → Current-state discovery → Design → Specification → Test planning → Implementation → Review and verification → Readiness and release | product-discovery, software-architecture-analysis, systematic-debugging, api-design-and-evolution, product-design-and-ux, spec-driven-development, qa-methodology, secure-software-engineering, web-accessibility, verification-methodology, technical-documentation, release-engineering, site-reliability-engineering | A non-trivial change request, issue, or task with a verifiable contract; Current-state evidence (repository, tests, config, recent history)(software-architecture-analysis); Change contract and evidence ledger entries(verification-methodology) | change-contract, evidence-ledger, delivery-packet, implementation-plan, verification-report, release-record | verification-report → verification-methodology; release-record → release-engineering; delivery-packet → human reviewer; evidence-ledger → next change (via evidence ledger) | product-discovery (with product-lifecycle); product-design-and-ux (with product-lifecycle); spec-driven-development (with product-lifecycle); qa-methodology (with product-lifecycle); qa-methodology (with production-excellence); secure-software-engineering (with product-lifecycle); secure-software-engineering (with production-excellence); secure-software-engineering (with agent-production-operations); verification-methodology (with product-lifecycle); verification-methodology (with production-excellence); release-engineering (with product-lifecycle); release-engineering (with production-excellence); release-engineering (with agent-production-operations); site-reliability-engineering (with product-lifecycle); site-reliability-engineering (with production-excellence); site-reliability-engineering (with agent-production-operations) | evals/evals.json |
| product-lifecycle | Route a product through its full lifecycle — discovery, strategy and 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. | Product managers, product operations, and portfolio teams navigating a product across multiple lifecycle phases; agents that need to know which specialist skill to load at each phase and what evidence to hand off to the next phase. | Discovery → Strategy and portfolio choice → Roadmap → UX and requirements → Experimentation → Delivery handoff → Adoption → Success → Lifecycle review | product-discovery, product-strategy, strategy-frameworks, product-roadmapping-and-portfolio, product-design-and-ux, product-experimentation, implementation-planning, production-readiness, release-engineering, product-adoption, product-analytics-and-measurement, conditional-customer-success, product-lifecycle-learning, product-methodology, product-operations-and-governance, financial-modeling, go-to-market, data-scientist, spec-driven-development, privacy-engineering, secure-software-engineering, verification-methodology, qa-methodology, site-reliability-engineering, platform-engineering, neckbeard | Product idea, market signal, or stakeholder request; Problem statement and discovery log(product-discovery); Strategic assessment and portfolio decision(product-strategy); Roadmap entry and bet record(product-roadmapping-and-portfolio); UX contracts and acceptance criteria(product-design-and-ux); Experiment readout and assumptions register(product-experimentation) | lifecycle-evidence-ledger, problem-statement, strategic-assessment, roadmap-entry, interface-contracts, experiment-brief, implementation-plan, readiness-verdict, release-plan, adoption-plan, outcome-measurement, outcome-review, lifecycle-decision | readiness-verdict → production-excellence bundle; implementation-plan → delivery team; lifecycle-evidence-ledger → next phase (via evidence ledger); lifecycle-decision → product-lifecycle-learning | production-readiness (with production-excellence); production-readiness (with agent-production-operations); release-engineering (with production-excellence); release-engineering (with agent-production-operations); site-reliability-engineering (with production-excellence); site-reliability-engineering (with agent-production-operations); secure-software-engineering (with production-excellence); secure-software-engineering (with agent-production-operations); platform-engineering (with production-excellence); platform-engineering (with agent-production-operations); privacy-engineering (with agent-production-operations); qa-methodology (with production-excellence); verification-methodology (with production-excellence) | evals/evals.json |
| production-excellence | Route cross-domain production evidence (readiness, migration, recovery, capacity/cost, incident-learning) into a launch or operational decision — go, no-go, defer, exception, or escalation — with an accountable owner and a post-launch learning path. | Service owners, SRE, release, platform, security, data, and QA teams coordinating a production change; agents assembling cross-domain production evidence into a defensible launch decision without re-deriving specialist runbooks. | Cross-domain evidence assembly → Gate evaluation → Operational handoff → Post-launch learning | production-readiness, migration-engineering, resilience-and-recovery, capacity-and-cost-engineering, incident-learning, site-reliability-engineering, release-engineering, platform-engineering, secure-software-engineering, data-engineering, qa-methodology, verification-methodology | Readiness review evidence packet (risk-scaled, 11 categories)(production-readiness); Migration plan, compatibility windows, and reconciliation evidence(migration-engineering); Resilience and recovery evidence (RTO/RPO, restore tests, game days)(resilience-and-recovery); Capacity and cost model evidence (demand, scaling, unit cost)(capacity-and-cost-engineering); Incident history, causal hypotheses, and verified-closure records(incident-learning); SLO and error-budget status(site-reliability-engineering); Release plan and rollback strategy(release-engineering) | gate-decision, operational-handoff-record, accountable-owner-record, evidence-gap-register | operational-handoff-record → incident-learning; operational-handoff-record → product-lifecycle-learning; gate-decision → agent-production-operations; accountable-owner-record → service owner | production-readiness (with product-lifecycle); production-readiness (with agent-production-operations); release-engineering (with product-lifecycle); release-engineering (with agent-production-operations); site-reliability-engineering (with product-lifecycle); site-reliability-engineering (with agent-production-operations); secure-software-engineering (with product-lifecycle); secure-software-engineering (with agent-production-operations); platform-engineering (with product-lifecycle); platform-engineering (with agent-production-operations); incident-learning (with agent-production-operations); qa-methodology (with product-lifecycle); verification-methodology (with product-lifecycle) | evals/evals.json |
@@ -67,6 +68,95 @@ the migration path, and the field definitions. Regenerate with
- privacy-engineering (`../../privacy-engineering/SKILL.md`) with product-lifecycle — Privacy engineering is shared. This bundle routes to it for trace scrubbing and user-data-access grants; product-lifecycle routes to it for PII, consent, retention, and data flows in any phase.
- **Eval suite:** evals/evals.json
### forward-deployed-engineering
- Derivation: `manifest` — source: `bundles/forward-deployed-engineering/manifest.yaml`
- **Purpose:** Carry an embedded technical engagement from ambiguous stakeholder need through discovery, framing, hypothesis, build, evaluation, deployment, adoption, measurement, and generalization while preserving decision rights, evidence, handoffs, and reusable field learning.
- **Audience:** Technical leads and agents embedded across stakeholder discovery, implementation, production fit, adoption, and measurable workflow outcomes; this is a continuity layer that routes specialist methods rather than replacing them.
- **Stages (ordered):**
1. Discover — product-discovery (`../../product-discovery/SKILL.md`), data-engineering (`../../data-engineering/SKILL.md`), remote-systems-administration (`../../remote-systems-administration/SKILL.md`)
2. Frame — product-design-and-ux (`../../product-design-and-ux/SKILL.md`), privacy-engineering (`../../privacy-engineering/SKILL.md`), secure-software-engineering (`../../secure-software-engineering/SKILL.md`)
3. Hypothesize — product-experimentation (`../../product-experimentation/SKILL.md`), agent-evals-and-observability (`../../agent-evals-and-observability/SKILL.md`)
4. Build — implementation-planning (`../../implementation-planning/SKILL.md`), backend-engineering (`../../backend-engineering/SKILL.md`), frontend-engineering (`../../frontend-engineering/SKILL.md`), data-engineering (`../../data-engineering/SKILL.md`)
5. Evaluate — agent-evals-and-observability (`../../agent-evals-and-observability/SKILL.md`), qa-methodology (`../../qa-methodology/SKILL.md`), verification-methodology (`../../verification-methodology/SKILL.md`)
6. Deploy — production-readiness (`../../production-readiness/SKILL.md`), release-engineering (`../../release-engineering/SKILL.md`), platform-engineering (`../../platform-engineering/SKILL.md`), remote-systems-administration (`../../remote-systems-administration/SKILL.md`)
7. Adopt — product-adoption (`../../product-adoption/SKILL.md`), product-design-and-ux (`../../product-design-and-ux/SKILL.md`)
8. Measure — product-analytics-and-measurement (`../../product-analytics-and-measurement/SKILL.md`), agent-evals-and-observability (`../../agent-evals-and-observability/SKILL.md`), site-reliability-engineering (`../../site-reliability-engineering/SKILL.md`)
9. Generalize — product-lifecycle-learning (`../../product-lifecycle-learning/SKILL.md`), product-methodology (`../../product-methodology/SKILL.md`)
- **Included skills:**
- product-discovery (`../../product-discovery/SKILL.md`)
- product-design-and-ux (`../../product-design-and-ux/SKILL.md`)
- product-experimentation (`../../product-experimentation/SKILL.md`)
- agent-evals-and-observability (`../../agent-evals-and-observability/SKILL.md`)
- implementation-planning (`../../implementation-planning/SKILL.md`)
- backend-engineering (`../../backend-engineering/SKILL.md`)
- frontend-engineering (`../../frontend-engineering/SKILL.md`)
- data-engineering (`../../data-engineering/SKILL.md`)
- qa-methodology (`../../qa-methodology/SKILL.md`)
- verification-methodology (`../../verification-methodology/SKILL.md`)
- production-readiness (`../../production-readiness/SKILL.md`)
- release-engineering (`../../release-engineering/SKILL.md`)
- platform-engineering (`../../platform-engineering/SKILL.md`)
- remote-systems-administration (`../../remote-systems-administration/SKILL.md`)
- product-adoption (`../../product-adoption/SKILL.md`)
- product-analytics-and-measurement (`../../product-analytics-and-measurement/SKILL.md`)
- site-reliability-engineering (`../../site-reliability-engineering/SKILL.md`)
- product-lifecycle-learning (`../../product-lifecycle-learning/SKILL.md`)
- product-methodology (`../../product-methodology/SKILL.md`)
- privacy-engineering (`../../privacy-engineering/SKILL.md`)
- secure-software-engineering (`../../secure-software-engineering/SKILL.md`)
- **Prerequisites:**
- Stakeholder request or observed workflow opportunity and a named accountable lead
- Authority to conduct non-destructive discovery with access to relevant stakeholders or workflow evidence
- **Outputs:** engagement-charter, stakeholder-workflow-map, assumptions-decisions-risks-ledger, engagement-status, stage-handoff-record, evaluation-and-release-decision, adoption-scorecard, outcome-measurement-record, productization-record, field-learning-record
- **Handoffs:**
- stage-handoff-record → next lifecycle stage — Each stage receives the current charter, workflow map, ledger, evidence labels, unresolved unknowns, and an explicit entry decision.
- evaluation-and-release-decision → production-readiness and release specialists — A demo or prototype cannot be called production-ready without representative evidence, risk constraints, rollout and rollback evidence, and an authorized decision.
- adoption-scorecard → adoption and measurement specialists — Deployment hands off target workflow, activation path, owner, support path, baseline, and decision rule; adoption remains part of completion.
- productization-record → product, platform, or receiving delivery owner — Field learning is classified with evidence, reuse boundary, owner, and next action rather than being promoted by enthusiasm alone.
- field-learning-record → engagement sponsor — The engagement closes with observed outcomes, unresolved uncertainty, and a durable transfer or follow-up path.
- **Conflicts:**
- product-discovery (`../../product-discovery/SKILL.md`) with product-lifecycle — This bundle uses product-discovery for embedded delivery continuity and workflow context; product-lifecycle owns product investment and lifecycle governance.
- product-discovery (`../../product-discovery/SKILL.md`) with research-and-vault — Use product-discovery for stakeholder and workflow discovery; use research-and-vault for a reusable web-research-to-knowledge capture chain.
- product-experimentation (`../../product-experimentation/SKILL.md`) with product-lifecycle — This bundle routes experiments to test an engagement intervention; product-lifecycle routes product investment experiments within its lifecycle governance.
- implementation-planning (`../../implementation-planning/SKILL.md`) with product-lifecycle — This bundle routes implementation planning only during Build after an authorized owner approves the requirement; product-lifecycle owns product delivery handoff. Route a bounded code change to neckbeard.
- production-readiness (`../../production-readiness/SKILL.md`) with production-excellence — This bundle carries engagement evidence into the specialist readiness review; production-excellence owns the cross-domain launch gate decision.
- production-readiness (`../../production-readiness/SKILL.md`) with product-lifecycle — This bundle routes readiness for an embedded capability; product-lifecycle owns product lifecycle delivery handoff. Do not run both orchestration paths for one decision.
- release-engineering (`../../release-engineering/SKILL.md`) with production-excellence — This bundle routes deployment evidence from the engagement; production-excellence uses release evidence for a launch gate.
- release-engineering (`../../release-engineering/SKILL.md`) with product-lifecycle — This bundle uses release engineering for embedded rollout continuity; product-lifecycle uses it for product delivery handoff.
- platform-engineering (`../../platform-engineering/SKILL.md`) with production-excellence — This bundle routes platform work needed to deploy the engagement capability; production-excellence assembles platform evidence for launch gating.
- platform-engineering (`../../platform-engineering/SKILL.md`) with product-lifecycle — This bundle routes platform work needed by the engagement; product-lifecycle routes platform work in a product delivery handoff.
- platform-engineering (`../../platform-engineering/SKILL.md`) with agent-production-operations — This bundle routes product or engagement platform delivery; agent-production-operations owns runtime agent sandboxing and tool-execution isolation.
- secure-software-engineering (`../../secure-software-engineering/SKILL.md`) with production-excellence — This bundle routes trust-boundary work during the engagement; production-excellence consumes security evidence for its launch gate.
- secure-software-engineering (`../../secure-software-engineering/SKILL.md`) with product-lifecycle — This bundle routes security work in the embedded lifecycle; product-lifecycle routes security work in product lifecycle phases.
- secure-software-engineering (`../../secure-software-engineering/SKILL.md`) with agent-production-operations — This bundle routes application and engagement security; agent-production-operations owns agent authority, disablement, and runtime security controls.
- privacy-engineering (`../../privacy-engineering/SKILL.md`) with product-lifecycle — This bundle routes privacy work for engagement data flows; product-lifecycle routes privacy work across product lifecycle phases.
- privacy-engineering (`../../privacy-engineering/SKILL.md`) with agent-production-operations — This bundle routes engagement privacy decisions; agent-production-operations routes trace scrubbing and user-data-access grants.
- qa-methodology (`../../qa-methodology/SKILL.md`) with production-excellence — This bundle routes quality evidence for the built capability; production-excellence uses QA evidence at the launch gate.
- qa-methodology (`../../qa-methodology/SKILL.md`) with product-lifecycle — This bundle routes evaluation and quality work for engagement delivery; product-lifecycle uses QA at product delivery handoff.
- verification-methodology (`../../verification-methodology/SKILL.md`) with production-excellence — This bundle uses verification to label engagement evidence; production-excellence uses it to verify launch-boundary evidence.
- verification-methodology (`../../verification-methodology/SKILL.md`) with product-lifecycle — This bundle verifies continuity artifacts and field outcomes; product-lifecycle verifies evidence at product phase gates.
- site-reliability-engineering (`../../site-reliability-engineering/SKILL.md`) with production-excellence — This bundle routes reliability evidence for the engagement; production-excellence uses SRE evidence for its production gate.
- site-reliability-engineering (`../../site-reliability-engineering/SKILL.md`) with product-lifecycle — This bundle routes reliability work needed for adoption and operation; product-lifecycle routes SRE work in product delivery handoff.
- site-reliability-engineering (`../../site-reliability-engineering/SKILL.md`) with agent-production-operations — This bundle routes service reliability; agent-production-operations routes runtime latency, cost budgets, and incident handoff for agents.
- data-engineering (`../../data-engineering/SKILL.md`) with production-excellence — This bundle routes data work required by the engagement; production-excellence consumes data evidence in its operational handoff and launch gate.
- product-adoption (`../../product-adoption/SKILL.md`) with product-lifecycle — This bundle owns adoption continuity for an embedded engagement; product-lifecycle owns product adoption as one phase of product governance.
- product-analytics-and-measurement (`../../product-analytics-and-measurement/SKILL.md`) with product-lifecycle — This bundle measures workflow impact for engagement completion; product-lifecycle measures product outcomes in lifecycle review.
- product-lifecycle-learning (`../../product-lifecycle-learning/SKILL.md`) with product-lifecycle — This bundle uses field learning to decide generalization; product-lifecycle-learning owns the product lifecycle learning method and decision record.
- agent-evals-and-observability (`../../agent-evals-and-observability/SKILL.md`) with agent-production-operations — This bundle routes eval evidence for engagement release and learning; agent-production-operations consumes eval and trace evidence for runtime control.
- production-readiness (`../../production-readiness/SKILL.md`) with agent-production-operations — This bundle routes readiness for an embedded capability; agent-production-operations consumes readiness as an authority-gating input.
- release-engineering (`../../release-engineering/SKILL.md`) with agent-production-operations — This bundle uses release engineering for engagement rollout; agent-production-operations uses it for staged runtime rollout and fallback.
- product-design-and-ux (`../../product-design-and-ux/SKILL.md`) with neckbeard — This bundle routes UX for embedded workflow adoption; neckbeard uses UX only as needed for a bounded software change. Route by task boundary.
- product-discovery (`../../product-discovery/SKILL.md`) with neckbeard — This bundle owns embedded stakeholder and workflow discovery; neckbeard handles the bounded change after its requirements are known.
- qa-methodology (`../../qa-methodology/SKILL.md`) with neckbeard — This bundle routes QA for engagement evidence; neckbeard applies QA within its software delivery journey for a bounded repository change.
- release-engineering (`../../release-engineering/SKILL.md`) with neckbeard — This bundle routes release work across the engagement lifecycle; neckbeard owns release delivery for a bounded change.
- secure-software-engineering (`../../secure-software-engineering/SKILL.md`) with neckbeard — This bundle routes security decisions across embedded delivery; neckbeard applies security to its bounded software change.
- site-reliability-engineering (`../../site-reliability-engineering/SKILL.md`) with neckbeard — This bundle routes reliability for engagement outcomes; neckbeard routes reliability concerns within its software delivery journey.
- verification-methodology (`../../verification-methodology/SKILL.md`) with neckbeard — This bundle verifies stage continuity and outcome evidence; neckbeard verifies the bounded repository change.
- product-design-and-ux (`../../product-design-and-ux/SKILL.md`) with product-lifecycle — This bundle routes UX for embedded workflow adoption; product-lifecycle routes UX for product requirements and lifecycle governance.
- product-methodology (`../../product-methodology/SKILL.md`) with product-lifecycle — This bundle uses prioritization only to support engagement generalization; product-lifecycle owns product prioritization and portfolio methods.
- **Eval suite:** evals/evals.json
### neckbeard
- Derivation: `manifest` — source: `bundles/neckbeard/manifest.yaml`
+1
View File
@@ -42,6 +42,7 @@
- [flaresolverr](flaresolverr/SKILL.md): Use the minimal FlareSolverr wrapper for a one-off health check or browser-backed GET/POST when ordinary retrieval is blocked by Cloudflare or DDoS-GUARD. Choose flaresolverr-cli instead for named session lifecycle, cookie-only returns, dry-run planning, or the full operational command surface.
- [flaresolverr-cli](flaresolverr-cli/SKILL.md): Use a small FlareSolverr JSON CLI for browser-backed GET and POST requests, readiness checks, and session lifecycle management when a site requires Cloudflare or DDoS-GUARD challenge handling.
- [forgejo-cli](forgejo-cli/SKILL.md): Use when managing a Forgejo or Gitea server from the terminal: issues, pull requests, repositories, file contents, labels, milestones, releases, webhooks, user settings, or any /api/v1 endpoint through a safe generic API command.
- [forward-deployed-engineering](bundles/forward-deployed-engineering/SKILL.md): Guide embedded technical engagements from ambiguous stakeholder need through discovery, framing, hypothesis, build, evaluation, deployment, adoption, measurement, and generalization while preserving evidence, decision rights, and field learning. Use when one accountable technical lead must carry continuity across customer or stakeholder discovery, implementation, production fit, adoption, and measurable outcomes. Do not use for a bounded repository change, product investment governance, ongoing reliability or platform ownership, an isolated specialist task, or advisory work that ends before implementation and adoption.
- [frontend-engineering](frontend-engineering/SKILL.md): Build and maintain web frontends — component architecture, state management, API integration, responsive layout, client-side performance, and frontend testing patterns. Framework agnostic, focused on web frontend implementation. Do not use for backend service implementation, data engineering, or platform infrastructure work.
- [ghost-cli](ghost-cli/SKILL.md): Manage Ghost CMS content from the terminal — create and list posts, pages, and tags, and fetch site info via the Ghost Admin API (v5/v6). Use when the user asks about ghost, cms, blog, blogging, posts, pages, tags, publishing, or site configuration.
- [github-runner](github-runner/SKILL.md): Deploy, manage, and troubleshoot self-hosted GitHub Actions runners. Covers systemd service, Docker containers, Kubernetes (Actions Runner Controller), and the Scale Set Client. Use when setting up a CI runner, debugging registration failures, designing autoscaling, or hardening runner security.