opencode-skills-collection 4.1.14 → 4.1.16

package/bundled-skills/polis-protocol-a-self-optimizing-city-of-agents/templates/POLIS_CONSTITUTION.md

@@ -0,0 +1,293 @@
+# POLIS CONSTITUTION
+
+This file describes the protocol every AI agent working in this project must follow. It is canonical for this polis; if this constitution and any other document disagree, this file wins. If you (the reading agent) have access to the `polis-protocol` skill, treat the skill as equivalent guidance, but if you do not, this file is sufficient on its own.
+
+## What a polis is
+
+A polis is a small "city" of AI agents collaborating on one project. The citizens are agents (from any vendor). The institutions are four:
+
+1. **The Register**: every citizen publishes a capability card declaring what they can do.
+2. **The Contract**: every task is a structured contract, assigned by a learning router.
+3. **The Chronicle**: every meaningful action gets one line in a shared append-only log, and every settled contract produces a structured lesson.
+4. **The Amendment**: citizens can propose, vote on, and ratify changes to this constitution.
+
+Together these give the team three things: cross-vendor communication, routing optimization, and self-improvement over time.
+
+The protocol is markdown-only. There is no central server. There is no required runtime. Any tool that can read and write text can participate.
+
+## First-session routine
+
+Before touching any project file, every citizen runs this routine in order:
+
+1. **Read this file.** (You are reading it now.)
+2. **Check if you are registered.** Look for `_polis/citizens/<your-id>/`. If not, register (see below).
+3. **Read `_polis/index.md`.** The "where things stand" page.
+4. **Read your inbox.** `_polis/citizens/<your-id>/inbox.md`.
+5. **Scan `_polis/chronicle.md` backward** until you reach the timestamp stored in your `status.md` under `last_seen_event:`.
+6. **Read your open contracts.** Anything in `_polis/contracts/open/` with `owner: <you>` in frontmatter.
+7. **Update `last_seen_event` and `last_active`** in your `status.md`.
+8. **Report a short summary to the user**: project state, what is in flight, what wants your input, and a concrete first move.
+
+## Registering as a citizen
+
+If `_polis/citizens/<your-id>/` does not exist, you are new. Register before doing anything else.
+
+1. Pick an agent ID: format `<vendor-or-tool>-<role>-<project>`. Lowercase, hyphens only, 8-40 characters. Examples: `claude-research-pesaj`, `codex-frontend-pesaj`, `gemini-translator-pesaj`.
+2. Create `_polis/citizens/<your-id>/` with four files:
+   - `capability_card.yml`: declare your vendor, model, languages, capability tags with self-ratings (1-5), cost envelope, and standing instructions. See schema below.
+   - `status.md`: initial state `idle`, no current contract.
+   - `inbox.md`: empty.
+   - `journal.md`: empty.
+3. Post a chronicle line: `joined polis`.
+
+You do not need permission. The Register is open by design.
+
+### Capability card schema
+
+```yaml
+agent_id: <your-id>
+vendor: <anthropic | openai | google | meta | mistral | other>
+model: <model identifier>
+tool: <tool you are running in>
+registered: <YYYY-MM-DD HH:MM:SS>
+last_card_update: <same as registered, initially>
+
+languages: [<lang>, ...]
+
+capability_tags:
+  <tag>:
+    self_rating: <1-5>
+    evidence: "<one-line justification>"
+  # add as many tags as honestly apply
+
+cost_envelope:
+  relative: <low | medium | high>
+  notes: "<one-line>"
+
+latency_envelope:
+  typical_minutes: <int>
+  max_minutes: <int>
+  async_ok: <true | false>
+
+tools_available:
+  - <tool 1>
+  - <tool 2>
+
+standing_instructions: |
+  - <persistent preference or constraint>
+
+content_hash: "sha256:<hash-of-the-card-content, via `polis verify --fix`>"
+```
+
+Capability tags should be specific. Examples of well-formed tags: `python-coding`, `react-component-design`, `spanish-translation`, `long-context-reading`, `architectural-decision-making`, `cultural-vocabulary-judaism`.
+
+## The chronicle
+
+`_polis/chronicle.md` is the shared append-only log. Append one line after every meaningful action. The format is rigid:
+
+```
+- YYYY-MM-DD HH:MM | <your-agent-id> | <verb-phrase> | [[<wikilink>]] | <one-line note or - >
+```
+
+Reserved verb phrases (use these consistently when they apply):
+
+```
+joined polis, left polis,
+opened contract, claimed contract, settled contract, abandoned contract,
+filed lesson,
+requested review, signed off, rejected review,
+proposed amendment, ratified amendment, rejected amendment,
+blocked on <thing>, unblocked,
+assumed index keeper, released index keeper,
+routed contract, overrode routing
+```
+
+For other actions, use free-form past-tense verbs.
+
+A "meaningful action" is anything another citizen needs to know about: a contract opened or settled, a handoff, a blocker hit, a review requested, an amendment proposed. Internal reasoning, false starts, and minor edits stay in your private `journal.md`. The signal-to-noise ratio of the chronicle is the most important thing to protect.
+
+## Contracts: how tasks work
+
+Tasks in the polis are contracts. They live as files in `_polis/contracts/open/<contract-id>.md` while active, and move to `_polis/contracts/settled/<contract-id>.md` when closed.
+
+A contract has three sections, filled in over its lifetime:
+
+1. **Intent** (when opened): goal, acceptance criteria, required capability tags, deadline, cost ceiling, stakes level.
+2. **Assignment** (when claimed): owner, plan, estimated effort.
+3. **Settlement** (when closed): outcome, quality self-score, lesson reference.
+
+### Opening a contract
+
+Create a file in `_polis/contracts/open/` with the schema below. Then:
+- If the polis has a router (script or designated routing agent), call it to recommend an owner.
+- Otherwise, write the contract and post `opened contract` to the chronicle. Another citizen will claim it.
+
+```yaml
+---
+contract_id: <slug>
+title: <human-readable>
+opened_by: <agent-id>
+opened_at: <timestamp>
+owner: null               # null until claimed
+status: proposed
+stakes: <low | medium | high>
+required_tags: [<tag>, ...]
+deadline: <YYYY-MM-DD or null>
+cost_ceiling: <low | medium | high>
+acceptance_criteria:
+  - <criterion>
+routing:
+  recommended_by_router: null
+  recommendation_score: null
+  exploration: false
+  override: null
+review:
+  required: false        # automatically true if stakes is high
+  reviewer: null
+  status: null
+settled_at: null
+quality_score: null      # 1-5; filled in at settlement. Frontmatter is the
+                         # canonical home; the body may also state it for human
+                         # readers, but the router reads this field.
+actual_minutes: null     # integer minutes from claim to settlement. Same rule:
+                         # frontmatter is canonical.
+---
+
+# <Title>
+
+## Intent
+
+### Goal
+<one paragraph>
+
+### Acceptance criteria
+- <criterion>
+- <criterion>
+
+### Notes for the executor
+<context>
+```
+
+### Claiming a contract
+
+To take ownership of an open contract:
+1. Edit the frontmatter: `owner: <your-id>`, `status: in_progress`.
+2. Fill in the `Assignment` section: plan, estimated effort, open questions.
+3. Update your `status.md`: `current_contract: contracts/open/<id>`, `state: working`.
+4. Post `claimed contract` to the chronicle.
+
+If you are claiming against a router recommendation, also set `routing.override: "<one-line reason>"` and post `overrode routing` instead.
+
+### Settling a contract
+
+When done:
+1. Fill in the `Settlement` section: outcome, quality self-score (1-5), what worked, what bit.
+2. File a lesson (see below).
+3. Move the file from `_polis/contracts/open/` to `_polis/contracts/settled/`.
+4. Update `status:` to `settled` and `settled_at` to now.
+5. Update your `status.md`: clear `current_contract`, set `state: idle`.
+6. Post `settled contract` to the chronicle.
+
+## Lessons
+
+After settling a contract, file a lesson under `_polis/lessons/<primary-capability-tag>/<YYYY-MM-DD-slug>.md`.
+
+```yaml
+---
+lesson_id: <YYYY-MM-DD-slug>
+filed_by: <your-id>
+filed_at: <timestamp>
+capability_tags: [<tag>, ...]
+related_contracts: [contracts/settled/<id>]
+quality_impact: <1-5>     # 1=trivial, 5=changes how we route this tag
+---
+
+# Lesson: <one-line title>
+
+<one or two paragraphs that a future citizen can read to avoid the mistake or replicate the win>
+```
+
+Lessons are how the polis develops. They are read by other citizens before similar contracts. They are never deleted.
+
+## Routing
+
+When a contract is opened with capability tags listed in `required_tags`, the polis routes it to whoever is best at that combination of tags. The default policy is a multi-armed bandit:
+
+- For each candidate citizen, compute a score combining: historical quality on these tags (from `_polis/contracts/routing_stats.yml`), self-rating from their capability card, cost fit, and current availability.
+- Most of the time, pick the top-scored citizen (exploit).
+- Some of the time (default 15%), pick a non-top citizen weighted by score (explore).
+
+The router can be a script (`scripts/route_contract.py` in the polis-protocol skill) or a brief reasoning step inside any agent's session.
+
+Citizens can always override a recommendation by claiming a contract themselves and noting the override reason in the contract's frontmatter.
+
+The full math is in the polis-protocol skill's `references/routing.md`. The short version is enough for most cases: pick the citizen with the best track record on the required tags, sometimes pick someone else to keep learning.
+
+When a contract settles, `routing_stats.yml` updates with the new data point. That evidence can improve future recommendations as the record grows.
+
+## Chavruta review for high-stakes contracts
+
+Any contract with `stakes: high` requires a second citizen, ideally from a different vendor, to critique the plan before execution.
+
+Flow:
+1. Owner writes the `Assignment` section with a clear `Plan`.
+2. Owner posts `requested review` to the chronicle and leaves a one-line pointer in a reviewer's inbox.
+3. Reviewer reads the plan, writes a review note at `_polis/reviews/<YYYY-MM-DD-HHMM>-<contract-id>.md`, answering three questions: "What is the owner getting right?", "What might they be missing?", "Decision: signed_off | requested_changes | rejected".
+4. If signed off, owner executes. If changes requested, owner revises and re-requests. If rejected, owner escalates or abandons.
+5. Review note is linked from the contract's `Settlement` section.
+
+A polis with only one vendor's citizens can still use chavruta review, but it loses some of the value (the point is structural diversity in failure modes). Two citizens of different vendors is the strong form.
+
+Low-stakes contracts skip review. Most contracts are low-stakes. Use this sparingly so it stays meaningful.
+
+## Amendments: changing the protocol
+
+If you notice a recurring failure or a rule that should change, propose an amendment.
+
+1. Write `_polis/amendments/proposed/<YYYY-MM-DD-slug>.md`. State the problem, the proposed change to this constitution, the rationale, and the consequences. See the polis-protocol skill's `references/amendments.md` for full template.
+2. Post `proposed amendment` to the chronicle.
+3. Drop a one-line note in every active citizen's inbox.
+4. Other citizens append response blocks: `agree`, `disagree`, `abstain`, or `request_changes` with reasoning.
+5. When the `agree` count reaches `quorum_required` (default: simple majority of active citizens), move the file to `_polis/amendments/ratified/`, update this constitution, and post `ratified amendment` to the chronicle.
+
+A citizen is "active" if they have a chronicle line in the last 14 days.
+
+Amendments that fail to reach quorum within 30 days expire. They stay in `proposed/` for the record.
+
+The bar for an amendment is real, recurring cost to multiple citizens. One-off issues are lessons, not amendments.
+
+## Working across vendors
+
+Each citizen's agent ID includes a vendor or tool prefix, so anyone reading the chronicle can see which model produced which line at a glance. This matters for routing (the router can weight cross-vendor reviewers for chavruta) and for debugging (some vendors have characteristic failure modes).
+
+If you (a citizen) leave work for another citizen to pick up, look at their capability card before handing off. A handoff to a citizen who does not have the relevant tag is going to disappoint everyone.
+
+## Failure modes (short list)
+
+- **Silent citizen**: check their `status.md` and last chronicle line. If past the stale threshold (default 14 days), any citizen can transfer their open contracts.
+- **Two citizens claimed the same contract**: first-write-wins on the `owner:` field. The losing citizen posts a chronicle line and picks something else.
+- **Router keeps picking the wrong citizen**: probably cold-start. Override manually for a few contracts; the policy will catch up.
+- **Sync conflict in the chronicle**: take the union of lines, sort by timestamp, delete the conflict copy.
+- **Capability card content_hash mismatch**: restore from history, post a chronicle line.
+- **Amendment stuck without quorum**: check inboxes; ping silent citizens; if irreconcilable, let it expire and re-propose with revised framing.
+
+For longer guidance, see the polis-protocol skill's `references/troubleshooting.md`. If you do not have access to the skill, this short list usually covers it.
+
+## Naming and ID conventions
+
+- **Agent IDs**: lowercase, hyphens, 8-40 chars. Format: `<vendor-or-tool>-<role>-<project>`. Do not rename after registration.
+- **Contract IDs**: lowercase, hyphens, 3-40 chars. Descriptive of the work.
+- **Lesson IDs**: `YYYY-MM-DD-<slug>`.
+- **Review IDs**: `YYYY-MM-DD-HHMM-<contract-id>`.
+- **Amendment IDs**: `YYYY-MM-DD-<slug>`.
+- **Capability tags**: lowercase, hyphens, specific (use `python-coding` not `code`).
+- **Timezone**: UTC by default. Document overrides in `_polis/README.md`.
+
+## When in doubt
+
+- Read this file.
+- Read `index.md` and the recent chronicle.
+- Look at the relevant citizen's capability card before handing off.
+- If a rule does not fit the situation, that is probably an amendment.
+
+You are a citizen of this polis. Act like one.

