Tutorials

Try it. Check the result.

Four tasks with fictional customer context. Swap in only material you may share.

Analyze meeting notes Fix an integration Keep a customer record Prepare a handoff

Select fde to coordinate, or the named skill for one task. Claude Code plugin: /fdeops:<skill-name>.

Analyze meeting notes

discover

Give it something concrete

Use FDEOps discover. This is a one-off analysis; do not create a customer record. Fictional notes: The support team reads requests from a shared queue. They look up the customer in a CRM and check internal guidance before assigning a team. Some requests wait because the team owner is unclear. We have not measured handling time or waiting time. The sponsor asked for an AI routing assistant. Explain the current process, distinguish evidence from assumptions, and identify the next questions to ask before choosing a solution.

Check the result

Traces the current process step by step
Flags the missing baseline measurements
Questions whether unclear ownership is the main delay

No invented time savings
The AI assistant stays a request, not an agreed solution

Compare solutions with options

Fix an integration

integrate

Before you start

Your own development repository with code and tests you may inspect (no sample app)
Cause unknown? Start with debug
No repository? Do the meeting-notes tutorial first

npx skills add suboss87/fdeops --skill integrate

Ask for the change

Use FDEOps integrate. In this development repository, a request sometimes times out after the upstream system has accepted it. A retry can create a duplicate. Inspect the existing integration and tests, establish how we can determine whether the first write succeeded, and implement the smallest justified fix. Preserve existing behavior outside this case. Run the relevant checks and report anything you cannot verify. Do not deploy or send requests to a live customer system.

Check the result

Shows how requests match upstream results
Reconciles an uncertain write before any retry
Tests cover timeout-after-success and legitimate distinct requests
If the API cannot confirm the result, that limit stays visible

Local tests do not prove it works in the customer's environment. Record the remaining checks and get access before running them.

Review the change

Keep a customer record

fde

Before you start

Install fde using the setup guide, then select a fictional customer in your agent:

Use FDEOps fde for practice-support. Start a continuing customer record for this fictional practice engagement. Help me record a kickoff accurately.

Optional terminal setup

Run from the intended customer workspace.

npx fdeops resume --init practice-support

Review the meeting notes

Review these fictional kickoff notes and propose an update to practice-support. The sponsor requested faster assignment of incoming support requests. Operations said unclear ownership may be the main delay. We have no baseline yet. No rollout date or acceptance owner was agreed. Next action: ask the operations lead for a permitted sample of requests. Keep the requested outcome, open questions and next action separate. Do not fill in a signer, target saving or approval that is not in the notes. Show the proposal before saving it.

Correct the proposal against the notes, then say which update to save. Saving a record update is not customer acceptance.

Return to the work

Resume practice-support. What is the next step? Open the updated fieldbook.

Optional terminal commands

npx fdeops resume

npx fdeops dashboard --all --open

Check the result

Selected record is practice-support
Baseline and acceptance owner show as unresolved
Next action: request the sample from operations
Regenerated fieldbook matches the saved record

Before a customer meeting

Prepare my customer update: what was agreed, what we measured, and which decisions we need at the meeting.

When someone asks what was agreed

What did we agree about the rollout date? Show the source. If there is no agreement in the record, say so.

Cites the supporting record, or says it is missing

Never turns a request into an agreement

Prepare a handoff

handoff

Before you start

A project with known operating requirements and a receiving team
handoff alone, or via fde or the full pack
Drafts from supplied context; exporting a record needs it selected

npx skills add suboss87/fdeops --skill handoff

Prepare the handoff

Use FDEOps handoff with the operating context and runbook below. Identify what the receiving team must be able to do, who has accepted responsibility and what still needs to be rehearsed. Keep unknowns visible. [Add permitted context and the runbook.]

Run the rehearsal

step 1Operator runs the agreed routine and recovery tasks in a test environment
step 2Record where they needed help
step 3Fix the instructions or system, then repeat that task

Export a record when useful

Export the selected customer record to successor.md for the receiving team.

Optional terminal command

npx fdeops handoff --out successor.md

Review before sharing. An export summarizes the record; it does not prove the team can operate the system.

Capture a product finding separately

Needs feedback (also available via fde or the full pack).

npx skills add suboss87/fdeops --skill feedback

Use FDEOps feedback. Turn this observation into a product finding with reproduction steps, affected users, current workaround and open questions. Separate customer-specific details from a potentially reusable improvement. Do not claim that one customer's issue proves demand across customers.

Check the result

Receiving team accepted responsibility and demonstrated the agreed tasks
Every unresolved item has an owner and a next action
Reusable findings reviewed for confidentiality before sharing

Bring FDEOps into your next customer task.

Use one task skill or let fde help you work across the project. Start with the notes or code you already have.

Get started Browse skills