@groupby/ai-dev 0.2.1 → 0.3.0

package/toolsets/rzlv-flow/resources/confluence-file-structure.md

@@ -1,6 +1,6 @@
 # Confluence File Structure — Local Page Mirrors
 
-**Pattern:** Dual-mode local mirrors for Confluence pages
+**Pattern:** Leaf Bundle local mirrors for Confluence pages
 
 ---
 
@@ -15,6 +15,30 @@ Both modes follow the FCMP protocol for safe sync operations and preserve manual
 
 ---
 
+## Leaf Bundle Pattern
+
+Every Confluence page is stored as a **directory** containing an `index.md` file — never as a standalone `.md` file. This is called the Leaf Bundle pattern.
+
+### Why Folders, Not Files?
+
+- **Child pages** — A Confluence page can have child pages. The folder naturally represents this hierarchy; child pages become subdirectories.
+- **Assets** — Pages may include attachments, images, or diagrams. These are stored alongside `index.md` in the same folder.
+- **Hierarchy expansion** — New child pages can be added without restructuring. A flat file cannot grow into a parent.
+
+### DO NOT / DO
+
+```
+❌ DO NOT create flat files:
+docs/confluence/rezolve/ENG/strategic-context.md
+
+✅ DO create Leaf Bundle directories:
+docs/confluence/rezolve/ENG/strategic-context/index.md
+```
+
+This rule applies to **all** Confluence page mirrors, in both structured and flexible modes.
+
+---
+
 ## Base Path
 
 ```
@@ -37,27 +61,34 @@ docs/confluence/{instance}/{space}/
 └── {initiative-name}/
     ├── index.md                          # Initiative Overview
     └── {epic-name}/
-        ├── overview.md
-        ├── technical-architecture.md
-        ├── decisions.md
-        ├── strategic-context.md
-        ├── research-and-findings.md         # Created only if relevant content exists
-        ├── assumptions.md                   # Created only if relevant content exists
-        └── implementation-guidance.md
+        ├── overview/
+        │   └── index.md
+        ├── technical-architecture/
+        │   └── index.md
+        ├── decisions/
+        │   └── index.md
+        ├── strategic-context/
+        │   └── index.md
+        ├── research-and-findings/         # Created only if relevant content exists
+        │   └── index.md
+        ├── assumptions/                   # Created only if relevant content exists
+        │   └── index.md
+        └── implementation-guidance/
+            └── index.md
 ```
 
 ### Page Types
 
-| Page Type | Source | Description |
-|-----------|--------|-------------|
-| Initiative Overview (`index.md` at initiative root) | Initiative metadata | Top-level overview: goals, epic breakdown, navigation |
-| `overview.md` | Epic `_docs/` | High-level epic overview and goals |
-| `technical-architecture.md` | Epic `_docs/` | Architecture decisions and technical design |
-| `decisions.md` | Epic `_docs/` | Decision log and rationale |
-| `strategic-context.md` | Epic `_docs/` | Business context and strategic alignment |
-| `research-and-findings.md` | Epic `_docs/` | User research, discoveries, and clarifications* |
-| `assumptions.md` | Epic `_docs/` | Assumptions with confidence levels and validation status* |
-| `implementation-guidance.md` | Epic `_docs/` | High-value technical guides for development |
+| Page Type | Folder | Source | Description |
+|-----------|--------|--------|-------------|
+| Initiative Overview | `index.md` (at initiative root) | Initiative metadata | Top-level overview: goals, epic breakdown, navigation |
+| Overview | `overview/index.md` | Epic `_docs/` | High-level epic overview and goals |
+| Technical Architecture | `technical-architecture/index.md` | Epic `_docs/` | Architecture decisions and technical design |
+| Decisions | `decisions/index.md` | Epic `_docs/` | Decision log and rationale |
+| Strategic Context | `strategic-context/index.md` | Epic `_docs/` | Business context and strategic alignment |
+| Research & Findings | `research-and-findings/index.md` | Epic `_docs/` | User research, discoveries, and clarifications* |
+| Assumptions | `assumptions/index.md` | Epic `_docs/` | Assumptions with confidence levels and validation status* |
+| Implementation Guidance | `implementation-guidance/index.md` | Epic `_docs/` | High-value technical guides for development |
 
 \* Created only if the source material includes relevant content.
 
