opencode-skills-collection 4.0.54 → 4.0.55

package/bundled-skills/.antigravity-install-manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "updatedAt": "2026-09-06T01:38:35.007Z",
+  "updatedAt": "2026-09-07T01:36:38.487Z",
   "entries": [
     "00-andruia-consultant",
     "007",

package/bundled-skills/antigravity-maintainer-batch-release/SKILL.md

@@ -82,6 +82,14 @@ Before changing anything:
 
 When changing maintainer scripts, workflows, or policy, update the canonical skill, maintainer documentation, and regression tests in the same source PR. Add a negative test for every failure mode being fixed, run the relevant dry-run path, and reject any implementation/documentation mismatch. Source PRs must exclude generated registries and plugin mirrors; the protected canonical-sync PR owns that derived state, except for files intentionally staged by the scripted protected-release flow.
 
+## Repository documentation consistency
+
+When auditing repository documentation, compare operational guides and translations with exact-base scripts and workflow behavior. Check local links, heading anchors and documented npm commands with `tools/scripts/tests/test_documentation_consistency.py`; dated evidence and backup snapshots are historical, not current instructions. Keep canonical guides discoverable from `docs/README.md`, distinguish source merge from release availability, and report the scope of the audit without claiming that all skill procedures or external integrations ran.
+
+## Specialized Plugin Consistency
+
+Use `data/specialized-plugin-candidates.json` for specialized-plugin membership and `data/editorial-bundles.json` for the installable composition, descriptions, limits and starter prompts. Review changes against canonical `skills_index.json`; keep IDs stable unless a migration is explicitly requested. Derive the web catalog and prerender/live-verifier counts from these sources instead of maintaining copied lists or fixed counts. Verify full skill-list expansion, source-to-web parity and a negative stale-count case. The specialized-resource regression must reject missing prose-declared local support paths and verify their bytes in generated specialized bundles; fenced application examples remain a separate semantic review. Run the pure-example regressions when editing documented calculations or chunking behavior. Regenerate plugin artifacts as evidence, but leave their commit to the protected canonical-sync lane. A source refresh does not authorize release or deployment.
+
 ## Hosted Catalog and Legacy Redirect Bridge
 
 Treat the current catalog and the legacy user-site bridge as one public system:
@@ -113,9 +121,10 @@ For AAS CLI, MCP, stack, catalog-cache, or Workbench changes:
    - Explicit caller search filters may narrow retrieval; they never define skill eligibility. For search changes, verify backward-compatible broad matching, all-term matching, bounded filters, category aliases, stable pagination, complete-catalog reachability without filters, and preservation of supplied options through evidence export and inspection.
 4. Keep `aas-stack.json` free of Core selection policy. It pins catalog identity, targets, goals, and the exact IDs selected by the agent. `compose_stack` validates and records that selection; missing or cautionary metadata must never make a canonical skill unselectable or unusable.
 5. Keep the supported public path at manifest validation and immutable plan preview. Planning may write only the requested plan artifact; it must not materialize skill payloads or AAS managed state in the target.
+   - Verify manifest-to-installer command preparation preserves exact agent-selected IDs and catalog version, rejects empty or unknown selections, quotes shell arguments, and only emits a dry run. Runtime auto-resolution must stay offline and bounded, fully verify cached bytes, and reject multiple verified identities; never infer skill suitability from runtime or metadata checks. Exercise actual packed installation in a temporary destination, compare all selected file bytes, repeat it, preserve unmanaged files, and reject moved-release and symlink-target cases. Distinguish fixture publication resolution from a real published-release/client check; the aggregate must reject missing installation evidence. Require both Linux and Windows packed receipts. Execute the emitted PowerShell command with both PowerShell 7 and Windows PowerShell 5.1 on a disposable Windows runner, recording and checking both actual shell versions, including paths with spaces and apostrophes, full payload comparison, repeat/prune behavior and junction rejection. Local Git/publication fixtures are not proof of registry availability or a native client session.
    - Infer a target only for a validated single-target manifest; require an explicit choice otherwise. Verify that the cached runtime's catalog matches the manifest, and keep runtime integrity, cache location and destination explicit. Document the separate direct-installer handoff without implying it applies Core plans.
    - Workbench evidence imports must remain bounded and in memory. Verify artifact digests, project references, manifest/catalog/profile/selection bindings, conflict displays and replacement of stale results. Identify browser checks separately from full Core inspection and semantic judgment. Recorded examples need real inputs and observed checks; optional feedback may export only user-entered fields after an explicit action, without telemetry or imported project data.
-   - Verify large manifest and evidence round trips through real stdio, not just in-process handlers. Artifact arguments may use the existing 256 KiB frame ceiling; ordinary requests and unrelated metadata remain bounded at 4 KiB. Rejected, safely parsed requests must retain a bounded request ID; never reflect malformed or unbounded IDs.
+   - Verify large manifest and evidence round trips through real stdio, not just in-process handlers. Artifact arguments may use the existing 256 KiB frame ceiling; ordinary requests and unrelated metadata remain bounded at 4 KiB. Rejected, safely parsed requests must retain a bounded request ID; never reflect malformed or unbounded IDs. Keep overload errors correlated to bounded, strictly parsed request IDs; valid notifications receive no response, including when the queue is full or a handler fails. Reject invalid envelopes without reflecting invalid IDs, and test the burst path through real stdio.
 6. Treat apply and recovery as experimental opt-ins outside the supported preview claim. Do not add apply/recovery, benchmark, fuzz, crash/race, or synthetic verifier work unless the user explicitly places it in scope.
 7. When the task asks for end-to-end client proof, use a real supported client that discovers and invokes the local AAS MCP tools; direct stdio probes and automated tests do not substitute for that evidence.
 8. Do not tag, publish npm, deploy Pages, or write real user MCP configuration without the separately required publication approval.

package/bundled-skills/backend-security-coder/resources/implementation-playbook.md

@@ -0,0 +1,23 @@
+# Backend security implementation
+
+## Inputs
+
+Endpoint code, request schema, identity/tenant model, persistence adapter and existing tests.
+
+## Procedure
+
+1. Trace each untrusted field from request to database, outbound call and response. Record the resource owner separately from the authenticated caller.
+2. Implement allowlisted input fields, parameterized persistence and server-side resource authorization before side effects. Keep error responses generic and logs free of request bodies or credentials.
+3. Exercise anonymous, wrong-role, wrong-tenant, malformed and oversized requests in a disposable test environment. Check the database and outbound-call mocks to prove denied requests did not act.
+
+## Worked example
+
+A user can edit another tenant's invoice by changing its ID. Add a tenant-bound lookup and test own-tenant success plus cross-tenant denial with unchanged stored data.
+
+## Verification and handoff
+
+Report the actual files or configuration changed, checks performed, observed results and any untested environment. Keep the original inputs and evidence sufficient to reproduce the conclusion.
+
+## Limitations
+
+An authenticated request is not proof of resource ownership. A passing scanner is not proof that authorization works.

package/bundled-skills/business-analyst/resources/implementation-playbook.md

@@ -0,0 +1,23 @@
+# Business analysis decision brief
+
+## Inputs
+
+Decision owner, business question, source tables, reporting window, definitions and known data gaps.
+
+## Procedure
+
+1. Write the decision and alternatives before choosing metrics. Define grain, population, exclusions, currency and time zone.
+2. Check missing values, duplicates and join cardinality. Reconcile totals to a small hand-calculated sample before segmenting or forecasting.
+3. Separate observed results, assumptions and recommendations. Deliver reproducible calculations and a decision threshold; identify which missing evidence could change the choice.
+
+## Worked example
+
+Compare two acquisition channels using reconciled spend and distinct acquired customers for the same period. Keep attribution uncertainty visible rather than inferring causality from conversion differences.
+
+## Verification and handoff
+
+Report the actual files or configuration changed, checks performed, observed results and any untested environment. Keep the original inputs and evidence sufficient to reproduce the conclusion.
+
+## Limitations
+
+Do not invent benchmarks, forecast accuracy or causal effects. A chart cannot repair an ambiguous denominator.

package/bundled-skills/devops-troubleshooter/resources/implementation-playbook.md

@@ -0,0 +1,23 @@
+# DevOps failure investigation
+
+## Inputs
+
+Affected service and environment, impact window, recent changes, authorized read access and recovery owner.
+
+## Procedure
+
+1. Capture the failing symptom and a healthy comparison. Read bounded logs, metrics, deployment identity and dependency status without dumping environment variables.
+2. Write competing hypotheses and choose the cheapest discriminating observation. Preserve timestamps and exact filters so another engineer can reproduce the evidence.
+3. Prepare a bounded mitigation with rollback and abort conditions. Apply only within authorized operational scope, then verify the original user journey and dependent services.
+
+## Worked example
+
+After a rollout, requests time out while CPU stays normal. Compare connection-pool occupancy and downstream latency across old and new instances before proposing scaling.
+
+## Verification and handoff
+
+Report the actual files or configuration changed, checks performed, observed results and any untested environment. Keep the original inputs and evidence sufficient to reproduce the conclusion.
+
+## Limitations
+
+Correlation with a deployment is not proof of cause. Avoid broad restarts, destructive cleanup and fault injection during diagnosis.

package/bundled-skills/distributed-tracing/SKILL.md

@@ -8,451 +8,38 @@ date_added: "2026-02-27"
 
 # Distributed Tracing
 
-Implement distributed tracing with Jaeger and Tempo for request flow visibility across microservices.
+## When to Use
 
-## Do not use this skill when
+Trace a request across services, diagnose latency and error propagation, or add observable boundaries to a new integration.
 
-- The task is unrelated to distributed tracing
-- You need a different domain or tool outside this scope
+## Inputs and prerequisites
 
-## Instructions
+Record installed SDK and backend versions, permitted collector endpoints, the service graph and a staging request. Inspect the installed version's primary documentation before selecting exporter APIs or deployment configuration. This bundle does not install a tracing backend.
 
-- 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`.
+## Procedure
 
-## Purpose
+1. Read `resources/implementation-playbook.md` and identify one user journey.
+2. Configure the matching OpenTelemetry SDK and OTLP exporter before loading instrumented frameworks. Use `references/instrumentation.md` for propagation, shutdown and privacy checks.
+3. Configure Jaeger using `references/jaeger-setup.md`, or the existing Tempo/collector deployment's supported configuration. Review listeners, authentication, transport protection, storage and retention before any deployment.
+4. Propagate context over HTTP and asynchronous messages. Use stable operation names and allowlisted attributes. Do not log credentials, raw request bodies or sensitive query values.
+5. Send successful and failing staging requests and verify connected spans in the backend. Record service identity, parentage, duration units and exporter errors.
+6. Measure queue loss and overhead. Select sampling based on those observations; no fixed percentage guarantees coverage or performance.
 
-Track requests across distributed systems to understand latency, dependencies, and failure points.
+## Example
 
-## Use this skill when
+A checkout calls inventory and payment. Verify that the root request and both downstream operations share a trace, that a simulated payment timeout is recorded, and that no card data is present. Repeat with exporter connectivity unavailable: request handling must retain the application's defined behavior.
 
-- Debug latency issues
-- Understand service dependencies
-- Identify bottlenecks
-- Trace error propagation
-- Analyze request paths
+## Verification
 
-## Distributed Tracing Concepts
+- Actual trace evidence for each exercised boundary, including queue consumers.
+- Allowed fields only; bounded attribute cardinality.
+- Shutdown flush and exporter failure behavior observed.
+- Access, storage and retention checked independently from UI availability.
 
-### Trace Structure
-```
-Trace (Request ID: abc123)
-  ↓
-Span (frontend) [100ms]
-  ↓
-Span (api-gateway) [80ms]
-  ├→ Span (auth-service) [10ms]
-  └→ Span (user-service) [60ms]
-      └→ Span (database) [40ms]
-```
-
-### Key Components
-- **Trace** - End-to-end request journey
-- **Span** - Single operation within a trace
-- **Context** - Metadata propagated between services
-- **Tags** - Key-value pairs for filtering
-- **Logs** - Timestamped events within a span
-
-## Jaeger Setup
-
-### Kubernetes Deployment
-
-```bash
-# Deploy Jaeger Operator
-kubectl create namespace observability
-kubectl create -f https://github.com/jaegertracing/jaeger-operator/releases/download/v1.51.0/jaeger-operator.yaml -n observability
-
-# Deploy Jaeger instance
-kubectl apply -f - <<EOF
-apiVersion: jaegertracing.io/v1
-kind: Jaeger
-metadata:
-  name: jaeger
-  namespace: observability
-spec:
-  strategy: production
-  storage:
-    type: elasticsearch
-    options:
-      es:
-        server-urls: http://elasticsearch:9200
-  ingress:
-    enabled: true
-EOF
-```
-
-### Docker Compose
-
-```yaml
-version: '3.8'
-services:
-  jaeger:
-    image: jaegertracing/all-in-one:latest
-    ports:
-      - "5775:5775/udp"
-      - "6831:6831/udp"
-      - "6832:6832/udp"
-      - "5778:5778"
-      - "16686:16686"  # UI
-      - "14268:14268"  # Collector
-      - "14250:14250"  # gRPC
-      - "9411:9411"    # Zipkin
-    environment:
-      - COLLECTOR_ZIPKIN_HOST_PORT=:9411
-```
-
-**Reference:** See `references/jaeger-setup.md`
-
-## Application Instrumentation
-
-### OpenTelemetry (Recommended)
-
-#### Python (Flask)
-```python
-from opentelemetry import trace
-from opentelemetry.exporter.jaeger.thrift import JaegerExporter
-from opentelemetry.sdk.resources import SERVICE_NAME, Resource
-from opentelemetry.sdk.trace import TracerProvider
-from opentelemetry.sdk.trace.export import BatchSpanProcessor
-from opentelemetry.instrumentation.flask import FlaskInstrumentor
-from flask import Flask
-
-# Initialize tracer
-resource = Resource(attributes={SERVICE_NAME: "my-service"})
-provider = TracerProvider(resource=resource)
-processor = BatchSpanProcessor(JaegerExporter(
-    agent_host_name="jaeger",
-    agent_port=6831,
-))
-provider.add_span_processor(processor)
-trace.set_tracer_provider(provider)
-
-# Instrument Flask
-app = Flask(__name__)
-FlaskInstrumentor().instrument_app(app)
-
-@app.route('/api/users')
-def get_users():
-    tracer = trace.get_tracer(__name__)
-
-    with tracer.start_as_current_span("get_users") as span:
-        span.set_attribute("user.count", 100)
-        # Business logic
-        users = fetch_users_from_db()
-        return {"users": users}
-
-def fetch_users_from_db():
-    tracer = trace.get_tracer(__name__)
-
-    with tracer.start_as_current_span("database_query") as span:
-        span.set_attribute("db.system", "postgresql")
-        span.set_attribute("db.statement", "SELECT * FROM users")
-        # Database query
-        return query_database()
-```
-
-#### Node.js (Express)
-```javascript
-const { NodeTracerProvider } = require('@opentelemetry/sdk-trace-node');
-const { JaegerExporter } = require('@opentelemetry/exporter-jaeger');
-const { BatchSpanProcessor } = require('@opentelemetry/sdk-trace-base');
-const { registerInstrumentations } = require('@opentelemetry/instrumentation');
-const { HttpInstrumentation } = require('@opentelemetry/instrumentation-http');
-const { ExpressInstrumentation } = require('@opentelemetry/instrumentation-express');
-
-// Initialize tracer
-const provider = new NodeTracerProvider({
-  resource: { attributes: { 'service.name': 'my-service' } }
-});
-
-const exporter = new JaegerExporter({
-  endpoint: 'http://jaeger:14268/api/traces'
-});
-
-provider.addSpanProcessor(new BatchSpanProcessor(exporter));
-provider.register();
-
-// Instrument libraries
-registerInstrumentations({
-  instrumentations: [
-    new HttpInstrumentation(),
-    new ExpressInstrumentation(),
-  ],
-});
-
-const express = require('express');
-const app = express();
-
-app.get('/api/users', async (req, res) => {
-  const tracer = trace.getTracer('my-service');
-  const span = tracer.startSpan('get_users');
-
-  try {
-    const users = await fetchUsers();
-    span.setAttributes({ 'user.count': users.length });
-    res.json({ users });
-  } finally {
-    span.end();
-  }
-});
-```
-
-#### Go
-```go
-package main
-
-import (
-    "context"
-    "go.opentelemetry.io/otel"
-    "go.opentelemetry.io/otel/exporters/jaeger"
-    "go.opentelemetry.io/otel/sdk/resource"
-    sdktrace "go.opentelemetry.io/otel/sdk/trace"
-    semconv "go.opentelemetry.io/otel/semconv/v1.4.0"
-)
-
-func initTracer() (*sdktrace.TracerProvider, error) {
-    exporter, err := jaeger.New(jaeger.WithCollectorEndpoint(
-        jaeger.WithEndpoint("http://jaeger:14268/api/traces"),
-    ))
-    if err != nil {
-        return nil, err
-    }
-
-    tp := sdktrace.NewTracerProvider(
-        sdktrace.WithBatcher(exporter),
-        sdktrace.WithResource(resource.NewWithAttributes(
-            semconv.SchemaURL,
-            semconv.ServiceNameKey.String("my-service"),
-        )),
-    )
-
-    otel.SetTracerProvider(tp)
-    return tp, nil
-}
-
-func getUsers(ctx context.Context) ([]User, error) {
-    tracer := otel.Tracer("my-service")
-    ctx, span := tracer.Start(ctx, "get_users")
-    defer span.End()
-
-    span.SetAttributes(attribute.String("user.filter", "active"))
-
-    users, err := fetchUsersFromDB(ctx)
-    if err != nil {
-        span.RecordError(err)
-        return nil, err
-    }
-
-    span.SetAttributes(attribute.Int("user.count", len(users)))
-    return users, nil
-}
-```
-
-**Reference:** See `references/instrumentation.md`
-
-## Context Propagation
-
-### HTTP Headers
-```
-traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
-tracestate: congo=t61rcWkgMzE
-```
-
-### Propagation in HTTP Requests
-
-#### Python
-```python
-from opentelemetry.propagate import inject
-
-headers = {}
-inject(headers)  # Injects trace context
-
-response = requests.get('http://downstream-service/api', headers=headers)
-```
-
-#### Node.js
-```javascript
-const { propagation } = require('@opentelemetry/api');
-
-const headers = {};
-propagation.inject(context.active(), headers);
-
-axios.get('http://downstream-service/api', { headers });
-```
-
-## Tempo Setup (Grafana)
-
-### Kubernetes Deployment
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: tempo-config
-data:
-  tempo.yaml: |
-    server:
-      http_listen_port: 3200
-
-    distributor:
-      receivers:
-        jaeger:
-          protocols:
-            thrift_http:
-            grpc:
-        otlp:
-          protocols:
-            http:
-            grpc:
-
-    storage:
-      trace:
-        backend: s3
-        s3:
-          bucket: tempo-traces
-          endpoint: s3.amazonaws.com
-
-    querier:
-      frontend_worker:
-        frontend_address: tempo-query-frontend:9095
----
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: tempo
-spec:
-  replicas: 1
-  template:
-    spec:
-      containers:
-      - name: tempo
-        image: grafana/tempo:latest
-        args:
-          - -config.file=/etc/tempo/tempo.yaml
-        volumeMounts:
-        - name: config
-          mountPath: /etc/tempo
-      volumes:
-      - name: config
-        configMap:
-          name: tempo-config
-```
-
-**Reference:** See `assets/jaeger-config.yaml.template`
-
-## Sampling Strategies
-
-### Probabilistic Sampling
-```yaml
-# Sample 1% of traces
-sampler:
-  type: probabilistic
-  param: 0.01
-```
-
-### Rate Limiting Sampling
-```yaml
-# Sample max 100 traces per second
-sampler:
-  type: ratelimiting
-  param: 100
-```
-
-### Adaptive Sampling
-```python
-from opentelemetry.sdk.trace.sampling import ParentBased, TraceIdRatioBased
-
-# Sample based on trace ID (deterministic)
-sampler = ParentBased(root=TraceIdRatioBased(0.01))
-```
-
-## Trace Analysis
-
-### Finding Slow Requests
-
-**Jaeger Query:**
-```
-service=my-service
-duration > 1s
-```
-
-### Finding Errors
-
-**Jaeger Query:**
-```
-service=my-service
-error=true
-tags.http.status_code >= 500
-```
-
-### Service Dependency Graph
-
-Jaeger automatically generates service dependency graphs showing:
-- Service relationships
-- Request rates
-- Error rates
-- Average latencies
-
-## Best Practices
-
-1. **Sample appropriately** (1-10% in production)
-2. **Add meaningful tags** (user_id, request_id)
-3. **Propagate context** across all service boundaries
-4. **Log exceptions** in spans
-5. **Use consistent naming** for operations
-6. **Monitor tracing overhead** (<1% CPU impact)
-7. **Set up alerts** for trace errors
-8. **Implement distributed context** (baggage)
-9. **Use span events** for important milestones
-10. **Document instrumentation** standards
-
-## Integration with Logging
-
-### Correlated Logs
-```python
-import logging
-from opentelemetry import trace
-
-logger = logging.getLogger(__name__)
-
-def process_request():
-    span = trace.get_current_span()
-    trace_id = span.get_span_context().trace_id
-
-    logger.info(
-        "Processing request",
-        extra={"trace_id": format(trace_id, '032x')}
-    )
-```
-
-## Troubleshooting
-
-**No traces appearing:**
-- Check collector endpoint
-- Verify network connectivity
-- Check sampling configuration
-- Review application logs
-
-**High latency overhead:**
-- Reduce sampling rate
-- Use batch span processor
-- Check exporter configuration
-
-## Reference Files
-
-- `references/jaeger-setup.md` - Jaeger installation
-- `references/instrumentation.md` - Instrumentation patterns
-- `assets/jaeger-config.yaml.template` - Jaeger configuration
+## Limitations
 
-## Related Skills
+Head sampling can discard errors before tail sampling sees them. In-memory demos do not prove durable storage. Context propagation and cross-service clocks need actual integration tests; this guide is not a runnable multi-service application.
 
-- `prometheus-configuration` - For metrics
-- `grafana-dashboards` - For visualization
-- `slo-implementation` - For latency SLOs
+## Sources
 
-## 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.
-- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
+- [OpenTelemetry exporter documentation](https://opentelemetry.io/docs/languages/python/exporters/) — use the installed SDK's matching documentation.

package/bundled-skills/distributed-tracing/references/instrumentation.md

@@ -0,0 +1,13 @@
+# Instrumentation checks
+
+## Inputs
+
+Choose the installed OpenTelemetry SDK and matching exporter. Initialize before instrumented libraries and use OTLP for the configured collector transport.
+
+## Procedure and verification
+
+Follow one request across two services. Assert trace identity and parent-child relationships, exercise an exception, and flush on orderly shutdown. Allowlist low-cardinality operation attributes; exclude credentials, raw payloads and sensitive query values. Verify exporter failures do not make the application request fail.
+
+## Limitations
+
+A local span is not proof of context propagation. Sampling and queue overflow can discard traces; test the actual failure and shutdown behavior.

package/bundled-skills/distributed-tracing/references/jaeger-setup.md

@@ -0,0 +1,13 @@
+# Jaeger integration checklist
+
+## Inputs
+
+Record the installed Jaeger version, storage backend, retention, query access and OTLP transport. Use that version's deployment guide; the collector endpoint and query UI are different services.
+
+## Procedure and verification
+
+Prepare configuration in a disposable environment. Restrict listeners and query access, use transport protection appropriate to the network, and verify storage credentials without exposing them in manifests. Send a synthetic trace and locate it through the query interface. Restart the disposable instance to check the chosen persistence behavior.
+
+## Limitations
+
+An in-memory demonstration is not durable production storage. A healthy UI does not prove ingestion, retention or authorization. Record the exact tested configuration and rollback path.

package/bundled-skills/distributed-tracing/resources/implementation-playbook.md

@@ -0,0 +1,23 @@
+# Tracing integration playbook
+
+## Inputs
+
+Service graph, installed SDK versions, allowed collector endpoint, representative requests and telemetry policy.
+
+## Procedure
+
+1. Map one request through entrypoint, outbound call and downstream handler. Use the same propagation format and distinguish service identity from operation names.
+2. Configure the SDK and exporter before instrumented libraries load. Use a bounded batch queue and graceful shutdown. Allowlist attributes and omit credentials, raw SQL values and request bodies.
+3. Send one successful and one failed staging request. Verify connected spans, duration units, expected service names and exporter failures. Measure overhead before choosing a sampling rate.
+
+## Worked example
+
+A checkout calls inventory and payment. Locate both calls under the checkout trace and ensure a timeout is visible without recording payment data.
+
+## Verification and handoff
+
+Report the actual files or configuration changed, checks performed, observed results and any untested environment. Keep the original inputs and evidence sufficient to reproduce the conclusion.
+
+## Limitations
+
+Sampling may drop an error before a later collector sees it. Never promise complete error retention from a head-sampled stream.

package/bundled-skills/django-pro/resources/implementation-playbook.md

@@ -0,0 +1,23 @@
+# Django feature implementation
+
+## Inputs
+
+Installed Django/DRF versions, models, permissions, database backend and existing test commands.
+
+## Procedure
+
+1. Trace the endpoint through middleware, view, serializer and queryset. Reuse the project's authentication and transaction boundaries.
+2. Implement the smallest change and a migration only when needed. Scope list and detail querysets by tenant; validate writes and use server-owned fields for ownership.
+3. Test authorized and unauthorized access, validation failure and rollback. Inspect query count and migration behavior on a disposable database before preparing deployment.
+
+## Worked example
+
+Add a project notes endpoint. Test that another tenant cannot list, retrieve or create notes in that project; verify the allowed user can.
+
+## Verification and handoff
+
+Report the actual files or configuration changed, checks performed, observed results and any untested environment. Keep the original inputs and evidence sufficient to reproduce the conclusion.
+
+## Limitations
+
+Async views do not make synchronous database work non-blocking. Check the installed framework's supported async and transaction behavior.