@oriro/orirocli 0.1.0

package/skills/technical/product-management/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/product-management/SKILL.md

@@ -0,0 +1,94 @@
+---
+watermark: ORIRO
+name: product-management
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+description: >
+  Product management — product discovery, prioritization, roadmaps, user research,
+  metrics, and the product development process. Activate for questions about
+  product strategy, writing PRDs, prioritization, user research, product metrics,
+  roadmaps, or any product management question. Sources: SVPG, Intercom PM content.
+---
+
+# Product Management
+
+## What product managers do
+
+PMs sit at the intersection of business, technology, and user experience.
+**Core responsibilities:** Define what to build and why. Prioritize ruthlessly. Align stakeholders. Measure outcomes.
+PMs don't manage engineers. They manage the product and the product process.
+
+## Product discovery
+
+### Understanding users
+
+**User interviews:** Talk to users weekly. 30-minute sessions. Ask about problems, not solutions.
+"Tell me about the last time you tried to do X" beats "Would you use a feature that does Y?"
+**Jobs to be Done:** What 'job' is the user 'hiring' your product to do?
+"When I [situation], I want to [motivation], so I can [expected outcome]."
+**5 Whys:** Drill to root cause of user problems. First answer is rarely the real problem.
+
+### Validation techniques
+
+**Fake door test:** Add a button for a feature before building it. Measure clicks. If nobody clicks, don't build.
+**Concierge MVP:** Manually fulfill the service before building automation.
+**Smoke test:** Landing page for unbuilt product. Measure signups. Ship only if demand confirmed.
+
+## Prioritization frameworks
+
+### RICE Score
+
+Reach × Impact × Confidence / Effort
+**Reach:** How many users in a time period?
+**Impact:** How much will it move the needle? (3=massive, 2=significant, 1=minimal, 0.5=low, 0.25=minimal)
+**Confidence:** How sure are you? (100%=high, 80%=medium, 50%=low)
+**Effort:** Person-months
+
+### ICE Score
+
+Impact × Confidence × Ease (simpler, similar)
+
+### MoSCoW
+
+Must have / Should have / Could have / Won't have (for this release)
+
+## Writing good requirements
+
+**User story format:** "As a [user type], I want to [action] so that [benefit]."
+
+**Full PRD minimum structure:**
+
+1. Problem statement: What problem are we solving? For whom?
+2. Success metrics: How will we know this worked?
+3. User stories with acceptance criteria
+4. Out of scope (explicit)
+5. Dependencies
+6. Open questions
+
+**Acceptance criteria (Given/When/Then):**
+"Given I am on the checkout page, When I enter an invalid card number, Then I see an error message explaining the issue."
+
+## Product metrics
+
+**North Star Metric:** The one metric that best captures delivered value.
+Airbnb: Nights booked. Spotify: Time spent listening. Slack: Messages sent.
+**Input metrics (leading):** Actions that drive the North Star. Controllable.
+**Output metrics (lagging):** Revenue, retention. Outcomes of input metric success.
+**Guardrails:** Metrics you must NOT harm while improving North Star.
+
+## Roadmap strategy
+
+**What a roadmap IS NOT:** A commitment to ship specific features on specific dates.
+**What it IS:** Current best understanding of direction, expected to change.
+**Now / Next / Later:** Concrete (Now), directional (Next), aspirational (Later).
+**Theme-based roadmaps:** Solve the "Improve checkout experience" problem vs. "Add PayPal." Problems age better than solutions.
+**Always share 'why':** Context prevents roadmap debates becoming feature debates.
+
+## Working with engineering
+
+**Estimation:** See scope-estimation skill. Involve engineers early, not after spec is written.
+**Definition of Done:** Agreed upfront. Acceptance testing. Performance benchmarks. Documentation.
+**Discovery alongside delivery:** Dual-track. Product discovers next sprint's work while engineers build current sprint.
+**Respect technical constraints:** PMs who over-promise ship faster and break more. Better: "Tell me the constraint; let's find another path."
+
+Sources: SVPG (svpg.com — free articles), Lenny Rachitsky newsletter (partial free), Reforge (limited free), Intercom Product Blog (free), Mind the Product (free)

package/skills/technical/saas-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/saas-builder/SKILL.md

