Merge branch 'develop'

Author: DominusKelvin

skills/the-algorithm/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: the-algorithm
+description: >
+  Product-building operating system inspired by Elon Musk's five-step "The Algorithm" —
+  question every requirement, delete nonessential work, simplify what remains, accelerate feedback loops,
+  and automate last. Use this skill when shaping offers, features, onboarding, pricing, architecture,
+  workflow, launch, or automation decisions in The Boring JavaScript Stack. Tailored for founders,
+  designers, operators, product engineers, and AI coding agents building real products.
+metadata:
+  author: sailscastshq
+  version: '1.0.0'
+  tags: the-algorithm, product-strategy, mvp, scope, architecture, simplification, delivery, automation, boring-stack
+---
+
+# The Algorithm
+
+The Algorithm is a subtraction-first way to build products. Its value for builders is not the factory metaphor. It is the sequence:
+
+1. prove the requirement
+2. remove unnecessary work
+3. simplify the surviving path
+4. speed up learning and delivery
+5. automate only after the flow is stable
+
+In The Boring JavaScript Stack, this usually means resisting extra layers and extra surfaces:
+
+- no extra API when a Sails action can render an Inertia page directly
+- no client state system when the database and page props are enough
+- no queue, socket, cache, search service, or microservice until the product truly needs it
+- no second or third pricing idea before the first one proves itself
+- no AI automation over a workflow humans do not yet understand
+
+## When to Use
+
+Use this skill when:
+
+- shaping an MVP, offer, feature spec, onboarding flow, pricing flow, internal tool, or launch plan
+- reviewing a bloated plan and deciding what to cut before implementation
+- deciding how narrow the first version should be
+- simplifying positioning, product promise, or distribution flow
+- choosing whether a page, action, helper, model, queue, websocket, or integration should exist
+- deciding whether to build a public API, background job, realtime feature, or custom client state layer
+- simplifying a tangled React, Vue, or Svelte experience into one clear happy path
+- improving cycle time for prototyping, testing, QA, feedback, and release
+- deciding what should stay manual, what should become a checklist, and what is ready for automation
+- steering an AI coding agent away from premature complexity and toward product outcomes
+- applying discipline to vibe coding so speed does not outrun judgment
+
+## Default Biases
+
+When this skill is active, bias toward:
+
+- one primary actor before many roles
+- one painful job before many adjacent jobs
+- one obvious path before many options
+- one source of truth before mirrored state
+- one vertical slice before broad platform work
+- one manual proof before a permanent automation
+
+## Rules
+
+Read the rule files that match the decision you are making:
+
+- [rules/five-steps.md](rules/five-steps.md) - The five-step sequence translated from manufacturing into builder and product work
+- [rules/product-shaping.md](rules/product-shaping.md) - Applying the algorithm from problem selection through offer, MVP scope, UX, pricing, distribution, and launch
+- [rules/boring-stack-decisions.md](rules/boring-stack-decisions.md) - How to use the algorithm to choose the simplest fitting architecture in this stack
+- [rules/feedback-loops.md](rules/feedback-loops.md) - How to accelerate learning, validation, testing, and release without speeding up waste
+- [rules/automation-last.md](rules/automation-last.md) - What is actually ready for automation, and what should remain manual for now
+- [rules/review-prompts.md](rules/review-prompts.md) - Reusable questions for planning, code review, roadmap pruning, and agent prompts

skills/the-algorithm/metadata.json

