repo-conventionslisted

Follow the target repository's established conventions before applying fallback guidance for API design, backend or frontend structure, Playwright E2E tests, current research, or a bounded local work cycle. Use when implementing or reviewing one of those areas; do not use when a more specific installed skill owns the task.
espensev/ai-skills · ★ 0 · Testing & QA · score 72

Install: claude install-skill espensev/ai-skills

# Repository Conventions Start with the repository's actual contracts. Framework-shaped advice is a fallback, not authority to overwrite an established design. ## Repository-First Workflow 1. Read the nearest `AGENTS.md`, `CONTRIBUTING.md`, project configuration, and relevant architecture or test docs. 2. Inspect two or three nearby examples in the same subsystem. 3. Identify the established naming, layering, error, state, test, and tooling conventions that constrain the change. 4. Select the narrow playbook below. Apply its fallback rules only where the repository is silent or demonstrably inconsistent. 5. Implement the smallest coherent change and verify it with the repository's own commands. 6. Report the convention followed, any deliberate exception, verification, and remaining risk. If repository guidance conflicts, call out the conflict and prefer the most local current authority. Do not quietly invent a third convention. ## Capability Map This table makes the consolidation auditable. Each former section has one destination in this skill. | Former skill / section | Destination here | |---|---| | `api-design` / Start Here | Repository-First Workflow | | `api-design` / Core Rules | API Contracts / Core rules | | `api-design` / Resource Design | API Contracts / Resources and queries | | `api-design` / Response Design | API Contracts / Responses and errors | | `api-design` / Versioning | API Contracts / Compatibility and security | | `api-design` / Sec