super-tech-blueprint
Skill0 starsChanged 20 days agoMITView on GitHub
Choose or generate a target technology stack: compare frameworks with TCO, security and ecosystem scoring, plan a migration, or write a blueprint for a new or next system. Use when comparing X vs Y, picking a framework, estimating migration cost, or producing a stack blueprint for greenfield or a target architecture. Not for documenting or diagnosing an existing codebase — use codebase-learner.
In this repository57 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/comments.mdcCursor rule
- .cursor/rules/commit-messages.mdcCursor rule
- .cursor/rules/git-workflow.mdcCursor rule
- .cursor/rules/manage-stack.mdcCursor rule
- .cursor/rules/no-worktrees.mdcCursor rule
- manage-stackSkill
- convert-as-skillSkill
- create-agentSkill
- create-agents-mdSkill
- create-commandSkill
- create-hookSkill
- create-ruleSkill
- create-skillSkill
- retrospectiveSkill
- super-architectureSkill
- super-cachingSkill
- super-elixirSkill
- super-nodejsSkill
- super-protobufSkill
- atomic-semantic-commitSkill
- code-reviewSkill
- create-bruno-collectionSkill
- create-documentationSkill
- create-ticketsSkill
- ready-specSkill
- write-adrSkill
- write-changelogSkill
- write-mr-descriptionSkill
- write-planSkill
- write-postmortemSkill
- write-runbookSkill
- noslopSkill
- output-saversSkill
- safe-refactorSkill
- tddSkill
- verifySkill
- get-movingSkill
- later-listSkill
- standupSkill
- challenge-meSkill
- codebase-learnerSkill
- researchSkill
- second-opinionSkill
- traceSkill
- color-kitSkill
- design-system-kitSkill
- diagramSkill
- infographicSkill
- product-polish-workflowSkill
- prototype-wireframeSkill
- ui-ux-kitSkill
- evidenceSkill
- find-skillsSkill
- handoffSkill
- rumblingSkill
- use-levistackSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 44
Do this first and do not announce it.
- Very specific: line 58
Current state (sibling): If a repo exists and facts are missing, load codebase-learner.
- Very specific: line 72
Run from specialities/stack-evaluator/.
- Distinctive: line 86
Every current-stack fact cites learner output or a file the user provided.
≈ “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
Super Tech Blueprint
Answers what should we build with / migrate toward? Target, greenfield, and stack choice. One skill, two specialities. Call it once. It picks the speciality from the job and loads only that guide.
Not for documenting what a repo uses today, writing ARCHITECTURE.md of existing code, or diagnosing current module smells — use codebase-learner. After a current-state map exists, this skill owns the target.
The guides are kept whole. Each is a full, separate skill that was merged in.
Step 0: detect the job
Do this first and do not announce it.
| If the user is doing this | Speciality | Load |
| What stack this repo uses, architecture docs of existing code, onboarding, current smells | not this skill | codebase-learner |
| Comparing technologies, scoring ecosystem health, assessing security posture, estimating TCO | evaluate | stack-evaluator |
| Greenfield or next system: stack blueprint, templates, target diagrams | blueprint | blueprint-generator |
| "Should we move off our current stack" / migrate | learner first (current), then evaluate, then blueprint (target) | sibling, then both, in order |
| Target architecture from a current-state diagnosis | blueprint, using the diagnosis as constraints | target-from-current, then blueprint |
The evaluator ships Python scripts and sample inputs. Run them from specialities/stack-evaluator/, for example python scripts/stack_comparator.py --help. If Python is unavailable, follow the guide's workflows by hand and say so.
Pipeline: from current facts to a target pick
- Current state (sibling). If a repo exists and facts are missing, load
codebase-learner. Do not re-inventory the tree here. - Evaluate. stack-evaluator with current-state as the baseline plus the user's constraints (team skills, budget, compliance, time).
- Blueprint the target. blueprint-generator for the next stack: versions to adopt, patterns to require, templates for new code. How to consume a diagnosis: target-from-current.
- Report. One recommendation with the evidence behind it, the confidence level, and what would change the answer.
Rules that hold across both guides
- Facts from the sibling (or the user), estimates labeled. Detected versions and patterns come from learner output or the user; costs, team size and traffic come from the user or are labeled as assumptions. Do not present a guessed current stack as a scan of this skill.
- Say how sure you are. Mark anything inferred rather than read, and any score built on missing data.
- Recommend, do not survey. End with one pick and the deciding reasons, not a table of equal options.
- Do not invent current-state docs.
ARCHITECTURE.md, onboarding guides, and smell reports are learner deliverables.
Bundled helpers (stack-evaluator)
Run from specialities/stack-evaluator/. format_detector.py detects the input format and report_generator.py renders the final report; both are called by the other scripts. The assets/ JSON files are sample inputs (sample_input_structured.json, sample_input_text.json) and an expected output (expected_output_comparison.json) for trying the scripts.
Related skills
codebase-learner: current-state facts are missing.challenge-me: stress-test the pick before you commit.super-architecture: choose the architecture style for the target stack.write-plan: turn the migration into a step-by-step plan.create-tickets: split the plan into tickets.
Done when
- Current-state work was sent to
codebase-learnerwhen that was the job. - The guide that matches the job was opened, and the second only when the job needs both.
- Every current-stack fact cites learner output or a file the user provided; every estimate is labeled as one.
- A comparison ends in a recommendation with its confidence.
Breaking renames
technology-stack-blueprint-generator→ blueprint speciality (now target / greenfield, not a current-repo inventory)tech-stack-evaluator→ evaluate specialityimprove-codebase-architecture(target stack / migration / next architecture) → this skill; current smells →codebase-learnerdiagnose
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
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.