fde-core

Plugin fde-core from marketplace fde-skills in rpraharaj/forward-deployed-engineer. Commands read from the repo's manifest — 12 days ago.

Skills (34)

• access-and-onboarding

  Turn getting access into a tracked critical path instead of a passive wait. Enumerate every credential, permission, environment, and account the engagement needs, identify who approves each and its lead time, request long-lead items first, find workarounds for what is blocked, and keep a queue of us

• adoption-plan

  Plan and assess how intended end users move to a new business workflow, including barriers, process ownership, a bounded pilot, support, fallback, and successful-use measures. Use when a live solution is underused, users keep an old workaround, or rollout needs changes to daily work. Training the re

• blast-radius

  Map everything a proposed change could break before making it - direct callers, cross-repository consumers, published contracts, event subscribers, feature flags, shared database objects, and config coupling - ending with a risk rating and the specific things to verify. Use before any non-trivial ch

• change-control-navigation

  Find and work with the organization's change process before it blocks you - which gates apply, what evidence each requires, submission deadlines, freeze periods, release calendars, and segregation of duties - then work backwards from the release window. Use early in any engagement that will reach pr

• characterization-tests

  Pin the current behavior of untested legacy code before changing it - including behavior that looks like a bug, because something downstream may depend on it - using golden master and approval test patterns so a refactor or fix can be verified as behavior-preserving. Use before modifying code with t

• context-strategy

  Work effectively in a codebase far larger than any context window, across an engagement that spans many sessions. Decide what to read versus search versus script versus delegate, maintain a durable working guide so each session does not re-derive the same map, define a working set, and hand off clea

• delivery-plan

  Sequence work by risk rather than convenience - unknowns first so bad news arrives early, slices that are independently shippable, dependencies on other teams surfaced with lead times, and an explicit statement of what would change the plan. Use once feasibility and estimation exist and someone want

• deploy-runbook

  Write the executable deployment procedure - pre-checks, ordered steps, what to observe after each, the specific conditions that trigger a rollback, and the rollback procedure itself - so that someone who is not the author can run it at 2am. Use before the first deploy of anything new or risky, when

• enablement-handoff

  Teach the receiving team to operate and extend what you built, rather than only documenting it - pairing, walkthroughs, deliberately leaving work for them to finish, and confirming they can actually run it without you. Use when an engagement is ending and the team must continue without you, when you

• env-bootstrap

  Get a working build, test, and run loop in an unfamiliar repository on a locked-down machine - read the CI config as ground truth for how the software is actually built, check toolchain versions against the repo's pins, configure internal registries and proxies, start required services, and record e

• escalation-and-renegotiation

  Raise a problem early with evidence and a recommendation, or reopen scope without losing credibility - when the plan is no longer achievable, a dependency is not moving, the requirement turns out to be wrong, or you are being asked to commit to something you believe is not deliverable. Use as soon a

• estimation

  Size work under genuine uncertainty, grounded in feasibility findings rather than optimism - ranges rather than points, explicit assumptions, the organizational overheads engineers routinely forget, and a clear statement of what would move the number. Use when asked how long something will take, whe

• fde-orient

  Open a new engagement as a forward deployed engineer - establish what you have actually been asked to do, classify the engagement type, set up the .fde workspace, and produce a sequenced plan of which skills to run. Use when starting at a new client, joining an unfamiliar team, being assigned to a p

• feasibility-probe

  Ground a specification in the actual codebase - for each requirement establish whether the capability already exists, exactly where a change would land, what shape the change takes, what is missing entirely, and which items look cheap but are not. Use after a spec exists and before anyone estimates,

• git-archaeology

  Recover intent from history when code looks wrong - blame to commit to pull request to linked ticket, plus revert and hotfix patterns - so you find out why something is the way it is before removing it. Use when code looks unnecessary or bizarre, before deleting anything odd, when a constant or spec

• handover-pack

  Consolidate an engagement into what the receiving team actually needs - refreshed working guide, runbooks, ADRs, known issues, and explicitly the open risks and unfinished business that most handovers omit. Use when an engagement is ending, when rotating to another team, when someone else will take

• incident-triage

  Work backward from a production symptom to its cause under time pressure - stack trace to source, correlation IDs across services, log and metric narrowing, recent-change correlation - while prioritizing mitigation over root cause and saying explicitly which one you are doing. Use when production is