@@ -84,10 +115,11 @@ Used for ad-hoc documentation, user-specified locations, and non-epic-based cont
 ```
 docs/confluence/{instance}/{space}/
 └── {user-specified-path}/
-    └── {page-name}.md
+    └── {page-name}/
+        └── index.md
 ```
 
-No predefined structure — adapts to the user's needs.
+No predefined structure beyond the Leaf Bundle requirement — adapts to the user's needs.
 
 ### When to Use
 
@@ -141,15 +173,28 @@ Skills using flexible mode should ask:
 
 ---
 
+## Confluence Link Format
+
+When constructing Confluence URLs:
+
+- Replace spaces in page titles with `+`
+- Use the `/wiki/display/{SPACE}/{Title}` format for display links
+- Use the `/wiki/spaces/{SPACE}/pages/{pageId}` format for direct links
+
+Example: `https://company.atlassian.net/wiki/display/ENG/Technical+Architecture`
+
+---
+
 ## Page File Format
 
-Each local Confluence mirror file uses YAML frontmatter for sync metadata:
+Each local Confluence mirror file (`index.md` inside a Leaf Bundle directory) uses YAML frontmatter for sync metadata:
 
 ```yaml
 ---
 sync:
   confluence_page_id: "123456789"
   confluence_url: "https://company.atlassian.net/wiki/spaces/ENG/pages/123456789"
+  confluence_title: "Technical Architecture"
   space: "ENG"
   parent_page_id: "987654321"
   last_synced: "2025-12-11T10:30:00Z"
@@ -163,6 +208,9 @@ source:
   jira_ticket: "PROJ-120"
   doc_type: "technical-architecture"
   generated_from: "docs/jira/rezolve/PROJ/user-authentication/_docs/technical-architecture.md"
+  bmad_docs_referenced:
+    - "docs/jira/rezolve/PROJ/PROJ-120-user-auth/_docs/technical-architecture.md"
+  jira_initiative_key: "PROJ-100"
 
   # For flexible mode
   # origin: "manual"
@@ -174,6 +222,64 @@ source:
 Page content in markdown, converted to Confluence storage format during sync.
 ```
 
