monorepo-structure

Run build, test, lint, typegen, and install commands inside the correct sibling directory.

68|18|Updated Aug 12, 2025
One-click install
npx skills add https://github.com/DayMoonDevelopment/post-for-me --skill monorepo-structure-daymoondevelopment
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: monorepo-structure
Source: https://github.com/DayMoonDevelopment/post-for-me/tree/main/.agents/skills/monorepo-structure
Command: npx skills add https://github.com/DayMoonDevelopment/post-for-me --skill monorepo-structure-daymoondevelopment

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

post-for-me is organized as a non-workspace, "dumb monorepo" where each surface is a self-contained sibling with its own tooling. The iron rule requires every build, test, lint, typegen, and package command to run from inside the appropriate sibling, never from the repo root. Use BEFORE running any bun/npm/supabase/trigger/shadcn command, before installing or adding a dependency, before generating DB types, or whenever a skill or task says to "run X" without naming a directory. Reach for this guideline any time you're about to shell out a command in this repo and you're not certain which directory it belongs in, or when a root-level command fails with "no package.json / no lockfile / script not found" at the root.

Core Features & Use Cases

  • Self-contained siblings: Each surface (api/, trigger/, dashboard/, marketing/) owns its own package.json, scripts, dependencies, lockfile, node_modules, and CI surface.
  • Iron rule: All builds, tests, typegen, and install commands must be executed from within the corresponding sibling directory.
  • Guardrails: Reduces root-level errors by ensuring commands are executed in the proper directory and by documenting the workflow for uncertain commands.

Quick Start

Navigate to the appropriate sibling and run all commands there before installing dependencies or invoking root tooling.

Frequently Asked Questions about monorepo-structure

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why do npm or bun commands fail with no package.json errors in a monorepo?

Commands fail in a non-workspace monorepo because the root directory lacks a package.json. You must cd into the specific sibling directory, such as api or dashboard, to execute build, test, and install commands successfully.

How do I run scripts correctly in a non-workspace monorepo structure?

To run scripts correctly in a non-workspace monorepo, navigate into the appropriate sibling directory before executing shell commands. Each surface owns its own tooling, so running builds or linting from the root will cause missing script errors.

What is a dumb monorepo and how does it handle dependencies?

A dumb monorepo is a non-workspace structure where each surface is a self-contained sibling directory. Each sibling owns its own dependencies, lockfile, and CI surface, requiring you to install packages within the specific sibling rather than the root.

Where should I generate database types for a monorepo with sibling directories?

You should generate database types inside the specific sibling directory that requires them. Running typegen commands from the repo root fails, so always cd into the target sibling directory before invoking type generation tools.

Can I install a new dependency from the root of a dumb monorepo?

No, you cannot install dependencies from the root of a dumb monorepo. You must cd into the appropriate sibling directory, such as trigger or marketing, and run the install command there to update that specific surface's lockfile and node_modules.

When should I navigate into a sibling directory before running a command?

You should navigate into a sibling directory whenever you are preparing to run build, test, lint, typegen, or install commands. If a root-level command fails with no lockfile or script not found, move into the correct sibling directory.