br4zz4:structure

Documents the br4zz4 monorepo workspace layout, project conventions, and script placement rules.

Updated May 25, 2025
One-click install
npx skills add https://github.com/oporpino/commons --skill br4zz4-structure-oporpino
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: br4zz4:structure
Source: https://github.com/oporpino/commons/tree/main/ai/shared/skills/br4zz4%3Astructure
Command: npx skills add https://github.com/oporpino/commons --skill br4zz4-structure-oporpino

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams working across multiple br4zz4 projects struggle to know where files belong — scripts, docs, makefiles, docker configs, and infrastructure all follow strict conventions that are easy to violate without a reference. ## Core Features & Use Cases - Workspace Layout Reference: Explains the br4zz4/ workspace, the .commons symlink, per-project layout, and multi-module modules/ structure. - File Placement Rules: Defines where scripts live (run/, tasks/, bin/, .commons/bin/), the closed set of .project/docs/ directories, and Makefile/compose.yml patterns. - Use Case: When creating a new project or adding a script, consult this Skill to decide whether it belongs in run/, tasks/, or .commons/shell/tasks/, and to follow the new-project checklist. ## Quick Start Ask where a new deployment script should live in a br4zz4 project and how to structure its Makefile and compose.yml.

Frequently Asked Questions about br4zz4:structure

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

FAQPage Schema
Where should I put a new script in a br4zz4 project?▼

Standard operations like server, test, and lint go in run/ as executable scripts. Project-specific tasks go in tasks/<domain>/<name>.sh, while generic scripts reused across projects belong in .commons/bin/ or .commons/shell/tasks/.

How does the .commons symlink work in br4zz4 projects?▼

Each project has a .commons symlink pointing to the shared commons repo, created via make commons.projects.symlink. It is tracked in git as a submodule pointer, so .commons/shell/tasks/ resolves to commons/shell/tasks/ in every project.

What directories are allowed inside .project/docs/?▼

The first level is a closed set: specs/, plans/, features/, learnings/, architecture/, guides/, reference/<scope>/, and rules/<scope>/, plus reserved files README.md, RULES.md, and modules.md. No other directories are valid at that level.

How are multi-module projects structured in br4zz4?▼

All modules live under modules/ at the root, each self-contained with its own manifest, .module/ metadata, and .infra/ directory. The project root holds only modules/, .project/, the .commons symlink, Makefile, compose.yml, and env files — never a root-level .infra/.

How does Makefile stack auto-detection work?▼

The _contract.mk file auto-detects the stack from file presence: Gemfile for Ruby, package.json for Node, mix.exs for Elixir, and pyproject.toml or requirements.txt for Python. The Makefile only needs to include the commons main.makefile.

Where do temporary files and backups go in br4zz4 projects?▼

All non-source artifacts like DB dumps, exports, and backups go under ./tmp at the project or module root, typically in timestamped subdirectories. The tmp/ directory is gitignored once, and bespoke backup folders are never created.