mandrel 1.93.0 → 2.0.0

package/.agents/skills/core/using-agent-skills/SKILL.md

@@ -1,232 +0,0 @@
----
-name: using-agent-skills
-description:
-  Discovers and invokes agent skills. Use when starting a session or when you
-  need to discover which skill applies to the current task. This is the
-  meta-skill that governs how all other skills are discovered and invoked.
----
-
-# Using Agent Skills
-
-## Policy Capsule
-
-- Check for an applicable skill **before** starting work; skills are workflows, not suggestions — follow steps in order and never skip the verification step.
-- Surface assumptions explicitly before any non-trivial implementation (`ASSUMPTIONS I'M MAKING:` block) and invite correction.
-- Manage confusion actively: STOP, name the inconsistency, present the trade-off, wait for resolution. Never silently pick an interpretation.
-- **Sub-agent exception**: when running under `helpers/epic-deliver-story`, `helpers/single-story-deliver`, or another non-interactive parent, never stall for input. Pick the narrowest reasonable interpretation that satisfies the parent Story's AC; if truly stuck, transition to `agent::blocked`, post a `friction` structured comment with the default assumption, and exit non-zero.
-- Push back on flawed approaches with concrete, quantified downsides and an alternative; sycophancy is a failure mode.
-- Enforce Simplicity: prefer the boring, obvious solution. Resist abstraction unless it earns its complexity; 1000 lines where 100 suffice is a failure.
-- Maintain Scope Discipline: no drive-by cleanups, no refactoring adjacent systems, no deletions you don't fully understand, no unsolicited features.
-- Verify, don't assume — tasks complete only when evidence (passing tests, build output, runtime data) is in hand.
-- When in doubt and the task is non-trivial without a spec, start with `spec-driven-development`. Multiple skills compose; follow the canonical lifecycle order when delivering a complete feature.
-
-## Overview
-
-Agent Skills is a collection of engineering workflow skills organized by
-development phase. Each skill encodes a specific process that senior engineers
-follow. This meta-skill helps you discover and apply the right skill for your
-current task.
-
-## Skill Discovery
-
-When a task arrives, identify the development phase and apply the corresponding
-skill:
-
-```text
-Task arrives
-    │
-    ├── Vague idea/need refinement? ──→ idea-refinement
-    ├── New project/feature/change? ──→ spec-driven-development
-    ├── Have a spec, need tasks? ──────→ planning-and-task-breakdown
-    ├── Implementing code? ────────────→ incremental-implementation
-    │   ├── UI work? ─────────────────→ frontend-ui-engineering
-    │   ├── API work? ────────────────→ api-and-interface-design
-    │   └── Need better context? ─────→ context-engineering
-    ├── Writing/running tests? ────────→ test-driven-development
-    │   └── Browser-based? ───────────→ browser-testing-with-devtools
-    ├── Something broke? ──────────────→ debugging-and-error-recovery
-    ├── Reviewing code? ───────────────→ code-review-and-quality
-    │   ├── Security concerns? ───────→ security-and-hardening
-    │   └── Performance concerns? ────→ performance-optimization
-    ├── Committing/branching? ─────────→ git-workflow-and-versioning
-    ├── CI/CD pipeline work? ──────────→ ci-cd-and-automation
-    ├── Writing docs/ADRs? ───────────→ documentation-and-adrs
-    └── Deploying/launching? ─────────→ shipping-and-launch
-```
-
-## Core Operating Behaviors
-
-These behaviors apply at all times, across all skills. They are non-negotiable.
-
-### 1. Surface Assumptions
-
-Before implementing anything non-trivial, explicitly state your assumptions:
-
-```text
-ASSUMPTIONS I'M MAKING:
-1. [assumption about requirements]
-2. [assumption about architecture]
-3. [assumption about scope]
-→ Correct me now or I'll proceed with these.
-```
-
-Don't silently fill in ambiguous requirements. The most common failure mode is
-making wrong assumptions and running with them unchecked. Surface uncertainty
-early — it's cheaper than rework.
-
-### 2. Manage Confusion Actively
-
-When you encounter inconsistencies, conflicting requirements, or unclear
-specifications:
-
-1. **STOP.** Do not proceed with a guess.
-2. Name the specific confusion.
-3. Present the tradeoff or ask the clarifying question.
-4. Wait for resolution before continuing.
-
-**Bad:** Silently picking one interpretation and hoping it's right. **Good:** "I
-see X in the spec but Y in the existing code. Which takes precedence?"
-
-#### Sub-agent exception
-
-The "STOP and ask the operator" guidance above applies when a human is in
-the loop. When you are running as a **sub-agent** of another skill — most
-commonly a Story executor spawned by `helpers/epic-deliver-story` or
-`helpers/single-story-deliver` — there is **no input channel** to ask.
-In that context:
-
-1. Pick the **narrowest reasonable interpretation** that satisfies the
-   Story's acceptance criteria. Out-of-scope cleanups belong in a
-   follow-on ticket, not a widened Story.
-2. If you genuinely cannot proceed, transition to `agent::blocked`, post a
-   `friction` structured comment naming the decision required and the
-   default assumption you would have made, and exit non-zero. The parent
-   `/deliver` aggregator will surface the block.
-3. **Never** stall waiting for input that will never arrive.
-
-This is the only documented exception to the "Manage Confusion Actively"
-rule. Read it together with the Story-implementation contracts in
-[`helpers/epic-deliver-story`](../../../workflows/helpers/epic-deliver-story.md)
-and [`helpers/single-story-deliver`](../../../workflows/helpers/single-story-deliver.md),
-which state the same constraint from the executor side.
-
-### 3. Push Back When Warranted
-
-You are not a yes-machine. When an approach has clear problems:
-
-- Point out the issue directly
-- Explain the concrete downside (quantify when possible — "this adds ~200ms
-  latency" not "this might be slower")
-- Propose an alternative
-- Accept the human's decision if they override with full information
-
-Sycophancy is a failure mode. "Of course!" followed by implementing a bad idea
-helps no one. Honest technical disagreement is more valuable than false
-agreement.
-
-### 4. Enforce Simplicity
-
-Your natural tendency is to overcomplicate. Actively resist it.
-
-Before finishing any implementation, ask:
-
-- Can this be done in fewer lines?
-- Are these abstractions earning their complexity?
-- Would a staff engineer look at this and say "why didn't you just..."?
-
-If you build 1000 lines and 100 would suffice, you have failed. Prefer the
-boring, obvious solution. Cleverness is expensive.
-
-### 5. Maintain Scope Discipline
-
-Touch only what you're asked to touch.
-
-Do NOT:
-
-- Remove comments you don't understand
-- "Clean up" code orthogonal to the task
-- Refactor adjacent systems as a side effect
-- Delete code that seems unused without explicit approval
-- Add features not in the spec because they "seem useful"
-
-Your job is surgical precision, not unsolicited renovation.
-
-### 6. Verify, Don't Assume
-
-Every skill includes a verification step. A task is not complete until
-verification passes. "Seems right" is never sufficient — there must be evidence
-(passing tests, build output, runtime data).
-
-## Failure Modes to Avoid
-
-These are the subtle errors that look like productivity but create problems:
-
-1. Making wrong assumptions without checking
-2. Not managing your own confusion — plowing ahead when lost
-3. Not surfacing inconsistencies you notice
-4. Not presenting tradeoffs on non-obvious decisions
-5. Being sycophantic ("Of course!") to approaches with clear problems
-6. Overcomplicating code and APIs
-7. Modifying code or comments orthogonal to the task
-8. Removing things you don't fully understand
-9. Building without a spec because "it's obvious"
-10. Skipping verification because "it looks right"
-
-## Skill Rules
-
-1. **Check for an applicable skill before starting work.** Skills encode
-   processes that prevent common mistakes.
-
-2. **Skills are workflows, not suggestions.** Follow the steps in order. Don't
-   skip verification steps.
-
-3. **Multiple skills can apply.** A feature implementation might involve
-   `idea-refinement` → `spec-driven-development` → `planning-and-task-breakdown`
-   → `incremental-implementation` → `test-driven-development` →
-   `code-review-and-quality` → `shipping-and-launch` in sequence.
-
-4. **When in doubt, start with a spec.** If the task is non-trivial and there's
-   no spec, begin with `spec-driven-development`.
-
-## Lifecycle Sequence
-
-For a complete feature, the typical skill sequence is:
-
-```text
-1. idea-refinement                 → Refine vague ideas
-2. spec-driven-development     → Define what we're building
-3. planning-and-task-breakdown → Break into verifiable chunks
-4. context-engineering         → Load the right context
-5. incremental-implementation  → Build slice by slice
-6. test-driven-development     → Prove each slice works
-7. code-review-and-quality     → Review before merge
-8. git-workflow-and-versioning → Clean commit history
-9. documentation-and-adrs      → Document decisions
-10. shipping-and-launch        → Deploy safely
-```
-
-Not every task needs every skill. A bug fix might only need:
-`debugging-and-error-recovery` → `test-driven-development` →
-`code-review-and-quality`.
-
-## Quick Reference
-
-| Phase  | Skill                         | One-Line Summary                                                  |
-| ------ | ----------------------------- | ----------------------------------------------------------------- |
-| Define | idea-refinement               | Refine ideas through structured divergent and convergent thinking |
-| Define | spec-driven-development       | Requirements and acceptance criteria before code                  |
-| Plan   | planning-and-task-breakdown   | Decompose into small, verifiable tasks                            |
-| Build  | incremental-implementation    | Thin vertical slices, test each before expanding                  |
-| Build  | context-engineering           | Right context at the right time                                   |
-| Build  | frontend-ui-engineering       | Production-quality UI with accessibility                          |
-| Build  | api-and-interface-design      | Stable interfaces with clear contracts                            |
-| Verify | test-driven-development       | Failing test first, then make it pass                             |
-| Verify | browser-testing-with-devtools | Chrome DevTools MCP for runtime verification                      |
-| Verify | debugging-and-error-recovery  | Reproduce → localize → fix → guard                                |
-| Review | code-review-and-quality       | Five-axis review with quality gates                               |
-| Review | security-and-hardening        | OWASP prevention, input validation, least privilege               |
-| Review | performance-optimization      | Measure first, optimize only what matters                         |
-| Ship   | git-workflow-and-versioning   | Atomic commits, clean history                                     |
-| Ship   | ci-cd-and-automation          | Automated quality gates on every change                           |
-| Ship   | documentation-and-adrs        | Document the why, not just the what                               |
-| Ship   | shipping-and-launch           | Pre-launch checklist, monitoring, rollback plan                   |

package/.agents/skills/stack/architecture/monorepo-path-strategist/SKILL.md

@@ -1,31 +0,0 @@
----
-name: monorepo-path-strategist
-description:
-  Enforces strict workspace package routing and dependency boundaries. Use when
-  working in a monorepo with workspace aliases (e.g. `@repo/shared/*`,
-  `@repo/ui/*`) and you need to prevent deep relative imports, cross-workspace
-  contamination, or dependencies added at the wrong package.json level.
----
-
-# Monorepo Path Strategist
-
-## Policy Capsule
-
-- Never use deeply nested relative imports to access shared logic across workspaces.
-- Use the established workspace aliases (e.g. `@repo/shared/db`, `@repo/ui/components`) for every cross-package reference.
-- Add new dependencies to the specific workspace's `package.json`, not the monorepo root.
-- Never cross-contaminate UI surfaces: `@repo/web` and `@repo/mobile` must not import from each other.
-- Treat workspace aliases as the canonical contract — refactor any deep relative import you encounter into the alias form.
-
-**Description:** Enforces strict workspace package routing and dependency
-boundaries.
-
-**Instruction:** You are operating within a strict monorepo environment.
-
-- NEVER use deeply nested relative imports to access shared logic.
-- You MUST use the established workspace aliases (e.g., `@repo/shared/db`,
-  `@repo/ui/components`).
-- Ensure any new dependencies are added to the correct workspace `package.json`,
-  not the root.
-- Do not cross-contaminate UI code: `@repo/web` and `@repo/mobile` must never
-  import from each other.

package/.agents/skills/stack/architecture/structured-output-zod/SKILL.md

@@ -1,51 +0,0 @@
----
-name: structured-output-zod
-description:
-  Validates external and structured data with Zod schemas. Use when accepting
-  untrusted input at API boundaries, validating environment variables on
-  startup, parsing third-party responses, or generating typed shapes via
-  `z.infer`. Parse, don't validate.
-vendor: zod
----
-
-# Skill: Structured Output (Zod)
-
-## Policy Capsule
-
-- Define every external or structured data shape as a Zod schema before it is processed or stored.
-- Derive TypeScript types from schemas via `z.infer`; never hand-author a parallel `type` for the same shape.
-- Parse untrusted input with `z.parse()` or `z.safeParse()` — do not pass raw values past the boundary.
-- Validate every incoming request body and query parameter at the application boundary.
-- Validate `process.env` at startup with a Zod schema so missing or malformed config fails fast.
-- Compose complex schemas with `.extend()`, `.merge()`, and `.pick()` to keep shapes DRY.
-- Use `z.coerce.*` deliberately for form and query inputs; do not coerce in trusted server-to-server paths.
-
-Guidelines for ensuring system reliability through schema validation and typed
-safety.
-
-## 1. Core Principles
-
-- **Schema First:** Always define data shapes with Zod before processing or
-  storing external data.
-- **Type Safety:** Leverage Zod's `z.infer` to automatically generate TypeScript
-  types from your schemas.
-- **Parse, Don't Validate:** Use `z.parse()` or `z.safeParse()` to transform
-  untrusted input into trusted, typed objects.
-
-## 2. Technical Standards
-
-- **API Validation:** Validate every incoming request body and query parameter
-  at the application boundary.
-- **Environment Variables:** Use Zod to validate `process.env` on startup to
-  fail fast if critical config is missing.
-- **Database Schemas:** In systems like Drizzle or Turso collections, use Zod
-  schemas to ensure data integrity during writes.
-
-## 3. Best Practices
-
-- **Error Messages:** Provide user-friendly, specific error messages via Zod's
-  custom error formatting.
-- **Composition:** Build complex schemas using `.extend()`, `.merge()`, and
-  `.pick()` to maintain DRY principles in your types.
-- **Coercion:** Use Zod coercion (`z.coerce.number()`) carefully to handle
-  string inputs from forms or query parameters.

package/.agents/skills/stack/architecture/subagent-orchestration/SKILL.md

@@ -1,76 +0,0 @@
----
-name: subagent-orchestration
-description:
-  Coordinates complex tasks via task-isolated subagents. Use when one objective
-  is too large for a single agent or when independent work streams should run
-  concurrently with minimal context bleed. One objective per subagent;
-  summarize before returning to keep the orchestrator's context window clean.
-  Applies recursively — an orchestrator at any supported nesting depth applies
-  the same policy to its own children.
----
-
-# Skill: Subagent Orchestration
-
-## Recursive orchestration model
-
-This skill describes **recursive orchestration**, not a fixed two-tier
-"main agent vs. subagents" split. An **orchestrator** is any agent that
-dispatches sub-agents; a sub-agent is itself an orchestrator over its own
-children. The Claude Code harness carries the `Agent` tool into sub-agents
-(verified nesting depth 2, announced max depth 5; see
-[#2870](https://github.com/dsj1984/mandrel/issues/2870)), so the same
-one-objective / verify / parallelize policy applies **at every level** —
-substitute "orchestrator" for "main agent" and "child" for "subagent"
-throughout and the rules hold unchanged. Keeping a given dispatch level
-flat remains a legitimate **design choice** (e.g. the `/deliver` wave
-loop), but it is no longer forced by a harness limitation.
-
-The cost caution compounds with depth: every nesting level re-pays the
-full always-loaded context, so an orchestrator MUST weigh the depth it
-opens against its budget (see
-[`instructions.md` § 4](../../../../instructions.md)) and stay within the
-supported depth envelope.
-
-## Policy Capsule
-
-- Dispatch one objective per subagent; never bundle unrelated goals into a single delegation.
-- Hand each subagent only the minimum context (files, docs, goal) required — no broad context dumps.
-- Specify the expected return format explicitly (JSON summary, diff, bullet list) in every handoff.
-- Verify the subagent's output before incorporating it; treat returned artifacts as untrusted until checked.
-- Run non-dependent subagents in parallel; serialize only when one subagent's output is required input for another.
-- Require a concise summary back from each subagent to keep the orchestrator's context window clean.
-- Investigate subagent failures rather than retrying blindly with the same prompt.
-- Respect the nesting depth budget; each level opened re-pays the always-loaded context, so orchestrate deeper only when the isolation or parallelism gain justifies the cost.
-
-Internal protocol for managing complex tasks through the creation and
-coordination of subagents, applied recursively by the orchestrator at any
-supported depth.
-
-## 1. Core Principles
-
-- **Task Isolation:** One objective per subagent. Do not overload a subagent
-  with multiple unrelated tasks.
-- **Minimal Context:** Provide only the necessary context (files, docs, specific
-  goal) to keep the subagent focused and token-efficient.
-- **Verification:** The orchestrator must always verify each child's output
-  before incorporating it into its own result — at every level of the tree.
-- **Depth Awareness:** Orchestration is recursive; before opening a deeper
-  level, confirm the work justifies re-paying the always-loaded context and
-  that the nesting stays within the supported depth envelope.
-
-## 2. Operation Standards
-
-- **Handoffs:** When delegating, clearly state the expected return format (e.g.,
-  "Return a JSON summary", "Provide a diff for file X").
-- **Error Handling:** If a subagent fails or returns an ambiguous result,
-  investigate the failure rather than retrying blindly.
-- **Parallelism:** Use subagents to perform non-dependent tasks concurrently
-  (e.g., auditing three different modules simultaneously). A child that is
-  itself an orchestrator may parallelize its own sub-units the same way.
-
-## 3. Best Practices
-
-- **State Sync:** Ensure the orchestrator's mental model remains the source of
-  truth if multiple subagents modify the codebase.
-- **Summarization:** Require subagents to provide a concise summary of their
-  findings to prevent the orchestrator's context window from being flooded.

package/.agents/skills/stack/backend/cloudflare-hono-architect/SKILL.md

@@ -1,31 +0,0 @@
----
-name: cloudflare-hono-architect
-description:
-  Prevents Node.js module hallucinations in Cloudflare Worker (V8 isolate)
-  edge environments. Use when writing Hono routes deployed to Workers — prefer
-  Web APIs (Fetch, Web Crypto) over Node built-ins (`fs`, `path`,
-  `child_process`, `crypto`), and access bindings via Hono's `c.env`.
-vendor: cloudflare
----
-
-# Cloudflare Worker & Hono Architect
-
-## Policy Capsule
-
-- Never import Node.js built-ins (`fs`, `path`, `child_process`, Node's `crypto`) in Worker code — they do not exist in the V8 isolate runtime.
-- Use the Web Crypto API for hashing, signing, and random bytes; do not reach for `node:crypto`.
-- Access bindings (env vars, R2 buckets, KV, Queues, D1) only through Hono's context (`c.env`), never through `process.env`.
-- Prefer Web platform APIs (`fetch`, `Request`, `Response`, `URLPattern`) over Node-flavored equivalents.
-- Treat any import that resolves to a Node-only polyfill as a hallucination — surface and remove it.
-
-**Description:** Prevents Node.js module hallucinations in edge environments.
-
-**Instruction:** The API is built with Hono and deployed to Cloudflare Workers
-(V8 Isolates).
-
-- YOU MUST NOT use standard Node.js built-ins (e.g., `fs`, `path`,
-  `child_process`).
-- If cryptography is needed, use the standard Web Crypto API, not Node's
-  `crypto`.
-- Access all environment variables, R2 buckets, and Queues strictly through the
-  Hono Context bindings (`c.env`).

package/.agents/skills/stack/backend/cloudflare-hono-architect/examples/route-template.ts

@@ -1,33 +0,0 @@
-import { zValidator } from '@hono/zod-validator';
-import { Hono } from 'hono';
-import { z } from 'zod';
-
-// EXAMPLE: Strict Cloudflare environment bindings
-type Bindings = {
-  DB: D1Database;
-  STRIPE_SECRET_KEY: string;
-  MY_QUEUE: Queue;
-};
-
-const app = new Hono<{ Bindings: Bindings }>();
-
-// EXAMPLE: Route with strict Zod validation and c.env access
-app.post(
-  '/api/example',
-  zValidator(
-    'json',
-    z.object({
-      title: z.string().min(1),
-    }),
-  ),
-  async (c) => {
-    const { title } = c.req.valid('json');
-    const _db = c.env.DB; // Access via Cloudflare bindings, NOT process.env
-
-    // Implementation here...
-
-    return c.json({ success: true, title }, 201);
-  },
-);
-
-export default app;

package/.agents/skills/stack/backend/cloudflare-queue-manager/SKILL.md

@@ -1,31 +0,0 @@
----
-name: cloudflare-queue-manager
-description:
-  Ensures idempotent and resilient background job execution on Cloudflare
-  Queues. Use when writing consumer handlers — design for at-least-once
-  delivery, wrap processing in try/catch with `message.retry()`, and order
-  cascading deletes so the database row drops last.
-vendor: cloudflare
----
-
-# Cloudflare Queue Lifecycle Manager
-
-## Policy Capsule
-
-- Design every consumer handler to be idempotent; assume at-least-once delivery and treat duplicate messages as expected.
-- Wrap message processing in `try/catch`; never let an unhandled throw kill the worker mid-batch.
-- Use `message.retry()` for transient failures rather than crashing the whole consumer.
-- For cascading deletions, delete third-party assets (Mux, R2, external APIs) first and the database row last to avoid orphans.
-- Log each message ID and processing outcome so retried duplicates are traceable across replays.
-
-**Description:** Ensures idempotent and resilient background job execution.
-
-**Instruction:** You are writing consumer logic for Cloudflare Queues.
-
-- Always assume messages can be delivered more than once; design all worker
-  logic for strict idempotency.
-- Wrap processing logic in `try/catch` blocks.
-- If a sub-task fails (e.g., deleting a video from a third-party API), do NOT
-  crash the whole worker. Log the error and use `message.retry()` strategically.
-- For cascading deletions, ensure the database deletion happens LAST, only after
-  third-party assets (Mux, R2) are confirmed deleted, to avoid orphaned data.

package/.agents/skills/stack/backend/cloudflare-workers/SKILL.md

@@ -1,51 +0,0 @@
----
-name: cloudflare-workers
-description:
-  Builds and deploys high-performance edge logic on Cloudflare Workers. Use
-  when working within Workers' 128MB memory and 5–50ms CPU constraints,
-  integrating KV/R2/D1 storage, or writing Wrangler-managed edge-first
-  request/response code.
-vendor: cloudflare
----
-
-# Skill: Cloudflare Workers
-
-## Policy Capsule
-
-- Respect the Worker resource envelope: 128MB memory and 5–50ms CPU per invocation; design code paths to fit inside it.
-- Configure and deploy via Wrangler; do not hand-roll deployment scripts.
-- Pick the right storage primitive: KV for simple key-value, R2 for object storage, D1 for relational data.
-- Use the standard Fetch API for outgoing HTTP; never reach for Node-flavored HTTP clients.
-- Store secrets with `wrangler secret`; never commit secrets to source.
-- Minimize sub-requests per invocation to stay under platform limits.
-- Stream large payloads via `TransformStream`; never buffer them entirely into memory.
-- Install a global error handler so a single failing request does not take down the worker.
-
-Guidelines for building and deploying high-performance serverless logic at the
-edge.
-
-## 1. Core Principles
-
-- **Edge First:** Run code as close to the user as possible.
-- **Resource Constraints:** Be mindful of the 128MB memory limit and the strict
-  CPU time limits (e.g., 5-50ms) for workers.
-- **Cold Starts:** Workers have near-zero cold starts, but external resource
-  initialization must be optimized.
-
-## 2. Technical Standards
-
-- **Routing:** Use `Wrangler` for configuration and local development.
-- **Storage Integration:** Use `KV` for simple key-value needs, `R2` for object
-  storage, and `D1` for relational data.
-- **Fetch API:** Always use the standard Fetch API for outgoing network
-  requests.
-- **Security:** Use `wrangler secret` for environment variables and API keys.
-
-## 3. Best Practices
-
-- **Sub-requests:** Minimize the number of sub-requests per worker invocation to
-  stay within limits.
-- **Streaming:** Use the `TransformStream` API for processing large payloads
-  without loading everything into memory.
-- **Error Handling:** Implement robust global error handlers to prevent total
-  worker failure on a single request error.

package/.agents/skills/stack/backend/highlevel-crm/SKILL.md

@@ -1,54 +0,0 @@
----
-name: highlevel-crm
-description:
-  Integrates with the HighLevel (GoHighLevel) CRM API v2 and its automation
-  engine. Use when synchronizing data via OAuth 2.0, building custom widgets,
-  handling sub-account `locationId` scoping, or implementing webhook-driven
-  workflows with rate-limit-aware retries.
-vendor: highlevel
----
-
-# Skill: HighLevel CRM (GoHighLevel)
-
-## Policy Capsule
-
-- Integrate with HighLevel exclusively through API v2 over OAuth 2.0; never hardcode credentials.
-- Manage `access_token` and `refresh_token` rotation in code — assume tokens expire and refresh proactively.
-- Include `locationId` on every API request to scope writes to the correct sub-account.
-- Prefer HighLevel's native automation engine; reach for custom code only when native workflows cannot express the requirement.
-- Implement exponential-backoff retry to respect HighLevel's API rate limits.
-- Use email as the primary key for contact deduplication; do not rely on CRM-internal IDs for cross-system joins.
-- Drive event-driven flows through HighLevel webhooks rather than polling.
-- Test integrations against a sandbox sub-account before pointing them at live data.
-
-Protocols for integrating with the HighLevel CRM API (v2) and building custom
-widgets/automations.
-
-## 1. Core Principles
-
-- **API-First Integration:** Use the HighLevel API v2 for all data
-  synchronization, focusing on OAuth 2.0 security.
-- **Workflow Automation:** Leverage HighLevel's internal automation engine
-  effectively; only use custom code when native workflows are insufficient.
-- **Data Integrity:** Ensure all custom fields, tags, and contacts are mapped
-  accurately to prevent data corruption.
-
-## 2. Technical Standards
-
-- **OAuth 2.0:** Securely manage `access_token` and `refresh_token` flows. Never
-  hardcode credentials.
-- **Webhooks:** Use webhooks to trigger application logic when events occur in
-  CRM (e.g., contact created, opportunity moved).
-- **Rate Limiting:** Implement exponential backoff and retry logic to respect
-  HighLevel's API rate limits.
-- **Location Context:** Always include the `locationId` in your API requests to
-  ensure data is scoped to the correct sub-account.
-
-## 3. Best Practices
-
-- **Custom Fields:** Use unique, descriptive names for custom fields and mapping
-  keys to avoid collisions.
-- **Contact Sync:** Use email addresses as the primary identifier for contact
-  deduplication.
-- **Testing:** Always use a sandbox/test sub-account in HighLevel before
-  deploying integrations to live accounts.

package/.agents/skills/stack/backend/sqlite-drizzle-expert/SKILL.md

@@ -1,29 +0,0 @@
----
-name: sqlite-drizzle-expert
-description:
-  Enforces SQLite dialect for Drizzle ORM and Turso (libSQL). Use when writing
-  schema or queries with `drizzle-orm/sqlite-core` — avoid PostgreSQL-only
-  types (`serial`, `jsonb`, `uuid`), use `text()` for IDs and dates, and
-  define relations explicitly via the `relations` API.
-vendor: drizzle
----
-
-# SQLite Drizzle Expert
-
-## Policy Capsule
-
-- Import only from `drizzle-orm/sqlite-core`; never mix in PostgreSQL or MySQL Drizzle modules.
-- Never use Postgres-only types (`serial`, `jsonb`, `uuid`) — SQLite does not implement them.
-- Use `text()` for IDs, enums, and date columns.
-- Use `integer({ mode: 'boolean' })` for booleans; SQLite has no native boolean type.
-- Define every relation explicitly with Drizzle's `relations` API rather than relying on implicit foreign-key inference.
-
-**Description:** Enforces SQLite dialect for Drizzle ORM and Turso.
-
-**Instruction:** You are modifying a Turso (libSQL) database using Drizzle ORM.
-You MUST strictly use `drizzle-orm/sqlite-core`.
-
-- NEVER use PostgreSQL-specific types like `serial`, `jsonb`, or `uuid`.
-- Use `text()` for IDs, Enums, and dates.
-- Use `integer({ mode: 'boolean' })` for booleans.
-- Ensure all relations are explicitly defined using Drizzle's `relations` API.

package/.agents/skills/stack/backend/sqlite-drizzle-expert/examples/schema-template.ts

@@ -1,30 +0,0 @@
-import { relations, sql } from 'drizzle-orm';
-import { integer, sqliteTable, text } from 'drizzle-orm/sqlite-core';
-
-// EXAMPLE: Standard SQLite table optimized for Turso
-export const users = sqliteTable('users', {
-  id: text('id').primaryKey(), // DO NOT use uuid() or serial()
-  email: text('email').notNull().unique(),
-  isActive: integer('is_active', { mode: 'boolean' }).default(true), // SQLite boolean workaround
-  createdAt: text('created_at').default(sql`CURRENT_TIMESTAMP`).notNull(),
-});
-
-export const posts = sqliteTable('posts', {
-  id: text('id').primaryKey(),
-  authorId: text('author_id')
-    .notNull()
-    .references(() => users.id, { onDelete: 'cascade' }),
-  content: text('content').notNull(),
-});
-
-// EXAMPLE: Explicit relations definition
-export const usersRelations = relations(users, ({ many }) => ({
-  posts: many(posts),
-}));
-
-export const postsRelations = relations(posts, ({ one }) => ({
-  author: one(users, {
-    fields: [posts.authorId],
-    references: [users.id],
-  }),
-}));