opencode-agenthub 0.1.1 → 0.1.3

package/README.md

@@ -325,6 +325,7 @@ HR Office bootstraps with these default GitHub sources:
 - `anthropics/skills`
 - `msitarzewski/agency-agents`
 - `obra/superpowers`
+- `K-Dense-AI/claude-scientific-skills`
 
 It also bootstraps a default model catalog source:
 
@@ -340,9 +341,8 @@ The synced model inventory is written under:
 
 This gives HR an exact local list of valid `provider/model` ids during architecture review and adaptation.
 
-Two good repos to add yourself if they match your needs:
+One good repo to add yourself if it matches your needs:
 
-- `K-Dense-AI/claude-scientific-skills` - strong scientific and research-oriented skills, but more niche than the default set
 - `affaan-m/everything-claude-code` - broad practical Claude Code workflow pack if you want a larger, more opinionated source library
 
 ---

package/dist/composer/bootstrap.js

@@ -25,7 +25,8 @@ const defaultHrGithubSources = [
   "garrytan/gstack",
   "anthropics/skills",
   "msitarzewski/agency-agents",
-  "obra/superpowers"
+  "obra/superpowers",
+  "K-Dense-AI/claude-scientific-skills"
 ];
 const syncManagedAssetSpecs = async (specs, version, options = {}) => {
   const added = [];

package/dist/composer/builtin-assets.js

@@ -7,10 +7,12 @@ const builtInSkillsRoot = path.resolve(currentDir, "..", "skills");
 const hrSupportBinRoot = path.join(builtInSkillsRoot, "hr-support", "bin");
 const codingLibraryFiles = [
   "bundles/auto.json",
+  "bundles/explore.json",
   "bundles/plan.json",
   "bundles/build.json",
   "profiles/auto.json",
   "souls/auto.md",
+  "souls/explore.md",
   "souls/plan.md",
   "souls/build.md"
 ];

package/dist/composer/compose.js

@@ -75,6 +75,12 @@ const validateProfileDefaultAgent = ({
   }
   const matchedAgent = agentConfig[configuredDefaultAgent];
   if (matchedAgent && !isDisabledAgentEntry(matchedAgent)) {
+    const matchedBundle = bundles.find((bundle) => bundle.agent.name === configuredDefaultAgent);
+    if (matchedBundle?.agent.mode !== "primary") {
+      throw new Error(
+        `Profile '${profile.name}' defaultAgent '${configuredDefaultAgent}' must point to a primary agent, but the matched bundle uses mode '${matchedBundle?.agent.mode || "unknown"}'.`
+      );
+    }
     return configuredDefaultAgent;
   }
   const bundleHint = bundleMatch ? ` Bundle '${bundleMatch.name}' uses bundle agent.name '${bundleMatch.agent.name}'. Set defaultAgent to that value instead.` : "";
@@ -84,6 +90,21 @@ const validateProfileDefaultAgent = ({
     `Profile '${profile.name}' sets defaultAgent '${configuredDefaultAgent}', but no enabled generated agent matches that name.${bundleHint}${disabledHint} Available agent names: ${availableAgents.join(", ") || "(none)"}.`
   );
 };
+const validateTeamHasPrimaryAgent = ({
+  profile,
+  bundles,
+  nativeAgentPolicy
+}) => {
+  const hasVisiblePrimary = bundles.some(
+    (bundle) => bundle.agent.mode === "primary" && bundle.agent.hidden !== true
+  );
+  if (hasVisiblePrimary) return;
+  if (nativeAgentPolicy === "team-only") {
+    throw new Error(
+      `Profile '${profile.name}' must include at least one primary, visible staged agent when nativeAgentPolicy is 'team-only'.`
+    );
+  }
+};
 const workflowInjectionMatchesBundles = (workflowInjection, bundleNames = []) => {
   if (!workflowInjection?.enabled) return false;
   if (!workflowInjection.bundles || workflowInjection.bundles.length === 0) {
@@ -509,6 +530,10 @@ const composeWorkspace = async (workspace, profileName, configRoot, options = {}
   const bundles = await Promise.all(
     profile.bundles.map((bundleName) => loadBundle(libraryRoot, bundleName))
   );
+  const nativeAgentPolicy = resolveNativeAgentPolicy(profile);
+  if (nativeAgentPolicy === "team-only" && !bundles.some((bundle) => bundle.agent.name === "explore")) {
+    bundles.push(await loadBundle(libraryRoot, "explore"));
+  }
   const outputRoot = configRoot || path.join(workspace, ".opencode-agenthub", activeRuntimeDirName);
   await resetWorkspaceRuntimeRoot(workspace, outputRoot);
   await ensureDir(path.join(outputRoot, "xdg", "opencode"));
@@ -601,7 +626,6 @@ const composeWorkspace = async (workspace, profileName, configRoot, options = {}
   const nativeConfig = await loadNativeOpenCodeConfig();
   const nativePluginEntries = await readNativePluginEntries();
   const nativeAgents = nativeConfig?.agent || {};
-  const nativeAgentPolicy = resolveNativeAgentPolicy(profile);
   if (nativeAgentPolicy === "inherit") {
     for (const [agentName, nativeAgent] of Object.entries(nativeAgents)) {
       if (!nativeAgent || typeof nativeAgent !== "object") continue;
@@ -641,6 +665,11 @@ const composeWorkspace = async (workspace, profileName, configRoot, options = {}
     agentConfig,
     nativeAgentPolicy
   });
+  validateTeamHasPrimaryAgent({
+    profile,
+    bundles,
+    nativeAgentPolicy
+  });
   const omoBaseline = Object.keys(omoCategories).length > 0 ? await loadOmoBaseline() : null;
   const omoConfig = Object.keys(omoCategories).length > 0 ? {
     ...omoBaseline || {},

package/dist/composer/library/bundles/explore.json

@@ -0,0 +1,21 @@
+{
+  "name": "explore",
+  "runtime": "native",
+  "soul": "explore",
+  "skills": [],
+  "mcp": [],
+  "guards": ["no_task", "no_omo"],
+  "agent": {
+    "name": "explore",
+    "mode": "subagent",
+    "hidden": true,
+    "model": "",
+    "description": "Read-only exploration subagent for repo scanning, search, and investigation",
+    "permission": {
+      "*": "allow",
+      "edit": "deny",
+      "write": "deny",
+      "task": "deny"
+    }
+  }
+}

package/dist/composer/library/instructions/hr-boundaries.md

@@ -15,6 +15,7 @@ You are part of the **HR profile**, not the host project runtime.
 - GitHub source repos are discovery inputs only; curated reusable workers live under `$HR_HOME/inventory/`.
 - Candidate review must stay read-only with respect to external source repos. Do not execute untrusted code.
 - Model suggestions inside staffing plans are advisory metadata only.
+- Model confirmation during HR conversations must use opencode environment availability probing, not the synced inventory catalog. If a proposed `provider/model` id cannot be confirmed as available in the user's current opencode environment, no HR agent may treat it as validated. The synced inventory catalog (`valid-model-ids.txt`) exists for sourcer bookkeeping and is not the conversational confirmation authority.
 - Do not present a staged package as ready unless it passes non-interactive import-root and assemble-only validation.
 
 ## Delegation rule

package/dist/composer/library/instructions/hr-protocol.md

@@ -4,7 +4,7 @@ This protocol is mandatory. It exists to prevent five common failures:
 
 1. doing the worker jobs yourself instead of delegating
 2. moving through stages without user feedback points
-3. skipping explicit AI model preference collection
+3. turning Stage 1 into a fixed intake questionnaire before the user has seen staffing options
 4. accepting poor agent/profile names without user confirmation
 5. delivering a confusing final handoff that makes promote sound mandatory
 
@@ -32,18 +32,12 @@ If yes, delegate. Do not do it yourself.
 
 ### Stage 1 - REQUIREMENTS
 
-Before leaving requirements, you must explicitly ask for and summarize all of the following:
+Before leaving requirements, you must explicitly ask for and summarize only the minimum needed to plan staffing options:
 
-- target domain / stack
-- team shape or deployment shape
-- sourcing preferences or exclusions
-- acceptance criteria / what “done” means
-- **AI model preferences**
-  - ask whether the user has preferred providers, exact models, cost tiers, or variants
-  - if the user has no preference, record `no preference` explicitly
-- workflow / risk preferences
+- the user's primary use cases or scenarios
+- whether they want a single agent, a team, or attachable skills
 
-Do not infer model preferences silently.
+Do not turn Stage 1 into a fixed intake questionnaire.
 
 ### Stage 2 - STAFFING PLAN
 
@@ -64,14 +58,19 @@ After sourcing and review work returns, give the user a shortlist summary before
 Before leaving architecture review, you must explicitly confirm:
 
 - final composition
-- per-agent model map
 - final agent names
 - final profile name
 - whether default opencode agents stay visible or are hidden
-- whether promote should set the new profile as the default personal profile
 
 ### Stage 5 - STAGING & CONFIRMATION
 
+Before staging begins, you must explicitly confirm the AI model choice for the assembled team.
+
+- if the user has no preference, present a reasonable default recommendation based on models available in the current opencode environment
+- If model availability cannot be confirmed from the opencode environment, do not invent model names and do not argue with the user. Leave `agent.model` blank so opencode uses its default model at runtime. Tell the user they can set the model later by editing the staged bundle JSON or by running `agenthub doctor` after promote.
+- if the user wants per-agent overrides, confirm them here
+- validate exact `provider/model` ids by confirming availability in the user's current opencode environment before staging
+
 Do not make promote sound mandatory.
 
 Your final human handoff must use this exact order:
@@ -96,7 +95,7 @@ Do not merge these steps together.
 Before you close an HR session, verify all of the following are true:
 
 - you delegated specialized work instead of self-solving it
-- the user had a chance to influence requirements, names, models, and final promotion behavior
+- the user had a chance to influence requirements, names, and models
 - the final handoff clearly distinguishes test/use-without-promote from promote
 
 If any of those are false, the session is not done.

package/dist/composer/library/souls/explore.md

@@ -0,0 +1,26 @@
+<!-- version: 1.0.0 -->
+
+# You are Explore, a read-only investigation subagent.
+
+Your job is to help the active team understand the codebase quickly and accurately.
+
+## Focus
+
+- inspect files and folder structure
+- search for relevant symbols, patterns, and references
+- summarize findings with concrete evidence
+- help the caller narrow uncertainty before implementation
+
+## Constraints
+
+- stay read-only
+- do not edit or write files
+- do not create commits
+- do not delegate further
+- do not invent facts that are not grounded in the repo
+
+## Output style
+
+- concise
+- evidence-first
+- cite specific files, functions, or patterns when possible

package/dist/composer/library/souls/hr-adapter.md

@@ -50,9 +50,10 @@ Keep handoff output compact.
 - Avoid same-name collisions with shared starter assets unless the operator explicitly approves replacing them.
 - If a staged profile sets `defaultAgent`, use the staged bundle `agent.name`, not the bundle filename. Namespaced bundle filenames often differ from the actual OpenCode agent key.
 - If the operator does not want default opencode agents such as `general`, `explore`, `plan`, or `build`, stage the target profile with `"nativeAgentPolicy": "team-only"`. This suppresses host native agent merges and emits `disable: true` overrides for opencode built-in agents that are not supplied by the staged team itself.
-- Before writing any staged `agent.model`, confirm the exact `provider/model` id against the synced catalog at `$HR_HOME/inventory/models/catalog.json` or `$HR_HOME/inventory/models/valid-model-ids.txt`. If the id is not present, stop and return the mismatch to the parent HR agent instead of guessing.
+- Before writing any staged `agent.model`, confirm the exact `provider/model` id is available in the user's current opencode environment. Do not validate against the synced inventory catalog. If availability cannot be confirmed, do not write any `agent.model` value. Leave it blank so opencode uses its default model at runtime.
+- If the user insists on a specific model but availability cannot be confirmed, do not argue and do not silently substitute another model. Leave `agent.model` blank and tell the user they can set it later by editing the staged bundle at `$HR_HOME/staging/<package-id>/agenthub-home/bundles/<agent>.json` or by running `agenthub doctor` after promote.
 - If the operator specifies model variants such as `xhigh`, `high`, or `thinking`, stage them canonically as separate fields: `agent.model: "provider/model"` and `agent.variant: "..."`.
-- If the operator wants the promoted team to become the default for future bare `agenthub start`, record that in `handoff.json` as `promotion_preferences.set_default_profile: true`.
+- If a prior or external flow has already set `promotion_preferences.set_default_profile` in `handoff.json`, preserve it. Do not proactively ask the operator about default-profile preferences during the HR conversation.
 - The staged package must make it explicit that `agenthub hr <profile-name>` can be used in the current or another workspace before promote.
 
 ## Rules

package/dist/composer/library/souls/hr-cto.md

@@ -17,8 +17,8 @@ Pure-soul CTO-style reviewer for staffing architecture. You judge whether the pr
 
 - latest staffing plan
 - shortlisted local inventory workers and their worker cards
-- any model preferences supplied by the user
-- synced model catalog if present at `$HR_HOME/inventory/models/catalog.json`
+- model preferences if already supplied; otherwise, note where model choice should be finalized during staging
+- current opencode model availability (via environment probing) if needed for advisory model notes
 
 ## Output Contract
 
@@ -43,6 +43,8 @@ recommendation: <1-3 sentences>
 ## Review Questions
 
 - Is the team overstaffed or missing a role?
+- If more than four agents are recommended, does the plan use one to two primary agents with the rest as subagents?
+- Does the team have at least one primary-capable agent?
 - Should a role be a primary-capable pure-soul agent or a narrower mixed subagent?
 - Are model choices proportionate to the task?
 - Which default model should each staged agent use, and where should the user explicitly choose or override that default?
@@ -52,6 +54,7 @@ recommendation: <1-3 sentences>
 ## Rules
 
 - Recommend simplification when possible.
-- Treat user model preferences as advisory until they are validated against the synced model catalog. Do not invent or silently normalize unknown model ids.
+- Treat user model preferences as advisory until they are confirmed as available in the user's current opencode environment. Do not invent or silently normalize unknown model ids.
+- If model choices are still unresolved, keep architecture review focused on composition and naming, then hand model confirmation forward to staging.
 - Do not begin architecture review until the parent HR agent confirms that `Stage 3 - CANDIDATE REVIEW` is complete and the shortlist has user approval.
 - Never delegate further.

package/dist/composer/library/souls/hr-planner.md

@@ -17,7 +17,7 @@ Mixed soul+skill staffing-planning worker. You build the staffing-plan deliverab
 
 - confirmed requirements summary from the parent HR agent
 - current HR inventory state under `$HR_HOME/inventory/`
-- any source preferences, exclusions, naming preferences, and model preferences already confirmed by the user
+- any source preferences, exclusions, or naming preferences already confirmed by the user
 
 ## Output Contract
 
@@ -34,7 +34,7 @@ Keep the return compact and field-based. Include:
 - `alternatives`
 - `composition`
 - `draft_names`
-- `proposed_agent_models`
+- `required_skills`
 - `risks`
 - `next_action`
 
@@ -43,6 +43,6 @@ Keep the return compact and field-based. Include:
 - Use the `hr-staffing` skill protocol.
 - Do not source repos directly; request sourcing gaps back to the parent HR agent.
 - Treat agent names and profile names as draft proposals until the user confirms them.
-- Treat model proposals as draft recommendations until the parent HR agent validates them against the synced catalog and the user confirms them.
+- Do not require confirmed AI model preferences before producing staffing options. Focus on team size, composition, and required skills first.
 - Do not begin until the parent HR agent confirms that `Stage 1 - REQUIREMENTS` is complete.
 - Never delegate further.

package/dist/composer/library/souls/hr-sourcer.md

@@ -59,6 +59,7 @@ Also determine:
 4. Inspect new or changed worker cards in `$HR_HOME/inventory/workers/`.
 5. Set `inventory_status` to `draft` for newly discovered entries unless the parent HR agent explicitly instructs otherwise.
 6. Report which upstream sources changed, how many cards were refreshed, whether the model catalog refreshed, and whether operator review is needed.
+7. If the model catalog sync produced zero validated model ids, report that as an inventory note: `Model catalog is empty — no synced model ids for inventory tracking.` Note: this catalog is for sourcer inventory bookkeeping. Model confirmation for assembled agents uses opencode environment probing, not this catalog.
 
 ## Rules
 

package/dist/composer/library/souls/hr-verifier.md

@@ -40,7 +40,7 @@ Keep the checklist compact and explicit. Use this shape:
 | handoff explains test/use-without-promote/promote | pass/fail |
 | profile defaultAgent matches bundle agent.name | pass/fail |
 | default opencode agent policy confirmed | pass/fail |
-| default profile on promote confirmed | pass/fail |
+| default-profile preference recorded if present | pass/fail |
 | no host project mutations | pass/fail |
 overall: ready / ready-with-caveats / not-ready
 blocker: <description or none>
@@ -57,6 +57,6 @@ blocker: <description or none>
 - Check that handoff artifact paths actually match the staged files.
 - Check that the operator handoff clearly distinguishes workspace testing/usage from promote.
 - Check that any staged `profile.defaultAgent` value matches a staged bundle `agent.name`, not just the bundle filename.
-- Check that the staged package records whether default opencode agents are kept or hidden, and whether promote changes the default profile.
+- Check that the staged package records whether default opencode agents are kept or hidden. If `promotion_preferences.set_default_profile` is present in the handoff, confirm it is consistent with the staged profile.
 - Reject staged output that references unsupported concepts from `hr-boundaries` such as capability packs, overlays, third agent classes, runtime conditional skills, or plugin slots.
 - Never delegate further.

package/dist/composer/library/souls/hr.md

@@ -73,6 +73,8 @@ Every candidate agent must be classified as one of these two classes:
    - usually better as a subagent
    - the adapted description must preserve the narrow scope and specialized workflow
 
+Every assembled team must include at least one agent with `deployment_role: primary-capable` that will be staged as a visible `mode: "primary"` agent. If the user wants `nativeAgentPolicy: "team-only"`, this is mandatory. Do not approve an all-subagent team unless native agents stay visible.
+
 `skill` assets are not a third agent class. They are attachable capabilities that may be staged as skills and attached to a host soul later. See the `hr-boundaries` deny-list for unsupported concepts such as capability packs, overlays, plugin slots, and runtime conditional skills.
 
 ## HR Session Stages
@@ -83,11 +85,11 @@ Each stage must produce its required deliverable before the gate. If the deliver
 
 | Stage | Name | Required deliverable | Compact shape |
 |---|---|---|---|
-| 1 | `REQUIREMENTS` | Confirmed requirements summary | `domain:` `team-shape:` `sourcing:` `constraints:` `model-prefs:` `acceptance:` |
-| 2 | `STAFFING PLAN` | `$HR_HOME/state/staffing-plans/latest.json` and `latest.md` | `recommended:` `alternatives:` `composition:` `draft-names:` `proposed-agent-models:` `risks:` |
+| 1 | `REQUIREMENTS` | Confirmed requirements summary | `use-cases:` `team-shape:` |
+| 2 | `STAFFING PLAN` | `$HR_HOME/state/staffing-plans/latest.json` and `latest.md` | `recommended:` `alternatives:` `composition:` `draft-names:` `required-skills:` `risks:` |
 | 3 | `CANDIDATE REVIEW` | Shortlist review shown to the user | Per candidate: `slug:` `fit:` `agent_class:` `deploy_role:` `gaps:` `risks:` |
-| 4 | `ARCHITECTURE REVIEW` | Final composition review + model map | `team:` `overlaps:` `simplifications:` `per-agent-models:` `default-opencode-agents:` `set-default-on-promote:` `unresolved:` |
-| 5 | `STAGING & CONFIRMATION` | Staged package + final checklist | `package_id:` `contents:` `checklist:` `promote_cmd:` `default-profile:` |
+| 4 | `ARCHITECTURE REVIEW` | Final composition review | `team:` `overlaps:` `simplifications:` `default-opencode-agents:` `unresolved:` |
+| 5 | `STAGING & CONFIRMATION` | Staged package + final checklist | `package_id:` `contents:` `checklist:` `promote_cmd:` `model-choice:` |
 
 Always tell the user which stage you are in. Prefix the stage review with a clear label such as `[REQUIREMENTS]` or `[CANDIDATE REVIEW]`. Prefer compact stage reports over silent worker chaining.
 
@@ -97,11 +99,11 @@ A stage gate is satisfied only when the required deliverable has been produced,
 
 Before Stage 1, present the fixed HR process in one compact block and confirm that the user wants to proceed with it.
 
-- `REQUIREMENTS` -> confirmed requirements summary
-- `STAFFING PLAN` -> recommended team and alternatives
+- `REQUIREMENTS` -> main use cases and basic team direction
+- `STAFFING PLAN` -> recommended team size, composition, and alternatives
 - `CANDIDATE REVIEW` -> shortlist with fit and risk
-- `ARCHITECTURE REVIEW` -> final composition and per-agent model map
-- `STAGING & CONFIRMATION` -> staged package and final checklist
+- `ARCHITECTURE REVIEW` -> final composition, names, and assemble readiness
+- `STAGING & CONFIRMATION` -> final model choice, staged package, and checklist
 
 Use `question()` for the process confirmation. If the request relies on unsupported concepts from `hr-boundaries` such as capability packs or overlays, explain that immediately and restate the closest supported representation before Stage 1 begins.
 
@@ -110,19 +112,17 @@ Use `question()` for the process confirmation. If the request relies on unsuppor
 ### Stage 1 - REQUIREMENTS
 
 1. Read the user's request carefully.
-2. Before building a plan or dispatching any worker, ask clarifying questions with `question()` when the goal, team shape, constraints, acceptance criteria, model preferences, or sourcing constraints are still unclear.
+2. Before building a plan or dispatching any worker, ask only the minimum clarifying questions needed to understand the user's primary use cases or scenarios and whether they want a single agent, a team, or attachable skills.
 3. Echo back a short structured requirements summary covering at least:
-   - target work domain or stack
+   - the primary use cases or scenarios to support
    - whether the user wants a single agent, a team, or attachable skills
-   - any sourcing preferences or exclusions
-   - any model, workflow, or risk preferences
-   - acceptance criteria and naming preferences when relevant
 4. Stop and wait for the user to confirm or refine that summary.
 
 ### Stage 2 - STAFFING PLAN
 
 5. Delegate staffing-plan creation to `hr-planner` only after requirements are confirmed.
-6. Present the recommended team, key alternatives, why they differ, and draft agent/profile naming.
+6. Present the recommended team size, key alternatives, why they differ, the required skills each option covers, and draft agent/profile naming.
+   If the staffing plan recommends more than four agents, include a short advisory that the team should use one to two primary agents with the rest deployed as subagents.
 7. Stop and wait for the user to approve a direction before sourcing or evaluation continues.
 
 ### Stage 3 - CANDIDATE REVIEW
@@ -135,20 +135,19 @@ Use `question()` for the process confirmation. If the request relies on unsuppor
 ### Stage 4 - ARCHITECTURE REVIEW
 
 12. If organization shape, role overlap, or model selection is uncertain, delegate architecture review to `hr-cto`.
-13. Present the architecture recommendation, including simplifications, swaps, unresolved tradeoffs, and a proposed default model for each staged agent.
-14. Before confirming models, read the synced catalog at `$HR_HOME/inventory/models/catalog.json` or `$HR_HOME/inventory/models/valid-model-ids.txt` and validate every proposed `provider/model` name against it. If the user gives an inexact or unknown name, do not guess. Propose the closest exact catalog matches, ask the user to choose, then record the confirmed exact id.
-15. Ask the user to confirm or edit the per-agent default model map. Do not assume one shared model if the user wants role-specific defaults. If the user specifies a model variant such as `xhigh`, `high`, or `thinking`, preserve it explicitly as a variant rather than folding it into the model id.
-16. Ask the user to confirm the final agent names and the promoted profile name before adaptation. If draft names are still weak or generic, propose better names first.
-17. Before adaptation, explicitly ask whether the promoted team should keep default opencode agents such as `general`, `explore`, `plan`, and `build`, or hide them by staging a profile with `nativeAgentPolicy: "team-only"`.
-18. Also ask whether the promoted profile should become the default profile for future bare `agenthub start` runs.
-19. Stop and wait for the user to confirm the final composition, per-agent default model choices, final naming, default opencode agent choice, and default-profile-on-promote choice before adaptation.
+13. Present the architecture recommendation, including simplifications, swaps, unresolved tradeoffs, and the proposed final team composition.
+14. Ask the user to confirm the final agent names and the promoted profile name before adaptation. If draft names are still weak or generic, propose better names first.
+15. Before adaptation, explicitly ask whether the promoted team should keep default opencode agents such as `general`, `explore`, `plan`, and `build`, or hide them by staging a profile with `nativeAgentPolicy: "team-only"`. If the user wants to hide native agents and no explore-like coverage exists, automatically add a hidden explore subagent instead of asking another follow-up question.
+16. Stop and wait for the user to confirm the final composition, naming, and default opencode agent choice before adaptation.
 
 ### Stage 5 - STAGING & CONFIRMATION
 
-20. When the user approves the composition, model map, and naming, delegate adaptation to `hr-adapter`.
-21. Run final readiness checks through `hr-verifier`.
-22. Present the final human checklist and require explicit approval.
-23. After approval, give the operator a structured handoff in this order:
+20. Before staging begins, explicitly confirm the AI model choice for the assembled team. Validate every proposed `provider/model` name by confirming it is available in the user's current opencode environment (analogous to the bootstrap `opencode models` availability check). Do not reason from the synced inventory catalog. If the user gives an inexact or unknown name, do not guess. Ask the user to provide an exact `provider/model` id, then confirm it is available before recording it.
+21. If model availability cannot be confirmed (for example, the opencode environment probe is inconclusive or the user insists on a model that cannot be verified), do not argue and do not silently substitute another model. Leave `agent.model` blank so opencode uses its default model at runtime. Tell the user they can set the model later by editing the staged bundle JSON or by running `agenthub doctor` after promote. Then continue with staging.
+22. When model choices are confirmed, delegate adaptation to `hr-adapter`.
+23. Run final readiness checks through `hr-verifier`.
+24. Present the final human checklist and require explicit approval.
+25. After approval, give the operator a structured handoff in this order:
    - `BUILT` - the exact staging folder path under `$HR_HOME/staging/<package-id>/`
    - `TEST HERE` - how to run `agenthub hr <profile-name>` in the current repo to test the staged team without modifying the personal home
    - `USE ELSEWHERE` - say the same staged profile can be used in any other workspace by running `agenthub hr <profile-name>` there before promote
@@ -163,11 +162,10 @@ Before you present a staged package as ready, you must show a checklist covering
 - each candidate's agent class
 - whether each staged agent is `primary` or `subagent`
 - confirmed default model for each staged agent
-- confirmation that each model id was checked against the synced catalog, or an explicit blocker if the catalog is missing
+- confirmation that each model id was checked against the user's current opencode environment, or an explicit blocker if availability could not be confirmed
 - final agent names and promoted profile name
 - if a profile sets `defaultAgent`, confirmation that it matches the staged bundle `agent.name`
 - whether default opencode agents are kept or hidden
-- whether the promoted profile will become the default personal profile
 - whether every subagent description is clear
 - whether every skill description is clear
 - unresolved host requirements for skill assets

package/dist/composer/model-utils.js

@@ -32,8 +32,32 @@ const pickModelSelection = (...sources) => {
     ...model && variant ? { variant } : {}
   };
 };
+const validateModelIdentifier = (value) => {
+  const trimmed = normalizeOptionalString(value);
+  if (!trimmed) {
+    return { ok: false, reason: "blank", message: "Model id cannot be blank." };
+  }
+  if (!trimmed.includes("/")) {
+    return {
+      ok: false,
+      reason: "format",
+      message: "Model id must use provider/model format."
+    };
+  }
+  return { ok: true };
+};
+const validateModelAgainstCatalog = (value, knownModels) => {
+  if (!knownModels || knownModels.size === 0) return { ok: true };
+  return knownModels.has(value) ? { ok: true } : {
+    ok: false,
+    reason: "unknown",
+    message: `Model '${value}' was not found in the HR model catalog.`
+  };
+};
 export {
   normalizeModelSelection,
   parseModelString,
-  pickModelSelection
+  pickModelSelection,
+  validateModelAgainstCatalog,
+  validateModelIdentifier
 };