scriptoriumadmin/skillhub
1
0
Fork 0
mirror of https://github.com/iflytek/skillhub.git synced 2026-08-27 11:14:59 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

docs(governance): add DPGA policy evidence

Browse source 
Signed-off-by: FenjuFu <92919259+FenjuFu@users.noreply.github.com>
This commit is contained in:
FenjuFu 2026-08-18 17:57:20 +08:00
parent d2403bb591
commit 5b123e24c3
4 changed files with 432 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
CODE_OF_CONDUCT.md
View file

@ -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).

12
README.md
View file

@ -65,6 +65,18 @@ with the Skill's source and the problem it solves, or submit a PR by following t
- 📖 **[User Guide](https://iflytek.github.io/skillhub/)** — Skill publishing, search, CLI usage and other user guides
- 🛠️ **[Developer Docs](https://zread.ai/iflytek/skillhub)** — Architecture, API reference, local development, deployment and operations
## 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.

220
docs/CONTENT_SAFETY.md Normal file
View file

@ -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.

187
docs/PRIVACY_AND_DATA_GOVERNANCE.md Normal file
View file

@ -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.