@@ -0,0 +1,138 @@
+---
+watermark: ORIRO
+name: saas-builder
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+description: >
+  SaaS product development — multi-tenancy, subscription billing, onboarding, feature flags, and SaaS architecture patterns.
+
+
+
+
+
+  Sources: Stripe docs, Anthropic docs, Sanity/Contentful docs, industry-specific technical resources.
+---
+
+# SaaS Product Development
+
+## Multi-tenancy architecture
+
+### Models
+
+**Single database, shared schema:** All tenants in same tables. `tenant_id` column on every table. Simplest. RLS (Row-Level Security) enforces isolation.
+**Database per tenant:** Full isolation. More complex. Higher cost. Required for data residency requirements.
+**Schema per tenant (PostgreSQL):** Middle ground. Isolated but in same database.
+
+### Row Level Security (PostgreSQL)
+
+```sql
+ALTER TABLE posts ENABLE ROW LEVEL SECURITY;
+CREATE POLICY tenant_isolation ON posts
+  USING (tenant_id = current_setting('app.tenant_id')::uuid);
+```
+
+Set `app.tenant_id` in your connection before queries. Postgres enforces the policy.
+
+### Tenant resolution
+
+**Subdomain:** `acme.yourapp.com` → tenant = acme. Common for B2B.
+**URL path:** `yourapp.com/org/acme` → tenant from URL.
+**Custom domain:** `app.acme.com` → custom domain mapped to tenant in DB.
+
+```ts
+// Middleware for subdomain resolution
+function getTenantFromRequest(req: Request): string {
+  const host = req.headers.get("host") ?? "";
+  const subdomain = host.split(".")[0];
+  if (subdomain && subdomain !== "www" && subdomain !== "app") return subdomain;
+  return req.headers.get("x-tenant-id") ?? ""; // fallback for custom domains
+}
+```
+
+## Subscription billing (Stripe)
+
+### Products and prices
+
+```ts
+// Create product and price in Stripe
+const product = await stripe.products.create({ name: "Pro Plan" });
+const price = await stripe.prices.create({
+  product: product.id,
+  unit_amount: 2900, // $29.00 in cents
+  currency: "usd",
+  recurring: { interval: "month" },
+});
+```
+
+### Checkout flow
+
+```ts
+// Create checkout session
+const session = await stripe.checkout.sessions.create({
+  customer_email: user.email,
+  payment_method_types: ["card"],
+  line_items: [{ price: priceId, quantity: 1 }],
+  mode: "subscription",
+  success_url: `${baseUrl}/dashboard?session_id={CHECKOUT_SESSION_ID}`,
+  cancel_url: `${baseUrl}/pricing`,
+  metadata: { userId: user.id },
+});
+return redirect(session.url);
+```
+
+### Webhook handling (always verify signature)
+
+```ts
+app.post("/webhooks/stripe", express.raw({ type: "application/json" }), async (req, res) => {
+  const sig = req.headers["stripe-signature"];
+  let event;
+  try {
+    event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);
+  } catch (err) {
+    return res.status(400).send(`Webhook Error: ${err.message}`);
+  }
+
+  switch (event.type) {
+    case "customer.subscription.created":
+    case "customer.subscription.updated":
+      await syncSubscription(event.data.object);
+      break;
+    case "customer.subscription.deleted":
+      await cancelSubscription(event.data.object.customer);
+      break;
+    case "invoice.payment_failed":
+      await handlePaymentFailure(event.data.object);
+      break;
+  }
+  res.json({ received: true });
+});
+```
+
+## Feature flags
+
+```ts
+// Simple feature flag check
+function isFeatureEnabled(feature: string, user: User): boolean {
+  // Check: override table → plan features → percentage rollout
+  const override = featureOverrides[user.id]?.[feature];
+  if (override !== undefined) return override;
+
+  const planFeatures = planConfig[user.subscription.plan];
+  if (feature in planFeatures) return planFeatures[feature];
+
+  return defaultFeatures[feature] ?? false;
+}
+```
+
+For production: LaunchDarkly, Unleash (self-hosted), or Statsig.
+
+## SaaS metrics to track
+
+- MRR/ARR, MRR movements (new/expansion/contraction/churn)
+- Churn rate (customer and revenue)
+- NRR (Net Revenue Retention)
+- CAC and LTV by acquisition channel
+- Feature adoption rates
+- Time to value (time from signup to first meaningful action)
+
+Sources: Stripe documentation (stripe.com/docs — free), PGTune (for PostgreSQL config), Christoph Nakazawa SaaS patterns

