Skip to content
Tutorials

Try it. Check the result.

Start with a one-off analysis, a code change or a continuing customer record. The examples below use fictional customer context. Replace it only with material you are permitted to share.

Select fde to coordinate the work, then continue in plain language. For a single task, use the named skill below. In the Claude Code plugin, select /fdeops:<skill-name>. Other agents use their own skill picker or invocation syntax.

01 / Analyze meeting notes

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

The response should trace the current process, identify missing baseline measurements and question whether unclear ownership is the main delay. It should not invent time savings or treat the requested AI assistant as an agreed solution.

Compare solutions with options

02 / Fix an integration

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

The agent should identify how requests are matched to upstream results and how an uncertain write is reconciled before another write occurs. Evidence should cover the timeout-after-success case and legitimate distinct requests. If the upstream API offers no safe way to establish the result, that limitation must remain visible rather than be hidden behind automatic retries.

Passing local tests does not prove the integration works in the customer's environment. Record the remaining integration checks and obtain the required access before running them.

Review the change

03 / Keep a customer record

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.

Check the proposal against the notes. Correct it, then tell the agent which update to save. Human confirmation of a record update is not customer acceptance of the project.

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

The selected record should be practice-support. The summary should show the baseline and acceptance owner as unresolved, with the sample request as the next action. The fieldbook should reflect the saved record after regeneration.

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.

A good result locates the supporting record or clearly states that it is missing. It does not turn a request into an agreement.

04 / Prepare a 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

Ask the receiving operator to perform the agreed routine and recovery tasks in an appropriate test environment. Record where they need help. Update the instructions or system, then repeat the affected 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 the snapshot before sharing. An export is a summary of the record, not proof that the receiving team can operate the system.

Capture a product finding separately

If you installed only handoff, install feedback for this separate task. It is also available through 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

The receiving team has accepted the relevant responsibilities and demonstrated the agreed tasks. Unresolved items have owners and next actions. Reusable findings have been reviewed for customer confidentiality before sharing.