-See `sync-state-format.md` for full frontmatter schema details.
+### Frontmatter Field Reference
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `sync.confluence_page_id` | string | After first sync | Confluence page ID |
+| `sync.confluence_url` | string | After first sync | Full page URL |
+| `sync.confluence_title` | string | Yes | Exact title as it appears in Confluence (used for page lookups) |
+| `sync.space` | string | Yes | Confluence space key |
+| `sync.parent_page_id` | string | Yes | Parent page ID in Confluence |
+| `sync.last_synced` | ISO8601 | After first sync | Last sync timestamp |
+| `sync.version` | number | After first sync | Confluence page version for optimistic locking |
+| `sync.remote_updated` | ISO8601 | After first sync | Last remote change timestamp |
+| `mode` | enum | Yes | `structured` or `flexible` |
+| `source.jira_ticket` | string | Structured | Associated Jira ticket key |
+| `source.doc_type` | string | Structured | Page type (overview, technical-architecture, decisions, strategic-context) |
+| `source.generated_from` | string | Structured | Path to the `_docs/` source file |
+| `source.bmad_docs_referenced` | string[] | No | BMAD source docs used to generate the page (traceability) |
+| `source.jira_initiative_key` | string | No | Related Jira initiative key (cross-linking) |
+| `source.origin` | string | Flexible | Origin skill or `manual` |
+| `source.linked_jira` | string | Flexible | Optionally linked Jira ticket |
+
+> **Note on field naming:** The source rzlv-flow repo uses flat root-level fields (e.g. `confluence_space_key: "ENG"`). This toolset uses nested fields under `sync.*` for consistency with the Jira file schema. Both conventions represent the same data; skills should follow the nested format documented here.
+
+### Post-Sync Frontmatter Example
+
+**Before first sync (draft state):**
+```yaml
+---
+sync:
+  confluence_title: "Technical Architecture"
+  space: "ENG"
+  parent_page_id: "987654321"
+mode: "structured"
+source:
+  jira_ticket: "PROJ-120"
+  doc_type: "technical-architecture"
+  generated_from: "docs/jira/rezolve/PROJ/PROJ-120-user-auth/_docs/technical-architecture.md"
+---
+```
+
+**After first sync (populated by sync operation):**
+```yaml
+---
+sync:
+  confluence_page_id: "123456789"
+  confluence_url: "https://company.atlassian.net/wiki/spaces/ENG/pages/123456789"
+  confluence_title: "Technical Architecture"
+  space: "ENG"
+  parent_page_id: "987654321"
+  last_synced: "2025-12-11T10:30:00Z"
+  version: 1
+  remote_updated: "2025-12-11T10:30:00Z"
+mode: "structured"
+source:
+  jira_ticket: "PROJ-120"
+  doc_type: "technical-architecture"
+  generated_from: "docs/jira/rezolve/PROJ/PROJ-120-user-auth/_docs/technical-architecture.md"
+---
+```
 
-<!-- TODO: Pull additional detail from full rzlv-flow repo for Leaf Bundle pattern specifics and doc-type-mapping rules if available -->
+See `sync-state-format.md` for the full frontmatter schema and worked examples.

package/toolsets/rzlv-flow/resources/sync-state-format.md

@@ -113,6 +113,7 @@ Confluence mirror files use this frontmatter:
 sync:
   confluence_page_id: "123456789"          # Confluence page ID
   confluence_url: "https://..."            # Full page URL
+  confluence_title: "Page Title"           # Exact title as it appears in Confluence
   space: "ENG"                             # Confluence space key
   parent_page_id: "987654321"              # Parent page ID in Confluence
   last_synced: "2025-12-11T10:30:00Z"      # Last sync timestamp
@@ -126,6 +127,9 @@ source:
   jira_ticket: "PROJ-120"                  # Associated Jira ticket (optional)
   doc_type: "technical-architecture"       # overview | technical | decisions | strategic
   generated_from: "docs/jira/.../technical-architecture.md"  # Source _docs/ file
+  bmad_docs_referenced:                    # BMAD source docs used (traceability)
+    - "docs/jira/.../technical-architecture.md"
+  jira_initiative_key: "PROJ-100"          # Related Jira initiative (cross-linking)
 
   # Flexible mode fields (use instead of structured fields)
   # origin: "manual"                       # manual | context-analyst | other skill
