@ketecode/loom 0.1.0 → 0.2.0

package/skills/patent-research/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: patent-research
+description: Patent and trademark search groundwork across USPTO Patent Public Search and Trademark Search, EPO Espacenet, Google Patents and WIPO PATENTSCOPE and Global Brand Database, covering breaking an invention into searchable features, keyword and CPC classification queries, prior-art and freedom-to-operate lead lists, reading independent claims element by element, checking legal status, family and expiry, and knockout trademark screens by Nice class, with every result labelled as leads for a registered patent attorney or trademark lawyer to assess. Use when checking whether an idea looks new before filing, looking for patents that might block a product launch, mapping competitors' patent filings, summarising what a patent actually claims, or screening a brand name before adopting it.
+license: MIT
+compatibility: Any Agent Skills host. Needs network access to the public patent and trademark databases. Not legal advice; novelty, patentability, infringement, validity and registrability opinions need a qualified patent attorney or trademark lawyer.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: compliance
+  kete-loom/risk: network
+  kete-loom/owner: "Kete-org"
+---
+
+# Patent and trademark research
+
+Find the documents a professional should look at, explain what they claim in plain language, and hand over a search record they can rely on. You produce leads and summaries; you never give an opinion that something is patentable, infringing, invalid, or free to use.
+
+## Attorney-review gate
+
+Every output carries: `Search leads only, not a legal opinion. Have a registered patent attorney or agent (or a trademark lawyer for marks) review before any filing, launch or licensing decision.`
+
+**Stop and tell the user they need a qualified professional now** when:
+
+- They plan to file, launch, invest, or respond to a demand letter based on the result.
+- A lead looks close to their product or invention (a claim where most elements seem present). Do not write an infringement or validity analysis; list the lead and say why it needs review.
+- They received a cease-and-desist, an infringement claim, or an office action.
+- They ask whether they can safely use a mark or a technology.
+
+Also warn the user, before they describe an unfiled invention: public disclosure can destroy patent rights in many countries (Europe has no general grace period; the US has a limited one-year inventor grace period). Keep details in a confidential setting and do not paste unpublished invention details into services the user has not approved.
+
+## 0. Define the question
+
+Ask, then restate:
+
+1. Search type: novelty or prior art (before filing), freedom to operate (FTO, before launch), landscape (who files what), single-patent summary, or trademark knockout.
+2. The invention or product as features: what it is, the problem it solves, how it works, each technical feature separately.
+3. Jurisdictions that matter (where they will file, make or sell). FTO is per country: only patents in force there matter.
+4. Dates: the user's earliest filing or disclosure date for novelty; launch date for FTO.
+
+## 1. Build the search
+
+1. Split the invention into 3 to 6 key concepts. For each, list synonyms, broader and narrower terms, and how a patent drafter would say it ("fastening member" for "screw").
+2. Find the CPC classes: search keywords, open the most relevant hits, note the CPC codes they share, then read the class definitions on the CPC scheme (cooperativepatentclassification.org) to confirm. Search by class and keyword together.
+3. Run the search in at least two databases. What each one is good for, and query syntax, are in `references/databases-and-queries.md`.
+4. Follow citations both ways from the best hits (what they cite, and what cites them), and check the family to find versions in other languages and jurisdictions.
+5. Record every query, database, date and number of hits. A search nobody can repeat is worth little.
+
+Remember the blind spot: applications usually publish about 18 months after their earliest priority date, so the most recent filings cannot be found yet.
+
+For novelty, prior art also includes non-patent literature: papers, standards, product manuals, websites. Search those too (for example Google Scholar) and note the publication date.
+
+## 2. Screen and read
+
+1. Screen titles, abstracts and drawings first; keep anything plausibly relevant.
+2. For each kept document, read the **claims**, not the abstract. The claims define the rights; the description only explains them.
+3. Find the independent claims (those that do not refer to another claim). Break each into elements (preamble, then each "comprising" feature).
+4. Make a claim chart: one row per element, with where the same feature appears in the user's product or invention (for FTO) or in the prior art (for novelty). Mark each as `present`, `absent`, or `unclear`. This is a reading aid for the attorney, not a conclusion.
+5. Note claim language that matters: "comprising" (open) versus "consisting of" (closed), means-plus-function language, numeric ranges.
+
+## 3. Check status and dates
+
+For each lead that matters for FTO:
+
+- Granted or only an application? Applications are not enforceable until granted, and pending claims can change.
+- Legal status: in force, lapsed for non-payment, expired, withdrawn, revoked. Use the official register (EP Register, USPTO Patent Center, national registers) and Espacenet's INPADOC legal status; Google Patents' status is a hint, not a record.
+- Expiry: usually 20 years from the patent's filing date (in the US, from the earliest US non-provisional or PCT application whose benefit it claims; provisionals and foreign Paris Convention priority do not start the clock), adjusted for term adjustments, extensions, terminal disclaimers and lapses. Give the estimate with the reasoning, and say a professional must confirm it.
+- Where it is in force: list the family members and their countries.
+
+## 4. Trademark knockout screen
+
+1. Identify the goods and services and their Nice classes.
+2. Search identical and similar marks (spelling variants, sound-alikes, translations, design elements) in the target registers: USPTO Trademark Search (tmsearch.uspto.gov), EUIPO and national offices through TMview, and the WIPO Global Brand Database, plus common-law use (web, app stores, company registries, domain names).
+3. List live marks in the same or related classes as conflicts to review; note dead marks separately.
+4. A clean knockout screen does not mean the mark is available; a full clearance search and lawyer opinion are needed before launch.
+
+## Rules
+
+- Never say something is "new", "patentable", "not infringing", "invalid" or "free to use". Say what you found and what needs review.
+- Never rely on the abstract or title for what a patent covers; read the claims.
+- Never state a legal status or expiry date without the source and the date checked.
+- Do not paste confidential invention details into a public search tool the user has not approved; search with generic concept terms.
+- Quote claims exactly when you cite them, with the publication number and claim number.
+
+## Report
+
+```
+Search: <type> | question: <one line> | jurisdictions: <list> | date run: <date>
+Search log: database | query | hits | reviewed
+Leads (most relevant first):
+  <pub number> | title | assignee | priority date | status (source, date) | est. expiry | CPC | why relevant
+  Claim chart for independent claim <n>: element | present / absent / unclear | where
+Trademark screen: mark | register | class | status | similarity note
+Gaps: unpublished applications, databases not searched, non-patent literature not covered
+Search leads only, not a legal opinion. Needs review by a registered patent attorney or trademark lawyer.
+```

