Procurement Admission Copilot

SKILL商业运营
商业运营 未标注权限 许可证不明确
安装这个技能

采购准入影子助手

一句话选型结论

按资料字段整理

Procurement Admission Copilot是商业运营类的 Agent Skill,安装方式未标注,权限级别未标注,许可证不明确,有可直接复制的安装命令。技能本质是给模型读的说明书,效果取决于模型与客户端;装完先用一个小任务验证,再放进正式流程。

分类商业运营 安装方式未标注 权限级别未标注权限 许可证许可证不明确
累计安装 未标注 本周 未标注
GitHub 星标 未标注 仓库 未标注
下载量 未标注 技能市场下载数
权限级别 未标注权限 安装前请确认风险范围
许可证 许可证不明确 未说明

安装

未标注
在支持 Skills 的客户端里执行,装完问一句「你有哪些技能」验证
skillhub install user_7fbe8d41/procurement-admission-copilot-skill
  1. 1
    确认客户端支持

    确认你的客户端支持 Skills(Claude、Codex、Cursor 等),并升级到较新的版本。

  2. 2
    拿到技能文件

    执行上面的命令安装;也可以把仓库里的 SKILL.md 手动放进客户端的 skills 目录。

  3. 3
    刷新技能列表

    重新打开客户端,或刷新技能列表,让新放进来的技能被加载。

  4. 4
    验证是否生效

    问一句「你有哪些技能」,确认列表里出现它,再拿一个小任务试跑。

技能档案

商业运营
字段来自技能仓库与公开索引,中文说明由本站标注
作者 / 维护方user_7fbe8d41仓库 未标注 · 版本 未标注
宿主客户端未标注技能可被这些客户端加载
安装方式未标注安装包 community
权限级别未标注权限安装前请确认风险范围
许可证未说明许可证不明确,商用前请自行确认条款
仓库可用性available技能仓库当前是否可访问
最近核验未标注上游最后核验时间 · 数据更新 1791624763
正文体量11.7 KBSKILL.md 原文大小,越大说明说明书写得越细

典型使用场景

3 类
按分类整理的常见用法,具体以 SKILL.md 为准
写运营方案

按目标产出活动方案与执行清单。

分析数据与指标

从报表里找问题、给结论。

整理客户与销售材料

把客户信息与话术整理成可直接用的材料。

选择建议

装之前先看这几条
按条目字段给出的判断,不替你决定用不用

值得选的地方

  • 有可直接复制的安装命令,不用自己翻文档找入口。

先想清楚的地方

  • 没有标注权限级别,实际能做什么要装好后确认。
  • 许可证不明确,商用或二次分发前先到仓库确认条款。
  • 没有做站内核验,内容以作者仓库为准。
  • 技能只是说明书,实际效果取决于模型与客户端,装完先用小任务试一遍。

更适合

  • 需要在商业运营场景里给模型补一套做法的人。
  • 愿意先读一遍 SKILL.md、确认它会让模型做什么的人。

不太适合

  • 对许可证要求很严、必须明确可商用的人。
  • 只想装完就自动变强、不打算看说明书的人。

同类对比

6 个同类
同分类里挑最接近的几条,字段以各自详情页为准
技能权限级别安装方式累计安装宿主客户端安装命令
Procurement Admission Copilot当前 未标注权限 未标注 未标注 未标注 有
MX 股票筛选器 联网访问 ClawHub 市场 79.9 万 OpenClaw 有
交易 未标注权限 ClawHub 市场 58.1 万 OpenClaw 有
营销技巧 只读 ClawHub 市场 54.0 万 OpenClaw 有
百灵鸟好 联网访问 GitHub 仓库 52.6 万 Codex、Claude、Cursor 有
股票信息浏览器 接触敏感数据 ClawHub 市场 40.5 万 OpenClaw 有

SKILL.md 全文

11.7 KB
模型实际读到的说明书原文,来自技能仓库

Procurement Admission Copilot

