feasibility

/mobile-spine:feasibility — Pre-design feasibility review

Every other spine path ends in a _tasks spec. This one stops before design is settled: it starts from a planning document alone — a prose spec, or an HTML prototype that stands in for one — and answers, before anyone builds a screen: does each platform allow what this document asks for, and what would it take in our repos? The output is one review document for planners and designers — _context/feasibility/{feature}.md.

The main session runs this command and does the extraction and the merge itself. Two kinds of judgment are delegated, in parallel:

Layer	Who	Tools	Answers
OS / store policy	docs-agent	WebFetch, WebSearch only	Does the OS allow it, from which version, under what policy — with fetched citations
Repo	android-agent / ios-agent §Feasibility check mode	their usual tools, read-only mode	Version floor, what is declared, what already exists

Neither layer sees the other's half: docs-agent cannot read the repos, and the platform agents have no WebFetch / WebSearch and do no web research in this mode. The verdict that reaches planners is the merge of the two.

User argument: $ARGUMENTS

Workspace prerequisite

Same checks as /mobile-spine:feat §Workspace prerequisite: .claude/mobile-spine.config.yaml must exist and pass the schema check (pm-agent.md Configuration → §Config schema versioning). Abort with the same messages if not, prefixed [/feasibility] instead of [/feat].

Configuration: read app from the config. In this file myapp stands for that value — ../myapp-android/ is ../{app}-android/, and so on.

Step 1 — Collect the inputs (ask only for what is missing)

Parse $ARGUMENTS first; ask only for what it does not supply, batched into one AskUserQuestion.

• Planning document — a path. Read it by type:
  • .md / .txt / .pdf → Read directly.
  • .docx → convert to text: textutil -convert txt -stdout {path} (macOS), else pandoc -t plain {path}. If neither is available, ask the user for a .pdf or .md export. Never guess at a document you could not read.
  • HTML prototype — a .html file, or a folder holding one (see §HTML prototype input below).
  • Check the text you read, whatever the format. A converter can succeed and still return nothing useful — a renamed .doc, a protected file, requirements held in text boxes or pasted as images — and a long PDF read in page ranges can stop short. If the text is empty, far shorter than the document should be, or missing sections its own table of contents lists, try the other converter (or read the remaining pages), then ask for a PDF export. For a prototype, the check is that every screen its navigation or router names was found. Treat an input that still reads this way as unreadable (§Abort conditions).
  • Must not live inside ../myapp-android/, ../myapp-ios/, or ../myapp-backend/ — ask the user to copy it into the workspace instead (platform repos are their agents' territory).
• Feature key — kebab-case, used for the output filename. Derive it from the document title when obvious and say so; ask only when it is not. For a prototype under _context/design/{feature}/, the folder name is the key (when it is kebab-case; otherwise derive one and say so).