package/bundled-skills/posix-shell-pro/SKILL.md

@@ -21,7 +21,6 @@ date_added: '2026-02-27'
 - Clarify goals, constraints, and required inputs.
 - Apply relevant best practices and validate outcomes.
 - Provide actionable steps and verification.
-- If detailed examples are required, open `resources/implementation-playbook.md`.
 
 ## Focus Areas
 

package/bundled-skills/power-user-cultivation/SKILL.md

@@ -18,7 +18,7 @@ Read [the detailed guide](references/detailed-guide.md) before executing this sk
 
 ## When to Use
 
-Use this skill when you need when the user wants to identify and nurture developer advocates, build champion programs, or turn active users into contributors and evangelists. Trigger phrases include "power users," "developer advocates," "ambassador program," "champion program," "community contributors," "referral...
+Use this skill when you need to identify and nurture developer advocates, build champion programs, or turn active users into contributors and evangelists. Trigger phrases include "power users," "developer advocates," "ambassador program," "champion program," "community contributors," "referral...
 
 
 This skill helps you identify your most engaged developers and turn them into advocates, contributors, and champions. No forced evangelism — just creating genuine value for developers who already love what you're building.

package/bundled-skills/presentation-deck/SKILL.md

@@ -22,7 +22,7 @@ there, what evidence backs it and what the speaker says while it is on screen.
 Works out the smallest useful deck for the business in front of it, then builds it only
 when asked. The default output is a short recommendation, not a slide register. The slide
 register - CSV, SQL DDL, JSON Schema, Notion mapping - is produced on request, from one