A shadow-mode, review-only copilot for the two repeatable, high-friction parts of B2B supplier / vendor procurement admission:

  1. Supplier material package readiness — given a supplier's scattered qualification inputs (business license, certificates, product catalog, case studies, financials summary, compliance docs), check that the package is complete and internally consistent before it is submitted for admission review.
  2. Approval case management — given a set of admission approval cases (each a supplier's request with submitted materials, reviewer, stage, due date, and decision), track status, stalls, and gaps so a human reviewer can act.

It structures and flags. It does not draft contract clauses and does not make the admission / sourcing decision. Responsibility stays with the procurement committee or buyer.

When to use

  • A supplier is preparing the document package for procurement admission / vendor onboarding and you want a readiness pass before submission.
  • You receive a supplier's materials and need to know, fast, whether company identity, certificates, and figures are consistent across documents.
  • You manage a queue of admission approval cases and need a status dashboard: what is stalled, what is blocked by missing documents, what needs a decision.
  • You want a reviewable, one-pass readiness or case report to hand to a human reviewer or committee.

Do not use

  • Drafting contract terms, pricing clauses, or the legal/sourcing conclusion of admission → out of scope by design ("不碰合同结论").
  • A single-document fact-check of an article or report → use claim-to-source-auditor.
  • Negotiation or scorecard weighting of suppliers → this skill tracks and flags, it does not rank or decide.
  • Directly modifying supplier documents.

Input

mode: material_package | approval_cases
# Mode A — material_package
supplier_inputs:        # folder or list of files
  - path:
    label: 营业执照 | 资质证书 | 产品册 | 案例 | 财报摘要 | 合规材料
checklist:              # optional industry qualification list
  - item:
    mandatory: true
reference_source:       # doc authoritative for company identity (default: 营业执照)
# Mode B — approval_cases
cases:                  # CSV / JSON / folder of case files
  - supplier:
    submitted_materials:
    reviewer:
    stage:
    due_date:
    decision:           # pending | approved | rejected | needs-info
    notes:
review_only: true       # never rewrite; output structured findings

Workflow

Mode A — Material Package Readiness (供应商材料包)

Step 1: [Deterministic] Load + extract structured fields

For each supplied document, extract:

  • Company legal name as written in that document (capture per-doc wording — differences are the signal).
  • Unified Social Credit Code (USCC) if present.
  • Certificate names with issue / expiry dates.
  • Revenue / scale figures and their stated source.
  • Product / service categories and declared scope.
  • Contact and registration details.

Record the extraction into a material manifest (the deterministic script consumes this).

Step 2: [Deterministic] Run the readiness check

Run scripts/check_material_package.py on the manifest. It performs:

  • Identity consistency: compare legal names across documents after normalization; flag any divergence as a potential P0.
  • USCC presence: flag missing USCC when mandatory.
  • Certificate validity: expired mandatory cert → P0; expiry within 90 days → P1.
  • Required-document completeness: any missing mandatory document → P0.
  • Financial consistency: when two revenue figures differ beyond a tolerance band, flag P1 (inconsistency to reconcile).

Output 01-readiness-check.json.

Step 3: [LLM] Consistency & quality review

Explain and extend the deterministic findings, and add judgments the script cannot:

  • Name mismatch across documents (营业执照 vs 产品册 vs 案例).
  • Expired or near-expiry certificates.
  • Revenue inconsistency between financials, tax summary, and case-study scale.
  • Weak or boilerplate case studies (no measurable outcome).
  • Missing recommended (non-mandatory) qualification (ISO / industry cert / security clearance).
  • Declared scope vs product categories mismatch.

Severity:

  • P0: identity conflict (same supplier under different legal names / USCC); expired mandatory certificate; missing mandatory document; required USCC absent.
  • P1: near-expiry certificate; revenue inconsistency; weak case study; missing recommended qualification.
  • P2: cosmetic / formatting issues that do not affect admission readiness.

Step 4: [LLM] Produce the structured package + readiness report

Render a standardized supplier material package (from templates/supplier-material-package.md) and a readiness report (from templates/readiness-report.template.md) with the P0/P1/P2 list and recommended actions. Recommended fixes must cite an existing supplied document — never invent.

Step 5: [Deterministic] Human confirmation

Pause. Confirm P0/P1 disposition. The human (or the supplier's BD) revises the package. This skill is review-only.

Mode B — Approval Case Management (审批案件管理)

Step 1: [Deterministic] Load + normalize

Read the cases (CSV / JSON / folder). Normalize each to the case schema: supplier, submitted materials, reviewer, stage, due date, decision, notes. Output 01-cases-normalized.json.

Step 2: [LLM] Status analysis

  • Stalled: past due with no decision → P0 if a compliance deadline is at risk, else P1.
  • Inconsistent decisions: same supplier approved by one reviewer and rejected by another without rationale → P0.
  • Doc-gap blocked: decision pending because a mandatory document is missing → P1.
  • Reviewer bottleneck: one reviewer holds an outsized share of open cases → P1.
  • Labeling / format drift: P2.

Step 3: [LLM] Produce the case dashboard

Render a status dashboard (from templates/case-dashboard.template.md): status distribution, risk-flag list, pending-decision list, and recommended actions for human reviewers. The dashboard surfaces what a human needs to decide; it does not decide.

Step 4: [Deterministic] Human confirmation

Pause. A human reviewer acts on the flagged cases. This skill never emits the approval/rejection decision.

Hard Rules

  1. Review-only. Never modify supplier documents or case files. Output structured findings; hands-off after delivery.
  2. No contract conclusions. Never draft contract clauses, pricing, or the admission/sourcing decision. Structure and flag; the human decides.
  3. Identity is anchored to the official registration. The business license / official registration is authoritative for legal name and USCC; every other document must agree with it.
  4. P0 blocks readiness / decision-readiness. A package with a P0 is not admission-ready; a case with a P0 needs human attention before any decision.
  5. No fabricated content. Recommended fixes must reference an existing supplied document.
  6. Deterministic checks are the baseline. scripts/check_material_package.py owns the numbers; the LLM layer explains and extends, never overrides a deterministic result.

Failure Handling

Scenario Action
No supplier inputs provided (Mode A) Stop; at least one document is required
Document unreadable / non-text Mark it and check only the readable ones
Manifest missing required fields Ask for the missing field; do not guess identity
All checks pass Report "package ready" / "no case risk found"
P0 found in an already-submitted package Flag with extra severity; recommend resubmission
Cases provided without due dates Compute stall only where dates exist; note coverage gap

Output Format

<run-dir>/
├── (Mode A) 01-readiness-check.json   # deterministic script output
├── (Mode A) 02-material-package.md    # structured supplier package
├── (Mode A) 03-readiness-report.md    # P0/P1/P2 + actions
├── (Mode B) 01-cases-normalized.json
└── (Mode B) 02-case-dashboard.md

Verification

  • [ ] Every supplied document's legal name compared for identity consistency.
  • [ ] Certificate expiry checked against a reference date; P0/P1 assigned correctly.
  • [ ] Required-document completeness checked against the checklist.
  • [ ] Financial inconsistencies flagged when figure divergence exceeds tolerance.
  • [ ] No contract clause or admission decision appears in any output.
  • [ ] Human confirmation documented before the task is marked complete.

Pitfalls

  • Treating a near-expiry certificate as fine — 90 days is the warning line, not a pass.
  • Reconciling revenue by picking the "nicer" number — flag the divergence, let the supplier explain.
  • Letting the dashboard imply a decision ("approve supplier X") — it surfaces, it does not decide.
  • Assuming the product catalog's scope equals the declared business scope — mismatch is a real admission risk.
  • Running Mode A on a single document and calling it "ready" — completeness needs the whole set.

中文摘要(Chinese Summary)

本 Skill 是采购准入的影子助手,只覆盖两个高重复、高摩擦的环节,且不碰合同结论:

  • 供应商材料包就绪度审查:给定供应商散落的资质材料(营业执照、资质证书、产品册、案例、财报摘要、合规材料),在提交准入评审前检查材料包是否完整、内部一致。
  • 审批案件管理:给定一批准入审批案件(每家供应商的请求 + 提交材料 + 评审人 + 阶段 + 截止日 + 结论),跟踪状态、卡点、缺口,供评审人行动。

关键约束(双语要点 / Bilingual key points):

  • 只审阅不决策 Review-only, no decision:绝不撰写合同条款,绝不下准入/采购结论;只结构化、标记,责任留在采购委员会/采购方。
  • 身份锚定官方登记 Identity anchored to registration:营业执照/官方登记的名称与统一社会信用代码为权威;其他材料必须与之对齐。
  • P0 阻断就绪 P0 blocks readiness:材料包有 P0 即未就绪;案件有 P0 须人工介入方可决策。
  • 确定件检查是基线 Deterministic baseline:scripts/check_material_package.py 负责数字与一致性,LLM 层只解释与扩展,不推翻确定件结论。
  • 不编造 No fabrication:修复建议必须引用已提交材料,不得凭空生成。

何时用(场景引导 / When to reach for it): 供应商准备准入/入库材料包、想提交前过一遍就绪度;你收到供应商材料想快速判断名称/证书/数字是否跨文档一致;你管一批准入审批案件想要状态看板(卡在哪、缺什么、谁该决策);想给评审人/委员会一份可一键审阅的报告。它专门抓"名字对不上、证书快过期、数字前后矛盾、案件超时无结论"这类问题。

常见问题

5 问
答案由本站依据条目字段整理
Procurement Admission Copilot怎么安装?

在支持 Skills 的客户端里执行:skillhub install user_7fbe8d41/procurement-admission-copilot-skill。安装方式为未标注。装完刷新技能列表或重开客户端。

Procurement Admission Copilot支持哪些客户端?

资料没有标注宿主客户端,但只要客户端支持 Skills(Claude、Codex、Cursor 等),一般都能加载。

Procurement Admission Copilot权限高吗,安全吗?

权限级别为未标注权限。安装前先看它会读取或写入哪些内容。

Procurement Admission Copilot收费吗?

本站不代收费用,也没有标注具体价格。是否收费取决于技能本身和所用的模型或客户端,正式使用前按作者说明确认。

Procurement Admission Copilot用什么许可证?

许可证标注为 未说明(许可证不明确)。商用或二次分发前请到仓库确认条款原文。

热门专题

按场景挑技能
全部专题 →

技能内容以作者仓库为准;分类、权限级别与许可证状态的中文说明为中文整理,最近核验 未标注。