Update to QI

{
  "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.",
  "included_files": [
    {
      "relative_path": "references/coding-standards.md",
      "size_in_bytes": 31123
    },
    {
      "relative_path": "references/errors-and-limits.md",
      "size_in_bytes": 6016
    },
    {
      "relative_path": "references/generated-project-conventions.md",
      "size_in_bytes": 2387
    },
    {
      "relative_path": "references/platform-services.md",
      "size_in_bytes": 7293
    },
    {
      "relative_path": "references/react-design-standards.md",
      "size_in_bytes": 45153
    }
  ],
  "name": "qi-remote-dev",
  "skill_md_contents": "---\nname: qi-remote-dev\ndescription: \"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.\"\n---\n\n# QI remote development\n\nUse 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.\n\n`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.\n\nFor 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.\n\nQI 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.\n\n## Workflow\n\n1. 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.\n2. 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.\n3. 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.\n4. After creation, call `get_development_standards` with `document=checklist` before any file write, then call `get_project_context`, `get_project_status`, and `list_qi_project_directory` with the returned `projectId`.\n5. For an existing app, call `list_projects`. If the user has not identified a project, ask them to choose from the returned names; never invent an ID. Then call `get_development_standards` with `document=checklist` before any file write, and pass that `projectId` explicitly to `get_project_context`, `get_project_status`, file tools, build tools, preview tools, deployment tools, DataPack tools, standards-check, and logs.\n6. For frontend work, read [React design standards](references/react-design-standards.md) or call `get_development_standards` with `document=react-design`. For backend, data, or application-logic work, read [coding standards](references/coding-standards.md) or call it with `document=coding`. Before work involving SharedModule/DataPack, UserModule, platform mail, connectors, authentication/tenant context, branding, or runtime environment contracts, read [platform services](references/platform-services.md) or call it with `document=platform-services`.\n7. Inspect the existing template before editing: `README.md`, `MyApp.csproj`, `Program.cs`, `appsettings.json`, `Data/AppDbContext.cs`, `ClientApp/src/App.tsx`, `ClientApp/src/index.css`, `ClientApp/src/services/api.ts`, and the Header, Sidebar, MobileTabNav, and ThemeProvider components. Derive a feature/completeness checklist from the PRD or skipped prompt. Build on this template instead of replacing it.\n8. Preserve the full-stack contract. Domain records use the generated ASP.NET API, EF Core, and SQLite; browser storage is only for UI preferences such as theme. Entity apps default to complete CRUD. Do not add sample records unless requested.\n9. Use `edit_qi_project_file` for a unique, targeted replacement. Use `write_qi_project_file` for a complete new file or intentional whole-file replacement. Use `delete_qi_project_file` only to remove an obsolete project file; it does not delete directories or protected paths.\n10. Treat concurrent writes as last-write-wins. Re-read a file before a consequential edit when another user or agent may be working on it.\n11. Create a checkpoint at meaningful milestones, especially before a broad change and after a coherent working state.\n12. Use `add_ef_migration` to generate migrations instead of writing migration or snapshot files by hand. Use `check_ef_migrations` to detect pending model changes, `list_ef_migrations` to inspect migrations, `remove_ef_migration` to remove the latest unapplied migration, and `update_ef_database` to apply migrations to the project database. An earlier database target or target `0` rolls back migrations and may delete data; use only when the user requests that rollback.\n13. Call `check_project_standards` after implementation. Fix every blocking violation before proceeding.\n14. Call `build_project`. Use `test_project` to run .NET tests, `restore_project` to restore packages, `clean_project` to remove build outputs, or `check_project_format` to report formatting violations without applying edits. These tools accept no raw arguments.\n15. Run `verify_project`. Strict generated projects cannot verify until template, architecture, browser-storage, demo-removal, and migration checks pass. Verification stops an existing preview before building. Success requests preview startup; failure may leave it stopped.\n16. Use `get_project_preview` to report the QI preview URL and runner availability. Confirm the page loads before claiming the app is ready; runner availability alone is insufficient. Use `get_application_logs` to diagnose selected-project server or frontend runtime failures.\n17. When the user asks to deploy, call `prepare_deployment`. Present the current/next version, deployed URL, code-change state, and every structured DataPack blocker or schema change. Obtain explicit confirmation for that exact preview and any required `copy_test_rows` or `schema_only` choice, then call the destructive `deploy_project` with the returned single-use plan ID. Preview again if it expires or becomes stale. A confirmed no-change redeployment is allowed.\n\nNo general shell MCP tool or raw command input is exposed. Commands outside the .NET and EF allowlists, directory deletion, and rename are unavailable. DataPack MCP tools expose schema only. Call `list_data_packs` and `get_data_pack_schema` for field definitions, relationships, configured tag choices, and asset types. Do not request entity records, sample values, record counts, or tag assignments. Schema writes can only add definitions to the explicit `projectId`'s default linked pack; generated applications retain their normal authorized SharedModule data access. `delete_qi_project_file` permanently removes one regular project file and rejects protected paths and symbolic links. Build and EF operations may also restore declared project packages. Build, test, and EF design-time operations can execute targets or code already declared by the explicit `projectId`, inside its project-bound MCP container, including targets that modify files/data or access external services. `database-update` uses that project's configured development database. Never ask the user for tenant IDs, access tokens, project API keys, internal routes, or certificate data. Use the project ID returned by `create_project` for a newly created app, or by `list_projects` for an existing app. Never invent project IDs.\n\nAlways read [generated project conventions](references/generated-project-conventions.md) before changing a generated QI app. Read [React design standards](references/react-design-standards.md) for frontend implementation, [coding standards](references/coding-standards.md) for backend/data/application implementation, [platform services](references/platform-services.md) for QI module/service integration, and [errors and limits](references/errors-and-limits.md) when a tool rejects an operation.\n\n## Discovery conversation\n\nProduct questions are requirements gathering, not requests for permission to follow this skill. Explain the product decision when context is useful. Avoid quoting internal pacing rules, saying “the skill requires,” or linking local skill files to justify an ordinary discovery question, unless the user asks about the instructions or a higher-priority instruction requires disclosure. Do not ask permission to start gathering requirements; begin with the user's app idea. Keep the separate PRD acceptance and deployment confirmation steps explicit.\n\nFor example, for “Help me build a todo list app,” introduce the first question naturally: “I'll help you define the app's requirements, then show you the requirements document for approval before building. Would you like one simple checklist, or separate lists for things like work, home, and shopping?” That question starts discovery. Continue with relevant follow-up questions after the answer, then prepare both documents when the requirements are clear.\n"
}