From software-architecture-vibe-coding
Use this skill when building, modifying, or refactoring code with Claude while preserving software architecture and keeping token use low. It gives concise engineering guidance for repository inspection, change classification, dependency direction, information hiding, scoped implementation, testing, and verification.
How this skill is triggered — by the user, by Claude, or both
Slash command
/software-architecture-vibe-coding:vibe-codeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Help Claude code quickly without creating architecture drift. Use the smallest professional workflow that fits the task. Do not add ceremony for trivial edits, and do not generate broad rewrites when a focused change solves the request.
Help Claude code quickly without creating architecture drift. Use the smallest professional workflow that fits the task. Do not add ceremony for trivial edits, and do not generate broad rewrites when a focused change solves the request.
Core rule:
Fast coding is allowed. Architecture drift is not.
Use this skill for feature work, bug fixes, refactors, plugin work, APIs, exporters, simulations, BIM/XR/robotics tools, or cleanup of AI-generated code.
Do not force the full workflow for a typo, one-line setting change, copy edit, or disposable script.
Classify the work before coding.
Tiny change
Examples: text edit, one constant, one import, one obvious bug line. Apply directly after checking the immediate context. Do not touch unrelated code.
Local change
Examples: one function, component, class, command, script, or test area. Inspect nearby code, match existing style, and avoid new abstractions unless they remove real coupling or duplication.
Architectural change
Examples: new feature, new module, new dependency, new file format, database/API boundary, exporter, SDK integration, multi-file refactor, or domain rule change. Do a short design pass before implementation and keep the slice small.
When uncertain, treat the task as local or architectural until repository inspection proves it is tiny.
Inspect first. Read the relevant files, entry points, tests, and configuration before changing non-trivial code.
Control dependency direction. UI, CLI, API, commands, jobs, and framework glue should depend on application use cases. Application code may depend on domain models and ports. Infrastructure adapters should depend inward, not the other way around.
Keep policy separate from detail. Domain decisions and business rules should not be hidden in UI handlers, SDK callbacks, database code, HTTP clients, file exporters, or vendor-specific APIs.
Treat external tools as details. Revit, Unity, ROS, IFC, USD, glTF, databases, file systems, web frameworks, cloud SDKs, and LLM APIs should sit behind boundaries when their behavior affects domain logic or testing.
Hide changeable decisions. Isolate file formats, protocols, coordinate systems, unit conversion, thresholds, caching, and vendor APIs when they are likely to change. Do not create interfaces only for decoration.
Design around stable concepts. Prefer names and modules based on domain meaning, responsibilities, and data flow over button clicks, screens, or implementation steps.
Keep changes surgical. Touch only what the request requires. Preserve existing style. Do not refactor adjacent code unless the requested change cannot be made safely without it.
Implement a vertical slice. For larger work, connect the smallest useful path through data model, use case, adapter/UI, and tests. Avoid half-built frameworks.
Make failure behavior explicit. Handle realistic errors at boundaries. Do not hide failures with broad catch-all logic or silent fallbacks.
Leave evidence. Add or update tests where behavior changes. Run the most relevant verification command available in the repo.
For non-trivial work:
Ask the user only when a decision materially changes behavior, public API, data shape, migration risk, or user-visible workflow and cannot be resolved from the repo.
Match test effort to risk:
If tests cannot run because dependencies, tools, permissions, or environment are missing, say exactly what was not run and why.
Keep the final answer short and concrete:
Do not over-explain the architecture unless the user asks.
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub isaddiq/software-architecture-vibe-coding --plugin software-architecture-vibe-coding