Shared package candidates

Separate established packages from patterns that still need evidence.

Established packages

These should be treated as canonical shared packages now:

• @howells/lint
  • pinned Oxlint/Oxfmt, Ultracite, and React Doctor presets
• @howells/typescript-config
  • explicit thin tsconfig presets
• @howells/motion
  • shared durations, easings, springs and presets
• @patternmode/stacksheet
  • the preferred abstraction for stacked sheet flows
• @howells/envelope
  • strict structured IO wrapper for CLI-model workflows
• @howells/ai
  • the model for each job, read by AI-capable apps and agent packages
• @howells/motif-sdk
  • shared fal.ai image-generation, editing, utility media, model registry, and cost-estimation surface
• @howells/motif-cli
  • agent-friendly image-generation CLI with dry runs, structured output, local history, and series workflows
• @howells/envy
  • typed env parsing, lint helpers, and deployment env preflight checks
• @howells/stow-server
  • the reusable server integration surface when a repo needs to talk to the house media storage platform directly
• @howells/stow-next
  • the reusable Next.js-facing media storage integration
• @howells/srcfull
  • shared source-fetching layer for browser/page-source ingestion workflows

Continue standardising: model choice

@howells/ai is the model lookup every AI-capable repo reads from.

Recommendation:

• keep the pick for each job and its measured settings in @howells/ai, and nothing else; provider wiring stays with Mastra's model router or the OpenRouter AI SDK provider
• keep product-specific prompts, tools, and workflows in repo-local packages/mastra
• do not publish repo-specific agent packages just because several repos use Mastra

Mastra and MCP should standardize as architecture choices before becoming more shared package surface.

Continue standardising: image generation

Motif should be the default surface for fal.ai image generation, image editing, upscaling, background removal, image-to-video, model metadata, dry runs, cost estimates, and structured agent-facing command-line work.

Recommendation:

• use @howells/motif-sdk for product or package code
• use @howells/motif-cli for scriptable local and agent workflows
• use the CLI's JSON/NDJSON output, semantic exit codes, and live --describe schema when an agent needs the tool surface
• keep durable media storage separate through the house media storage platform
• do not write raw fal.ai clients in app routes unless Motif cannot cover the endpoint yet

Medium candidate: drawer and side-panel layer

You have repeated vaul wrappers across several active UI repos.

That is a signal.

Recommendation:

• do not publish a generic drawer package yet
• first collapse the repeated wrappers into the scaffold UI baseline or a repo-local shared UI package
• publish only if that API becomes stable and broadly useful outside your repos

For now:

• keep simple drawers in shared UI packages
• use @patternmode/stacksheet when the flow becomes stack-oriented

Keep local for now

These are useful patterns, but they should stay repo-local for now:

• repo-local env packages
• project-local domain packages
• repo-specific auth wrappers
• repo-specific TRPC wrappers

They encode app boundaries, not cross-project standards.

The env exception is implementation, not ownership: keep a repo-local packages/env boundary, but build it on @howells/envy instead of publishing another env package per app.

Product and package choices

Keep these choices separate:

• the house media storage platform is the product recommendation
• @howells/stow-server is the package recommendation

For new projects, the default decision should be:

• if the repo needs image, vector, or media storage, start by asking whether it should use the house media storage platform
• if the repo needs typed server-side integration, reach for @howells/stow-server
• keep provider clients inside the storage/upload package rather than calling them from apps

Standardisation order

Reduce duplicated package work in this order:

1. prefer @howells/lint and @howells/typescript-config everywhere
2. use @howells/envy for repo-local env boundaries instead of creating more package-specific env tooling
3. read model IDs from @howells/ai instead of scattering model strings
4. use howells/motif for image generation and media utility workflows instead of scattering raw fal.ai clients
5. standardize @patternmode/stacksheet as the default stacked-panel abstraction
6. use @howells/motion for motion tokens
7. add recurring UI patterns to Patternmode rather than copying them between repos