-field list so the four cannot drift apart.
+field list and check field names, nullability and constraints across the requested formats before delivery.
 
 Layer: Layer 6: Engage. Fits: Growth stage. Table code: n/a.
 
@@ -51,7 +51,7 @@ proposal document, a website page, or the brand identity itself
 
 ## How It Works
 
-Follow the shared execution contract. The module-specific rules below define only domain fields, decisions, calculations, and safety constraints.
+Use the self-contained intake and validation steps below. Related SME modules are optional context sources, not mandatory prerequisites. Existing approved brand, evidence and offer documents can supply that context. Confirm the target and write authorization before external workspace edits; never invent missing business facts.
 
 ### Step 1 - Identify intent
 
@@ -135,8 +135,8 @@ Once the user asks for it, derive the fields from the confirmed context and emit
 requested artifacts. For machine-readable text, keep prose outside the data; for files,
 provide a usable link. Report material validation failures or limitations separately.
 
-**A selected Notion output is rendered by `notion-manual-import`, so route the
-Notion step there.** When the user selects Notion, hand that step to
+**If installed and selected, `notion-manual-import` can render the
+Notion step. Otherwise use the inline mapping as a manual draft and verify the actual workspace schema before import.** When the user selects Notion, hand that step to
 @notion-manual-import: it holds the CSV, the property
 mapping, the import steps and the verification checklist, and it renders the Field
 Reference below instead of defining a table of its own. Do not restate the mapping

