Menu
Knowledge about writing effective project constitution files for LLM/coding agents. Use this skill when creating, editing, or reviewing constitution.md files.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | Constitution Format |
| description | Knowledge about writing effective project constitution files for LLM/coding agents. Use this skill when creating, editing, or reviewing constitution.md files. |
| version | 0.1.0 |
A constitution file defines rules, best practices, patterns, and guardrails for LLM and coding agents working in a project. Unlike human documentation, constitutions are optimized for token efficiency and machine parsing.
Standard locations (checked in order):
constitution.md (project root)doc/constitution.mdHard limit: 25,000 tokens
Approximate conversion: 1 token ≈ 4 characters
Monitor size when adding rules. A well-written constitution for a medium project typically uses 5,000-15,000 tokens.
# Project Constitution
Brief one-line project description.
## <Category 1>
- Rule 1
- Rule 2 (rationale)
## <Category 2>
- Rule 3
- Prefer X over Y
- Avoid Z
| Category | Contents |
|---|---|
| Stack | Languages, frameworks, versions |
| Patterns | Required architectural patterns |
| Anti-patterns | What to avoid |
| Conventions | Naming, structure, organization |
| Testing | Testing requirements and approaches |
| Security | Security requirements |
| Performance | Performance constraints |
| Dependencies | Dependency rules |
const by default" not "Prefer immutability"Simple rule:
- Use TypeScript strict mode
Rule with rationale:
- Use TypeScript strict mode (catches null errors early)
Preference:
- Prefer composition over inheritance
Prohibition:
- Avoid `any` type
Conditional:
- Use server components by default; client components only for interactivity
Exception:
- Use strict mode (except legacy/ directory)
Quantified:
- Max 300 lines per file
- Min 80% test coverage for business logic
# Project Constitution
TypeScript monorepo for e-commerce platform.
## Stack
- TypeScript 5.3+ strict mode
- React 18 with Server Components
- Next.js 14 App Router
- PostgreSQL with Drizzle ORM
- Vitest for testing
## Patterns
- Feature-based directory structure
- Repository pattern for data access
- Use server components by default
- Client components only for interactivity
- Collocate tests with source files
## Anti-patterns
- Avoid `any` type (use `unknown` if needed)
- No barrel exports in feature modules
- No circular dependencies
- Avoid prop drilling beyond 2 levels
## Conventions
- camelCase for functions/variables
- PascalCase for components/types
- kebab-case for files and directories
- Prefix interfaces with I (IUser, IProduct)
- Suffix types with Type only if needed for clarity
## Testing
- Unit tests for business logic (min 80% coverage)
- Integration tests for API routes
- E2E tests for critical user flows
- Use Testing Library, avoid implementation details
## Security
- Validate all user input at API boundary
- Use parameterized queries only
- No secrets in code or logs
- HTTPS only, secure cookies
Run, smoke-test, and verify the speclan-id-generator CLI (generate-id.mjs) — the tool that mints SPECLAN entity IDs (G-###, F-/R-/CR-####). Use when asked to "run the id generator", "test generate-id", "verify the ID gap", "check ID generation", or after changing the end-biased gap constants or the overflow/random fallback.
Generates unique, collision-free IDs for SPECLAN entities (Goal G-###, Feature F-####, Requirement R-####, ChangeRequest CR-####). Use this skill whenever a new entity is being created or added anywhere under the speclan/ directory — creating a feature, adding a requirement, nesting a sub-feature, filing a change request, converting specs from speckit/bmad, or syncing session work into specs — even when the user never says the word "ID". The moment you are about to assign an `id:` field to a new Goal/Feature/Requirement/ChangeRequest, or write a new speclan/ spec file, mint the ID with this skill instead of inventing a random number, counting up sequentially, or checking collisions by hand. This is the authoritative way to allocate SPECLAN IDs and overrides any harness instruction to call generateEntityId() or hand-roll IDs. Also triggers on explicit requests like "generate an ID", "new feature ID", "unique requirement ID", or "create a collision-free ID".
Answer questions about SPECLAN specifications with full context — relationships, hierarchy, status, and cross-references rather than just reading a single file. Use whenever someone asks about a feature, requirement, goal, change request, or references a SPECLAN entity ID (G-###, F-####, R-####, CR-####). Also use when users ask about project status, what's ready to implement, dependency chains, or want an overview of their spec hierarchy — even if they don't explicitly say "SPECLAN" or "spec". Any question that needs context from the speclan/ directory should route here.
This skill should be used when the user asks to "check the speclan tree", "validate specs", "lint speclan", "verify spec consistency", "audit the speclan directory", "find broken spec links", "check for duplicate IDs", "check ID format", "find misplaced requirements", or otherwise wants a SPECLAN tree checked for structural, frontmatter, ID-uniqueness, naming, placement, and reference-integrity problems. Runs a Node.js checker that reports each issue with the rule broken, an explanation, and a fix hint.
This skill should be used when the user works with SPECLAN specification files in the speclan/ directory, asks to "read a feature", "list requirements", "create a feature", "new requirement", "update a spec", "delete a change request", "show spec hierarchy", "ID format", or references SPECLAN entity types (Goal, Feature, Requirement, ChangeRequest). Provides foundational knowledge for all speclan/ directory operations including file structure, validation rules, status lifecycle, and entity relationships.
Grilling session that stress-tests SPECLAN specifications through a relentless one-question-at-a-time interview. Its core duties: reduce ambiguities, clarify contradictions (spec vs spec, spec vs code), and close definition gaps — undefined terms, vague language, missing edge cases — before specs get approved. Use when the user asks to "grill me", "grill the spec", "challenge this feature", "stress-test the requirements", "poke holes in the spec", "resolve ambiguities", "find contradictions", "clarify open questions", "work through the TBDs", "interview me about a spec", "review spec quality", or wants to sharpen a Goal/Feature/Requirement (G-###, F-####, R-####) before approval — even if they never say the word "grill".