Generates Daniel Jackson concept models (purpose, OP, state, actions, syncs) only when the user explicitly invokes $concept-design. / 仅在用户显式调用 $concept-design 时做概念建模。
SkillScore67Maintained
Automatic
◆Product Management pack
Last verified 10/10/2026
What it changes
Passed 16 of 24 test cases with the skill, and 7 of 24 without it.
Without skill29%
With skill67%
Checks it passed that the model alone missed
Refuse to output the complete PRD directly within the current turn.
Explicitly name concept-implementation as the missing authorized step.
Reject combining user verification and user ratings into a single concept.
and 11 more in the full report
10 fixed6 passed either way7 still failing1 broke
Pass-rate lift
+38 pp
Tokens
-1%
Agent turns
0%
Response time
-29%
Model gemini-3.6-flashMeasured 10/10/2026v316 of 24 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 10
Prompt
$concept-design Where should I look in the references to find definitions and local conventions used in concept design?
What was checked, without and with the skill
Checked
Without skill
With skill
Direct the user to consult references/sources.md for definitions and local conventions.
Missed
Passed
case-23 · gemini-3.6-flash · 10/10/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md69 lines7 files
Concept Design
Complete the concept design with the user: confirm the three alignment sections, then write the
design record. Run only on explicit $concept-design invocation. Continue into PRD or
implementation only when already authorized. If concept-prd or concept-implementation is
missing, deliver the model and name the missing step.
Design principles
Familiarity. Use a familiar concept, or a variant of one, when it meets the need.
Specificity. Each concept serves one purpose. Do not add a second concept for the same purpose.
Integrity. Synchronization may exclude some of a concept's behavior. It may not make the
concept do something its own specification disallows.
Two arguments. Contract → OP → concept purpose; concept selection and synchronizations →
application scenarios → application purpose. Local validity does not prove overall fitness. The
single-purpose criterion applies to concepts, not mechanically to applications.
Evidence. Source facts, and label inferences and open decisions. Absence of a counterexample
is not proof. Pages, entities, and code modules are only candidate clues.
Design process
Confirm each part with the user. Mark anything not yet confirmed as pending, and do not record it
as a confirmed fact.
Check facts — With the user, identify beneficiaries, application purpose, current state,
desired outcome, and constraints. In an existing system, trace actual entry points, state
ownership, failure paths, and tests. Separate current from desired behavior. If the purpose is
not yet stated, mark it open.
Propose the inventory — Write the concept inventory from references/artifacts.md and ask
which concepts to include. After confirmation, write state and actions from
references/spec-format.md. External identity is a type parameter with no assumed fields.
Review seams — Read references/criteria.md. Give all eight conclusions for each candidate.
Leave disputes for the user to decide.
Confirm scope, then compose — Ask the user to confirm dependencies and subsets using
references/sync-notation.md. Then write syncs from the specification contract, and check
under-synchronization, over-synchronization, the synchronization diagram, and the MVP.
Write the record — Correct an evidenced misfit using the qualification standard. Write
confirmed alignment into the design record. Keep pending items in exclusions and open decisions,
and block only the portion that depends on them.