package/skills/technical/scope-estimation/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/scope-estimation/SKILL.md

@@ -0,0 +1,99 @@
+---
+watermark: ORIRO
+name: scope-estimation
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+description: >
+
+
+
+
+
+
+
+  Engineering scope estimation — breaking down work, estimating complexity, communicating uncertainty, and avoiding common estimation traps.
+
+
+
+
+  Sources: Google Search Central, GDPR text, AWS security documentation, Stripe API docs.
+---
+
+# Engineering Scope Estimation
+
+## Why estimation is hard
+
+**Hofstadter's Law:** It always takes longer than you expect, even when you take into account Hofstadter's Law.
+**Core problem:** You're estimating work that's never been done before. If it had been done before, you wouldn't need to estimate.
+**Uncertainty types:** Technical uncertainty (how to build it), scope uncertainty (what exactly), dependency uncertainty (what else needs to happen).
+
+## The three-point estimation method
+
+Don't give a single number. Give a range.
+**Optimistic (O):** Best case — everything goes right.
+**Most Likely (M):** Normal case — some issues encountered.
+**Pessimistic (P):** Worst case — major problems arise.
+
+PERT estimate: (O + 4M + P) / 6
+Standard deviation: (P - O) / 6
+
+Example: Feature estimate
+O = 3 days, M = 5 days, P = 12 days
+PERT = (3 + 20 + 12) / 6 = 5.8 days ≈ 6 days
+σ = (12 - 3) / 6 = 1.5 days
+90% confidence interval: ~6 ± 2.5 days = 3.5 to 8.5 days
+
+**Communicate the range:** "This will take 5-8 days, with 90% confidence."
+
+## Breaking down work
+
+**The 2-day rule:** No task should be estimated longer than 2 days. If it is, break it down further.
+**Tasks must be verifiable:** "Implement auth" is not a task. "Implement JWT login endpoint that returns access and refresh tokens" is a task.
+
+**Decomposition framework:**
+
+1. Design/planning (often underestimated): ER diagram, API design, state machine.
+2. Core implementation: The main feature work.
+3. Error handling and edge cases (often 30% of total).
+4. Tests: Unit, integration, E2E.
+5. Documentation: Code comments, API docs, README updates.
+6. Code review and feedback incorporation.
+7. Deployment and verification.
+
+**Missing from most estimates:**
+
+- Integration work (connecting to other services)
+- Security considerations (auth, input validation, rate limiting)
+- Logging and observability
+- Performance optimization to meet SLA
+- Edge cases (what happens when X is null? When the network fails?)
+
+## Common estimation traps
+
+**The planning fallacy:** Optimism bias. People consistently underestimate time.
+**Fix:** Reference class forecasting. How long did similar past tasks actually take?
+
+**Anchoring:** First estimate mentioned becomes anchor. People adjust insufficiently from anchor.
+**Fix:** Estimate independently before sharing. Reveal simultaneously (planning poker).
+
+**Scope creep acceptance:** Saying yes to small additions without resetting estimate.
+**Fix:** Any change to scope = new estimate or explicit acknowledgment of trade-offs.
+
+**Integration tax:** Connecting two systems always takes longer than expected.
+**Rule:** Add 30% to any estimate involving integration with external systems.
+
+## Communicating estimates
+
+**Confidence levels:**
+High confidence (well-understood work): ±25%
+Medium confidence (some unknowns): ±50%
+Low confidence (significant unknowns): ±100%
+
+**What to say:**
+"Based on what I understand, this will take X days. My confidence level is [high/medium/low] because [reason]. The main unknowns are [X, Y, Z]. If we discover [major risk], the estimate could increase to [worst case]."
+
+**What NOT to commit to:**
+Exact dates when you have significant unknowns.
+"We can definitely finish by [date]" when you're already behind.
+
+Sources: McConnell "Software Estimation: Demystifying the Black Art" (principles), Steve McConnell cone of uncertainty, PERT estimation method (USAF, public domain), Kahneman planning fallacy research

package/skills/technical/secrets-management/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/secrets-management/SKILL.md

