From memstack
Enforces project tiers (Prototype, MVP, Production) and complexity constraints to prevent over-engineering. Activates on 'new project', init, scope, or tier discussions.
npx claudepluginhub cwinvestments/memstack --plugin memstackThis skill uses the workspace's default tool permissions.
*Enforce tier-appropriate complexity. Prevent over-engineering the #1 waste of time in AI-assisted development.*
Classifies projects into 6 tiers by scope to right-size architecture, prevent over-engineering, and constrain patterns. Use for design, pattern selection, or implementation.
Scaffolds greenfield project architecture, test infrastructure, guard rails, and AI agent harness via interview-driven layers to requirements.md. Use for /scaffold, new projects, or setup.
Generates atomic PLAN.md files for hierarchical project planning in solo agentic dev with Claude. Covers briefs, roadmaps, phases; includes tasks, verification, checkpoints, success criteria.
Share bugs, ideas, or general feedback.
Enforce tier-appropriate complexity. Prevent over-engineering the #1 waste of time in AI-assisted development.
When this skill activates, output:
๐๏ธ Governor โ Checking project tier constraints...
Then execute the protocol below.
| 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 | โ |
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. |
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.
| 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.
| 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.
| 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.
Output a brief summary:
๐๏ธ Project: {name}
Tier: {Prototype | MVP | Production}
Allowed: {brief list}
NOT allowed: {brief list of key restrictions}
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.
git push is your CI