@@ -207,3 +211,108 @@ Build a REST API endpoint for user authentication that accepts username/password
 - Uses existing `UserService` for credential validation
 - Token signing key stored in environment variables
 ```
+
+---
+
+## Complete Example: Synced Confluence Page (Structured Mode)
+
+This example shows a Confluence page mirror created via the `atlassian-orchestrator` skill from an epic's `_docs/` folder. The file lives at:
+
+```
+docs/confluence/rezolve/ENG/platform-initiative/user-authentication/technical-architecture/index.md
+```
+
+Note the **Leaf Bundle** pattern: the page is a directory (`technical-architecture/`) containing `index.md`, not a flat `.md` file. See `confluence-file-structure.md` for details.
+
+```yaml
+---
+sync:
+  confluence_page_id: "456789012"
+  confluence_url: "https://rezolve.atlassian.net/wiki/spaces/ENG/pages/456789012"
+  confluence_title: "Technical Architecture — User Authentication"
+  space: "ENG"
+  parent_page_id: "456789000"
+  last_synced: "2025-12-11T10:30:00Z"
+  version: 3
+  remote_updated: "2025-12-11T09:15:00Z"
+
+mode: "structured"
+
+source:
+  jira_ticket: "AIP-200"
+  doc_type: "technical-architecture"
+  generated_from: "docs/jira/rezolve/AIP/AIP-200-user-authentication/_docs/technical-architecture.md"
+  bmad_docs_referenced:
+    - "docs/jira/rezolve/AIP/AIP-200-user-authentication/_docs/technical-architecture.md"
+  jira_initiative_key: "AIP-100"
+
+orchestrator:
+  generated_at: "2025-12-08T14:00:00Z"
+  auto_sync: true
+---
+
+# Technical Architecture — User Authentication
+
+## Overview
+
+REST API authentication using JWT tokens with bcrypt password hashing and Redis-backed rate limiting.
+
+## Authentication Flow
+
+1. Client sends POST `/api/auth/login` with credentials
+2. Server validates against UserService
+3. On success: sign JWT with RS256, return token + expiry
+4. On failure: increment rate limiter, return 401
+
+## Technology Decisions
+
+- **JWT signing:** RS256 with rotating keys (see decisions.md)
+- **Rate limiting:** Redis sliding window, 5 req/min/IP
+- **Password storage:** bcrypt with cost factor 12
+```
+
+---
+
+## Complete Example: Synced Confluence Page (Flexible Mode)
+
+This example shows an ad-hoc page published to Confluence by a developer using the `confluence-publish` skill. The file lives at:
+
+```
+docs/confluence/rezolve/ENG/team-guides/onboarding-guide/index.md
+```
+
+```yaml
+---
+sync:
+  confluence_page_id: "789012345"
+  confluence_url: "https://rezolve.atlassian.net/wiki/spaces/ENG/pages/789012345"
+  confluence_title: "Developer Onboarding Guide"
+  space: "ENG"
+  parent_page_id: "789012000"
+  last_synced: "2025-12-12T14:00:00Z"
+  version: 1
+  remote_updated: "2025-12-12T14:00:00Z"
+
+mode: "flexible"
+
+source:
+  origin: "manual"
+  linked_jira: "AIP-300"
+---
+
+# Developer Onboarding Guide
+
+Welcome to the team! This guide covers local setup, tooling, and key workflows.
+
+## Local Setup
+
+1. Clone the monorepo
+2. Run `npm install` in the root
+3. Copy `.env.example` to `.env` and fill in values
+
+## Key Workflows
+
+- **Daily triage:** Use `jira-daily-triage` to start your day
+- **Ticket focus:** Use `jira-ticket-focus` to deep-load a ticket
+- **Wrap up:** Use `jira-wrap-sync` when finishing work
+```

package/toolsets/rzlv-flow/skills/jira-daily-triage/SKILL.md

@@ -40,9 +40,9 @@ Before executing, read these resource files for protocol and structure guidance:
   ```
   JQL: project = {PROJECT} AND sprint in openSprints()
   ```
-- Extract the sprint name and ID from the results.
-- If no open sprint is found, inform the user and continue without a sprint filter.
-- Store the active sprint name and ID for the session.
+- Extract the sprint name, ID, end date, and days remaining from the results.
+- If no open sprint is found, display: "No active sprint detected — Backlog mode" and continue without a sprint filter. In Backlog mode, skip sprint-scoped queries and show only the user's assigned tickets ordered by priority.
+- Store the active sprint name, ID, end date, and days remaining for the session.
 
 > **Note:** Sprint data may be stored in custom fields whose names vary by Jira instance. When using MCP to query sprint tickets, inspect the returned fields for sprint information (name, start/end dates, goal). If sprint details are missing from the default field set, request additional fields or use `'*all'` to retrieve all fields.
 
@@ -90,7 +90,12 @@ Present results using this structure:
 
 ```
 ## 🌅 Your Day — {date}
