agentleFS
educlopezeduclopez/mallard/skills/ps-console/SKILL.md

ps-console

Skill4 starsChanged 13 days agoMITView on GitHub

Run PrestaShop maintenance and one-off scripts inside a project's local Lando container: clear the cache, run `bin/console` commands, and execute ad-hoc PHP that boots PrestaShop (read an Employee, check a Configuration value, list a hook, query a product through the classes). Use when the user says "limpia la caché", "cache clear", "bin/console", "ejecuta esto con PrestaShop cargado", "mira esta config de PS desde PHP", "haz un script rápido con la clase X". Local Lando only: never against PRE or PROD.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Check Lando is up first (lando info).

    line 24
  2. Very specific:

    All versions, including 1.7 where bin/console is limited or missing, clear Smarty, XML and media caches by bootstrapping the shop:

    line 35
  3. Very specific:

    If bin/console fails with a container/compile error, the Symfony cache is corrupt: remove var/cache/<env>/ and run cache:clear again.

    line 41
  4. Very specific:

    Use the project classes, not raw SQL, when you only read data: new Employee(13), Configuration::get("PS_SHOP_NAME"), …

    line 54

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

ps-console

Short, safe recipes for the PHP-in-Lando commands that come up in almost every PrestaShop session.

Rules

  • Local only. Run from the project root where .lando.yml lives. If the user wants this on a server, stop: servers have their own deploy steps (OPcache, PHP-FPM reload) and other people use them.
  • Scripts that write to the DB are fine locally, but say what they write. Throw-away scripts are never committed.
  • Check Lando is up first (lando info); if not, use the lando-check skill.

Cache

PrestaShop 8/9 (Symfony):

lando php bin/console cache:clear --env=prod 2>&1 | tail -3
lando php bin/console cache:clear --env=dev 2>&1 | tail -3     # when the project runs in dev mode

All versions, including 1.7 where bin/console is limited or missing, clear Smarty, XML and media caches by bootstrapping the shop:

lando php -r 'require "config/config.inc.php"; Tools::clearAllCache(); echo "cache cleared\n";'

If bin/console fails with a container/compile error, the Symfony cache is corrupt: remove var/cache/<env>/ and run cache:clear again.

Front-office template changes (.tpl) need the Smarty cache cleared (or "Force compilation" in Performance); CSS/JS also need the theme asset cache cleared (Media::clearCache() is included in clearAllCache).

One-off PHP with PrestaShop loaded

lando php -r 'require "config/config.inc.php"; /* your code */'

Notes that avoid the usual confusion:

  • CLI has no HTTP_HOST. On multistore or multi-domain projects set it before the require so the right shop and URLs resolve: $_SERVER["HTTP_HOST"]="<name>.lndo.site";.
  • Use the project classes, not raw SQL, when you only read data: new Employee(13), Configuration::get("PS_SHOP_NAME"), Product::getProductName(…). Use Db::getInstance()->executeS(...) for queries; the table prefix is _DB_PREFIX_.
  • For anything longer than a line, write a throw-away script inside the project (Lando mounts only the project directory), e.g. _tmp-check.php, run it with lando php _tmp-check.php, and delete it afterwards. Never leave it tracked; check git status before any commit.
  • Print results as plain text or json_encode, and keep them short. Do not echo secrets (_COOKIE_KEY_, DB password, API keys).

Admin / BO checks without a browser

  • Employee exists and is active: lando php -r 'require "config/config.inc.php"; $e=new Employee(13); echo $e->email," ",(int)$e->active,"\n";'
  • A module is installed/enabled: lando php -r 'require "config/config.inc.php"; var_dump(Module::isInstalled("<name>"), Module::isEnabled("<name>"));'
  • Hook registered modules: lando php -r 'require "config/config.inc.php"; print_r(array_column(Hook::getHookModuleExecList("<hookName>")?:[], "module"));'

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.