agentleFS
ImYourBoyRoyImYourBoyRoy/Portable_Web_toolkit/skills/portable-web-toolkit/SKILL.md

portable-web-toolkit

Skill2 starsChanged 4 months agoMITView on GitHub

Coordinate multi-capability work, deployment or release sequencing, and ambiguous operations in Astro and Cloudflare projects managed by Portable Web Toolkit. Use when the task crosses toolkit owners or needs routing and safety gates. Defer directly to a narrow skill when readiness, scaffolding, updating, Instagram fallback, or vectorization clearly owns the request. Do not use for unrelated or merely generic web work.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 11 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    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
  1. Distinctive:

    Use the project contract and deterministic toolkit commands without creating a parallel workflow.

    line 8
  2. Distinctive:

    If one narrow skill clearly owns the request, use it directly and do not load this router merely because toolkit management is established.

    line 11
  3. Distinctive:

    Read project contract whenever instructions, profiles, brand guidance, environment values, or generic skills may conflict.

    line 27
  4. Very specific:

    Run site-readiness when beginning material site work, after scaffolding, before release preparation, or when project state is uncertain.

    line 36
  5. Distinctive:

    Read its structured report before choosing fixes.

    line 38
  6. Very specific:

    Use --skip-network when policy or environment disallows external checks.

    line 40
  7. Distinctive:

    Read operations routing only after the task and deployment target are known.

    line 55
  8. Distinctive:

    Use repository-approved package, build, and deploy commands.

    line 60
  9. Distinctive:

    Treat staging and production as separate authorization boundaries.

    line 63
  10. Distinctive:

    Keep secrets out of command output, committed files, profiles, and reports.

    line 64
  11. Distinctive:

    Do not install host software, update the toolkit, reinstall skills, deploy, publish, or release merely because ordinary site work was …

    line 65
  12. Distinctive:

    Stop on unexplained profile conflicts, destructive generated-file churn, or incompatible toolkit versions.

    line 67
  13. Distinctive:

    Read toolkit maintenance only for toolkit updates, host setup, skill distribution, or toolkit publication.

    line 76

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

Portable Web Toolkit

Use the project contract and deterministic toolkit commands without creating a parallel workflow.

If one narrow skill clearly owns the request, use it directly and do not load this router merely because toolkit management is established.

Confirm toolkit management

Require at least one authoritative signal:

  • repository instructions establish Portable Web Toolkit
  • package scripts invoke Web_Toolkit commands
  • a compatible toolkit site profile governs the site
  • an established Web_Toolkit link is corroborated by configuration or docs
  • the user explicitly selects the toolkit

A folder name alone is not proof. If management is uncertain, inspect and report the evidence before imposing toolkit conventions.

Read project contract whenever instructions, profiles, brand guidance, environment values, or generic skills may conflict.

Establish current state

  1. Resolve the active client repository and applicable instructions.
  2. Preserve unrelated and uncommitted work.
  3. Locate the toolkit source, site profile, package manager, and supported project commands.
  4. Run site-readiness when beginning material site work, after scaffolding, before release preparation, or when project state is uncertain.
  5. Read its structured report before choosing fixes.

Use --skip-network when policy or environment disallows external checks. Readiness findings do not authorize dependency installation, infrastructure mutation, deployment, or toolkit updates.

Route to the narrow owner

NeedOwner
New toolkit-managed sitesite-starter
Project readiness and next actionssite-readiness
Public Instagram fallbackinstagram-clone
Wordmark or raster-to-SVG candidatevectorize-pipeline
Toolkit and skill version comparisontoolkit-update
Existing deterministic operationRelevant Web_Toolkit CLI

Read operations routing only after the task and deployment target are known.

Preserve mutation boundaries

  • Use repository-approved package, build, and deploy commands.
  • Audit and dry-run Cloudflare, DNS, cache, registrar, header, and hardening changes before an authorized apply.
  • Treat staging and production as separate authorization boundaries.
  • Keep secrets out of command output, committed files, profiles, and reports.
  • Do not install host software, update the toolkit, reinstall skills, deploy, publish, or release merely because ordinary site work was requested.
  • Stop on unexplained profile conflicts, destructive generated-file churn, or incompatible toolkit versions.

Complete with evidence

Report the management evidence, project authority followed, readiness state, toolkit commands used, files and environments changed, dry-run and live evidence, warnings, skipped checks, rollback path, and unresolved uncertainty.

Read toolkit maintenance only for toolkit updates, host setup, skill distribution, or toolkit publication.

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.