package/skills/patent-research/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Before we file, search Espacenet and Google Patents for prior art on our self-cleaning water bottle cap",
+    "We launch a smart thermostat in the US and Germany next year, find patents in force that could block it",
+    "Summarise what claim 1 of US patent 10,123,456 actually covers and when it expires",
+    "Map which competitors are filing patents in CPC class H01M 10 for battery cooling",
+    "Screen the brand name Lumora for conflicting trademarks in class 9 and 42 before we adopt it"
+  ],
+  "should_not_trigger": [
+    "Draft an NDA to share our invention with a manufacturer",
+    "Add an open source licence and NOTICE file to our repository",
+    "Check our npm dependencies for licences that conflict with commercial use",
+    "Write the brand voice guidelines for our new product line",
+    "Classify our products with HS codes for export to Canada"
+  ]
+}

package/skills/patent-research/references/databases-and-queries.md

@@ -0,0 +1,52 @@
+# Databases and query patterns
+
+Read this when building a search (section 1). Syntax changes; if a query fails, check the database's own help page and note the syntax you used in the search log.
+
+## Patent databases
+
+| Database | URL | Best for |
+|---|---|---|
+| USPTO Patent Public Search | ppubs.uspto.gov | full text of US grants and published applications; Basic and Advanced search with field codes |
+| USPTO Patent Center | patentcenter.uspto.gov | US file wrappers, status, fees paid |
+| Global Dossier | via the USPTO site | file histories across the main patent offices for one family |
+| EPO Espacenet | worldwide.espacenet.com | worldwide coverage, families (simple and INPADOC), CPC browsing, INPADOC legal status |
+| European Patent Register | register.epo.org | authoritative status of European applications and patents |
+| Google Patents | patents.google.com | fast full-text search with machine translation, CPC filters, citations, "similar documents"; status is not authoritative |
+| WIPO PATENTSCOPE | patentscope.wipo.int | PCT international applications, national collections, cross-lingual search |
+| CPC scheme | cooperativepatentclassification.org | class definitions and titles (CPC is run jointly by the EPO and USPTO) |
+
+## Trademark databases
+
+| Database | URL | Notes |
+|---|---|---|
+| USPTO Trademark Search | tmsearch.uspto.gov | replaced TESS in November 2023; different syntax from TESS |
+| TMview | via tmdn.org | EUIPO and many national and international registers in one search |
+| WIPO Global Brand Database | branddb.wipo.int | international registrations (Madrid) and many national collections |
+| Nice Classification | WIPO site | goods and services classes; check the edition in force |
+
+## Query patterns
+
+Build each query as concept blocks joined with AND, synonyms inside a block joined with OR, and a class block when you have one.
+
+Espacenet Smart search (field identifiers such as `ti` title, `ab` abstract, `ta` title or abstract, `cl` claims, `cpc` classification, `pa` applicant, `pd` publication date; `txt` covers different fields in different interfaces, and a `/low` qualifier widens a CPC symbol to its child groups; check the current help page):
+
+```
+ta=(drone OR "unmanned aerial") AND ta=(parcel OR package) AND cpc=B64U
+pa="acme" AND pd>=2018
+```
+
+Google Patents (search box terms plus filters; `cpc:B64U` includes child codes, `CPC=B64U/low` is the field form; `TI=`, `AB=`, `CL=`, `TAC=` restrict to title, abstract, claims or all three; the advanced form shows the date and country syntax it generates):
+
+```
+(drone OR "unmanned aerial vehicle") (parcel OR package) (winch OR tether)
+cpc:B64U  before:priority:20200101  country:US,EP
+```
+
+USPTO Patent Public Search: use the Advanced search with field codes (for example `.ti.` title, `.ab.` abstract, `.clm.` claims, `.cpc.` classification) and proximity operators such as `ADJ`, `NEAR` and `SAME`; the system's help lists the full set.
+
+## Tips
+
+- Start broad, then add a block at a time; record hit counts at each step.
+- Search claims text separately for FTO; a feature that appears only in the description is not claimed.
+- Use applicant searches for competitors, then harmonise name variants (subsidiaries, old names).
+- Check translations of non-English hits before dismissing them.

