@pikku/cli 0.12.90 → 0.12.92

package/skills/pikku-gateway-slack/SKILL.md

@@ -1,115 +0,0 @@
----
-name: pikku-gateway-slack
-description: >-
-  Use when integrating Slack with a Pikku app. Covers SlackGatewayAdapter, slash commands, OAuth
-  flow, message handling, and signature verification. TRIGGER when: code uses SlackGatewayAdapter,
-  parseSlashCommand, buildSlackInstallUrl, or user asks about Slack integration, Slack bots, or
-  @pikku/gateway-slack. DO NOT TRIGGER when: user asks about general gateway/webhook patterns (use
-  pikku-trigger).
----
-
-# Pikku Gateway Slack
-
-## Agent Operating Procedure
-
-Use this skill as an execution checklist, not reference material.
-
-1. Discover before editing. Prefer OpenCode tools such as `pikku-meta` when available; otherwise run the relevant `pikku meta ... --json` command and inspect only the focused output you need.
-2. Identify the source files that own the behavior. Do not start by reading generated output, `.pikku`, `node_modules`, vendored packages, or broad build artifacts.
-3. Make the smallest source change that satisfies the task. Keep generated files generated, and avoid hand-editing SDKs, schema output, or typegen.
-4. Validate with the narrowest relevant command first, then run `pikku-verify` or `pikku all` when functions, wirings, schemas, or generated clients may have changed.
-5. If validation fails, fix the source cause and rerun validation. Do not paper over generated errors by editing generated files.
-
-`@pikku/gateway-slack` provides a Slack Events API gateway adapter, slash command handling, OAuth installation flow, and message utilities.
-
-## Installation
-
-```bash
-yarn add @pikku/gateway-slack @slack/web-api
-```
-
-## API Reference
-
-### `SlackGatewayAdapter`
-
-```typescript
-import { SlackGatewayAdapter } from '@pikku/gateway-slack'
-
-const adapter = new SlackGatewayAdapter(options: SlackGatewayAdapterOptions)
-```
-
-Bridges Slack Events API webhooks with Pikku's gateway system for processing Slack events as Pikku functions.
-
-### `SlackGatewayHelper`
-
-Helper for handling Slack messages and metadata within gateway functions.
-
-### Slash Commands
-
-```typescript
-import { parseSlashCommand, respondToSlashCommand } from '@pikku/gateway-slack'
-
-const command = parseSlashCommand(request)
-await respondToSlashCommand(responseUrl, { text: 'Done!' })
-```
-
-### OAuth Flow
-
-```typescript
-import {
-  buildSlackInstallUrl,
-  exchangeSlackOAuthCode,
-  RECOMMENDED_BOT_SCOPES,
-} from '@pikku/gateway-slack'
-
-const installUrl = buildSlackInstallUrl({
-  clientId: config.slackClientId,
-  scopes: RECOMMENDED_BOT_SCOPES,
-  redirectUri: config.slackRedirectUri,
-})
-
-const tokens = await exchangeSlackOAuthCode({
-  clientId: config.slackClientId,
-  clientSecret: config.slackClientSecret,
-  code: oauthCode,
-  redirectUri: config.slackRedirectUri,
-})
-```
-
-### Signature Verification
-
-```typescript
-import { verifySlackSignature } from '@pikku/gateway-slack'
-
-verifySlackSignature(signingSecret, timestamp, body, signature)
-```
-
-## Usage Patterns
-
-### Slack Bot Gateway
-
-```typescript
-import { SlackGatewayAdapter } from '@pikku/gateway-slack'
-
-const slackGateway = new SlackGatewayAdapter({
-  signingSecret: config.slackSigningSecret,
-  botToken: config.slackBotToken,
-})
-
-// Register with your HTTP runner to handle /slack/events endpoint
-```
-
-### Slash Command Handler
-
-```typescript
-const handleSlashCommand = pikkuSessionlessFunc({
-  title: 'Handle Slack Command',
-  func: async ({ db }, data) => {
-    const command = parseSlashCommand(data)
-    // Process command...
-    await respondToSlashCommand(command.response_url, {
-      text: `Processed: ${command.text}`,
-    })
-  },
-})
-```

