design-information-prep

Name: design-information-prep
Author: SeanJ1ang

218stars11forks

How to install design-information-prep?

seanj1ang/design-judge-skills/design-information-prep

$npx -y skills add SeanJ1ang/design-judge-skills --skill design-information-prep

Installs into the current project.

Summary

Extract evidence-grounded project facts from user-provided design attachments, identify missing information, and prepare the exact written fields required by supported design-award entry forms. Use when a user asks to prepare, draft, adapt, translate, or validate application text

Files · 1

View on GitHub

SKILL.md

1	# Design Information Prep
2
3	## Purpose
4
5	Turn user-authorized attachments into a reusable, evidence-linked project dossier, then compile that dossier into the exact text fields required by one supported award route. Generate no project fact from past-winner copy or unsupported inference.
6
7	## Runtime Boundary
8
9	- Treat user attachments and explicit user confirmations as the only sources of project facts.
10	- Read local award field specifications for field names, limits, routing, and drafting instructions.
11	- Do not connect to Supabase, read `.env`, query winner databases, or place full winner descriptions in model context.
12	- Use optional aggregate benchmark profiles only for coverage prompts such as what evidence to look for. Never use them as project facts, prose templates, hidden judging preferences, or winning probabilities.
13	- Verify current official rules at request time. Stored specifications record a checked date, not permanent truth.
14
15	## Input Contract
16
17	Accept PDFs, presentations, documents, spreadsheets, images, videos, structured JSON, or plain text. Determine or request:
18
19	- exact award, cycle, route, and language;
20	- applicant type and project maturity when they affect routing;
21	- all user-authorized project materials;
22	- confidentiality or publication restrictions;
23	- whether the user wants a dossier, missing-information audit, draft fields, translation, or final text validation.
24
25	If the award or route is unknown, use `$design-award-match` first. If the user only wants final file and portal compliance, use `$design-submission-check` after drafting.
26
27	## Workflow
28
29	### 1. Lock the target
30
31	Read the selected file under `references/awards/`. Record the exact award id, cycle, route, stage, language, official sources, and checked date. Verify any current cycle rule that could have changed, including requiredness, limits, language, conditional fields, and publication behavior.
32
33	Do not silently merge professional, student, product, and concept routes.
34
35	### 2. Build the project dossier
36
37	Read [references/evidence-policy.md](references/evidence-policy.md) and [references/project-dossier-schema.json](references/project-dossier-schema.json). Extract canonical facts into `facts` records containing:
38
39	- value;
40	- status: `supported`, `inferred`, `confirmed_by_user`, or `missing`;
41	- confidence;
42	- attachment evidence and locator;
43	- whether user confirmation is required.
44
45	Preserve contradictions as separate findings. Do not choose a convenient value without reporting the conflict. Mark unavailable facts `missing`; never fill them from general knowledge or a past winner.
46
47	### 3. Prepare an award-specific evidence packet
48
49	Save the dossier as structured JSON and run:
50
51	```powershell
52	python scripts/prepare_entry_packet.py `
53	--dossier examples/project-dossier.example.json `
54	--award idea `
55	--route general `
56	--pretty
57	```
58
59	The packet identifies ready fields, missing essential facts, available evidence, limits, and drafting instructions. Ask only the questions that block required fields. Continue with partial output when the user prefers, labeling every unresolved field.
60
61	### 4. Draft field by field
62
63	Use only facts listed in each field's prepared evidence packet. Follow the official field purpose rather than forcing one generic description into every form.
64
65	- Lead with the answer, not promotional framing.
66	- Prefer specific mechanisms and outcomes over unverified superlatives.
67	- Distinguish measured outcomes from intended benefits.
68	- Preserve units, denominators, dates, maturity, and uncertainty.
69	- Do not convert an inference into a confirmed claim through fluent wording.
70	- Count words and characters according to the field specification.
71	- Keep translations semantically aligned; do not introduce new claims in one language.
72
73	Prepare machine-checkable output using [references/entry-output-schema.json](references/entry-output-schema.json). Include `used_fact_ids` for every drafted field.
74
75	### 5. Validate the draft
76
77	Run:
78
79	```powershell
80	python scripts/validate_entry_output.py `
81	--dossier examples/project-dossier.example.json `
82	--entry examples/idea-entry-output.example.json `
83	--pretty
84	```
85
86	Resolve every Blocker before presenting a field as submission-ready. Treat unsupported or inferred claims awaiting co

People who liked this also viewed

6 picks

Type

design-information-prep

218stars11forks

View on GitHub

How to install design-information-prep?

seanj1ang/design-judge-skills/design-information-prep

$npx -y skills add SeanJ1ang/design-judge-skills --skill design-information-prep

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Design Information Prep
2
3	## Purpose
4
5	Turn user-authorized attachments into a reusable, evidence-linked project dossier, then compile that dossier into the exact text fields required by one supported award route. Generate no project fact from past-winner copy or unsupported inference.
6
7	## Runtime Boundary
8
9	- Treat user attachments and explicit user confirmations as the only sources of project facts.
10	- Read local award field specifications for field names, limits, routing, and drafting instructions.
11	- Do not connect to Supabase, read `.env`, query winner databases, or place full winner descriptions in model context.
12	- Use optional aggregate benchmark profiles only for coverage prompts such as what evidence to look for. Never use them as project facts, prose templates, hidden judging preferences, or winning probabilities.
13	- Verify current official rules at request time. Stored specifications record a checked date, not permanent truth.
14
15	## Input Contract
16
17	Accept PDFs, presentations, documents, spreadsheets, images, videos, structured JSON, or plain text. Determine or request:
18
19	- exact award, cycle, route, and language;
20	- applicant type and project maturity when they affect routing;
21	- all user-authorized project materials;
22	- confidentiality or publication restrictions;
23	- whether the user wants a dossier, missing-information audit, draft fields, translation, or final text validation.
24
25	If the award or route is unknown, use `$design-award-match` first. If the user only wants final file and portal compliance, use `$design-submission-check` after drafting.
26
27	## Workflow
28
29	### 1. Lock the target
30
31	Read the selected file under `references/awards/`. Record the exact award id, cycle, route, stage, language, official sources, and checked date. Verify any current cycle rule that could have changed, including requiredness, limits, language, conditional fields, and publication behavior.
32
33	Do not silently merge professional, student, product, and concept routes.
34
35	### 2. Build the project dossier
36
37	Read [references/evidence-policy.md](references/evidence-policy.md) and [references/project-dossier-schema.json](references/project-dossier-schema.json). Extract canonical facts into `facts` records containing:
38
39	- value;
40	- status: `supported`, `inferred`, `confirmed_by_user`, or `missing`;
41	- confidence;
42	- attachment evidence and locator;
43	- whether user confirmation is required.
44
45	Preserve contradictions as separate findings. Do not choose a convenient value without reporting the conflict. Mark unavailable facts `missing`; never fill them from general knowledge or a past winner.
46
47	### 3. Prepare an award-specific evidence packet
48
49	Save the dossier as structured JSON and run:
50
51	```powershell
52	python scripts/prepare_entry_packet.py `
53	--dossier examples/project-dossier.example.json `
54	--award idea `
55	--route general `
56	--pretty
57	```
58
59	The packet identifies ready fields, missing essential facts, available evidence, limits, and drafting instructions. Ask only the questions that block required fields. Continue with partial output when the user prefers, labeling every unresolved field.
60
61	### 4. Draft field by field
62
63	Use only facts listed in each field's prepared evidence packet. Follow the official field purpose rather than forcing one generic description into every form.
64
65	- Lead with the answer, not promotional framing.
66	- Prefer specific mechanisms and outcomes over unverified superlatives.
67	- Distinguish measured outcomes from intended benefits.
68	- Preserve units, denominators, dates, maturity, and uncertainty.
69	- Do not convert an inference into a confirmed claim through fluent wording.
70	- Count words and characters according to the field specification.
71	- Keep translations semantically aligned; do not introduce new claims in one language.
72
73	Prepare machine-checkable output using [references/entry-output-schema.json](references/entry-output-schema.json). Include `used_fact_ids` for every drafted field.
74
75	### 5. Validate the draft
76
77	Run:
78
79	```powershell
80	python scripts/validate_entry_output.py `
81	--dossier examples/project-dossier.example.json `
82	--entry examples/idea-entry-output.example.json `
83	--pretty
84	```
85
86	Resolve every Blocker before presenting a field as submission-ready. Treat unsupported or inferred claims awaiting co

People who liked this also viewed

6 picks

Type