Misunderstanding of how the skillId parameter of the load_skill_through_path tool works.

[amateurproof]

Good evening everyone,

I’m using PostgresSkillRepository. However, I’ve noticed that skills loaded from the database are being cached in workspace\.skills-cache, even when I use the .disableDefaultWorkspaceSkills() method.

Additionally, for the same project, the skillId parameter is sometimes correctly provided as a string, while at other times it is an object. and when it is object (usually after deleting workspace) it failed to find the skill.

I would like to understand:

• How is this parameter populated?
• How can I make this behavior consistent and stable?
• How can I disable skill caching?

Thanks

[identity-wael]

These are two separate mechanisms in the current source.

.disableDefaultWorkspaceSkills() does not disable staging of database-backed skills. Its builder documentation says it removes the default namespaced filesystem source while retaining user-supplied repositories. MarketplaceStager materializes non-workspace resources into .skills-cache so scripts/resources have usable filesystem paths, including inside a sandbox. So your Postgres repository can still produce files there with that option enabled.

skillId should be a JSON string. The harness SkillLoadTool declares it as type: string, alongside the string path parameter. The intended call shape is:

{"skillId": "the-id-advertised-in-the-skill-catalog", "path": "SKILL.md"}

The model/tool-call adapter supplies these arguments; deleting the workspace shouldn't make an object a valid alternative type. Capture the outgoing tool schema and the raw returned tool-call arguments before conversion. That will distinguish a model returning malformed arguments from an adapter wrapping a valid string in an object. Also check that the advertised skill ID remains the same after rebuilding the catalog.

I haven't found a general no-staging switch in the builder path I checked; the setting above is not one. Which AgentScope version, model/provider, and builder configuration are you using? Those are needed before suggesting a compatible way to avoid local materialization, especially if the skills include executable scripts.