@@ -0,0 +1,14 @@
+{
+  "version": "1.0.0",
+  "organization": "Sailscasts",
+  "date": "March 2026",
+  "abstract": "Product-building skill inspired by Elon Musk's five-step Algorithm and adapted for The Boring JavaScript Stack. Covers requirement scrutiny, deletion-first scope shaping, simplification of offers, products, architecture, and operations, faster feedback loops, and automation-last guidance for founders and builders using Sails.js, Inertia.js, Waterline, Tailwind CSS, Sounding, Quest, Realtime, and related stack capabilities.",
+  "references": [
+    "https://bookshop.org/p/books/the-algorithm-the-hypergrowth-formula-that-transformed-tesla-lululemon-general-motors-and-spacex-jonathan-mcneill/3aa79740e551c321",
+    "https://www.penguin.co.uk/books/475948/the-algorithm-by-mcneill-jon/9781529986617",
+    "https://www.businessinsider.com/elon-musk-tesla-manufacturing-algorithm-delete-automate-isaacson-biography-2023-9",
+    "https://www.wsj.com/business/autos/elon-musk-tesla-space-book-excerpt-654eda83",
+    "https://www.axios.com/2026/03/30/elon-musk-openai-altman-anthropic",
+    "https://docs.sailscasts.com/boring-stack"
+  ]
+}

skills/the-algorithm/rules/automation-last.md

@@ -0,0 +1,82 @@
+---
+name: automation-last
+description: Deciding what is ready for automation and what should remain manual for now
+metadata:
+  tags: automation, ai, agents, ci, jobs, scripts, operations
+---
+
+# Automation Last
+
+Automation is a multiplier. It multiplies clarity when the workflow is sound, and multiplies confusion when it is not.
+
+## What Is Ready to Automate
+
+A workflow is ready when:
+
+- people can describe the exact trigger
+- the inputs are consistent
+- the outputs are recognizable
+- the manual version has already succeeded repeatedly
+- edge cases are known enough to handle or escalate
+- somebody owns the failures
+
+If those conditions are missing, automate later.
+
+## Good Automation Targets
+
+Strong candidates:
+
+- running stable test suites in CI
+- repeatable setup and scaffolding
+- deterministic formatting and linting
+- scheduled jobs with clear retries and alerts
+- transactional emails tied to well-defined events
+- lifecycle messages tied to proven product moments
+- support or ops checklists that already exist in human form
+- AI assistance on bounded tasks with review points
+
+## Bad Automation Targets
+
+Avoid automating:
+
+- a signup or onboarding flow that is still being redesigned
+- a sales workflow you still cannot explain clearly
+- a content engine around a message that has not landed yet
+- requirements gathering when the problem is still fuzzy
+- prompts that produce unstable business logic
+- alerting without clear response ownership
+- flaky tests
+- workflows with unresolved policy or compliance questions
+
+Automating a broken process does not create leverage. It creates a faster failure mode.
+
+## AI and Agent Guidance
+
+AI is still automation. Treat it with the same discipline.
+
+Before delegating to an agent, ask:
+
+- Is the task concrete and bounded?
+- Do we know what good output looks like?
+- Can a human review the result quickly?
+- Will the task still exist next month, or are we automating temporary confusion?
+
+Use AI after the human workflow is legible, not instead of making it legible.
+
+## Boring Stack Examples
+
+Examples that often belong late, not early:
+
+- background jobs with `quest`
+- realtime fanout with `realtime`
+- aggressive caching layers
+- custom generators and codegen
+- autonomous content or support agents
+
+Examples that often belong earlier once stable:
+
+- Sounding in CI
+- migration scripts
+- deployment scripts
+- mail templates for known events
+- billing webhooks for confirmed payment flows

skills/the-algorithm/rules/boring-stack-decisions.md