package/skills/prospect-research/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: prospect-research
+description: B2B prospect list building and enrichment from public sources such as company websites, filings, job posts, press and public directories, with a written ideal-customer-fit scorecard, a 0-100 fit score and a cited reason per account, buying-committee roles to contact, and warm-introduction paths found in the user's own contacts and investors, while keeping to platform terms and privacy law with no scraping behind logins. Use when a founder or sales team needs a target account list researched, scored and enriched before any outreach is written, or wants to know who in their network can introduce them to a target company.
+license: MIT
+compatibility: Any Agent Skills host. Web access helps for public research; the user supplies their own contact exports. Not legal advice on data protection.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: business
+  kete-loom/risk: network
+  kete-loom/owner: "Kete-org"
+---
+
+# Prospect research
+
+Produce a short, ranked list of accounts that fit, the people to approach at each, and the warmest way in, with a source for every fact. Writing the outreach itself is the job of `cold-outreach-sequences`; sizing the whole market is `market-research`.
+
+## Ground rules
+
+1. **Public and permitted sources only.** Company websites, annual reports and company registries, regulator registers, press releases and news, job postings, conference speaker lists, public GitHub orgs, app store listings, and data providers the user already licenses. Never log in to a site to collect data, never bypass a paywall, rate limit or robots.txt, and never automate collection from a platform whose terms forbid it (LinkedIn's User Agreement forbids scraping and automated access; the user may look profiles up by hand).
+2. **Cite or drop.** Every fact on the list carries a source URL or document and an access date. A guess is marked as a guess or left out.
+3. **Business data, minimum personal data.** Collect name, role, company and a business contact route only. No home addresses, personal phone numbers, family details, photos or anything about health, religion, politics or other special categories.
+4. **No guessed emails sent blind.** Pattern-guessed addresses are marked "unverified" and are not a substitute for a lawful basis to contact someone.
+5. **The user's network data stays theirs.** Contact exports the user shares are used for matching only, are not added to the prospect file wholesale, and are not sent to any third-party service without the user's say-so.
+
+## Step 1: Write the ideal-customer-fit scorecard
+
+Ask the user for their best five to ten current customers (or design partners) and what made each a good fit. From that, agree on four to six criteria with weights that sum to 100, for example:
+
+| Criterion | Weight | Evidence that counts |
+|---|---|---|
+| Industry / segment | 25 | registry SIC/NAICS code, website |
+| Size (staff or revenue band) | 20 | filings, registry, headcount on careers page |
+| Trigger event in last 6 months | 25 | funding, new market, hiring for a role, regulation change |
+| Tech or process fit | 20 | job posts naming tools, public integrations, docs |
+| Geography / language | 10 | registered office, markets served |
+
+Add **disqualifiers** (too small, existing competitor customer under contract, sanctioned country, already a customer). Stop and ask the user to confirm the scorecard before researching any account.
+
+## Step 2: Build the account list
+
+1. Start from sources that list many companies at once: industry association member lists, registries filtered by code and region, event exhibitor lists, investor portfolio pages, marketplace or integration directories.
+2. Deduplicate by legal entity and domain; note parent companies and subsidiaries.
+3. Aim for 1.5 to 2 times the number of accounts the user wants, because scoring will cut some.
+
+## Step 3: Enrich and score each account
+
+For each account record: legal name, domain, country, size band, segment, the trigger (with date and source), tech or process signals, and any disqualifier. Score each criterion 0, half or full weight from the evidence, sum to a 0-100 fit score, and write one line saying why. Mark accounts with fewer than three sourced criteria as "thin evidence" instead of scoring them high.
+
+Tiers: **A** 75+, **B** 50-74, **C** below 50 (park, don't contact).
+
+## Step 4: Map the buying committee
+
+For A and B accounts, list the roles that matter (economic buyer, champion or user, technical evaluator, possible blocker) and the named person only where a public source shows them in that role now. Note the source and date; people move, so anything older than 12 months is "check before contact".
+
+## Step 5: Find warm-intro paths
+
+Ask the user for what they are willing to share: a contacts export, a list of investors, advisers, past employers, customers who would refer, alumni groups. Match on company domain and past employers. For each A account, rank the paths:
+
+1. A current customer or investor who knows someone at the account.
+2. A former colleague who now works there or recently did.
+3. A shared investor, adviser or community.
+4. A public route: speaking at the same event, a mutual open-source project.
+
+For each path, write who to ask, what to ask them for, and a two-line forwardable blurb. Never contact anyone on the user's behalf.
+
+## Privacy and compliance checks
+
+- **EU and UK prospects:** personal data about named people is covered by the GDPR and UK GDPR even in a B2B context. The user needs a lawful basis (usually legitimate interests, with a documented balancing test), and Article 14 requires telling a person whose data you collected from elsewhere, at the latest within one month or at the first communication. Keep a record of the source of each person's data.
+- **Electronic marketing rules differ by country** (for example PECR in the UK, national rules in Germany that are stricter about unsolicited email). Flag the country; leave the decision on whether to email to the user and `cold-outreach-sequences`.
+- **Opt-outs and existing suppression lists** from the user's CRM must be checked before anyone is added.
+- This skill is not legal advice; for a large programme or a regulated sector, recommend the user's data protection lead or counsel reviews the basis and notices.
+
+## Stop and ask the user
+
+- Before research starts, to confirm the scorecard, target count and regions.
+- If a requested source needs a login, a paid seat the user has not mentioned, or automated collection from a platform that forbids it.
+- If the user asks for personal data beyond business contact details, or for people in a country whose rules you have not checked.
+
+## Output
+
+Return a table (or a CSV the user can import) and a summary:
+
+```
+Account | Domain | Country | Size | Fit | Tier | Why (one line) | Trigger (date, source) | Roles / named people (source, date) | Warm path | Evidence gaps
+```
+
+Then: the scorecard used, how many accounts were found, scored and parked, the sources used with access dates, accounts marked "thin evidence", and the privacy points the user must act on before outreach.

package/skills/prospect-research/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Build me a list of 50 mid-size logistics companies in Kenya that fit our ICP, scored and with sources",
+    "Define our ideal customer profile from these ten customers and score this list of target accounts against it",
+    "Who in my LinkedIn connections export or our investor list could introduce me to people at these 20 target companies?",
+    "Enrich this account list with company size, recent funding and hiring signals before our sales team starts outreach",
+    "Find the economic buyer and technical evaluator at each of these fintechs using public sources only"
+  ],
+  "should_not_trigger": [
+    "Write a four-step cold email sequence to the heads of operations on our prospect list",
+    "Size the market for fleet management software in East Africa with TAM, SAM and SOM",
+    "Our outbound emails are going to spam since we started a new sending domain, fix our DMARC",
+    "Plan our launch campaign channels, calendar and budget for next quarter",
+    "Triage my inbox this morning and draft replies to the urgent ones"
+  ]
+}