-**Project:** {PROJECT} | **Sprint:** {Sprint Name} ({X}/{Y} tickets complete)
+**Project:** {PROJECT} | **Sprint:** {Sprint Name} | **Ends:** {end_date} ({days_left} days left)
+**Sprint Progress:** {X}/{Y} tickets complete
+
+{IF NO SPRINT:}
+## 🌅 Your Day — {date}
+**Project:** {PROJECT} | **No active sprint detected — Backlog mode**
 
 ### 🔥 In Progress (Complete These First)
 | # | Ticket | Summary | Points | Days Active |
@@ -114,7 +119,10 @@ Present results using this structure:
 | 5 | PROJ-130 | Performance fix | 5 | Critical |
 
 ### ⚠️ Blockers & Flags
-- PROJ-120: Waiting on design review (3 days)
+- {TICKET-KEY}: {blocker description} ({n} days)
+- {TICKET-KEY}: {blocker description} ({n} days)
+{IF NO BLOCKERS:}
+✓ No blockers detected
 
 **Recommended Focus:** #1 PROJ-123 (continue in-progress work) or #2 PROJ-124 (fresh start)
 

package/toolsets/rzlv-flow/skills/jira-sprint-status/SKILL.md

@@ -30,7 +30,7 @@ Use MCP to find the active sprint:
 JQL: project = {PROJECT} AND sprint in openSprints()
 ```
 
-Extract the sprint name and ID. If no open sprint is found, inform the user and offer to report on a specific sprint or the full backlog.
+Extract the sprint name, ID, start date, end date, and sprint goal (if set). If no open sprint is found, inform the user and offer to report on a specific sprint or the full backlog.
 
 > **Note:** Sprint data may be stored in custom fields whose names vary by Jira instance. When using MCP to query sprint tickets, inspect the returned fields for sprint information (name, start/end dates, goal). If sprint details are missing from the default field set, request additional fields or use `'*all'` to retrieve all fields.
 
@@ -59,6 +59,16 @@ Calculate:
 - Overall completion percentage (done points / total points, or done count / total count)
 - Sprint velocity so far (points completed)
 
+### Step 4b: Calculate Velocity and Forecast
+
+Using the sprint start date, end date, and points completed so far:
+
+- **Days elapsed** — business days since sprint start
+- **Days remaining** — business days until sprint end
+- **Ideal velocity** — total points / total sprint days (points/day to finish on time)
+- **Actual velocity** — done points / days elapsed
+- **Forecast** — at current velocity, project whether the sprint will finish on time, ahead, or behind. If behind, estimate the shortfall: "May miss by {n} points"
+
 ### Step 5: Identify Risks
 
 Flag potential risks:
@@ -81,6 +91,11 @@ Filter tickets assigned to the current user:
 ```
 ## 📊 Sprint Status: {Sprint Name}
 **Project:** {PROJECT} | **Sprint:** {Sprint Name}
+**Ends:** {end_date} ({days_left} days left)
+{IF SPRINT GOAL SET:}
+**Goal:** {Sprint Goal}
+
+████████████░░░░░░░░ {percent}% Complete
 
 ### Progress
 | Status | Tickets | Story Points |
@@ -92,6 +107,11 @@ Filter tickets assigned to the current user:
 
 **Completion:** {percent}% by points ({done_pts}/{total_pts})
 
+### Velocity & Forecast
+- **Ideal:** {n} points/day
+- **Actual:** {n} points/day
+- **Forecast:** {On track | Ahead by {n} points | May miss by {n} points}
+
 ### Ticket Breakdown
 | # | Ticket | Summary | Status | Assignee | Points |
 |---|--------|---------|--------|----------|--------|
