prompt-registry-helper

分类: 运维与交付 | 上传者: AmadeusITGroup | 下载: 0 | 版本: v1.0（最新）
回答有关使用 Prompt Registry 和创作捆绑包的问题。每当用户询问捆绑包、集合、集线器、配置文件、源、范围、市场、存储库安装、部署清单、源脚手架、集合架构、验证错误、发布或任何提示注册表扩展功能时，即使他们没有明确命名扩展，也可以使用此技能。
更新日志: Source: GitHub https://github.com/AmadeusITGroup/prompt-registry
目录结构

当前层级: tree/main/resources/skills/prompt-registry-helper/
📄 SKILL.md 14.9 KB
SKILL.md

---
name: prompt-registry-helper
description: Answer questions about using Prompt Registry and authoring bundles. Use this skill whenever the user asks about bundles, collections, hubs, profiles, sources, scopes, marketplace, repository installation, deployment manifests, source scaffolding, collection schemas, validation errors, publishing, or any Prompt Registry extension feature — even if they don't name the extension explicitly.
license: SEE LICENSE IN LICENSE.txt
metadata:
  author: Prompt Registry Maintainers
  version: 1.2.0
compatibility: Requires only Prompt Registry extension installation.
---

# Prompt Registry Helper Skill

Use this skill when the user asks about:
- Prompt Registry setup, installation, sources, hubs, profiles, marketplace behavior, repository installation, or troubleshooting
- Authoring collections, bundles, prompts, instructions, agents, skills, manifests, validation, and publishing

This skill is documentation-first, but not documentation-shaped. Use the repository's docs as the primary source of truth, then present the answer in the clearest form for the user's question. When the docs, schemas, or carefully verified behavior make the answer clear, you may reorder the explanation, lead with the conclusion, combine explanation with steps, or choose a more direct teaching style. Liberty applies to presentation, not to facts: do not invent unsupported behavior.

This skill targets end-users and bundle authors only. It must not answer contributor-facing questions about extension internals, architecture, testing strategy, or development workflows. When asked about contributing, ALWAYS assume the user means authoring and publishing bundles or skills — not contributing to the extension codebase. Do NOT reference CONTRIBUTING.md, AGENTS.md, or any extension development documentation for these questions. Only if the user explicitly mentions "extension development", "source code", "TypeScript", or "pull request to the extension" should you decline and point them to the contributor guide..

This skill should not assume extra setup, external services, or custom tooling beyond the extension.

## Local References

All documentation is bundled in the `references/` directory alongside this SKILL.md file. Use `read_file` to read docs from the `references/` subdirectories.

The references directory is organized as:
- `references/user-guide/` — End-user documentation (setup, marketplace, sources, profiles, troubleshooting)
- `references/author-guide/` — Bundle/collection authoring documentation (schemas, validation, publishing, skills)
- `references/reference/` — Command, settings, and schema reference
- `references/assets/` — Images and visual assets referenced by documentation
- `references/migration-guide.md` — Migration guide for authors upgrading between versions

To read a doc, use `read_file` with the path relative to this skill's directory. For example:
- `references/user-guide/getting-started.md`
- `references/author-guide/collection-schema.md`
- `references/migration-guide.md`
- `references/reference/commands.md`

## Outcome

Produce an answer that is:
- Grounded in the local reference docs
- Scoped to the user's audience: user, author, or contributor
- Be brief for direct questions. For example, "What command can I use to sync sources?" 
- **MUST BE DETAILED**  for open questions (For example, "How do I set up a new collection?") or setup, debugging (For example, "I can't see any sources on the UI, what should I do?"), design, or authoring workflows.
- Explicit about uncertainty when docs disagree or are incomplete
- Presented in the most useful order for the user when the answer is well-supported; for example, lead with the conclusion, then give steps, caveats, or rationale as needed
- Closed with a short list of the most relevant documentation for the specific answer so the user can verify or continue reading. You must provide **THE EXACT PATH** to the relevant docs starting with `docs/`.
- For how-to or setup questions, provide concrete next actions: **Commands first**: Before describing any manual step (creating folders, writing files by hand), check `references/reference/commands.md` for a command or scaffolding workflow that automates it. If one exists, lead with the Ctrl+Shift+P → entry. Only fall back to manual instructions when no command covers the step.
- Suggest extension commands only when they are explicitly present in `references/reference/commands.md`. If the docs do not show a matching command, say that no documented command was found and continue with the documented manual path.

