QI

View saved version →

---
name: qi-prd-acceptance
description: "Review, revise, and explicitly accept a QI application PRD draft after provide_prd and before create_project. Use after provide_prd saves a draft, the user asks to inspect or edit the pending PRD, or create_project reports that a draft still needs acceptance."
---

# QI PRD acceptance

Use the server draft as the source of truth. Call `get_prd_draft` at the start, even when the documents were just submitted. Do not reconstruct the draft from conversation memory.

Present the complete persisted documents to the user before requesting approval. Use clearly labelled `Product Requirements Document` and `Technical Requirements` sections and include the full markdown returned by `get_prd_draft`. Do not summarize, abbreviate, elide sections, replace content with placeholders, or merely offer the complete documents on request. A short introduction may precede them, but it cannot replace either document.

After displaying both complete documents, ask whether the exact draft is approved or needs changes. This is an approval gate: silence, moving to another topic, a general request to continue, or approval given before the complete current documents were displayed is not approval. Accept only an explicit statement that the displayed PRD and Technical Requirements are approved, accepted, correct, or ready to create.

If the user requests edits, update whichever document is affected, preserve unaffected content, and call `update_prd` with both complete replacement documents. Then call `get_prd_draft` again and display both refreshed documents in full before asking for approval again. Repeat until the user explicitly approves the exact current documents. Never call `accept_prd` in the same response that first displays a new or edited draft.

If the user asks a question about the draft, answer it without treating the question as approval. If the answer changes either document, update the persisted draft and display both complete refreshed documents again before returning to the approval question.

After explicit approval, call `accept_prd` exactly once. Report that the documents are locked, then return to the `qi-remote-dev` workflow and call `create_project` with the agreed name and description. If the server reports the draft is already accepted, do not attempt edits; continue to project creation. If it reports expiry, restart through `start_prd_discovery` and explain that the prior draft expired.

The `skip_prd` path is outside this skill and remains valid only when the user explicitly asks to skip PRD discovery.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: qi-remote-dev
description: "Use the QI Platform MCP app for PRD-guided, template-based, standards-enforced full-stack development: discover, review and accept a new-app PRD (or explicitly skip it), create or identify an authorized project, use QI platform services and DataPacks, inspect and edit code, migrate EF Core, diagnose logs, preview, verify, and deploy with confirmation."
---

# QI remote development

Use this skill when working through the QI Platform app. OAuth binds the connection to exactly one tenant. For a new app, call `start_prd_discovery` before asking discovery questions or creating anything. Follow those instructions conversationally and call `provide_prd` once with the completed PRD and Technical Requirements. That creates a draft: call `get_prd_draft`, display both complete documents, request explicit approval, and call `accept_prd` only after approval. The `qi-prd-acceptance` skill provides this workflow when available; it is not required to use the MCP tools. Do not call `create_project` until acceptance succeeds. If the user explicitly asks to skip discovery and build directly from their simple prompt, call `skip_prd` exactly once after loading the instructions, then call `create_project`. Never infer that the user wants to skip merely because their initial prompt is short.

`create_project` consumes the pending PRD decision for this OAuth connection, saves supplied documents on the new project, copies the standard React + ASP.NET template, moves the project directly into development, and returns the new project ID for subsequent explicit tool calls. Do not call `list_projects` or ask the user to choose a project for an explicitly new app. Infer the concise project name and description only after discovery is submitted or explicitly skipped.

For existing-project work, call `list_projects`, then pass a returned `projectId` explicitly on every project, file, build, checkpoint, preview, EF, deployment, DataPack, standards-check, and log tool call. Reconnecting is required to change tenants, but not to switch projects inside the connected tenant.

QI routes each project-scoped tool call to a project-bound MCP container that mounts that project's code at `/workspace/code` and its development data at `/data`, both writable. The data mount is shared with the project's development preview so EF commands update the same SQLite database. Production data and other projects' data are not mounted. Passing `projectId` explicitly prevents one chat or agent from changing another chat's effective working project.

## Workflow

1. Classify the request as new-app creation or existing-project work. “Create/build/make me a new … app” is new-app creation unless the user identifies an existing project.
2. For a new app, call `start_prd_discovery` first. Briefly explain that you are gathering the app's requirements and will show the requirements document for approval before building, then ask the first relevant product question in the same response. Continue from the user's existing prompt and answers, asking focused questions until the requirements are clear. Treat QI authentication, server-side database persistence, tenant-shared records, full entity CRUD, and retention through workflow state changes as defaults; do not ask the user to reconfirm them, and raise deviations or optional features only when the request makes them consequential. Do not create a project or write files during discovery.
3. When discovery is complete, call `provide_prd` exactly once with both complete documents. Call `get_prd_draft` to retrieve the persisted server draft and display the complete PRD and complete Technical Requirements to the user before asking for approval. After any edit, retrieve and display both complete documents again. Call `accept_prd` only after the user explicitly approves the exact displayed documents, then call `create_project`. If the user explicitly chose to skip, call `skip_prd` exactly once instead.
4. After 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.