skillhone-prd

Name: skillhone-prd
Author: Tencent

58stars5forks

How to install skillhone-prd?

tencent/skillhone/skillhone-prd

$npx -y skills add Tencent/SkillHone --skill skillhone-prd

Installs into the current project.

Summary

Interactively gather a PRD (Product Requirements Document) for an agent skill that is about to be built or optimized by SkillHone. Use when the user says things like "I want to write a new skill", "help me spec this skill", "what should <x>-skill do", or before running `skillhone

Files · 1

View on GitHub

SKILL.md

1	# skillhone-prd — Interactive PRD builder for skills
2
3	## Why this skill exists
4
5	Before SkillHone can meaningfully optimize a skill, three things must be unambiguous: what the skill is trying to achieve (goal), what environment it runs in (tools), and how its outputs will be judged (evaluation — both the structural format and the scoring rubric). Writing ordinary product PRDs doesn't cut it — a skill PRD is primarily an evaluation contract, not a feature list.
6
7	This skill drives a multi-round interview via `AskUserQuestion` and emits three files into the paired `<skill>-eval` repo:
8
9	- `PRD.md` — full PRD, including evaluation criteria. Visible to the eval agent only.
10	- `PRD.improver_only.md` — same PRD with section 4 (Evaluation) stripped. Visible to the improver / iter agent.
11	- `PRD.choice.md` — full question/answer transcript. Eval artifact; never published to the skill wiki.
12
13	The split is deliberate: if the improver sees its own grading rubric, Goodhart's Law takes over within a few iterations.
14
15	## The three dimensions to pin down (in this order)
16
17	A skill PRD is structurally analogous to an RL problem spec:
18
19	\| RL concept \| Skill PRD dimension \| Why it comes when it does \|
20	\|---\|---\|---\|
21	\| Task goal \| Goal \| Without a goal, you can't pick what tools matter or what to measure. \|
22	\| Environment \| Environment (tools, runtime) \| Tools = the action space; sets the ceiling on what's testable. \|
23	\| Reward \| Evaluation (incl. output format) \| Reward is meaningful only relative to a fixed goal and environment. \|
24
25	> Output format is part of evaluation, not separate from it. Format validity is the structural reward gate; metrics and thresholds are the content reward. They're rendered as two sections (3 and 4) so that the improver-only file can keep the format spec visible while redacting the scoring rubric.
26
27	PRD section order in `PRD.md` is fixed: `## 1. Environment` → `## 2. Goal` → `## 3. Output format` → `## 4. Evaluation`. The interview order is independent — the script reorders for you.
28
29	If the user pushes to jump ahead ("let's talk metrics first"), briefly redirect: "reward depends on what the agent can actually do — let's pin down the goal and the tools first, or we'll just be optimizing a metric that doesn't correspond to the task."
30
31	## Interaction contract — use `AskUserQuestion`, always
32
33	Drive every round through the `AskUserQuestion` tool. Do not paste numbered lists into your text reply — the tool gives the user a real picker UI and structured answers come back to you, which removes parsing ambiguity.
34
35	Language: match the language of the user's most recent message for all user-facing text (questions, options, your prose). Keep file names, the four dimension keys (`environment`, `goal`, `output_format`, `evaluation`), and the generated-PRD headings in English — the script depends on them.
36
37	### Hard rules for questions
38
39	- 2–4 options per question (tool-enforced). Prefer 3.
40	- `header` ≤ 12 chars. Crisp nouns: `Tools`, `Goal`, `Format`, `Metric`.
41	- `label` = what the user picks; `description` = why. Both required.
42	- `multiSelect: true` only when more than one option can legitimately apply.
43	- One question = one decision. No double-barreled questions.
44	- Options must be MECE, distinct, and actionable. No vague adjectives ("fast", "good"), no "recommended"/"best" labels unless the user used those words.
45	- No fake options. If you can't name 2 grounded alternatives, ask an upstream context question first.
46	- Batch aggressively within a round. Round 1 should cover all four dimensions where questions don't depend on each other.
47	- Each later round depends on the prior round's answers. Don't pre-compute the full tree.
48	- Always accept free-text. The UI supplies it automatically — treat it as more authoritative than your offered options.
49
50	For the full catalogue of worked examples, anti-patterns, and dimension-by-dimension question templates, see [references/question_playbook.md](references/question_playbook.md). Load that file if yo

