Skip to main content

pta-website-edits

Safe-edit playbook for changes requested through PTA Studio by a non-technical parent volunteer. Use for ANY content/copy/image/styling change to the Schweitzer PTA site. Defines the smallest-safe-change rule, the hard do-not-touch list (auth, Supabase, API routes, payments, config, dependencies, migrations, file deletion), and how to politely refuse anything that needs a developer.

Ir a la instalación

Datos de origen

Repositorio
craigm26/SchweitzerPTA
Última actividad en el origen
17 de julio de 2026 a las 02:54
Idioma detectado de SKILL.md
inglés
Estrellas
0
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
pta-website-edits
description
Safe-edit playbook for changes requested through PTA Studio by a non-technical parent volunteer. Use for ANY content/copy/image/styling change to the Schweitzer PTA site. Defines the smallest-safe-change rule, the hard do-not-touch list (auth, Supabase, API routes, payments, config, dependencies, migrations, file deletion), and how to politely refuse anything that needs a developer.
# Editing the PTA website safely (for a non-technical editor) The person asking is a **parent volunteer, not a developer**, using PTA Studio. She types what she wants in plain language; you make the change; she reviews a preview and Publishes it live. Your job is to make her intent real **without ever breaking the site or touching anything risky**. ## The one rule Make the **smallest change** that satisfies the request, keep the site building, and stop. When unsure between two readings, pick the simpler one and say what you assumed. ## Green — just do these - Change **text / copy / headings / button labels** on a page. - Swap or update **images** already referenced (or add an image to an existing gallery/section). - Adjust **simple styling** on existing elements: colors, spacing, font size, alignment, show/hide, reorder sections. - Update **wording** of existing components (Header/Footer/Card text, hero copy, about text). - Fix typos, dates in copy, contact text, event descriptions written as page content. Always: edit existing files, match the surrounding code/Tailwind style, keep it valid TSX. ## Red — never do these. Say it needs Craig, and change nothing. - **Auth & data plumbing:** `src/lib/supabase/**`, `src/lib/auth-context.tsx`, `src/middleware.ts`, anything about login, roles, sessions, or RLS. - **API routes:** anything under `src/app/api/**` (server behavior, data reads/writes). - **Database:** `supabase/schema.sql`, migrations, table/column changes. - **Payments/donations:** `src/app/api/donate/**`, Stripe keys or logic, `src/utils/stripe.ts`. - **Config & tooling:** `package.json`, `pnpm-lock.yaml`, `next.config.ts`, `vercel.json`, `tsconfig.json`, `.env*`, `.gitignore`, `.github/**`, `middleware`. - **Dependencies:** never add, remove, or upgrade a package. - **Deleting** pages, components, routes, or files. - **Git / deploy / dev server:** never commit, push, or start/stop anything — PTA Studio owns saving and publishing. ## When a request is red or impossible Don't half-do it and don't work around the rule. Make **no** file changes and end with a friendly, non-technical line, e.g.: > Done: This one changes how the website works behind the scenes, so it's safer for Craig > to do it — I didn't change anything. Everything's still just as it was. (Keep the `Done:` prefix so PTA Studio can show her a clean summary.) ## Worked examples - *"Change the homepage welcome text to 'Welcome, Wildcat families!'"* → edit the hero copy in `src/app/page.tsx`. ✅ - *"Make the Donate button green."* → change the Tailwind classes on that button. ✅ (Do **not** touch the donation API or Stripe.) - *"Add next Friday's bake sale to the events page."* → if events are page content, edit the content; if events come from the database/API, that's **red** — tell her it's added through the admin area and needs Craig or the admin login, and change nothing. - *"Let parents log in with Google."* / *"Change what the newsletter form saves."* → red. Explain it needs Craig; change nothing. ## Reminders - The dev server is already running and auto-refreshes — never start it. - If you truly cannot find what she means, make your best small guess on the most likely page and say what you assumed, rather than doing nothing or doing something drastic.
Ver en GitHub