Add AI Pass to an Existing App Without Moving Hosting or Auth

Map the existing action before adding another integration

For an agent working inside an established product, “add AI Pass” is not permission to move the product. Start by tracing one existing user action from its button through authorization, data loading, provider invocation, and result persistence. Hosting and identity should appear on that map as existing infrastructure, not empty boxes awaiting replacement.

Imagine an illustrative maintenance portal called Workshop. Technicians sign in through the company's existing identity service. A backend constructs repair-summary prompts from private service records. The frontend is already deployed, and a queue processes longer maintenance reports. The smallest useful AI Pass integration is an optional route for the interactive repair summary, not a rewrite of the queue, account system, and deployment.

The canonical integration skill requires preserving existing deployment and authentication. It prefers a browser SDK where suitable, but private server-side prompts and restrictive runtime policies can justify backend OAuth. The repository inspection determines which condition actually applies.

Inspect for evidence, not familiar filenames

Locate manifests and lockfiles first. Then identify the actual framework entry points, test commands, session middleware, AI wrappers, billing checks, and deployment configuration. Filenames below illustrate findings an agent might record; they are not a claim about your repository.

Artifact	Observed responsibility	Planned treatment
server/repairSummary.ts	Loads private records and invokes provider	Add an explicit adapter selection
server/session.ts	Resolves signed-in technician	Preserve unchanged
ui/SummaryAction.tsx	Starts interactive summary	Add route status and pending state
jobs/reportWorker.ts	Generates scheduled reports	Exclude from first change
deploy/service.toml	Existing deployment target	Preserve target and build command

Confirm each responsibility by following imports and callers. A file named “auth” may only format headers; a provider wrapper may also deduct host credits. Search for side effects before deciding where a new route belongs.

Produce an artifact plan with explicit exclusions

The plan should name files or modules, intended behavior, tests, and rollback. It should not merely say “install SDK and connect wallet.” Workshop's backend retains custody of private prompt assembly, while the host session continues authorizing access to service records. The AI Pass connection is a separate authorization relationship for inference, not a replacement technician identity.

Use the REST documentation and the canonical skill's backend OAuth reference for the chosen implementation. If inspection instead finds a public client-side action that meets policy, consult the SDK documentation. Do not weaken content security policy merely to fit the browser path.

A useful artifact plan includes these distinct deliverables:

• A dependency diagram showing the summary route and existing authorization checks.
• A narrow adapter interface that returns the app's existing summary result type.
• An explicit route selector whose default preserves current behavior.
• Connection-state UI that does not impersonate the host's login screen.
• Tests for record authorization, route selection, and unchanged scheduled jobs.
• A rollback switch that disables new AI Pass starts without erasing pending work.

Unknown callback origins belong in a blocker list. Determine exact runtime callbacks before provisioning; follow the canonical setup procedure rather than asking for runtime tokens or inventing client-registration calls.

Prove that the surrounding product stayed put

Run the repository's documented checks using its existing package manager and lockfile. Test a signed-out repair-summary request, a technician requesting another team's record, and an existing direct-provider action. Each should retain its prior authorization or routing result. A wallet connection must not grant access to someone else's service history.

Inspect the changed-file list for accidental deployment edits, identity migrations, or broad dependency upgrades. A new integration rarely justifies replacing unrelated infrastructure. If a necessary change expands the scope, report it before treating the expanded plan as approved.

Use the public model catalog only for discovery. Reading it does not validate authenticated inference or authorize spending. A local fake can prove the summary result renders, but cannot prove the user's wallet funded anything.

Hand off an implementation-sized boundary

Workshop's first milestone is the interactive summary path with existing login, storage, hosting, and scheduled reports preserved. Record what was built, which checks actually ran, and which approvals or environment values remain unavailable. If no approved real call occurred, label live wallet-funded verification pending. The artifact plan succeeds when another engineer can implement or review the narrow change without guessing what must remain untouched.

---
name: aipass-existing-app-artifact-plan
description: Use when adding AI Pass to an existing app. Inspect the repository and plan the smallest change without moving hosting or login.
---

# Existing application artifact plan

## Scope and prerequisites
Produce a repository-grounded integration plan for one visible action. Require an identified repository and approved optional AI Pass intent. This planning skill does not authorize edits, deployment, setup mutations, or inference spending.

## Inspection procedure
1. Read manifests, lockfiles, documented commands, and deployment files. Follow actual imports rather than assuming a framework from filenames.
2. Trace one AI action through UI, host session, resource authorization, prompt assembly, provider wrapper, billing side effects, persistence, and error rendering.
3. Identify queue callers and scheduled work that share the wrapper; explicitly exclude them or document why they must change.
4. Read the [canonical integration skill](https://aipass.one/skills/aipass-integration/SKILL.md), then its path-decision and existing-auth-and-billing references. Read the SDK path for permitted browser actions or backend OAuth for private server prompts and policy-restricted runtimes. Derive exact OAuth mechanics only from those references.
5. Preserve current hosting, identity, subscriptions, credits, storage, and direct provider routes. Never select Spaces merely because AI Pass is being added.
6. Map proposed artifacts to their actual repository paths, intended changes, tests, dependencies, and rollback. Mark unknown callback origins as blockers before any later provisioning.
7. Review the plan for unrelated migrations, dependency upgrades, and hidden host-credit deductions.

## Required output
- `action-map.md`: observed call chain, evidence paths, authorization and billing side effects.
- `artifact-plan.md`: file-by-file change table, integration path rationale, exclusions, callback requirements, and approval blockers.
- `preservation-checks.md`: signed-out access, cross-user resource access, existing BYOK, scheduled work, deployment target, and rollback checks.

## Acceptance
Another engineer can locate every proposed change and every preserved boundary. Unknowns are visible rather than filled with imaginary repository facts. Link [SDK docs](https://aipass.one/docs/sdk) and [REST docs](https://aipass.one/docs/rest) as appropriate. Report the plan as inspected and proposed, never as implemented, deployed, or wallet-funded verified.