@@ -0,0 +1,83 @@
+---
+name: boring-stack-decisions
+description: Using the Algorithm to choose the simplest fitting architecture in The Boring JavaScript Stack
+metadata:
+  tags: boring-stack, sails, inertia, architecture, waterline, quest, realtime, payments
+---
+
+# Boring Stack Decisions
+
+This stack already encodes several deletion-first opinions. Use them before inventing new layers.
+
+## Default Architecture Bias
+
+Prefer this sequence:
+
+1. Sails action receives the request
+2. helper contains reusable business logic when needed
+3. Waterline persists the truth
+4. Inertia renders the page with server-provided props
+5. Tailwind styles the interface
+
+Reach for extra infrastructure only when the product requirement clearly demands it.
+
+## What to Delete First
+
+When a plan feels heavy, try removing:
+
+- a separate API layer for page-first product work
+- duplicated validation split across many places
+- client-side state that mirrors server truth
+- custom data-fetching wrappers around straightforward Inertia flows
+- a background job for something that is fast enough inline
+- realtime updates for information users can refresh
+- a queue, cache, or search service added for anticipated scale
+- a new package when the platform or stack already covers it
+
+## Architecture Questions by Layer
+
+### Page and Request Flow
+
+Ask:
+
+- Can this be one page and one action instead of a wizard or mini-app?
+- Can the server compute this and send it as props?
+- Can the successful path be a redirect instead of local mutation choreography?
+
+### Domain Logic
+
+Ask:
+
+- Does this logic belong in a helper instead of a controller branch?
+- Can two helpers become one clearer helper with better naming?
+- Are we modeling business rules, or just compensating for a confusing UI?
+
+### Data Model
+
+Ask:
+
+- Can one table or association replace multiple coordination structures?
+- Do we really need this status field, or can the state be derived?
+- Are we storing a source of truth or a cached convenience copy?
+
+### Frontend State
+
+Ask:
+
+- Is this truly client-owned state, or should it come from the server?
+- Can `useForm` or page props replace a custom store?
+- Does this state need to survive reloads, or is it ephemeral UI?
+
+## Add Complexity Only on Proof
+
+Use the existing skills when the answer is yes:
+
+- `authentication` when the product truly needs richer auth flows
+- `payments` when billing becomes a real requirement
+- `email` when transactional email is part of the core product loop
+- `quest` when work is slow, retryable, or scheduled
+- `realtime` when live updates materially change value
+- `durable-ui` when state genuinely belongs in the browser or URL
+- `testing` when faster confidence requires stronger trials
+
+The burden of proof is on the new layer, not on the boring default.

skills/the-algorithm/rules/feedback-loops.md

@@ -0,0 +1,69 @@
+---
+name: feedback-loops
+description: Accelerating learning, validation, testing, and release without speeding up waste
+metadata:
+  tags: cycle-time, feedback, testing, prototyping, release, instrumentation
+---
+
+# Feedback Loops
+
+Cycle time is how long it takes to learn whether your decision was right. Faster feedback is valuable only after the work itself is small and clean.
+
+## Shorten the Proof Path
+
+Prefer the fastest proof that can kill or confirm the idea:
+
+1. written hypothesis
+2. static mock or page stub
+3. local end-to-end happy path
+4. request-level trial
+5. browser trial
+6. beta user interaction
+7. production telemetry
+
+Do not start at level 7 when level 3 would answer the question.
+
+## Accelerate Product Delivery
+
+Reduce batch size:
+
+- ship vertical slices instead of parallel subsystems
+- keep pull requests narrow
+- make acceptance criteria visible
+- test the critical path first
+- stage rollout when risk is uneven
+
+The goal is not maximum activity. It is minimum time between decision and evidence.
+
+## Accelerate the Local Loop in This Stack
+
+Use the stack's natural fast paths:
+
+- render the page with Inertia before building cross-page state machinery
+- verify behavior with Sounding request trials before reaching for browser tests
+- capture mail locally before integrating a live provider
+- use fixtures, factories, and focused scenarios instead of giant seed states
+- reproduce bugs with the smallest failing page, action, helper, or model path
+
+## Measure the Right Things
+
+Faster loops need clear signals.
+
+Track:
+
+- time to first user success
+- completion rate of the main flow
+- time from bug report to reproduced case
+- time from change to deployed validation
+- support questions per new feature
+
+Avoid vanity acceleration like faster builds for features nobody should have built.
+
+## Review Loop Questions
+
+Ask:
+
+- What is the smallest end-to-end slice that proves this matters?
+- What evidence can we gather this week instead of next month?
+- Which test gives us the fastest honest confidence?
+- Are we speeding up the right thing, or just making motion look productive?