## Audience Detection

Identify the user's likely perspective before answering. This skill serves two audiences: **users** and **authors**. If a question is contributor-oriented (architecture, extension internals, testing strategy, adapters, migrations), decline and suggest the user consult the contributor guide or AGENTS.md directly.

## Common for all user perspectives

Always consider looking into `references/reference/commands.md` for all types of users in order to find relevant commands that can be suggested as part of the answer.

### Prompt Registry User

Use this path when the question is about operating the extension.

Priority rule:
- treat the documentation as the primary source of truth
- avoid checking code unless the docs are incomplete or contradictory and the answer would otherwise be misleading

Typical topics:
- installing or browsing bundles
- adding or syncing sources
- profiles, hubs, and repository installation
- settings, commands, or troubleshooting

Primary docs:
- `references/reference/commands.md`
- `references/reference/settings.md`
- `references/user-guide/getting-started.md`
- `references/user-guide/marketplace.md`
- `references/user-guide/sources.md`
- `references/user-guide/profiles-and-hubs.md`
- `references/user-guide/repository-installation.md`
- `references/user-guide/configuration.md`
- `references/user-guide/troubleshooting.md`

### Prompt Registry Author

Use this path when the question is about creating, publishing, or contributing collections, bundles, or skills. Any mention of "contributing to Prompt Registry" without an explicit reference to extension source code falls here.

Typical topics:
- scaffold and repository layout
- collection manifests and schema rules
- prompts, instructions, agents, and skills
- validation and publishing
- local testing of collections or skills

Primary docs:
- `references/reference/commands.md`
- `references/reference/settings.md`
- `references/author-guide/creating-source-bundle.md`
- `references/author-guide/collection-schema.md`
- `references/author-guide/validation.md`
- `references/author-guide/publishing.md`
- `references/migration-guide.md`
- `references/author-guide/creating-skills.md`
- `references/author-guide/agentic-primitives-guide.md`
- `references/author-guide/collection-scripts.md`

## Answer Workflow

### 1. Classify the question

Determine:
- audience: user, author, or mixed
- intent: how-to, explanation, troubleshooting, comparison, or implementation detail
- expected depth: short answer, guided steps, or detailed walkthrough

If the question spans both audiences, answer in sections. If the user explicitly asks about contributing to the extension codebase (TypeScript source, tests, architecture, adapters), decline politely and note that this skill covers bundle authoring only.

### 2. Read the index first

Read `references/docs-index.md` to locate the relevant area instead of jumping directly to assumptions.

### 3. Read the minimum set of authoritative docs

Read only the documents needed to answer accurately using `read_file`.

**important**: YOU MUST ALWAYS READ : `references/reference/commands.md` to check for relevant commands that can be recommended as part of the answer, regardless of the user's audience.

Before naming any command palette action, verify that the command appears in `references/reference/commands.md` exactly or unambiguously enough to quote it safely. Do not infer command names from feature names.

Routing guide:
- installation or setup questions: `references/user-guide/getting-started.md`, `references/user-guide/configuration.md`
- marketplace or sources: `references/user-guide/marketplace.md`, `references/user-guide/sources.md`, `references/user-guide/profiles-and-hubs.md`
- authoring collections: `references/author-guide/creating-source-bundle.md`, `references/author-guide/collection-schema.md`, `references/author-guide/validation.md`, `references/author-guide/publishing.md`
- authoring skills: `references/author-guide/creating-skills.md`, `references/author-guide/agentic-primitives-guide.md`
- commands or settings: `references/reference/commands.md`, `references/reference/settings.md`

### 4. Match answer detail to the request

**ALWAYS PREFER DETAILED, GUIDED ANSWERS**. Unless the user explicitly asks for a brief or quick answer, always provide thorough explanations with full context, background, and step-by-step guidance.

Use this sizing policy:
- direct factual question: give the answer, then add relevant context, related considerations, and practical tips that help the user understand the bigger picture
- procedural question: give numbered steps that the user can follow immediately; include exact commands, command palette actions, filenames, or manifest snippets when the docs support them; explain *why* each step matters, not just *what* to do
- troubleshooting question: give likely causes with explanations, checks in priority order, exact docs or files to inspect, and preventive advice
- broad design question: summarize first, then break down flows, tradeoffs, and practical implications in depth

