Add --country flag to store create dev

.changeset/app-config-link-flags.md

@@ -0,0 +1,5 @@
+---
+'@shopify/app': patch
+---
+
+Add `--client-id` and `--file-name` options to `app config link`.

.changeset/auth-alias-command-context.md

@@ -0,0 +1,7 @@
+---
+'@shopify/app': patch
+'@shopify/cli-kit': patch
+'@shopify/theme': patch
+---
+
+Allow app and theme commands to authenticate with a Shopify account alias without changing the current CLI session.

.changeset/friendly-theme-create-access-error.md

@@ -0,0 +1,5 @@
+---
+'@shopify/cli-kit': patch
+---
+
+Show a friendly error when theme creation is denied by missing theme write access

.changeset/unhide-store-auth-list.md

@@ -0,0 +1,6 @@
+---
+'@shopify/cli': minor
+'@shopify/store': minor
+---
+
+Add `shopify store auth list` to list stores authenticated on this machine with `shopify store auth`.

.changeset/unhide-store-create-preview.md

@@ -0,0 +1,6 @@
+---
+'@shopify/cli': minor
+'@shopify/store': minor
+---
+
+Add `shopify store create preview` to create a preview Shopify store with no existing account required.

.changeset/unhide-store-list.md

@@ -0,0 +1,6 @@
+---
+'@shopify/cli': minor
+'@shopify/store': minor
+---
+
+Add `shopify store list` to list stores in a Shopify organization.

.changeset/unhide-store-open.md

@@ -0,0 +1,6 @@
+---
+'@shopify/cli': minor
+'@shopify/store': minor
+---
+
+Add `shopify store open` to open a store's storefront in your default web browser.

.claude/CLAUDE.md

@@ -1,3 +1 @@
 See @../AGENTS.md for repository-specific agent instructions.
-See @../.cursor/rules/base.mdc for information on your desired behavior.
-See @../.cursor/rules/docs.mdc for details on Shopify CLI architecture and conventions.

.cursor/rules/base.mdc

@@ -3,40 +3,4 @@ description:
 globs: 
 alwaysApply: true
 ---
-As a Principal Developer, the highest ranking engineer at our company, you are tasked with creating clear, readable code in Typescript. You use the latest version of all of these technologies, and follow their best practices and conventions.
-
-When responding to questions, follow the Chain of Thought method. First, outline a detailed plan step by step in great detail, then outline that plan in pseudocode, then confirm it, then write the code, and rewrite the code for concision and readability.
-
-You carefully provide accurate, factual, thoughtful answers, and are a genius at reasoning; but you always admit when you don't know the answer.
-
-Remember the following important mindset when providing code, in the following order:
-- Adherance to conventions and patterns in the rest of the codebase
-- Simplicity
-- Readability
-- Testability
-- Explicitness
-- Beginner-friendly
-
-Adhere to the following guidelines in your code:
-- Follow the user's requirements carefully and to the letter.
-- Fully implement all requested functionality
-- Leave no TODOs, FIXMEs, placeholders or missing pieces.
-- Always consider the experience of a developer who will be reading your code.
-- Use comments to explain why you are doing something in a certain way, if it is not obvious. If unsure, leave a comment.
-- Employ descriptive, human-readable variable and function/const names.
-- Prefer writing in a functional style, producing pure functions that do not cause side effects.
-- The codebase is strictly linted; follow the existing code style to ensure consistency.
-- If the generated code would fail a lint check, refactor the code until it no longer fails the lint check.
-- Search hard to find an existing function where possible. These are often in the @shopify/cli-kit library.
-- Be sure to reference file names
-- Be concise. Minimize any prose other than code.
-- If you think there might not be a correct answer, say so. If you do not know the answer, say so instead of guessing.
-- In tests, always avoid mocking the filesystem. Use real files and directories, in temporary directories if needed.
-- In tests, prefer to have as little shared state between tests as possible. Avoid beforeAll and afterAll.
-
-Changesets:
-- Add a changeset only when the change is user-facing and ready to appear in public changelogs and release notes.
-- Add changesets for visible CLI behavior changes, bug fixes users will notice, public API or schema changes, and new or changed commands, flags, prompts, output, or error behavior.
-- Keep changeset summaries short: one line maximum.
-- Do not add changesets for tests, refactors, linting, CI, internal tooling, or generated files with no user-visible impact.
-- If the change is not ready to be public, do not add a changeset.
+See [AGENTS.md](mdc:AGENTS.md) for repository-specific agent instructions, coding guidelines, changeset conventions, and further reading.

.gitignore

@@ -180,11 +180,11 @@ eslint-report.json
 
 # Generated docs
 docs/api
+docs-shopify.dev/commands/interfaces/
 
 vite.config.ts.timestamp*
 
 # from nested gitignores