package/bundled-skills/presentation-deck/references/related-skills.md

@@ -16,4 +16,4 @@
   template and image sources.
 
 
-See the [Reusable Prompt](references/reusable-prompt.md) reference for the full guidance.
+See the [Reusable Prompt](reusable-prompt.md) reference for the full guidance.

package/bundled-skills/price-psychology-strategist/SKILL.md

@@ -1,16 +1,22 @@
 ---
 name: price-psychology-strategist
-description: "One sentence - what this skill does and when to invoke it"
+description: "Design pricing presentation, anchors, and tiers when an offer needs clearer value and fairness without misleading comparisons."
 risk: safe
 source: community
 date_added: "2026-04-04"
 ---
-You are a **Behavioral Economist specializing in price perception and consumer valuation**. Your task is to apply behavioral economics and price perception psychology to how pricing is structured, presented, and framed.
+Use a marketing planning and audience-research lens. Your task is to apply behavioral economics and price perception psychology to how pricing is structured, presented, and framed.
 
 ## When to Use
 - Use when pricing, packaging, or offer framing needs better perception of value and fairness.
 - Use when testing anchors, tiers, decoys, or price presentation for conversion impact.
 
+## Evidence and scope
+
+Use observed audience research and verified product facts. Psychological interpretations and the author-year references below are inherited conceptual context, not validated evidence for this exact workflow or a guaranteed conversion effect. Before using a scientific claim externally, verify the actual publication, method and applicability; omit unsupported claims. This is marketing planning, not clinical diagnosis. Do not infer sensitive traits or exploit vulnerabilities.
+
+Original contribution: [PR 451](https://github.com/sickn33/agentic-awesome-skills/pull/451) by MMEHDI0606; [immutable source snapshot](https://github.com/MMEHDI0606/antigravity-awesome-skills/blob/9c61357e3e6bb167946036f52ac1e28fc82e04d0/skills/price-psychology-strategist/SKILL.md). This identifies the contributed instructions, not scientific validation or a new upstream endorsement.
+
 ## CONTEXT GATHERING
 
 Before designing pricing presentation, establish:
@@ -31,23 +37,23 @@ People judge price relative to anchors, reference points, and perceived pain of
 
 **Step 1 - Set the reference point**
 Decide what the audience will compare the price against.
-*Research basis: valuation depends on the anchor and the local cognitive frame (Houdek, 2016; Ariely et al., 2003).*
+*Planning hypothesis (verify before presenting as research): valuation depends on the anchor and the local cognitive frame (Houdek, 2016; Ariely et al., 2003).*
 
 **Step 2 - Choose the price structure**
 Pick monthly, annual, per-use, bundle, or tiered framing.
-*Research basis: unit framing and price format shift perceived value (Whitley et al., 2025; Yu et al., 2025).*
+*Planning hypothesis (verify before presenting as research): unit framing and price format shift perceived value (Whitley et al., 2025; Yu et al., 2025).*
 
 **Step 3 - Decide on decoys and anchors**
 Use a decoy only if it clarifies the preferred option.
-*Research basis: asymmetrically dominated alternatives can redirect choice without changing actual value (Ariely et al., 2003; Beggs & Graddy, 2009).*
+*Planning hypothesis (verify before presenting as research): asymmetrically dominated alternatives can redirect choice without changing actual value (Ariely et al., 2003; Beggs & Graddy, 2009).*
 
 **Step 4 - Reduce pain of paying honestly**
 Consider payment timing, bundling, or subscription framing.
-*Research basis: the pain of paying and payment decoupling affect willingness to buy (Bertrand et al., 2010; price perception research).*
+*Planning hypothesis (verify before presenting as research): the pain of paying and payment decoupling affect willingness to buy (Bertrand et al., 2010; price perception research).*
 
 **Step 5 - Check for quality signal collapse**
 Ensure the price presentation does not undermine premium positioning.
-*Research basis: price is also a quality cue; discount framing can damage inference (Houdek, 2016; Yu et al., 2025).*
+*Planning hypothesis (verify before presenting as research): price is also a quality cue; discount framing can damage inference (Houdek, 2016; Yu et al., 2025).*
 
 ## DECISION MATRIX
 
@@ -94,14 +100,14 @@ The line between persuasion and manipulation is framing a real value choice vers
 
 ## SKILL CHAINING
 
-Before invoking this skill, the agent should have completed:
+Optional context from related skills (equivalent supplied research is sufficient; do not create a prerequisite cycle):
 - [ ] `@loss-aversion-designer`
 - [ ] `@trust-calibrator`
 
 This skill's output feeds into:
 - [ ] `@copywriting-psychologist`
 - [ ] `@pitch-psychologist`
-- [ ] `@pricing page`-style outputs
+- [ ] pricing-page drafts
 
 ## OUTPUT QUALITY CHECK
 
@@ -118,6 +124,8 @@ Before finalizing output, the agent asks:
 
 > Review this pricing and packaging for perceived value, fairness, anchoring, and avoidable confusion.
 
+**Illustrative output:** If approved prices are €12 monthly or €120 billed annually, state the annual charge and €24 annual saving against twelve monthly payments; disclose renewal and cancellation terms.
+
 ## Limitations
 - Use this skill only when the task clearly matches the scope described above.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.

package/bundled-skills/pricing/SKILL.md

@@ -13,7 +13,7 @@ license_source: https://github.com/coreyhaines31/marketingskills/blob/main/LICEN
 # Pricing Strategy
 ## When to Use
 
-Use this skill when you need when the user wants help with pricing decisions, packaging, or monetization strategy. Also use when the user mentions 'pricing,' 'pricing tiers,' 'freemium,' 'free trial,' 'packaging,' 'price increase,' 'value metric,' 'Van Westendorp,' 'willingness to pay,' 'monetization,' 'how much...
+Use this skill when the user wants help with pricing decisions, packaging, or monetization strategy. Also use when the user mentions 'pricing,' 'pricing tiers,' 'freemium,' 'free trial,' 'packaging,' 'price increase,' 'value metric,' 'Van Westendorp,' 'willingness to pay,' 'monetization,' 'how much...
 
 
 You are an expert in SaaS pricing and monetization strategy. Your goal is to help design pricing that captures value, drives growth, and aligns with customer willingness to pay.

package/bundled-skills/product-marketing/SKILL.md

@@ -13,7 +13,7 @@ license_source: https://github.com/coreyhaines31/marketingskills/blob/main/LICEN
 # Product Marketing Context
 ## When to Use
 
-Use this skill when you need when the user wants to create or update their product marketing context document. Also use when the user mentions 'product context,' 'marketing context,' 'set up context,' 'positioning,' 'who is my target audience,' 'describe my product,' 'ICP,' 'ideal customer profile,' or wants to...
+Use this skill when you need to create or update their product marketing context document. Also use when the user mentions 'product context,' 'marketing context,' 'set up context,' 'positioning,' 'who is my target audience,' 'describe my product,' 'ICP,' 'ideal customer profile,' or wants to...
 
 
 You help users create and maintain a product marketing context document. This captures foundational positioning and messaging information that other marketing skills reference, so users don't repeat themselves.

package/bundled-skills/prometheus-configuration/SKILL.md

@@ -5,6 +5,17 @@ risk: critical
 source: community
 date_added: "2026-02-27"
 ---
+## Supporting material availability
+
+This catalog copy contains the inline guidance below, but does not include the following supporting paths. They are external prerequisites, not bundled files:
+
+- `<support-root>/assets/prometheus.yml.template`
+- `<support-root>/references/scrape-configs.md`
+- `<support-root>/references/recording-rules.md`
+- `<support-root>/scripts/validate-prometheus.sh`
+
+Ask for the original supporting material or an existing installation before using a step that depends on these paths; this catalog does not identify a verified download source for them. Resolve each path relative to that installation, inspect its contents, and verify any applicable license and execution prerequisites. Do not run a command or claim a referenced procedure was followed until its required file exists. Do not fabricate the missing scripts or treat an unrelated file with the same name as equivalent. Independent steps fully documented here can proceed within the user’s authorized scope; report any dependent step as unavailable.
+
 
 # Prometheus Configuration
 
@@ -20,7 +31,6 @@ Complete guide to Prometheus setup, metric collection, scrape configuration, and
 - Clarify goals, constraints, and required inputs.
 - Apply relevant best practices and validate outcomes.
 - Provide actionable steps and verification.
-- If detailed examples are required, open `resources/implementation-playbook.md`.
 
 ## Purpose
 

package/bundled-skills/prompt-engineering-patterns/SKILL.md

@@ -20,7 +20,6 @@ Master advanced prompt engineering techniques to maximize LLM performance, relia
 - Clarify goals, constraints, and required inputs.
 - Apply relevant best practices and validate outcomes.
 - Provide actionable steps and verification.
-- If detailed examples are required, open `resources/implementation-playbook.md`.
 
 ## Use this skill when
 

package/bundled-skills/public-relations/SKILL.md

@@ -13,7 +13,7 @@ license_source: https://github.com/coreyhaines31/marketingskills/blob/main/LICEN
 # Public Relations & Earned Media
 ## When to Use
 
-Use this skill when you need when the user wants help with public relations, earned media, press coverage, journalist outreach, or media strategy (not pull requests). Also use when the user mentions 'PR,' 'public relations,' 'press,' 'press release,' 'press coverage,' 'media outreach,' 'pitch a journalist,' 'get...
+Use this skill when the user wants help with public relations, earned media, press coverage, journalist outreach, or media strategy (not pull requests). Also use when the user mentions 'PR,' 'public relations,' 'press,' 'press release,' 'press coverage,' 'media outreach,' 'pitch a journalist,' 'get...
 
 
 You are an expert in earned media for software products. Your goal is to help the user get covered by journalists, podcasts, and newsletters — efficiently, with respect for the people on the other end of the pitch.

package/bundled-skills/pubmed-database/SKILL.md

@@ -8,6 +8,16 @@ risk: critical
 source: community
 date_added: "2026-09-04"
 ---
+## Supporting material availability
+
+This catalog copy contains the inline guidance below, but does not include the following supporting paths. They are external prerequisites, not bundled files:
+
+- `<support-root>/references/api_reference.md`
+- `<support-root>/references/search_syntax.md`
+- `<support-root>/references/common_queries.md`
+
+Ask for the original supporting material or an existing installation before using a step that depends on these paths; this catalog does not identify a verified download source for them. Resolve each path relative to that installation, inspect its contents, and verify any applicable license and execution prerequisites. Do not run a command or claim a referenced procedure was followed until its required file exists. Do not fabricate the missing scripts or treat an unrelated file with the same name as equivalent. Independent steps fully documented here can proceed within the user’s authorized scope; report any dependent step as unavailable.
+
 
 # PubMed Database
 

package/bundled-skills/pypict-skill/SKILL.md

@@ -12,15 +12,28 @@ date_added: "2026-02-27"
 
 Pairwise test generation
 
-## When to Use This Skill
+## When to Use
 
-Use this skill when you need to work with pairwise test generation.
+Design a small test matrix covering every pair of values across discrete factors,
+when exhaustive combinations are too costly and pairwise coverage is appropriate.
 
-## Instructions
+## Procedure
 
-This skill provides guidance and patterns for pairwise test generation.
+1. Define factors, permitted values and real invalid-combination constraints.
+2. Inspect an actual installed pairwise generator and its supported input format;
+   this entrypoint does not bundle a Python package or executable.
+3. Generate candidate rows and independently enumerate covered valid value pairs.
+   Missing pairs must remain visible; constraints must not be invented to hide them.
+4. Convert rows into tests with expected behavior, not just input combinations.
 
-For more information, see the [source repository](https://github.com/omkamal/pypict-claude-skill/blob/main/SKILL.md).
+For three binary factors, this illustrative matrix covers all two-factor pairs:
+
+```json
+[[0,0,0],[0,1,1],[1,0,1],[1,1,0]]
+```
+
+Pair coverage is not correctness or coverage of three-way interactions. Add known
+boundary, authorization and failure cases separately.
 
 ## Example
 

package/bundled-skills/python-testing-patterns/resources/implementation-playbook.md

@@ -1,6 +1,6 @@
 # Python Testing Patterns Implementation Playbook
 
-This file contains detailed patterns, checklists, and code samples referenced by the skill.
+Examples are isolated teaching fixtures. Stubbed database/network tests do not exercise a deployed system. Confirm project-local dependency versions, preserve synthetic data and do not enable coverage uploads without destination authorization. Naming-only and marker-only examples must be explicitly skipped until real assertions are implemented.
 
 # Python Testing Patterns
 
@@ -207,7 +207,10 @@ import pytest
 
 def is_valid_email(email: str) -> bool:
     """Check if email is valid."""
-    return "@" in email and "." in email.split("@")[1]
+    parts = email.split("@")
+    return len(parts) == 2 and bool(parts[0]) and "." in parts[1] and not parts[1].startswith(".") and not parts[1].endswith(".")
+
+# Teaching predicate for these fixtures, not complete RFC email validation.
 
 
 @pytest.mark.parametrize("email,expected", [
@@ -368,6 +371,7 @@ def test_exception_info():
 ```python
 # test_async.py
 import pytest
+import pytest_asyncio
 import asyncio
 
 async def fetch_data(url: str) -> dict:
@@ -395,7 +399,7 @@ async def test_concurrent_fetches():
     assert all("data" in r for r in results)
 
 
-@pytest.fixture
+@pytest_asyncio.fixture
 async def async_client():
     """Async fixture."""
     client = {"connected": True}
@@ -634,17 +638,20 @@ def test_sorted_list_properties(lst):
 ### Test Naming
 
 ```python
-# Good test names
+# Good test names; naming-only examples are not passing behavioral tests.
+@pytest.mark.skip(reason="Naming illustration; no implementation")
 def test_user_creation_with_valid_data():
     """Clear name describes what is being tested."""
     pass
 
 
+@pytest.mark.skip(reason="Naming illustration; no implementation")
 def test_login_fails_with_invalid_password():
     """Name describes expected behavior."""
     pass
 
 
+@pytest.mark.skip(reason="Naming illustration; no implementation")
 def test_api_returns_404_for_missing_resource():
     """Specific about inputs and expected outcomes."""
     pass
@@ -667,6 +674,7 @@ def test_function():  # Doesn't explain what's tested
 
 ```python
 # test_markers.py
+import os
 import pytest
 
 @pytest.mark.slow
@@ -677,6 +685,7 @@ def test_slow_operation():
 
 
 @pytest.mark.integration
+@pytest.mark.skip(reason="Integration illustration; implement real assertions")
 def test_database_integration():
     """Mark integration tests."""
     pass

package/bundled-skills/qiskit/SKILL.md

@@ -8,6 +8,9 @@ risk: critical
 source: community
 date_added: "2026-09-04"
 ---
+## Bundled upstream support
+
+Supporting files are included at skill-relative paths. See [UPSTREAM-NOTICE.md](UPSTREAM-NOTICE.md) for their pinned sources, licenses, hashes, and import changes.
 
 # Qiskit