@@ -0,0 +1,135 @@
+---
+watermark: ORIRO
+name: secrets-management
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+description: >
+
+
+
+
+
+
+
+
+
+  Secrets and configuration management — environment variables, secret stores, rotation, and security best practices for credentials.
+
+
+  Sources: Google Search Central, GDPR text, AWS security documentation, Stripe API docs.
+---
+
+# Secrets and Configuration Management
+
+## The non-negotiable rules
+
+**Never commit secrets to version control.** Ever.
+**Never log secrets.** Logs are often less secured than applications.
+**Never put secrets in URLs.** They appear in server logs, browser history, Referer headers.
+**Rotate secrets regularly.** Especially after any potential exposure.
+
+### .gitignore baseline
+
+```
+.env
+.env.local
+.env.*.local
+*.pem
+*.key
+service-account.json
+*-credentials.json
+```
+
+## Environment variables (baseline)
+
+### Local development
+
+```bash
+# .env.local (not committed)
+DATABASE_URL="postgresql://localhost:5432/myapp_dev"
+STRIPE_SECRET_KEY="sk_test_..."  # Always use test keys locally
+ANTHROPIC_API_KEY="sk-ant-..."
+JWT_SECRET="development-secret-change-in-production"
+```
+
+### Production environments
+
+**Platform env vars:** Vercel, Railway, Render, Heroku — set in dashboard. Never exposed in code.
+**Validate on startup:**
+
+```ts
+// lib/env.ts — fail fast if required secrets missing
+import { z } from "zod";
+
+const envSchema = z.object({
+  DATABASE_URL: z.string().url(),
+  STRIPE_SECRET_KEY: z.string().startsWith("sk_"),
+  ANTHROPIC_API_KEY: z.string().startsWith("sk-ant-"),
+  JWT_SECRET: z.string().min(32),
+  NODE_ENV: z.enum(["development", "production", "test"]).default("development"),
+});
+
+export const env = envSchema.parse(process.env);
+// If any required variable missing: throws at startup with clear error
+```
+
+## Secret stores (for scale)
+
+### HashiCorp Vault
+
+Open source or cloud. Centralized secret storage with access control, rotation, audit logs.
+
+```bash
+# Store secret
+vault kv put secret/myapp/prod stripe_key=sk_live_...
+
+# Read secret
+vault kv get -field=stripe_key secret/myapp/prod
+```
+
+### Cloud provider secret managers
+
+**AWS Secrets Manager:** Native AWS. Auto-rotation. IAM-controlled access.
+**GCP Secret Manager:** Native GCP. IAM-controlled. Versioned.
+**Azure Key Vault:** Native Azure. Hardware security module option.
+
+```ts
+// GCP Secret Manager (example)
+import { SecretManagerServiceClient } from "@google-cloud/secret-manager";
+
+const client = new SecretManagerServiceClient();
+
+async function getSecret(secretName: string): Promise<string> {
+  const name = `projects/${projectId}/secrets/${secretName}/versions/latest`;
+  const [version] = await client.accessSecretVersion({ name });
+  return version.payload!.data!.toString();
+}
+```
+
+## Secret rotation
+
+### Rotation strategy
+
+1. Create new secret value.
+2. Update secret store.
+3. Redeploy application(s) reading the new value.
+4. Verify new value works.
+5. Revoke old value.
+
+**For API keys:** Create new key in provider → deploy new key → verify → revoke old.
+**For database passwords:** Most cloud databases support rotation without downtime via a rotation Lambda/function.
+
+### When to rotate
+
+- Immediately: Key exposed (committed to git, sent in Slack/email, logged).
+- Regularly: Every 90 days for high-value secrets. Some compliance frameworks require this.
+- On personnel change: When engineer with access leaves.
+
+## Service accounts and access control
+
+**Principle of least privilege:** Each service gets only the permissions it needs. Nothing more.
+**Separate credentials per environment:** Production DB never uses same credentials as development.
+**No shared credentials:** Each service has its own API key. If one is compromised, others aren't.
+**Audit access:** Log who accessed what secret and when (built into Vault, AWS Secrets Manager, GCP Secret Manager).
+
+Sources: HashiCorp Vault documentation (vaultproject.io — free), AWS Secrets Manager docs (free), GCP Secret Manager docs (free), OWASP Secrets Management Cheat Sheet (free)

package/skills/technical/seo-technical/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.