The vision of unifying Copilot/Cursor/Roo/Cline/etc. under a common configuration and best-practice layer is compelling, and I like the direction toward reusable templates and memory.

That said, I think the project might be aiming a bit too directly at the highest level of complexity — the full integration of vibe-driven rules across assistants — without first grounding things in foundational concepts. Personally, I’d love to see a clearer breakdown of stages, such as:

1. Formal concepts of LLM-driven project management, akin to how we reason about conventional PM tools/processes.

2. Abstractions and interfaces to build structured rules/prompts (in the broad sense) that can be versioned, composed, and reasoned about.

3. Configuration management to deploy/adapt those rules across specific environments (LLMs, IDEs, agents).

Laying that groundwork could make the ambitious cross-assistant unification feel more achievable and less brittle.

Still, kudos — I think we need more of this kind of experimentation and discussion in the open.

I think this suggestion of polishing the basic layer first and then building the high level layer is a good one. Since the potential development directions are so broad (marketplace for rule sets, evaluation of rule sets, version control of rule sets, more useful tools, unit test & deployment & PM rules), I have never dared to over-design before users have clear feedback.

For project management, I have another exploratory project. This project is a set of rules that use Cursor/Cline/Windsurf as a project manager assistant. repo is here: https://github.com/botingw/pm-workflow-copilot-ide

For your 2, I understand versioning with rules. Does compose mean assembling rules? What does reasoned about mean?

For your 3, what configuration management do you recommend adding?

Yes, I agree. This feels very complex for something that is supposed to support vibe coding.