Add a tailored constitution to your project. Use when starting a new project, bootstrapping governance, or when user asks to "create a constitution", "set up project principles", or "define coding standards". Conducts structured discovery through clarifying questions about project scale, risk profile, lifespan, architecture, team size, and delivery expectations, then recommends appropriate engineering principles, patterns, and practices matched to the project's characteristics.
From constitutionnpx claudepluginhub aaronbassett/agent-foundry --plugin constitutionThis skill uses the workspace's default tool permissions.
references/engineering-principles.mdreferences/extracted-patterns.mdreferences/principles-mapping.mdtemplates/constitution.template.mdProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Analyzes competition with Porter's Five Forces, Blue Ocean Strategy, and positioning maps to identify differentiation opportunities and market positioning for startups and pitches.
Write a tailored constitution by discovering project characteristics and recommending matched principles.
Ask questions to understand the project. Group related questions; don't overwhelm with all at once.
Round 1 - Project Nature:
Round 2 - Technical Profile:
Round 3 - Risk & Operations:
Round 4 - Quality Expectations:
Based on discovery, select principles from the catalog below. Only suggest what matches the project profile.
Selection Rules:
| Project Characteristic | Suggested Principles |
|---|---|
| Hackathon/prototype | MVP Speed, Demo-First, Skip Tests, Good Enough Architecture |
| Solo personal tool | Ship Fast Fix What Hurts, Build for Joy, Dogfood Relentlessly |
| Team project | Single Responsibility, Conventional Commits, Code Review Required |
| Long-lived system | Modularity, Documentation Standards, Semantic Versioning |
| High uptime (99%+) | Fail Fast & Loud, Graceful Degradation, Observability First |
| Public/multi-tenant | Zero Trust, Least Privilege, Input Validation Required |
| Financial/regulated | Security by Default, Audit Trails, No Silent Failures |
| CLI tool | Unix Philosophy, Text I/O Protocol, Predictable Exit Codes |
| Distributed system | CAP Awareness, Idempotency, Circuit Breaking |
| Complex domain | Domain-Driven Design (selective), Clear Naming |
| Fast iteration needed | YAGNI, KISS, Refactor When It Hurts |
Anti-patterns to avoid:
Read the constitution template file templates/constitution.template.md and fill in each section based on the user's input. Follow the structure of the template, but you do not have match it item for item. For example the project's constitution may have less or more principles than the template. Do not add unnecessary principles for no other reason than to match the number in the template, and by the same token not leave principles out or merge them together because you have more than the template.
Show the user the newly written project constitution and solicit feedback or revisions. If the user approves the constitution save it as ./CONSTITUTION.md.
MVP Speed: Ship smallest working version fast. Cut features aggressively. Skip premature optimization. Refactor when it hurts, not before.
Ship Fast, Fix What Hurts: Build smallest useful thing, dogfood immediately, iterate on real pain. Ignore hypothetical requirements.
KISS: Do simplest thing that works. If you can't explain it in one sentence, it's too complex.
YAGNI: No speculative features. Build when needed, not "just in case."
Good Enough Architecture: Use patterns you know. Boring and fast beats novel and slow.
Make It Work, Then Make It Fast: Correctness first. Measure before optimizing. "Fast enough" is good enough.
Single Responsibility: Each component does one thing well. Don't blur lines between concerns.
Modularity: Well-defined boundaries. Explicit dependencies. No circular dependencies.
Composition Over Inheritance: Prefer composing simple parts over complex inheritance hierarchies.
Encapsulate What Varies: Isolate the parts that change from the parts that stay the same.
Rule of Three: Don't generalize until the third repetition.
Integration Tests First: Test real workflows against real environments. Mocks are last resort.
Test What Matters: Focus on catching bugs, not coverage metrics. Test critical paths, skip trivialities.
Tests Optional (Hackathon): Manual testing acceptable. Automated tests only if they save debugging time.
Don't Test Your Mocks: If tests pass but real integration fails, tests are useless.
Fail Fast & Loud: Crash early with clear context. No silent failures.
Fail Safe: When failure happens, fail to a safe state.
Human-Readable Errors: "API connection failed: returned 503. Check network." Not "ECONNREFUSED".
Actionable Feedback: Every error suggests a fix or next step.
Graceful Degradation: If a service is down, say so clearly. Don't pretend everything is fine.
README First: Installation, setup, and basic usage must be documented.
Comment the Why: Not the what. Assume reader understands the language.
Code as Documentation: Clear naming > comments. Comments for non-obvious decisions only.
Documentation as Code: Keep docs next to code. Update together.
Observability First: You can't fix what you can't see. Logs, metrics, traces.
Infrastructure as Code: If it's not in code, it doesn't exist.
Automate What Hurts: If it's repeated and painful, automate it.
Runbooks Over Tribal Knowledge: Write down how to fix things.
Zero Trust: Assume networks are hostile. Verify everything.
Least Privilege: Minimum access needed. No more.
Secure by Default: Opt into risk, not safety.
Defense in Depth: Multiple layers of protection.
Input Validation Required: Validate at system boundaries. Use schemas (Zod, etc.).
Never Log Secrets: Private keys, tokens, passwords never in logs or output.
Conventional Commits: type(scope): subject format for clear, searchable history.
Trunk-Based Development: Short-lived branches. Merge frequently.
Code Review Required: All changes reviewed before merge.
Blameless Postmortems: Learn from failures without blame.
Strong Opinions, Weakly Held: Commit to decisions but change when evidence warrants.
Unix Philosophy: Single purpose. Text I/O. Composable. Predictable exit codes.
Hexagonal/Ports & Adapters: Isolate business logic from I/O.
Locality of Behavior: Put things that change together, together.
Stable Dependencies: Depend on things less likely to change.
API First Design: Design the contract before implementation.
Small Batches: Ship small, ship often. Smaller changes = smaller risks.
Done Means Deployed: Code isn't done until it's running somewhere.
Feature Flags Over Branches: Deploy dark, enable incrementally.
Continuous Delivery: Always be in a deployable state.
Solve Real Problems: Not imaginary ones. Follow demand, don't anticipate it.
Defaults Are Product Decisions: Make the right thing easy.
Evidence Over Opinions: Measure outcomes, not output.
If It's Not Used, It Doesn't Exist: Features require adoption to be "done".
Frictionless Setup: One command to install, one to run.
Speed Is a Feature: Fast feedback loops. Progress for anything >500ms.
Predictability Over Flashiness: Do what users expect.
Design for the Primary Use Case: Not the edge cases.
Before presenting the constitution: