@oriro/orirocli 0.1.0

package/skills/technical/analytics-setup/SKILL.md

@@ -0,0 +1,125 @@
+---
+watermark: ORIRO
+name: analytics-setup
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+description: >
+
+  Analytics implementation — tracking setup, event design, funnel analysis, A/B testing, and data-driven product decisions.
+
+
+
+
+
+
+
+
+
+
+  Sources: Google Search Central, GDPR text, AWS security documentation, Stripe API docs.
+---
+
+# Analytics Implementation
+
+## Event tracking design
+
+### Naming convention
+
+```
+Object Action: user_signed_up, post_published, payment_completed, button_clicked
+```
+
+Consistent naming from day one. Inconsistency = unusable data at scale.
+
+### What to track
+
+**Product events:**
+
+- Acquisition: page_viewed (first session), signup_started, signup_completed, onboarding_step_completed
+- Activation: first_key_action (varies by product — first post created, first file uploaded, first transaction)
+- Retention: session_started, core_feature_used (daily/weekly)
+- Revenue: plan_selected, trial_started, subscription_created, payment_failed
+- Referral: share_clicked, invite_sent, referral_link_clicked
+
+**Don't track everything.** Track actions that matter. Every event that's not used is noise.
+
+## Implementation (Segment / Posthog)
+
+### Segment
+
+```ts
+// Track event
+analytics.track("post_published", {
+  userId: user.id,
+  postId: post.id,
+  category: post.category,
+  wordCount: post.wordCount,
+  publishedAt: new Date().toISOString(),
+});
+
+// Identify user
+analytics.identify(user.id, {
+  email: user.email,
+  plan: user.subscription.plan,
+  createdAt: user.createdAt,
+  company: user.company?.name,
+});
+```
+
+### PostHog (self-hosted or cloud)
+
+```ts
+import posthog from "posthog-js";
+
+// Initialize
+posthog.init(process.env.NEXT_PUBLIC_POSTHOG_KEY, {
+  api_host: process.env.NEXT_PUBLIC_POSTHOG_HOST,
+  loaded: (posthog) => {
+    if (process.env.NODE_ENV === "development") posthog.opt_out_capturing();
+  },
+});
+
+// Track
+posthog.capture("post_published", { postId: post.id, category: post.category });
+
+// Identify
+posthog.identify(userId, { email, plan });
+```
+
+## Funnel analysis
+
+```
+Signup page view → Form submitted → Email verified → Onboarding started → Onboarding completed → Core action taken → Subscription
+Step 1: 10,000 → Step 2: 5,000 (50%) → Step 3: 3,500 (70%) → Step 4: 2,800 (80%) → Step 5: 1,400 (50%) → Step 6: 840 (60%) → Step 7: 168 (20%)
+```
+
+Where is the biggest drop? That's where to focus.
+
+## A/B testing
+
+```ts
+// PostHog feature flags for A/B tests
+const variant = posthog.getFeatureFlag("checkout-cta-test");
+// variant = 'control' or 'test'
+
+// Show different UI based on variant
+const ctaText = variant === "test" ? "Start free trial" : "Get started";
+```
+
+**Don't peek at results early** — statistical significance requires adequate sample size.
+Calculate sample size before starting: need ~95% confidence, 80% power.
+
+## Key metrics by product type
+
+**SaaS:** DAU/WAU/MAU, DAU/MAU ratio (engagement), Activation rate, NRR.
+**E-commerce:** Conversion rate, Cart abandonment, Average order value, Return rate.
+**Content:** Page views, Time on page, Pages per session, Scroll depth, Return visitors.
+**Marketplace:** Liquidity (listings → transactions), GMV, Take rate, NPS both sides.
+
+## Data quality
+
+**Source of truth:** Agree on ONE definition for each metric. "Active user" must mean the same thing everywhere.
+**Validate tracking:** Use Segment debugger, PostHog event explorer, or browser console to verify events fire correctly.
+**Data warehouse:** Segment → Snowflake/BigQuery/Redshift for complex analysis, not just dashboards.
+
+Sources: Segment documentation (segment.com/docs — free), PostHog documentation (posthog.com/docs — free), Google Analytics 4 documentation (free)

package/skills/technical/api-builder/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 ORIRO.ai
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/technical/api-builder/SKILL.md

