opencode-agenthub 0.1.2 → 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/library/instructions/hr-boundaries.md

@@ -15,7 +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.
-- If the synced model catalog (`$HR_HOME/inventory/models/catalog.json` or `valid-model-ids.txt`) is empty or missing, no HR agent may propose, fill in, or confirm a concrete `provider/model` id. Use `<pending-catalog-sync>` or an explicit blocker until verified catalog data is available.
+- 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

@@ -66,10 +66,10 @@ Before leaving architecture review, you must explicitly confirm:
 
 Before staging begins, you must explicitly confirm the AI model choice for the assembled team.
 
-- if the user has no preference and the synced catalog contains verified entries, present a reasonable default recommendation from that verified catalog
-- If the synced model catalog is empty or missing, do not invent model names. State that model selection is blocked pending catalog sync or ask the user to provide an exact verified `provider/model` id.
+- 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 against the synced catalog before staging
+- validate exact `provider/model` ids by confirming availability in the user's current opencode environment before staging
 
 Do not make promote sound mandatory.
 
@@ -95,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/hr-adapter.md

@@ -50,10 +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.
-- If the synced model catalog is empty or missing, do not write any `agent.model` value. Stop and report that model assembly is blocked until catalog data is available.
+- 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

@@ -18,7 +18,7 @@ Pure-soul CTO-style reviewer for staffing architecture. You judge whether the pr
 - latest staffing plan
 - shortlisted local inventory workers and their worker cards
 - model preferences if already supplied; otherwise, note where model choice should be finalized during staging
-- synced model catalog if present at `$HR_HOME/inventory/models/catalog.json`
+- current opencode model availability (via environment probing) if needed for advisory model notes
 
 ## Output Contract
 
@@ -43,6 +43,7 @@ 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?
@@ -53,7 +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-sourcer.md

@@ -59,7 +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 explicit blocker: `Model catalog is empty — downstream model proposals are blocked until catalog data is available.`
+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

@@ -89,7 +89,7 @@ Each stage must produce its required deliverable before the gate. If the deliver
 | 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 | `team:` `overlaps:` `simplifications:` `default-opencode-agents:` `unresolved:` |
-| 5 | `STAGING & CONFIRMATION` | Staged package + final checklist | `package_id:` `contents:` `checklist:` `promote_cmd:` `default-profile:` `model-choice:` |
+| 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.
 
@@ -122,6 +122,7 @@ Use `question()` for the process confirmation. If the request relies on unsuppor
 
 5. Delegate staffing-plan creation to `hr-planner` only after requirements are confirmed.
 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
@@ -141,13 +142,12 @@ Use `question()` for the process confirmation. If the request relies on unsuppor
 
 ### Stage 5 - STAGING & CONFIRMATION
 
-20. Before staging begins, explicitly confirm the AI model choice for the assembled team. 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.
-21. If the synced catalog is empty or missing, do not suggest exact model ids from your own knowledge. Treat model choice as blocked until the catalog is synced, or ask the user to provide an exact verified `provider/model` id.
-22. Also ask whether the promoted profile should become the default personal profile for future bare `agenthub start` runs.
-23. When model choices and default-profile preference are confirmed, delegate adaptation to `hr-adapter`.
-24. Run final readiness checks through `hr-verifier`.
-25. Present the final human checklist and require explicit approval.
-26. 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
@@ -162,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/skills/hr-assembly/SKILL.md

@@ -43,8 +43,8 @@ $HR_HOME/staging/<package-id>/
 - Before final assembly, confirm whether the operator wants to keep default opencode agents such as `general`, `explore`, `plan`, and `build`. If not, the staged profile must set `"nativeAgentPolicy": "team-only"`. This suppresses host native agent merges and emits `disable: true` overrides for default opencode agents that are not supplied by the staged team itself.
 - If `nativeAgentPolicy` is `team-only` and the staged bundle set does not already provide `explore`, automatically include the built-in hidden `explore` subagent so the team retains investigation coverage without another user prompt.
 - Before final assembly, MUST verify the staged bundle set includes at least one `agent.mode: "primary"` agent that is not hidden. If all sourced candidates are subagent-style, either add/create a primary host agent or keep native agents visible. Never stage an all-subagent team as `team-only`.
-- Before final assembly, confirm whether the promoted profile should become the default personal profile for future bare `agenthub start` runs. Record that choice in `handoff.json` under `promotion_preferences.set_default_profile`.
-- If AI models are still unresolved when final assembly begins, stop and confirm the exact model choice here before writing staged agent defaults.
+- If a prior or external flow has set `promotion_preferences.set_default_profile`, preserve it in `handoff.json`. Do not proactively ask the operator about default-profile preferences during assembly.
+- If AI models are still unresolved when final assembly begins, stop and confirm the exact model choice here before writing staged agent defaults. Model confirmation must use opencode environment availability probing, not the synced inventory catalog.
 - If the operator specifies a model variant such as `xhigh`, `high`, or `thinking`, store it canonically as `agent.model: "provider/model"` plus `agent.variant: "..."`. For backward compatibility, combined strings like `"provider/model xhigh"` may still be accepted on read, but staged output should prefer the split form.
 - The package must be promotable by:
 

