repo-guardrails

Enforce repository architecture boundaries and artifact placement rules during code reviews.

Updated Apr 3, 2026
One-click install
npx skills add https://github.com/YunosukeYoshino/harness --skill repo-guardrails
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: repo-guardrails
Source: https://github.com/YunosukeYoshino/harness/tree/main/.claude/skills/repo-guardrails
Command: npx skills add https://github.com/YunosukeYoshino/harness --skill repo-guardrails

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Repository guardrails provide consistent checks for architecture boundaries, durable docs, and review readiness to reduce drift across projects and teams.

Core Features & Use Cases

  • Architecture boundaries enforcement: explicit forbiddances to prevent risky coupling (e.g., packages/app -> packages/ui is forbidden; domain stays UI-free)
  • Artifact placement: durable docs live in docs/, mutable task state in work/, avoid adding new root markdown files; update repo maps when structure changes
  • Review readiness: verify required artifacts exist before closing work items and ensure deterministic checks

Quick Start

Run a repository guardrails review on your project to enforce boundaries and ensure artifacts are correctly placed.

Frequently Asked Questions about repo-guardrails

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

FAQPage Schema
How do I enforce repository architecture boundaries during code reviews?

Artifact placement guardrails enforce durable docs in docs/, mutable state in work/, and block new root markdown files. This ensures consistent project structure and reduces drift across teams during code reviews.

What are repository guardrails and how do they maintain project structure?

Repository guardrails are architecture boundary rules that enforce consistent artifact placement, keeping durable docs in docs/ and mutable state in work/. They prevent structural drift by blocking risky package coupling and new root markdown files.

How do I check review readiness and verify required artifacts before closing work items?

Review readiness checks verify required artifacts exist and pass deterministic checks before closing work items. This ensures architectural boundaries and artifact placement rules are satisfied across multi-repo projects.

Can I use architecture boundary enforcement for multi-repo projects with different package structures?

Yes, architecture boundary enforcement applies across multi-repo projects by imposing explicit forbiddances against risky package coupling. It ensures correct artifact placement regardless of differing package structures.

Why does my code review fail when adding a new root markdown file?

Code reviews fail when adding new root markdown files because repository guardrails block this action to maintain structure. Durable docs must live in docs/ and repo maps must be updated when structure changes.