package/skills/python-app-distribution/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: python-app-distribution
+description: Ships a Python application to people who do not have Python, by freezing it with PyInstaller or compiling it with Nuitka per target OS, wrapping Windows builds in an Inno Setup or MSIX installer with Authenticode signing, signing macOS app bundles with a Developer ID under the hardened runtime and notarizing them with notarytool, and publishing wheels and an sdist to PyPI through GitHub trusted publishing. Use when turning a Python script, CLI or Qt/Tk GUI into a downloadable .exe, .app or .dmg, an installer, or a pip-installable release, or when a frozen build misses data files, gets flagged by SmartScreen or Gatekeeper, or a PyPI upload needs to drop API tokens.
+license: MIT
+compatibility: Any Agent Skills host. Builds must run on each target OS (no cross-compiling); macOS signing needs Xcode command line tools and an Apple Developer account, Windows signing needs a code-signing certificate or signing service.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: devops
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "python"
+  kete-loom/owner: "Kete-org"
+---
+
+# Python app distribution
+
+Ship a build the user can double-click or `pip install` without warnings, missing files or a second Python install, built the same way every time in CI.
+
+Project layout, `pyproject.toml` tooling and code style belong to `python-patterns`. Version numbers and changelogs belong to `release-management`. This skill covers turning a working app into artifacts and getting them signed and published.
+
+## 0. Decide the channel
+
+Ask, or infer from the project:
+
+| Users | Ship |
+|---|---|
+| Developers who have Python | Wheel + sdist on PyPI (`pip install`, `pipx install`, `uv tool install`) |
+| End users on Windows | Frozen app inside an installer (Inno Setup `.exe`, or MSIX) |
+| End users on macOS | Signed, notarized `.app`, usually inside a `.dmg` |
+| End users on Linux | Frozen folder in a tarball, or AppImage/Flatpak (check the project's preference) |
+
+If both developers and end users are targets, do both. If signing credentials do not exist yet, **stop and ask**: who owns the Apple Developer account and the Windows certificate, and where CI may read them.
+
+## 1. Make the app freezable
+
+1. One entry point (`src/app/__main__.py` or a `[project.scripts]` function).
+2. Read bundled data through `importlib.resources`, or through a helper that checks `getattr(sys, "frozen", False)` and `sys._MEIPASS` for PyInstaller. Never rely on the current working directory.
+3. Write user data to the platform's user directory (`platformdirs`), never next to the executable; `Program Files` and signed `.app` bundles are read-only.
+4. Pin dependencies with a lockfile so builds are repeatable.
+
+## 2. Freeze
+
+### PyInstaller
+
+1. `pyinstaller --name MyApp --windowed --onedir src/app/__main__.py` once, then commit the generated `MyApp.spec` and build from it: `pyinstaller MyApp.spec --clean --noconfirm`.
+2. Declare data files and hidden imports in the spec (`datas`, `hiddenimports`), not by copying files after the build.
+3. Prefer `--onedir` for GUI apps inside an installer or `.app`: faster start, fewer antivirus false positives. Use `--onefile` only for a single-file CLI download.
+4. Build on each OS and architecture you ship (Windows x64, macOS arm64 and x86_64 or universal2, Linux on the oldest glibc you support). PyInstaller does not cross-compile.
+
+### Nuitka
+
+`python -m nuitka --mode=standalone --include-data-dir=src/app/assets=assets src/app/__main__.py` (or `--mode=onefile`, `--mode=app` on macOS). Test standalone first; data-file problems are easier to see there. Expect longer builds and a C compiler requirement; Nuitka's benefit is speed and harder-to-unpack code, not secrecy.
+
+### Smoke test the frozen build
+
+Run the built executable on a clean machine or VM without Python, exercise the main path, and check its log for `ModuleNotFoundError` or missing files.
+
+## 3. Windows: installer and signing
+
+1. Installer: Inno Setup script (`installer.iss`) compiled with `iscc installer.iss`, or MSIX packaged with `makeappx pack` (MSIX gives clean uninstall and Store distribution; it needs a manifest and signing with a matching publisher). Details in `references/windows-macos-signing.md`.
+2. Sign the app executable first, then the installer: `signtool sign /fd SHA256 /tr <timestamp URL> /td SHA256 ...`. Always timestamp so signatures outlive the certificate.
+3. Code-signing keys now live in hardware or a cloud signing service (for example Azure Artifact Signing, formerly Trusted Signing, or a CA's cloud HSM); plan CI around that, not around a `.pfx` in a secret.
+4. A new certificate still builds SmartScreen reputation gradually; tell the user to expect warnings on the first downloads.
+
+## 4. macOS: sign, notarize, staple
+
+1. Sign every binary inside the bundle, inside out, with the hardened runtime and a secure timestamp: `codesign --force --options runtime --timestamp --entitlements entitlements.plist --sign "Developer ID Application: <Team> (<TEAMID>)" MyApp.app` (nested `.dylib`/`.so` files first, or use the PyInstaller `--codesign-identity` option and re-check).
+2. Verify: `codesign --verify --deep --strict --verbose=2 MyApp.app`.
+3. Package (`.dmg` via `hdiutil create`, or a `.zip`), sign the `.dmg`, then notarize: `xcrun notarytool submit MyApp.dmg --keychain-profile <profile> --wait`.
+4. On failure read the log: `xcrun notarytool log <submission-id> --keychain-profile <profile>`.
+5. Staple: `xcrun stapler staple MyApp.dmg`, then check with `spctl --assess --type open --context context:primary-signature -v MyApp.dmg`.
+
+Entitlements, CI keychain setup and common notarization errors are in `references/windows-macos-signing.md`.
+
+## 5. PyPI: wheels, sdist, trusted publishing
+
+1. Build backend declared in `pyproject.toml` (`hatchling`, `setuptools`, `flit-core`, `uv_build`, or `maturin`/`scikit-build-core` for compiled extensions).
+2. Build: `python -m build` (or `uv build`), then `twine check dist/*`. Install the wheel into a fresh virtual environment and run the CLI once.
+3. Compiled extensions: build platform wheels with `cibuildwheel` in CI; pure Python ships one `py3-none-any` wheel.
+4. Publish from CI with trusted publishing, no API token: register the publisher on PyPI (project settings, or a pending publisher for a new project) naming the repository, workflow file and environment; the workflow then needs `permissions: id-token: write` and `pypa/gh-action-pypi-publish@release/v1`. Template in `references/pypi-trusted-publishing.md`.
+5. Rehearse on TestPyPI first. A version number can never be re-uploaded, even after deleting it.
+
+## 6. CI
+
+One workflow, triggered by a version tag: a build matrix per OS that freezes, signs, smoke-tests and uploads artifacts; a publish job that needs the builds and runs in a protected environment with required reviewers. Secrets (Apple app-specific password or API key, signing credentials) live only in that environment.
+
+## Never
+
+- Never commit certificates, `.p12` files, passwords or PyPI tokens.
+- Never tell users to disable Gatekeeper, SmartScreen or antivirus as the fix.
+- Never ship an unsigned build labelled as a release when signing was expected; ask first.
+- Never publish to PyPI from a developer laptop when the project has a CI publisher.
+
+## Regulated or high-stakes distribution
+
+Export controls on cryptography, app-store rules and licence obligations of bundled libraries (GPL/LGPL Qt bindings, for example) are not covered here. Flag them and have the owner or legal review before a public release.
+
+## Report back
+
+```
+## Distribution: <app> <version>
+Channels: <PyPI | Windows installer | macOS dmg | Linux>
+Builds: <OS/arch -> artifact, size>
+Signing: Windows <signed+timestamped yes/no>, macOS <signed, notarized, stapled yes/no>
+PyPI: <TestPyPI ok, trusted publisher configured, published yes/no>
+Smoke tests: <clean-machine result per OS>
+Open items: <credentials, reputation, licences>
+```

package/skills/python-app-distribution/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Turn our PySide6 desktop tool into a signed Windows installer our customers can download",
+    "The PyInstaller build works on my machine but the exe can't find its icons and config file",
+    "macOS says our Python app is damaged and can't be opened; set up codesign and notarization",
+    "Publish our library to PyPI from GitHub Actions without storing an API token",
+    "Compile our Python CLI with Nuitka into a single binary for Linux and macOS"
+  ],
+  "should_not_trigger": [
+    "Set up ruff, mypy and a pyproject.toml for our new Python service",
+    "Decide the next semantic version and write release notes for this sprint's changes",
+    "Pin the Python interpreter version so every developer and CI use the same one",
+    "Write a Dockerfile that runs our Python API in production",
+    "Write pytest fixtures for the billing module"
+  ]
+}

