## Resolve the project slug

This prompt takes no slash-arguments — the project slug is resolved from
the user's environment BEFORE any other work. Source priority — first hit
wins:

### Source 1 — User's message

If the user named a project in their latest message (e.g. "use
daycationist", "for task360-prod", or just typed the slug as a single
word after the slash command), treat it as an explicit override. Call
`get_project({project: <that-slug>})` to confirm it exists and the
authenticated API key can access it.

- 200 OK → use this slug. Do not announce; the user named it, they know.
- 404 → STOP with a clear error: `Project "<slug>" not found or not
  accessible by the current API key. Check the slug spelling, or rephrase
  without naming a project to pick from your accessible list.` Do NOT
  fall through — explicit user intent is a contract; a typo is a hard
  error, not a reason to silently pick a different project.

### Source 2 — `.pinappai/context.json`

If the user did not name a project, read `.pinappai/context.json` at the
repo root. If the file exists and has a `project` field with a non-empty
string, call `get_project({project: <that-slug>})`.

- 200 OK → use this slug. Announce in one line: `Using project: <slug>
  (from .pinappai/context.json).`
- 404 → tell the user `.pinappai/context.json is bound to project "<slug>"
  but it's no longer accessible — running discovery instead.` Then fall
  through to Source 3. This handles project renames, archives, or
  workspace switches without forcing the user to hand-edit the file.

### Source 3 — `list_projects` MCP tool

If sources 1 and 2 didn't resolve, call `list_projects()` (takes no
arguments — returns every project the authenticated API key can access
in its workspace).

- **Zero projects** → STOP with: `No projects accessible in this
  workspace. Run /pinappai:setup-project to create one.`
- **One project** → auto-select. Announce: `Workspace has one project:
  <slug> — using it.` so the user can Ctrl+C if it's wrong.
- **Multiple projects** → present them numbered with slug + name (and
  `domain` if non-null). Ask `Which project? [1-N]` and WAIT for the
  answer. No silent default.

### After resolving from Source 3 (or after Source 2 fell through)

Offer to bind the resolved slug to the repo so future prompts skip this
block entirely. Read `.pinappai/context.json` if it exists, merge the
new `project: "<slug>"` field with existing keys (do NOT overwrite
unrelated fields like `text_lives_in`, `framework`, etc.), and ask:

`Bind this repo to project <slug>? Future /pinappai:* prompts will
resolve to it automatically. [Y/n]`

Default is yes — most repos are bound to one project for their lifetime.
If the user accepts, write `.pinappai/context.json` (create the
directory + file if missing) and confirm: `Bound. Future prompts in this
repo will use project "<slug>".` If they decline, continue with the
in-memory slug for this run only.

If the working tree is read-only or `.pinappai/` is gitignored, skip the
write silently — the in-memory slug still drives this run.

### Convention from here on

For the remainder of this prompt, "the project" and any subsequent
reference to `<resolved slug>` means the slug from this block. Call
subsequent tools with `project: "<that slug>"` — substitute the actual
string the resolution block returned, never the literal `<resolved
slug>` placeholder text.