Skills Central repo and base skills creation prompt

project-managing-skill-scaffold.prompt.md

Current Skill Scaffold Prompt

You are a senior AI repository engineer and skill-system architect.

I already have a central repository for reusable AI and agent skills. I want you to scaffold the current set of repository-management skills for that repository, following the sharing model below.

Repository model:
- The central repository is the source of truth for reusable skills
- Project repositories use `AGENTS.md` at the repository root alongside a root `skills/` folder
- Project repositories consume selected shared skills from the central repository
- Shared-skill workflows should not assume a separate project `.ai/` or `ai/` folder
- Favor provider-agnostic skills wherever possible
- When provider-specific behavior is needed, use provider-specific add-on skills rather than mixing provider logic into a shared core skill
- Reusable skills in this repository should include `eval_queries.json` and `evals/evals.json`
- Imported skills must include `skill-source.md`
- Locally authored skills must not include `skill-source.md`
- If a script belongs to a specific skill workflow, keep it inside that skill rather than in a generic top-level `scripts/` folder

Please scaffold the following skills under `skills/experimental/ai/`:

1. `project-skill-installer`
Purpose:
- Central-repo-owned installer workflow for installing selected shared skills into a project's root `skills/` tree
- Accept a destination folder chosen somewhere inside the target project
- Resolve the actual project root from that selected folder
- Support symlink mode by default
- Support copy mode when needed

2. `github-skill-importer`
Purpose:
- Import a foreign skill from a GitHub repository into this central repository
- Copy the imported skill into the correct functional category
- Generate `skill-source.md`

3. `skill-creator-core`
Purpose:
- Provider-agnostic reusable-skill authoring workflow for this repository
- Scaffold `SKILL.md`, `eval_queries.json`, and `evals/evals.json`
- Validate reusable skill structure
- Keep shared guidance independent from provider-specific packaging

4. `skill-creator-openai`
Purpose:
- OpenAI or Codex-specific add-on for skill authoring
- Own `agents/openai.yaml` guidance or generation
- Stay separate from the provider-agnostic core

5. `skill-creator-anthropic`
Purpose:
- Anthropic or Claude-specific add-on for skill authoring
- Bridge provider-agnostic skills into Anthropic-specific repository instruction patterns
- Keep shared guidance separate from provider-specific wrappers

6. `skill-creator-github-copilot`
Purpose:
- GitHub Copilot-specific add-on for skill authoring
- Bridge provider-agnostic skills into GitHub Copilot skill locations such as `.github/skills/` and `~/.copilot/skills/`
- Keep shared guidance separate from provider-specific placement and packaging rules

Design requirements:
- Keep all of these skills in `experimental` for now
- Do not generate unnecessary filler files
- Each skill must contain a real `SKILL.md`
- Each skill must contain `eval_queries.json`
- Each skill must contain `evals/evals.json`
- Add `scripts/` only where there is an actual script-based workflow
- Add `references/` only where reference material is actually needed
- Add `skill-source.md` only to imported skills
- Use lowercase folder names with hyphens
- Keep each skill understandable in isolation
- Ensure the core/add-on boundary is obvious from the file structure and descriptions
- Do not create a second overlapping bootstrap skill for project consumption

Imported skill policy:
- If you adapt from an upstream skill, mark the imported version as `adapted`
- Capture provenance in `skill-source.md`
- Make the central repository the operational source of truth
- Do not leave project repositories dependent on the upstream source

Validation requirements:
- The scaffold should be consistent with agentskills-style eval files
- Trigger evals should distinguish similar but different skills
- Output evals should check the intended behavior and boundaries of each skill
- The provider-agnostic core should not require OpenAI-specific files

Deliverables:
1. Proposed folder tree for these skills
2. For each skill:
   - purpose
   - required files
   - optional files
   - notes on scope boundaries
3. A concise explanation of how the provider-agnostic core relates to the three provider-specific add-ons
4. A concise explanation of which of these skills should carry `skill-source.md`
5. Compact starter content for all required files

Important constraints:
- Do not overengineer
- Do not invent unrelated additional skills
- Do not create duplicate top-level helper scripts outside skill folders
- Keep the skill set pragmatic and team-shareable
- Optimize for maintainability and clarity over cleverness

skills-central-repo-creation.prompt.md

Repository Design Prompt

