create-architecture

Create or update repo-specific architecture boundary documentation in docs/ARCHITECTURE.md.

2|Updated Feb 17, 2026
One-click install
npx skills add https://github.com/nodatall/primedirective --skill create-architecture-nodatall
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: create-architecture
Source: https://github.com/nodatall/primedirective/tree/main/skills/create-architecture
Command: npx skills add https://github.com/nodatall/primedirective --skill create-architecture-nodatall

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Non-trivial repositories often lack a clear, maintained architecture boundary contract, leading to inconsistent module boundaries, forbidden dependency violations, and confusion when making boundary-affecting changes to the codebase.

Core Features & Use Cases

  • Dual-mode operation: Supports both inspecting existing repositories to capture actual architecture and creating greenfield architecture baselines for new projects.
  • Concrete boundary documentation: Records module responsibilities, allowed/forbidden dependencies, composition roots, shared-code rules, testing boundaries, and accepted deviations specific to your repo.
  • Use Case: Use this skill when bootstrapping a new non-trivial codebase, or before implementing changes that modify module boundaries if your repo lacks an existing architecture document.

Quick Start

Invoke the create-architecture skill to generate or update your repo's docs/ARCHITECTURE.md file with concrete, stack-native boundary rules tailored to your codebase.

Frequently Asked Questions about create-architecture

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

FAQPage Schema
How do I document module boundaries and dependency rules for an existing repository?

You can document module boundaries and dependency rules for an existing repository by inspecting the codebase to capture actual architecture, recording allowed and forbidden dependencies, composition roots, and shared-code rules into a standing boundary contract.

What is the best way to establish architecture baselines for greenfield projects before coding starts?

Establishing architecture baselines for greenfield projects requires creating stack-native architecture documentation that defines module responsibilities and dependency direction upfront, providing a concrete baseline before implementation begins.

When do I need to create architecture boundary documentation for my codebase?

You need architecture boundary documentation when bootstrapping a non-trivial codebase or before implementing changes that modify module boundaries, ensuring consistent dependency direction and eliminating ambiguity around module responsibilities.

Does this approach work for recording accepted deviations and testing boundaries in non-trivial repos?

Yes, this approach works for non-trivial repos by recording accepted deviations and testing boundaries alongside module responsibilities and composition roots, creating a repo-specific architecture contract that accommodates edge cases.

How to update an existing architecture document when modifying module boundaries?

To update an existing architecture document when modifying module boundaries, you regenerate the repo-specific boundary records to reflect new dependency rules, shared-code constraints, and composition roots affected by the changes.