In agent products, “skill” easily becomes an overloaded word. Any instruction, workflow, prompt, or rule written for an AI may get called a skill.

But in a product like SketchUp Agent Harness, skills are not just a loose folder of prompts. They are part of the product architecture.

SAH has at least three skill layers: product runtime skills, project/session dynamic runtime skills, and maintainer development skills. These layers must stay separate.

Product runtime skills are product surface

Product runtime skills are shipped to designers as part of the runtime experience. They describe spatial planning, component search, semantic placement, floor-plan import, design rules, visual feedback, and layout validation.

Their reader is not the maintainer. Their reader is the agent operating inside a designer’s project through an agent CLI.

That means they must:

  • be installed through the product or plugin mechanism into a user-loadable location;
  • not depend on maintainer source paths;
  • not encode facts from one customer project or one source image;
  • not leak temporary implementation details from development;
  • be testable and maintainable as product behavior.

A product runtime skill is product surface. It is not an ad hoc prompt.

Dynamic runtime skills are project-local memory

During designer use, some information only applies to the current project.

Examples include a symbol legend from one imported source, corrections the designer made for one import, current project room naming conventions, low-confidence regions for a specific source, or an explicitly stated preference for this project.

This can help the agent continue working in the current project, but it should not become product baseline behavior.

It belongs as project/session dynamic runtime skills in the active design project’s supported skill locations. Those skills are guidance, not canonical truth. The canonical structured state remains in design_model.json and imports/.

Development skills belong to maintainers

Maintainers also need skills, but those are different.

Development skills support product engineering: architecture decisions, Ruby bridge changes, MCP tools, release smoke, runtime skill authoring, issue triage, language review, and so on.

They should not live in the product repository’s runtime skills/ directory, and they should not be exposed to designers through product plugin manifests.

The reason is simple: maintainer workflow and designer runtime are different contexts. Mixing them leaks implementation detail into user runtime and lets temporary development judgments influence product behavior.

What goes wrong when layers mix

If product runtime skills include source-specific corrections, the next user may inherit lessons from the wrong drawing.

If dynamic runtime skills are committed to the product repository, local memory becomes global behavior.

If development skills are installed for designers, the agent may follow maintainer engineering workflow rather than designer workflow.

If product runtime skills only exist in the source tree and are not distributed through installation, designers are forced to clone the repository or copy files manually.

These are product governance problems, not documentation housekeeping problems.

Skills should not replace truth

Dynamic runtime skills should also not replace design_model.json.

A skill can guide the agent: “in this project, symbol X means a certain opening.” But the actual opening, wall, dimensions, and source provenance should live in structured truth or import evidence.

If all facts move into skills, the project loses validated state. The agent may understand the prompt, but the tool layer cannot validate, diff, execute, or repair it.

Skill is guidance. Truth is state. They cannot replace each other.

When local experience can be promoted

Some dynamic runtime memory may reveal a product gap.

For example, multiple projects may need the same source-symbol handling, or multiple designers may correct imports in the same pattern. Even then, the answer is not to copy one project’s dynamic skill into the product baseline.

A better promotion path is: abstract the reusable pattern, remove source-specific facts, add tests across variants, update product code, docs, or baseline runtime skills, and promote a central knowledge object only when the pattern is stable.

That is what skill governance means in product architecture.

Source trace