aiblueprint-cli 1.4.103 → 1.4.105

package/agents-config/skills/commit/agents/openai.yaml

@@ -1,10 +0,0 @@
-interface:
-  display_name: "Commit"
-  short_description: "Quick commit and push with minimal, clean messages"
-  icon_small: "./assets/codex-icon.svg"
-  icon_large: "./assets/codex-icon.svg"
-  brand_color: "#4BD0FC"
-  default_prompt: "Use $commit to help with this task."
-
-policy:
-  allow_implicit_invocation: false

package/agents-config/skills/commit/assets/codex-icon.svg

@@ -1,17 +0,0 @@
-<!-- @license lucide-static v1.24.0 - ISC -->
-<svg role="img" aria-label="commit skill icon"
-  class="lucide lucide-git-commit-horizontal"
-  xmlns="http://www.w3.org/2000/svg"
-  width="128"
-  height="128"
-  viewBox="0 0 24 24"
-  fill="none"
-  stroke="#F5F5F5"
-  stroke-width="2"
-  stroke-linecap="round"
-  stroke-linejoin="round"
->
-  <circle cx="12" cy="12" r="3" />
-  <line x1="3" x2="9" y1="12" y2="12" />
-  <line x1="15" x2="21" y1="12" y2="12" />
-</svg>

package/agents-config/skills/create-pr/SKILL.md

@@ -1,55 +0,0 @@
----
-name: create-pr
-description: Create and push PR with auto-generated title and description
-model: haiku
-allowed-tools: Bash(git :*), Bash(gh :*)
-disable-model-invocation: true
-allow_implicit_invocation: false
----
-
-# Create PR
-
-Create pull request with concise, meaningful description.
-
-## Context
-
-- Current branch: !`git branch --show-current`
-- Working tree status: !`git status --short`
-- Recent commits: !`git log --oneline -5`
-- Remote tracking: !`git rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo "none"`
-
-## Workflow
-
-1. **Verify**: Check `git status` and current branch
-2. **Branch Safety**: **CRITICAL** - If on main/master, create descriptive branch from changes
-3. **Push**: `git push -u origin HEAD`
-4. **Analyze**: `git diff origin/main...HEAD --stat`
-5. **Generate PR**:
-   - Title: One-line summary (max 72 chars)
-   - Body: Bullet points of key changes
-6. **Submit**: `gh pr create --title "..." --body "..."`
-7. **Return**: Display PR URL
-
-## PR Format
-
-```markdown
-## Summary
-
-• [Main change or feature]
-• [Secondary changes]
-• [Any fixes included]
-
-## Type
-
-[feat/fix/refactor/docs/chore]
-```
-
-## Rules
-
-- NO verbose descriptions
-- NO "Generated with" signatures
-- Auto-detect base branch (main/master/develop)
-- Use HEREDOC for multi-line body
-- If PR exists, return existing URL
-
-User: $ARGUMENTS

package/agents-config/skills/create-pr/agents/openai.yaml

@@ -1,10 +0,0 @@
-interface:
-  display_name: "Create Pr"
-  short_description: "Create and push PR with auto-generated title and description"
-  icon_small: "./assets/codex-icon.svg"
-  icon_large: "./assets/codex-icon.svg"
-  brand_color: "#951556"
-  default_prompt: "Use $create-pr to help with this task."
-
-policy:
-  allow_implicit_invocation: false

package/agents-config/skills/create-pr/assets/codex-icon.svg

@@ -1,17 +0,0 @@
-<!-- @license lucide-static v1.24.0 - ISC -->
-<svg role="img" aria-label="create-pr skill icon"
-  class="lucide lucide-git-merge"
-  xmlns="http://www.w3.org/2000/svg"
-  width="128"
-  height="128"
-  viewBox="0 0 24 24"
-  fill="none"
-  stroke="#F5F5F5"
-  stroke-width="2"
-  stroke-linecap="round"
-  stroke-linejoin="round"
->
-  <circle cx="18" cy="18" r="3" />
-  <circle cx="6" cy="6" r="3" />
-  <path d="M6 21V9a9 9 0 0 0 9 9" />
-</svg>

package/agents-config/skills/oneshot/SKILL.md