You are a senior AI engineering assistant, repository designer, and developer tooling architect.

I want you to design a Git repository for centralized AI skill management on macOS.

Context:
- I work on a Mac
- I use VS Code, Codex, and Xcode
- I want one central repository as the source of truth for reusable AI and agent skills
- Individual project repositories should later consume selected skills from this central repo, ideally via symlinks or a small bootstrap script
- The solution should be easy to share with a team
- This setup may later also be introduced at work
- The repo should therefore not feel like a personal experiment, but like a pragmatic and maintainable foundation
- Main framework areas are:
  - AI
  - .NET
  - .NET MAUI
  - Swift / SwiftUI
- I also want shared cross-project skills such as:
  - architecture review
  - code review
  - TDD coaching
  - ADR / specification writing
  - technical blog writing

Goals:
- Create a maintainable, scalable repository structure
- Keep the solution tool-agnostic as much as possible
- Make it easy for project repos to consume selected skills
- Separate stable vs experimental skills
- Separate global reusable skills from project-local context
- Make the repository understandable and shareable in a team setting
- Prepare the repo so it is good enough to later support a technical blog post about the setup

Important repository design preferences:
- Do not create placeholder skills
- Do not generate fake example skills just to fill folders
- If a folder is intentionally empty, use `.gitkeep`
- Assume the repository will quickly be filled with real content
- Favor clean structure and conventions over artificial examples
- Prefer lowercase folder names with hyphens where appropriate
- Use Markdown for documentation
- Assume the repo will be hosted on GitHub
- Project repositories should use `AGENTS.md` at the repository root alongside a root `skills/` folder
- Do not assume a separate project `.ai/` or `ai/` folder for the shared-skill workflow
- If a script belongs to a specific skill workflow, prefer keeping it inside that skill rather than in a generic top-level `scripts/` folder
- Favor provider-agnostic reusable skills wherever possible
- When provider-specific behavior is needed, prefer provider-specific add-on skills over mixing provider logic into a shared core skill
- Reusable skills in this repository should include `eval_queries.json` and `evals/evals.json`

Imported / external skill policy:
- The central repository must be the operational source of truth for imported external skills
- Project repositories must not import third-party skills directly from external repositories once this central repo exists
- Imported skills should live in their functional category (for example `ai`, `dotnet`, `maui`, `swift`) rather than in a separate `imported` root
- Every imported external skill should contain a `skill-source.md` file documenting provenance and update information
- `skill-source.md` should capture at least:
  - upstream repository
  - upstream path
  - imported commit / tag / version
  - import date
  - local status (`mirror`, `adapted`, or `forked`)
  - notes about local modifications
- Locally authored skills should not contain `skill-source.md`
- The repository design should include a concise update policy for imported skills
- The default recommendation should be to import external skills by copy into the central repo, curate them there, and update them intentionally

Please design the repository with the following deliverables:

1. Proposed repository name
2. Short design rationale
3. Recommended folder structure
4. Naming conventions for folders and skills
5. A clear separation strategy for:
   - shared skills
   - ai skills
   - dotnet skills
   - maui skills
   - swift skills
   - writing skills
   - architecture skills
   - stable vs experimental
6. A proposal for minimal documentation files, such as:
   - README.md
   - CONTRIBUTING.md
   - docs/architecture.md
   - docs/usage.md
   - docs/imports.md
7. A proposal for how project repos should consume these skills:
   - symlink-based approach
   - optional bootstrap script approach
8. A small example bootstrap script for macOS shell
9. Guidance on what belongs in the central repo vs what should remain project-local
10. A concise update policy for imported skills, including the role of `skill-source.md`
11. A section called “Team adoption notes” that explains how this repo can be introduced in a small engineering team
12. A section called “Future blog post notes” summarizing why this setup is useful

Important constraints:
- Do not overengineer
- Favor pragmatic simplicity
- The structure should be easy to understand for a single developer but extensible for a team
- Do not generate huge placeholder content
- Do not invent sample skills just to populate the tree
- Use `.gitkeep` for intentionally empty folders
- Keep all starter documentation concise but concrete

Output format:
- First provide a short design rationale
- Then show the proposed repository tree
- Then provide the recommended starter files with compact content
- Then provide the bootstrap script
- Then provide operating guidelines for maintaining the repo over time
- Finally provide team adoption notes and future blog post notes