package/dist/skills/hr-final-check/SKILL.md

@@ -26,7 +26,7 @@ Verify that a staged package is understandable and safe before the human operato
 7. deployment role correctness
 8. unresolved risks / open decisions
 9. import-root and assemble-only validation
-10. runtime/default-profile confirmation
+10. runtime configuration confirmation
 11. protocol-compliance checkpoints
 
 ## Clarity Definitions
@@ -72,11 +72,11 @@ Keep `final-checklist.md` compact and explicit. Use this shape:
 | model preferences were confirmed before assembly | pass/fail |
 | final names were user-confirmed | pass/fail |
 | specialized work was delegated | pass/fail |
-| staged model ids validated against synced catalog | pass/fail |
+| staged model ids confirmed via opencode environment | pass/fail |
 | profile defaultAgent matches bundle agent.name | pass/fail |
 | team includes at least one primary, non-hidden agent | 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 FOR HUMAN CONFIRMATION | READY WITH CAVEATS | NOT READY
 blocker: <description or none>
@@ -90,8 +90,8 @@ The package cannot be marked ready unless the verifier confirms:
 2. the manual import fallback points to `<package-root>/agenthub-home` and is described as advanced/manual only
 3. all referenced skills either exist inside the staged `skills/` directory or are explicitly rejected as missing blockers
 4. `python3 $HR_HOME/bin/validate_staged_package.py $HR_HOME/staging/<package-id>` passes
-5. the package explicitly records whether default opencode agents are kept or hidden, and whether the promoted profile should become the default profile
-6. staged model ids either match the synced catalog exactly or are called out as blockers/caveats for human review
+5. the package explicitly records whether default opencode agents are kept or hidden, and if `promotion_preferences.set_default_profile` is present, it is consistent
+6. staged model ids are either confirmed available in the opencode environment or are called out as blockers/caveats for human review
 7. if any bundle references MCP tools, the staged package includes the referenced `mcp/*.json` files, the required `mcp-servers/` implementation files, and `mcp-servers/package.json` when runtime dependencies are needed
 8. the handoff clearly shows how to test/use the staged profile in a workspace before promote, and promote is not described as mandatory for workspace use
 9. if a profile sets `defaultAgent`, that value exactly matches one of the staged bundles' `agent.name` values (not just the bundle filename)

package/dist/skills/hr-staffing/SKILL.md

@@ -39,6 +39,7 @@ Every staffing plan must include:
 - `required_tools`
 - `draft_names` (draft agent names and draft profile name for user review)
 - `risks`
+- `team_size_advisory` (included when recommended team exceeds four agents)
 - `next_action`
 
 ## Compact Summary Shape
@@ -59,6 +60,7 @@ required_skills:
 - skill: ... | why: ...
 risks:
 - ...
+team_size_advisory: <omit if ≤4 agents; otherwise: "Recommend one to two primary agents with remaining agents as subagents.">
 next_action: ...
 ```
 
@@ -75,11 +77,12 @@ For each recommended entry, specify:
 
 - At least one staffing-plan entry must have `deployment_role: primary-capable`.
 - Prefer the smallest team that can cover planning, sourcing/exploration, implementation, audit, verification, and documentation.
+- If the recommended team has more than four agents, include a `team_size_advisory` noting that the team should be structured around one to two primary agents with the remaining agents deployed as subagents. Do not recommend more than two primary-capable agents unless the user explicitly requests it.
 - When multiple candidates can cover the same seat, prefer a pure-soul agent with attached skills over a mixed soul+skill agent. Use a mixed soul+skill agent only when the specialized workflow cannot be cleanly separated, the source is tightly fused, or the user explicitly wants that mixed form.
 - Prefer local worker cards from `$HR_HOME/inventory/workers/` with `inventory_status = available`.
 - Treat `draft` worker cards as sourcing inputs that still need review or explicit operator acceptance.
 - Exclude `retired` worker cards from recommended staffing compositions.
-- Treat user-supplied model names as advisory until checked against `$HR_HOME/inventory/models/catalog.json` or `$HR_HOME/inventory/models/valid-model-ids.txt`. If an exact catalog match is missing, mark the proposal unresolved instead of inventing a model id.
+- Treat user-supplied model names as advisory. Model confirmation happens during staging via opencode environment availability probing, not during staffing planning. If a user-supplied name looks syntactically invalid, note that, but do not attempt catalog-based validation here.
 - If multiple valid compositions exist, present them as options rather than pretending one is certain.
 - If a skill host is unresolved, say so plainly.
 - Draft names must be treated as proposals only. The parent HR agent must show them to the user and get confirmation before adaptation starts.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-agenthub",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "A control plane for organizing, composing, and activating OpenCode agents, skills, profiles, and bundles.",
   "type": "module",
   "main": "./dist/plugins/opencode-agenthub.js",