De eerste werkbare PadelOS skill staat nu klaar, inclusief jouw volledige commandocatalogus van 1–150.
Ik heb drie dingen vastgelegd: SKILL.md als compacte router/control plane, references/COMMANDS.md als canonieke commandotaal, en agents/openai.yaml voor de Skill-interface. De skill is daarna gevalideerd en succesvol verpakt volgens de Skill-structuur.
Belangrijke uitbreiding: combinaties worden nu als één programma gelezen. Bijvoorbeeld mes + padelos + sheet + schema + codegs + index + login + profile + observation + lessonreport + deploy + qa. Ook zijn normalisaties toegevoegd zoals code.gs → codegs, index.html → index, observations → observation, footwork → voetenwerk en socrates → socratic. Onbekende commando's mogen niet stil verdwijnen maar worden gemarkeerd als UNRESOLVED COMMAND.
De volgende logische uitbreiding van deze skill is om naast COMMANDS.md de gespecialiseerde bestanden toe te voegen die je eerder voor PadelStudy wilde: strokes.md, tactics.md, nbf.md, sites.md, sheet.md, script.md, schema.md, exports.md, credits.md, login.md, planplay.md, socratic.md, observations.md, lessonreport.md en uiteindelijk de build_lesson.py + HTML-assets. Daarmee wordt mes + padelos + ... niet alleen een commandotaal, maar een volledige herbruikbare PadelStudy / PadelOS bouwmachine.
Hier is een realistische prompt waarmee de nieuwe PadelOS-skill goed tot zijn recht komt:
padelstudy + padelos + mes + sss + newproject + lesson + service + nbf:timing + a1a2b + socratic5 + observation + sheet + schema + codegs + index + login + profile + settings + exporttxt + credits + qa + status + next
Maak voor PadelStudy een mobiele “Service Timing Lab”. Een trainer moet een speler kunnen laten oefenen met A1, A2 en B, objectieve observaties kunnen opslaan en apart daarvan een interpretatie kunnen noteren. Focus op timing bij de service en het herstel naar de volgende positie.
De skill leest zo’n opdracht daadwerkelijk als een command program. padelstudy activeert coaching/lesontwikkeling, padelos de operationele kant en mes + sss maakt er één Site + Sheet + Script-systeem van. De catalogus schrijft bovendien de volgorde voor: eerst project/schema, daarna backend en gebruikersfundament, vervolgens domeinmodule/UI, exports, QA, status en uiteindelijk één beste vervolgstap.
Project: PadelStudy · Service Timing Lab
Situatie: service
NBF: timing
Leermodel: A1 → A2 → B → observeren → Socratische reflectie.
Het SMART-doel in het voorbeeld is: de speler serveert 8 van 10 ballen gecontroleerd, gebruikt een herkenbaar contactmoment vóór het lichaam, herstelt meteen naar de afgesproken positie en kan uitleggen waarom het gekozen tempo passend was.
A1 is bewust vast en uitvoerbaar: 10 cross-services met één ritme. A2 verandert naar waarnemen en kiezen: de returnpositie verandert en de speler kiest tempo/richting. B maakt dat spelrealistisch door punten werkelijk vanuit de service te starten. Dat volgt precies de skillregel dat A1 fixed/executable, A2 observe-and-choose en B game-realistic moet zijn.
De observatie-opbouw gebruikt twee afzonderlijke velden:
Objectief: bijvoorbeeld 7/10 services in; 6× contact vóór lichaam; 4× herstel vóór returncontact.
Interpretatie: bijvoorbeeld onder druk versnelt het ritme waardoor herstel later begint.
Dat is expres gescheiden, omdat PadelOS voorschrijft dat observaties objectief blijven en interpretaties apart worden opgeslagen.
De Socratische laag bevat vijf concrete vragen, waaronder: Wat zag je vóór je begon?, Welke service gaf de beste volgende bal? en Wat ga je in de volgende drie punten bewust herhalen?
Ik heb de skill ook echt doorgetrokken naar een complete kleine build:
Index.html — mobiele interface met Les / Observatie / Profiel.
Code.gs — bootstrap, Sheet-initialisatie, observatie-opslag en TXT-export.
SHEET_SCHEMA.md — canonieke tabbladen en velden.
README.md — installatie, startupflow en QA-criteria.
De backend maakt deze tabs:
Settings · Users · Sessions · Lessons · Observations
De startupflow is bewust eenvoudig:
Sheet → psEnsureSheets() → Apps Script backend → Index → Web App → eventueel Google Sites.
Login/sessions zijn in dit kleine demonstratieproject als foundation/schema opgenomen; een echte mailcode/password-authflow zou de volgende uitbreiding zijn. Ik heb dus niet gedaan alsof vier regels code al veilige authenticatie vormen.
DONE
Command parsing, PadelStudy + PadelOS routing, MES/SSS-architectuur, service/timing-lesmodel, A1/A2/B, Socratische 5, observatiemodel, Sheet-schema, Apps Script, mobiele Index en TXT-export met credits.
WORKING
Geen onderdelen meer nodig voor deze demonstratie.
TODO
Volledige mailcode/password-authenticatie, personal edits/history, uitgebreid lesson library-systeem en echte Google Sites-integratie.
BLOCKED
Geen blokkade voor de demo. Voor live deployment zou alleen een echte Google Sheet/Apps Script deployment nodig zijn.
NEXT
De hoogste waarde is nu: dezelfde skill gebruiken om van deze mini-demo een herbruikbare PadelStudy MES-kern te maken waarop Service, Return, Achterspel, Netspel en Transitie allemaal als modules kunnen draaien.
Je kunt de volledige gegenereerde voorbeeldbuild hier bekijken:
Download PadelOS Skill End-to-End Example
Afzonderlijk:
Index.html
Code.gs
Sheet schema
README
Dit laat meteen het belangrijkste verschil zien: PadelOS is niet alleen een promptbibliotheek. De skill gebruikt jouw commando’s als een compacte programmeertaal voor coaching én systeemontwikkeling.
Commands may be combined with +. Parameters may follow with : such as nbf:timing, level:7, stroke:bandeja.
padelstudy — route the task through the PadelStudy learning/coaching model.
padelos — route the task through the operational PadelOS model.
mes — build a complete mobile-first Site + Sheet + Script application.
sss — apply Site + Sheet + Script architecture.
newproject — define project identity, users, data and first milestone.
status — show DONE / WORKING / TODO / BLOCKED / NEXT.
next — choose one best next action.
whatnow — answer what, where, when, how, why, with what and who.
roadmap — make phases, milestones and acceptance criteria.
focus — reduce to the top 1–3 priorities.
rules — consolidate project rules.
version — create changelog/version note.
compareversions — compare two versions.
release — prepare release/deploy checklist.
qa — run quality checks.
audit — inspect data, permissions and important actions.
backup — create portable backup plan/output.
restore — restore from a validated backup.
merge — merge imported data with conflict rules.
migrate — move old schema/data to a newer version.
site — define site structure and canonical URL behavior.
sites — apply mandatory engineering/site rules.
index — build or improve Index.html.
design — define visual system and components.
responsive — optimize phone/tablet/desktop/embed.
a11y — improve accessibility and keyboard/focus behavior.
nav — design navigation/tabs/view flow.
search — add search/filter/sort.
dashboard — build role-appropriate dashboard.
sheet — design or build Google Sheet tabs.
schema — define canonical fields and relations.
seed — add safe initial reference rows/settings.
codegs — build Apps Script backend.
script — apply backend architecture rules.
deploy — prepare Apps Script web-app deployment.
bootstrap — design startup/load call.
diagnostics — show version, backend, tab and load state.
login — build real login/logout.
mailcode — build email-code verification.
recover — build password reset/recovery.
sessions — build session restore/expiry/revoke.
profile — build profile CRUD.
settings — build user display and app settings.
roles — define user roles.
permissions — define action/resource authorization.
users — manage users/status/access.
crud — build create/read/update/archive/delete.
history — build record history.
favorites — build user favorites.
personaledit — store user edits without overwriting source.
import — import with parse/validate/preview/new-or-merge.
export — export current requested scope.
exportjson — create portable JSON.
exporttxt — create readable TXT.
exportcsv — create UTF-8 CSV safely.
exporthtml — create standalone readable HTML.
exportpdf — prepare print/PDF output.
exportdocx — prepare DOCX when useful.
exportxlsx — prepare XLSX when useful.
whatsapp — open prefilled WhatsApp composer.
copy — copy generated scope text.
share — build permission-aware share flow.
speak — add text-to-speech.
stopvoice — stop speech.
credits — apply visible project credits.
aco — apply always-visible credits internally; hide acronym from users.
library — build a dynamic content/card library.
cards — build coaching/lesson card viewer.
random — randomly select current library item(s).
reload — reload authoritative content from Sheet.
strokes — use full padel stroke library.
stroke — analyze or build around one stroke.
service — focus service situation.
return — focus return situation.
achterspel — focus back-court play.
netspel — focus net play.
transitie — focus transition play.
intention — identify game intention.
scoren — focus scoring intention.
uitlokken — focus provoking a weaker reply.
opbouwen — focus building/manoeuvring.
neutraliseren — focus neutralising/recovering.
voorkomen — focus prevention/risk reduction.
nbf — select or analyze level-determining factors.
vastheid — focus consistency.
precisie — focus precision.
vaart — focus ball pace.
plaatsing — focus placement.
richting — focus direction.
hoogte — focus trajectory height.
diepte — focus depth.
spin — focus effect/spin.
timing — focus decision/contact timing.
balans — focus balance.
voetenwerk — focus footwork.
positie — focus position and recovery.
preparation — analyze shot preparation.
racketface — analyze racket-face/edge orientation.
contact — analyze spacing and contact point.
recovery — analyze next preparation and court recovery.
lesson — create or improve a complete lesson.
lessoncard — create one PlanPlay lesson card.
planplay — apply PlanPlay card standard.
a1 — create fixed executable A1 form.
a2 — create observe-and-choose A2 form.
b — create game-realistic B form.
a1a2b — build all three phases coherently.
smartgoal — write observable measurable lesson goal.
beginsituatie — define starting situation.
demo — define concise demonstration.
freeze — use freeze observation where relevant.
gras — apply GRAS/Freeze framework where relevant.
temporiseren — analyze timing/tempo and tactical patience.
partner — focus pair spacing and communication.
communication — create partner/player/trainer communication.
socratic — use Socratic coaching.
socratic3 — ask 3 focused Socratic questions.
socratic5 — ask 5 focused Socratic questions.
socratic8 — ask 8 focused Socratic questions.
socratic100 — build a structured 100-question bank.
observe — record objective observation.
interpret — separate possible interpretation.
observation — create observation record/form.
lessonreport — generate lesson report.
progress — compare development over time.
goal — create learning goal.
goals — manage learning goals.
action — define one concrete development action.
reflect — run reflection and transfer.
evaluate — evaluate lesson/player result.
player — create/analyze player profile and development.
players — build player module.
trainer — build trainer module.
team — build team/pair module.
planning — build lesson planning.
agenda — build agenda/calendar model.
lessonrequest — build lesson request flow.
attendance — track attendance/cancellations.
location — build club/location/court data.
materials — track lesson materials.
matchplan — create compact match plan.
matchreview — review match evidence and next plan.
exercise — create one exercise.
exercises — build exercise library.
report — create structured report.
admin — build administration overview.
finance — connect operational finance only when requested.
aihelp — propose useful AI assistance from current context.
research — verify current external/official information when needed.
!! — continue the current task from the last useful point.
padelstudy + lesson + service + nbf:timing + a1a2b + socratic5 + export
padelos + sheet + schema + codegs + index + login + profile + observations + lessonreport + deploy + qa
matchplan + partner + temporiseren + richting + lob + reflect
planplay + cards + library + favorites + personaledit + whatsapp + credits
!! — continue the current build without restarting.
Build padel systems that connect game situation → perception → intention → choice → technique → execution → result → recovery → reflection → next goal.
Treat PadelStudy as the learning/coaching layer and PadelOS as the operational/data layer. Reuse the user's Site + Sheet + Script standards instead of rebuilding infrastructure from scratch.
Detect whether the task is primarily padel content, lesson/coaching, observation/progress, match/tactics, site/app build, or PadelOS operations.
Read only the relevant references below.
Preserve existing project names, URLs, Sheet IDs, deploy URLs and user conventions when supplied.
Distinguish facts/observations from interpretation and advice.
Prefer one coherent build over patch-on-patch additions.
Do not claim login, mail, Sheet sync, exports or deploy are working until implemented and tested.
Read references/strokes.md for stroke vocabulary, preparation and execution.
Read references/tactics.md for game situations, intentions, choices, partner communication and temporising.
Read references/nbf.md for level-determining factors and observation dimensions.
Read references/lessons.md for lesson cards, A1/A2/B, learning goals and PlanPlay.
Read references/socratic.md for Socratic coaching and question design.
Read references/observations.md for observation, progress, reports and next-step logic.
Read references/data-model.md for PadelOS entities, Sheet tabs and relationships.
Read references/site.md for the recommended build order.
Read references/sites.md for mandatory Site + Sheet + Script engineering rules.
Read references/sheet.md for workbook design and schemas.
Read references/script.md for Apps Script backend patterns.
Read references/export.md for export, backup and WhatsApp rules.
Read references/credits.md for visible credits and canonical-link behavior.
Read references/commands.md when the user invokes compact commands or asks what can be built.
Read references/workflow.md for end-to-end project flow and definition of done.
Use these five main game situations unless the task specifies another official/current framework:
SERVICE · RETURN · ACHTERSPEL · NETSPEL · TRANSITIE
Use these five intentions:
SCOREN · UITLOKKEN · OPBOUWEN · NEUTRALISEREN · VOORKOMEN
Use the coaching chain:
ZIEN → BEDOELEN → KIEZEN → UITVOEREN → CONTROLEREN → HERSTELLEN → REFLECTEREN → VOLGENDE STAP
Use A1/A2/B as:
A1 — fixed, executable, low decision load.
A2 — observe and choose.
B — game-realistic decision and consequence.
Use GRAS/Freeze or another project framework only when relevant to the current lesson or source material. Never force technical cues that conflict with current official coaching material.
For a complete lesson card include, when relevant:
ID · title · player/group · level · main game situation · intention · stroke · NBF · learning goal · start situation · key question · demonstration · tactical choice · technical cues · A1 · A2 · B · coach questions · differentiation · safety · evaluation · emergency card · next step · tags · version
Keep instruction economical: normally one question, one choice, one technical cue, then execute again.
Use scripts/build_lesson.py when deterministic generation from structured JSON is useful. Use assets/lesson-template.html as the starter asset for an embeddable lesson view.
For operational systems consider only the modules needed for the request:
Users · Roles · Profiles · Players · Parents/Guardians · Trainers · Teams · Locations · Courts · Availability · Lesson Requests · Lesson Series · Lesson Groups · Lessons · Attendance · Lesson Preparation · Exercises · Strokes · Game Situations · Intentions · Learning Lines · Learning Goals · Player Goals · Evaluations · Observations · Reports · Progress · Actions · Messages · Notifications · Products · Packages · Invoices · Payments · Materials · Audit Log
Keep source/reference content separate from user-owned edits and observations.
When building a production PadelStudy/PadelOS site, default to:
Google Sites canonical page → Apps Script Web App (Index.html) → Apps Script backend → Google Sheet
Minimum engineering behavior:
mobile-first and Google Sites iframe-safe;
clear backend/loading/error state;
real registration/login when auth is requested;
stable IDs and server-side authorization;
profile/settings persistence;
Sheet-authoritative production data;
import/export and backup;
WhatsApp composer, never auto-send;
visible canonical site link and credits;
deploy instructions and end-to-end QA.
Always separate:
Observation — what was seen/heard/measured.
Interpretation — possible meaning.
Question — invites learner thinking.
Intervention — one practical change/experiment.
Result — what changed.
Next step — one concrete continuation.
Prefer questions about perception, intention, options, choice, result and transfer over questions that hide the answer.
Commands can be combined, for example:
padelstudy + lesson + service + nbf:timing + a1a2b + socratic5 + export + qa
or:
padelos + sheet + schema + codegs + index + login + profile + observations + lessonreport + deploy
When the user writes !!, continue the current build from the last useful point without asking for confirmation unless a genuinely missing external identifier blocks execution.
Before calling a build complete, verify:
requested padel content is internally coherent;
observations are not presented as facts when inferred;
card IDs are stable/unique;
mobile navigation and controls work;
Sheet headers match backend expectations;
create/read/update/archive/delete behavior is explicit;
auth secrets never appear in client HTML or export;
settings survive refresh when promised;
exports contain real content and canonical link;
WhatsApp opens a prefilled composer and does not send automatically;
Google Sites embed is tested separately from direct /exec;
a new Apps Script version is deployed after code changes;
current official rules/protocols override older derived training material when they differ.
For substantial work return:
Goal
Current working state
Padel model
Site/app structure
Sheet/data structure
Apps Script/API
User flow and permissions
Import/export/credits
QA/deploy
Next step
Favor a complete clean version over incremental patches.
Ik ga dit opbouwen als één PadelOS / PadelStudy master-skill: eerst haal ik de terugkerende patronen uit je eerdere projecten en gesprekken, daarna zet ik die om in een duidelijke Skill-structuur met aparte MD-bestanden voor site, Sheet, Apps Script, exports, credits, padelinhoud en een commandocatalogus van minimaal 100 opdrachten.
Ik ga dit opbouwen als één PadelOS / PadelStudy master-skill:
Gepersonaliseerde PadelOS-projecten en herbruikbare sitefuncties beoordeeld
Ik heb al een belangrijke basis teruggevonden: je hebt feitelijk al een algemene GODOGOOD Project OS-skill, plus aparte SITE.md en SITES.md standaarden. Voor PadelStudy ga ik die niet dupliceren, maar als technische onderlaag gebruiken en daarboven de padelspecifieke kennislaag zetten: slagen, tactiek, NBF, Socratisch coachen, observaties, leskaarten, wedstrijdplannen en voortgang.
Used skill-creator skill
De gevonden PadelStudy-basis is veel rijker dan alleen “slagen”. De PlanPlay-standaard heeft al 360 kaarten (24 slagen × 12 NBF + spelsituatie- en overzichtskaarten), met de vaste leerlijn zien → bedoelen → kiezen → uitvoeren → controleren en A1/A2/B-opbouw. Daarnaast bestaat er al een uitgebreid PadelOS-datamodel voor spelers, trainers, lessen, lesvoorbereidingen, oefeningen, leerdoelen, evaluaties en observaties.
De technische standaard staat ook al stevig: Google Sites → Apps Script Web App (Index.html) → Code.gs → Google Sheet, met echte login/mailcode, profiel, CRUD, settings, import/export, WhatsApp, credits, deploy en end-to-end tests. Ik maak de PadelStudy-skill daarom als een bovenlaag die deze SSS-standaard aanroept, zodat we niet telkens opnieuw dezelfde techniek hoeven uit te leggen.