People who liked this also viewed

6 picks

Type

skillhone-prd

58stars5forks

View on GitHub

How to install skillhone-prd?

tencent/skillhone/skillhone-prd

$npx -y skills add Tencent/SkillHone --skill skillhone-prd

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# skillhone-prd — Interactive PRD builder for skills
2
3	## Why this skill exists
4
5	Before SkillHone can meaningfully optimize a skill, three things must be unambiguous: what the skill is trying to achieve (goal), what environment it runs in (tools), and how its outputs will be judged (evaluation — both the structural format and the scoring rubric). Writing ordinary product PRDs doesn't cut it — a skill PRD is primarily an evaluation contract, not a feature list.
6
7	This skill drives a multi-round interview via `AskUserQuestion` and emits three files into the paired `<skill>-eval` repo:
8
9	- `PRD.md` — full PRD, including evaluation criteria. Visible to the eval agent only.
10	- `PRD.improver_only.md` — same PRD with section 4 (Evaluation) stripped. Visible to the improver / iter agent.
11	- `PRD.choice.md` — full question/answer transcript. Eval artifact; never published to the skill wiki.
12
13	The split is deliberate: if the improver sees its own grading rubric, Goodhart's Law takes over within a few iterations.
14
15	## The three dimensions to pin down (in this order)
16
17	A skill PRD is structurally analogous to an RL problem spec:
18
19	\| RL concept \| Skill PRD dimension \| Why it comes when it does \|
20	\|---\|---\|---\|
21	\| Task goal \| Goal \| Without a goal, you can't pick what tools matter or what to measure. \|
22	\| Environment \| Environment (tools, runtime) \| Tools = the action space; sets the ceiling on what's testable. \|
23	\| Reward \| Evaluation (incl. output format) \| Reward is meaningful only relative to a fixed goal and environment. \|
24
25	> Output format is part of evaluation, not separate from it. Format validity is the structural reward gate; metrics and thresholds are the content reward. They're rendered as two sections (3 and 4) so that the improver-only file can keep the format spec visible while redacting the scoring rubric.
26
27	PRD section order in `PRD.md` is fixed: `## 1. Environment` → `## 2. Goal` → `## 3. Output format` → `## 4. Evaluation`. The interview order is independent — the script reorders for you.
28
29	If the user pushes to jump ahead ("let's talk metrics first"), briefly redirect: "reward depends on what the agent can actually do — let's pin down the goal and the tools first, or we'll just be optimizing a metric that doesn't correspond to the task."
30
31	## Interaction contract — use `AskUserQuestion`, always
32
33	Drive every round through the `AskUserQuestion` tool. Do not paste numbered lists into your text reply — the tool gives the user a real picker UI and structured answers come back to you, which removes parsing ambiguity.
34
35	Language: match the language of the user's most recent message for all user-facing text (questions, options, your prose). Keep file names, the four dimension keys (`environment`, `goal`, `output_format`, `evaluation`), and the generated-PRD headings in English — the script depends on them.
36
37	### Hard rules for questions
38
39	- 2–4 options per question (tool-enforced). Prefer 3.
40	- `header` ≤ 12 chars. Crisp nouns: `Tools`, `Goal`, `Format`, `Metric`.
41	- `label` = what the user picks; `description` = why. Both required.
42	- `multiSelect: true` only when more than one option can legitimately apply.
43	- One question = one decision. No double-barreled questions.
44	- Options must be MECE, distinct, and actionable. No vague adjectives ("fast", "good"), no "recommended"/"best" labels unless the user used those words.
45	- No fake options. If you can't name 2 grounded alternatives, ask an upstream context question first.
46	- Batch aggressively within a round. Round 1 should cover all four dimensions where questions don't depend on each other.
47	- Each later round depends on the prior round's answers. Don't pre-compute the full tree.
48	- Always accept free-text. The UI supplies it automatically — treat it as more authoritative than your offered options.
49
50	For the full catalogue of worked examples, anti-patterns, and dimension-by-dimension question templates, see [references/question_playbook.md](references/question_playbook.md). Load that file if yo

People who liked this also viewed

6 picks

Type