convention-tiering

Classify design decisions into hard conventions, strong defaults, and local freedom.

2|Updated Feb 13, 2026
One-click install
npx skills add https://github.com/yutna/vibe-next-template --skill convention-tiering
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: convention-tiering
Source: https://github.com/yutna/vibe-next-template/tree/main/.claude/skills/convention-tiering
Command: npx skills add https://github.com/yutna/vibe-next-template --skill convention-tiering

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill should be used when a task changes architecture, naming, folder structure, boundaries, or repository conventions. Classifies design decisions into hard conventions, strong defaults, and local freedom so plans and reviews stay contract-driven.

Core Features & Use Cases

  • Classifies touched design decisions into hard conventions, strong defaults, and local freedom.
  • Preserves hard conventions automatically.
  • Reuses strong defaults unless a plan records a reason to deviate.
  • Restricts local freedom to stable module, route, and boundary contracts.
  • Helps planning and reviews stay contract-driven across teams.

Quick Start

List the touched design decisions and classify each one into hard conventions, strong defaults, and local freedom to produce a contract-driven plan.

Frequently Asked Questions about convention-tiering

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

FAQPage Schema
How do I keep architecture decisions contract-driven when changing repository conventions?

To keep architecture decisions contract-driven, classify each touched design decision into hard conventions, strong defaults, and local freedom. This preserves strict rules automatically while justifying any deviations from standard defaults.

What is the best way to manage module boundaries and folder structure changes during planning?

Manage module boundaries and folder structure changes by classifying them as hard conventions, strong defaults, or local freedom. Reuse strong defaults unless a deviation is explicitly justified, restricting local freedom to stable modules.

How do I codify design decisions for naming conventions and boundary contracts?

Codify design decisions by categorizing naming conventions and boundary contracts into a tiered system. Hard conventions are preserved automatically, while local freedom is restricted to stable module and route contracts to maintain stability.

When do I need to classify design decisions into hard conventions and local freedom?

Classify design decisions into hard conventions and local freedom when a task changes architecture, naming, folder structure, boundaries, or repository conventions. This classification ensures plans and code reviews remain contract-driven across teams.

Does this approach work for planning and reviewing architecture changes across teams?

Yes, classifying design decisions into hard conventions, strong defaults, and local freedom helps planning and reviews stay contract-driven across teams. It preserves hard conventions automatically and limits local freedom to stable boundaries.