@@ -113,4 +133,11 @@ Filter tickets assigned to the current user:
 - **Completed:** {n} tickets ({pts} pts)
 - **In Progress:** {n} tickets ({pts} pts)
 - **Assigned (To Do):** {n} tickets ({pts} pts)
+
+---
+**Quick Actions:**
+1. View at-risk tickets in detail
+2. Focus on blocked items
+3. Generate standup update (summary for copy/paste)
+4. Export sprint data as markdown table
 ```

package/toolsets/rzlv-flow/skills/jira-ticket-focus/SKILL.md

@@ -25,7 +25,10 @@ Before executing, read these resource files — they are critical for correct be
 - If the user provides a **number** (e.g. "3"), look it up from the `numbered_ticket_list` stored in conversational context from a prior `jira-daily-triage` run.
 - If the user provides a **Jira key** (e.g. "PROJ-123"), use it directly.
 - If the key is **incomplete** (e.g. "123"), prepend the `confirmed_project` key from session context (e.g. "PROJ-123").
-- If neither a number mapping nor a project key is available, ask the user for the full ticket key.
+- If neither a number mapping nor a project key is available, attempt fallback detection:
+  1. **Git branch:** Check the current branch name for a `{PROJECT}-{n}` pattern (e.g. `feature/PROJ-123` → project is `PROJ`).
+  2. **Config file:** Check for a `.jira.json` file in the project root containing `{ "project": "PROJ", "instance": "rezolve" }`.
+  3. If neither yields a project key, ask the user for the full ticket key.
 
 ### Step 2: Fetch Ticket Details (FCMP Fetch Step)
 
@@ -35,6 +38,8 @@ Use `mcp_atlassian-rovo_fetch()` to retrieve:
 - Comments and recent history
 - Sprint information (use `active_sprint_name` from session context if available)
 - Linked Confluence documents (if any)
+- **Subtasks** — fetch all subtasks of the ticket via JQL: `parent = {TICKET-KEY} ORDER BY status ASC, priority DESC`
+- **Linked issues** — fetch linked issues (blocks, is blocked by, relates to)
 
 **Parent Epic detection** — check in this order:
 

package/toolsets/rzlv-flow/skills/jira-wrap-sync/SKILL.md

@@ -40,12 +40,23 @@ Before executing, read these resource files:
 - Map code changes to acceptance criteria where possible.
 - Summarize: files changed, insertions, deletions.
 
+**c) Acceptance criteria progress:**
+- Read the AC list from the ticket file.
+- Based on code changes and commit messages, infer which AC items have been completed.
+- Show checkbox progress:
+  ```
+  - [x] AC 1 — Completed (matches changes in auth-controller.ts)
+  - [x] AC 2 — Completed (matches changes in rate-limiter.ts)
+  - [ ] AC 3 — Not yet addressed
+  ```
+- Note: this is a best-effort inference. The user confirms the final state.
+
 ### Step 3: Draft Jira Comment
 
-Build a comprehensive comment covering both ticket updates and code progress:
+Build a comprehensive comment with the standardized prefix `[rzlv-flow Update]`:
 
 ```
-**Work Update:**
+[rzlv-flow Update]
 
 {IF TICKET FIELD CHANGES:}
 **Ticket Updates:**
@@ -61,22 +72,44 @@ Build a comprehensive comment covering both ticket updates and code progress:
 - {file1}: {brief description}
 - {file2}: {brief description}
 