package/skills/pikku-http/SKILL.md

@@ -1,220 +0,0 @@
----
-name: pikku-http
-description: >-
-  Use when adding HTTP routes, REST APIs, web endpoints, or SSE streams to a Pikku app. Covers
-  wireHTTP, defineHTTPRoutes, route groups, auth, middleware, SSE, and generated
-  fetch client. TRIGGER when: code uses wireHTTP/defineHTTPRoutes/wireHTTPRoutes, user asks about
-  REST endpoints, API routes, SSE, or the generated fetch client. DO NOT TRIGGER when: user asks
-  about WebSocket (use pikku-websocket), queue workers (use pikku-queue), or deployment (use
-  pikku-deploy-*).
-installGroups: [core]
----
-
-# Pikku HTTP Wiring
-
-## Agent Operating Procedure
-
-Use this skill as an execution checklist, not reference material.
-
-1. Discover before editing. Prefer OpenCode tools such as `pikku-meta` when available; otherwise run the relevant `pikku meta ... --json` command and inspect only the focused output you need.
-2. Identify the source files that own the behavior. Do not start by reading generated output, `.pikku`, `node_modules`, vendored packages, or broad build artifacts.
-3. Make the smallest source change that satisfies the task. Keep generated files generated, and avoid hand-editing SDKs, schema output, or typegen.
-4. Validate with the narrowest relevant command first, then run `pikku-verify` or `pikku all` when functions, wirings, schemas, or generated clients may have changed.
-5. If validation fails, fix the source cause and rerun validation. Do not paper over generated errors by editing generated files.
-
-Wire Pikku functions to HTTP endpoints. Supports single routes, composable route groups, auth, middleware, SSE, and auto-generated type-safe clients. (Authorization lives on the function, not the wiring — see `pikku-permissions`.)
-
-## Before You Start
-
-Run these commands to understand the current project:
-
-```bash
-pikku info functions --verbose   # See existing functions, their types, tags, middleware
-pikku info tags --verbose        # Understand project organization and naming conventions
-pikku info middleware --verbose  # See what middleware is already applied
-```
-
-Follow existing patterns you find (naming, tag usage, file organization). See `pikku-concepts` for the core mental model.
-
-## API Reference
-
-- `wireHTTP(config)` (from `@pikku/core/http`) — wire one function to one endpoint.
-- `defineHTTPRoutes(config)` + `wireHTTPRoutes(config)` (from `.pikku/pikku-types.gen.js`) — group routes with shared config; composable/nestable.
-
-Function input/output types come from the function's own `input:`/`output:` zod schemas — never declared in the wiring. Route `:params`, query params, and body are merged into the function's `data` arg (see Data Flow).
-
-Config cascading across groups: `basePath` concatenates down the chain, `tags` merge (union), `auth` child overrides parent.
-
-For the full option tables (every `wireHTTP` field, the `defineHTTPRoutes`/`wireHTTPRoutes` config shape), read `references/http-options.md`.
-
-### `addHTTPMiddleware(pattern, middlewares)`
-
-```typescript
-addHTTPMiddleware('*', [authBearer()]) // All routes
-addHTTPMiddleware('/api/*', [rateLimit()]) // Pattern match
-```
-
-> HTTP-route-level permissions (`addHTTPPermission`, a `permissions` field on the wiring) were removed in #972. Declare authorization on the function definition (`pikkuFunc({ permissions })`, see `pikku-permissions`), or app-wide via `addGlobalPermission`. Tags/patterns are for *middleware* only now.
-
-## Data Flow
-
-Pikku merges route params, query params, and request body into a single `data` object:
-
-```typescript
-// POST /books/42?format=pdf  with body { title: "New Title" }
-wireHTTP({ method: 'post', route: '/books/:bookId', func: updateBook })
-// → updateBook receives: { bookId: "42", format: "pdf", title: "New Title" }
-```
-
-## Usage Patterns
-
-### Single Route
-
-```typescript
-wireHTTP({
-  method: 'get',
-  route: '/books/:bookId',
-  func: getBook,
-})
-```
-
-### Route Groups (Recommended for CRUD)
-
-```typescript
-const booksRoutes = defineHTTPRoutes({
-  tags: ['books'],
-  routes: {
-    list: { method: 'get', route: '/books', func: listBooks, auth: false }, // per-route override
-    get: { method: 'get', route: '/books/:bookId', func: getBook },
-    create: { method: 'post', route: '/books', func: createBook },
-    delete: { method: 'delete', route: '/books/:bookId', func: deleteBook },
-  },
-})
-
-const todosRoutes = defineHTTPRoutes({
-  auth: false, // group-level default, overridable per-route
-  tags: ['todos'],
-  routes: {
-    list: { method: 'get', route: '/todos', func: listTodos },
-  },
-})
-
-wireHTTPRoutes({
-  basePath: '/api/v1',
-  middleware: [cors()],
-  routes: { books: booksRoutes, todos: todosRoutes },
-})
-// Results in: GET /api/v1/books, POST /api/v1/books, GET /api/v1/todos, etc.
-```
-
-### Auth
-
-```typescript
-// Public route (no auth)
-wireHTTP({ method: 'get', route: '/books', func: listBooks, auth: false })
-
-// Authenticated route (default when a global auth middleware is set)
-wireHTTP({ method: 'delete', route: '/books/:bookId', func: deleteBook })
-```
-
-Authorization is not a wiring concern — declare it on the function via `permissions` (see `pikku-permissions`), or app-wide via `addGlobalPermission`.
-
-### Middleware
-
-```typescript
-import { cors, authBearer } from '@pikku/core/middleware'
-
-// Global middleware
-addHTTPMiddleware('*', [
-  cors({ origin: 'https://app.example.com', credentials: true }),
-  authBearer(),
-])
-
-// Scoped middleware
-addHTTPMiddleware('/api/*', [rateLimit({ maxRequests: 100, windowMs: 60_000 })])
-
-// Per-route middleware
-wireHTTP({
-  method: 'delete',
-  route: '/books/:bookId',
-  func: deleteBook,
-  middleware: [auditLog],
-})
-```
-
-### SSE (Server-Sent Events)
-
-```typescript
-wireHTTP({
-  method: 'get',
-  route: '/todos',
-  func: getTodos,
-  sse: true,
-})
-
-const getTodos = pikkuFunc({
-  title: 'Get Todos',
-  func: async ({ db, channel }, {}) => {
-    const todos = await db.getTodos()
-
-    if (channel) {
-      for (const todo of todos) {
-        channel.send({ todo })
-        await sleep(100)
-      }
-      return
-    }
-
-    return { todos }
-  },
-})
-```
-
-### Generated Fetch Client
-
-After `npx pikku all`, a type-safe client is generated:
-
-```typescript
-import { pikkuFetch } from '.pikku/pikku-fetch.gen.js'
-
-pikkuFetch.setServerUrl('http://localhost:4002')
-
-const books = await pikkuFetch.get('/api/v1/books', {})
-const book = await pikkuFetch.get('/api/v1/books/:bookId', { bookId: '42' })
-const created = await pikkuFetch.post('/api/v1/books', {
-  title: 'The Pikku Guide',
-  author: 'You',
-})
-
-pikkuFetch.setAuthorizationJWT(token)
-const deleted = await pikkuFetch.delete('/api/v1/books/:bookId', {
-  bookId: created.bookId,
-})
-```
-
-## Complete Example
-
-Functions live in their own files (one per file) and supply behavior + `permissions`; the wiring file imports them and wires routes. Sessionless funcs need no session; `pikkuFunc` does.
-
-```typescript
-// functions/books.functions.ts
-import { pikkuFunc, pikkuSessionlessFunc } from '#pikku'
-
-export const listBooks = pikkuSessionlessFunc({
-  title: 'List Books',
-  func: async ({ db }, { limit }) => ({ books: await db.listBooks(limit) }),
-})
-
-export const getBook = pikkuFunc({
-  title: 'Get Book',
-  description: 'Retrieve a book by ID',
-  func: async ({ db }, { bookId }) => await db.getBook(bookId),
-  permissions: { user: isAuthenticated },
-})
-
-// wirings/books.http.ts — same defineHTTPRoutes/wireHTTPRoutes shape as the Route Groups example above
-import { addHTTPMiddleware } from '@pikku/core/http'
-import { cors, authBearer } from '@pikku/core/middleware'
-
-addHTTPMiddleware('*', [cors(), authBearer()])
-```

