docs(governance): add DPGA policy evidence

Validated documentation, links, markdown checks, and CI.

CODE_OF_CONDUCT.md

@@ -29,5 +29,16 @@ project spaces.
 
 ## Reporting
 
-Report conduct issues privately to the maintainers through a private maintainer
-channel. Do not use public issues for personal or sensitive reports.
+Report conduct issues privately to
+[ifly_opensource@iflytek.com](mailto:ifly_opensource@iflytek.com) with the subject
+`SkillHub Code of Conduct report`. Do not use public issues for personal, sensitive,
+or confidential reports.
+
+Reports are handled under the iFLYTEK community
+[incident resolution procedures](https://github.com/iflytek/community/blob/master/code-of-conduct/coc-incident-resolution-procedures.md).
+Information is shared only with people who need it to review the report, protect
+participants, or comply with law. Retaliation for a good-faith report is prohibited.
+
+People materially affected by a conduct decision may request an impartial review
+through the appeal process in the
+[Content Safety Policy](docs/CONTENT_SAFETY.md#appeals).

README.md

@@ -66,6 +66,18 @@ with the Skill's source and the problem it solves, or submit a PR by following t
 - 🛠️ **[Developer Docs](https://zread.ai/iflytek/skillhub)** — Architecture, API reference, local development, deployment and operations
 - 🐍 **[Python Examples](./examples/python)** — Search, download, and publish skills from Python via the REST API
 
+## Governance and Safety
+
+- **[Privacy and Data Governance](docs/PRIVACY_AND_DATA_GOVERNANCE.md)** —
+  Data categories, operator responsibilities, retention, portability, and incident
+  handling for public and self-hosted instances
+- **[Content Safety](docs/CONTENT_SAFETY.md)** — Package safety expectations,
+  review and reporting controls, appeals, and child-safety responsibilities
+- **[Code of Conduct](CODE_OF_CONDUCT.md)** — Community standards and the private
+  reporting channel
+- **[Security Policy](https://github.com/iflytek/.github/blob/main/SECURITY.md)** —
+  Private vulnerability reporting and coordinated disclosure
+
 ## Highlights
 
 - **Self-Hosted & Private** — Deploy on your own infrastructure.

docs/CONTENT_SAFETY.md

@@ -0,0 +1,220 @@
+# Content Safety Policy
+
+Last updated: August 18, 2026
+
+## Purpose and scope
+
+SkillHub accepts, stores, reviews, and distributes agent skill packages. Packages
+can contain instructions, scripts, documentation, examples, images, and other files
+that influence an AI agent or execute on a user's computer. Profiles, namespace
+descriptions, reviews, reports, ratings, and release notes also contain user-supplied
+content.
+
+This document describes the project's content-safety expectations, available
+technical and governance controls, and the responsibilities of people who publish,
+review, operate, and install skills.
+
+The SkillHub maintainers do not operate or moderate every independently hosted
+instance. Each operator must assess its users, jurisdiction, deployment model, and
+risk; publish enforceable rules and a reporting channel; configure appropriate
+controls; and staff its own review, appeal, and emergency processes.
+
+## Baseline rules
+
+SkillHub instances should not knowingly publish or distribute content or packages
+that:
+
+- violate applicable law or another person's intellectual-property, privacy, or
+  other rights;
+- sexually exploit or endanger children, including child sexual abuse material;
+- credibly threaten, harass, or promote violence or hateful abuse against people;
+- expose personal, confidential, or authentication data without authorization;
+- contain malware, credential theft, destructive payloads, unauthorized access,
+  persistence, evasion, or instructions intended to defeat security controls;
+- impersonate people or organizations, facilitate fraud, or intentionally present
+  deceptive or materially misleading claims;
+- secretly collect, transmit, or use data beyond the skill's documented purpose;
+- conceal important external services, downloads, commands, permissions, or side
+  effects from reviewers and users; or
+- bypass an instance's review, scanning, namespace, visibility, or access-control
+  rules.
+
+Context matters. Legitimate security research, education, documentation, and
+defensive automation can discuss or test risky behavior without promoting harm.
+Reviewers should consider purpose, provenance, permissions, likely impact, and
+applicable law instead of relying on keywords alone.
+
+## Content and package risks
+
+A skill may instruct an agent to read or modify files, run commands, call external
+services, install dependencies, browse websites, or handle sensitive inputs.
+Documentation and examples may be inaccurate or omit important consequences.
+Images and archives may contain hidden payloads. Ratings or social signals do not
+prove that a package is safe, lawful, accurate, or suitable for a particular use.
+
+Publishers must accurately describe required permissions, external recipients,
+dependencies, expected side effects, supported environments, and known limitations.
+Installers must review package contents and apply least privilege before execution.
+
+## Available technical and governance controls
+
+SkillHub includes controls that an operator can combine according to its risk:
+
+- package limits and file-type validation, including size, file-count, extension,
+  and selected file-signature checks;
+- a configurable security scanner that can inspect uploaded packages and produce
+  findings for reviewers;
+- namespace and platform review workflows with approve, reject, withdraw, and
+  promotion decisions;
+- user reports and administrator actions such as hiding, archiving, rejecting, or
+  yanking content and versions;
+- platform and namespace RBAC for publishing and governance actions;
+- public, namespace-only, and private visibility; and
+- audit records and notifications for relevant governance activity.
+
+The implementation and operating guidance are documented in the
+[scanner guide](security-scanning.md),
+[review guide](skillhub/en/guide/review.md), and
+[security architecture](../document/docs/04-developer/architecture/security.md).
+
+## Important limitations
+
+These controls reduce risk but do not certify a package as safe or compliant:
+
+- scanner operation is configurable, and an operator can run SkillHub without an
+  enabled scanner;
+- optional LLM-backed analysis depends on the service selected by the operator and
+  can create additional privacy and reliability risks;
+- static, behavioral, metadata, and model-based analysis can produce false
+  positives and false negatives;
+- a successfully scanned package can still be misleading, vulnerable, or
+  malicious in context, or unsuitable for a specific environment;
+- privileged publication paths require operator governance and periodic review;
+  and
+- independently hosted instances can configure different review, visibility, and
+  enforcement practices.
+
+Operators must disclose which controls are active. A package that fails scanning
+or review should remain unavailable for ordinary installation until the failure
+is resolved through a documented process. Scanner failure must not be treated as
+proof that a package is safe.
+
+## Publisher responsibilities
+
+Before submitting a skill, a publisher should:
+
+- inspect every included file and remove secrets, personal data, build artifacts,
+  and unrelated binaries;
+- document commands, network destinations, external downloads, required
+  permissions, and persistent changes;
+- pin or constrain dependencies where practical and preserve their license notices;
+- provide evidence for security, compliance, or standards claims instead of relying
+  on labels alone;
+- test failure and rollback behavior in an isolated environment;
+- avoid manipulative instructions designed to override system, user, or operator
+  safety controls; and
+- update or withdraw a package when a material risk is discovered.
+
+## Operator safeguards
+
+Before opening an instance to publishers or installers, an operator should:
+
+- define permitted and prohibited content, reviewers, escalation owners, and
+  emergency contacts;
+- enable scanning and human review appropriate to the instance's exposure and
+  package risk;
+- restrict direct-publish and governance roles, log their use, and review them
+  regularly;
+- isolate scanning and package inspection from production secrets and sensitive
+  networks;
+- rate-limit uploads, downloads, reports, and automated activity;
+- preserve only the evidence needed for review and protect reporter identities;
+- provide a visible reporting channel and an impartial appeal route; and
+- train reviewers to handle malware, privacy, child-safety, fraud, and
+  intellectual-property reports safely.
+
+## Reporting
+
+For a skill or profile visible in a SkillHub instance, use that instance's report
+feature or contact the operator identified in its published policies. Include the
+package coordinate and version, the reason for concern, the time observed, and the
+minimum context needed to investigate. Do not execute a suspected malicious package
+or resend illegal, exploitative, personal, or confidential material through an
+unprotected channel.
+
+For abusive or harassing conduct on SkillHub project-managed community surfaces,
+report privately to
+[ifly_opensource@iflytek.com](mailto:ifly_opensource@iflytek.com) under the
+[Code of Conduct](../CODE_OF_CONDUCT.md). Report upstream security vulnerabilities
+privately to [security@iflytek.com](mailto:security@iflytek.com) under the
+[iFLYTEK organization security policy](https://github.com/iflytek/.github/blob/main/SECURITY.md).
+Do not disclose vulnerabilities or personal data in a public issue.
+
+## Review, action, and notice
+
+An operator's documented process should:
+
+1. triage imminent danger, child-safety concerns, credible malware, exposed
+   credentials, and active security incidents for urgent specialist handling;
+2. preserve only the evidence needed for a proportionate review;
+3. assess the package, context, applicable rule, law, provenance, permissions, and
+   likely user impact;
+4. take proportionate action, such as rejecting a version, hiding or yanking a
+   package, restricting an account, revoking a token, or escalating to an authorized
+   specialist;
+5. record the rule, evidence, and rationale and notify affected people when lawful
+   and safe; and
+6. provide an appeal route and use confirmed incidents to improve controls.
+
+SkillHub's review guide recommends completing routine package reviews within 24
+hours to avoid blocking publishers. That recommendation is not a historical average
+for safety reports and is not an emergency-response guarantee. The upstream project
+does not yet have enough comparable safety reports to publish a meaningful average
+assessment or action time. Each operator must publish targets appropriate to its
+risk, staffing, and legal obligations, with an urgent path for imminent harm and
+child safety.
+
+## Appeals
+
+A publisher, reporter, account holder, or other person materially affected by a
+governance decision should be able to request review through the instance
+operator's private channel. The request should identify the original decision and
+give a reason for review, such as significant new evidence, a material procedural
+error, a conflict of interest, or a clearly disproportionate action.
+
+Appeals should be handled by a person who did not make the original decision and
+has no conflict of interest. The reviewer may uphold, modify, or reverse the action,
+or require a new investigation. Temporary protective measures may remain in place
+while needed to protect people, systems, evidence, or legal obligations.
+
+For Code of Conduct decisions on project-managed community surfaces, send an appeal
+to [ifly_opensource@iflytek.com](mailto:ifly_opensource@iflytek.com) with the
+subject `SkillHub Code of Conduct appeal`. Include the original case reference,
+the outcome being challenged, and the reason for review. Appeal information must
+be limited to people who need it. Retaliation for a good-faith report or appeal
+is prohibited.
+
+## Children and young people
+
+SkillHub is a general-purpose developer and enterprise collaboration tool, not a
+child-directed service. An operator that permits use by children or processes their
+data must perform an age-appropriate risk assessment, use any legally required
+parental or guardian consent, minimize collection and profiling, restrict contact
+and high-risk package capabilities, provide child-accessible notices and reporting,
+and route serious concerns to trained personnel and appropriate authorities.
+
+If those protections cannot be provided, the instance should not be offered to
+children. The project Code of Conduct separately protects community participation
+from harassment regardless of age.
+
+## Privacy and policy review
+
+Package inspection, reports, audit logs, and investigations can expose sensitive
+information. They must follow the
+[Privacy and Data Governance Policy](PRIVACY_AND_DATA_GOVERNANCE.md) and the
+instance's own privacy notice and retention schedule.
+
+Material changes to this policy are made through the repository's public review
+process. Operators should periodically test their controls, review incident trends,
+and update their policy when the product, threat model, law, or operating context
+changes.

docs/PRIVACY_AND_DATA_GOVERNANCE.md

@@ -0,0 +1,187 @@
+# Privacy and Data Governance Policy
+
+Last updated: August 18, 2026
+
+## Purpose and scope
+
+SkillHub is open-source software for publishing, reviewing, discovering, and
+installing reusable agent skill packages. This document describes the project's
+privacy and data-governance expectations and the controls available to people who
+operate SkillHub instances.
+
+The SkillHub maintainers publish source code and project infrastructure. They do
+not operate or control every independently hosted instance. The organization or
+person operating an instance determines why and how personal data is processed in
+that environment and is responsible for publishing an instance-specific privacy
+notice, selecting lawful processing grounds, handling data-subject requests, and
+complying with applicable law.
+
+The public SkillHub service also publishes an in-product
+[privacy notice](https://skill.xfyun.cn/privacy). This project document supplements
+that notice for source-code reviewers and self-hosted operators. It is not legal
+advice and does not certify that every deployment is automatically compliant with
+any law.
+
+## Applicable law
+
+Privacy and data-protection obligations depend on the operator's legal entity,
+where the instance and its users are located, the people it serves, the data in
+skill packages, and the infrastructure and integrations selected by the operator.
+
+Before processing personal data, each operator must:
+
+- identify and document the domestic and international laws that apply;
+- determine and record the lawful basis for each material processing purpose;
+- complete any required privacy, child-safety, security, or transfer assessment;
+- reflect those obligations in notices, contracts, procedures, and configuration;
+  and
+- avoid or redesign processing that cannot be operated lawfully.
+
+Open-source availability and configurable controls support implementation. They
+do not replace an operator's legal analysis or operational responsibilities.
+
+## Data the software can process
+
+The exact data depends on the authentication, storage, email, observability,
+scanner, and deployment options selected by the operator. A SkillHub instance can
+process:
+
+- account and identity data, such as username, email address, avatar, OAuth
+  provider identifiers, account status, platform roles, and namespace membership;
+- authentication and security data, such as session identifiers, password hashes,
+  API token metadata, login events, IP addresses, device or browser information,
+  and password-reset records;
+- skill package content, including `SKILL.md`, scripts, documentation, images,
+  examples, license files, archives, and version metadata;
+- collaboration and governance data, such as namespaces, reviews, review comments,
+  promotion requests, reports, ratings, stars, notifications, and audit records;
+- usage and operational data, such as searches, downloads, request identifiers,
+  timestamps, errors, metrics, traces, application logs, and security findings;
+  and
+- configuration and connection data for object storage, identity providers, email,
+  monitoring, and optional scanning services.
+
+A skill package, review comment, profile, log entry, or security report can contain
+personal, confidential, or authentication data even when a field is not labelled
+as personal data. Operators and publishers must classify data according to its
+actual content and use.
+
+## Roles and responsibilities
+
+For an independently operated instance, the instance operator normally decides the
+purposes and means of processing and must document its role under applicable law.
+Publishers and namespace administrators are responsible for the content they upload
+and the access decisions they make. External identity, storage, email, monitoring,
+and scanner providers may process data under their own terms and assigned roles.
+
+The upstream SkillHub maintainers generally cannot access, correct, export, or
+delete data held by an independently operated instance. Requests concerning an
+instance must go to the operator identified in that instance's privacy notice.
+
+## Purpose limitation and data minimization
+
+Data should be collected only when needed to authenticate users, enforce access
+rules, publish and distribute skill packages, operate review and governance
+workflows, secure and troubleshoot the instance, and meet documented legal duties.
+
+Operators, administrators, and publishers should:
+
+- avoid placing secrets or unnecessary personal data in skill packages, README
+  files, examples, namespace profiles, reviews, or report details;
+- use pseudonymous or organization-scoped identifiers where practical;
+- configure the shortest retention and least visibility needed for each purpose;
+- redact sensitive values before sending packages or findings to an external
+  scanner, model, log sink, or support channel;
+- restrict privileged roles and review them regularly; and
+- document the source, purpose, recipients, lawful basis, and retention period for
+  each material category of personal data.
+
+## Storage, access, and isolation
+
+SkillHub supports authenticated access, platform and namespace RBAC, public,
+namespace-only and private visibility, audit logs, hashed API tokens, PostgreSQL,
+Redis, and local or S3-compatible object storage. These capabilities are building
+blocks, not a secure deployment by themselves.
+
+Operators are responsible for:
+
+- disabling development authentication and replacing example credentials before
+  exposing an instance;
+- using HTTPS for external traffic and protected networks for internal services;
+- applying least-privilege roles to users, services, databases, caches, and object
+  stores;
+- encrypting sensitive data and backups according to their threat model and legal
+  obligations;
+- storing secrets in an appropriate secrets manager rather than source code, skill
+  packages, client-side configuration, or logs;
+- testing namespace and object-storage isolation for their configuration;
+- restricting and monitoring access to packages, audit data, logs, traces, backups,
+  and security findings; and
+- applying supported security updates and maintaining a recovery process.
+
+## External services and international transfers
+
+OAuth providers, S3-compatible storage, email services, monitoring systems,
+mirrors, and optional scanner integrations can receive data from a SkillHub
+instance. An operator that enables an external service must assess its privacy and
+security terms, hosting locations, retention, subprocessors, training-data rules,
+and cross-border transfer mechanism.
+
+The optional scanner can process uploaded skill archives and findings. If an
+operator enables an external or LLM-backed scanner, that disclosure must be covered
+by the instance's privacy notice and data-flow review. A service does not become
+private merely because SkillHub can integrate with it.
+
+## Retention, deletion, and portability
+
+The open-source project does not impose one retention period on independently
+operated instances. Each operator must publish periods that are no longer than
+necessary for its purposes and legal duties.
+
+A deletion process should cover account and namespace records, package objects,
+reviews, reports, ratings, notifications, security findings, caches, audit records,
+logs, traces, exports, and backups. Where immediate backup deletion is not
+practical, deleted data should be isolated from normal use and expire under a
+documented schedule. Operators must also account for copies already disclosed to
+external providers or downloaded by authorized users.
+
+Operators should provide authenticated channels for access, correction, deletion,
+restriction, objection, and portability requests where applicable. Requests should
+be verified, recorded, completed within legally required time limits, and denied
+only on a documented basis.
+
+Skill packages can be downloaded as archives and installed through the CLI. Public
+APIs expose package and metadata workflows. Operators should separately document
+which instance records can be imported or exported, their non-proprietary formats,
+version compatibility, and any PII excluded from an export.
+
+## Security and incident handling
+
+Security vulnerabilities in the upstream project must be reported under the public
+[iFLYTEK organization security policy](https://github.com/iflytek/.github/blob/main/SECURITY.md)
+and its detailed
+[community security policy](https://github.com/iflytek/community/blob/master/SECURITY.md).
+Send vulnerability details privately to
+[security@iflytek.com](mailto:security@iflytek.com), not in a public issue.
+
+Instance operators remain responsible for monitoring their environments,
+maintaining an incident-response plan, preserving proportionate evidence, rotating
+affected credentials, applying fixes, and notifying users or authorities where
+required.
+
+## Project and instance contacts
+
+- Report an upstream security vulnerability privately to
+  [security@iflytek.com](mailto:security@iflytek.com).
+- Send questions about this project policy to
+  [ifly_opensource@iflytek.com](mailto:ifly_opensource@iflytek.com). Do not include
+  personal data or confidential incident details in a public GitHub issue.
+- Contact the operator named in an instance's privacy notice for data-subject
+  requests or incidents involving that instance.
+
+## Governance and changes
+
+Privacy-impacting changes should be reviewed for data minimization, access and
+namespace boundaries, package visibility, external disclosures, retention,
+logging, deletion, and portability. Material changes to this document are made
+through the repository's public review process, and the file history records them.