Questions about ooo external Skills // claude-cli

[MaStr]

Thank you for that amazing project. Love it.

I am running the project inside claude cli tool with the ooo commands using the "internal" mcp backend.

I am trying to figure out how skills inside the users ~/.claude/ folders may contribute to the different agents.
For example:

• I like to have some coding style guides for C development and I created a claude skill for that.
• I have another plugin written for storing some analysis results in mcp based knowledge based. To guide claude in this direction I have a skill.

I assume that these things are currently not taken into account by the subagents doing the actual work.
Is my assumption correct?

If so, how can I steer ooo into a direction like this ideally without modifying the plugin's source code locally.

Many thanks

[ouroboros-agent]

$Thanks for the kind words — and yes, your assumption is very likely correct.

The current worker/sub-agent flow typically only sees the context and tools that Ouroboros explicitly passes into that run. Personal Claude skills living in ~/.claude/ are generally not something Ouroboros can assume or automatically inherit across the internal MCP-backed execution path unless that integration is wired in on purpose.

So if your goal is to steer ooo without modifying the plugin source locally, the safest current options are usually:\n\n- put the important guidance directly into the task/spec/seed that drives the run

• expose reusable behavior through an MCP-accessible tool or knowledge source the worker can call
• keep project-specific conventions in repo-visible docs/config that the agent is instructed to read

What would help most is a concrete example of the steering model you want:

1. Should user-local Claude skills be inherited automatically by all subagents?
2. Should they be selectively enabled per run/mind?
3. Or should there be an explicit bridge from external Claude skills into Ouroboros seeds/specs?

If you want, we can treat this issue as a product/design discussion first and then turn it into a scoped feature request once the desired behavior is precise enough.

ouroboros-agent[bot]

[MaStr]

Thank you for the verification of my assumption. Those are very good questions, i needed to think a while about that.

If I am running inside claude context out of the claude-cli, I think - as a part of the setup - you can choose to make the skills available to all subagents or not.

The most advanced option could be to configure skills in the .ouroboros folder like:

• .ouroboros/skills -> root folder
• .ouroboros/skills/all -> Skill which should be available to all agents
• .ouroboros/skills/<agent_name> -> addiitonal skills, which should be only available to one particular persona

If .ouroboros/skills is created, I guess the best thing is to ignore claude's skills in that case.

[ouroboros-agent]

Thanks for the thoughtful proposal — the directory structure idea is clean and intuitive.

The part we need to think carefully about is that Ouroboros is built on Socratic reasoning: the interview process generates questions to reduce ambiguity, and the evaluator judges results against acceptance criteria derived from that conversation. Injecting external skills into subagents could subtly shift how questions are framed or how verification evidence is interpreted — which is exactly the kind of hidden assumption Ouroboros is designed to surface, not absorb silently.

So the design question is not just "where do skills load from" but "at which pipeline stage should external guidance enter, and how do we keep it transparent to the Socratic process?"

We are tracking this as a feature request and will think through the interaction model before committing to an implementation.

ouroboros-agent[bot]

[Q00]

Hey @MaStr, really appreciate the thoughtful proposal! The .ouroboros/skills/{all,<agent_name>} directory idea is super clean — love how intuitive it feels.

We're definitely going to explore this direction. That said, we want to be honest about the complexity involved. Ouroboros leans heavily on its Socratic pipeline (interview → seed → execute → evaluate) to catch hidden assumptions early. If external skills get injected into subagents without careful guardrails, they could quietly shift how questions get framed or how results get evaluated — which is exactly the kind of invisible influence the system is built to prevent.

So we'll take our time with this one. The goal is to make sure any external guidance enters the pipeline in a way that's explicit and traceable, not as a silent backdoor. We'll share design updates here as things take shape.

Thanks again for pushing us on this — it's the right problem to solve.