verify-ps-project
Skill4 starsChanged 13 days agoMITView on GitHub
Prove a change works in the real local PrestaShop storefront: bring Lando up, run a read-only doctor, drive home, category, product page, cart and checkout in a browser, capture evidence, clean up. Also keeps the project's feature map honest (maintenance pass). Use when the user says "verifica este cambio en local", "prueba el checkout", "demuestra que funciona", "haz una pasada de verificación", "revisa que el mapa de features sigue vigente", or before declaring done a theme, module or checkout change.
In this repository37 other files it gives its agents.
- blast-radiusSkill
- elementflow-kbSkill
- gitlab-changelog-releaseSkill
- gitlab-ci-quality-gatesSkill
- gitlab-project-bootstrapSkill
- gitlab-security-setupSkill
- gitlab-wiki-bootstrapSkill
- lando-checkSkill
- lando-img-placeholderSkill
- lando-mail-smtpSkill
- lando-setupSkill
- mallard-releaseSkill
- mr-flowSkill
- no-commentsSkill
- paginated-report-pdfSkill
- panda-kbSkill
- ploi-prestashop-deploySkill
- prestashop-kbSkill
- ps-consoleSkill
- ps-css-buildSkill
- ps-demo-userSkill
- ps-email-previewSkill
- ps-image-regenSkill
- ps-invoice-previewSkill
- ps-new-projectSkill
- ps-one-page-checkoutSkill
- ps-project-docSkill
- ps-security-auditSkill
- ps-storefront-polishSkill
- ps-theme-cacheSkill
- ps-translateSkill
- ps-view-transitionsSkill
- ps-watchSkill
- reflectSkill
- show-me-your-workSkill
- skill-authorSkill
- task-contextSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
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 20
Write everything for an agent that reads it cold: real selectors and URLs from this project, no placeholders.
- Very specific: line 24
Run lando-check. Ready means the shop answers 200 on its real local URL, not that a container exists.
- Distinctive: line 48
After clicking "Añadir al carrito", wait until the cart counter changes (or the modal appears) before navigating: the add is AJAX, and …
- Distinctive: line 58
Stop only what this run started.
- Very specific: line 62
Keep .verify/features/<feature>.md per user-facing feature (3-5 to start): what it is, how to reach it, how to drive it, what proves it …
- Distinctive: line 66
Read the map index; fix missing, duplicate or dead entries.
≈ “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
verify-ps-project
Drives the real storefront the way a customer does and leaves proof. Adapted from pstack's create-verification-skill / maintain-verification-skill. It does not set Lando up (lando-setup), fix Lando (lando-check) or edit product code.
Write everything for an agent that reads it cold: real selectors and URLs from this project, no placeholders.
1. Launch
- Run
lando-check. Ready means the shop answers200on its real local URL, not that a container exists. - Confirm the DB is usable:
lando ssh -c "php bin/console doctrine:query:sql 'SELECT 1'"(PS 8/9) or open the BO login. - Pick the browser tool already available:
agent-browserskill, Chrome DevTools MCP or Claude in Chrome. Do not install Playwright just for this.
2. Doctor (read-only, run first whenever something looks off)
- Right project:
.lando.ymlname matches the repo directory. - Right URL: the shop does not redirect to the production domain (
/ps-urlif it does). - Right theme: the active child theme is the one under test.
- Port and containers are ours: never drive an instance you did not start or confirm.
- Child theme CSS is built: the compiled file (usually
themes/<child>/assets/css/custom.css) exists and is not empty. A 404 or 0-byte file here means the CSS build was never run (ps-css-build).
3. Drive
Cover the flows a customer touches, in order. Prefer stable handles (data-*, ids, route paths, ARIA labels) over coordinates.
| Flow | Check |
| Home | Loads, no console errors, no 404 assets |
| Category | Listing renders, sort and filter change the list |
| Product | Gallery, price, combination switch, add to cart |
| Cart | Line appears, quantity change updates totals |
| Checkout | Reaches each step; demo user via /ps-customer or ps-demo-user; stop before real payment |
After clicking "Añadir al carrito", wait until the cart counter changes (or the modal appears) before navigating: the add is AJAX, and navigating early leaves an empty cart that looks like a failure.
Side effects count: check the cart row, order record or email in Mailhog alongside what is visible. No test-only endpoints.
4. Evidence
Save to .verify/evidence/<YYYY-MM-DD-HHMM>/ in the project: one screenshot per step plus console.txt with errors. Some browser MCPs only write files inside their configured workspace roots and refuse the project path; then take the screenshot without filePath, use the path the tool returns, and copy that file into .verify/ with cp. Keep .verify/ out of git via .git/info/exclude, not the shared .gitignore. Report one line per flow: pass, fail or not driven, with the evidence path.
5. Cleanup
Stop only what this run started. Never kill by process name. Remove scratch data created for the run (demo customer, test cart). Evidence stays.
6. Feature map and maintenance
Keep .verify/features/<feature>.md per user-facing feature (3-5 to start): what it is, how to reach it, how to drive it, what proves it works. Seed it from the routes and menus you actually see.
Maintenance pass (when asked, not on a schedule):
- Read the map index; fix missing, duplicate or dead entries.
- For each feature, read the source entry points, then drive it once live.
- Classify each difference: wrong description is doc drift (fix the map); working behavior the flow cannot drive is a harness gap (fix it); broken behavior is a product bug (report it, do not hide it in docs).
- Show the proposed corrections and wait for the user's OK before editing. Never edit product code in this pass.
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.