prompt-migate-lidr-ai-specs-copilot-plugin.md

prompt-migate-lidr-ai-specs-copilot-plugin.md

Role

You are a senior software architect and GitHub Copilot CLI plugin specialist. You have deep expertise in the GitHub Copilot CLI plugin system (plugin.json manifests, *.agent.md agent profiles, SKILL.md skill files, hooks.json hook configurations, and .mcp.json MCP server configs), and you are fluent at translating multi-copilot AI development specifications into this specific plugin format.

Objective

Analyse the LIDR-academy/ai-specs seed repository (https://github.com/LIDR-academy/ai-specs) and produce a detailed, step-by-step implementation plan that translates its development rules, standards, agent configurations, command-based workflows, and prompt templates into a valid, installable GitHub Copilot CLI plugin.

Context

The seed repository (LIDR-academy/ai-specs)

This repository provides a portable, multi-copilot development framework. Its structure is:

.
├── ai-specs/
│   ├── specs/
│   │   ├── base-standards.mdc      # Core dev rules (single source of truth)
│   │   ├── backend-standards.mdc
│   │   ├── frontend-standards.mdc
│   │   ├── documentation-standards.mdc
│   │   ├── api-spec.yml            # OpenAPI spec (reference example)
│   │   ├── data-model.md           # Database/domain models (reference example)
│   │   ├── development_guide.md    # Setup, workflows (reference example)
│   │   └── prompts.md              # Reusable prompt templates
│   └── changes/
│       ├── SCRUM-10-Position-Update.md  # Enriched user story example
│       └── SCRUM-10_backend.md          # Implementation plan example
├── AGENTS.md       # Generic agent config
├── CLAUDE.md       # Claude-specific config
├── codex.md        # Codex-specific config
└── GEMINI.md       # Gemini-specific config

Key concepts to translate:

1. Development standards (base-standards.mdc, backend-standards.mdc, frontend-standards.mdc, documentation-standards.mdc) — These define core principles (TDD, small incremental tasks, 90%+ test coverage, type safety, English-only, clear naming). They should become the plugin's foundational instructions.

2. Command-based workflow — The seed defines three sequential commands:

   • /enrich-us <TICKET-ID> — Enriches a user story with acceptance criteria, edge cases, technical considerations, testing scenarios.
   • /plan-backend-ticket <TICKET-ID> and /plan-frontend-ticket <TICKET-ID> — Generates step-by-step implementation plans saved to ai-specs/changes/.
   • /develop-backend @<PLAN-FILE> and /develop-frontend @<PLAN-FILE> — Implements the plan with TDD, proper testing, documentation updates.

3. Prompt templates (prompts.md) — Reusable prompt patterns used by the commands.

4. Reference examples (api-spec.yml, data-model.md, development_guide.md, enriched user story and implementation plan in changes/) — Serve as context and templates.

5. Multi-copilot agent configs (AGENTS.md, CLAUDE.md, codex.md, GEMINI.md) — Each references base-standards.mdc as single source of truth.

Target: GitHub Copilot CLI plugin format

The plugin must follow the official structure documented at https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/plugins-creating:

plugin-name/
├── plugin.json           # Required manifest
├── agents/               # Custom agents (*.agent.md files)
│   └── <name>.agent.md
├── skills/               # Skills (subdirectories with SKILL.md)
│   └── <skill-name>/
│       └── SKILL.md
├── hooks.json            # Hook configuration (optional)
└── .mcp.json             # MCP server config (optional)

plugin.json manifest fields: name, description, version, author, license, keywords, agents (path to agents dir), skills (array of paths to skills dirs), hooks (path to hooks.json), mcpServers (path to .mcp.json).

Agent profiles (.agent.md): Markdown with YAML frontmatter containing name, description, tools (array, optional — defaults to all tools), and a Markdown body with the agent's system prompt/instructions.

Skills (SKILL.md): Markdown with YAML frontmatter containing name (lowercase, hyphenated, must match parent directory name), description (10–1024 chars, describes when Copilot should use it), optional license. Markdown body contains instructions, examples, guidelines. Skills can include bundled scripts, references, and assets in subdirectories. Skills are invoked with /skill-name in the CLI.

Hooks (hooks.json): JSON with version: 1 and hook types like preToolUse, postToolUse, sessionStart, sessionEnd, etc. Each hook entry has type, bash/powershell commands, optional cwd, env, timeoutSec.

My repository

I have an empty repository ready to receive this plugin's code. The plan should assume a clean repo and provide the full file tree and content strategy for each file.

Transformation rules

1. Read every file in the seed repository (ai-specs/specs/*.mdc, ai-specs/specs/*.yml, ai-specs/specs/*.md, ai-specs/changes/*.md, AGENTS.md, CLAUDE.md, codex.md, GEMINI.md, and README.md) before producing the plan.

2. Map seed concepts → plugin components:

   • Development standards (.mdc files) → Embed as foundational instructions inside agent prompts and skill instructions. Standards content should be preserved faithfully — do not summarize or dilute the rules.
   • Command workflows (/enrich-us, /plan-backend-ticket, /plan-frontend-ticket, /develop-backend, /develop-frontend) → Each becomes a skill (subdirectory with SKILL.md). The skill description must clearly state the trigger phrases/patterns. The skill body must contain the full workflow instructions, referencing the standards.
   • Agent configs (AGENTS.md, CLAUDE.md, codex.md) → Merge into one or more custom agents (.agent.md). The primary agent should be a general-purpose development agent that enforces the standards. Consider whether specialised agents (e.g., backend-dev, frontend-dev, code-reviewer) add value.
   • Prompt templates (prompts.md) → Incorporate into relevant skill instructions as reference examples.
   • Reference examples (api-spec.yml, data-model.md, enriched US, implementation plan) → Bundle as reference files inside relevant skill directories (e.g., skills/enrich-us/references/, skills/plan-backend-ticket/references/).

3. Do not invent new functionality — Only translate what exists in the seed. If a concept has no natural mapping, note it in the plan and suggest how the user could extend it later.

4. Ensure the plugin is installable and testable — The plan must include:

   • Exact plugin.json content.
   • The full directory tree with every file listed.
   • For each file, a description of its purpose and the source material it derives from.
   • Instructions for local testing (copilot plugin install ./path, copilot plugin list, verification steps).

5. Preserve the single-source-of-truth principle — Standards content should live in one place within the plugin (e.g., a shared references/ directory or embedded once in the primary agent) and be referenced from skills, not duplicated across multiple files.

Output format

Produce the implementation plan as a structured Markdown document with these sections:

1. Plugin Overview — Name, description, version, target audience, and high-level goal.
2. Directory Tree — Full tree of every file and directory in the plugin, with inline annotations.
3. Component Mapping Table — A table mapping each seed file/concept to its plugin counterpart, with rationale.
4. File-by-File Specification — For every file in the directory tree:
   • File path
   • Purpose
   • Source material (which seed files it derives from)
   • Content strategy (what goes in it, key sections, how it references other plugin files)
   • Any open questions or decisions for the user
5. Implementation Order — Numbered sequence of steps to create the files, with dependencies noted (e.g., "create the shared references before the skills that reference them").
6. Testing & Validation Checklist — Steps to install, verify, and smoke-test the plugin locally using copilot plugin install, /skills list, /agent, etc.
7. Future Extensions — Brief notes on how the plugin could evolve (e.g., adding hooks, MCP servers, marketplace distribution).

Use code blocks for all file content, directory trees, and commands. Do not produce the actual file contents yet — only the plan. The implementation will happen in a subsequent step.