-**AC Completed:** {X}/{Y}
-**Remaining:** {what's left}
+**Acceptance Criteria:**
+- [x] {completed AC 1}
+- [x] {completed AC 2}
+- [ ] {remaining AC 3}
+**Progress:** {X}/{Y} completed
 
 **Next Steps:** {suggested next action}
+
+Context: {optional PR link or Confluence doc link}
 ```
 
-### Step 4: FCMP Protocol (Before Any Sync)
+### Step 4: FCMP Preview (Prepare PUSH — Dry Run)
 
-Before executing any write operations, run the full FCMP cycle:
+Before executing any write operations, run the full FCMP cycle and present a dry-run preview:
 
 1. **FETCH** — Get the current ticket state from Jira via MCP.
 2. **COMPARE** — Check for remote changes since last sync (compare `sync.version` and `sync.remote_updated`).
 3. **MERGE** — If conflicts detected, show a diff of remote changes vs local changes and resolve with the user.
-4. Show the diff to the user and warn if conflicts exist.
+4. **Preview** — Show a dry-run diff of what will change if the user proceeds:
+
+```
+### FCMP Preview (Dry Run)
+{IF NO REMOTE CHANGES:}
+✓ Remote is unchanged since last sync — safe to push.
+
+{IF REMOTE CHANGES DETECTED:}
+⚠️ Remote changes detected since last sync:
+- {field}: {old_value} → {new_value}
+
+**Proposed local → remote changes:**
+- Description: {diff summary}
+- Story Points: {old} → {new}
+- Status: {current} (no change)
+
+Proceed with sync? (y/n)
+```
 
-Only proceed to the action menu after the FCMP cycle completes.
+Only proceed to the action menu after the FCMP preview is confirmed.
 
 ### Step 5: Present Multi-Select Action Menu
 

package/skills/skills/README.md

@@ -1,61 +0,0 @@
-# Skills
-
-This folder manages all skills, archived skills, and examples/instructions on using them.
-
-All skills in this `skills/library/` should represent _generally useful skills_ that might be used across teams.
-
-If any particular skill goes missing, note that it may have simply been archived (see [the archive](skills/archived/)) and may no longer be recommended for use. Ideally skills are not simply deleted from this repository, since others may be expecting them to be there.
-
-## Usage
-
-When developing a project, it is generally recommended to commit any skills you use to that codebase so that others may use them as well. Skills are stored as folders and can include many files, but need to include at least a SKILL.md file. Normal locations are:
-
-* **Claude Code**: `.claude/skills/<skill-name>/`
-* **Copilot**: `.github/skills/<skill-name>/`
-* **Codex**: `.agents/skills/<skill-name>/`
-  * Codex allows for storing skills in [many places](https://developers.openai.com/codex/skills#where-to-save-skills), including outside the repo.
-
-Note that each folder must contain a SKILL.md file, and may optionally contain other arbitrary files:
-* Other markdown files that describe processes
-* Script files that allow for deterministic coding
-* ...plus other resources required by either
-
-All of the above should be referenced directly by their SKILL.md file, with an explanation on when to read or use them.
-
-## Recommended usage
-
-However, to allow everyone to use skills regardless of their LLM client of choice, it can be valuable to do the following:
-
-* Store the skill folder in a place like `docs/ai/skills/<skill-name>/`
-* Reference the skill in the folder for each relevant client.
-
-For example:
-
-In `docs/ai/skills/frontend-design/SKILL.md`:
-
-```
----
-name: frontend-design
-description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
----
-
-This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
-
-The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
-
-...
-```
-
-Then, in `.github/skills/frontend-design/SKILL.md` (and anywhere else needed):
-
-```
----
-name: frontend-design
-description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
-license: Complete terms in LICENSE.txt
----
-
-See `docs/ai/skills/frontend-design/SKILL.md` and follow closely.
-```
-
-Note that we MUST include the skill boilerplate in any official skills location (eg. `.github/skills/`, etc.) to enable discovery and usage. We then copy the entire skill into `docs/ai/skills/` to leave it intact, though we don't technically need the boilerplate.

package/skills/skills/archived/README.md

@@ -1,3 +0,0 @@
-# Skills archive
-
-Any deprecated/archived skills should be moved here for discoverability purposes.

package/skills/skills/library/README.md

@@ -1,3 +0,0 @@
-# Skills library
-
-This folder contains skill folders that can be easily copied into project repos.