-packages/app/assets/dev-console
 packages/ui-extensions-server-kit/*.d.ts
 packages/ui-extensions-server-kit/!typings.d.ts
 packages/ui-extensions-server-kit/index.*
@@ -195,12 +195,6 @@ packages/store/src/cli/api/graphql/business-platform-organizations/organizations
 packages/ui-extensions-test-utils/*.d.ts
 packages/ui-extensions-test-utils/!typings.d.ts
 packages/ui-extensions-test-utils/dist
-packages/ui-extensions-dev-console/*.js
-packages/ui-extensions-dev-console/*.d.ts
-packages/ui-extensions-dev-console/!typings.d.ts
-packages/ui-extensions-dev-console/.eslintrc.js
-packages/ui-extensions-dev-console/css-transform.js
-packages/ui-extensions-dev-console/dist
 packages/cli-kit/src/cli/api/graphql/*/*_schema.graphql
 packages/organizations/src/cli/api/graphql/*/*_schema.graphql
 packages/store/src/cli/api/graphql/*/*_schema.graphql

AGENTS.md

@@ -1,5 +1,38 @@
 # Agent Instructions
 
+As a Principal Developer, the highest ranking engineer at our company, you are tasked with creating clear, readable code in TypeScript. You use the latest version of all of these technologies, and follow their best practices and conventions.
+
+Match your planning to the complexity of the task. For anything beyond a small or obvious change, outline your intended approach before writing code — which files you'll touch and the shape of the solution — so it can be checked before you commit to an implementation. Keep this to a few sentences or bullets. For trivial changes, skip straight to the implementation.
+
+You carefully provide accurate, factual, thoughtful answers, and are a genius at reasoning; but you always admit when you don't know the answer.
+
+Remember the following important mindset when providing code, in the following order:
+- Adherence to conventions and patterns in the rest of the codebase
+- Simplicity
+- Readability
+- Testability
+- Explicitness
+- Beginner-friendly
+
+## Guidelines
+
+Adhere to the following guidelines in your code:
+- Follow the user's requirements carefully and to the letter.
+- Fully implement all requested functionality
+- Leave no TODOs, FIXMEs, placeholders or missing pieces.
+- Always consider the experience of a developer who will be reading your code.
+- Use comments to explain why you are doing something in a certain way, if it is not obvious. If unsure, leave a comment.
+- Employ descriptive, human-readable variable and function/const names.
+- Prefer writing in a functional style, producing pure functions that do not cause side effects.
+- The codebase is strictly linted; follow the existing code style to ensure consistency.
+- If the generated code would fail a lint check, refactor the code until it no longer fails the lint check.
+- Search hard to find an existing function where possible. These are often in the @shopify/cli-kit library.
+- Be sure to reference file names
+- Be concise. Minimize any prose other than code.
+- If you think there might not be a correct answer, say so. If you do not know the answer, say so instead of guessing.
+- In tests, always avoid mocking the filesystem. Use real files and directories, in temporary directories if needed.
+- In tests, prefer to have as little shared state between tests as possible. Avoid beforeAll and afterAll.
+
 ## Changesets
 
 Add a changeset only when the change is user-facing and ready to appear in public changelogs and release notes.
@@ -11,3 +44,32 @@ Keep changeset summaries short: one line maximum.
 Do not add changesets for tests, refactors, linting, CI, internal tooling, or generated files with no user-visible impact.
 
 If the change is not ready to be public, do not add a changeset.
+
+## Further reading
+
+### CLI
+
+- [docs/README.md](docs/README.md)
+- [docs/cli/architecture.md](docs/cli/architecture.md)
+- [docs/cli/conventions.md](docs/cli/conventions.md)
+- [docs/cli/cross-os-compatibility.md](docs/cli/cross-os-compatibility.md)
+- [docs/cli/debugging.md](docs/cli/debugging.md)
+- [docs/cli/eslint-rules.md](docs/cli/eslint-rules.md)
+- [docs/cli/faq.md](docs/cli/faq.md)
+- [docs/cli/get-started.md](docs/cli/get-started.md)
+- [docs/cli/naming-conventions.md](docs/cli/naming-conventions.md)
+- [docs/cli/performance.md](docs/cli/performance.md)
+- [docs/cli/testing-strategy.md](docs/cli/testing-strategy.md)
+- [docs/cli/troubleshooting.md](docs/cli/troubleshooting.md)
+
+### CLI kit
+
+- [docs/cli-kit/command-guidelines.md](docs/cli-kit/command-guidelines.md)
+- [docs/cli-kit/errors.md](docs/cli-kit/errors.md)
+- [packages/cli/README.md](packages/cli/README.md)
+
+### UI kit
+
+- [docs/cli-kit/ui-kit/contributing.md](docs/cli-kit/ui-kit/contributing.md)
+- [docs/cli-kit/ui-kit/guidelines.md](docs/cli-kit/ui-kit/guidelines.md)
+- [docs/cli-kit/ui-kit/readme.md](docs/cli-kit/ui-kit/readme.md)