gproject-stack-advisor
Skill0 starsChanged 5 months agoMITView on GitHub
Determines project level (MVP/pet/startup/production) and recommends optimal technology stack with trade-off analysis. Use when: dispatched by gproject-orchestrator Phase 2. NOT for: direct user invocation.
In this repository76 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- autodoc-analystSkill
- autodoc-architectSkill
- autodoc-assemblerSkill
- autodoc-orchestratorSkill
- autodoc-scannerSkill
- autodoc-writerSkill
- brainstormSkill
- brd-creatorSkill
- caveman-modeSkill
- changelogSkill
- claude-md-managementSkill
- code-ai-reviewSkill
- code-boss-reviewSkill
- code-mobx-store-reviewSkill
- code-reviewSkill
- code-style-reviewSkill
- code-verifierSkill
- commitSkill
- constraint-driven-developmentSkill
- context-collectorSkill
- db-migrateSkill
- dependency-updateSkill
- deploySkill
- doubt-driven-developmentSkill
- feature-analyzerSkill
- feature-devSkill
- fsd-creatorSkill
- gproject-consistency-checkerSkill
- gproject-discoverySkill
- gproject-orchestratorSkill
- gproject-patterns-researcherSkill
- gproject-plannerSkill
- gproject-problem-definerSkill
- gproject-spec-writerSkill
- hookifySkill
- iagoSkill
- interviewerSkill
- interviewSkill
- issue-analyzerSkill
- job-documenterSkill
- job-orchestratorSkill
- perf-checkSkill
- plan-gatekeeperSkill
- prd-creatorSkill
- pr-issue-documenterSkill
- pr-review-commentsSkill
- prSkill
- pushSkill
- review-architectureSkill
- review-backendSkill
- review-clean-codeSkill
- review-core-boundariesSkill
- review-flow-graphSkill
- review-frontend-conventionsSkill
- review-frontendSkill
- review-greptileSkill
- review-highloadSkill
- review-logicSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
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
- Distinctive: line 127
If mode is task_in_project:
- Distinctive: line 128
Start from existing stack (detected by context-collector)
- Distinctive: line 129
Only recommend NEW technologies if:
≈ “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.
Files
gproject-stack-advisor
Purpose
Select the right project level and technology stack based on problems, goals, constraints, and best practices. Every recommendation must be justified with trade-offs — not "use React because it's popular" but "use React because [specific reasons matching this project's constraints]."
Iron Laws
| # | Law |
| 1 | EVERY technology choice MUST have explicit rationale tied to project constraints |
| 2 | EVERY choice MUST list at least one considered alternative and why it was rejected |
| 3 | Stack MUST match project level — no Kubernetes for an MVP |
| 4 | In task_in_project mode, default to existing stack unless change is strongly justified |
| 5 | NEVER recommend a technology without checking its maturity and community support |
| 6 | Team skills MUST be a primary factor — perfect tech with no team knowledge = wrong choice |
Red Flags
| Flag | What's happening | Action |
| Recommending 5+ new technologies for MVP | Over-engineering | Simplify to max 3 core choices |
| Ignoring team skills in rationale | Tech-driven not people-driven | Re-evaluate with team factor |
| No alternative considered | Confirmation bias | Research at least 1 alternative per choice |
| Recommending bleeding-edge for production | Risk ignorance | Flag maturity concern |
Input Contract
task: "Select project level and technology stack"
input_artifacts:
- jobs/<job>/artifacts/problem-statement.md
decisions_so_far:
D_core_problems: [...]
D_goals: [...]
D_non_goals: [...]
D_target_users: "..."
D_scale_estimate: "..."
# For task_in_project:
D_existing_stack: "<if detected by context-collector>"Output Contract
status: "DONE" | "NEEDS_CONTEXT"
summary: "<3-5 sentences: level chosen, stack chosen, key trade-off>"
new_decisions:
D_level: "mvp | pet | startup | production"
D_frontend: "<framework + version>"
D_backend: "<framework + version>"
D_database: "<DB + version>"
D_cache: "<if needed>"
D_queue: "<if needed>"
D_auth: "<approach>"
D_deploy: "<strategy>"
D_infra: "<approach>"
artifact_path: "jobs/<job>/artifacts/stack-decision.md"
next_phase_needs:
- "Per-technology best practices research"
- "Architecture pattern selection"Workflow
Step 1: Determine Project Level
Evaluate against criteria matrix:
| Factor | MVP | Pet/Learning | Startup | Production |
| Users | <100 | 1 (self) | 100-10K | 10K+ |
| Team | 1 person | 1 person | 2-5 | 5+ |
| Lifespan | weeks | indefinite | months-years | years |
| Budget | minimal | zero | seed/limited | funded |
| Uptime SLA | none | none | 99% | 99.9%+ |
| Data sensitivity | low | low | medium | high |
| Compliance | none | none | basic | regulated |
The level determines complexity ceiling:
- MVP: max simplicity, monolith, single deploy target, minimal infra
- Pet: developer experience priority, learning-friendly stack
- Startup: balance of speed and scalability, ready for growth
- Production: reliability, security, observability, scalability first
Step 2: Evaluate Stack Options
For each layer, evaluate 2-3 options against project-specific criteria:
Evaluation criteria (weight varies by project level):
- Problem fit — does it solve our specific problems well?
- Team match — does the team know it? Learning curve?
- Ecosystem — libraries, tools, community for our use case
- Scalability ceiling — will it handle our target scale?
- Velocity — how fast can we ship with it?
- Cost — licensing, hosting, operational cost
- Maturity — production-proven? Active maintenance?
- Integration — works well with other chosen components?
Step 3: Web Research (Best Practices)
For the shortlisted stack, research:
- Current best practices (2024-2025 sources preferred)
- Common pitfalls and antipatterns
- Production case studies at similar scale
- Performance benchmarks relevant to our use case
Step 4: task_in_project Mode Adjustments
If mode is task_in_project:
- Start from existing stack (detected by context-collector)
- Only recommend NEW technologies if:
- Existing stack cannot solve the specific problem
- New tech integrates cleanly with existing stack
- Learning overhead is justified by benefit
- Flag any technology additions clearly as "NEW — requires team learning"
Step 5: Write Stack Decision
Write artifacts/stack-decision.md:
# Stack Decision: <Project/Task Name>
## Project Level: <LEVEL>
**Rationale**: <why this level, based on constraints>
## Technology Stack
### Frontend: <Choice>
**Version**: <specific>
**Rationale**: <tied to project constraints>
**Alternative considered**: <what and why rejected>
**Key libraries**: <essential deps>
### Backend: <Choice>
**Version**: <specific>
**Rationale**: <tied to project constraints>
**Alternative considered**: <what and why rejected>
**Key libraries**: <essential deps>
### Database: <Choice>
...
### Infrastructure & Deploy: <Choice>
...
### Additional Services (if any)
- Cache: <if needed, with rationale>
- Queue: <if needed, with rationale>
- Search: <if needed, with rationale>
## Stack Compatibility Matrix
| Component | Integrates With | Integration Quality |
|-----------|----------------|-------------------|
| <A> | <B> | proven / good / experimental |
## Trade-offs Accepted
| Trade-off | What We Gain | What We Give Up |
|-----------|-------------|-----------------|
| <choice> | <benefit> | <cost> |
## Complexity Budget
**Total new technologies**: <count>
**Team learning required**: <list what's new>
**Estimated ramp-up**: <time>
## Risk Assessment
| Risk | Probability | Impact | Mitigation |
|------|------------|--------|------------|
| <risk> | <H/M/L> | <H/M/L> | <plan> |Step 6: Return Summary
Compact summary: level + core stack (one line) + biggest trade-off + confidence.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

