@ketecode/loom 0.0.0-stage → 0.1.0

package/skills/pci-dss-scope/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: pci-dss-scope
+description: Shrinks PCI DSS scope by keeping cardholder data off your own systems, using processor-hosted payment pages, redirects or iframe hosted fields, provider tokens instead of card numbers, strict rules on what never to log or store (full PAN, CVV, track data, PIN), and a high-level guide to which self-assessment questionnaire (SAQ A, A-EP, D and others) the design points to, with a clear not-legal-advice and not-QSA line. Use when designing card checkout, deciding between hosted fields and a custom card form, finding card numbers in logs or databases, or estimating PCI effort for a merchant.
+license: MIT
+compatibility: Any Agent Skills host. Works with any card processor (Stripe, Adyen, Paystack, Flutterwave, Braintree and others). Standard detail lives in references/saq-and-data.md and must be checked against the PCI SSC document library.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: compliance
+  kete-loom/risk: writes-files
+  kete-loom/owner: "Kete-org"
+---
+
+# PCI DSS scope
+
+The cheapest PCI DSS control is card data that never touches your systems. Design so the browser or app sends card details straight to the processor, your servers only ever see a token, and nothing you run can read or alter the card form.
+
+## Boundary: this is not legal or assessor advice
+
+- You help with architecture and code. Your acquirer (the merchant's bank) decides which validation the merchant must do, and a Qualified Security Assessor (QSA) or the acquirer decides the final scope and SAQ type.
+- Say so once when the user asks "are we compliant" or "which SAQ", give the engineering view, and tell them to confirm with the acquirer or QSA.
+- Never state that a system "is PCI compliant". Say what is in scope, what was removed from scope, and what remains.
+
+## Step 1: find the card data flow
+
+Search the codebase and config for:
+
+- Card form fields: `card_number`, `cardNumber`, `pan`, `cvv`, `cvc`, `expiry`, `exp_month`, inputs with `autocomplete="cc-number"` or `cc-csc`.
+- Server endpoints or models that accept or store those fields, and any calls to processor "raw card" APIs (direct card charge, server-side tokenisation with raw PAN).
+- Logs, error trackers, analytics, session replay, support tooling and data warehouse tables that could capture request bodies on checkout pages.
+- Mobile apps: native card fields posting to your API instead of the processor SDK.
+
+Draw the flow: where card data is entered, which system receives it first, and where tokens go.
+
+## Step 2: choose the lowest-scope pattern
+
+Prefer, in this order:
+
+1. **Redirect to a processor-hosted payment page** (for example Stripe Checkout, Paystack or Flutterwave hosted checkout, Adyen Hosted Checkout). Card entry happens entirely on the processor's domain.
+2. **Processor iframe or hosted fields** (for example Stripe Elements, Adyen Drop-in or Components, Braintree Hosted Fields). Each card field is an iframe served by the processor; your page never has the card values.
+3. **Processor mobile SDK** with its own card UI, which returns a token or payment method id.
+4. **Your own card form that posts directly to the processor with JavaScript** (direct post, or your script calling a tokenisation API). Your page can read the card data, so your web server is in scope (typically SAQ A-EP territory).
+5. **Card data through your servers** (your API receives the PAN). This brings full scope (SAQ D or an onsite assessment). **Stop and ask the user** for the business reason before building it, and recommend 1 to 3 instead.
+
+When asked to "add a card form", build option 1 or 2 unless the user gives a reason not to.
+
+## Step 3: tokens, not card numbers
+
+- Store only the processor's token or payment method id, plus display data the processor returns: brand, last four digits, expiry month and year.
+- Use the processor's customer and saved-payment-method APIs for repeat charges and subscriptions. Never build your own card vault.
+- Webhooks and API responses may contain masked card data; persist only the fields you need.
+- If a legacy table already holds full PANs, **stop and tell the user**. Plan a migration to processor tokens, then securely delete the PAN column and its backups. Don't quietly drop the data.
+
+## Step 4: what never to log or store
+
+Sensitive authentication data must never be stored after authorisation, even encrypted:
+
+- CVV, CVC, CVV2, CID (the 3 or 4 digit card verification code)
+- Full magnetic stripe or chip track data
+- PIN or PIN block
+
+Never log or store a full PAN (card number) in your systems when using the patterns above. In code:
+
+- Add a redaction filter to the logger, error tracker and APM that masks any 13 to 19 digit sequence passing a Luhn check, and drops fields named like the ones in Step 1. Test it with a known test card number such as `4242424242424242`.
+- Turn off request body capture on checkout routes in error trackers and session replay.
+- Never put card data in URLs, query strings, analytics events, emails, tickets or AI prompts.
+- If a PAN must be shown, show at most the BIN (first six or eight digits) and last four; usually last four is enough.
+- Use only the processor's documented test card numbers in tests and fixtures, never real cards.
+
+## Step 5: protect the payment page itself
+
+Even with a redirect or iframe, the page that loads or links to the payment form can be attacked (for example a script that swaps the iframe or redirect URL for a fake one).
+
+- Serve the checkout page over HTTPS with a strict Content Security Policy that lists only your own and the processor's script and frame origins.
+- Keep third-party scripts (tag managers, chat widgets, A/B testing, ads) off checkout pages, or keep an inventory of each with a reason.
+- Use Subresource Integrity on static third-party scripts where the vendor supports it.
+- Monitor checkout pages for unexpected script or header changes.
+- These controls matter most for iframe or hosted-fields pages: SAQ A eligibility for an embedded form depends on the page not being open to script attacks (see `references/saq-and-data.md`). A full redirect avoids that question, which is one reason it ranks first.
+
+## Step 6: estimate the SAQ at a high level
+
+Use `references/saq-and-data.md` to map the chosen pattern to a likely SAQ, and list the eligibility conditions that must stay true. Present it as "likely SAQ, to confirm with your acquirer", never as a decision.
+
+## Never
+
+- Never accept, forward or store card numbers on your servers when a hosted option exists, without the user's explicit, informed agreement.
+- Never store CVV, track data or PIN, in any form, for any length of time after authorisation.
+- Never log raw request bodies on payment routes.
+- Never copy production payment data to test or staging.
+- Never use real card numbers in tests, demos or screenshots.
+
+## Report format
+
+```
+PCI scope review: <app or checkout>
+Card entry pattern: <redirect | hosted fields | SDK | direct post | server-side>
+Systems that see card data: <list, or "none: processor only">
+Likely SAQ (confirm with acquirer or QSA): <type> because <reason>
+Findings (highest risk first):
+  1. [High|Medium|Low] <what> at <file:line or system> -> <fix>
+Scope reductions available: <list>
+Not checked: <systems you could not see>
+This is engineering guidance, not legal or assessor advice.
+```

package/skills/pci-dss-scope/evals/triggers.json

@@ -0,0 +1,18 @@
+{
+  "should_trigger": [
+    "We want our own styled card form on checkout, how do we do that without pulling our servers into PCI scope?",
+    "I found full card numbers in our application logs, what do we do and how do we stop it?",
+    "Which PCI self-assessment questionnaire do we likely need if we use Stripe Elements?",
+    "Is it okay to save the CVV in the database so returning customers don't have to type it again?",
+    "Our mobile app posts card details to our API and then we call the processor, is that a PCI problem?",
+    "Hosted payment page or iframe fields: which keeps us at SAQ A?"
+  ],
+  "should_not_trigger": [
+    "Integrate Stripe subscriptions with trial periods and proration into our SaaS billing",
+    "My Paystack webhook signature check keeps failing, can you fix it?",
+    "We store patient insurance ids, do we need a BAA with our cloud provider?",
+    "Build a consent banner and data export for GDPR subject access requests",
+    "Review our payment service code for double charging and missing idempotency keys",
+    "Run a dependency audit on our checkout service and flag vulnerable npm packages"
+  ]
+}

package/skills/pci-dss-scope/references/saq-and-data.md

@@ -0,0 +1,36 @@
+# SAQ types and card data rules
+
+Engineering summary only. The PCI Security Standards Council (pcisecuritystandards.org) document library is the source of truth, and the acquirer decides which validation a merchant does. Check the current SAQ document and its eligibility criteria before telling a user which one applies.
+
+## Current standard
+
+- PCI DSS v4.0.1 (published June 2024) is the current version this skill was written against; v4.0 was retired at the end of 2024. Requirements marked "future-dated" in v4.x became mandatory on 31 March 2025.
+- SAQ A was revised in January 2025 (effective 31 March 2025): requirements 6.4.3 and 11.6.1 (payment page script management and change detection) and 12.3.1 were removed from it, and a new eligibility criterion was added that the merchant confirms its site is not susceptible to attacks from scripts that could affect the merchant's e-commerce systems. PCI SSC FAQ 1588 (February 2025) clarifies that this criterion concerns merchant pages that embed the processor's payment form (iframes), not pages that only redirect or link to the processor's page. Assessors differ on how much script control (page-level 6.4.3 and 11.6.1 style controls, or site-wide) satisfies it. Read the current SAQ A and FAQ, and let the acquirer or QSA decide.
+
+## Common SAQ types (high level)
+
+| SAQ | Typical situation | What it means for engineering |
+|---|---|---|
+| A | Card-not-present merchant that fully outsources all cardholder data functions: redirect to a processor page, or processor iframes for every card field. No electronic storage, processing or transmission of card data on merchant systems | Keep it that way: no card fields of your own, protect the page that hosts the iframe or redirect (Step 5 of the skill), minimal stored data |
+| A-EP | E-commerce merchant that outsources processing but whose website can affect the security of the payment transaction, for example a merchant page with direct post or JavaScript that handles card entry | Web servers serving the payment page are in scope: hardening, vulnerability scans, change control, script controls |
+| B | Imprint machines or standalone dial-out terminals, no electronic card data storage | Not usually an engineering concern |
+| B-IP | Standalone PTS-approved terminals with an IP connection to the processor | Network segmentation for the terminals |
+| C-VT | Manual entry, one transaction at a time, into a processor's virtual terminal in a browser | Locked-down workstations; no card data storage |
+| C | Payment application systems connected to the internet, no electronic storage | Larger scope: the payment application and its network |
+| P2PE | Validated point-to-point encryption hardware solution only | Use the listed P2PE solution as validated |
+| D (merchant) | Everything else, including any merchant that stores card data electronically or whose servers receive the PAN | Full PCI DSS requirements |
+| D (service provider) | Service providers eligible to self-assess | Full requirements for service providers |
+
+Higher-volume merchants may need an onsite assessment by a QSA and a Report on Compliance instead of an SAQ. The card brands and acquirer set those levels.
+
+## Data rules (PCI DSS v4.0.1 Requirement 3)
+
+| Data element | Store? | Notes |
+|---|---|---|
+| Primary account number (PAN) | Only if needed, and then unreadable | Masked when displayed: at most BIN (first six or eight) and last four. Unreadable when stored: strong cryptography, truncation, tokenisation or one-way hashes with controls |
+| Cardholder name, expiry, service code | Allowed if needed | Protected when stored with the PAN |
+| Full track data (stripe or chip) | Never after authorisation | Even if encrypted |
+| CVV2, CVC2, CID, CAV2 | Never after authorisation | Even if encrypted |
+| PIN, PIN block | Never after authorisation | Even if encrypted |
+
+Requirement 3.3.1 forbids keeping sensitive authentication data after authorisation. A processor token (for example a Stripe `pm_...` id or a Paystack `authorization_code`) is not a PAN, which is why tokenisation keeps systems out of scope.

package/skills/perl-patterns/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: perl-patterns
+description: Modern Perl 5 conventions for writing and restructuring code - strict and warnings, lexical scope, references and nested data, Moo or Moose classes, try/catch error handling, cpanfile with cpanm or Carton, Perl::Critic policy and taint-safe system calls. Use when writing new Perl, modernising a legacy .pl or .pm script, choosing between Moo and Moose, or deciding how a Perl program should manage CPAN dependencies and shell out safely.
+license: MIT
+compatibility: Any Agent Skills host. Needs perl 5.10 or newer; guidance marks what needs 5.36 or 5.40.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: writes-files
+  kete-loom/requires: "perl"
+  kete-loom/owner: "Kete-org"
+---
+
+# Modern Perl patterns
+
+Write Perl that a maintainer can read in five years. Match the project first, then apply these rules.
+
+## 0. Before you write
+
+1. Find the minimum perl the code must run on: `use v5.x` lines, `cpanfile` (`requires 'perl', '5.x'`), `Makefile.PL` (`MIN_PERL_VERSION`), `dist.ini`, CI matrix, and `perl -v` on the target host.
+2. Find the house OO system (Moo, Moose, Mouse, Object::Pad, hand-rolled `bless`) and the error style (die objects, Try::Tiny, `feature 'try'`). Keep using them.
+3. If the target perl is unknown and you need features newer than 5.10, **stop and ask** which perl ships in production.
+
+## 1. File header
+
+Every file starts with strict and warnings. Pick one form:
+
+```perl
+use v5.36;            # strict, warnings, say, signatures; disables indirect and multidimensional
+```
+
+```perl
+use strict;
+use warnings;         # for code that must run on perls older than 5.36
+```
+
+- `use v5.40` adds the stable `try` feature and the builtin bundle (`true`, `false`, `trim`, ...). `finally` blocks are still experimental there.
+- Modules end with `1;` unless the file uses `v5.38`+ (the `module_true` feature).
+- Add `use utf8;` only when the source itself contains non-ASCII literals. Decode input and encode output explicitly (`open my $fh, '<:encoding(UTF-8)', $path`).
+
+## 2. Scope and variables
+
+- Declare every variable with `my` in the smallest enclosing block. Use `state` for per-sub persistent values, not file-level globals.
+- Never use `local $_` tricks or package globals to pass data between subs; pass arguments.
+- `local` is only for dynamic globals you must change temporarily: `local $/;`, `local $@;`, `local $ENV{PATH}`.
+- Use signatures on 5.36+: `sub fetch($url, %opt) { ... }`. Older code: `my ($self, %args) = @_;` on the first line.
+
+## 3. References and data structures
+
+- Build nested data with literals: `my %cfg = (hosts => [ ... ], retry => { max => 3 });`.
+- Dereference with postfix syntax on 5.24+: `$cfg->{hosts}->@*`, `$row->%{qw(id name)}`. Use `@{ $ref }` on older perls.
+- Check shape before you trust it: `ref $x eq 'HASH'`, or `Scalar::Util::reftype` / `blessed` for objects.
+- Copy deeply only when needed (`Storable::dclone`); assigning a ref shares the data.
+- Avoid autovivification surprises: `exists $h{a} && exists $h{a}{b}` instead of testing `$h{a}{b}` directly, or use the `autovivification` pragma if the project already does.
+- Know context: `my $n = @list` gives a count, `my ($first) = @list` gives an element, `return;` (not `return undef;`) for "nothing" so list callers get an empty list.
+
+## 4. Object orientation
+
+Decision rule:
+
+| Need | Use |
+|---|---|
+| Plain classes, fast startup, few dependencies | Moo |
+| Introspection, meta-programming, MooseX extensions already in the project | Moose |
+| perl 5.38+ and the team accepts an experimental feature | core `class` (`use feature 'class'`) |
+| Tiny script with one data holder | a hash, not a class |
+
+Moo class shape:
+
+```perl
+package My::Client;
+use v5.36;
+use Moo;
+use HTTP::Tiny;
+use Types::Standard qw(Str Int);
+use namespace::autoclean;
+
+has base_url => (is => 'ro', isa => Str, required => 1);
+has timeout  => (is => 'ro', isa => Int, default => 10);
+has _ua      => (is => 'lazy');
+sub _build__ua ($self) { HTTP::Tiny->new(timeout => $self->timeout) }
+
+1;
+```
+
+- Prefer `is => 'ro'` and build new objects instead of mutating.
+- Use roles (`Moo::Role`, `with`) for shared behaviour instead of deep inheritance.
+- With Moose, end the class with `__PACKAGE__->meta->make_immutable;`.
+
+## 5. Error handling
+
+- Fail with `die`, using `Carp::croak` in modules so the error points at the caller.
+- For errors callers branch on, throw objects (an exception class with a `message` and a type) rather than matching message strings.
+- Catching, by target perl:
+  - 5.40+: `use v5.40; try { ... } catch ($e) { ... }`.
+  - 5.34 to 5.38: `use feature 'try'; no warnings 'experimental::try';` only if the team accepts experimental code; otherwise Try::Tiny.
+  - Older: Try::Tiny (`try { } catch { warn $_ };` note the trailing semicolon and that `return` inside returns from the block, not the sub), or Syntax::Keyword::Try.
+- Without Try::Tiny or `try`, never write `eval { ... }; if ($@)`: `$@` can be empty or clobbered by a destructor. Use `eval { ...; 1 } or do { my $err = $@ || 'unknown error'; ... };`.
+- Check every system call: `open(...) or die "open $path: $!"`, `close $fh or die ...`. Or `use autodie;` file-wide.
+
+## 6. Dependencies (CPAN)
+
+1. Declare dependencies in a `cpanfile` (`requires 'Moo', '2.004';`, `on test => sub { requires 'Test2::V0'; };`).
+2. Install for development: `cpanm --installdeps .`.
+3. For reproducible apps, use Carton: `carton install` writes `cpanfile.snapshot` and `local/`; run with `carton exec perl script.pl` or `carton exec prove -lr t`. Commit `cpanfile.snapshot`, never `local/`.
+4. Do not install into the system perl with `sudo cpan`. Use local::lib, Carton, or perlbrew/plenv.
+5. Before adding a module, check it is maintained (MetaCPAN: recent release, CPAN Testers results) and that a core module (`List::Util`, `Scalar::Util`, `File::Spec`, `File::Temp`, `HTTP::Tiny`, `JSON::PP`, `Time::Piece`) does not already do the job.
+
+## 7. Perl::Critic and tidying
+
+- Run `perlcritic --severity 3 lib/ bin/` (lower number is stricter; 5 is gentlest). Respect the project's `.perlcriticrc`.
+- Fix the code rather than adding `## no critic`. If a disable is justified, name the policy and give the reason on the same line: `## no critic (ProhibitStringyEval) -- loads generated plugin code`.
+- Format with `perltidy` using the project's `.perltidyrc`; do not reformat files you did not otherwise change.
+
+## 8. Security: input, files, shells
+
+- Run untrusted-input programs (CGI, setuid, scripts fed by other users) under taint mode: `#!/usr/bin/perl -T`. Untaint only by matching a strict allow-list regex and using the capture: `my ($id) = $in =~ /\A(\d{1,10})\z/ or die "bad id";`.
+- Under taint, set a safe environment before any command: `local $ENV{PATH} = '/usr/bin:/bin'; delete @ENV{qw(IFS CDPATH ENV BASH_ENV)};`.
+- Always three-arg `open` with a lexical handle: `open my $fh, '<', $path`. Never two-arg `open(FH, $path)`; a filename like `| rm -rf ~` runs a command.
+- Run commands with the list form so no shell parses the arguments: `system('git', 'log', '--', $file) == 0 or die "git failed: $?";`.
+- Capture output without a shell: `open my $ph, '-|', 'git', 'log', '--', $file or die $!;` or IPC::Run3 / IPC::Open3. Never interpolate input into backticks, `qx//` or one-string `system`.
+- Anchor validation regexes with `\A` and `\z` (not `^` and `$`, which allow a trailing newline).
+- Never `eval` a string built from input. Use `quotemeta` / `\Q...\E` when input goes into a regex.
+- Database code: placeholders with DBI (`$dbh->prepare('SELECT * FROM t WHERE id = ?')`), never interpolated SQL. Set `RaiseError => 1`.
+
+## Never
+
+- Never ship code without `use strict; use warnings` (or a `use v5.36`+ line).
+- Never use `$&`, `$'` or `` $` `` in code that must run on perls older than 5.20 (global slowdown).
+- Never rely on hash order; sort keys when output order matters.
+- Never change the house OO system or error style in a patch that has another purpose.
+
+## Report back
+
+End with: files changed, the minimum perl the code now needs, new CPAN dependencies (with versions) and whether `cpanfile` was updated, the `perlcritic` severity you ran and its result, and anything you did not verify (for example "did not run under -T").

package/skills/perl-patterns/evals/triggers.json

@@ -0,0 +1,18 @@
+{
+  "should_trigger": [
+    "Turn this old Perl script with global variables and no strict into modern Perl",
+    "Should I write this Perl class with Moo or Moose? It's a small CLI tool",
+    "How do I call an external command from Perl with a filename the user gave me, without shell injection?",
+    "Set up a cpanfile and Carton so our Perl app deploys the same module versions everywhere",
+    "What's the right way to catch exceptions in Perl 5.36, Try::Tiny or the try feature?",
+    "My nested Perl hash of arrays keeps autovivifying keys, how should I structure and access it?"
+  ],
+  "should_not_trigger": [
+    "Write Test::More tests for my Perl module and measure coverage with Devel::Cover",
+    "Review this Perl pull request for injection and two-arg open problems",
+    "cpanm fails building DBD::mysql with 'mysql_config not found', fix it",
+    "Can't locate My/Module.pm in @INC when I run the script from cron",
+    "Write idiomatic Ruby service objects for this Rails controller",
+    "Convert this Perl one-liner into a Python script"
+  ]
+}

package/skills/perl-testing/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: perl-testing
+description: Perl test suites with Test::More or Test2::V0, run through prove - writing .t files, subtests, exception and warning checks, mocking with Test::MockModule or Test2::Mock, temp-file fixtures, and coverage reports from Devel::Cover. Use when adding or fixing tests for a Perl module or script, setting up a t/ directory, making a flaky prove run deterministic, or finding which Perl code paths no test exercises.
+license: MIT
+compatibility: Any Agent Skills host. Needs perl and prove; coverage needs Devel::Cover from CPAN.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: testing
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "perl, prove"
+  kete-loom/owner: "Kete-org"
+---
+
+# Perl testing
+
+Tests live in `t/*.t`, run with `prove`, and stay deterministic. Match the framework the project already uses.
+
+## 0. Before you start
+
+1. Find the test setup: `t/`, `xt/` (author tests), `cpanfile` `on test` block, `Makefile.PL` / `Build.PL` / `dist.ini`, CI config.
+2. Find the framework in existing tests: `use Test::More`, `use Test2::V0`, Test::Class, Test::Most. Keep it. New projects: Test2::V0.
+3. Run the suite once: `prove -lr t` (`-l` adds `lib/` to `@INC`, `-r` recurses). With Carton: `carton exec prove -lr t`. Dist::Zilla: `dzil test`.
+4. If it already fails, **stop and tell the user** which files fail before changing anything.
+
+## 1. File shape
+
+Test::More:
+
+```perl
+use strict;
+use warnings;
+use Test::More;
+
+use My::Parser;
+
+subtest 'parses a simple line' => sub {
+    my $r = My::Parser->new->parse("a=1");
+    is_deeply $r, { a => 1 }, 'key and value';
+};
+
+done_testing;
+```
+
+Test2::V0 (enables strict and warnings itself):
+
+```perl
+use Test2::V0;
+use My::Parser;
+
+is(My::Parser->new->parse("a=1"), { a => 1 }, 'deep compare with is');
+like(dies { My::Parser->new->parse(undef) }, qr/no input/, 'dies on undef');
+
+done_testing;
+```
+
+- End every file with `done_testing;` instead of a hard-coded plan.
+- One behaviour per `subtest`, named as a sentence.
+- Name every assertion; the name is what a failure prints.
+
+## 2. Assertions to reach for
+
+| Check | Test::More | Test2::V0 |
+|---|---|---|
+| Scalar equal | `is` | `is` |
+| Deep structure | `is_deeply` | `is` (with `hash`/`array` builders for partial checks) |
+| Regex | `like` | `like` |
+| Dies | `eval` + `like $@` or Test::Fatal `exception { }` | `dies { }`, `lives { }` |
+| Warns | Test::Warnings / Test::Warn | `warning { }`, `warnings { }`, `no_warnings { }` |
+| Object | `isa_ok`, `can_ok` | `isa_ok`, `can_ok` |
+
+- Add Test::Warnings (or `Test2::Plugin::NoWarnings`) so an unexpected warning fails the test.
+- Compare numbers with a tolerance for floats; do not use `is` on computed floats.
+
+## 3. Fixtures and isolation
+
+- Temp files: `File::Temp qw(tempdir)` with `tempdir(CLEANUP => 1)`. Never write into the repo or `/tmp` by fixed name.
+- Small data files go in `t/data/`; locate them with `FindBin` or `File::Spec->catfile(...)` relative to the test file.
+- Shared helpers go in `t/lib/` and load with `use lib 't/lib';`.
+- Environment: `local $ENV{TZ} = 'UTC';` inside the test, never global changes.
+- Time: inject a clock, or override with Test::MockTime; do not sleep.
+
+## 4. Mocking
+
+Mock only slow or external boundaries (network, clock, external commands). Never mock the module under test.
+
+Test::MockModule:
+
+```perl
+use Test::MockModule;
+my $mock = Test::MockModule->new('HTTP::Tiny');
+$mock->redefine(get => sub { { success => 1, content => '{"ok":1}' } });
+# restored automatically when $mock goes out of scope
+```
+
+Test2::Mock (with Test2::V0): `my $m = mock 'HTTP::Tiny' => (override => [ get => sub { ... } ]);`.
+
+- Use `redefine` (fails if the sub does not exist) rather than `mock` so a typo or API rename breaks the test.
+- For external commands, wrap the call in one sub in your code and mock that sub.
+- Keep the mock object in a lexical that lives for the whole test; once it goes out of scope the real sub returns.
+
+## 5. Running
+
+- Single file, verbose: `prove -lv t/parser.t`.
+- Parallel: `prove -lr -j4 t` (only if tests do not share files or ports).
+- Author/release tests: `prove -lr xt` with `AUTHOR_TESTING=1` or `RELEASE_TESTING=1`, as the project expects.
+- Shuffle to find order dependence: `prove -lr --shuffle t`.
+
+## 6. Coverage with Devel::Cover
+
+1. Install: `cpanm Devel::Cover` (or add to the `on develop` block of `cpanfile`).
+2. Clear old data and run: `cover -delete && HARNESS_PERL_SWITCHES=-MDevel::Cover prove -lr t && cover`.
+   For ExtUtils::MakeMaker or Module::Build dists, `cover -test` does the same.
+3. Read `cover_db/coverage.html`, or `cover -report text` in a terminal. Look at branch and condition columns, not only statement.
+4. Add tests for uncovered branches that carry behaviour (error paths, input validation). Do not write tests that only execute lines.
+5. Add `cover_db/` to `.gitignore`.
+
+## Rules
+
+- Never delete, skip (`skip`, `todo`) or weaken an existing test to make the suite pass without telling the user why.
+- No real network in `t/`. Live tests go in `xt/` behind an env var.
+- Fixed seeds (`srand 42` only inside the test) and fixed time.
+- If a test cannot be made green after three focused attempts, stop and report what you tried.
+
+## Report back
+
+End with: test files added or changed, the exact `prove` command run, the pass/fail counts from its summary, coverage before and after if measured, and what is left untested.

package/skills/perl-testing/evals/triggers.json

@@ -0,0 +1,17 @@
+{
+  "should_trigger": [
+    "Write Test::More tests for lib/My/Invoice.pm including the error cases",
+    "How do I mock HTTP::Tiny in a Perl test so it doesn't hit the network?",
+    "Set up Devel::Cover for our Perl project and show me which branches aren't tested",
+    "Migrate our t/ directory from Test::More to Test2::V0",
+    "prove -lr t passes alone but fails with -j4, help me make these Perl tests independent"
+  ],
+  "should_not_trigger": [
+    "Refactor this Perl module to use Moo instead of hand-written bless",
+    "Review my Perl changes for missing strict and unsafe system calls",
+    "Test::More won't install, cpanm says the build failed on make test, fix the dependency",
+    "Write RSpec tests for this Ruby class",
+    "Write pytest fixtures for the invoice module",
+    "Add Playwright end-to-end tests for the checkout page"
+  ]
+}

package/skills/php-patterns/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: php-patterns
+description: Modern PHP 8 conventions for writing new code and restructuring old code, covering declare(strict_types=1), typed and readonly properties, backed enums, constructor promotion, exception hierarchies, PSR-4 autoloading through Composer, PSR-12 style, PHPStan or Psalm at a high level, and safe handling of SQL, output escaping, passwords and unserialize. Use when writing or modernising PHP 8.x classes, designing a Composer package or PHP service, or asking how idiomatic typed PHP should look.
+license: MIT
+compatibility: Any Agent Skills host. Needs php and composer; PHPStan or Psalm and PHP-CS-Fixer or PHP_CodeSniffer are used if the project has them.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "php, composer"
+  kete-loom/owner: "Kete-org"
+---
+
+# PHP patterns
+
+Write PHP that a static analyser can fully understand: every file strict, every value typed, no magic you can't see. Follow the project's existing conventions and framework first (Laravel, Symfony and others have their own); these rules fill the gaps.
+
+## 0. Before you write
+
+1. Read `composer.json`: the `require.php` constraint and `config.platform.php` set the lowest PHP version you may target. Do not use a feature newer than that (see the table in section 2).
+2. Note `autoload.psr-4` namespaces so new classes land in the right folder with the right namespace.
+3. Find the quality tools: `phpstan.neon(.dist)`, `psalm.xml`, `.php-cs-fixer(.dist).php`, `phpcs.xml(.dist)`, `rector.php`, and the `scripts` section of `composer.json`. Use those commands, not your own.
+4. Search the codebase for an existing exception, value object, enum or helper before adding one.
+
+## 1. Every file
+
+- Start with `<?php`, then `declare(strict_types=1);` as the first statement, then the namespace and `use` lines. No closing `?>` in pure-PHP files.
+- One class, interface, trait or enum per file; file name equals the class name; path matches the PSR-4 prefix.
+- Type every parameter, return and property. Use `void`, `never`, `?T`, union `A|B`, and `mixed` only when the value really is anything.
+- Mark classes `final` unless they are designed for extension. Keep constructors free of I/O.
+- Follow PSR-12 (or PER Coding Style) layout; let the project's fixer format it rather than formatting by hand.
+
+`strict_types` applies to calls made *from* that file. Without it, `strlen(123)` and `function f(int $x)` called with `"5"` silently coerce. Adding it to an old file can turn a silent coercion into a `TypeError`: run the tests after adding it.
+
+## 2. Language features by version
+
+| Feature | Since | Use for |
+|---|---|---|
+| Constructor promotion, `match`, nullsafe `?->`, named arguments, union types, `#[Attributes]` | 8.0 | Short value objects, exhaustive branching |
+| Enums (pure and backed), `readonly` properties, `never`, first-class callables `f(...)`, `new` in initialisers | 8.1 | Closed sets of values, immutable data |
+| `readonly` classes, DNF types `(A&B)\|null`, `true`/`false`/`null` as standalone types | 8.2 | Immutable DTOs |
+| Typed class constants, `#[\Override]`, `json_validate()` | 8.3 | Catching broken overrides |
+| Property hooks, asymmetric visibility `public private(set)`, `new Foo()->bar()` without parentheses, `#[\Deprecated]` | 8.4 | Replacing trivial getters/setters |
+
+PHP 8.4 deprecates implicitly nullable parameters (`function f(Foo $x = null)`); write `?Foo $x = null`.
+
+## 3. Data and types
+
+- Value objects: `final readonly class Money { public function __construct(public int $amountMinor, public Currency $currency) {} }`. Validate in the constructor and throw on invalid input; a constructed object is always valid.
+- Money is integer minor units or a decimal library (`brick/money`, `moneyphp/money`), never `float`.
+- Use a backed enum for any closed set of strings or ints that crosses a boundary (database column, API field): `enum Status: string { case Paid = 'paid'; }`. Parse with `Status::from()` when invalid input is a bug, `Status::tryFrom()` when it is user input you will reject.
+- Use `match` instead of `switch`: it compares strictly, returns a value and throws `UnhandledMatchError` on a missing case. Over an enum, list every case and omit `default` so a new case fails loudly.
+- Always compare with `===` and `!==`. Pass `true` as the strict flag to `in_array()` and `array_search()`. Never compare hashes or tokens with `==` (`"0e123" == "0e456"` is true); use `hash_equals()`.
+- Arrays with a fixed shape are a missing class. Return a DTO, not `['id' => ..., 'name' => ...]`. Where arrays stay, document them for the analyser: `@param list<int>`, `@return array<string, User>`, `@var array{id: int, name: string}`.
+- Prefer immutability: return a new instance (`withX()`) instead of mutating shared objects.
+
+## 4. Errors
+
+- Throw exceptions; never return `false` or `null` to mean "failed" in new code. Return `null` only for "not found" and type it `?T`.
+- Define a small hierarchy per module: `final class InvoiceNotFound extends \DomainException`. Extend SPL exceptions (`InvalidArgumentException`, `RuntimeException`, `LogicException`, `DomainException`) so callers can catch broadly.
+- When rethrowing, chain the cause: `throw new PaymentFailed('charge declined', previous: $e);`.
+- Catch only what you can handle. Never write an empty `catch (\Throwable $e) {}`. Catch `\Throwable` only at the top level (HTTP kernel, queue worker, CLI entry point) to log and respond.
+- Many built-ins still signal failure by return value: check `file_get_contents`, `fopen`, `preg_match`, `json_decode`, `strpos` results with `=== false`. For JSON use `json_decode($s, true, 512, JSON_THROW_ON_ERROR)` and `json_encode($v, JSON_THROW_ON_ERROR)`.
+- Never use the `@` error-suppression operator to hide a failure.
+
+## 5. Composer and autoloading
+
+- Every class loads through Composer's PSR-4 autoloader; no `require_once` for classes. Tests use `autoload-dev`.
+- After changing `autoload` in `composer.json` run `composer dump-autoload`. In production builds use `composer install --no-dev --optimize-autoloader` (or `--classmap-authoritative`).
+- Commit `composer.lock` for applications; packages usually don't. Run `composer validate --strict` after editing `composer.json`.
+- Add dependencies with `composer require vendor/pkg` (`--dev` for tools), using a caret constraint (`^2.3`). Do not hand-edit versions and skip the lock update.
+- Set `config.platform.php` to the production PHP version so the lock file resolves for the server, not your laptop.
+- Run `composer audit` before release and when adding a dependency.
+
+## 6. Static analysis
+
+- PHPStan: aim for the highest level the project can sustain; for new projects start at level 6 or higher and raise it. Run `vendor/bin/phpstan analyse`.
+- Psalm: `vendor/bin/psalm`, with `errorLevel` in `psalm.xml` (1 is strictest).
+- Fix the type, don't silence the error. If legacy code makes a level impossible, generate a baseline (`phpstan analyse --generate-baseline`, `psalm --set-baseline=psalm-baseline.xml`) and never add new code to it.
+- When you must ignore one line, use an identifier-specific ignore with a reason (`// @phpstan-ignore argument.type (reason)`, `/** @psalm-suppress PossiblyNullReference */`), never a blanket ignore.
+- Use generics in docblocks (`@template T`, `Collection<int, User>`) where the language can't express the type.
+
+## 7. Security defaults
+
+| Risk | Do | Never |
+|---|---|---|
+| SQL injection | PDO or the framework query builder with bound parameters: `$stmt = $pdo->prepare('SELECT * FROM users WHERE id = ?'); $stmt->execute([$id]);`. Allow-list column and sort names. | Interpolate input into SQL, even "just an int" |
+| XSS | Escape at output in the template engine (Twig, Blade escape by default). In raw PHP: `htmlspecialchars($s, ENT_QUOTES \| ENT_SUBSTITUTE, 'UTF-8')` | `echo $_GET[...]`, `{!! !!}` / `\|raw` on user data |
+| Passwords | `password_hash($p, PASSWORD_DEFAULT)`, `password_verify()`, `password_needs_rehash()` | `md5`, `sha1`, unsalted hashes |
+| Tokens | `random_bytes()`, `random_int()`, `bin2hex(random_bytes(32))` | `rand`, `mt_rand`, `uniqid` for secrets |
+| Deserialisation | `json_decode`; if `unserialize` is unavoidable, `unserialize($s, ['allowed_classes' => false])` | `unserialize()` on any data a user can influence |
+| Commands | Avoid the shell; if required, `escapeshellarg()` each argument or pass an array to `proc_open()` | Build shell strings from input |
+| Files | Resolve with `realpath()` and check the prefix; store uploads outside the web root with generated names | `include`/`require` a path built from input |
+| Config | Secrets from environment or a secrets manager; `display_errors=Off` in production | Commit `.env` or credentials |
+
+Also: set PDO `PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION` and `PDO::ATTR_EMULATE_PREPARES => false` unless the project relies on emulation.
+
+## 8. Stop and ask the user
+
+- The change needs a higher PHP version than `composer.json` allows, or a new runtime dependency.
+- Adding `strict_types` or tightening types would change behaviour that existing callers depend on and there are no tests.
+- You would need to raise or lower the PHPStan/Psalm level, or regenerate the baseline.
+
+## 9. Before you finish
+
+1. Run the project's linters and analyser on touched files (`vendor/bin/phpstan analyse <paths>`, `vendor/bin/psalm <paths>`, the fixer in check/dry-run mode).
+2. Run `php -l` on any file you could not analyse.
+3. Run the test suite (`vendor/bin/phpunit` or `vendor/bin/pest`). For writing tests, use the `php-testing` skill.
+4. Report what you changed and anything you did not run.
+
+## Never
+
+- Leave a file without `declare(strict_types=1);` in a project that uses it.
+- Use `extract()`, `eval()`, variable variables (`$$name`) or `global`.
+- Use `float` for money, `==` for security comparisons, or `unserialize` on untrusted input.
+- Disable a check, lower an analysis level or add to a baseline to make new code pass.

package/skills/php-patterns/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Write a PHP 8.3 value object for an email address with validation and readonly properties",
+    "How should I model order statuses in PHP now that we have enums?",
+    "Modernise this old PHP 7 class with typed properties and constructor promotion",
+    "Set up PSR-4 autoloading and a sensible folder layout for my new Composer package",
+    "What's the idiomatic way to handle errors in modern PHP instead of returning false?"
+  ],
+  "should_not_trigger": [
+    "Add PHPUnit tests with a data provider covering the discount rules",
+    "Check this PHP pull request for injection and escaping bugs before merge",
+    "composer update can't resolve a conflict between symfony/console and laravel/framework",
+    "Build a Laravel Eloquent model and controller for blog posts",
+    "Write idiomatic Ruby with proper error handling for this service object"
+  ]
+}