addressed comments (clarification of customers vs product teams)

Author: jrobertboos

docs/design/agent-skills/agent-skills-spike.md

@@ -16,11 +16,13 @@ These are the high-level decisions that determine scope, approach, and cost. Eac
 
 | Option | Description |
 |--------|-------------|
-| A | Built-in skills only (Lightspeed developers ship pre-defined skills) |
-| B | Customer-defined only (end users import their own skill definitions) |
-| C | Both built-in and customer-defined |
+| A | Built-in skills only (Lightspeed Core developers ship pre-defined skills) |
+| B | Product team-defined only (LS app teams like RHEL Lightspeed define their own skills) |
+| C | Both built-in and product team-defined |
 
-**Recommendation**: **B** (Customer-defined only). This allows end users to extend Lightspeed with their own domain expertise without requiring changes to the core product. Built-in skills can be added later if needed.
+**Recommendation**: **B** (Product team-defined only). This allows LS app teams (e.g., RHEL Lightspeed, Ansible Lightspeed) to extend Lightspeed with domain-specific skills without requiring changes to Lightspeed Core. Product teams ship skills alongside the lightspeed-stack container by mounting skill directories via configmaps or container volumes, then pointing to them in `lightspeed-stack.yaml`. Built-in skills can be added to Lightspeed Core later if common patterns emerge.
+
+**Note**: End users of LS app products do NOT have the ability to add skills, similar to how they cannot add MCP servers. Skill configuration is controlled by product teams at deployment time.
 
 ### Decision 2: Discovery mechanism?
 
@@ -29,7 +31,7 @@ These are the high-level decisions that determine scope, approach, and cost. Eac
 | A | Filesystem-based (scan configured directories for `SKILL.md` files) |
 | B | Config-based (define skills in `lightspeed-stack.yaml`) |
 | C | API-based (skills registered/managed via REST API) |
-| D | Hybrid (built-in via config, customer-defined via filesystem or API) |
+| D | Hybrid (built-in via config, product team-defined via filesystem or API) |
 
 **Recommendation**: **B** (Config-based). Skills are defined in `lightspeed-stack.yaml` similar to `mcp_servers`. This provides explicit control over which skills are available, integrates with existing configuration patterns, and avoids filesystem scanning complexity.
 
@@ -332,7 +334,7 @@ OpenAI's SDK already includes `LocalSkill` and `Skill` types in its responses mo
 
 **Path restrictions**: The `activate_skill` tool and reference file access are restricted to configured skill directories. The LLM cannot access arbitrary filesystem paths through skills.
 
-**Trust model**: Since skills are configured by administrators in `lightspeed-stack.yaml`, there's an implicit trust that configured skill paths contain appropriate content.
+**Trust model**: Skills are configured by LS app teams (e.g., RHEL Lightspeed) at deployment time, not by end users. Product teams mount skill directories into the container via configmaps or volumes and reference them in `lightspeed-stack.yaml`. This mirrors the MCP server trust model — end users cannot add arbitrary skills, only use the skills their product team has deployed.
 
 ## Appendix A: Existing approaches research
 

docs/design/agent-skills/agent-skills.md

@@ -11,7 +11,9 @@
 
 ## What
 
-Agent Skills support allows customers to extend Lightspeed Core with specialized instructions and domain knowledge packaged as portable skill directories. Skills follow the [Agent Skills open standard](https://agentskills.io) and are configured in `lightspeed-stack.yaml`.
+Agent Skills support allows LS app teams (e.g., RHEL Lightspeed, Ansible Lightspeed) to extend Lightspeed Core with specialized instructions and domain knowledge packaged as portable skill directories. Skills follow the [Agent Skills open standard](https://agentskills.io) and are configured in `lightspeed-stack.yaml`. Product teams ship skills alongside the lightspeed-stack container by mounting skill directories via configmaps or container volumes.
+
+**Note**: End users of LS app products do NOT have the ability to add skills, similar to how they cannot add MCP servers. Skill configuration is controlled by product teams at deployment time.
 
 The LLM sees a skill catalog (name + description) in the system prompt and can load full instructions on demand using the `activate_skill` tool.
 
@@ -43,10 +45,10 @@ Skills solve this by giving the LLM access to procedural knowledge and domain-sp
 
 ## Use Cases
 
-- **U1:** As a platform administrator, I want to configure troubleshooting skills so that the LLM can help users diagnose common issues
+- **U1:** As an LS app team administrator, I want to configure troubleshooting skills so that the LLM can help users diagnose common issues
 - **U2:** As a skill author, I want to create a SKILL.md file with instructions so that I can package domain expertise portably
 - **U3:** As a user, I want the LLM to automatically use relevant skills so that I get better answers without manually specifying which skill to use
-- **U4:** As an enterprise customer, I want to deploy custom skills so that the LLM understands our internal processes and terminology
+- **U4:** As an LS app team, I want to deploy domain-specific skills so that the LLM understands product-specific processes and terminology
 
 ## Architecture