@@ -1,44 +0,0 @@
----
-name: oneshot
-description: Implement one focused code change quickly with minimal exploration and targeted validation. Use for small bug fixes, single feature edits, config updates, or explicit "$oneshot" requests.
-disable-model-invocation: true
-metadata:
-  opencode/autoinvoke: "false"
-  opencode/slash: "true"
-argument-hint: <feature-description>
----
-
-# OneShot
-
-Use this for one narrow implementation task. Optimize for the shortest reliable path to a working, verified change.
-
-## Workflow
-
-### 1. Scope
-
-- Identify the exact target and likely files with `rg` / `rg --files`.
-- Read only the files needed to edit safely, usually 2-5 plus nearby examples.
-- Look up docs only when API, version, or current behavior may be stale.
-
-### 2. Implement
-
-- Edit as soon as the existing pattern is clear.
-- Keep the diff minimal and local to the request.
-- Do not refactor, rename, redesign, rewrite docs, or clean adjacent code unless required.
-- Prefer existing helpers, conventions, and package scripts.
-
-### 3. Validate
-
-- Run the smallest meaningful checks: targeted tests, touched-package lint/typecheck, and formatter when expected.
-- If a check fails, fix only failures caused by this change and rerun.
-- Run broader checks only for shared/high-risk code or when the user asks.
-
-## Stop Rules
-
-- Do not expand into adjacent improvements.
-- Ask only when a missing decision blocks safe implementation.
-- If blocked after two concrete attempts, report the blocker, evidence, and the next exact option.
-
-## Final Response
-
-Report changed files, validation commands/results, and any skipped checks with reason.

package/agents-config/skills/oneshot/agents/openai.yaml

@@ -1,10 +0,0 @@
-interface:
-  display_name: "Oneshot"
-  short_description: "Implement one focused code change quickly with minimal..."
-  icon_small: "./assets/codex-icon.svg"
-  icon_large: "./assets/codex-icon.svg"
-  brand_color: "#CF80EF"
-  default_prompt: "Use $oneshot to help with this task."
-
-policy:
-  allow_implicit_invocation: false

package/agents-config/skills/oneshot/assets/codex-icon.svg

@@ -1,18 +0,0 @@
-<!-- @license lucide-static v1.24.0 - ISC -->
-<svg role="img" aria-label="oneshot skill icon"
-  class="lucide lucide-sparkles"
-  xmlns="http://www.w3.org/2000/svg"
-  width="128"
-  height="128"
-  viewBox="0 0 24 24"
-  fill="none"
-  stroke="#F5F5F5"
-  stroke-width="2"
-  stroke-linecap="round"
-  stroke-linejoin="round"
->
-  <path d="M11.017 2.814a1 1 0 0 1 1.966 0l1.051 5.558a2 2 0 0 0 1.594 1.594l5.558 1.051a1 1 0 0 1 0 1.966l-5.558 1.051a2 2 0 0 0-1.594 1.594l-1.051 5.558a1 1 0 0 1-1.966 0l-1.051-5.558a2 2 0 0 0-1.594-1.594l-5.558-1.051a1 1 0 0 1 0-1.966l5.558-1.051a2 2 0 0 0 1.594-1.594z" />
-  <path d="M20 2v4" />
-  <path d="M22 4h-4" />
-  <circle cx="4" cy="20" r="2" />
-</svg>

package/agents-config/skills/tools/SKILL.md

