Healthtech shares fintech's regulatory weight and adds its own: patient safety, clinical accuracy, and data sensitivity that most software never has to reason about. A workflow built around trustworthy documentation and cited root causes isn't a nice-to-have here — it's closer to table stakes for building this kind of software responsibly, AI-assisted or not.
Why "probably" is never an acceptable diagnosis here
The Investigate skill's insistence on a cited, verified root cause — not a plausible guess — matters everywhere, but it matters differently in a system where a bug could affect a clinical workflow, a dosage calculation, or a record a clinician relies on. "It's probably a rounding issue" is an unacceptable standard of diagnosis anywhere; in healthtech it's a standard of diagnosis that shouldn't exist at all. The workflow's refusal to let a fix get proposed before a cause is confirmed maps directly onto what good clinical-software practice already demands.
Full tier for anything touching patient data or clinical logic
Any change to how patient data is stored, transmitted, or calculated against — and certainly anything touching clinical decision support — belongs in full tier without much debate. The architecture doc and the EARS-format requirements aren't bureaucracy in this context; they're close to the minimum documentation a responsible healthtech engineering team would want regardless of whether an AI agent was involved in writing the code.
Product identity as a safety-adjacent document, not just a marketing one
product.md's "non-goals" section does unusually important work in healthtech: explicitly stating what a tool is not trying to do — not a diagnostic device, not a replacement for clinical judgment, not validated for a use case outside its stated scope — is a genuinely load-bearing piece of documentation here, not boilerplate. Writing it down clearly, early, and revisiting it deliberately as the product evolves is worth the dialogue-driven process product-design runs it through.
What this still doesn't replace
None of this substitutes for your actual regulatory pathway, clinical validation process, or legal and compliance review specific to your jurisdiction and product category — that guidance has to come from qualified people who know your specific situation, not from a development workflow. What SpecDevShip's discipline does is make sure the engineering process underneath all of that produces trustworthy, checkable artifacts instead of undocumented guesses, which is the least any of it should ask for.