agentleFS
cwinvestmentscwinvestments/memstack/skills/governor/SKILL.md

governor

Skill425 starsChanged 5 months agoMITView on GitHub

Use when the user says 'new project', 'project init', 'what tier', 'scope', or discusses project maturity, complexity budget, or what's appropriate to build.

  • Commits and pushes

2 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 11 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When this skill activates, output:

    line 14
  2. Distinctive:

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

    line 32
  3. Distinctive:

    Ask or infer the project tier from context:

    line 47
  4. Distinctive:

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

    line 55
  5. Distinctive:

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

    line 72
  6. Distinctive:

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

    line 86
  7. Distinctive:

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

    line 100
  8. Distinctive:

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

    line 115
  9. Distinctive:

    Always defer to the user if they override.

    line 124
  10. Distinctive:

    Writing tests for throwaway code: If the prototype proves the idea wrong, those tests are wasted

    line 130
  11. Distinctive:

    No error tracking: If you can't see errors, you can't fix them

    line 153

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

🏛️ 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

ContextStatusPriority
User starts a new project ("new project", "init", "scaffold")ACTIVE: assign tierP1
User asks "what tier", "what's allowed", "scope check"ACTIVE, report current tier constraintsP1
User proposes work that exceeds current tierACTIVE: flag and adviseP2
User is executing work within tier constraintsDORMANT: don't interruptnone
User explicitly overrides ("I know, do it anyway")DORMANT: user has authoritynone

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:

TierDescriptionEffort Allocation
PrototypeExploring an idea. May be thrown away.Minimal: working code only
MVPValidated idea, building for first users.Moderate: basic quality gates
ProductionServing 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

AllowedNOT Allowed
Working code that demonstrates the ideaUnit tests
Hardcoded config valuesCI/CD pipelines
Console.log for debuggingType systems / strict typing
Single-file scriptsMonitoring / alerting
README with setup instructionsAuthentication / authorization
Infrastructure-as-code
Rate limiting
Database migrations (use SQLite)

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

MVP: Prove It Works

AllowedNOT 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 configMulti-environment deploys
Basic input validationPerformance optimization
Simple auth (if multi-user)Horizontal scaling
README + basic API docsComprehensive logging

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

Production: Reliability Matters

AllowedRequired
Everything from MVP, plus:Comprehensive tests (unit + integration)
Performance optimizationCI/CD pipeline
Monitoring and alertingError tracking (Sentry or equivalent)
Multi-environment deploymentInput validation at all boundaries
Horizontal scalingAuthentication + authorization
Database migrationsLogging with structured output
Rate limitingAPI 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)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.