danielletto2020/vibe-rules

Purpose and delivery model

vibe-rules is a Claude Code marketplace repository delivering composable engineering-standard plugins. It combines path-scoped written rules with executable hooks (“locks”) that block or escalate risky actions. Marketplace discovery begins at .claude-plugin/marketplace.json; each installable unit is independently declared, for example plugins/std-core/.claude-plugin/plugin.json.

Primary entry points

Users install std-core, then invoke Claude commands for project lifecycle: setup, update, diagnostics, and project-local rules. Command definitions are plugins/std-core/commands/setup.md, plugins/std-core/commands/update.md, and plugins/std-core/commands/doctor.md. The setup implementation is shell-based (plugins/std-core/scripts/std-setup.sh) and detects a target repository’s technology, configures plugins/settings, links rules, and preserves explicit profile/manual choices on repeat runs.

Module architecture and rule loading

The repository is a catalog of technology and process modules: core enforcement, quality gates, policy, language/framework rules, messaging, data stores, and operations. Modules keep manifests beside path-triggered rule documents, e.g. plugins/std-js-typescript/.claude-plugin/plugin.json and plugins/std-js-typescript/rules/20-boundaries.md; plugins/std-sql-postgres/rules/10-migrations.md is another domain example. Rules are linked into the consumer project because Claude plugins do not natively distribute .claude/rules; plugins/std-core/scripts/std-link.sh resolves plugin locations dynamically after updates.

Core enforcement boundary

std-core supplies hooks and shell guards that execute independently of model compliance. Hook registration is at plugins/std-core/hooks/hooks.json; major enforcement scripts include plugins/std-core/scripts/guard-bash.sh, plugins/std-core/scripts/guard-secrets.sh, and plugins/std-core/scripts/guard-infra.sh. These form a boundary around tool use: destructive shell operations, secret exposure, protected infrastructure/configuration edits, dependency changes, and test changes are denied or require escalation. They are safeguards rather than a sandbox; real isolation is delegated to a development container template at templates/devcontainer/compose.yml.

Contextual standardization flow

Rules load according to timing and file paths rather than as one global prompt. After edits, plugins/std-core/scripts/rules-recheck.sh identifies applicable modules and prompts review of the changed file within edit scope. For new files, plugins/std-core/scripts/code-siblings.sh finds comparable project files to establish local conventions. Session-level validation is handled by plugins/std-core/scripts/session-check.sh; this detects broken links and missing prerequisites such as jq rather than silently disabling protection.

Quality-gate pipeline

std-gauntlet is an optional, independently installable quality system: specification → independently derived tests → mutation testing → metrics/diff coverage → human review items. Its execution orchestrator is plugins/std-gauntlet/scripts/gauntlet.sh, invoked through plugins/std-gauntlet/commands/run.md. It maintains non-regressing quality/debt thresholds through plugins/std-gauntlet/scripts/ratchet.sh; plugins/std-gauntlet/scripts/guard-commit.sh prevents commits after source changes invalidate the last successful gate run. Profiles and lifecycle choices originate in plugins/std-core/profiles/profiles.json.

Organization policy and repository validation

std-policy optionally evaluates a private organization-supplied policy without publishing its contents; enforcement is plugins/std-policy/scripts/guard-policy.sh, and the public schema example is plugins/std-policy/configs/policy.example.json. Repository CI runs GitHub Actions from .github/workflows/validate.yml, backed by tests/run.sh. Tests validate module metadata, hook decisions, secret handling, profiles, links, gates, and publishing behavior. Releases are performed by tools/publish.sh, with version work in tools/bump.sh.