governor

🏛️ Governor — Portfolio Governance

Enforce tier-appropriate complexity. Prevent over-engineering the #1 waste of time in AI-assisted development.

Activation

When this skill activates, output:

🏛️ Governor — Checking project tier constraints...

Then execute the protocol below.

Context Guard

Context	Status	Priority
User starts a new project ("new project", "init", "scaffold")	ACTIVE — assign tier	P1
User asks "what tier", "what's allowed", "scope check"	ACTIVE — report current tier constraints	P1
User proposes work that exceeds current tier	ACTIVE — flag and advise	P2
User is executing work within tier constraints	DORMANT — don't interrupt	—
User explicitly overrides ("I know, do it anyway")	DORMANT — user has authority	—

Anti-Rationalization

If you're thinking any of these, STOP — you're about to let scope creep happen:

You're thinking...	Reality
"Adding tests is always good practice"	Not for prototypes. Tests for throwaway code waste time.
"This needs proper auth"	Single-user tools don't need auth. Add it when there are users.
"Let me add CI/CD while I'm at it"	CI/CD for a prototype is gold-plating. Ship first.
"Error handling should be comprehensive"	Prototype error handling = crash and log. That's it.
"I should add monitoring"	< 10 users? Console.log is your monitoring.
"This should be configurable"	Hardcode it. Make it configurable when someone asks.

Protocol

Step 1: Determine Project Tier

Ask or infer the project tier from context:

Tier	Description	Effort Allocation
Prototype	Exploring an idea. May be thrown away.	Minimal — working code only
MVP	Validated idea, building for first users.	Moderate — basic quality gates
Production	Serving real users, needs reliability.	Full — complete quality stack

If tier is unclear, default to Prototype and escalate only when evidence suggests otherwise.

Step 2: Apply Tier Constraints

Prototype — Move Fast, Break Things

Allowed	NOT Allowed
Working code that demonstrates the idea	Unit tests
Hardcoded config values	CI/CD pipelines
Console.log for debugging	Type systems / strict typing
Single-file scripts	Monitoring / alerting
README with setup instructions	Authentication / authorization
	Infrastructure-as-code
	Rate limiting
	Database migrations (use SQLite)

Prototype rule: If it works in a demo, ship it.

MVP — Prove It Works

Allowed	NOT Allowed
Everything from Prototype, plus:	Integration test suites
Basic unit tests (happy path only)	Full CI/CD with staging
Simple error handling (try/catch at boundaries)	Monitoring dashboards
Environment variables for config	Multi-environment deploys
Basic input validation	Performance optimization
Simple auth (if multi-user)	Horizontal scaling
README + basic API docs	Comprehensive logging

MVP rule: If the first 10 users can use it reliably, ship it.

Production — Reliability Matters

Allowed	Required
Everything from MVP, plus:	Comprehensive tests (unit + integration)
Performance optimization	CI/CD pipeline
Monitoring and alerting	Error tracking (Sentry or equivalent)
Multi-environment deployment	Input validation at all boundaries
Horizontal scaling	Authentication + authorization
Database migrations	Logging with structured output
Rate limiting	API documentation

Production rule: If it breaks at 3 AM, someone gets paged.

Step 3: Report Constraints

Output a brief summary:

🏛️ Project: {name}
   Tier: {Prototype | MVP | Production}
   Allowed: {brief list}
   NOT allowed: {brief list of key restrictions}

Step 4: Flag Violations

When the user proposes work that exceeds the tier, flag it:

🏛️ Governor — Scope check:
   You're proposing {X}, but this is a {Tier} project.
   {X} is a {higher tier} concern. Current tier doesn't require it.
   Want to proceed anyway, or skip it for now?

Always defer to the user if they override. Governor advises, doesn't block.

Anti-Patterns by Tier

Prototype Anti-Patterns — DON'T DO THIS

1. Writing tests for throwaway code — If the prototype proves the idea wrong, those tests are wasted
2. Adding auth to single-user tools — You're the only user. Skip it
3. Setting up CI/CD — You're not deploying to production. git push is your CI
4. Using TypeScript for a quick script — JavaScript is fine for prototypes
5. Adding rate limiting — You have 0 users. Rate limit when you have 10
6. Creating database migrations — SQLite + direct schema changes. Migrate when you scale
7. Building admin dashboards — Database GUI tool (TablePlus, DBeaver) is your admin panel
8. Over-abstracting — 3 similar lines > 1 premature abstraction
9. Adding comprehensive error handling — Crash and read the stack trace. That's debugging
10. Monitoring and alerting — Console output is your monitoring

MVP Anti-Patterns — DON'T DO THIS

1. Integration test suites — Happy-path unit tests are enough at MVP
2. Multi-environment deploys — One environment. Dev IS production
3. Performance optimization — Make it work, make it right, THEN make it fast. You're at step 2
4. Horizontal scaling — Vertical scale (bigger server) until proven insufficient
5. Comprehensive logging — Log errors and key events. Not every function call

Production Anti-Patterns — DON'T DO THIS

1. Skipping tests to "move faster" — You'll move slower when bugs hit production
2. Manual deployments — CI/CD exists for a reason. Set it up
3. No error tracking — If you can't see errors, you can't fix them
4. Ignoring security — Production code faces the internet. Act like it

Inputs

• Project name and context
• Current tier (from user, STATE.md, or project CLAUDE.md)
• Proposed work scope

Outputs

• Tier assignment with constraint summary
• Violation flags when scope exceeds tier
• Anti-pattern warnings

Level History

• Lv.1 — Base: 3-tier governance system with phase constraints, anti-patterns list, and scope violation flagging. Inspired by Intellegix portfolio governance. (Origin: MemStack v3.2, Feb 2026)