@@ -0,0 +1,202 @@
+---
+watermark: ORIRO
+name: api-builder
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+description: >
+  API design and development — REST, GraphQL, tRPC, versioning, authentication,
+  rate limiting, documentation, and API best practices. Activate for questions
+  about building APIs, designing endpoints, API versioning, API security,
+  or any API development question. Sources: OpenAPI specification, REST best
+  practices, GraphQL Foundation.
+---
+
+# API Design and Development
+
+## REST API design principles
+
+### Resource naming
+
+Resources are nouns, not verbs. HTTP methods provide the action.
+
+```
+✅  GET    /users              List users
+✅  POST   /users              Create user
+✅  GET    /users/{id}         Get user
+✅  PATCH  /users/{id}         Update user
+✅  DELETE /users/{id}         Delete user
+✅  GET    /users/{id}/posts   Get user's posts
+
+❌  GET    /getUsers
+❌  POST   /createUser
+❌  GET    /users/delete/{id}
+```
+
+Plural nouns for collections. Nested resources for clear ownership (max 2 levels deep).
+
+### HTTP status codes — use them correctly
+
+```
+200 OK              — Successful GET, PATCH, PUT
+201 Created         — Successful POST (include Location header)
+204 No Content      — Successful DELETE
+400 Bad Request     — Invalid input (validation errors)
+401 Unauthorized    — Not authenticated (no/invalid token)
+403 Forbidden       — Authenticated but lacks permission
+404 Not Found       — Resource doesn't exist
+409 Conflict        — State conflict (duplicate email, etc.)
+422 Unprocessable   — Validation failed (alternative to 400)
+429 Too Many Requests — Rate limit exceeded
+500 Internal Server Error — Unexpected server error (never expose details)
+```
+
+### Request and response design
+
+**Always return JSON with consistent structure:**
+
+```json
+// Success response
+{ "data": { "id": "123", "name": "Alice", "email": "alice@example.com" } }
+
+// Error response
+{
+  "error": {
+    "code": "VALIDATION_ERROR",
+    "message": "Invalid email address",
+    "field": "email"
+  }
+}
+
+// List response
+{
+  "data": [...],
+  "meta": { "total": 342, "page": 1, "limit": 20 }
+}
+```
+
+## Authentication
+
+### API Keys
+
+Simple, widely understood. Best for server-to-server.
+
+```
+Authorization: Bearer sk_live_abc123...
+X-API-Key: sk_live_abc123...
+```
+
+Store hashed in DB. Never log API keys.
+
+### JWT (JSON Web Tokens)
+
+```
+Header.Payload.Signature
+eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
+```
+
+Access token: short-lived (15 min). Refresh token: longer-lived (7-30 days), stored in httpOnly cookie.
+Never store access tokens in localStorage (XSS risk).
+
+### OAuth 2.0 flows
+
+Authorization Code + PKCE: For web/mobile apps. User redirected to provider.
+Client Credentials: For server-to-server (machine-to-machine).
+Never use Implicit flow (deprecated).
+
+## Rate limiting
+
+**Why:** Protect against abuse, DDoS, runaway clients.
+**Strategies:**
+Fixed window: Max N requests per hour. Simple but burst vulnerable.
+Sliding window: Better burst handling.
+Token bucket: Smooth rate limiting with burst allowance.
+
+**Headers to return:**
+
+```
+X-RateLimit-Limit: 1000
+X-RateLimit-Remaining: 997
+X-RateLimit-Reset: 1640000000
+Retry-After: 3600  (when rate limited)
+```
+
+**Implementation:** Redis `INCR` with expiry or `ZREMRANGEBYSCORE` for sliding window.
+
+## Versioning
+
+**URL versioning (most common):** `/api/v1/users`, `/api/v2/users`
+Clear, cacheable, easy to debug. Downside: URL redundancy.
+**Header versioning:** `Accept: application/vnd.api+json;version=2`
+**Query parameter:** `/api/users?version=2`
+
+**When to increment version:** Breaking changes only.
+Breaking: Removing/renaming fields, changing field types, changing behavior.
+Non-breaking: Adding optional fields, adding new endpoints.
+Support N-1 versions minimum. Deprecation notice before removal.
+
+## Validation and error handling
+
+**Validate at the boundary.** Don't let invalid data into your system.
+
+```ts
+import { z } from "zod";
+
+const CreateUserSchema = z.object({
+  email: z.string().email(),
+  name: z.string().min(1).max(100),
+  age: z.number().int().min(13).max(120).optional(),
+});
+
+// In route handler:
+const parsed = CreateUserSchema.safeParse(body);
+if (!parsed.success) {
+  return Response.json({ error: parsed.error.flatten() }, { status: 422 });
+}
+```
+
+## API documentation
+
+**OpenAPI/Swagger:** Industry standard. Machine-readable. Generates client SDKs, testing UIs.
+
+```yaml
+openapi: 3.0.0
+info:
+  title: My API
+  version: 1.0.0
+paths:
+  /users:
+    get:
+      summary: List users
+      parameters:
+        - in: query
+          name: limit
+          schema:
+            type: integer
+            default: 20
+      responses:
+        "200":
+          description: List of users
+```
+
+## GraphQL vs REST
+
+Use GraphQL when: Clients need flexible queries, multiple clients with different data needs, complex nested data, real-time subscriptions matter.
+Use REST when: Simple CRUD, caching is important, team is familiar, simpler debugging.
+GraphQL costs: N+1 query problem (use DataLoader), schema management overhead, complexity.
+
+## Webhooks
+
+Push model: You push events to subscriber's URL instead of subscriber polling.
+
+```
+POST https://customer-app.com/webhook
+Content-Type: application/json
+X-Signature: sha256=abc123...
+
+{ "event": "order.created", "data": { ... } }
+```
+
+**Security:** HMAC signature on payload. Customer verifies before processing.
+**Reliability:** Retry with exponential backoff. Idempotency keys so duplicates are safe.
+
+Sources: OpenAPI Specification (swagger.io/specification — free), REST API Design Rulebook principles (Richardson), Google API Design Guide (free), Stripe API design (excellent public example)

