$ARGUMENTS

Do you want to establish a project constitution?

A) No, skip it - I don't need a formal constitution
B) Yes, minimal - Core technical standards only (≈1 page, 3-5 questions)
C) Yes, comprehensive - Full governance and tribal knowledge (≈2-3 pages, 8-12 questions)

Phase 1: Technical Standards
These are the non-negotiable technical requirements that all features must follow.
This phase is recommended for all projects.

What languages and frameworks are required for this project?
Examples:
- "Python 3.11+ with FastAPI for backend"
- "TypeScript 4.9+ with React 18 for frontend"
- "Rust 1.70+ with no external dependencies"

What testing framework and coverage requirements?
Examples:
- "pytest with 80% line coverage, 100% for critical paths"
- "Jest with 90% coverage, unit + integration tests required"
- "cargo test, no specific coverage target but all features must have tests"

What are the performance and scale expectations?
Examples:
- "Handle 1000 requests/second at p95 < 200ms"
- "Support 10k concurrent users, 1M daily active users"
- "CLI operations complete in < 2 seconds"
- "N/A - performance not a primary concern"

What are the deployment constraints or platform requirements?
Examples:
- "Docker-only, deployed to Kubernetes"
- "Must run on Ubuntu 20.04 LTS without external dependencies"
- "Cross-platform: Linux, macOS, Windows 10+"
- "N/A - no specific deployment constraints"

Phase 2: Code Quality
Skip this if your team uses standard practices without special requirements.

Do you want to define code quality standards?
A) Yes, ask questions
B) No, skip this phase (use standard practices)

What are the requirements for pull requests?
Examples:
- "2 approvals required, 1 must be from core team"
- "1 approval required, PR must pass CI checks"
- "Self-merge allowed after CI passes for maintainers"

What should reviewers check during code review?
Examples:
- "Tests added, docstrings updated, follows PEP 8, no security issues"
- "Type annotations present, error handling robust, performance considered"
- "Standard review - correctness, clarity, maintainability"

What quality gates must pass before merging?
Examples:
- "All tests pass, coverage ≥80%, linter clean, security scan clean"
- "Tests pass, type checking passes, manual QA approved"
- "CI green, no merge conflicts, PR approved"

What documentation is required?
Examples:
- "All public APIs must have docstrings + examples"
- "README updated for new features, ADRs for architectural decisions"
- "Inline comments for complex logic, keep docs up to date"
- "Minimal - code should be self-documenting"

Phase 3: Tribal Knowledge
Skip this for new projects or if team conventions are minimal.

Do you want to capture tribal knowledge?
A) Yes, ask questions
B) No, skip this phase

What team conventions or coding styles should everyone follow?
Examples:
- "Use Result<T, E> for fallible operations, never unwrap() in prod"
- "Prefer composition over inheritance, keep classes small (<200 lines)"
- "Use feature flags for gradual rollouts, never merge half-finished features"

What past mistakes or lessons learned should guide future work?
Examples:
- "Always version APIs from day 1"
- "Write integration tests first"
- "Keep dependencies minimal - every dependency is a liability"
- "N/A - no major lessons yet"

Do you want to document historical architectural decisions?
A) Yes
B) No

Any historical architectural decisions that should guide future work?
Examples:
- "Chose microservices for independent scaling"
- "Chose monorepo for atomic changes across services"
- "Chose SQLite for simplicity over PostgreSQL"

Phase 4: Governance
Skip this to use simple defaults.

Do you want to define governance process?
A) Yes, ask questions
B) No, skip this phase (use simple defaults)

How should the constitution be amended?
Examples:
- "PR with 2 approvals, announce in team chat, 1 week discussion"
- "Any maintainer can update via PR"
- "Quarterly review, team votes on changes"

Who validates that features comply with the constitution?
Examples:
- "Code reviewers check compliance, block merge if violated"
- "Team lead reviews architecture"
- "Self-managed - developers responsible"

Do you want to define exception handling?
A) Yes
B) No

How should exceptions to the constitution be handled?
Examples:
- "Document in ADR, require 3 approvals, set sunset date"
- "Case-by-case discussion, strong justification required"
- "Exceptions discouraged - update constitution instead"

Constitution Summary
====================

You've completed [X] phases and answered [Y] questions.
Here's what will be written to .kittify/memory/constitution.md:

Technical Standards:
- Languages: [Q1]
- Testing: [Q2]
- Performance: [Q3]
- Deployment: [Q4]

[If Phase 2 completed]
Code Quality:
- PR Requirements: [Q5]
- Review Checklist: [Q6]
- Quality Gates: [Q7]
- Documentation: [Q8]

[If Phase 3 completed]
Tribal Knowledge:
- Conventions: [Q9]
- Lessons Learned: [Q10]
- Historical Decisions: [Q11 if present]

Governance: [Custom if Phase 4 completed, otherwise defaults]

Estimated length: ≈[50-80 lines minimal] or ≈[150-200 lines comprehensive]

Proceed with writing constitution?
A) Yes, write it
B) No, let me start over
C) Cancel, don't create constitution

undefined

undefined