package/skills/pikku-http/references/http-options.md

@@ -1,55 +0,0 @@
-# wireHTTP / defineHTTPRoutes / wireHTTPRoutes — full option reference
-
-## `wireHTTP(config)`
-
-Wire a single function to an HTTP endpoint. Import from `@pikku/core/http`.
-
-| Option | Type | Notes |
-| --- | --- | --- |
-| `method` | `'get' \| 'post' \| 'put' \| 'patch' \| 'delete' \| 'head'` | HTTP verb |
-| `route` | `string` | e.g. `/books/:bookId` — `:params` become `data` fields |
-| `func` | `PikkuFunc` | The function to call |
-| `auth?` | `boolean` | Override default auth (`true` = require session) |
-| `tags?` | `string[]` | For grouping, middleware targeting |
-| `middleware?` | `PikkuMiddleware[]` | Per-route middleware |
-| `sse?` | `boolean` | Enable Server-Sent Events |
-| `contentType?` | `'xml' \| 'json'` | Response content type |
-| `timeout?` | `number` | Request timeout in ms |
-| `headers?` | `HTTPHeadersSchema` | Expected headers schema |
-| `docs?` | `HTTPRouteDocsConfig` | OpenAPI docs config |
-
-## `defineHTTPRoutes(config)` + `wireHTTPRoutes(config)`
-
-Group routes with shared configuration. Groups are composable and nestable. Import from `.pikku/pikku-types.gen.js`.
-
-```typescript
-const routes = defineHTTPRoutes({
-  basePath?: string,       // Prepended to all route paths
-  tags?: string[],         // Applied to all routes in group
-  auth?: boolean,          // Default auth for all routes (overridable per-route)
-  middleware?: PikkuMiddleware[],
-  routes: {
-    [key: string]: {
-      method: string,
-      route: string,
-      func: PikkuFunc,
-      auth?: boolean,      // Override group auth
-      middleware?: PikkuMiddleware[],
-    }
-  }
-})
-
-wireHTTPRoutes({
-  basePath?: string,       // Top-level prefix (e.g. '/api/v1')
-  middleware?: PikkuMiddleware[],
-  routes: {
-    [key: string]: ReturnType<typeof defineHTTPRoutes>,
-  }
-})
-```
-
-Config cascading rules:
-
-- `basePath` — concatenates down the chain
-- `tags` — merge (union)
-- `auth` — child overrides parent

