To dev dependency or to fork [useful Drupal AI projects]? That is the question.

Could we do a mixture of both? Have a fork of specific projects but closely align them so we can choose when we want to pull things in from the external project and aim to push things back?

This might be good from a "Drupal CMS" point of view but allow us to let other repos and libraries still control their own thing? (Given that this will likely be a dev tool anyway, its possible this isn't that important. The issue is whether or not the external skills we bring in change so much it makes devs less likely to want to use this tool)

I wonder if we take the approach of:

- Start by merely pulling in people's repos and leaving their code, skills etc in that external repo to manage. Get to a place where we like the core collection of skills that exist first.
- Figure out a good way of forking some skills and maintaining differences between the two and managing that. Do we have automated stuff telling us that things need to be updated so we can decide?

I suppose by "Both" I mean we fork it, but aim to keep it as close to the original as possible rather than truly have it diverge.

Edit: Seeing more of the context, I think we have lots of dependencies as the default approach. So many devs are already using lots of skills, it would be a shame for this to just be another one on the list. The world of Github that I think people are used to now is that there are tons of packages pulling things from all over the place. We can gradually fork things or build our own version of things here when we need to.

Edit: A major benefit to forking but keeping things in sync is it means we can more easily see and read through the skills in one place. If we go the dependency approach we should have some place, maybe documentation? That is automatically built that shows you all the skills that come with it so you can read them.

+1 on the approach :)

One thing to investigate is whether we can tie these external skill downloads to a specific git commit. If so, we can then control the "quality gate" and also check "diffs" / eval scores before pulling in newer versions. (I'm also curious if we can pull in _part_ of a broader skill; for example, https://skills.sh/grasmash/drupal-claude-skills/drupal-ddev which is part of https://skills.sh/grasmash/drupal-claude-skills/)

That should definitely be possible, for drupal/surge I'll be using Composer's package repository type for discovery for those non composer packages. You can see an example here:

{
    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "grasmash/drupal-claude-skills",
                "version": "1.0.0",
                "type": "library",
                "source": {
                    "url": "https://github.com/grasmash/drupal-claude-skills.git",
                    "type": "git",
                    "reference": "main"
                }
            }
        }
    ],
    "require": {
        "grasmash/drupal-claude-skills": "^1"
    }
}

The reference field should be a reference to the version that will be installed. Where the type field is git, the reference will be the commit id, branch or tag name.

That way we're basically doing the testing and versioning ourselves on those upstream changes that aren't doing release or tag management, we keep the control and the communication there.

The only thing we need to tackle is making sure it ends up in the right directory, as composer require won't install this in the right skills directory by default (but that is something we can achieve ourselves as well)