hide dev skills

[reidbaker]

Fixes: #156

Exclusions are done by following the documenation in https://github.com/vercel-labs/skills/blob/main/README.md#optional-fields

• Takes the skills that are intended for users of dart_skills_lint and excludes them for now.
• Takes the custom development and test skills and excludes them.
• Adds a new rule "prevent-skills-sh-publishing" for dart_skills_lint that can enforce when a directory or skill should not be published.
• Deletes the skills that are hosted elsewhere and gives instructions on how to install them with npx. This is the most important to me as I dont want skills.sh to republish those skills. The cost of this decision is more difficult onboarding for new dart_skills_lint contributors.

I dont actually have a way to test that the scraper that is run by vercel will work or a way to trigger it but this is in their documentation and in the code (https://github.com/vercel-labs/skills/blob/main/src/skills.ts#L81-L86)

Commits:

• Mark development and fixture skills as internal to exclude them from skills.sh
• Create prevent-skills-sh-publishing rule, enable it, add tests and documentation
• Mark specific development tools as internal and add them to linter enforcement config
• Migrate standard agent skills to npx remote installs
• Improve documentation and errors that show when in a bad state
• Address code review feedback: add copyright headers and handle string whitespace

[gemini-code-assist]

Code Review

This pull request introduces a new lint rule, prevent-skills-sh-publishing, which ensures that internal skills are marked with metadata: internal: true in their frontmatter to prevent accidental publishing. It also transitions several local skill files to remote dependencies, updates the skills-lock.json lockfile, and adds corresponding unit tests. The review feedback suggests checking for yamlParsingError to avoid duplicate diagnostics, adding a unit test for malformed YAML handling, and aligning the documented diagnostic shapes in RULES.md with the actual error messages in the implementation.

[gemini-code-assist]

To ensure that the rule correctly ignores malformed YAML (which is already handled by the valid-yaml-metadata rule), we should add a unit test verifying that no errors are returned when yamlParsingError is present.

    test('returns no errors when there is a YAML parsing error', () async {
      final rule = PreventSkillsShPublishingRule(severity: AnalysisSeverity.warning);
      final context = SkillContext(
        directory: Directory('dummy'),
        rawContent: '---\ninvalid: yaml: : mapping\n---\n',
        yamlParsingError: 'YAML parsing error details',
      );

      final List<ValidationError> errors = await rule.validate(context);

      expect(errors, isEmpty);
    });

[jakemac53]

If you run this locally will it not trigger on all your installed skills? Is something else skipping the git ignored skills?

[reidbaker]

If you look on line 17 the rule is disabled by default. So that begs the question where is it enabled. That happens in tool/dart_skills_lint/dart_skills_lint.yaml where we are listing the 3 skills that are checked in.

[jakemac53]

Hmmm ok, similar to my other comment that approach seems less than ideal when adding any new skills (you have to remember to manually add them or get no lints).

An opt-out model would likely be better.

IMO in general the whole skills "standard" just does a terrible job of handling mixed third party vs locally developed skills.

We could develop our own standard, putting custom skills under skills/local or something, and applying the lints to all of those. 🤷‍♂️

I don't think this has to be addressed in this PR in any case.

[reidbaker]

FWIW I added a test in tool/dart_skills_lint/test/prevent_skills_sh_publishing_rule_test.dart to enforce the behavior you are worried about in this repo.