_shared/term-detector

Detects new business terms and roles from specs and decisions for PRODUCT.md reconciliation.

4|Updated May 26, 2026
One-click install
npx skills add https://github.com/YYG501/PM-AI-Harness --skill shared-term-detector-yyg501
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: _shared/term-detector
Source: https://github.com/YYG501/PM-AI-Harness/tree/main/skills/_shared/term-detector
Command: npx skills add https://github.com/YYG501/PM-AI-Harness --skill shared-term-detector-yyg501

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After a module implementation lands, newly stabilized business terms and user roles often stay buried in module specs instead of being registered in the root PRODUCT.md, causing inconsistent naming across modules. This Skill reconciles those structured declarations against the existing product glossary so cross-module reuse stays consistent. ## Core Features & Use Cases - Structured Term Extraction: Reads only explicit declarations from spec.md glossary tables, user role tables, D-numbered decisions, and accepted_deltas affects entries—never guesses from prose, quotes, or code. - Whitelist and Skip Filtering: Applies a built-in whitelist of common tech and business words plus an optional .term-skip.json to suppress false positives. - Doc-Impact Integration: Emits pending kind=term items targeting PRODUCT.md through doc-impact.py, returning JSON with new_terms, new_roles, skipped, whitelisted, and registered lists. - Use Case: After a settlement module lands, the detector finds "结算批次" and "平台审核员" declared in the module spec but missing from PRODUCT.md, and queues them as documentation impact items for the compile step. ## Quick Start Run the term detector after a module lands to find any new business terms or roles that should be registered in PRODUCT.md.

Frequently Asked Questions about _shared/term-detector

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I keep a product glossary synchronized across module specs?

Run the term detector after each module implementation lands. It reads glossary and role tables from the affected spec.md files plus explicit term and role declarations in decisions, then reports only entries missing from the root PRODUCT.md as documentation impact items.

What sources does the term detector accept for new business terms?

It accepts the term column of glossary tables and role column of role tables in module specs, single-line term or role declarations in valid D-numbered decisions, and structured affects entries in accepted_deltas. It never scans quotes, bold text, prose, or code.

How do I prevent false positives in term detection?

The detector applies a built-in whitelist.json covering common tech and general business words, read from the PMAI installation directory. You can also add a .term-skip.json in the working directory to suppress project-specific terms.

When should the term detector not be used?

Do not run it during design exploration, since undecided wording must not be promoted to long-term terminology. It also never infers the product vocabulary from existing code and never creates a second glossary outside PRODUCT.md.

Can scoped-adjustment deltas introduce new roles or terms?

No. A scoped-adjustment can only add reconciliation signals for already approved term or role names. Introducing new product objects, role models, permissions, or rules must go back through the design step.