@@ -1,149 +0,0 @@
----
-name: tools
-description: Reference document listing all recommended tools and libraries for AIBlueprint development
----
-
-# AIBlueprint Tools & Libraries Reference
-
-This document lists all recommended tools and libraries for development with the AIBlueprint stack. Use this as a reference when making architecture decisions.
-
-## Quick Reference Table
-
-| Name | Description | Tags |
-|------|-------------|------|
-| [Next.js](https://nextjs.org/) | Main React framework with App Router | `framework`, `frontend`, `backend` |
-| [TanStack Query](https://tanstack.com/query) | Data fetching & caching for API routes | `frontend`, `library` |
-| [Zustand](https://zustand.docs.pmnd.rs/) | Client-side state management | `frontend`, `library` |
-| [nuqs](https://nuqs.47ng.com/) | URL state management | `frontend`, `library` |
-| [shadcn/ui](https://ui.shadcn.com/) | Customizable React components | `frontend`, `library` |
-| [Convex](https://www.convex.dev/) | Realtime database & backend | `backend`, `database`, `realtime` |
-| [Liveblocks](https://liveblocks.io/) | Multiplayer collaboration features | `frontend`, `backend`, `realtime` |
-| [Neon](https://neon.tech/) | Serverless PostgreSQL | `backend`, `database`, `sql` |
-| [Supabase](https://supabase.com/) | PostgreSQL + Backend as a Service | `backend`, `database`, `sql` |
-| [Prisma](https://prisma.io/) | Type-safe ORM (recommended for teams) | `backend`, `database`, `orm` |
-| [Drizzle ORM](https://orm.drizzle.team/) | Lightweight type-safe ORM | `backend`, `database`, `orm` |
-| [Better Auth](https://www.better-auth.com/) | Complete authentication solution | `backend`, `library` |
-| [Inngest](https://www.inngest.com/) | Background jobs & workflows | `backend`, `service` |
-| [Next Safe Action](https://next-safe-action.dev/) | Secure Server Actions | `backend`, `library` |
-| [next-zod-route](https://github.com/Melvynx/next-zod-route) | Secure API Routes | `backend`, `library` |
-| [Zod](https://zod.dev/) | Runtime validation (v4) | `library`, `validation` |
-| [AI SDK](https://ai-sdk.dev/) | LLM integration wrapper | `backend`, `frontend`, `library` |
-| [up-fetch](https://github.com/L-Blondy/up-fetch) | Modern fetch wrapper | `backend`, `frontend`, `library` |
-| [Vitest](https://vitest.dev/) | Fast unit testing | `testing`, `library` |
-| [Playwright](https://playwright.dev/) | E2E testing | `testing`, `library` |
-| [Sentry](https://sentry.io/) | Error tracking & monitoring | `monitoring`, `service` |
-| [Resend](https://resend.com/) | Developer email service | `email`, `service` |
-| [React Email](https://react.email/) | Email templates in React | `email`, `library` |
-| [AWS SES](https://aws.amazon.com/ses/) | High-volume email | `email`, `service` |
-| [Stripe](https://stripe.com/) | Complete payment solution | `payment`, `service` |
-| [Lemon Squeezy](https://lemonsqueezy.com/) | Payments with tax handling | `payment`, `service` |
-| [PostHog](https://posthog.com/) | Product analytics | `analytics`, `service` |
-| [Plausible](https://plausible.io/) | Simple web analytics | `analytics`, `service` |
-| [React Hook Form](https://react-hook-form.com/) | Form management (recommended) | `frontend`, `library`, `forms` |
-| [TanStack Form](https://tanstack.com/form) | Headless form management | `frontend`, `library`, `forms` |
-| [Uploadthing](https://uploadthing.com/) | Simple file uploads | `upload`, `images`, `service` |
-| [Cloudflare R2](https://developers.cloudflare.com/r2/) | S3-compatible storage | `backend`, `images`, `storage` |
-| [AWS S3](https://aws.amazon.com/s3/) | Object storage standard | `storage`, `images`, `infra` |
-
-## Categories
-
-### Framework & Frontend
-- **Next.js** - Main framework
-- **TanStack Query** - Data fetching & cache
-- **Zustand** - Client state management
-- **nuqs** - URL state
-- **shadcn/ui** - UI components
-
-### Backend & API
-- **Next Safe Action** - Secure Server Actions
-- **next-zod-route** - Secure API Routes
-- **Better Auth** - Authentication
-- **AI SDK** - LLM integration
-- **up-fetch** - HTTP client
-
-### Database & ORM
-- **Neon** - Serverless PostgreSQL (recommended)
-- **Supabase** - PostgreSQL + BaaS
-- **Prisma** - Type-safe ORM (recommended for teams)
-- **Drizzle ORM** - Lightweight ORM (recommended for performance)
-
-### Realtime & Collaboration
-- **Convex** - Realtime database + backend (recommended for realtime apps)
-- **Liveblocks** - Multiplayer collaboration (cursors, presence, comments)
-
-### Validation & Forms
-- **Zod** - Data validation (v4)
-- **React Hook Form** - Form management (recommended)
-- **TanStack Form** - Modern alternative
-
-### Testing
-- **Vitest** - Unit tests
-- **Playwright** - E2E tests
-
-### Monitoring & Analytics
-- **Sentry** - Error tracking & performance
-- **PostHog** - Product analytics (recommended)
-- **Plausible** - Simple web analytics
-
-### Payments
-- **Stripe** - Complete solution (recommended for flexibility)
-- **Lemon Squeezy** - Simple + handles taxes (recommended for solopreneurs)
-
-### Email
-- **Resend** - Transactional emails (recommended)
-- **React Email** - Email templates in React
-- **AWS SES** - High volume
-
-### Images & Upload
-- **Uploadthing** - Simple Next.js uploads (recommended)
-- **Cloudflare R2** - Cheap object storage
-- **AWS S3** - Standard object storage
-
-### Services & Infrastructure
-- **Inngest** - Async jobs & workflows
-- **Cloudflare Browser Rendering** - Serverless scraping
-
-## Recommended Stack
-
-### Frontend
-- Next.js + TanStack Query + Zustand + shadcn/ui
-- React Hook Form + Zod
-
-### Backend
-- Neon (DB) + Prisma or Drizzle (ORM)
-- Next Safe Action + Better Auth
-- Resend + React Email
-
-### Services
-- Stripe (payments)
-- Uploadthing (upload)
-- Cloudflare R2 (storage)
-- PostHog (analytics)
-- Sentry (monitoring)
-
-### Testing
-- Vitest + Playwright
-
-## Decision Guide
-
-| Decision | Recommendation |
-|----------|----------------|
-| Database | Neon + Prisma to start, Drizzle for performance |
-| Realtime | Convex for full realtime, Liveblocks for collaboration only |
-| Email | Resend to start, AWS SES for >100k/month |
-| Payments | Stripe for flexibility, Lemon Squeezy for tax simplicity |
-| Analytics | PostHog for product analytics, Plausible for simple web analytics |
-| Forms | React Hook Form (standard), TanStack Form (more control) |
-| ORM | Prisma (better DX), Drizzle (better perf, 2-3x faster) |
-| Upload | Uploadthing (simple), R2/S3 (more control) |
-| Testing | Vitest (unit), Playwright (E2E, more reliable than Cypress) |
-
-## Important Notes
-
-- **Zod**: Now v4, specify version to AI
-- **Supabase Auth**: Prefer Better-Auth for flexibility
-- **Convex vs Neon+Liveblocks**: Convex if entire app is realtime, Neon+Liveblocks if only some features need collaboration
-- **AWS S3**: Watch egress costs, prefer R2 for serving assets
-- **Stripe Tax**: Enable for automatic tax handling
-- **Sentry**: Configure source maps for real stack traces
-- **Prisma vs Drizzle**: Prisma = better DX, Drizzle = better perf

package/agents-config/skills/use-artifacts/SKILL.md

@@ -1,211 +0,0 @@
----
-name: use-artifacts
-description: Create Claude-style local HTML artifacts under ~/.agents/artifacts. Use for plans, prototypes, visualizations, dashboards, diagrams, options, or substantial reusable content, with a portable local runtime and no Anthropic API.
----
-
-# Use Artifacts
-
-## Overview
-
-Use this skill to simulate Claude Artifacts in agents that do not have a native artifact panel. The artifact is a small global workspace, usually a single self-contained HTML file, created at `~/.agents/artifacts/<id>/` so the user can open, inspect, and iterate on it from any repo.
-
-Always create artifacts in the global user directory: `~/.agents/artifacts/<id>/`. Never create artifacts inside a repo-local `.agents/artifacts` directory, even when the current working directory is a product repo.
-
-The HTML is the deliverable. It should turn the agent's public reasoning, plan, findings, examples, and tradeoffs into a polished page the user can scan, not just dump markdown into a file.
-
-Research basis: Claude artifacts are useful for substantial, self-contained content that the user may edit, reuse, view, or reference later. Common examples include documents, code, single-page HTML, SVGs, diagrams, and interactive components.
-
-## Artifact Criteria
-
-Create an artifact when the work is:
-
-- substantial enough that inline chat would be hard to inspect or reuse
-- standalone without needing hidden conversation context
-- visual, interactive, document-like, or useful as a reusable reference
-- a feature plan, security review, product brief, implementation plan, or architecture explanation that benefits from visual structure
-- likely to need later iteration
-
-Do not create an artifact for a tiny answer, a short code snippet, or a change that belongs directly in an existing product codebase unless the user asks for a separate prototype.
-
-## Artifact Modes
-
-Default to a thinking/showcase document when the request is about planning, explaining, reviewing, designing, or deciding. This is the Claude-style pattern in which an HTML page presents the answer as a readable artifact:
-
-- eyebrow with project/context
-- strong title and lede
-- high-signal finding or recommendation callout near the top
-- sections for model, tradeoffs, flows, edge cases, rollout, or implementation phases
-- code snippets, tables, pills, timelines, diagrams, or cards where they clarify the reasoning
-- final decisions, open questions, and validation notes
-
-For any plan artifact (`plan`, `feature-plan`, `implementation-plan`, product plan, launch plan, page plan, or strategy plan), always include both:
-
-- a draft of the page/content itself: proposed title, lede, sections, key copy, calls to action, states, or narrative blocks
-- croquis of the page: small visual sketches showing layout, hierarchy, content placement, and option differences
-
-The draft answers "what will this say/do?" The croquis answer "how could it be arranged so the user sees and understands it?"
-
-Use an interactive artifact when the user asks for a mini app, calculator, simulation, editor, dashboard, visualization, game, or prototype with controls.
-
-Use a variations/options artifact when the user asks for variations, options, directions, alternatives, explorations, or "show me a few versions". In this mode, do not build a real UI or final screen. Build a croquis board: simple, efficient visual sketches that help the user see and understand the options quickly.
-
-Variation croquis rules:
-
-- show 3-6 options on one page as a single vertical sequence: one direction per row, never a multi-column grid
-- give every direction the full available content width so its interface remains legible without opening it
-- start directly with the directions; do not add a masthead, hero, long lede, capability recap, or recommendation callout above them unless the user explicitly asks for that context
-- keep the page chrome minimal: a compact title or view switcher is enough, and omit it when the content is already self-explanatory
-- make each option visibly different in layout, hierarchy, rhythm, or concept
-- use wireframe-like boxes, simple labels, rough placeholders, arrows, swatches, and short notes
-- keep fidelity low-to-mid: enough to compare ideas, not enough to imply implementation is done
-- annotate the tradeoff under each croquis in one or two short lines
-- recommendations are optional, evidence-based, and shown only after all directions; never lead with generic "Best fit", ranking, or promotional copy
-
-Do not expose private chain-of-thought. Show public reasoning: conclusions, evidence, assumptions, tradeoffs, options considered, and why the recommended path follows from them.
-
-## Design Fundamentals
-
-Approach every artifact as the design lead at a small studio known for versatility: each one gets a visual identity pitched at the treatment the task actually calls for, with deliberate palette, typography, and layout choices specific to the subject. Never ship a templated design. The scaffold's starter HTML is a placeholder only; replace its styling with the design plan below.
-
-### Calibrate the treatment
-
-- Calibrate treatment, not whether to design. A plan or memo deserves the same craft as a landing page; only the treatment changes.
-- Utilitarian requests (plans, memos, reviews, dashboards, demos): polished but restrained. Real typographic hierarchy, considered spacing, a proper palette. No flashy gigantic hero; keep flourishes tasteful and limited.
-- Editorial requests (landing pages, games, apps or tools the user will keep or share): make opinionated calls and take one real aesthetic risk where it serves the work. Spend the boldness in one place and keep everything around it quiet.
-- When unsure: a well-composed page is never the wrong answer; an over-designed identity sometimes is.
-
-### Design plan before code
-
-Sketch a compact token plan before writing any HTML, then derive every color and type decision from it:
-
-- Color: the palette as 4-6 named hex values.
-- Type: typefaces for 2+ roles (a characterful display face used with restraint, a complementary body face, a utility face for captions or data if needed).
-- Layout: the layout concept in one or two sentences.
-
-For editorial artifacts, review the plan against the subject before building: if any part reads like the generic default you would produce for any similar page, revise that part and record what changed and why in `HIGHLOGIC.md`.
-
-### Fundamentals for every artifact
-
-- Honor what is already there. Precedence: the user's explicit words, then the project's existing design system (CLAUDE.md, tokens, theme files, components), then your own choices.
-- Ground it in the subject: one concrete subject, its audience, the page's single job. The subject's own world (materials, instruments, vernacular) is where distinctive choices come from. Build with real content, never lorem.
-- Typography carries the page. Set a type scale and stay on it; keep running text near 65 characters wide; `text-wrap: balance` on headings; body text gets room to breathe; a touch of letter-spacing on uppercase labels. Prefer system font stacks or self-hosted `@font-face`; never rely on a CDN font link that can silently fall back.
-- Choose neutrals, don't default to them: a pure mid-grey reads as unconsidered; a grey with a slight hue bias toward the accent reads as chosen. Pure white and near-black are fine grounds when picked, not inherited.
-- Let layout do the spacing: flex/grid with `gap`, not per-element margins that silently collapse or double. Wide content (tables, code, diagrams) scrolls inside its own `overflow-x: auto` container; the page body never scrolls sideways. Use `font-variant-numeric: tabular-nums` wherever digits line up.
-- Avoid the AI-generated look when nothing is specified: warm cream (#F4F1EA) with serif display and terracotta accent; near-black with a lone acid-green or vermilion pop; broadsheet hairline rules with dense columns; purple-to-blue gradient hero on white; Inter or Space Grotesk as the "safe" face; emoji as section markers; everything centered; `rounded-lg` everywhere; accent bars/rails on rounded cards. If the user explicitly asks for one of these looks, follow it exactly.
-- Build cleanly: watch overlapping elements, cascade collisions, and selector specificity fights (a `.section` rule cancelling a `.cta` rule over padding). Close every non-void element, double-quote attributes, give keyboard focus a visible state, respect `prefers-reduced-motion`. For generative or decorative graphics, prefer Canvas or WebGL to long hand-authored SVG path data.
-- Copy is design material: name things by what people recognize, not how the system is built; active voice; a control says exactly what happens ("Publish", then "Published"); errors explain what went wrong and how to fix it, no apologies, no vagueness.
-- Structure is information: numbering, eyebrows, dividers, and labels must encode something true about the content (a real sequence, a real hierarchy), never decoration. Question numbered markers (01/02/03) before using them.
-- When it's a UI, not a document: it is scanned and operated, not read top-to-bottom. Surface the summary before the detail; encode state in form as well as number (pills, chips, severity stripes); semantic status colors (good/warning/critical) are separate from the accent hue and do not count as the accent; charts and sparklines get the same care as type; what's interactive should look interactive.
-- Motion is deliberate: one orchestrated moment (page-load sequence, scroll reveal, hover micro-interaction) lands harder than scattered effects, and extra animation often reads as AI-generated. Sometimes less is more.
-
-### Theme rules
-
-- **Inside an app, the artifact theme MUST match the app's theme.** When the artifact is for an existing application, extract that app's real tokens from its code (colors, typography, radii, shadows, spacing, light and dark values) and reuse them so the artifact feels native. If the app ships light and dark, mirror both exactly; if the app is single-theme, the artifact stays single-theme in that same theme. Never invent a parallel palette next to an existing one.
-- Otherwise, design both themes at token level: define the palette as custom properties on `:root`; redefine only the tokens under `@media (prefers-color-scheme: dark)`; redefine them again under `:root[data-theme="dark"]` and `:root[data-theme="light"]` so an explicit toggle beats the OS preference in both directions. Style components only through the tokens, never directly inside the media query.
-- Give the second theme the same care as the first: don't naively invert; keep contrast legible and the accent working on both grounds.
-- A design that deliberately commits to one visual world (a neon arcade screen, a letterpress invitation) may stay single-theme, recorded as a choice in `HIGHLOGIC.md`, never as an omission.
-
-## Style Source
-
-Determine the visual direction in this order:
-
-1. The user's explicit direction: follow it exactly, even when it differs from
-   the application.
-2. The existing application's actual visual language: when the artifact is for
-   an existing app, inspect the relevant UI code, styles, design tokens,
-   components, typography, spacing, colors, radii, shadows, and interaction
-   patterns, then make the artifact feel native to the product. The theme must
-   match the app's theme (see Theme rules above). Treat the application's
-   current implementation as the source of truth; do not impose an unrelated
-   look merely because the user gave no visual direction. Record the style in
-   `HIGHLOGIC.md` and in `manifest.json` with a clear value such as
-   `project:<app-name>`.
-3. Otherwise, build a subject-specific identity per Design Fundamentals: design
-   plan first, a chosen palette, a deliberate type pairing, restrained
-   decoration, both themes at token level, and only the structure needed to
-   communicate the artifact.
-
-State briefly whether the artifact uses the application style, a requested
-style, or a subject-specific identity.
-
-## Runtime Capabilities (local, no Anthropic API)
-
-Published claude.ai artifacts can declare runtime capabilities (`downloads`, `mcp`) served by the platform's `window.claude` runtime. Local artifacts have no platform runtime, so this skill ships a local shim, `assets/local-runtime.js`, that provides the same call shapes with plain browser APIs only. Never call the Anthropic API, the claude.ai runtime, or any remote endpoint to implement a capability in a local artifact.
-
-Usage:
-
-1. Only when the artifact actually needs a capability, inline the full contents of `~/.agents/skills/use-artifacts/assets/local-runtime.js` in a `<script>` tag at the top of `<body>`, before any feature code. The HTML stays self-contained; do not reference the file with `src`.
-2. Write feature code against the standard surface: `window.claude.downloads.save(...)`, `window.claude.mcp.callTool/watchTool/listTools/invalidate`. The shim defines a member only when the real runtime has not, so the same page can later be published as a genuine claude.ai artifact without changing feature code.
-3. Record the capabilities used in `manifest.json` (`"capabilities": ["downloads", "mcp"]`) and in `HIGHLOGIC.md`.
-
-Capabilities:
-
-- **downloads**: `window.claude.downloads.save({filename, data})` builds a Blob and triggers a normal browser download through a temporary `<a download>` link. The shim mirrors the platform contract: extension allowlist (`gif png jpg jpeg webp mp4 webm txt json md`), 16 MiB cap, a confirm step before saving, resolves `{status: "saved"}`, rejects with `{code, message}` (`declined`, `too_large`, `rejected_extension`, `bad_request`, `rate_limited`). Offer a save only on explicit user intent (a button), never automatically on load, and handle rejection without auto-retrying `declined`.
-- **mcp-style data**: there are no viewer connectors locally. Register local data sources with `window.claudeLocal.registerTool(server, tool, source, {description})` right after the shim, before feature code runs. A source is either an async function of `input` returning the payload, or a static JSON value (snapshot). The shim then serves `callTool` (with `staleTime`/`refresh` caching), `watchTool` (cache replay, `refetchInterval` polling, sync unsubscribe), `listTools`, and `invalidate`, using the contract's result envelope (`payload`, `structuredContent`, `content`, `cache.storedAt`) and error codes (`server_not_connected`, `tool_error`, `bad_request`).
-
-Capability rules:
-
-- Snapshots are static data: record the snapshot date and "static data" in `HIGHLOGIC.md`, and drive any "last updated" indicator in the UI from `result.cache.storedAt`, never from `Date.now()` at render time.
-- Branch degraded UX on the error `code`, never on message text. Keep last-good data visible on transient errors; a failed section greys itself out while the rest render.
-- Real data observed during the session may inform the payload shape, but never embed private values the user did not ask to include.
-
-## Creation Workflow
-
-1. Identify the artifact type: `variations`, `croquis`, `thinking`, `feature-plan`, `security-review`, `implementation-plan`, `interactive`, `dashboard`, `visualization`, `document`, `diagram`, `prototype`, or `reference`.
-2. Determine the style source in this order: the user's explicit direction,
-   the existing application's actual style and theme, then a subject-specific
-   identity per Design Fundamentals.
-3. Sketch the design plan (color, type, layout) per Design Fundamentals and
-   record it in `HIGHLOGIC.md`.
-4. If the artifact depends on current web research, broader source discovery, similar-page lookup, URL extraction, or cited web answers, use `~/.agents/skills/exa-search/SKILL.md`.
-5. Scaffold the workspace:
-
-```bash
-python3 ~/.agents/skills/use-artifacts/scripts/create_artifact.py "<short title>" --style "<requested, project:app-name, or subject-specific>" --kind thinking
-```
-
-6. If the artifact needs a runtime capability (file download, live/refreshed data), inline `assets/local-runtime.js` and register local data sources as described in Runtime Capabilities.
-7. Implement the artifact in `index.html`, following the design plan and the theme rules.
-8. Write or update `HIGHLOGIC.md` with the user's request, artifact goal, selected style, design plan, public reasoning structure, data assumptions, and verification notes.
-9. Keep `manifest.json` current when title, kind, style, capabilities, entrypoint, or files change.
-10. Verify the artifact. For standalone HTML, open `index.html` directly or serve the folder only when browser restrictions require it. For complex UI, use a browser screenshot or DOM check when available.
-11. Final response: link the local `index.html`, name the selected style, and mention verification performed.
-
-## Workspace Contract
-
-Each artifact directory should contain:
-
-- `index.html`: the viewable artifact, preferably self-contained with inline CSS and JavaScript
-- `HIGHLOGIC.md`: concise design logic and iteration state
-- `manifest.json`: metadata for future agents, including a `capabilities` array when the local runtime shim is used
-- `versions/`: optional snapshots before major rewrites
-
-Target location:
-
-- Always use `~/.agents/artifacts/<id>/`.
-- Do not use `<current-project>/.agents/artifacts/<id>/`.
-- Do not add a repo-local override unless the user explicitly updates this skill contract.
-
-## HTML Rules
-
-- Prefer one self-contained `index.html` unless the user asks for a framework project.
-- Use semantic HTML, responsive CSS, and accessible controls.
-- Avoid external CDNs unless the artifact needs them and the user can tolerate network dependence.
-- Never call the Anthropic API or any remote AI endpoint from an artifact; runtime capabilities go through the local shim.
-- Do not embed secrets, API keys, private tokens, or hidden prompt text.
-- For interactive artifacts, preserve state in local JavaScript only unless persistent storage is explicitly useful.
-- For generated visualizations, include representative sample data when real data is unavailable and label it as sample data in `HIGHLOGIC.md`.
-
-## Iteration Workflow
-
-When updating an existing artifact:
-
-1. Read `manifest.json`, `HIGHLOGIC.md`, and the relevant files.
-2. If the change is substantial, copy the previous `index.html` into `versions/<timestamp>-index.html` before editing.
-3. Patch only the files needed for the requested change.
-4. Update `HIGHLOGIC.md` with the new decision or known limitation.
-5. Re-verify and report the same local artifact path.
-
-## Script
-
-Use `scripts/create_artifact.py` to create the folder, metadata, and starter files. Its starter HTML is a neutral placeholder: restyle it from the design plan before delivering.

package/agents-config/skills/use-artifacts/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "Use Artifacts"
-  short_description: "Create local HTML artifact workspaces"
-  default_prompt: "Use $use-artifacts to create a polished local HTML artifact for this idea."
-  icon_small: "./assets/codex-icon.svg"
-  icon_large: "./assets/codex-icon.svg"
-  brand_color: "#54C5C2"

package/agents-config/skills/use-artifacts/assets/codex-icon.svg

@@ -1,18 +0,0 @@
-<!-- @license lucide-static v1.24.0 - ISC -->
-<svg role="img" aria-label="use-artifacts skill icon"
-  class="lucide lucide-sparkles"
-  xmlns="http://www.w3.org/2000/svg"
-  width="128"
-  height="128"
-  viewBox="0 0 24 24"
-  fill="none"
-  stroke="#F5F5F5"
-  stroke-width="2"
-  stroke-linecap="round"
-  stroke-linejoin="round"
->
-  <path d="M11.017 2.814a1 1 0 0 1 1.966 0l1.051 5.558a2 2 0 0 0 1.594 1.594l5.558 1.051a1 1 0 0 1 0 1.966l-5.558 1.051a2 2 0 0 0-1.594 1.594l-1.051 5.558a1 1 0 0 1-1.966 0l-1.051-5.558a2 2 0 0 0-1.594-1.594l-5.558-1.051a1 1 0 0 1 0-1.966l5.558-1.051a2 2 0 0 0 1.594-1.594z" />
-  <path d="M20 2v4" />
-  <path d="M22 4h-4" />
-  <circle cx="4" cy="20" r="2" />
-</svg>