package/skills/python-app-distribution/references/pypi-trusted-publishing.md

@@ -0,0 +1,55 @@
+# PyPI trusted publishing (GitHub Actions)
+
+Read this when wiring a release workflow. Trusted publishing exchanges a short-lived GitHub OIDC token for a PyPI upload token; nothing long-lived is stored.
+
+## On PyPI
+
+Project settings, Publishing, add a GitHub publisher with: owner, repository, workflow file name (for example `release.yml`) and environment name (for example `pypi`). For a project that does not exist yet, add a pending publisher from your account's Publishing page. Do the same on TestPyPI for rehearsals.
+
+## Workflow
+
+```yaml
+name: release
+on:
+  push:
+    tags: ["v*"]
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+      - run: python -m pip install build twine
+      - run: python -m build
+      - run: twine check dist/*
+      - uses: actions/upload-artifact@v4
+        with:
+          name: dist
+          path: dist/
+
+  publish:
+    needs: build
+    runs-on: ubuntu-latest
+    environment: pypi          # must match the publisher on PyPI
+    permissions:
+      id-token: write          # required for trusted publishing
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          name: dist
+          path: dist/
+      - uses: pypa/gh-action-pypi-publish@release/v1
+```
+
+For TestPyPI add `with: repository-url: https://test.pypi.org/legacy/` and a separate environment.
+
+Keep `id-token: write` on the publish job only, and protect the environment with required reviewers and a tag rule. Recent versions of the publish action also generate and upload attestations by default; leave that on.
+
+## Checks before the first real upload
+
+- `name` and `version` in `pyproject.toml` are right; the version matches the tag.
+- `readme`, `license` and `classifiers` render: `twine check` passes.
+- A fresh `pip install` of the TestPyPI release works (`--extra-index-url https://pypi.org/simple/` so dependencies resolve).

