---
title: 'Integrate with a coding assistant'
description: 'Use a project audit, worker setup, or workflow prompt with your own codebase.'
category: 'Guides'
---

Open your project in your coding assistant, then copy the prompt that matches your next task. Each prompt asks the assistant to inspect your code and the current documentation before choosing an integration.

These prompts are instructions for your coding assistant. They are separate from Pipelogiq's optional [agent SDK](/docs/net/agents), which runs tool-based workflows in your application.

## Audit your project

Use this when you are deciding whether Pipelogiq is useful. It requests a plan and makes no file changes.

```text
Audit this repository for a useful first Pipelogiq integration. Do not modify files.

Read repository instructions. Inspect background jobs, queues, external APIs,
webhooks, retries, and current support tooling. Read https://pipelogiq.com/docs/
and its compatibility page before proposing an SDK or installation command.

Find up to three existing workflows where support asks engineers:
“Did it run?”, “Where did it stop?”, or “What can we safely retry?”

For each, cite relevant files and describe:
- The problem and which team currently handles it.
- Meaningful pipeline stages and existing functions each handler would call.
- Context and outcomes support can safely inspect.
- External side effects, unknown outcomes, and stable idempotency keys.
- The smallest useful integration and its operational limits.

Recommend one workflow. Explain where Pipelogiq adds little value.
Distinguish actual features from custom work and produce an implementation plan.
```

## Set up a worker

Use this after starting a compatible local Pipelogiq server. Keep the application key in local environment configuration.

```text
Set up a minimal local Pipelogiq worker in this project.

Read repository instructions and inspect its language, runtime, logging,
dependency injection, configuration, and deployment conventions.
Read https://pipelogiq.com/docs/quickstart and the matching SDK guide.
Verify server compatibility, package coordinates, versions, and package sources.
Do not substitute older preview packages when current packages are unavailable.

Use the documented .NET or Java HTTP worker where it fits. Register one harmless
typed handler before startup. Configure the API URL and application key through
environment variables. For Java, use the documented Pipelogiq.worker() facade;
let the SDK own readiness and graceful shutdown instead of adding manual lifecycle code.

Submit a matching pipeline, print its ID, wait for its result, and show how to
find the stages and context in the dashboard. Keep external services mocked.
Run a build and a local smoke test. Document exact startup commands, expected
output, and any prerequisite that could not be satisfied.
```

## Build your first workflow

Use this when a specific integration is already selected. It keeps business logic in your existing services.

```text
Integrate one existing workflow with Pipelogiq in this repository.

Read repository instructions, inspect the integration, and verify the current
SDK API using https://pipelogiq.com/docs/. Reuse existing business functions.
Choose a small process that generates recurring questions for support.

Create readable stage names and typed handlers. Expose useful operation IDs,
confirmed outcomes, and next actions in context. Keep secrets and personal
payloads out of general logs. Register every handler used by the pipeline.

Use idempotent pipeline creation. Add stable business-action keys for external
side effects; pipeline idempotency alone does not deduplicate them. Reconcile
unknown external outcomes before retrying. Classify transient failures and
terminal business rejections separately. Bound retries and timeouts.

Test success, a transient failure, rejection, and duplicate delivery with mocked
providers. Run a real local pipeline round trip when infrastructure is available.
Explain what support can diagnose, what Operators can safely do, and which cases
still require an engineer. Report remaining prerequisites accurately.
```

## Review the result

Check that handler names match, package versions resolve from the documented source, and the example completes through the server. Inspect the context as a support user would see it.

For payment-related processes, start with a read-only status reconciliation example. Live mutations belong behind your normal business validation, authorization, and idempotency controls.

Continue with [use cases](/docs/use-cases), [.NET workflows](/docs/net/workflows), or [Java workflows](/docs/java/workflows).