• knowledge-interview

  Extract what only a person knows - structured preparation and questioning for a short session with a long-tenured engineer, system owner, or business expert, then conversion of what you learn into cited artifacts. Use before or after meeting someone who knows a system you do not, when the code canno

• nfr-baseline

  Make non-functional requirements explicit and measurable before build starts - latency and throughput targets, data sensitivity classification, audit and retention obligations, observability needs, and failure and degradation behavior - each written as something you can actually test. Use before bui

• nfr-validation

  Actually measure the non-functional requirements rather than asserting them - performance under realistic load, behavior at failure boundaries, and whether the audit logging exists and contains what it should - reporting measured numbers with the conditions they were measured under. Use before relea

• outcome-measurement

  Define and baseline the business benefit of an engagement, then compare observed results with the original claim, costs, and measurement limits. Use when success has no agreed business measure, a sponsor asks whether delivery created value, or projected savings need checking. Technical latency/load

• ownership-map

  Work out who owns what and who decides, from evidence rather than the org chart - CODEOWNERS, commit authorship over time, review patterns, ticket references, and directory-level activity - distinguishing who wrote the code from who maintains it now. Use when you need a reviewer, an approver, or an

• release-readiness

  Assemble an evidence-based go/no-go position for a release - gather what prior artifacts already established, assess each readiness dimension as green, amber or red, state the recommendation together with the residual unknowns, and format it to survive a change advisory board. Use when approaching g

• repo-recon

  Build a breadth-first map of an unfamiliar codebase in a bounded amount of time - entry points, module boundaries, persistence and integration surface, churn hotspots, test topology, config surface, and landmines - then write it up as a durable system map plus a durable working guide. Use when dropp

• requirements-to-spec

  Turn a vague ask into a testable specification - separate the stated request from the underlying need, write acceptance criteria as observable behavior, state what is explicitly out of scope, and record every assumption with who can confirm it. Use when handed an ambiguous requirement, a one-line ti

• safe-change

  Implement an already-specified change in an unfamiliar or high-stakes codebase with the smallest viable diff - establish a green baseline first, match the surrounding idiom rather than importing your own, separate refactor commits from behavior commits, gate behind a flag where blast radius warrants

• security-compliance-check

  Review a change specifically for data handling before release - what sensitive data crosses this path, whether it is logged or cached, encryption in transit and at rest, secrets externalized, and whether the audit trail satisfies the stated obligation. Use as a pre-release gate on anything touching

• solution-design

  Generate genuine alternatives for a non-trivial change - including do-nothing and solve-it-outside-this-system - evaluate them against the real constraints already established, recommend one, and record why the others were rejected, as an ADR that survives your departure. Use when a change has more

• stakeholder-brief

  Translate the current technical position into something a busy non-engineer reads in ninety seconds - what changed, what it means, what decision is needed, what the risk is - pitched at the right register for the reader. Use at every phase boundary rather than only at the end, when a sponsor or deli

• test-data-strategy

  Get realistic test data in an organization where production data cannot be copied - synthesis, subsetting, masking with referential integrity preserved, and fixtures for the awkward edge cases that only real systems produce. Use when tests need data you do not have, when verification is blocked beca

• trace-the-flow

  Follow one concrete business operation end to end through every layer and process boundary - entry point, orchestration, persistence, messaging, downstream calls, and the error and retry paths - producing a sequence narrative with a citation at every hop. Use when you need to know how something actu

• use-case-selection

  Compare competing customer problems or potential use cases and recommend where an engagement should start, using impact evidence, data readiness, feasibility, sponsorship, risk, and time to first value. Use when there are several opportunities and no chosen problem. Sequencing already-scoped work is

• verification-plan

  Map every acceptance criterion to the specific evidence that proves it - which test, which manual check, which measurement - and surface the gap list of criteria with no verification at all. Use once implementation is underway, before claiming anything is done, before a release decision, or when som

• workflow-discovery

  Map how people actually carry out a business process by walking real cases, handoffs, waits, exceptions, and workarounds. Use when the current process is disputed or undocumented, users rely on email or spreadsheets, or the problem needs understanding before requirements are chosen. Following a code