@groupby/ai-dev 0.5.5 → 0.5.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@groupby/ai-dev",
-  "version": "0.5.5",
+  "version": "0.5.8",
   "description": "Interactive installer for Rezolve Ai development content",
   "type": "module",
   "bin": {

package/teams/OOF/skills/jira-ticket-creator/README.md

@@ -0,0 +1,22 @@
+# Jira Ticket Creator
+
+Creates well-structured Jira epics, stories, and sub-tasks from product and 
+technical specifications using the Atlassian MCP connector.
+
+## What it does
+- Reads product and/or technical specs from Confluence
+- Plans Epics → Stories → Sub-tasks hierarchy
+- Previews all ticket content for approval before creating anything in Jira
+- Creates tickets with correct parent relationships and team assignments
+
+## Prerequisites
+- Atlassian MCP connector connected
+- Write access to the target Jira project
+
+## Trigger phrases
+- "Create Jira tickets from this spec"
+- "Break this PRD into epics and stories"
+- "Generate Jira tickets from this Confluence page"
+
+## Team
+OOF

package/teams/OOF/skills/jira-ticket-creator/SKILL.md

@@ -0,0 +1,266 @@
+---
+name: jira-ticket-creator
+description: Create Jira epics, stories and sub-tasks from product and technical specifications. Use this skill whenever a user asks to create epics, stories, sub-tasks, or tickets in Jira from a spec, PRD, product specification, technical specification, or Confluence page. Also trigger when a user says things like "break this spec into epics", "create Jira tickets from this document", "plan this initiative into stories", "generate epics for this project", or any request involving turning requirements or specifications into structured Jira work items. Requires the Atlassian MCP connector.
+---
+
+# Jira Ticket Creator
+
+Creates well-structured Jira epics, stories and sub-tasks from product and technical specifications, using the Atlassian MCP connector.
+
+## Prerequisites
+
+- **Atlassian MCP connector** must be connected. If not connected, prompt the user to connect it before proceeding.
+- The user must have write access to the target Jira project.
+
+---
+
+## Configuration Parameters
+
+Collect ALL mandatory parameters before creating any tickets. Present them clearly and confirm with the user before proceeding.
+
+### Mandatory Parameters
+
+| Parameter | Description | Validation |
+|---|---|---|
+| **Jira Team** | The Jira team to assign to ALL tickets. The user MUST choose one of the two fixed options below. | Required. Present as a two-choice selection. Do not advance until the user selects a team. |
+| **Parent** | The Jira initiative key that all epics will be children of (e.g. `BD-7711`). | Required. Must be a valid Jira issue key. Do not advance until provided. |
+| **Product Specification** | A Confluence page URL containing the product spec / PRD. | Required. Must be a valid Confluence URL. Do not advance until provided. |
+
+**Jira Team options** (offer these two as selectable choices — do NOT ask the user to type a free-text team name):
+
+| Team name | Team ID (`customfield_10700` value) |
+|---|---|
+| **OOF Mobile Solution Team** | `b3f517d4-c4f8-4144-8920-b762ec5a033b` |
+| **OOF Application Solution Team** | `9817d9ca-6170-48e8-9e98-1aeb7c81daa5` |
+
+### Optional Parameters
+
+| Parameter | Description | Default |
+|---|---|---|
+| **Technical Specification** | A Confluence page URL containing the technical spec. | None — if not supplied, generate tickets from the product spec only. |
+| **Epic Number** | Maximum number of epics to produce. | LLM decides based on the scope of the specification. |
+| **Ticket Style** | A URL pointing to a Confluence page with guidelines for how to write/format tickets. Always offer the user the choice to accept the default page or enter a new URL. | `https://rezolvetech.atlassian.net/wiki/spaces/CPST/pages/5303500826/Definition+of+user+story+acceptance+criteria` |
+| **Sub Tasks** | Whether to create sub-tasks under each story. `yes` or `no`. | `no` — do not create sub-tasks unless explicitly set to `yes`. |
+
+---
+
+## Workflow
+
+### Step 1 — Collect and Confirm Configuration
+
+**Always ask the user for the configuration values interactively before doing anything else.** Go through the parameters **one at a time, in order**. For each parameter:
+
+- State the parameter name and a short description.
+- Show its **default value** (or `None` / `LLM decides` where there is no fixed default).
+- Offer the user the choice to **accept the default** or **enter a new value**. Use interactive options where possible (e.g. an "Accept default" choice alongside a free-text input).
+- **For mandatory parameters (Jira Team, Parent, Product Specification), you MUST NOT advance to the next parameter until the user supplies a value.** If the user leaves it blank, skips, or gives an empty answer, re-ask the SAME parameter and keep asking until a value is provided.
+- For **Jira Team**, present the two fixed options (**OOF Mobile Solution Team** and **OOF Application Solution Team**) as a selectable choice. Do NOT accept or ask for a free-text team name. Map the chosen team to its ID for the `customfield_10700` field.
+- For **Ticket Style**, always present an explicit choice to **accept the default Confluence page** or **enter a new ticket style URL**.
+
+Use a prompt along these lines, asking for one value at a time:
+
+> Let's set up the configuration. For each item, reply **"default"** to accept the shown default, or type a new value.
+>
+> | # | Parameter | Mandatory | Default value |
+> |---|---|---|---|
+> | 1 | **Jira Team** | Yes | None — choose **OOF Mobile Solution Team** or **OOF Application Solution Team** |
+> | 2 | **Parent** | Yes | None — please provide (e.g. `BD-7711`) |
+> | 3 | **Product Specification** | Yes | None — please provide a Confluence URL |
+> | 4 | **Technical Specification** | No | None (skipped if blank) |
+> | 5 | **Epic Number** | No | LLM decides based on spec scope |
+> | 6 | **Ticket Style** | No | `https://rezolvetech.atlassian.net/wiki/spaces/CPST/pages/5303500826/Definition+of+user+story+acceptance+criteria` |
+> | 7 | **Sub Tasks** | No | `no` |
+
+Once all values are collected, **display a summary table of the final configuration** — indicating for each parameter whether the default was accepted or a custom value was entered — and ask the user to confirm before proceeding.
+
+### Step 2 — Read the Specifications
+
+Use the Atlassian MCP connector to read the Confluence pages:
+
+1. **Read the Product Specification** from the supplied Confluence URL. This is the primary source of requirements.
+2. **Read the Technical Specification** (if supplied) from the Confluence URL. This supplements the product spec with implementation details.
+3. **Read the Ticket Style guide** from the Ticket Style URL. This defines how to format epic descriptions, story titles, acceptance criteria, and other ticket fields.
+
+If any page cannot be read, inform the user and ask for a corrected URL.
+
+### Step 3 — Jira Field Reference
+
+Use the following Jira field IDs and exact payload formats when creating tickets in the BD project. The `parent` field MUST be passed as an object (`{ "key": "..." }`), never as a bare string — passing a string is the usual cause of "can't find / invalid parent field" errors.
+
+1. **Team field** — custom field `customfield_10700` (Atlassian Team field type). It is **mandatory** on every ticket. Set it to the **ID** of the configured **Jira Team** as a **bare string**, e.g. `"customfield_10700": "b3f517d4-c4f8-4144-8920-b762ec5a033b"`. Use the ID, never the team name. **Do NOT wrap the ID in an object** (e.g. `{ "id": "..." }`) — although the field reads back as an object, on write the API rejects the object form with `Team id 'JsonData{data={id=...}}' is not valid`. Pass the raw ID string only:
+   - **OOF Mobile Solution Team** → `b3f517d4-c4f8-4144-8920-b762ec5a033b`
+   - **OOF Application Solution Team** → `9817d9ca-6170-48e8-9e98-1aeb7c81daa5`
+2. **Epic → parent initiative** — standard `parent` field: `"parent": { "key": "BD-7711" }` (substitute the configured **Parent** initiative key).
+3. **Story → parent epic** — standard `parent` field set to the epic's key: `"parent": { "key": "<EPIC-KEY>" }`.
+4. **Sub-task → parent story** — standard `parent` field: `"parent": { "key": "<STORY-KEY>" }`.
+
+All ticket content must be derived exclusively from the Product Specification and Technical Specification provided by the user.
+
+### Step 4 — Plan the Epics and Stories
+
+Based on the specifications and ticket style guide, plan the breakdown:
+
+1. **Identify logical epic groupings** from the product spec. Each epic should represent a coherent feature area or workstream.
+2. If **Epic Number** is set, constrain to that maximum. If not set, choose the number that best represents the natural groupings in the spec.
+3. For each epic, identify the user stories needed. Stories should be independently deliverable increments of work.
+4. If **Sub Tasks** is `yes`, further decompose each story into sub-tasks (implementation steps, testing, etc.).
+
+**Present the full plan to the user as a high-level tree for initial structural review:**
+
+```
+Epic 1: [Title]
+  ├── Story 1.1: [Title]
+  ├── Story 1.2: [Title]
+  └── Story 1.3: [Title]
+
+Epic 2: [Title]
+  ├── Story 2.1: [Title]
+  └── Story 2.2: [Title]
+  ...
+```
+
+Ask the user: **"Does this structure look right? Should I add, remove, merge, or split any epics or stories before I draft the full ticket content?"**
+
+Wait for approval or iterate on the structure until the user is satisfied.
+
+### Step 5 — Preview Full Ticket Content
+
+**CRITICAL: Do NOT create any tickets in Jira until the user explicitly approves the content in this step.**
+
+Once the structure is approved, draft the **complete content** for every ticket and present it to the user for review. Show each ticket exactly as it will be created, including all fields:
+
+#### For each Epic, show:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+EPIC: [Title]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Type:        Epic
+Team:        [configured team]
+Parent:      [configured initiative key]
+Summary:     [epic title]
+Description:
+  📄 Product Spec: [Confluence URL]
+  📄 Tech Spec: [Confluence URL or N/A]
+
+  [Full epic description per Ticket Style guide]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+#### For each Story, show:
+
+```
+──────────────────────────────────────
+  STORY under [Epic Title]: [Story Title]
+──────────────────────────────────────
+  Type:        Story
+  Team:        [configured team]
+  Epic:        [parent epic title]
+  Summary:     [story title]
+  Description:
+    📄 Product Spec: [Confluence URL]
+    📄 Tech Spec: [Confluence URL or N/A]
+
+    [Full story description per Ticket Style guide]
+
+    Acceptance Criteria:
+    [Full acceptance criteria per Ticket Style guide]
+──────────────────────────────────────
+```
+
+#### For each Sub-Task (if Sub Tasks = yes), show:
+
+```
+  · SUB-TASK under [Story Title]: [Sub-task Title]
+    Type:        Sub-task
+    Team:        [configured team]
+    Parent:      [parent story title]
+    Summary:     [sub-task title]
+    Description: [sub-task details]
+```
+
+After presenting ALL ticket content, ask the user:
+
+> **"Here is the full content for all tickets I'm about to create. Please review and let me know:**
+> - **Approve** — create all tickets as shown
+> - **Edit** — tell me which tickets to change and what to modify
+> - **Cancel** — abort without creating anything"
+
+**Do NOT proceed to Step 6 until the user explicitly says to approve / go ahead / create.** If the user requests edits, make the changes, re-display the affected tickets, and ask for approval again. Repeat until approved.
+
+### Step 6 — Create Tickets in Jira
+
+**Only execute this step after the user has explicitly approved the ticket content in Step 5.**
+
+Use the Atlassian MCP connector to create the tickets. Follow this order:
+
+#### 6a. Create Epics
+
+For each epic, create it using the exact content approved in Step 5:
+
+- **Issue Type**: Epic
+- **Summary**: As approved
+- **Description**: As approved — Product Spec link at top, Tech Spec link if supplied, full description per Ticket Style
+- **Team**: Set the `customfield_10700` field to the **ID** of the configured Jira Team (mandatory)
+- **Parent**: Set via the standard `parent` field as an object — `"parent": { "key": "<INITIATIVE-KEY>" }` (the user-supplied initiative key)
+
+#### 6b. Create Stories
+
+For each story, create it using the exact content approved in Step 5:
+
+- **Issue Type**: Story
+- **Summary**: As approved
+- **Description**: As approved — Product Spec link at top, Tech Spec link if supplied, acceptance criteria and context per Ticket Style
+- **Team**: Same team as the epics, set via `customfield_10700` to the selected team's ID (mandatory)
+- **Parent**: Set via the standard `parent` field as an object — `"parent": { "key": "<EPIC-KEY>" }` (the epic created in step 6a)
+
+#### 6c. Create Sub-Tasks (only if Sub Tasks = yes)
+
+For each sub-task, create it using the exact content approved in Step 5:
+
+- **Issue Type**: Sub-task
+- **Summary**: As approved
+- **Description**: As approved
+- **Team**: Same team as the epics, set via `customfield_10700` to the selected team's ID (mandatory)
+- **Parent**: Set via the standard `parent` field as an object — `"parent": { "key": "<STORY-KEY>" }` (the parent story)
+
+### Step 7 — Report Results
+
+After all tickets are created, present a summary:
+
+1. A table of all created tickets with their keys, titles, types, and parent relationships
+2. Direct links to each ticket
+3. A link to the parent initiative showing the new epics
+4. Any tickets that failed to create, with error details
+
+---
+
+## Ticket Content Rules
+
+These rules apply to ALL tickets (epics, stories, and sub-tasks):
+
+1. **Jira Team field is mandatory.** Set it on every ticket (epic, story, sub-task) using the **ID** of the team the user selected (`OOF Mobile Solution Team` → `b3f517d4-c4f8-4144-8920-b762ec5a033b`, `OOF Application Solution Team` → `9817d9ca-6170-48e8-9e98-1aeb7c81daa5`) via `customfield_10700`.
+2. **Product Specification link** must appear at the top of every story description and every epic description. Format as a clickable Confluence link.
+3. **Technical Specification link** (if provided) must appear directly below the product spec link in every description.
+4. **All epics must be children of the parent initiative.** Use the Jira parent field, not just a link.
+5. **Follow the Ticket Style guide** for all content — titles, descriptions, acceptance criteria, and formatting.
+6. **Respect the Epic Number** constraint. If a max is set, do not exceed it. Consolidate related work into fewer epics if needed.
+
+---
+
+## Error Handling
+
+- If the Atlassian MCP connector is not connected, stop and ask the user to connect it.
+- If a Confluence page cannot be read, report the error and ask for a corrected URL.
+- If a ticket fails to create, log the error, continue with remaining tickets, and report all failures at the end.
+- If the selected team's ID is rejected by Jira, report this and confirm the user's team choice before retrying.
+- If the parent initiative key is invalid, report this and ask for correction.
+
+---
+
+## Tips for Best Results
+
+- Provide a detailed product specification — the more complete the spec, the better the epic/story breakdown.
+- Adding a technical specification helps generate more accurate implementation-focused stories.
+- Use the Epic Number parameter to control granularity — fewer epics means broader groupings, more means finer-grained.
+- Review the structure in Step 4 and the full ticket content in Step 5 carefully — nothing is created in Jira until you explicitly approve.

package/teams/fhr-ai-team/github/PULL_REQUEST_TEMPLATE/full.md

@@ -0,0 +1,31 @@
+## Summary
+
+<!-- What problem does this solve? Link the ticket (XO-XXXX / EB-XXXX) if there is one. Brief summary of the approach. -->
+
+## Scope
+
+<!-- What is included in this PR? Delete this section when the scope is self-evident from the title. -->
+
+## Behavior
+
+<!-- Describe the observable outcomes of this change, not the implementation details.
+What does the system do differently after this PR? State it in terms a reviewer can verify:
+  - Given X, the system now does Y (previously: Z)
+  - Config key `foo.bar` controls ... ; default is ...
+For design decisions, explain what was chosen and why the alternatives were rejected. -->
+
+## Wiring
+
+<!-- How is the new code connected to the rest of the system? Which callers, configs, or entry points are affected? Delete this section for self-contained changes. -->
+
+## Tests
+
+<!-- How was this tested? List test commands, key scenarios covered, or link CI results. -->
+
+## How to run
+
+<!-- Steps to run or test this locally, if applicable. Delete this section for changes that don't need manual verification. -->
+
+## Backward compatibility
+
+<!-- Does this change any public API, config key, data format, or pipeline interface? If yes, explain the migration path. If fully backward-compatible, write "No breaking changes". Delete this section for internal-only changes. -->

package/teams/fhr-ai-team/github/PULL_REQUEST_TEMPLATE/light.md

@@ -0,0 +1,7 @@
+## What changed
+
+<!-- One or two sentences: what changed and why. -->
+
+## Notes for reviewer
+
+<!-- Optional: anything non-obvious about the change, or "None". -->

package/teams/fhr-ai-team/github/copilot-instructions.md

@@ -0,0 +1,24 @@
+# Custom instructions for GitHub Copilot
+
+When performing a code review, please ensure the following:
+
+## Crownpeak AI Team Conventions
+- Search the codebase for existing utilities before creating new ones.
+- Check shared libraries: earlybirds_commons, torch_toolbox, item-toolbox, nlp-toolbox.
+- Use "item" not "product", "encodings" not "embeddings".
+- JSON/YAML config keys: camelCase.
+- Parquet columns: camelCase.
+- GCS paths: kebab-case.
+- Strategy IDs: kebab-case.
+- Docker images: kebab-case.
+- Parquet column labels: class-level attributes (_label pattern), not module-level constants.
+- Config classes: use standard suffixes (*Config, *ModelConfig, *BatchConfig, etc.).
+- No placeholders, no "TBD", no vague error handling.
+
+## Commit Messages - Use the following guidelines
+- Use the imperative mood in the subject line (e.g., "Fix bug" instead of "Fixed bug").
+- Start with a capital letter.
+- Do not end the subject line with a period.
+- Use the body to explain what and why vs. how.
+- Use bullet points for multiple changes if necessary.
+- Keep the subject line under 50 characters.

package/teams/fhr-ai-team/github/instructions/python.instructions.md

@@ -0,0 +1,23 @@
+---
+applyTo: "**/*.py"
+---
+
+# Python Coding Style
+
+- Use PEP 8 style guide for Python code.
+- Don't write docstrings for all public modules, classes, functions, and methods.
+- Use meaningful variable and function names.
+- Use snake_case for variable and function names.
+- Use CamelCase for class names.
+- Use type annotations for function parameters and return types.
+- Add '_opt' at the end of the function name for optional parameters and at the end of variable name for optional variables.
+- Use double quotes for string literals. Use single quotes for string literals only when the string contains double quotes.
+- Use triple quotes for multi-line strings. Use implicit string concatenation inside parentheses when joining shorter fragments across lines.
+- Use f-strings for string formatting. Avoid using the format() method or % operator for string formatting.
+- Use list comprehensions and generator expressions for creating lists and iterators. Avoid using map() and filter() functions.
+- Use `with open(...) as file_obj:` for file I/O operations. Avoid manual `close()` calls when a context manager can manage the file handle.
+- Use context managers for resource management when available. Avoid using `try/finally` for resource cleanup when a context manager can express the same behavior more clearly.
+- Use exceptions for error handling. Avoid using return codes for error handling.
+- Use pytest for functional testing. Avoid using other testing frameworks unless necessary.
+- If a dict key is used in several places, use a variable for the key name. Use a constant for the key name if it is used in several modules. The variable name should be in snake_case and start with an underscore.
+- Use single responsibility principle for SOLID code.

package/teams/fhr-ai-team/github/pull_request_template.md

@@ -0,0 +1,21 @@
+<!-- 
+  Pick a template:
+  - Small change (bug fix, config, dependency bump, typo): use light template
+    -> append ?template=light.md to the PR creation URL
+  - Feature, refactor, or architectural change: use full template
+    -> append ?template=full.md to the PR creation URL
+  
+  Or fill in the default below.
+-->
+
+## Why
+
+<!-- What problem does this solve? Link the ticket (XO-XXXX / EB-XXXX) if there is one. -->
+
+## What
+
+<!-- Describe the approach. For non-trivial changes, explain the design and key decisions. -->
+
+## Tests
+
+<!-- How was this tested? List test commands, key scenarios covered, or link CI results. -->

package/teams/fhr-ai-team/prompts/brainstorm.md

@@ -0,0 +1,7 @@
+---
+description: Brainstorm a new feature or design with codebase context. Discovers AI team repos, searches existing code, gathers requirements interactively.
+---
+
+Invoke the ai.pierre:brainstorming skill.
+
+$ARGUMENTS

package/teams/fhr-ai-team/prompts/plan-algo-tests.md

@@ -0,0 +1,7 @@
+---
+description: Plan and configure a test for an algo pipeline. Interactive 3-stage flow to select pipeline, gather config, and generate Kubeflow JSON.
+---
+
+Invoke the ai.pierre:algo-test-planning skill.
+
+$ARGUMENTS

package/teams/fhr-ai-team/prompts/plan.md

@@ -0,0 +1,7 @@
+---
+description: Plan an implementation with mandatory codebase search and code reuse. Produces TDD-based bite-sized tasks with exact file paths.
+---
+
+Invoke the ai.pierre:planning skill.
+
+Implement $ARGUMENTS. IMPORTANT: First search the codebase for existing utilities, scripts, and patterns that do similar things. Reuse them. Do not create new abstractions without showing me what already exists.

package/teams/fhr-ai-team/prompts/pr-description.md

@@ -0,0 +1,7 @@
+---
+description: Generating a PR description from the current branch diff
+---
+
+Invoke the ai.pierre:pr-description skill.
+
+Generate a PR description for the current branch. $ARGUMENTS

package/teams/fhr-ai-team/prompts/test.md

@@ -0,0 +1,7 @@
+---
+description: Run tests - local pytest, Kubeflow pipeline e2e, or MLflow model validation. Uses ml-tooling-dev for pipeline operations.
+---
+
+Invoke the ai.pierre:e2e-testing skill.
+
+$ARGUMENTS

package/teams/fhr-ai-team/resources/AGENTS.md

@@ -0,0 +1,55 @@
+# ai.pierre - Agent Instructions
+
+This file provides instructions for AI coding agents (OpenCode, Copilot, and others) working with Crownpeak AI team repositories.
+
+## Skills Available
+
+The `skills/` directory contains the following skills. Detect which skill applies based on the user's request and invoke it automatically.
+
+### Workflow Skills
+
+| Skill | Directory | Trigger |
+|-------|-----------|---------|
+| Brainstorming | `skills/brainstorming/` | User wants to design, explore, or brainstorm a feature |
+| Planning | `skills/planning/` | User wants to plan an implementation or break down tasks |
+| Algo Test Planning | `skills/algo-test-planning/` | User wants to test a Kubeflow pipeline |
+| E2E Testing | `skills/e2e-testing/` | User wants to run tests (local, pipeline, or model validation) |
+| Grill Me | `skills/grill-me/` | User wants to stress-test a plan or design through rigorous questioning |
+
+### Domain Skills
+
+| Skill | Directory | Trigger |
+|-------|-----------|---------|
+| ML Tooling Dev | `skills/ml-tooling-dev/` | User works with Kubeflow, MLflow, or MongoDB |
+| Naming Conventions | `skills/naming-conventions-reviewer/` | User writes or reviews code in any ML repo |
+
+## Automatic Skill Selection
+
+The user does **not** need to explicitly request skills. Determine the applicable skill from the user's natural language request:
+
+- "Design a feature" / "How should we approach..." -> brainstorming
+- "Break this down" / "Plan the implementation" -> planning
+- "Test the pipeline" / "Run a test for..." -> algo-test-planning or e2e-testing
+- "Check the Kubeflow run" / "Debug this job" -> ml-tooling-dev
+- "Grill me" / "Stress-test this plan" / "Challenge my design" -> grill-me
+- "Review this code" / "Is this name right?" -> naming-conventions-reviewer
+
+## Team Context
+
+### Repository Naming
+- `algo.*` - ML algorithm projects (training, inference, evaluation)
+- `algo.*-ml` - ML model training/fine-tuning (run on Kubeflow)
+- `ai.*` - AI-powered microservices (FastAPI, Streamlit)
+- `*-toolbox` - Shared Python libraries
+- `attraqt-kubeflow-*` - Kubeflow pipeline configs and definitions
+- `ebap-*` - Early Birds AI Platform infrastructure
+
+### Shared Libraries
+Before writing new utilities, check:
+- `earlybirds_commons`, `torch_toolbox`, `item-toolbox`, `nlp-toolbox`, `eb_tensorflow`
+
+### Core Rules
+1. Search the codebase for existing implementations before proposing new code
+2. Reuse shared library utilities; do not duplicate
+3. Follow naming conventions (see `skills/naming-conventions-reviewer/`)
+4. No placeholders, no "TBD", no vague instructions in plans or designs

package/teams/fhr-ai-team/resources/CLAUDE.md

@@ -0,0 +1,52 @@
+# ai.pierre - Crownpeak AI Team Engineering Skills
+
+This plugin provides engineering skills and slash commands for the Crownpeak AI team's ML development workflow.
+
+## Available Commands
+
+| Command | When to use |
+|---------|-------------|
+| `/brainstorm` | Designing a new feature, exploring architecture decisions, or evaluating approaches |
+| `/pr-description` | Generating a PR description from the current branch diff |
+| `/plan` | Breaking down an approved design into implementation tasks |
+| `/plan-algo-tests` | Configuring and planning a Kubeflow pipeline test run |
+| `/test` | Running local tests, launching pipeline e2e tests, or validating model outputs |
+
+## Auto-Routing Rules
+
+When working in any Crownpeak AI repo, apply these skills automatically:
+
+- **Writing or reviewing code** in any repo -> invoke `ai.pierre:naming-conventions-reviewer` to validate names
+- **Working with Kubeflow, MLflow, or MongoDB** -> invoke `ai.pierre:ml-tooling-dev` for operations and debugging
+- **Brainstorming or designing** -> invoke `ai.pierre:brainstorming` for codebase-aware design
+- **Planning implementation** -> invoke `ai.pierre:planning` for task breakdown
+- **Testing pipelines** -> invoke `ai.pierre:algo-test-planning` for config generation, `ai.pierre:e2e-testing` for execution
+- **Stress-testing a plan or design** -> invoke `ai.pierre:grill-me` to interrogate decisions branch by branch
+- **Creating a PR or asked to write a PR description** -> invoke `ai.pierre:pr-description` to generate from the diff
+
+## Team Repo Structure
+
+| Pattern | Purpose | Examples |
+|---------|---------|---------|
+| `algo.*` | ML algorithm projects | `algo.search`, `algo.clip`, `algo.tagging` |
+| `algo.*-ml` | ML training (Kubeflow) | `algo.search-ml`, `algo.clip-ml` |
+| `ai.*` | AI microservices | `ai.tagging-service`, `ai.guardrails-service` |
+| `*-toolbox` | Shared Python libraries | `pytorch-toolbox`, `nlp-toolbox`, `item-toolbox` |
+| `attraqt-kubeflow-*` | Kubeflow infra | `attraqt-kubeflow-configs`, `attraqt-kubeflow-pipelines` |
+| `ebap-*` | AI Platform infra | `ebap-argo-app`, `ebap-schema` |
+
+## Shared Libraries
+
+Always check these before writing new utilities:
+- `earlybirds_commons` - shared utilities and configurations
+- `torch_toolbox` - PyTorch model training/inference
+- `item-toolbox` - e-commerce item data utilities
+- `nlp-toolbox` - text tokenization and NLP
+- `eb_tensorflow` - TensorFlow model utilities
+
+## Non-Negotiable Principles
+
+1. **Search before creating.** Always search the codebase for existing implementations before proposing new code.
+2. **Reuse before writing.** If a utility exists in a shared library, use it.
+3. **Name correctly.** All names must follow the conventions enforced by `naming-conventions-reviewer`.
+4. **No placeholders.** Every plan, design, and implementation must be complete and precise.

package/teams/fhr-ai-team/resources/README.md

@@ -0,0 +1,51 @@
+# ai.agent-skills
+
+Engineering skills for Crownpeak AI team coding agents. Plugin name: **ai.pierre**.
+
+Provides codebase-aware brainstorming, implementation planning with mandatory code reuse, interactive Kubeflow pipeline test configuration, and cross-repo naming convention enforcement.
+
+**New to Claude Code?** Start with the [onboarding guide](docs/onboarding.md) after installing.
+
+## Quick Install
+
+| Tool | Command |
+|------|---------|
+| **Claude Code** | `/plugin install ai.pierre` ([setup guide](docs/claude-code-setup.md)) |
+| **OpenCode** | Clone repo, open in OpenCode ([setup guide](docs/opencode-setup.md)) |
+| **GitHub Copilot** | Copy skills to `.github/skills/` ([setup guide](docs/copilot-setup.md)) |
+
+## Commands
+
+| Command | Description |
+|---------|-------------|
+| `/brainstorm` | Codebase-aware brainstorming with dynamic AI team repo discovery via `gh` |
+| `/plan` | Implementation planning with mandatory codebase search and code reuse |
+| `/plan-algo-tests` | Interactive 3-stage flow: pipeline selection, config gathering, Kubeflow JSON generation |
+| `/test` | Local pytest, Kubeflow pipeline e2e testing, or MLflow model validation |
+
+## Skills
+
+| Skill | Description |
+|-------|-------------|
+| `brainstorming` | Design exploration with repo discovery, codebase search, interactive requirements gathering |
+| `planning` | TDD-based task breakdown with cross-repo dependency mapping |
+| `algo-test-planning` | Pipeline test config generation with 3-stage interactive flow |
+| `e2e-testing` | Local, pipeline, and model validation testing workflows |
+| `ml-tooling-dev` | Kubeflow, MLflow, and MongoDB dev environment management |
+| `grill-me` | Stress-test a plan or design through relentless questioning, resolving each branch of the decision tree |
+| `naming-conventions-reviewer` | Cross-repo naming convention enforcement for ML repositories |
+
+## Copilot Instructions
+
+A reference [`copilot-instructions.md`](.github/copilot-instructions.md) is included for GitHub Copilot code reviews. It covers Python coding style, Crownpeak AI team naming conventions, and commit message standards. Copy it into your project's `.github/` directory to enable Copilot-assisted reviews. See the [Copilot setup guide](docs/copilot-setup.md) for details.
+
+## Repository Structure
+
+```
+.claude/commands/    Slash commands (thin wrappers invoking skills)
+.github/             Reference copilot-instructions.md for code reviews
+skills/              Skill definitions with SKILL.md, references/, and scripts/
+docs/                Setup guides for Claude Code, OpenCode, and Copilot
+CLAUDE.md            Agent instructions for Claude Code
+AGENTS.md            Agent instructions for OpenCode and Copilot
+```