Skills map
Reusable skills across projects
Every project should be able to produce reusable skills: build loops, UX decisions, data patterns, and product judgment that can move into the next project.
The point of the knowledge base is to turn scattered build pain into reusable operating memory, then make that memory one click away from becoming a skill.
Hard skills
Vite release loop: dev speed, build checks, route/base-path discipline.
Firebase realtime memory: rooms, game state, reconnects, cleanup logic.
UX implementation: audio controls, button states, loading states, table feedback.
Product skills
Know which details make a browser game feel like a real room.
Use the crew story as product context, not just decorative copy.
Keep project learnings fileable so they compound into the next build.
Basic requirements for a skill
It must have a clear trigger situation: when should this skill be suggested or used?
It must contain a reusable rule: what judgment should transfer to another project?
It must include executable steps: what should the user or agent do next?
It must include checks: how do we know the skill was applied correctly?
It must name the source project: where did this skill come from?
It must name anti-patterns: what should this skill prevent people from doing?
It must have tags for classification, retrieval, and future auto-suggestion.
What still needs to be added
Each skill should record source project, trigger situation, reusable rule, anti-pattern, and proof from the build.
A skill is not a diary note. It needs a repeatable action pattern: when to use it, what to check, and what output it should create.
The wiki should separate raw observation, refined principle, and executable skill so future users do not confuse memory with instruction.
One-click skillization flow
Step 1: user highlights or selects a wiki note, build log, bug fix, or project decision.
Step 2: the system extracts the skill candidate: trigger, context, rule, steps, warnings, examples, source link, and confidence.
Step 3: the user sees a preview card before saving. One click should never silently publish a skill without review.
Step 4: after approval, save it as a Skill Card with tags like Vite, Firebase, UX feedback, routing, analytics, or deployment.
Step 5: future project pages can pull those Skill Cards back in when the same trigger appears.
Minimum data shape
title: the skill name, written as an action, not a vague topic.
trigger: the situation where this skill should be suggested.
reusableRule: the principle or judgment that should transfer across projects.
procedure: the repeatable execution steps.
checks: how to verify the skill was applied correctly.
sourceProject: the project where this skill was learned.
antiPatterns: the mistakes this skill should prevent.
tags: categories for retrieval, filtering, and auto-suggestion.
sources: links back to the original project note or build log.
status: draft, reviewed, active, retired, or superseded.