Pr SubmissionSAFE
Self-hosted, open-source agent skill registry for enterprises. Publish & version skill packages, govern with RBAC and audit logs, deploy on-premise with Docker or Kubernetes.
Overview
Self-hosted, open-source agent skill registry for enterprises. Publish & version skill packages, govern with RBAC and audit logs, deploy on-premise with Docker or Kubernetes.
e94027cda310OBSERVED · 2026-10-11Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| openclaw | mentioned |
What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
--- name: pr-submission description: PR title format, commit conventions, and pre-PR checklist for SkillHub. Use when preparing or reviewing pull requests. license: Apache-2.0 --- # PR Submission Skill ## Workflow 1. Identify the scope of your change (feature, bug fix, docs, test, refactor, chore) 2. Format PR title and commits using the conventions below 3. Run the pre-PR checklist commands 4. Open the PR with a descriptive body ## PR Title Format Use conventional commit style: ``` <type>(<scope>): <description> ``` **Types:** | Type | When to Use | |------|-------------| | `feat` | New feature or capability | | `fix` | Bug fix | | `docs` | Documentation changes only | | `test` | Adding or updating tests | | `refactor` | Code restructuring with no behavior change | | `chore` | Build, CI, tooling, or maintenance tasks | **Scopes:** Use module or domain names: `auth`, `search`, `publish`, `review`, `namespace`, `governance`, `deploy`, `ci`, `frontend`, `scanner` **Examples:** ``` feat(auth): add local account login with password reset fix(publish): resolve null pointer when skill metadata is missing name docs(deploy): clarify runtime image usage test(namespace): add membership service edge case tests refactor(review): extract query repository for governance list chore(ci): add parallel workflow scripts for multi-agent development ``` ## Commit Message Format Same convention as PR titles. One logical change per commit. **Types:** - **feat**: A new feature for the user - **fix**: A bug fix for the user - **docs**: Documentation changes only - **test**: Adding or updating tests - **refactor**: Code change that neither fixes a bug nor adds a feature - **chore**: Changes to build process, CI, or maintenance tasks **Examples:** ``` fix(auth): resolve session cookie conflict in device flow feat(publish): support security scan before review submission docs(skill-protocol): add nested SKILL.md discovery rules test(search): verify jieba analysis with Chinese skill descriptions refactor(storage): simplify LocalFile path normalization ``` ## Pre-PR Checklist - [ ] Backend tests pass: `make test-backend-app` - [ ] Frontend typecheck passes: `make typecheck-web` - [ ] If API changed: `make generate-api` was run and `web/src/api/generated/schema.d.ts` is committed - [ ] Smoke test passes: `make staging` - [ ] Follow existing module boundaries and dependency direction - [ ] Add/update tests for new behavior - [ ] Update design docs when APIs, auth flows, deployment, or operator workflows change ## PR Body Structure When creating a PR, include: 1. **What** — Summary of the change 2. **Why** — Motivation (link to issue if applicable) 3. **How** — Key implementation details (especially for non-obvious decisions) 4. **Testing** — How to verify the change works 5. **Impact** — Breaking changes, migration notes, or rollout considerations ## Review Conventions - When reviewing, cite the specific AGENTS.md rule that applies if suggesting a convention change - For backend code, check dependency direction does not violate clean architecture rules - For frontend code, check OpenAPI types are regenerated if API changed
Trust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
e94027cda310full audit observations/trust-audit/skill/iflytek__pr-submission.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-11 | e94027cda310 | SAFE | B | 89 | first audit |
Questions
What does the Pr Submission skill do?
Self-hosted, open-source agent skill registry for enterprises. Publish & version skill packages, govern with RBAC and audit logs, deploy on-premise with Docker or Kubernetes.
Is Pr Submission safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Pr Submission access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
Which assistants does Pr Submission work with?
Its documentation mentions openclaw. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (e94027cda310), read on 2026-10-11. The repository is watched, and a new audit runs when it changes — this is the first audit.