Add a "generic agent" target architecture (no knowledge of specific internal tools)

[adilei]

Summary

Add a new "generic agent" target architecture to the Skill Builder (and ideally the Automation Builder) that has no knowledge of any specific internal tools. Selecting it should produce a portable, tool-agnostic SKILL.md that doesn't assume any single agent's native toolset.

Motivation

Today every target architecture is backed by a static capability catalogue of that agent's native/internal tools, and the builder deliberately generates a "native-tool-first" skill that prefers those tools:

• scout → workiq_*, browser, files, built-in skills (electron/skillbuilder/scout-catalog.ts)
• cowork → Teams/Outlook/Calendar/SharePoint, etc. (electron/skillbuilder/cowork-catalog.ts)

That's ideal when the destination agent is known, but it makes the output non-portable: a Scout- or Cowork-targeted skill references tools an arbitrary agent doesn't have. There's currently no way to record a task once and get a neutral skill you can hand to an unknown/third-party agent.

Proposed behavior

• New SkillArchitecture value, e.g. "generic", added to the enum and to ARCHITECTURES in common/skill.ts (enabled, with an explanatory note).
• Instead of an internal-tool catalogue, the generic target uses an empty/neutral capability catalogue: no workiq_*, no Scout/Cowork built-ins, no product-specific tool names.
• The builder generalizes steps in portable terms only — plain natural-language actions and, at most, universally-available primitives (shell, filesystem, HTTP/REST, a generic browser) — so any agent can execute it.
• catalogueFor("generic") must return a (neutral) catalogue so the builder gate in electron/skillbuilder/builder.ts ("That target architecture isn't available yet…") passes.

Scope / touch points

• common/skill.ts — enum + ARCHITECTURES selector metadata.
• electron/skillbuilder/ — new neutral generic-catalog.ts, wire into catalogueFor, plus a preamble/tail that explicitly forbids referencing product-specific tools.
• electron/automationbuilder/ — parallel support, or explicitly scope this issue to skills-only first (automations are Scout-only today).
• The renderer architecture selector should pick up the new enabled option automatically from ARCHITECTURES.

Acceptance criteria

• "Generic agent" appears as an enabled target in the architecture selector.
• Building a skill against it yields a SKILL.md with no product-specific internal tool names (e.g. no workiq_*, no Scout/Cowork built-in skill names).
• The generated steps remain runnable in principle by an agent that only has generic shell / browser / HTTP / file capabilities.
• Existing Scout and Cowork targets are unchanged.

Open questions

• Should "generic" permit a minimal common-denominator primitive set (shell/browser/HTTP/files), or be pure natural language with zero tool assumptions?
• Skills-only for v1, or include automations in the same change?

[karimad]

Opened #38 implementing this — a generic-catalog.ts with a neutral capability catalogue (no workiq_*/m365_*/named browser-tool suite, just shell/file/HTTP primitives), wired into SkillArchitecture/ARCHITECTURES/TARGETS/catalogueFor() alongside scout/cowork.

Tested end to end:

• Added a github-issue-triage-generic eval scenario (clone of the existing gh-vs-browser case, targeted at generic, rubric forbidding any vendor-specific tool name) — 100% pass against the real Copilot CLI builder; the plan generalized to gh CLI shell steps with zero product-specific references.
• Built a real skill through the app's UI end to end, exported the SKILL.md, installed it in an unrelated destination agent (Claude Code), and successfully invoked it there — confirming the output is genuinely portable, not just Scout/Cowork-shaped.

Scoped to skills only per your note in the issue (automations stay Scout-only). Doesn't implement #20's registry refactor — follows the existing enum/array/switch pattern so it's additive and shouldn't conflict if #20 lands separately.