package/skills/pikku-i18n/SKILL.md

@@ -1,137 +0,0 @@
----
-name: pikku-i18n
-description: 'Wire i18n into a Pikku frontend with Paraglide JS (inlang). English by default, every user-facing string is a typed message function (`m.some__key()`) compiled from `messages/<locale>.json`, and additional languages are served under `/fr` `/de` URL prefixes. TRIGGER when: scaffolding or editing a frontend and writing user-facing text, adding a second language, or asked to "make this translatable / use tokens / add i18n". DO NOT TRIGGER for backend functions, error messages thrown from functions, or log output.'
-installGroups: [core]
----
-
-# Pikku i18n (Paraglide JS)
-
-## Agent Operating Procedure
-
-Use this skill as an execution checklist, not reference material.
-
-1. Every user-facing string in a frontend is a message. Never hardcode display text — add a key to `messages/en.json` and render `m.the__key()`. This holds even when the app ships only English; the messages are the seam a second language slots into later.
-2. One `messages/<locale>.json` per language at the app root (NOT under `src/`), declared in `project.inlang/settings.json`. English (`en`) is `baseLocale` and the only locale until someone adds another.
-3. Messages compile to typed ESM functions in `src/paraglide/` (generated, self-gitignored — never edit or commit it). The Vite plugin compiles during `dev`/`build` with HMR on message edits; run the CLI compile only when you need `tsc` before Vite has ever run.
-4. Validate with the app's own `tsc` then its `build`. The deploy pipeline compiles Paraglide and runs each frontend's `tsc` before building it — an i18n mistake blocks the deploy.
-
-## The moving parts (starter-template layout)
-
-- `messages/en.json` — flat keys, `{param}` interpolation, inlang message-format:
-  ```json
-  {
-    "$schema": "https://inlang.com/schema/inlang-message-format",
-    "auth__login__title": "Sign in",
-    "auth__login__description": "Welcome back to {name}."
-  }
-  ```
-  Key convention: lower snake_case, `__` (double underscore) between namespace segments, `_` within a segment — `auth__login__title`, `common__email_placeholder`.
-- `project.inlang/settings.json` — `baseLocale`, `locales`, the `@inlang/plugin-message-format` module, `pathPattern: "./messages/{locale}.json"`.
-- `vite.config.ts` — `paraglideVitePlugin({ project: './project.inlang', outdir: './src/paraglide' })` from `@inlang/paraglide-js` (devDependency), FIRST in the plugins array.
-- `src/paraglide/` — compiled output (`messages.js`, `runtime.js`, per-locale `messages/*.js`). Generated; it writes its own `.gitignore`.
-- `src/i18n/config.ts` — locale plumbing, and the ONLY hand-written i18n module: `supportedLocales`/`defaultLocale` (re-exported from `../paraglide/runtime.js`), `detectLocale`, `localeDir` (RTL for ar/he/fa/ur), a reactive locale store (`overwriteGetLocale` bridged to `useSyncExternalStore`), `setActiveLocale`, `useLocale()`. This is not a wrapper over messages — Paraglide's `getLocale()` is a module global with no React reactivity, and this bridges it. Wire `overwriteGetLocale` or `m.*()` will resolve a different locale than the app thinks is active.
-- `tsconfig.json` — `"allowJs": true, "checkJs": false` so `tsc` can consume Paraglide's JSDoc-typed JS output.
-
-## Using messages in components
-
-```tsx
-import { m } from '../paraglide/messages.js'
-import { useLocale } from '@/i18n/config'
-
-function LoginPage() {
-  useLocale() // subscribe: re-render m.*() when the locale switches
-  return (
-    <>
-      <Title>{m.auth__login__title()}</Title>
-      <Text>{m.auth__login__description({ name: m.app__name() })}</Text>
-    </>
-  )
-}
-```
-
-- Params: `{name}` in the JSON → `m.auth__login__description({ name })`. Params are typed per message.
-- Any component that renders `m.*()` calls `useLocale()` (bare call is enough); it also returns `{ locale, dir, setLocale }` for switchers.
-- Non-component helpers (formatters, status maps) call `m.some__key()` directly — the functions are plain ESM, no hook needed; the render-time subscription lives in the component that displays the result.
-- Locale switching: the root route persists to localStorage, sets `<html lang dir>` (`localeDir`), and calls `setActiveLocale` — in-SPA re-render, no page reload. Mirror `routes/__root.tsx` in the starter template.
-
-## Keys only known at runtime (enum labels, status maps)
-
-A DB value picking a label (`enums__document_status__${status}`) is the one case a
-generated message can't express. Paraglide's README (§ "What about dynamic or
-CMS-driven keys?") is explicit: use an **explicit mapping from value to message
-function**. Key it on the enum type, never `string`:
-
-```ts
-import { m } from '../paraglide/messages.js'
-
-const DOCUMENT_STATUS_LABEL: Record<DocumentStatus, () => string> = {
-  completed: m.enums__document_status__completed,
-  in_progress: m.enums__document_status__in_progress,
-  required: m.enums__document_status__required,
-}
-
-// call site — no fallback, because there is no missing case
-DOCUMENT_STATUS_LABEL[status]()
-```
-
-`Record<DocumentStatus, …>` is exhaustive: add a value to the enum without a
-label and the build fails. That is the entire point.
-
-Do NOT write `Record<string, () => string>` with a `?? status` fallback, and do
-NOT index the namespace with a computed key (`m[\`enums__${name}__${value}\`]`).
-Both compile, both render the raw identifier to users when a label is missing,
-and both reintroduce exactly the silent-fallback failure Paraglide exists to
-eliminate. If you find yourself writing a `resolveDynamicKey(key: string)`
-helper, stop — that helper IS the bug.
-
-## Type safety — and why deploys block on i18n
-
-A message IS a function: a typo'd or deleted key (`m.auth__login__titel()`) is a missing export — a **TypeScript error**, not a silent runtime fallback string. Params are typed too. The deploy pipeline compiles Paraglide then runs each frontend's `tsc` (`"tsc": "tsc --noEmit"` script — keep it in every frontend's `package.json`) **before** building; a type error aborts the deploy. `vite build` does not type-check on its own, so this gate is the only thing standing between a broken message and production.
-
-The gate catches _invalid_ messages but not _inlined_ strings. The `@pikku/mantine` `I18nNode` prop typing catches those: a raw string literal fails to compile on a gated prop, because `I18nString` is a branded type a bare `string` can't satisfy. Between the two, `tsc` is the whole safety net — there is no runtime fallback to inspect, by design.
-
-## Compile step
-
-- **Dev/build:** the Vite plugin compiles automatically; editing `messages/*.json` under a running dev server recompiles + HMRs.
-- **Standalone `tsc` before Vite has run** (fresh clone, CI):
-  ```sh
-  npx @inlang/paraglide-js compile --project ./project.inlang --outdir ./src/paraglide
-  ```
-  This is exactly what the deploy CI does before the per-app `tsc`.
-
-## Adding a second language
-
-1. `messages/fr.json` mirroring `en.json`'s keys (translate the values, keep `{param}` names identical).
-2. Add `"fr"` to `locales` in `project.inlang/settings.json`.
-3. Recompile (restart/`vite dev` or the CLI compile). A locale file missing keys falls back to the base locale per message.
-4. Content is reachable via the `/<lang>` URL prefix (`detectLocale` already resolves it); the base locale needs no prefix. Expose the switcher via `useLocale().setLocale`.
-
-## i18n debug mode (find inlined strings)
-
-`tsc` catches invalid messages, and the `@pikku/mantine` gate catches raw strings on gated props — but neither sees a hardcoded string in plain JSX, an `aria-label`, `alt`, `document.title`, or anything passed to a non-Mantine component. Debug mode covers that gap: render every message as block glyphs (`█`), and whatever is still readable never went through a message.
-
-**Build it as a generated locale, never as a runtime wrapper.** Masked text is text, and rendering different text per locale is what Paraglide already does:
-
-1. A script generates `messages/zz.json` from `en.json`, replacing `\S` with `█` while leaving `{placeholders}` intact (they are message inputs — mangling them changes the compiled signature). Run it before `paraglide-js compile`; gitignore the output.
-2. Add `"zz"` to `locales` in `project.inlang/settings.json`.
-3. Switch to it in the locale bridge:
-   ```ts
-   overwriteGetLocale(() => (isI18nDebug() ? 'zz' : activeLocale))
-   ```
-
-Keep `zz` out of the app's own `supportedLocales` — that drives URL prefixes, hreflang and any backend `locale` param, none of which should see it.
-
-Generate the catalogue in dev only. With `messages/zz.json` absent, Paraglide compiles `zz` to an alias of the base locale (`const zz_x = en_x` — one line per message, no duplicated strings), so a production bundle carries the locale at effectively zero cost.
-
-Both the generator and the store bridge are being upstreamed (pikkujs/pikku#1036, #1035).
-
-The wrapper alternative — a module that walks the namespace and pipes each message through a `mask()` — is what this replaces. It defeats tree-shaking (touching every export), adds a check on every call, and forces every component to import `m` from the wrapper instead of Paraglide.
-
-## What NOT to do
-
-- Don't hardcode display strings "just for now" — the message is the work.
-- Don't edit or commit anything under `src/paraglide/` — it's regenerated; change `messages/*.json` instead.
-- **Don't wrap `m`.** No re-export module, no branding layer, no resolver. Components import `m` from `../paraglide/messages.js` and call it. `@pikku/react`'s `I18nString` is declared as `string & { readonly __brand: 'LocalizedString' }` — deliberately identical to Paraglide's own `LocalizedString` — so `m.some__key()` satisfies the `@pikku/mantine` `I18nNode` gate natively. A wrapper adds nothing and costs per-message tree-shaking.
-- Don't re-resolve messages by string key or re-implement `{param}` interpolation. A key-string resolver turns a missing key back into silent runtime text, surrendering the type safety that is the entire reason to use Paraglide.
-- Don't reach for i18next/react-i18next or a runtime-fetch translation loader — Paraglide's compiled functions are the whole delivery mechanism.
-- Don't tokenize backend error messages or logs here — those are not frontend display strings.

package/skills/pikku-info/SKILL.md

@@ -1,100 +0,0 @@
----
-name: pikku-info
-description: >-
-  Discover what exists in a Pikku project — functions, tags, middleware, permissions, HTTP routes,
-  channels, schedulers, queues, and more. Use when you need to understand the project structure,
-  find existing functions, or check what middleware and permissions are defined. TRIGGER when:
-  user asks "what functions exist?", "show me the project structure", "list
-  routes/middleware/permissions", or needs to understand an existing Pikku codebase. DO NOT
-  TRIGGER when: user is writing new code (use the specific wiring skill) or asking about Pikku
-  concepts (use pikku-concepts).
-installGroups: [core]
-allowed-tools: Bash(yarn pikku info *)
-argument-hint: '[functions|tags|middleware|permissions] [--verbose] [--limit N]'
----
-
-# Pikku Project Discovery
-
-## Agent Operating Procedure
-
-Use this skill as an execution checklist, not reference material.
-
-1. Discover before editing. Prefer OpenCode tools such as `pikku-meta` when available; otherwise run the relevant `pikku meta ... --json` command and inspect only the focused output you need.
-2. Identify the source files that own the behavior. Do not start by reading generated output, `.pikku`, `node_modules`, vendored packages, or broad build artifacts.
-3. Make the smallest source change that satisfies the task. Keep generated files generated, and avoid hand-editing SDKs, schema output, or typegen.
-4. Validate with the narrowest relevant command first, then run `pikku-verify` or `pikku all` when functions, wirings, schemas, or generated clients may have changed.
-5. If validation fails, fix the source cause and rerun validation. Do not paper over generated errors by editing generated files.
-
-Use the `pikku info` CLI commands to inspect this Pikku project. Run the commands below and present the results to the user in a clear summary.
-
-## Available Commands
-
-Always use `--silent` to suppress the banner and inspector logs.
-
-### Functions
-
-List all registered pikku functions:
-
-```bash
-yarn pikku info functions --silent
-```
-
-For full details including transport type (http/channel/scheduler/queue/workflow/mcp/cli/trigger), middleware, permissions, and source file:
-
-```bash
-yarn pikku info functions --verbose --silent
-```
-
-### Tags
-
-List all tags with counts of associated functions and middleware:
-
-```bash
-yarn pikku info tags --silent
-```
-
-For full names instead of counts:
-
-```bash
-yarn pikku info tags --verbose --silent
-```
-
-### Middleware
-
-List all middleware definitions:
-
-```bash
-yarn pikku info middleware --silent
-```
-
-For full details including source file, required services, and description:
-
-```bash
-yarn pikku info middleware --verbose --silent
-```
-
-### Permissions
-
-List all permission definitions:
-
-```bash
-yarn pikku info permissions --silent
-```
-
-For full details including source file, required services, and description:
-
-```bash
-yarn pikku info permissions --verbose --silent
-```
-
-## Instructions
-
-1. If the user specifies a subcommand (e.g., `/pikku-info functions`), run only that command.
-2. If no subcommand is specified, run all four commands to give a complete project overview.
-3. Always use `--silent` to suppress the Pikku banner and inspector logs.
-4. Use `--verbose` when the user asks for details, file paths, or "more info".
-5. Use `--limit N` to control output size (default is 50 rows).
-6. After running the commands, summarize the findings concisely:
-   - Total count of functions, tags, middleware, and permissions
-   - Notable patterns (e.g., which transport types are in use, which tags group the most functions)
-   - Any functions without tags or transport types (potential issues)