package/skills/python-app-distribution/references/windows-macos-signing.md

@@ -0,0 +1,70 @@
+# Windows installers and macOS signing
+
+Read this when writing the installer script, setting up signing in CI or debugging a notarization failure. Check Apple's and Microsoft's current documentation before relying on a specific certificate product; both change their signing offerings.
+
+## Inno Setup (minimal)
+
+```ini
+[Setup]
+AppId={{8C5E2F0A-REPLACE-WITH-YOUR-GUID}}
+AppName=MyApp
+AppVersion=1.4.0
+DefaultDirName={autopf}\MyApp
+DefaultGroupName=MyApp
+OutputBaseFilename=MyApp-1.4.0-setup
+Compression=lzma2
+SolidCompression=yes
+ArchitecturesAllowed=x64compatible
+ArchitecturesInstallIn64BitMode=x64compatible
+PrivilegesRequiredOverridesAllowed=dialog
+
+[Files]
+Source: "dist\MyApp\*"; DestDir: "{app}"; Flags: recursesubdirs ignoreversion
+
+[Icons]
+Name: "{group}\MyApp"; Filename: "{app}\MyApp.exe"
+
+[Run]
+Filename: "{app}\MyApp.exe"; Flags: nowait postinstall skipifsilent
+```
+
+Keep `AppId` fixed forever; upgrades find the old install by it. Compile with `iscc installer.iss`. Inno Setup can call the signer itself through a `SignTool=` entry so the uninstaller is signed too.
+
+## MSIX
+
+Needs an `AppxManifest.xml` whose `Publisher` matches the signing certificate subject exactly. Package with `makeappx pack /d <folder> /p MyApp.msix`, sign with `signtool sign /fd SHA256 ...`. MSIX apps run with a virtualized file system and registry; test file writes and per-user settings.
+
+## signtool
+
+```
+signtool sign /fd SHA256 /tr http://timestamp.example-ca.com /td SHA256 /a dist\MyApp\MyApp.exe
+signtool verify /pa /v dist\MyApp\MyApp.exe
+```
+
+Use the timestamp URL your CA or signing service documents. Cloud signing services ship their own signtool plug-in (dlib) and metadata file instead of `/a` or `/f`.
+
+## macOS entitlements for a frozen Python app
+
+Frozen Python apps often need these under the hardened runtime:
+
+```xml
+<key>com.apple.security.cs.allow-unsigned-executable-memory</key><true/>
+<key>com.apple.security.cs.disable-library-validation</key><true/>
+```
+
+Add only what the app needs; start without them and add one at a time if the signed app crashes at launch. Camera, microphone or Apple Events access also need usage strings in `Info.plist`.
+
+## macOS signing in CI
+
+1. Export the Developer ID Application certificate as `.p12`, store it base64-encoded with its password as CI secrets.
+2. In the job: create a temporary keychain (`security create-keychain`), import the `.p12` (`security import ... -T /usr/bin/codesign`), allow codesign access (`security set-key-partition-list -S apple-tool:,apple:`), sign, then delete the keychain.
+3. Notarize with an App Store Connect API key (`xcrun notarytool submit --key <p8> --key-id <id> --issuer <uuid>`) or an app-specific password stored with `xcrun notarytool store-credentials`.
+
+## Common notarization failures
+
+| Message | Fix |
+|---|---|
+| The binary is not signed with a valid Developer ID certificate | A nested `.so`/`.dylib` was skipped; sign every Mach-O file |
+| The signature does not include a secure timestamp | Add `--timestamp` |
+| The executable does not have the hardened runtime enabled | Add `--options runtime` |
+| Signed app fails after editing | Any change after signing breaks it; sign last, then package |

