Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add TashanGKD/tashan-cursor-skills --skill product-launch-validatorgit clone --depth 1 https://github.com/TashanGKD/tashan-cursor-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/tashangkd/tashan-cursor-skills/product-launch-validator)<a href="https://agentmods.dev/skills/tashangkd/tashan-cursor-skills/product-launch-validator"><img src="https://agentmods.dev/badge/skills/tashangkd/tashan-cursor-skills/product-launch-validator/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/tashangkd/tashan-cursor-skills/product-launch-validator"><img src="https://agentmods.dev/badge/skills/tashangkd/tashan-cursor-skills/product-launch-validator.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00136 | $0.01850 |
| Opus 5 | $0.00068 | $0.00925 |
| Sonnet 5 | $0.00027 | $0.00370 |
| Haiku 4.5 | $0.00014 | $0.00185 |
Grade A, and why
product-launch-validator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 134 lines — stays where its author put it; the contents beside it link to each section on GitHub.
新产品三大闭环兼容性验证(product-launch-validator)
关系类型:validates → 三大闭环架构蓝图(在立项时验证 Loop 1/2/3 的兼容性) 触发时机:role-产品经理 激活之前(可选但推荐) 设计依据:三大闭环架构蓝图 §差距清单「新产品/场景加入时兼容性检查:❌缺失」
使用场景
何时触发:
- 启动一个全新的产品项目(而非现有产品的迭代)
- 在现有生态中添加新的独立场景或子系统
- 不确定「这个新产品和我们现有的 Skill 体系/认知结构/部署架构是否兼容」
不应触发:
- 现有产品的功能迭代(走 role-产品经理 迭代模式即可)
- 纯 Skill 或 Rule 的新建(走 skill-designer)
激活后立即执行
Step 1 收集新产品基本信息
询问用户(如果上下文不明确):
「请描述新产品的:
1. 核心功能一句话描述
2. 主要用户群体
3. 依赖的技术栈(前端框架/后端语言/AI能力)
4. 与现有产品的关系(完全独立/共享账号/共享数据库)」
确认后继续。
Step 2 Loop 1 检查:Skill 体系兼容性
Read: .cursor/skills/skill-index/SKILL-INDEX.md(快速扫描,了解已有能力覆盖)
检查三项:
① 新产品的开发流程(PM→架构→前后端→测试→部署)是否有现有 Skill 完整覆盖?
→ 对每个阶段:现有 Skill 是否支持新产品的特殊需求(如新技术栈/新部署模式)
② 新产品涉及的领域(如:学术画像/科研工具/AI编辑器),是否有对应的域节点
在 DOMAIN-REGISTRY 中已定义?
→ 若无 → 标记「需要在 DOMAIN-REGISTRY 新增工作域」
③ 新产品是否引入了新的技术边界(如:新AI模型/新第三方服务/新部署架构)
需要新建 Skill 或 Rule 才能安全执行?
Step 3 Loop 2 检查:认知根对齐
Read: _内部总控/认知结构/L0_大脑总地图.md
Read: _内部总控/认知结构/L1.5_底层原则层/底层原则库.md(候选原则部分)
检查两项:
① 新产品的核心价值主张,在现有 L1 系统性文档中是否有对应的认知根?
→ 具体:L1 的哪篇文档支撑了「为什么要做这个产品」的判断?
→ 若无 → 标记「产品认知根缺失:建议先用 cognitive-capture-fragment
记录洞见,再用 cognitive-update-knowledge 补充 L1」
② 新产品的设计假设,是否与已确认的 L1.5 原则(P1/P2/...)兼容?
→ 扫描候选原则,识别可能与新产品设计有张力的原则
Step 4 Loop 3 检查:场景投射兼容性
Read: _内部总控/skill-system-design/DOMAIN-REGISTRY.md(快速了解已有工作域)
Read: _内部总控/开发规范/AI调用服务器助手接口规范.md(如有,了解技术约束)
检查两项:
① 新产品的工作域(工作任务/工作产物/项目结构)是否已在 DOMAIN-REGISTRY 的
五域定义之内?
→ 若无 → 标记「需要在 DOMAIN-REGISTRY 中新增节点」并给出建议定义
② 新产品的技术架构(账号体系/数据库/部署位置)是否与现有服务兼容?
→ 特别检查:是否重用现有账号体系?是否加入 tashan-shared 网络?
Step 5 输出兼容性报告
「━━ 立项兼容性检查报告 ━━
新产品:[名称]
Loop 1 Skill 体系:
✅ 已覆盖:[列举]
⚠️ 需补充:[列举缺口 + 建议行动]
Loop 2 认知根:
✅ 有认知根:[L1 文档名]
⚠️ 认知根缺失:[建议:先记录 L2 碎片或更新 L1]
Loop 3 工作域:
✅ 现有域覆盖:[域名]
⚠️ 需要新增域节点:[建议定义]
技术兼容性:[兼容 / 需要新建 Rule:前端品牌守门/API兼容检查/...]
─────────────────────────────
综合判断:
✅ 完全兼容 → 可直接触发 role-产品经理
⚠️ 有缺口但可并行补齐 → 建议按「建议行动」顺序处理后再启动开发
❌ 结构性不兼容 → 必须先解决阻塞项才能立项
[立即触发 role-产品经理] [先处理缺口]」
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 134 lines · 136 tokens per session scan A 74bf1936cfc3
product-launch-validator is a skill published in the GitHub repository TashanGKD/tashan-cursor-skills (20 stars, last pushed 5mo ago), licensed MIT. It adds 136 tokens to every session and 1,850 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
team
Coordinate parallel work across multiple Cursor sessions via shared .omc/team/ state.
template-helpers
Catalog of the reusable building blocks shipped with this Android template — BaseActivity/BaseFragment, the helpers/ extension files (navigation, lifecycle, toast, snackbar, dialogs, images, permissions, theme, locale, settings intents, date, delay), common/ (Firebase, network, observers), and…
android-feature
Workflow for implementing a new Android feature, screen, fragment, activity, dialog, adapter, or enhancement in this XML/MVVM template. Use whenever the user asks to add, build, implement, or extend functionality — before writing any code. Covers planning, the MVVM/MVI skeleton, the Android configuration checklist…
android-new-project
Workflow for turning a fresh copy of this Android template into a new app — renaming the package/namespace/applicationId, branding (icons, splash, palette, fonts), Firebase setup, signing config, stripping unused sample screens, and verifying the foundation. Use when the user says they are starting a new app…
android-preflight
Final verification checklist to run before declaring Android work finished — build, both themes, string resources, lifecycle and leak risks, registered permissions and components, resource parity between values and values-night, and honest reporting of what was and was not verified. Use at the end of any feature, fix…
android-upgrade
Workflow for changing an existing working Android project — upgrading dependencies, AGP/Gradle or SDK levels, migrating deprecated APIs, refactoring, and fixing bugs, without breaking what already works. Covers baseline verification, scoping the diff, targetSdk behaviour changes, SharedPreferences/Room data…