package/skills/technical/architecture-decisions/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 ORIRO.ai
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/technical/architecture-decisions/SKILL.md

@@ -0,0 +1,120 @@
+---
+watermark: ORIRO
+name: architecture-decisions
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+description: >
+
+
+
+
+
+  Architecture decision making — ADRs, monolith vs. microservices, build vs. buy, cloud selection, and making defensible technical decisions.
+
+
+
+
+
+
+  Sources: Google Search Central, GDPR text, AWS security documentation, Stripe API docs.
+---
+
+# Architecture Decision Making
+
+## Architecture Decision Records (ADRs)
+
+### Why document decisions
+
+Future engineers (including you in 6 months) will ask "why did they do it this way?"
+Without ADRs: Decisions get relitigated endlessly or silently changed.
+With ADRs: Context preserved. Decisions revisited consciously when circumstances change.
+
+### ADR template
+
+```markdown
+# ADR-001: Use PostgreSQL as Primary Database
+
+## Status
+
+Accepted (2024-01-15)
+
+## Context
+
+We need a primary database for the application. Team evaluates PostgreSQL vs. MongoDB vs. MySQL.
+
+## Decision
+
+We will use PostgreSQL 16.
+
+## Consequences
+
+**Positive:**
+
+- Strong ACID guarantees for financial transactions.
+- JSONB support for flexible data alongside relational.
+- Excellent ecosystem (Prisma, pgvector, PostGIS extensions).
+- Strong on-premise and cloud provider support.
+
+**Negative:**
+
+- Horizontal write scaling requires more complex setup (Citus, partitioning).
+- Schema migrations require careful management.
+
+## Alternatives considered
+
+**MongoDB:** Rejected. Our data is relational. Document model adds complexity.
+**MySQL:** Good option, PostgreSQL preferred for JSON support and extensions.
+```
+
+Store ADRs in `/docs/adr/` in your repository. Number sequentially.
+
+## Monolith vs. Microservices
+
+### Start monolith
+
+**For most products:** Monolith first, always.
+Microservices problems: Network latency, distributed transactions, deployment complexity, service discovery, observability, eventual consistency.
+Monolith benefits: Simple deployment, easy debugging, refactoring possible, no network calls for internal operations.
+
+**When to split:**
+
+- Team > 50 engineers struggling to coordinate deployments.
+- Specific service needs dramatically different scaling.
+- Compliance isolation required (e.g., payment processing).
+- Service owned by completely independent team.
+
+**Right migration path:**
+Modular monolith (internal modules with clean interfaces) → Extract module to service when justified.
+
+## Build vs. Buy decision matrix
+
+| Consideration              | Build                           | Buy                |
+| -------------------------- | ------------------------------- | ------------------ |
+| Core competitive advantage | ✅ Build                        | ❌ Avoid           |
+| Commodity functionality    | ❌ Wasteful                     | ✅ Buy             |
+| Team expertise             | Has it                          | Lacks it           |
+| Time to market             | Long                            | Short              |
+| Total cost                 | Long-term cheaper if high usage | Short-term cheaper |
+| Customization need         | High                            | Low                |
+
+**Rule:** Buy commodity infrastructure; build differentiated product.
+Buy: Auth (Clerk), payments (Stripe), email (Resend), observability (Datadog), queues (SQS).
+Build: your core product logic.
+
+## Cloud selection
+
+**AWS:** Broadest service catalog. Most enterprise-ready. Steeper learning curve.
+**GCP:** Best AI/ML services. Kubernetes (GKE). BigQuery for data.
+**Azure:** If your customers are Microsoft shops. Active Directory integration.
+**Vercel/Railway/Render:** For product teams who want to ship, not manage infrastructure.
+
+**Decision:** Use managed services wherever possible. Your value is in product, not infrastructure.
+
+## The scaling conversation
+
+**Pre-100 users:** Don't optimize for scale. Ship features.
+**100-10,000 users:** Add indexes, fix N+1 queries, add caching where hot.
+**10,000-100,000:** CDN, Redis caching, read replicas, optimize expensive queries.
+**100,000+:** Depends entirely on your architecture and bottlenecks. Measure first.
+
+Sources: Martin Fowler architecture patterns (martinfowler.com — free), Michael Nygard "Release It!" (principles), Designing Data-Intensive Applications (Kleppmann — principles), ADR GitHub organization (adr.github.io — free)

package/skills/technical/auth-security/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 ORIRO.ai
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.