minutework 0.1.23 → 0.1.25

package/EXTERNAL_ALPHA.md

@@ -63,6 +63,10 @@ the same source so they cannot drift) plus exported `skills/` guidance so the
 local coding agent sees the combined-web, mobile standalone-client,
 snapshot-delivery, and `mw.core.site` baseline workflow. Claude Code reads
 `CLAUDE.md`; Codex and other IDE agents read `AGENTS.md`.
+The exported guidance includes a project-orientation fast path so broad
+questions like "what is this project about?", "what can we build?", and "can we
+make an existing product agentic?" route through the relevant skills in one
+pass instead of requiring the user to ask for each topic separately.
 
 The workspace MCP (read-only context tools) is wired for Cursor
 (`.cursor/mcp.json`) and Codex (`.codex/config.toml`, which Codex loads for

package/README.md

@@ -91,8 +91,12 @@ minutework session resume
   overlapping phantom sessions.
 - Generated workspaces receive a root `CLAUDE.md` and `AGENTS.md` (rendered from
   the same source so they cannot drift) plus exported `skills/` guidance tailored
-  to the combined web and published-site workflow. Claude Code reads `CLAUDE.md`;
-  Codex and other IDE agents read `AGENTS.md`.
+  to the combined web, mobile, published-site, runtime-agent, OSS-adoption, and
+  ontology workflows. Claude Code reads `CLAUDE.md`; Codex and other IDE agents
+  read `AGENTS.md`.
+- Broad project questions route through a project-orientation fast path so the
+  agent can answer "what is this project about?" or "can we make an existing
+  product agentic?" without the user naming individual skills.
 - The workspace MCP (read-only context tools) is wired for Cursor
   (`.cursor/mcp.json`) and Codex (`.codex/config.toml`, which Codex loads for
   trusted projects); `mcp/claude-desktop.sample.json` is included for Claude

package/assets/claude-local/CLAUDE.md.template

@@ -36,6 +36,18 @@ coding agent can use them as reference: browse `skills/` and read the relevant
 automatically and `/skill-name` invokes one directly; other agents (Codex,
 Cursor) can open the files directly or ask "What skills are available?".
 
+## Project Orientation Fast Path
+
+When the user asks broad context questions like "what is this project about?",
+"what can we build with MinuteWork?", "can we build our own product or make an
+existing product agentic?", "how do OSS products fit?", or "what is the
+ontology/network effect?", do not wait for them to name skills one by one. Read
+`skills/project-overview-and-strategy/SKILL.md` first, then pull the routed
+skills it lists in the same pass. Answer with the integrated product story:
+workspace purpose, app-pack model, `tenant-app`/`sidecar`/`mobile` surfaces,
+runtime-agent model, build-native vs `attached_app`, ontology/shared-URN
+mapping, shadow participation, and capability-gap boundaries.
+
 ## Shell-First UI Default
 
 - For member-facing collaboration and operator work, check shell fit first.

package/assets/claude-local/skills/README.md

@@ -28,13 +28,14 @@ receive:
 
 Generated-workspace-first guidance should live here, especially:
 
+- `project-overview-and-strategy/SKILL.md`
 - `generated-workspace-architecture/SKILL.md`
 - `vuilder-public-site-authoring/SKILL.md`
 - `workspace-guidance-refresh/SKILL.md`
 - `shell-architecture/SKILL.md`
-- `standalone-mobile-client/SKILL.md`
 - `runtime-capability-inventory/SKILL.md`
 - `layering-and-import-modes/SKILL.md`
+- `standalone-mobile-client/SKILL.md`
 - `capability-gap-reporting/SKILL.md`
 - `shadow-participation-and-guest-threads/SKILL.md`
 - `email-ingress-and-thread-routing/SKILL.md`

package/assets/claude-local/skills/project-overview-and-strategy/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: project-overview-and-strategy
+description: "Broad project questions: what this workspace is, what MinuteWork can build, agentic apps, OSS adoption, ontology, or network effects."
+---
+
+# Project Overview And Strategy
+
+Use this skill before answering broad orientation or strategy questions such as:
+
+- "What is this project about?"
+- "What can we build with MinuteWork?"
+- "Can we build our own product or make an existing product agentic?"
+- "How do OSS products fit?"
+- "What is the ontology or network effect?"
+
+Answer these in one pass. Do not wait for the user to ask for each underlying
+skill separately.
+
+## One-Pass Skill Routing
+
+For broad project questions, read or summarize these local skills together as
+needed:
+
+- `generated-workspace-architecture/SKILL.md` for the generated workspace shape,
+  trust boundary, and local authoring model.
+- `app-pack-authoring/SKILL.md` for the shipped product unit, app-pack shape,
+  compose-before-rebuild defaults, and seed-record conventions.
+- `shell-architecture/SKILL.md` for why member/operator collaboration defaults
+  to the shell instead of bespoke standalone frontends.
+- `ai-capability-defaults/SKILL.md` for the runtime-agent model and why AI
+  belongs in governed runtime capabilities instead of browser/provider calls.
+- `layering-and-import-modes/SKILL.md` for build-native vs govern-existing,
+  `attached_app`, OSS adoption, and greenfield-last decisions.
+- `sidecar-generation/SKILL.md` for bridge/integration execution, workers,
+  webhooks, schedulers, and backend compute.
+- `standalone-mobile-client/SKILL.md` for Expo/native client boundaries.
+- `ontology-mapping/SKILL.md` for shared URNs, overlays, explicit promotion,
+  and the data network-effect story.
+- `shadow-participation-and-guest-threads/SKILL.md` for guests, external
+  participants, claim/upgrade, and collaboration network effects.
+- `contract-first-public-intake/SKILL.md` and
+  `email-ingress-and-thread-routing/SKILL.md` for external/anonymous intake,
+  handoff continuity, and communication surfaces.
+- `runtime-capability-inventory/SKILL.md` when the answer depends on what the
+  current workspace or linked runtime already exposes.
+- `capability-gap-reporting/SKILL.md` when a strategic answer reaches a missing
+  substrate or unshipped capability.
+
+## Compact Project Answer
+
+MinuteWork Builder is a governed local authoring workspace for building or
+extending MinuteWork app packs. An app pack is the product unit. The workspace
+usually composes schemas, manifests, `mw.core.site`, runtime capabilities,
+agents, overlays, and published-web flows before writing bespoke code.
+
+MinuteWork supports two legitimate paths: build a native MinuteWork product
+from scratch, or wrap an existing product/OSS system with a governed, agentic
+control surface.
+
+Implementation surfaces are:
+
+- `tenant-app`: Next.js web surface for public routes and private `/app`
+  standalone exceptions.
+- `sidecar`: internal backend bridge for webhooks, workers, schedulers,
+  integration APIs, long-running compute, and foreign-system adapters.
+- `mobile`: standalone Expo/React Native client that talks directly to platform
+  native session endpoints with device-flow bearer auth.
+
+For member/operator collaboration, check shell fit first. The default product
+experience is the gateway shell and thread/card/right-rail substrate. Standalone
+web or native surfaces are exceptions for public, embeddable, or explicitly
+separate client experiences.
+
+## Strategic Positioning
+
+MinuteWork is most differentiated when identity, shared meaning, external
+collaboration, AI agents, and foreign systems participate in the same governed
+substrate:
+
+- Shadow identity and guest/shared threads let people collaborate before they
+  have an account or runtime, then claim or upgrade explicitly without losing
+  continuity.
+- Ontology mappings connect local records to stable shared URNs while keeping
+  high-variance tenant data runtime-local until an explicit promotion workflow.
+- Runtime agents use `mw.runtime.agent` seed records and namespaced runtime-kind
+  tool packs. UI surfaces collect inputs and render governed outputs; they do
+  not run model/provider logic directly.
+- OSS and mature external products are adopted before rebuilding when they fit.
+  Use `attached_app` when the foreign system should remain independently
+  deployed, and use sidecar bridge code plus runtime agents/tool packs to make
+  it governed and agentic.
+- Build-native is appropriate when the capability is central, reusable, and
+  should become MinuteWork substrate. Greenfield is last after existing
+  substrate, reviewed skills, app-pack extension, OSS adoption, and
+  `attached_app` have been considered.
+
+## Answer Shape
+
+For broad user questions, lead with the product-level answer, then map to the
+concrete workspace surfaces. A good answer should usually cover:
+
+- what the workspace is;
+- what each surface is for;
+- how agentic behavior works;
+- when to build native vs govern an existing product;
+- how ontology and shadow participation create network effects;
+- which skill or workspace MCP tool to inspect next if the user asks for an
+  implementation plan.
+
+Do not end broad strategy answers by asking the user to name a skill. Choose
+the relevant skills yourself and give the integrated answer.
+
+If the user has not named a product or workflow yet, close by asking for that
+concrete target and say you will map it to shell vs `tenant-app` vs `sidecar` vs
+`mobile`, decide build-native vs `attached_app`, and identify the first
+schemas, agents, and bridges to author.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "minutework",
-  "version": "0.1.23",
+  "version": "0.1.25",
   "description": "MinuteWork CLI for workspace scaffolding, local preview workflows, and hosted preview deploys.",
   "type": "module",
   "bin": {