package/skills/quality-nonconformance/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: quality-nonconformance
+description: Nonconformance report (NCR) and corrective and preventive action (CAPA) workflow for regulated manufacturing such as medical devices under FDA's Quality Management System Regulation (21 CFR 820, which incorporates ISO 13485:2016) and automotive suppliers under IATF 16949, covering NCR intake and severity triage, containment and quarantine, root cause analysis with 5 Whys, Ishikawa diagrams and 8D, disposition decisions (use as is, rework, repair, scrap, return to supplier), CAPA plans, and effectiveness verification before closure. Use when a part, lot or process fails a specification, a customer complaint or audit finding needs a CAPA, you are writing or fixing an NCR or CAPA procedure or tracker, or a corrective action keeps failing to stop a repeat defect.
+license: MIT
+compatibility: Any Agent Skills host. Works from the user's NCR, inspection, complaint and production records. Quotes clause numbers, not licensed standard text; the user needs their own copies of ISO 13485 and IATF 16949. Not regulatory or legal advice.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: compliance
+  kete-loom/risk: read-only
+  kete-loom/owner: "Kete-org"
+---
+
+# Quality nonconformance and CAPA
+
+Stop bad product reaching the customer, find the cause that actually explains the defect, fix it so it does not come back, and leave a record an auditor can follow. This skill structures the work; the organisation's quality management system (QMS) procedures and its quality and regulatory staff decide.
+
+## Boundary: when a qualified person must decide
+
+**Stop and tell the user a qualified quality or regulatory person must decide**, and do not draft a conclusion for them, when:
+
+- The defect could affect patient or user safety, or a device already shipped: field action, recall, correction or removal, and Medical Device Reporting (21 CFR 803) or reports of corrections and removals (21 CFR 806) decisions belong to regulatory affairs.
+- A disposition would ship product outside specification (use as is, concession or deviation). Automotive: the customer must authorise it in writing under IATF 16949 and the customer's own requirements.
+- A design change, validated process change, or supplier change follows from the CAPA; it needs the change control and, where required, revalidation or customer approval (for example a PPAP resubmission).
+- Anyone asks to close a CAPA without objective evidence of effectiveness.
+
+## 1. Intake: open the NCR
+
+Record, from evidence, not memory:
+
+1. What failed: part number, revision, lot or serial numbers, quantity affected and quantity inspected.
+2. Requirement violated: drawing, specification, procedure or customer requirement, with revision.
+3. Where found (incoming, in process, final inspection, customer, field, audit) and by whom, when.
+4. Objective evidence: measurements, photos, test records.
+5. Severity and risk: link to the product's risk file (ISO 14971 risk management for devices; PFMEA and control plan for automotive). A failure mode not in the risk file is itself a finding.
+
+Number every NCR, never delete one, and keep its history (records and electronic signatures under 21 CFR Part 11 if records are electronic and the site is FDA-regulated).
+
+## 2. Containment, within hours
+
+1. Quarantine and tag all suspect material: in stock, in process, in transit, at suppliers, at distribution.
+2. Define the suspect range from the last known good to the first known good, using lot traceability. If you cannot bound it, widen it.
+3. Add a 100% check or sort at the point of detection until the fix is proven, and record results.
+4. Decide whether the customer must be told now (automotive customers usually require notification; device field impact goes to regulatory per the boundary above).
+
+Containment is not correction. Record both separately.
+
+## 3. Root cause
+
+Pick the method by the problem, and check the cause against the data:
+
+- **5 Whys** for a single, clear failure chain. Each "why" must be backed by evidence. Stop at a cause the organisation can control and that, if removed, would have prevented the defect.
+- **Ishikawa (fishbone)** when several causes are possible: list candidates under Man (people), Machine, Method, Material, Measurement, Environment, then test each one with data.
+- **8D** for customer complaints, recurring or cross-functional problems, and where the customer requires it (common in automotive). Steps and the report outline are in `references/8d-and-capa.md`.
+- Use is/is-not analysis, process data, and a test that turns the defect on and off when you can.
+
+Find two causes: why it **occurred** and why it **escaped** detection. Also ask why the system allowed it (systemic cause), for example a control plan that never covered the characteristic.
+
+Never accept "operator error" or "retrain the operator" as the root cause on its own. Ask what made the error possible and prefer error-proofing (IATF 16949 expects it in problem solving).
+
+Verify measurement before blaming the process: check that the gauge is calibrated and that measurement system analysis (gauge R&R) is acceptable for that characteristic.
+
+## 4. Disposition
+
+| Disposition | Needs |
+|---|---|
+| Use as is / concession | documented justification, authorised approver, customer authorisation where required |
+| Rework (back to specification) | approved rework instruction, re-inspection, record on the lot, batch or device production record (QMSR no longer uses the term device history record) |
+| Repair (still not fully to specification) | as concession, plus customer authorisation in automotive |
+| Scrap | controlled scrapping so it cannot re-enter stock |
+| Return to supplier | supplier NCR or SCAR, replacement or credit, supplier containment |
+
+Record who decided, when, and on what evidence.
+
+## 5. CAPA
+
+1. Decide whether a CAPA is needed by your procedure's rules (for example: safety impact, recurrence, customer complaint, audit finding, trend). Not every NCR needs one; record the decision either way.
+2. Corrective action removes the cause found in section 3; preventive action removes the cause of a potential problem elsewhere (similar products, lines or suppliers). ISO 13485 treats these as separate requirements (clauses 8.5.2 and 8.5.3).
+3. Each action has an owner, due date, and the evidence that will show it is done. Actions must not adversely affect product conformity or safety; check that before implementation.
+4. Update the documents the action touches: drawings, work instructions, PFMEA, control plan, risk file, training records, supplier requirements.
+
+## 6. Effectiveness check, then close
+
+1. Define the effectiveness criteria when the CAPA is opened, not when it is closed: for example zero recurrences in the next N lots or N weeks, a capability index above target, or complaint rate below a threshold.
+2. Wait long enough to see the result, then check against the criteria with data.
+3. Not effective: reopen the root cause analysis. Do not stack new actions on an unverified cause.
+4. Close only with objective evidence and the approver your procedure names. Feed the result into management review and trend analysis.
+
+Clause references and the records auditors expect are in `references/8d-and-capa.md`.
+
+## Rules
+
+- Never back-date, edit or delete a quality record; correct with a dated, signed amendment.
+- Never close a CAPA on "action completed" alone; closure needs verified effectiveness.
+- Never ship quarantined material without a recorded disposition.
+- Do not quote standard text you do not have; cite clause numbers and tell the user to check their licensed copy.
+
+## Report
+
+```
+NCR <id> | part <pn rev> | lots <range> | qty affected <n> | found at <stage> | severity <level>
+Requirement: <spec, rev>   Evidence: <refs>
+Containment: <actions, locations, qty quarantined, sort results>
+Root cause (occurrence): <cause + evidence>   Root cause (escape): <cause + evidence>   Method: <5 Whys | Ishikawa | 8D>
+Disposition: <type, approver, customer authorisation ref>
+CAPA <id>: actions (owner, due, evidence) | effectiveness criteria | check date | result
+Needs qualified decision: <reportability, concession, change control, other>
+```