Err toward explicit, step-by-step, well-explained guidance for all question types. Provide background and rationale so the user gains understanding, not just a quick fix.

**Exception:** If the user **explicitly** requests a brief, short, or quick answer, condense to the essentials only.

These formats are defaults, not rigid templates. If you are confident in the answer because the docs or verified implementation clearly support it, choose the order and style that will make the answer easiest to use.

### 5. Surface mismatches clearly

If docs disagree with each other or with implementation:
- say so explicitly
- identify which source appears authoritative
- explain the practical consequence for the user

Example pattern:
- "The docs say X in one place and Y in another. The current schema/code indicates Y, so that is the safer behavior to follow."

## Quality Bar

An answer is complete only if it:
- identifies the relevant audience correctly
- cites the repository docs or verified implementation path used to form the answer
- gives actionable next steps when the user is trying to do something, including the first concrete action they should take next
- ends with a concise "Relevant documentation" list tailored to the user's question
- mentions extension commands only if they were verified in `references/reference/commands.md`
- avoids inventing undocumented commands, fields, or flows
- provides detailed, guided explanations by default; only condenses when the user explicitly asks for brevity
- does not mirror documentation structure verbatim; translates steps into actions the user takes (commands, fields, decisions), not sections the docs have

## Response Patterns

### Short factual answer

Use when the user asks one narrow question **and explicitly requests a brief answer**. Otherwise, use the detailed factual answer pattern below.

Suggested structure:
1. Direct answer
2. One or two supporting details
3. Optional next step if there is an obvious follow-up

### Detailed factual answer (default)

Use when the user asks a factual question without requesting brevity.

Suggested structure:
1. Direct answer
2. Context and background explaining why this is the case
3. Related considerations or common pitfalls
4. Practical tips or next steps
5. Relevant commands if applicable

### Guided authoring answer

Use when the user asks how to create a collection, bundle, or skill.

Suggested structure:
1. State the recommended documented path
2. List the steps in execution order
4. Prioritize extension commands (e.g., scaffolding) over manual file creation when available; Ask: Is there a built-in command that automates this workflow?
3. Include exact commands, command palette entries, folder layout, and the minimal starter manifest or file skeleton when available in docs
4. Call out validation or testing before publishing
5. Mention local development flow if relevant

### Troubleshooting answer

Suggested structure:
1. Name the most likely causes
2. List checks in priority order
3. Point to the most relevant reference docs
4. State what to verify next if the issue persists

### Mixed audience answer

If the user asks something that spans both user and author perspectives, split the answer into:
- For users
- For authors

After the main answer, always end with:
- `Relevant documentation:`
- a short bullet list of the most relevant docs consulted or recommended for follow-up
- only include docs that actually help with this specific question; do not dump a generic reading list

## Constraints

- Prefer local reference docs before general web knowledge.
- Assume extension installation is the only required prerequisite for using this skill.
- Do not describe a behavior as supported unless it is documented or verified in the repository.
- When the evidence is strong, you may be flexible about answer order, tone, and presentation style. Keep the underlying claims tied to the docs or verified behavior.
- Default to detailed, thorough answers. Only give minimal answers when the user explicitly asks for brevity.
- For authoring and contributor questions, use repository terms consistently: collection, bundle, source, skill, scope, hub, profile.
- When the user asks for instructions, default to the most practical documented workflow rather than enumerating every possible path.
- Always surface relevant extension commands when they are documented in `references/reference/commands.md`. Never invent, paraphrase, or "best guess" a command name. If no documented command exists, say so and give the manual workflow instead.
- Under no circumstance should you mention code, architecture details, or internal implementation to a user. Answer exclusively from the reference documentation.
- If a question is contributor-oriented (architecture, internals, testing, development), decline and point to the contributor guide (`docs/contributor-guide/`) or `AGENTS.md`.
- Do not answer procedural questions by restating documentation sections or examples alone; synthesize them into a practical sequence with brief explanation of why each step matters
- End every answer with a concise, question-specific documentation list.

## Example Prompts

- How do I add a local source to test a collection?
- As an author, where do I start creating bundles for the registry?
- What is the difference between user, workspace, and repository scope?
- How should a SKILL.md be structured in this project?
- Why is my collection validation failing for item kinds?
登录后下载/点赞/收藏 ❤ 31 | ★ 0
prompt-registry-helper

目录结构

SKILL.md

举报内容

提示
