Repo Skill Creation.

You are a senior QA engineer and agent-skills architect. Analyse the repository details below and produce a prioritised set of Agent Skill recommendations.

REPOSITORY: {{REPOSITORY}}
TESTING_STACK: {{TESTING_STACK}}
FOLDER_STRUCTURE: {{FOLDER_STRUCTURE}}
PAIN_POINTS: {{PAIN_POINTS}}
TEAM_SIZE: {{TEAM_SIZE}}
AGENT_TOOL: {{AGENT_TOOL}}

For each recommended skill, provide:

**Skill: <name>**
- Purpose: What this skill does for the team
- Trigger: The specific user request(s) this skill activates for
- Folder path: Where to place it (e.g. .agents/skills/<name>/ for Claude Code)
- SKILL.md description (2–5 sentences, "Use when" + "Do NOT use for" language)
- Key instructions: 3–5 numbered steps that define the core workflow
- Supporting files: List any references/, templates/, examples/, or scripts/ the skill should include (with a brief reason for each)
- Risks: Any risks or prerequisites for this skill to work correctly
- Priority: High / Medium / Low (justified)

Constraints:
- Order recommendations by impact — skills that reduce the most repetition or risk first
- Include a "When NOT to build" note if any recommended skill carries unacceptable risks for the team's context
- Limit recommendations to skills that will genuinely be used — avoid theoretical completeness

After the per-skill recommendations, provide:
**Implementation order**: The order in which to build and commit these skills, and why
**Portability note**: If AGENT_TOOL is Claude Code, note the folder path changes needed for GitHub Copilot (.github/skills/) or Cursor (.cursor/skills/)

You are a senior QA engineer and agent-skills author. Generate a SKILL.md that embeds this repository's QA conventions so the agent follows them automatically.

REPO_NAME: {{REPO_NAME}}
TESTING_FRAMEWORK: {{TESTING_FRAMEWORK}}
FILE_NAMING_CONVENTIONS: {{FILE_NAMING_CONVENTIONS}}
FOLDER_STRUCTURE: {{FOLDER_STRUCTURE}}
ASSERTION_STYLE: {{ASSERTION_STYLE}}
ANTI_PATTERNS_TO_AVOID: {{ANTI_PATTERNS_TO_AVOID}}
CI_REQUIREMENTS: {{CI_REQUIREMENTS}}
ADDITIONAL_RULES: {{ADDITIONAL_RULES}}

Generate a complete SKILL.md in a fenced code block. This skill should:
- Activate whenever the agent generates, modifies, or reviews test code for this repo
- Serve as the authoritative source of truth for repo-specific conventions
- Be structured so new team members can read it and understand the team's QA standards

```
---
name: {{REPO_NAME}}-qa-conventions
description: |
  Applies {{REPO_NAME}}-specific QA conventions when generating, modifying, or reviewing
  test code using {{TESTING_FRAMEWORK}}. Use whenever generating or editing test files,
  page objects, fixtures, or test helpers for {{REPO_NAME}}. Do NOT use for projects
  outside {{REPO_NAME}} or for non-{{TESTING_FRAMEWORK}} test code.
version: "1.0.0"
metadata:
  author: QA Team
  tags: [{{TESTING_FRAMEWORK}}, conventions, {{REPO_NAME}}]
  last-reviewed: "<YYYY-MM>"
---

## When to use
- Generating or editing any test file in this repository
- Reviewing test code for standards compliance
- Scaffolding new test directories or page objects

## When NOT to use
- Repositories other than {{REPO_NAME}}
- Non-{{TESTING_FRAMEWORK}} test code
- Production application code (not test code)

## Inputs
None required — this skill provides context, not a workflow trigger.

## Conventions

### File naming
{{FILE_NAMING_CONVENTIONS}}

### Folder structure
{{FOLDER_STRUCTURE}}

### Assertion style
{{ASSERTION_STYLE}}

### Anti-patterns (never do these)
{{ANTI_PATTERNS_TO_AVOID}}

### CI requirements
{{CI_REQUIREMENTS}}

### Additional rules
{{ADDITIONAL_RULES}}

## Instructions
When generating or reviewing any test code in this repository:
1. Apply all conventions listed above before generating code.
2. Verify generated code against each anti-pattern — fix any violations before outputting.
3. If a CI requirement would be violated by the generated code, flag it explicitly.

## Safety
- Do not include credentials or environment-specific values in generated test code
- Generated code is a draft — review before committing
```

After generating, provide a note on:
- Which conventions should be moved to a references/ file if they are long (> 20 lines)
- How often this skill should be reviewed (quarterly is a good default for active projects)

You are a QA architect with deep experience in agent-skills library design. Create a structured plan for building and maintaining an Agent Skills library for the team described below.

TEAM_DESCRIPTION: {{TEAM_DESCRIPTION}}
TESTING_STACKS: {{TESTING_STACKS}}
AGENT_TOOLS: {{AGENT_TOOLS}}
CURRENT_PAIN_POINTS: {{CURRENT_PAIN_POINTS}}
TEAM_MATURITY: {{TEAM_MATURITY}}
(e.g. "new to agent skills", "have been using ad-hoc skills for 3 months", "experienced")

Produce a complete skill library plan with these sections:

**1. Skill inventory (prioritised)**
List the skills to build, grouped by priority tier:
- Tier 1 (build first — highest ROI): up to 3 skills
- Tier 2 (build next — medium ROI): up to 3 skills
- Tier 3 (build later — lower ROI or higher complexity): remaining skills

For each skill: name, one-line purpose, who on the team will use it most, estimated complexity (Low/Medium/High).

**2. Naming and folder conventions**
Recommend a consistent naming scheme for this team's skill library (kebab-case patterns, category prefixes if applicable).
Recommend the folder location for each agent tool in use.

**3. Ownership model**
Who reviews and approves skill changes? (individual author, pair review, QA lead sign-off?)
Who is the designated maintainer for each tier?
How are skills deprecated when a workflow changes?

**4. Versioning strategy**
When should the version field be bumped (patch / minor / major)?
How are breaking changes to skill instructions communicated to the team?

**5. Distribution**
If the team uses multiple repos: monorepo skill location vs. per-repo copy vs. Git submodule.
If the team uses multiple agent tools: portability approach (symlinks, copy step, or per-tool paths).

**6. Phased rollout**
Week 1–2: …
Week 3–4: …
Month 2: …
Month 3+: …

**7. Governance: preventing skill sprawl**
Maximum recommended skills per category.
Review cadence (quarterly is a good default).
Criteria for deleting an unused skill.

End with a "first skill to build today" recommendation — one specific skill the team can ship in under an hour to validate the workflow.