Initial commit
This commit is contained in:
Z User
783
skills/docx/scenes/academic.md
Executable file
783
skills/docx/scenes/academic.md
Executable file
@@ -0,0 +1,783 @@
|
||||
# Scene: Academic / Thesis
|
||||
|
||||
## Palette
|
||||
|
||||
**Academic Dark** (Cool + Heavy + Calm) — Academic papers use **pure black body text**. Palette only for cover decoration and minimal title scenarios.
|
||||
|
||||
```js
|
||||
const palette = {
|
||||
primary: "#000000", // Title — pure black
|
||||
body: "#000000", // Body — pure black
|
||||
secondary: "#333333", // Header/caption — dark grey
|
||||
accent: "#8B7E5A", // Cover decoration line — cover only
|
||||
surface: "#F5F7FA", // Table header light bg — three-line tables only
|
||||
};
|
||||
```
|
||||
|
||||
⚠️ **Body text color must be pure black `"000000"`**. No decorative dark-blue-grey. Academic papers require print-friendly, black-and-white clarity.
|
||||
|
||||
→ Placeholder convention & universal prohibitions — see `references/common-rules.md`
|
||||
→ **Note:** This scene uses Profile A fonts with academic-specific overrides below.
|
||||
|
||||
---
|
||||
|
||||
## Page Layout
|
||||
|
||||
| Property | Value | Twips |
|
||||
|----------|-------|-------|
|
||||
| Top margin | 2.54 cm | 1440 |
|
||||
| Bottom margin | 2.54 cm | 1440 |
|
||||
| Left margin | 3.00 cm | 1701 |
|
||||
| Right margin | 2.50 cm | 1417 |
|
||||
| Header distance | 1.5 cm | 850 |
|
||||
| Footer distance | 1.75 cm | 992 |
|
||||
|
||||
```js
|
||||
page: {
|
||||
size: { width: 11906, height: 16838 },
|
||||
margin: { top: 1440, bottom: 1440, left: 1701, right: 1417, header: 850, footer: 992 },
|
||||
}
|
||||
```
|
||||
|
||||
For binding margin, add 0.5–1.0 cm to left (i.e., left: 1985–2268).
|
||||
|
||||
---
|
||||
|
||||
## Font Specifications
|
||||
|
||||
| Element | CN Font | EN Font | Size | half-pt | Style |
|
||||
|---------|---------|---------|------|---------|-------|
|
||||
| Thesis title | SimHei | Times New Roman | Xiao Er 18pt | 36 | Bold, centered |
|
||||
| H1 | SimHei | Times New Roman | San Hao 16pt | 32 | Bold, centered |
|
||||
| H2 | SimHei | Times New Roman | Xiao San 15pt | 30 | Bold, left |
|
||||
| H3 | SimHei | Times New Roman | Si Hao 14pt | 28 | Bold, left |
|
||||
| Body | SimSun | Times New Roman | Xiao Si 12pt | 24 | Normal, justified |
|
||||
| Abstract title | SimHei | Times New Roman Bold | San Hao 16pt | 32 | Bold, centered |
|
||||
| Abstract body | SimSun | Times New Roman | Xiao Si 12pt | 24 | Normal, justified |
|
||||
| Keywords label | SimHei | Times New Roman Bold | Xiao Si 12pt | 24 | Bold |
|
||||
| Keywords content | SimSun | Times New Roman | Xiao Si 12pt | 24 | Normal |
|
||||
| Header | SimSun | Times New Roman | Xiao Wu 9pt | 18 | Centered, color 333333 |
|
||||
| Page number | — | Times New Roman | Xiao Wu 10.5pt | 21 | Centered |
|
||||
| Footnote | SimSun | Times New Roman | Xiao Wu 9pt | 18 | Normal |
|
||||
| Figure/table caption | SimSun | Times New Roman | Wu Hao 10.5pt | 21 | Centered |
|
||||
|
||||
### Paragraph Format
|
||||
- Body: justified, first-line indent 2 chars (`firstLine: 480`, SimSun Xiao Si = 480 twips)
|
||||
- Line spacing: 1.5x (`line: 360`); if school requires fixed 22pt, use `line: 440, lineRule: "exact"`
|
||||
- Body paragraph spacing: before/after 0pt; heading spacing per styles below
|
||||
|
||||
```js
|
||||
styles: {
|
||||
default: {
|
||||
document: {
|
||||
run: { font: { ascii: "Times New Roman", eastAsia: "SimSun" }, size: 24, color: "000000" },
|
||||
paragraph: { spacing: { line: 360 } },
|
||||
},
|
||||
heading1: {
|
||||
run: { font: { ascii: "Times New Roman", eastAsia: "SimHei" }, size: 32, bold: true, color: "000000" },
|
||||
paragraph: { alignment: AlignmentType.CENTER, spacing: { before: 480, after: 360, line: 360 } },
|
||||
},
|
||||
heading2: {
|
||||
run: { font: { ascii: "Times New Roman", eastAsia: "SimHei" }, size: 30, bold: true, color: "000000" },
|
||||
paragraph: { spacing: { before: 360, after: 240, line: 360 } },
|
||||
},
|
||||
heading3: {
|
||||
run: { font: { ascii: "Times New Roman", eastAsia: "SimHei" }, size: 28, bold: true, color: "000000" },
|
||||
paragraph: { spacing: { before: 240, after: 120, line: 360 } },
|
||||
},
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Heading Numbering System (Mandatory)
|
||||
|
||||
### Format
|
||||
|
||||
| Level | Format | Example |
|
||||
|-------|--------|---------|
|
||||
| H1 | Chapter X + title | 第一章 绪论 (Chapter 1 Introduction) |
|
||||
| H2 | X.X + section title | 1.1 Research Background |
|
||||
| H3 | X.X.X + subsection | 1.1.1 Domestic Research Status |
|
||||
|
||||
### Mandatory Rules
|
||||
1. **H1 must use "第X章" format** — not "一、", not "Chapter 1", not "第1章"
|
||||
2. **H2/H3 use Arabic decimal numbering** (1.1, 1.1.1) — no "(一)", "1)"
|
||||
3. **No mixing multiple numbering systems**
|
||||
4. **No level-skipping** (cannot jump from H1 to H3)
|
||||
5. **All body headings must use `heading: HeadingLevel.HEADING_X`** (TOC depends on this)
|
||||
|
||||
```js
|
||||
// ✅ Correct
|
||||
new Paragraph({
|
||||
heading: HeadingLevel.HEADING_1,
|
||||
children: [new TextRun({ text: "第一章 绪论", bold: true, size: 32, font: { eastAsia: "SimHei", ascii: "Times New Roman" } })]
|
||||
})
|
||||
new Paragraph({
|
||||
heading: HeadingLevel.HEADING_2,
|
||||
children: [new TextRun({ text: "1.1 研究背景", bold: true, size: 30, font: { eastAsia: "SimHei", ascii: "Times New Roman" } })]
|
||||
})
|
||||
```
|
||||
|
||||
### Non-Body Headings
|
||||
Abstract, Table of Contents, References, Appendices, Acknowledgments:
|
||||
- Use H1 style (San Hao SimHei centered) for TOC indexing
|
||||
- But **no numbering** (write directly: "摘 要", "参考文献", etc. — these are non-numbered standalone section headings)
|
||||
|
||||
---
|
||||
|
||||
## Document Structure & Multi-Section Architecture
|
||||
|
||||
Theses must use **multi-section structure** for independent page numbering and header/footer per section.
|
||||
|
||||
### Complete Structure
|
||||
|
||||
```
|
||||
Section 1: Cover → No page number, no header/footer
|
||||
Section 2: Chinese Abstract → Roman numerals starting from i
|
||||
Section 3: English Abstract → Roman numerals continued
|
||||
Section 4: Table of Contents → Roman numerals continued
|
||||
Section 5: Body (all chapters) → Arabic numerals from 1
|
||||
Section 6: References → Arabic numerals continued
|
||||
Section 7: Appendices (if any) → Arabic numerals continued
|
||||
Section 8: Acknowledgments (if any) → Arabic numerals continued
|
||||
```
|
||||
|
||||
### Page Number Implementation
|
||||
|
||||
```js
|
||||
const { NumberFormat } = require("docx");
|
||||
|
||||
// Section 1: Cover — no page number
|
||||
{
|
||||
properties: {
|
||||
page: { margin: { top: 0, bottom: 0, left: 0, right: 0 } },
|
||||
titlePage: true,
|
||||
},
|
||||
children: buildCover(...),
|
||||
}
|
||||
|
||||
// Section 2: Abstract — Roman numerals from i
|
||||
{
|
||||
properties: {
|
||||
type: SectionType.NEXT_PAGE,
|
||||
page: {
|
||||
margin: { top: 1440, bottom: 1440, left: 1701, right: 1417, header: 850, footer: 992 },
|
||||
pageNumbers: { start: 1, formatType: NumberFormat.UPPER_ROMAN },
|
||||
},
|
||||
},
|
||||
headers: { default: buildHeader("Thesis Title") },
|
||||
footers: { default: buildPageNumberFooter() },
|
||||
children: buildAbstractCN(...),
|
||||
}
|
||||
|
||||
// Section 3: English Abstract — Roman numerals continued (no reset)
|
||||
{
|
||||
properties: {
|
||||
type: SectionType.NEXT_PAGE,
|
||||
page: {
|
||||
margin: { top: 1440, bottom: 1440, left: 1701, right: 1417, header: 850, footer: 992 },
|
||||
pageNumbers: { formatType: NumberFormat.UPPER_ROMAN }, // no start → continues from previous
|
||||
},
|
||||
},
|
||||
headers: { default: buildHeader("Thesis Title") },
|
||||
footers: { default: buildPageNumberFooter() },
|
||||
children: buildAbstractEN(...),
|
||||
}
|
||||
|
||||
// Section 5: Body — Arabic numerals from 1
|
||||
{
|
||||
properties: {
|
||||
type: SectionType.NEXT_PAGE,
|
||||
page: {
|
||||
margin: { top: 1440, bottom: 1440, left: 1701, right: 1417, header: 850, footer: 992 },
|
||||
pageNumbers: { start: 1, formatType: NumberFormat.DECIMAL },
|
||||
},
|
||||
},
|
||||
headers: { default: buildHeader("Thesis Title") },
|
||||
footers: { default: buildPageNumberFooter() },
|
||||
children: buildMainContent(...),
|
||||
}
|
||||
// Section 6+: References/Appendices/Acknowledgments — Arabic continued
|
||||
```
|
||||
|
||||
### Header & Footer Helpers
|
||||
|
||||
```js
|
||||
function buildHeader(title) {
|
||||
return new Header({ children: [
|
||||
new Paragraph({ alignment: AlignmentType.CENTER,
|
||||
border: { bottom: { style: BorderStyle.SINGLE, size: 1, color: "000000" } },
|
||||
children: [new TextRun({ text: title, size: 18, color: "333333",
|
||||
font: { ascii: "Times New Roman", eastAsia: "SimSun" } })],
|
||||
}),
|
||||
] });
|
||||
}
|
||||
|
||||
function buildPageNumberFooter() {
|
||||
return new Footer({ children: [
|
||||
new Paragraph({ alignment: AlignmentType.CENTER,
|
||||
children: [
|
||||
new TextRun({ text: "- ", size: 21 }),
|
||||
new TextRun({ children: [PageNumber.CURRENT], size: 21 }),
|
||||
new TextRun({ text: " -", size: 21 }),
|
||||
],
|
||||
}),
|
||||
] });
|
||||
}
|
||||
```
|
||||
|
||||
### Page Break Rules
|
||||
- Cover is a separate section (no PageBreak needed)
|
||||
- Chinese abstract, English abstract, TOC each in their own section
|
||||
- All body chapters in **one section** (no forced page breaks between chapters unless user requests)
|
||||
- References, appendices, acknowledgments each in their own section
|
||||
- **Never use blank lines instead of section breaks**
|
||||
|
||||
---
|
||||
|
||||
## Cover
|
||||
|
||||
### Information Fields
|
||||
|
||||
Cover must include (use placeholders for missing info):
|
||||
|
||||
| Field | Format | Placeholder |
|
||||
|-------|--------|-------------|
|
||||
| University name | Er Hao SimHei, centered | ×××University |
|
||||
| Thesis title (CN) | Xiao Er SimHei, centered | (user-provided) |
|
||||
| Thesis title (EN) | San Hao Times New Roman, centered | (translated from CN) |
|
||||
| College | Si Hao SimSun | ×××College |
|
||||
| Major | Si Hao SimSun | ×××Major |
|
||||
| Author | Si Hao SimSun | ××× |
|
||||
| Student ID | Si Hao SimSun | ××××××× |
|
||||
| Advisor | Si Hao SimSun | ×××Professor |
|
||||
| Date | Si Hao SimSun | 2026/XX |
|
||||
|
||||
### Cover Style
|
||||
|
||||
Use Recipe R5 (Clean White) or academic-specific `buildAcademicCover()` — never use commercial-style covers.
|
||||
|
||||
### Cover Layout Order (Mandatory)
|
||||
|
||||
The visual order on academic covers must follow this hierarchy from top to bottom:
|
||||
|
||||
1. School name (top)
|
||||
2. Document type label (e.g., "Undergraduate Thesis", "Thesis Proposal Report")
|
||||
3. **Thesis title** (prominent, centered)
|
||||
4. Thesis English title (if bilingual)
|
||||
5. **Author information table** (college, major, author, student ID, advisor)
|
||||
6. Date (bottom)
|
||||
|
||||
⚠️ **Title MUST appear ABOVE the author info table.** The screenshot issue of info table appearing above the title is caused by incorrect element ordering. The `buildAcademicCover()` and `buildProposalCover()` functions below enforce correct order.
|
||||
|
||||
⚠️ **Layout must be vertically balanced** — use dynamic spacing to distribute whitespace evenly. Do not cram all elements into the top half or let large gaps appear between elements.
|
||||
|
||||
```js
|
||||
function buildAcademicCover(info) {
|
||||
const { school, title, titleEN, college, major, author, studentId, advisor, date } = info;
|
||||
|
||||
// ⚠️ Use safeText() for all values — never output "undefined"
|
||||
const infoRows = [
|
||||
["College", safeText(college, "【College】")],
|
||||
["Major", safeText(major, "【Major】")],
|
||||
["Author", safeText(author, "【Author】")],
|
||||
["Student ID", safeText(studentId, "【Student ID】")],
|
||||
["Advisor", safeText(advisor, "【Advisor】")],
|
||||
];
|
||||
|
||||
const infoTable = new Table({
|
||||
width: { size: 60, type: WidthType.PERCENTAGE },
|
||||
alignment: AlignmentType.CENTER,
|
||||
borders: { top: NB, bottom: NB, left: NB, right: NB, insideHorizontal: NB, insideVertical: NB },
|
||||
rows: infoRows.map(([label, value]) => new TableRow({
|
||||
cantSplit: true,
|
||||
children: [
|
||||
new TableCell({
|
||||
width: { size: 35, type: WidthType.PERCENTAGE },
|
||||
borders: { bottom: { style: BorderStyle.SINGLE, size: 1, color: "000000" }, top: NB, left: NB, right: NB },
|
||||
margins: { top: 60, bottom: 60, left: 120, right: 120 },
|
||||
children: [new Paragraph({
|
||||
alignment: AlignmentType.RIGHT,
|
||||
children: [new TextRun({ text: label + ":", size: 28, font: { eastAsia: "SimHei", ascii: "Times New Roman" } })],
|
||||
})],
|
||||
}),
|
||||
new TableCell({
|
||||
borders: { bottom: { style: BorderStyle.SINGLE, size: 1, color: "000000" }, top: NB, left: NB, right: NB },
|
||||
margins: { top: 60, bottom: 60, left: 120, right: 120 },
|
||||
children: [new Paragraph({
|
||||
alignment: AlignmentType.CENTER,
|
||||
children: [new TextRun({ text: value, size: 28, font: { eastAsia: "SimSun", ascii: "Times New Roman" } })],
|
||||
})],
|
||||
}),
|
||||
],
|
||||
})),
|
||||
});
|
||||
|
||||
// ⚠️ Correct order: school → doc type → TITLE → info table → date
|
||||
// ★ Rule 8: All large-font paragraphs must set explicit line spacing
|
||||
return [
|
||||
new Paragraph({ alignment: AlignmentType.CENTER, spacing: { before: 1200, after: 400, line: Math.ceil(22 * 23), lineRule: "atLeast" },
|
||||
children: [new TextRun({ text: safeText(school, "【University Name】"), size: 44, bold: true, font: { eastAsia: "SimHei" } })] }),
|
||||
new Paragraph({ alignment: AlignmentType.CENTER, spacing: { after: 800, line: Math.ceil(18 * 23), lineRule: "atLeast" },
|
||||
children: [new TextRun({ text: "Undergraduate Thesis", size: 36, font: { eastAsia: "SimHei" } })] }),
|
||||
new Paragraph({ alignment: AlignmentType.CENTER, spacing: { after: 200, line: Math.ceil(18 * 23), lineRule: "atLeast" },
|
||||
children: [new TextRun({ text: safeText(title, "【Thesis Title】"), size: 36, bold: true, font: { eastAsia: "SimHei", ascii: "Times New Roman" } })] }),
|
||||
titleEN ? new Paragraph({ alignment: AlignmentType.CENTER, spacing: { after: 1200, line: Math.ceil(16 * 23), lineRule: "atLeast" },
|
||||
children: [new TextRun({ text: titleEN, size: 32, font: { ascii: "Times New Roman" } })] })
|
||||
: new Paragraph({ spacing: { after: 1200 }, children: [] }),
|
||||
infoTable,
|
||||
new Paragraph({ alignment: AlignmentType.CENTER, spacing: { before: 1200, line: Math.ceil(14 * 23), lineRule: "atLeast" },
|
||||
children: [new TextRun({ text: safeText(date, "2026/XX"), size: 28, font: { eastAsia: "SimSun" } })] }),
|
||||
];
|
||||
}
|
||||
```
|
||||
|
||||
### Thesis Proposal Report Cover (开题报告)
|
||||
|
||||
Thesis proposal reports use a similar cover layout but with different document type label. The key layout rule is the same: **title above author info, evenly spaced**.
|
||||
|
||||
⚠️ **CRITICAL — Proposal cover MUST be an independent section:**
|
||||
The proposal cover MUST be placed in its **own section** (with margin: 0 and a 16838 wrapper table), completely separate from the body content. The body content starts in the **next section** (with `SectionType.NEXT_PAGE` or as a separate section entry). **Never place the cover elements and body content in the same section** — this causes them to render on the same page without any page break, which is the #1 proposal report formatting failure.
|
||||
|
||||
```js
|
||||
// ✅ Correct — cover and body in separate sections
|
||||
sections: [
|
||||
{
|
||||
properties: { page: { margin: { top: 0, bottom: 0, left: 0, right: 0 } } },
|
||||
children: buildProposalCover(info), // standalone cover section
|
||||
},
|
||||
{
|
||||
properties: { page: { margin: { top: 1440, bottom: 1440, left: 1701, right: 1417 } } },
|
||||
children: [...bodyContent], // body starts here
|
||||
},
|
||||
]
|
||||
|
||||
// ❌ WRONG — cover and body in same section (no page separation!)
|
||||
sections: [
|
||||
{
|
||||
children: [...coverElements, ...bodyContent], // everything on one continuous flow
|
||||
},
|
||||
]
|
||||
```
|
||||
|
||||
```js
|
||||
function buildProposalCover(info) {
|
||||
const { school, year, title, subtitle, college, major, author, studentId, advisor, date } = info;
|
||||
|
||||
// ⚠️ Use safeText() for all values
|
||||
const infoRows = [
|
||||
["姓名 (Name)", safeText(author, "XXX")],
|
||||
["专业 (Major)", safeText(major, "XXX")],
|
||||
["入学时间 (Enrollment)", safeText(info.enrollment, "XXX")],
|
||||
];
|
||||
|
||||
const infoTable = new Table({
|
||||
width: { size: 60, type: WidthType.PERCENTAGE },
|
||||
alignment: AlignmentType.CENTER,
|
||||
borders: { top: NB, bottom: NB, left: NB, right: NB, insideHorizontal: NB, insideVertical: NB },
|
||||
rows: infoRows.map(([label, value]) => new TableRow({
|
||||
children: [
|
||||
new TableCell({
|
||||
width: { size: 35, type: WidthType.PERCENTAGE },
|
||||
borders: { bottom: { style: BorderStyle.SINGLE, size: 1, color: "000000" }, top: NB, left: NB, right: NB },
|
||||
margins: { top: 60, bottom: 60, left: 120, right: 120 },
|
||||
children: [new Paragraph({
|
||||
alignment: AlignmentType.CENTER,
|
||||
children: [new TextRun({ text: label, size: 28, bold: true, font: { eastAsia: "SimHei", ascii: "Times New Roman" } })],
|
||||
})],
|
||||
}),
|
||||
new TableCell({
|
||||
borders: { bottom: { style: BorderStyle.SINGLE, size: 1, color: "000000" }, top: NB, left: NB, right: NB },
|
||||
margins: { top: 60, bottom: 60, left: 120, right: 120 },
|
||||
children: [new Paragraph({
|
||||
alignment: AlignmentType.CENTER,
|
||||
children: [new TextRun({ text: value, size: 28, font: { eastAsia: "SimSun", ascii: "Times New Roman" } })],
|
||||
})],
|
||||
}),
|
||||
],
|
||||
})),
|
||||
});
|
||||
|
||||
// ⚠️ Correct order: doc type label → info table → "论文题目" label → TITLE → subtitle
|
||||
// Layout balanced: upper 40% for header + info, middle 20% for title, lower 40% for whitespace
|
||||
// ★ Rule 8: All large-font paragraphs must set explicit line spacing
|
||||
return [
|
||||
new Paragraph({ alignment: AlignmentType.CENTER, spacing: { before: 1500, after: 600, line: Math.ceil(18 * 23), lineRule: "atLeast" },
|
||||
children: [new TextRun({ text: safeText(year, "2025") + " 届本科毕业论文开题报告",
|
||||
size: 36, bold: true, font: { eastAsia: "SimHei", ascii: "Times New Roman" } })] }),
|
||||
infoTable,
|
||||
new Paragraph({ spacing: { before: 1200 } }), // Balanced whitespace
|
||||
new Paragraph({ alignment: AlignmentType.CENTER, spacing: { after: 200 },
|
||||
children: [new TextRun({ text: "论文题目", size: 28, font: { eastAsia: "SimSun", ascii: "Times New Roman" } })] }),
|
||||
new Paragraph({ alignment: AlignmentType.CENTER, spacing: { after: 200, line: Math.ceil(16 * 23), lineRule: "atLeast" },
|
||||
children: [new TextRun({ text: safeText(title, "【Thesis Title】"), size: 32, bold: true,
|
||||
font: { eastAsia: "SimHei", ascii: "Times New Roman" } })] }),
|
||||
subtitle ? new Paragraph({ alignment: AlignmentType.CENTER, spacing: { after: 800 },
|
||||
children: [new TextRun({ text: "——" + subtitle, size: 28,
|
||||
font: { eastAsia: "SimSun", ascii: "Times New Roman" } })] })
|
||||
: new Paragraph({ spacing: { after: 800 }, children: [] }),
|
||||
];
|
||||
}
|
||||
```
|
||||
|
||||
### ⚠️ WPS Compatibility Notes for Academic Covers
|
||||
|
||||
Both thesis cover and proposal cover use info tables. These MUST follow the cross-engine rules:
|
||||
- Table uses **percentage widths** (`WidthType.PERCENTAGE`), NOT DXA — WPS renders DXA widths differently in nested contexts
|
||||
- Table width: adaptive 55–75%, centered via `alignment: CENTER` (calculated by `calcR5MetaLayout()`)
|
||||
- Label column: **LEFT aligned**, plain text + "：", NO full-width space padding, NO borders
|
||||
- Value column: **LEFT aligned**, `bottom: single sz=4` border = fixed-length underline
|
||||
- Cell `margins.top/bottom: 60` is acceptable (small values) but avoid larger values
|
||||
- All paragraphs with font size > 12pt (body) must set `spacing: { line: Math.ceil(fontPt * 23), lineRule: "atLeast" }` to prevent top clipping (Rule 8)
|
||||
- ⚠️ Do NOT use DXA widths, full-width space padding (`\u3000`), tab stops, or right-alignment for meta info
|
||||
|
||||
⚠️ **Proposal cover must fit on one page.** Use the same height-budget approach as commercial covers — total content height must stay within 15638 twips (1200 twips safety margin). If the title is very long, reduce font size (minimum 24pt).
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Section Content Standards
|
||||
|
||||
### Chinese Abstract
|
||||
**Format:**
|
||||
- Title: "摘 要" (space in middle), San Hao SimHei centered, H1 style
|
||||
- Body: Xiao Si SimSun, justified, first-line indent 480 twips
|
||||
- Keywords: "关键词：" SimHei bold + content SimSun normal, 3–8 keywords, semicolon-separated
|
||||
|
||||
**Content structure (mandatory):**
|
||||
1. Research background (1–2 sentences)
|
||||
2. Research problem/purpose (1 sentence)
|
||||
3. Research method (1–2 sentences)
|
||||
4. Main results/findings (2–3 sentences)
|
||||
5. Research significance/value (1 sentence)
|
||||
|
||||
⚠️ **Abstract is NOT a TOC summary.** Must not read as "Chapter 1 introduces... Chapter 2 analyzes..."
|
||||
|
||||
### English Abstract
|
||||
- Title: "Abstract", San Hao Times New Roman Bold, centered, H1 style
|
||||
- Body: Xiao Si Times New Roman, justified
|
||||
- Keywords: bold label + normal content, 3–8 keywords, comma-separated
|
||||
- **Must be consistent with Chinese abstract** — no significant shrinkage
|
||||
- Use formal academic English, avoid Chinglish
|
||||
|
||||
### Table of Contents
|
||||
- Title: "目 录", San Hao SimHei centered
|
||||
- Use `TableOfContents` field for auto-generation, display at least H1–H2, recommend H3
|
||||
- Run `"$DOCX_SCRIPTS/add_toc_placeholders.py" --auto` after generation
|
||||
- TOC on its own page
|
||||
|
||||
---
|
||||
|
||||
## Body Chapter Structure
|
||||
|
||||
### Standard Structure (6-chapter)
|
||||
|
||||
```
|
||||
Chapter 1: Introduction
|
||||
1.1 Research Background
|
||||
1.2 Research Purpose & Significance
|
||||
1.3 Literature Review (Domestic & International)
|
||||
1.4 Research Content & Methods
|
||||
1.5 Thesis Structure
|
||||
|
||||
Chapter 2: Theoretical Framework & Literature Review
|
||||
2.1 Core Concept Definitions
|
||||
2.2 Theoretical Basis
|
||||
2.3 Literature Review
|
||||
2.4 Research Gap & Entry Point
|
||||
|
||||
Chapter 3: Research Design / Method / Model
|
||||
3.1 Research Framework
|
||||
3.2 Method Design / System Architecture / Algorithm
|
||||
3.3 Variables / Data Sources / Experimental Environment
|
||||
|
||||
Chapter 4: Empirical Analysis / Case Study / Results
|
||||
4.1 Data Analysis / Case Description / Experiment Process
|
||||
4.2 Results Presentation
|
||||
4.3 Results Interpretation
|
||||
|
||||
Chapter 5: Discussion
|
||||
5.1 Key Findings
|
||||
5.2 Comparison with Existing Research
|
||||
5.3 Limitations
|
||||
|
||||
Chapter 6: Conclusions & Outlook
|
||||
6.1 Research Conclusions
|
||||
6.2 Contributions
|
||||
6.3 Limitations
|
||||
6.4 Future Research Directions
|
||||
```
|
||||
|
||||
### Chapter Content Requirements
|
||||
|
||||
**Chapter 1 (Introduction):** Must state background, purpose, significance, methods, content, structure.
|
||||
|
||||
**Chapter 2 (Literature Review):** Must be systematically organized by theme/method/stage — **never a chronological dump of papers**. Must identify contributions, gaps, and research opportunities.
|
||||
|
||||
**Chapter 3 (Method):** Must explain why this method was chosen and its rationale. Content must be understandable, executable, reproducible.
|
||||
|
||||
**Chapter 4 (Results):** Must be specific, not vague. Must be consistent with Chapter 3 design.
|
||||
|
||||
**Chapter 5 (Discussion):** Must not merely repeat Chapter 4 results. Must explain what results mean and what conclusions they support.
|
||||
|
||||
**Chapter 6 (Conclusions):** Must summarize concisely, state contributions, acknowledge limitations, propose future directions. Must end formally — no abrupt ending.
|
||||
|
||||
---
|
||||
|
||||
## Discipline-Adaptive Routing
|
||||
|
||||
Auto-adjust research methods and chapter emphasis by discipline. **When user doesn't specify method, choose the most appropriate research paradigm for the discipline — never mechanically apply "empirical + survey + regression" template.**
|
||||
|
||||
### 1. Humanities & Social Sciences (Literature, History, Philosophy, Arts)
|
||||
**Preferred methods:** Literature analysis, theoretical research, text analysis, comparative studies, historical research
|
||||
**Adjustments:** Ch.2 focuses on theoretical lineage; Ch.4 becomes text analysis/case argumentation; minimize "variables", "hypotheses", "regression" terminology
|
||||
|
||||
### 2. Management / Economics / Public Administration
|
||||
**Preferred methods:** Case analysis, surveys, model analysis, institutional research, empirical research
|
||||
**Adjustments:** Ch.3 focuses on hypotheses, variables, framework; Ch.4 on data collection & analysis; Ch.5 adds management implications/policy recommendations
|
||||
|
||||
### 3. Computer Science / Engineering / IT
|
||||
**Preferred methods:** Method design, system architecture, experimental comparison, performance evaluation, algorithm analysis
|
||||
**Adjustments:** Ch.3 becomes system/algorithm design; Ch.4 becomes experiments (environment, parameters, control experiments, metric comparison); minimize "interviews", "surveys"
|
||||
|
||||
### 4. Education / Linguistics / Communication
|
||||
**Preferred methods:** Teaching experiments, text analysis, survey research, interview research, case studies
|
||||
**Adjustments:** Ch.3 focuses on subjects, dimensions, samples; Ch.4 on teaching practice/communication case analysis; Ch.5 adds educational implications/communication strategies
|
||||
|
||||
### 5. Law / Marxism / Policy Studies
|
||||
**Preferred methods:** Normative analysis, statutory interpretation, case studies, institutional comparison, theoretical analysis
|
||||
**Adjustments:** Ch.2 focuses on legal/policy framework; Ch.4 becomes case analysis/institutional comparison; Ch.5 focuses on normative evaluation, reform recommendations
|
||||
|
||||
---
|
||||
|
||||
## Figure/Table/Formula Numbering (By Chapter)
|
||||
|
||||
### Numbering Rules
|
||||
|
||||
| Type | Format | Example |
|
||||
|------|--------|---------|
|
||||
| Figure | Figure X-Y | Figure 3-1, Figure 4-2 |
|
||||
| Table | Table X-Y | Table 2-1, Table 4-3 |
|
||||
| Formula | Eq. (X-Y) | Eq. (3-1), Eq. (5-2) |
|
||||
|
||||
Where X = chapter number, Y = sequential number within chapter.
|
||||
|
||||
### Figures
|
||||
- Caption **below** figure, Wu Hao SimSun, centered
|
||||
- Format: "Figure X-Y Description"
|
||||
- Must be referenced in text: "as shown in Figure 3-1"
|
||||
|
||||
```js
|
||||
new Paragraph({ alignment: AlignmentType.CENTER,
|
||||
children: [new ImageRun({ data: imgBuf, transformation: { width: w, height: h }, type: "png" })] }),
|
||||
new Paragraph({ alignment: AlignmentType.CENTER, spacing: { before: 60, after: 200 },
|
||||
children: [new TextRun({ text: "图3-1 System Architecture", size: 21,
|
||||
font: { eastAsia: "SimSun", ascii: "Times New Roman" } })] }),
|
||||
```
|
||||
|
||||
### Tables
|
||||
- Caption **above** table, Wu Hao SimSun, centered, `keepNext: true`
|
||||
- Format: "Table X-Y Description"
|
||||
- Must use three-line table (mandatory for academic papers)
|
||||
- Must be referenced in text: "as shown in Table 2-1"
|
||||
|
||||
### Formulas
|
||||
- Formula centered, number **right-aligned**
|
||||
- Use Tab for center + right alignment
|
||||
- Text reference: "from Eq. (3-1)"
|
||||
|
||||
```js
|
||||
new Paragraph({
|
||||
alignment: AlignmentType.CENTER,
|
||||
tabStops: [
|
||||
{ type: TabStopType.CENTER, position: 4500 },
|
||||
{ type: TabStopType.RIGHT, position: 9000 },
|
||||
],
|
||||
children: [
|
||||
new TextRun({ text: "\t" }),
|
||||
new TextRun({ text: "E = mc²" }),
|
||||
new TextRun({ text: "\t(3-1)" }),
|
||||
],
|
||||
}),
|
||||
```
|
||||
|
||||
### Mandatory Rules
|
||||
1. Figures/tables/formulas **must be referenced in text** — never placed without explanation
|
||||
2. Must have introductory and analytical text before/after
|
||||
3. Must not exceed page margins
|
||||
4. Insert only when analytically valuable — not for decoration
|
||||
|
||||
---
|
||||
|
||||
## Citation & Reference System
|
||||
|
||||
### In-Text Citation (Sequential Numbering)
|
||||
|
||||
Default: **GB/T 7714 sequential numbering** — `[1]`, `[2]` in text, references listed in order of appearance.
|
||||
|
||||
```js
|
||||
new TextRun({ text: "[1]", superScript: true, size: 18, font: { ascii: "Times New Roman" } })
|
||||
```
|
||||
|
||||
### Citation Rules
|
||||
1. In-text numbers must **correspond one-to-one** with reference list
|
||||
2. **Same source reused keeps the same number**
|
||||
3. **Do not mix footnote citations and endnote references** (unless user explicitly requests)
|
||||
4. Footnotes are for supplementary notes only, not primary citations
|
||||
|
||||
### Reference Format (GB/T 7714)
|
||||
```
|
||||
[1] Author. Title[J]. Journal, Year, Vol(No): Pages.
|
||||
[2] Author. Book Title[M]. Place: Publisher, Year: Pages.
|
||||
[3] Author. Title[D]. Location: Institution, Year.
|
||||
[4] Author. Title[EB/OL]. (Published)[Cited]. URL.
|
||||
```
|
||||
|
||||
### Reference Formatting
|
||||
```js
|
||||
// Reference title — H1 style
|
||||
new Paragraph({ heading: HeadingLevel.HEADING_1, alignment: AlignmentType.CENTER,
|
||||
children: [new TextRun({ text: "References", bold: true, size: 32, font: { eastAsia: "SimHei" } })] }),
|
||||
// Each entry — hanging indent
|
||||
new Paragraph({
|
||||
indent: { left: 420, hanging: 420 },
|
||||
spacing: { line: 360 },
|
||||
children: [new TextRun({ text: "[1] Author. Title[J]. Journal, 2024, 59(3): 45-62.",
|
||||
size: 21, font: { eastAsia: "SimSun", ascii: "Times New Roman" } })],
|
||||
}),
|
||||
```
|
||||
|
||||
### Reference Count Guidelines
|
||||
|
||||
| Thesis Type | Suggested Count |
|
||||
|------------|----------------|
|
||||
| Course paper (3000–5000 words) | 10–15 |
|
||||
| Undergraduate thesis | 15–30 |
|
||||
| Master's thesis | 40–80 |
|
||||
| Doctoral dissertation | 80–150 |
|
||||
|
||||
If user specifies APA, MLA, Chicago, or school-specific format, follow that instead.
|
||||
|
||||
---
|
||||
|
||||
## Three-Line Table (Mandatory for Academic Papers)
|
||||
|
||||
All tables in academic papers **must use three-line tables** — no full-border tables.
|
||||
|
||||
```js
|
||||
const threeLineTable = new Table({
|
||||
width: { size: 100, type: WidthType.PERCENTAGE },
|
||||
borders: {
|
||||
top: { style: BorderStyle.SINGLE, size: 4, color: "000000" },
|
||||
bottom: { style: BorderStyle.SINGLE, size: 4, color: "000000" },
|
||||
left: { style: BorderStyle.NONE }, right: { style: BorderStyle.NONE },
|
||||
insideHorizontal: { style: BorderStyle.NONE }, insideVertical: { style: BorderStyle.NONE },
|
||||
},
|
||||
rows: [
|
||||
new TableRow({
|
||||
tableHeader: true, cantSplit: true,
|
||||
children: headerCells.map(text => new TableCell({
|
||||
borders: { bottom: { style: BorderStyle.SINGLE, size: 2, color: "000000" },
|
||||
top: { style: BorderStyle.NONE }, left: { style: BorderStyle.NONE }, right: { style: BorderStyle.NONE } },
|
||||
margins: { top: 60, bottom: 60, left: 120, right: 120 },
|
||||
children: [new Paragraph({ alignment: AlignmentType.CENTER,
|
||||
children: [new TextRun({ text, bold: true, size: 21, font: { eastAsia: "SimSun", ascii: "Times New Roman" } })] })],
|
||||
})),
|
||||
}),
|
||||
...dataRows, // All borders NONE
|
||||
],
|
||||
});
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Content Quality Constraints (Mandatory)
|
||||
|
||||
### Truthfulness & Conservatism
|
||||
1. **Never fabricate** unverifiable statistics, survey response counts, significance levels, interview subject identities, experimental precision, government document numbers
|
||||
2. **Never invent** non-existent classic theories, authoritative scholar opinions, regulation names, core data sources
|
||||
3. When user provides no real data → prefer **theoretical analysis, literature research, case studies, comparative analysis** (low-risk methods)
|
||||
4. If example data must be constructed → keep scale reasonable, results conservative; never produce "significantly superior" or "dramatically improved" high-risk claims
|
||||
5. Research conclusions must be **restrained** — do not overstate contributions, effects, or applicability
|
||||
6. Research limitations must be **honestly disclosed**
|
||||
|
||||
### Language Style
|
||||
1. Formal academic register throughout
|
||||
2. **Forbidden:** "I think", "everyone knows", "obviously", "it is well known" (subjective expressions)
|
||||
3. **Forbidden:** Sloganeering, propaganda, advertising-style expressions
|
||||
4. First occurrence of CN/EN terms should include English original
|
||||
5. CN/EN punctuation, spacing, and number formats must be consistent throughout
|
||||
|
||||
### Structural Consistency
|
||||
1. Abstract, body, and conclusions **must be consistent** — no self-contradiction
|
||||
2. Must form complete loop: "research question → method → analysis → findings → conclusions & outlook"
|
||||
3. Terminology consistent throughout — no concept drift
|
||||
4. All chapters balanced and substantive — no padding
|
||||
|
||||
### Document Cleanliness
|
||||
1. **No residual** comments, tracked changes, field codes, template default text
|
||||
2. **No** "TBD", "omitted", "user modifies", "insert figure here" expressions
|
||||
3. **No** Markdown syntax, HTML tags, code blocks wrapping body text
|
||||
4. **No** consecutive blank lines, abnormal page breaks, chaotic numbering
|
||||
5. Final document must be clean, well-formatted, ready for submission
|
||||
|
||||
---
|
||||
|
||||
## School Standard Override Rule
|
||||
|
||||
⚠️ **When user specifies school/journal-specific format requirements, those requirements OVERRIDE all defaults above.**
|
||||
|
||||
Common override items:
|
||||
- Margins (binding margin left 3.5 cm common)
|
||||
- Body font (some schools require FangSong)
|
||||
- Line spacing (some schools require fixed 28pt)
|
||||
- Cover layout (varies significantly by school)
|
||||
- Reference format (APA, MLA, etc.)
|
||||
- Heading numbering (some schools use "1", "2" instead of "Chapter 1", "Chapter 2")
|
||||
|
||||
### Common Variants
|
||||
|
||||
| Thesis Type | Common Differences |
|
||||
|------------|-------------------|
|
||||
| Top universities | Strict GB/T 7714, often require STXiaoBiaoSong cover |
|
||||
| Regular undergraduate | More flexible, SimSun/SimHei sufficient |
|
||||
| Master's thesis | Requires English abstract, longer lit review, innovation statement |
|
||||
| Doctoral dissertation | Requires innovation statement, publication list, originality declaration |
|
||||
|
||||
---
|
||||
|
||||
## Scene-Specific Quality Checks
|
||||
|
||||
In addition to universal checks (see `references/common-rules.md`):
|
||||
|
||||
### Structure & Content
|
||||
- [ ] Cover, abstract, English abstract, TOC, body, references all present
|
||||
- [ ] Cover info complete (school/title/EN title/college/major/name/ID/advisor/date)
|
||||
- [ ] Abstract contains 5 elements: background + problem + method + results + significance
|
||||
- [ ] English abstract consistent with Chinese abstract
|
||||
- [ ] All chapters balanced, substantive, logical loop complete
|
||||
- [ ] Literature review is thematic, not chronological dump
|
||||
- [ ] Conclusions respond to research questions
|
||||
|
||||
### Format & Layout
|
||||
- [ ] Heading numbering consistent (Chapter X / X.X / X.X.X), no mixing
|
||||
- [ ] All body headings use `heading: HeadingLevel.HEADING_X`
|
||||
- [ ] Body text pure black `"000000"`
|
||||
- [ ] Three-line tables used consistently (no full-border tables)
|
||||
- [ ] Figure captions below, table captions above, numbered by chapter
|
||||
- [ ] Formulas centered, numbers right-aligned
|
||||
- [ ] In-text citations match reference list one-to-one
|
||||
- [ ] References use hanging indent, consistent format
|
||||
- [ ] Page numbers: front matter Roman, body Arabic from 1
|
||||
- [ ] Cover has no page number
|
||||
- [ ] Headers formal and concise
|
||||
- [ ] No extra blank pages
|
||||
|
||||
### Cleanliness
|
||||
- [ ] No comment/revision residuals
|
||||
- [ ] No "TBD" / "omitted" expressions
|
||||
- [ ] No Markdown/HTML/code block residuals
|
||||
- [ ] No consecutive blank lines or abnormal page breaks
|
||||
- [ ] No fabricated high-risk data or exaggerated conclusions
|
||||
463
skills/docx/scenes/contract.md
Executable file
463
skills/docx/scenes/contract.md
Executable file
@@ -0,0 +1,463 @@
|
||||
# Scene: Contract / Agreement
|
||||
|
||||
## Goal
|
||||
|
||||
Generate a complete, formal, well-structured legal document with clear clauses, rigorous logic, and proper formatting. Must simultaneously meet:
|
||||
- Complete structure, clear clauses, formal language, explicit responsibilities
|
||||
- Identifiable risk boundaries, proper Word formatting
|
||||
- Ready for review, revision, circulation, or signing preparation
|
||||
|
||||
**Forbidden:** Producing outlines-only / sample clauses / drafting advice / risk summaries; outputting chat-style explanations or filler phrases.
|
||||
|
||||
→ Font profile: **A (Formal)** — see `references/common-rules.md`
|
||||
→ Default layout: standard margins — see `references/common-rules.md`
|
||||
→ Placeholder convention & universal prohibitions — see `references/common-rules.md`
|
||||
|
||||
---
|
||||
|
||||
## Contract Type Routing
|
||||
|
||||
```js
|
||||
function selectContractType(keywords, topic) {
|
||||
if (/confidential|NDA|non-disclosure/.test(keywords)) return "nda";
|
||||
if (/transfer|equity|asset|rights/.test(keywords)) return "transfer";
|
||||
if (/framework|strategic|cooperation agreement/.test(keywords)) return "framework";
|
||||
if (/terms|platform rules|user agreement|privacy/.test(keywords)) return "terms";
|
||||
return "bilateral"; // default: bilateral commercial contract
|
||||
}
|
||||
```
|
||||
|
||||
### 5 Contract Types
|
||||
|
||||
| Type | Use Case | Structure Focus |
|
||||
|------|----------|----------------|
|
||||
| bilateral | Service/sale/development/procurement contracts | Subject → Consideration → Performance → Acceptance → Breach → Dispute |
|
||||
| transfer | Equity/debt/asset/rights transfer | Subject → Consideration → Closing & Registration → Representations → Tax |
|
||||
| nda | Non-disclosure agreements | Definition of Confidential Info → Obligations → Use Restrictions → Exceptions → Duration |
|
||||
| framework | Cooperation framework / strategic alliance | Scope → Division of Work → Mechanism → Subsequent Agreements |
|
||||
| terms | Platform rules / Terms of Service / User agreements | Definitions → Services → Rights & Obligations → Liability Limits → Amendments |
|
||||
|
||||
---
|
||||
|
||||
## Standard Template Structures
|
||||
|
||||
### Template A: Bilateral Commercial Contract
|
||||
1. Header (title, contract number, date, location)
|
||||
2. Party Information (Party A, Party B)
|
||||
3. Recitals ("Whereas" clauses)
|
||||
4. Definitions & Interpretation
|
||||
5. Subject Matter & Scope of Services/Delivery
|
||||
6. Contract Price & Payment Terms
|
||||
7. Rights & Obligations of Both Parties
|
||||
8. Timeline, Delivery & Acceptance
|
||||
9. Invoicing, Tax & Settlement
|
||||
10. Intellectual Property & Confidentiality
|
||||
11. Representations & Warranties (if applicable)
|
||||
12. Liability for Breach
|
||||
13. Force Majeure
|
||||
14. Termination & Dissolution
|
||||
15. Notices & Service
|
||||
16. Dispute Resolution
|
||||
17. Miscellaneous
|
||||
18. Signature Block
|
||||
|
||||
### Template B: Rights Transfer Agreement
|
||||
1. Header & Parties
|
||||
2. Recitals
|
||||
3. Definitions & Interpretation
|
||||
4. Subject of Transfer
|
||||
5. Consideration & Payment Arrangement
|
||||
6. Closing & Registration/Transfer
|
||||
7. Representations & Warranties
|
||||
8. Tax Allocation
|
||||
9. Liability for Breach
|
||||
10. Dispute Resolution
|
||||
11. Miscellaneous
|
||||
12. Signature Block
|
||||
|
||||
### Template C: Non-Disclosure Agreement (NDA)
|
||||
1. Header & Parties
|
||||
2. Recitals
|
||||
3. Definition of Confidential Information
|
||||
4. Confidentiality Obligations
|
||||
5. Use Restrictions
|
||||
6. Return, Deletion & Destruction of Information
|
||||
7. Exceptions
|
||||
8. Confidentiality Period
|
||||
9. Liability for Breach
|
||||
10. Dispute Resolution
|
||||
11. Miscellaneous
|
||||
12. Signature Block
|
||||
|
||||
### Template D: Framework / Cooperation Agreement
|
||||
1. Header & Parties
|
||||
2. Recitals
|
||||
3. Purpose & Principles
|
||||
4. Scope of Cooperation
|
||||
5. Division of Work & Responsibilities
|
||||
6. Project Advancement Mechanism
|
||||
7. Commercial Arrangements / Subsequent Agreements
|
||||
8. Confidentiality, IP & Compliance
|
||||
9. Term, Amendment & Termination
|
||||
10. Liability for Breach
|
||||
11. Dispute Resolution
|
||||
12. Miscellaneous
|
||||
13. Signature Block
|
||||
|
||||
### Template E: Unilateral Terms / Platform Rules
|
||||
1. Document Title
|
||||
2. Definitions & Scope
|
||||
3. Service/Rule Content
|
||||
4. User Rights & Obligations / Platform Rights & Obligations
|
||||
5. Liability Limitations & Disclaimers
|
||||
6. Fees & Payment (if applicable)
|
||||
7. Intellectual Property
|
||||
8. Termination, Suspension & Amendment
|
||||
9. Notices & Service
|
||||
10. Dispute Resolution
|
||||
11. Miscellaneous
|
||||
|
||||
**Note:** Unilateral/boilerplate terms require special attention to adhesion clause risks — avoid creating extremely one-sided documents.
|
||||
|
||||
**If the user provides an existing template, historical agreement, or company standard, always follow it first.**
|
||||
|
||||
---
|
||||
|
||||
## Input Recognition & Completion
|
||||
|
||||
### Processing Rules
|
||||
1. If user provides a template, historical agreement, or company standard → **always follow it first**
|
||||
2. If information is incomplete, fill conservatively — must be **restrained, natural, professional, consistent with transaction logic**
|
||||
3. **Never fabricate** unrealistic commercial terms, regulatory requirements, approval conclusions, qualification status, tax treatment results, payment facts, or performance facts
|
||||
4. If critical info is missing → use standardized placeholders
|
||||
5. If user does not specify jurisdiction → default to PRC commercial writing conventions, but avoid making specific legal conclusions
|
||||
|
||||
---
|
||||
|
||||
## Legal Writing Standards
|
||||
|
||||
### Register
|
||||
1. Use formal legal document register
|
||||
2. Use clear party designations: "Party A", "Party B", "both parties", "either party", "non-breaching party", "breaching party"
|
||||
3. **Forbidden:** Colloquial expressions ("you", "me", "they", "pay up", "cancel the contract", "handle ASAP")
|
||||
4. Preferred terms: "pay consideration", "perform obligations", "constitute a breach", "terminate the contract", "assume liability for damages", "written notice", "deliver and accept", "representations and warranties"
|
||||
|
||||
### Precision
|
||||
1. Eliminate vague adjectives: avoid "quality", "reasonable", "enormous", "appropriate", "ASAP" unless necessary for legal flexibility
|
||||
2. Each obligation must specify: who, when, how, what
|
||||
3. Consistent legal phrasing:
|
||||
- Mandatory obligation → "shall"
|
||||
- Right authorization → "has the right to"
|
||||
- Prohibition → "shall not"
|
||||
- Discretionary → "may"
|
||||
4. Amounts, dates, percentages, deadlines, business days vs. calendar days must be as specific as possible
|
||||
|
||||
### Clear Subjects
|
||||
1. Every clause must have an explicit responsible party — avoid vague subjects ("relevant parties", "relevant personnel", "when necessary")
|
||||
2. Joint obligations: explicitly write "both parties agree" or "both parties shall"
|
||||
3. Unilateral obligations: explicitly write "Party A shall" or "Party B shall"
|
||||
|
||||
---
|
||||
|
||||
## Transaction Closure & Risk Control
|
||||
|
||||
A contract must not only describe the transaction — it must ensure logical closure. Check the following:
|
||||
|
||||
1. If a performance deadline is specified → specify consequences of delay
|
||||
2. If payment milestones are specified → specify payment conditions, method, invoice requirements
|
||||
3. If a delivery obligation exists → specify delivery standards, method, acceptance rules, objection period
|
||||
4. If termination rights exist → specify conditions, notice, effective date, post-termination settlement
|
||||
5. If breach liability exists → must correspond to main obligations in preceding clauses
|
||||
6. If IP/technology/data/trade secrets are involved → separately address ownership, license scope, use restrictions
|
||||
7. If confidentiality obligations exist → define scope, exceptions, duration, breach consequences
|
||||
8. If force majeure clause exists → specify notice obligation, mitigation duty, subsequent negotiation mechanism
|
||||
9. If notice/service arrangements exist → specify address, contact person, email, or other delivery method
|
||||
10. If user requests significantly one-sided adhesion/disclaimer clauses → add a note near the clause:
|
||||
`[Note: This clause may involve adhesion terms or liability limitations. Manual review recommended for the specific transaction.]`
|
||||
|
||||
---
|
||||
|
||||
## Truthfulness & Legal Caution
|
||||
|
||||
1. **Never fabricate** specific statute article numbers, judicial interpretation numbers, or regulatory document numbers
|
||||
2. Legal bases should use general references, e.g.: "In accordance with the Civil Code of the PRC and relevant laws and regulations..."
|
||||
3. **Never** pretend to provide formal legal opinions, litigation success predictions, or definitive validity/invalidity conclusions
|
||||
4. **Never** state definitive legality conclusions for high-risk clauses (adhesion terms, penalty clauses, disclaimers, non-compete, exclusivity, unilateral interpretation rights)
|
||||
5. **Never** fabricate that regulatory approvals are obtained, title is unencumbered, tax compliance is assured, or third-party consent is secured
|
||||
6. When critical info is insufficient → use placeholders, never present as confirmed fact
|
||||
7. For high-risk areas (equity, debt, licenses, data compliance, labor, personal information, cross-border) → maintain restrained language, do not add rigid commitments without user confirmation
|
||||
|
||||
---
|
||||
|
||||
## Special Clause Requirements
|
||||
|
||||
### Definitions Clause
|
||||
If the document repeatedly uses specialized terms ("deliverables", "service results", "confidential information", "source code", "project milestones", "acceptance criteria", "trade secrets"), include a "Definitions & Interpretation" clause near the beginning.
|
||||
|
||||
### Dispute Resolution
|
||||
1. Must be explicit
|
||||
2. Choose between litigation OR arbitration — never mix both
|
||||
3. Litigation → specify jurisdictional connection point
|
||||
4. Arbitration → specify arbitration institution
|
||||
5. If user hasn't specified → use placeholder for confirmation
|
||||
|
||||
### Tax Clause
|
||||
1. If the transaction involves taxes → specify which party bears them, whether price includes tax, invoice type and conditions
|
||||
2. Avoid vague "taxes borne as required by law" without transaction-specific detail
|
||||
|
||||
### Breach Liability
|
||||
1. Must correspond to main obligations in preceding clauses
|
||||
2. Penalty amounts should be restrained — avoid obviously exaggerated or severely imbalanced figures
|
||||
3. If fundamental breach exists → consider corresponding termination rights and damages
|
||||
|
||||
### Appendices
|
||||
1. For complex subjects/pricing/technical requirements/deliverables → use "Appendix 1, Appendix 2..." format
|
||||
2. Explicitly state appendix-contract relationship (typically: "Appendices form an integral part of this contract")
|
||||
3. If appendix content is unknown → use placeholder
|
||||
|
||||
---
|
||||
|
||||
## Palette
|
||||
|
||||
**Legal Wood** (Warm + Heavy + Calm) — for decorative elements only; body text must be pure black.
|
||||
|
||||
```js
|
||||
const palette = { primary:"#28201C", body:"#000000", secondary:"#6E6560", accent:"#7A5C3A", surface:"#FBF9F7" };
|
||||
```
|
||||
|
||||
⚠️ **ALL visible text in contracts must be pure black `"000000"`.** This includes:
|
||||
- Contract title (SimHei, black, NOT accent color)
|
||||
- Contract number (black)
|
||||
- Clause headings (black)
|
||||
- Body text (black)
|
||||
- Party information (black)
|
||||
- Signature block text (black)
|
||||
|
||||
**The only exception** is red-header official documents (红头文件), which follow their own GB/T 9704 color rules. For standard contracts, NO colored text is permitted — no red, no accent color, no dark-blue-grey.
|
||||
|
||||
```js
|
||||
// ✅ Contract title — always pure black
|
||||
new Paragraph({ alignment: AlignmentType.CENTER,
|
||||
spacing: { line: Math.ceil(22 * 23), lineRule: "atLeast" }, // ★ Rule 8: prevent clipping
|
||||
children: [new TextRun({ text: "Training Cooperation Framework Agreement",
|
||||
size: 44, bold: true, color: "000000", // ← MUST be "000000"
|
||||
font: { eastAsia: "SimHei", ascii: "Times New Roman" } })]
|
||||
})
|
||||
|
||||
// ❌ FORBIDDEN — accent/palette color on contract text
|
||||
new TextRun({ text: "Training Cooperation Framework Agreement", color: palette.accent }) // ← WRONG
|
||||
new TextRun({ text: "Contract No.:", color: palette.primary }) // ← WRONG (if primary ≠ "000000")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Scene-Specific Font Overrides
|
||||
|
||||
Beyond Profile A defaults:
|
||||
|
||||
| Element | Font | Size | Style |
|
||||
|---------|------|------|-------|
|
||||
| Contract title | SimHei | Er Hao 22pt (size: 44) | Bold, centered |
|
||||
| Contract number | SimSun | Wu Hao 10.5pt (size: 21) | Right-aligned |
|
||||
| Clause heading | SimHei | Xiao Si 12pt (size: 24) | Bold |
|
||||
| Monetary amount | SimSun | Xiao Si 12pt (size: 24) | Bold |
|
||||
|
||||
---
|
||||
|
||||
## Document Structure
|
||||
|
||||
1. **Title**: "XXX Contract" or "XXX Agreement" — Er Hao SimHei, centered
|
||||
2. **Contract number**: right-aligned, Wu Hao
|
||||
3. **Preamble**: Party information with placeholders
|
||||
4. **Recitals** (summarize transaction background and purpose)
|
||||
5. **Definitions** (if specialized terms recur)
|
||||
6. **Substantive clauses** (per selected template)
|
||||
7. **Signature block**
|
||||
8. **Appendices** (if any)
|
||||
|
||||
---
|
||||
|
||||
## Clause Numbering System
|
||||
|
||||
Use stable, consistent, pure-text numbering suitable for Chinese legal documents.
|
||||
|
||||
```
|
||||
Article 1 Subject Matter
|
||||
1.1 xxxxxxxxxx
|
||||
1.2 xxxxxxxxxx
|
||||
(1) xxxxxxxxxx
|
||||
(2) xxxxxxxxxx
|
||||
① xxxxxxxxxx
|
||||
② xxxxxxxxxx
|
||||
Article 2 Price and Payment
|
||||
2.1 ...
|
||||
```
|
||||
|
||||
**Numbering discipline:**
|
||||
1. No level-skipping
|
||||
2. **Forbidden:** Using Markdown list markers (`-` `*` `1.`) for clause hierarchy
|
||||
3. No switching from "Article X" to `-` or `*` or auto-list mid-document
|
||||
4. Numbering style must be consistent throughout the entire document
|
||||
5. Clause headings should be clean and simple
|
||||
|
||||
---
|
||||
|
||||
## Party Information Layout (Table-Based Alignment — Mandatory)
|
||||
|
||||
Party A and Party B information MUST be laid out using a **borderless table** so that labels align vertically. Never use plain paragraphs with indentation — this causes misalignment between parties.
|
||||
|
||||
```js
|
||||
// ✅ Correct — borderless table ensures "统一社会信用代码：", "地址：", "法定代表人：" align
|
||||
function partyInfoBlock(partyLabel, partyName, fields) {
|
||||
// fields: [["Unified Social Credit Code", value], ["Address", value], ["Legal Representative", value]]
|
||||
const NB = { style: BorderStyle.NONE, size: 0, color: "FFFFFF" };
|
||||
const noBorders = { top: NB, bottom: NB, left: NB, right: NB };
|
||||
|
||||
const headerPara = new Paragraph({ spacing: { before: 200, after: 120 },
|
||||
children: [new TextRun({ text: `${partyLabel}: ${safeText(partyName, "【Company full name】")}`,
|
||||
size: 24, font: { eastAsia: "SimSun", ascii: "Times New Roman" } })]
|
||||
});
|
||||
|
||||
const infoTable = new Table({
|
||||
width: { size: 90, type: WidthType.PERCENTAGE },
|
||||
borders: { top: NB, bottom: NB, left: NB, right: NB, insideHorizontal: NB, insideVertical: NB },
|
||||
rows: fields.map(([label, value]) => new TableRow({
|
||||
children: [
|
||||
new TableCell({
|
||||
width: { size: 35, type: WidthType.PERCENTAGE },
|
||||
borders: noBorders,
|
||||
margins: { top: 40, bottom: 40, left: 420, right: 60 },
|
||||
children: [new Paragraph({
|
||||
children: [new TextRun({ text: `${label}:`, size: 24,
|
||||
font: { eastAsia: "SimSun", ascii: "Times New Roman" } })],
|
||||
})],
|
||||
}),
|
||||
new TableCell({
|
||||
borders: noBorders,
|
||||
margins: { top: 40, bottom: 40, left: 60, right: 120 },
|
||||
children: [new Paragraph({
|
||||
children: [new TextRun({ text: safeText(value, `【Please fill in: ${label}】`), size: 24,
|
||||
font: { eastAsia: "SimSun", ascii: "Times New Roman" } })],
|
||||
})],
|
||||
}),
|
||||
],
|
||||
})),
|
||||
});
|
||||
|
||||
return [headerPara, infoTable];
|
||||
}
|
||||
|
||||
// Usage:
|
||||
const partyAChildren = partyInfoBlock("Party A (甲方)", config.partyA?.name, [
|
||||
["Unified Social Credit Code (统一社会信用代码)", config.partyA?.creditCode],
|
||||
["Address (地址)", config.partyA?.address],
|
||||
["Legal Representative (法定代表人/负责人)", config.partyA?.legalRep],
|
||||
]);
|
||||
```
|
||||
|
||||
**Rules:**
|
||||
1. Party A and Party B info blocks must use the **same table column widths** — labels align across both blocks
|
||||
2. Use `safeText()` for all field values — never output `undefined`
|
||||
3. Label column width should accommodate the longest label (e.g., "统一社会信用代码")
|
||||
4. The indent (`margins.left: 420`) simulates sub-level nesting under the party name
|
||||
|
||||
---
|
||||
|
||||
## Signature Block
|
||||
|
||||
Left-right symmetric, structured, easy to adjust in Word. Never write as scattered paragraphs.
|
||||
|
||||
Required fields for each party:
|
||||
- Party name (seal)
|
||||
- Legal representative / Authorized representative
|
||||
- Contact person
|
||||
- Contact information
|
||||
- Signing location
|
||||
- Date: 【____/____/____】
|
||||
|
||||
Use a borderless 2-column table for symmetry. **Every field value must use `safeText()`** — never output `undefined` or empty string. If a field is not provided, use the appropriate `【Please fill in】` placeholder.
|
||||
|
||||
```js
|
||||
// ✅ Correct signature block — safeText for all values
|
||||
function buildSignatureBlock(partyA, partyB) {
|
||||
const fields = ["Party (Seal)", "Legal Rep / Authorized Rep (Signature)", "Contact Person", "Contact Info", "Signing Location", "Date"];
|
||||
const NB = { style: BorderStyle.NONE, size: 0, color: "FFFFFF" };
|
||||
const noBorders = { top: NB, bottom: NB, left: NB, right: NB };
|
||||
|
||||
return new Table({
|
||||
width: { size: 100, type: WidthType.PERCENTAGE },
|
||||
borders: { top: NB, bottom: NB, left: NB, right: NB, insideHorizontal: NB, insideVertical: NB },
|
||||
rows: fields.map((label, i) => {
|
||||
const aVal = i === fields.length - 1 ? "【____/____/____】" : safeText(partyA?.[i], "");
|
||||
const bVal = i === fields.length - 1 ? "【____/____/____】" : safeText(partyB?.[i], "");
|
||||
const displayA = i === 0 ? `Party A (甲方): ${aVal}` : `${label}: ${aVal}`;
|
||||
const displayB = i === 0 ? `Party B (乙方): ${bVal}` : `${label}: ${bVal}`;
|
||||
return new TableRow({
|
||||
children: [
|
||||
new TableCell({ width: { size: 50, type: WidthType.PERCENTAGE }, borders: noBorders,
|
||||
margins: { top: 80, bottom: 80, left: 120, right: 60 },
|
||||
children: [new Paragraph({ children: [new TextRun({ text: displayA, size: 24, color: "000000" })] })] }),
|
||||
new TableCell({ width: { size: 50, type: WidthType.PERCENTAGE }, borders: noBorders,
|
||||
margins: { top: 80, bottom: 80, left: 60, right: 120 },
|
||||
children: [new Paragraph({ children: [new TextRun({ text: displayB, size: 24, color: "000000" })] })] }),
|
||||
],
|
||||
});
|
||||
}),
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Monetary Amount Format
|
||||
|
||||
Contracts must show amounts in **both uppercase Chinese and numeric format**:
|
||||
|
||||
```
|
||||
Contract amount: RMB One Million Two Hundred Thirty-Four Thousand Five Hundred Sixty-Seven Yuan (¥1,234,567.00)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Style Rules
|
||||
|
||||
- **NO cover page** — title page is the first page (title + contract number at top)
|
||||
- **NO TOC** unless >20 clauses
|
||||
- **NO decorative elements** — contracts must be formal and clean
|
||||
- **Line spacing**: 1.5x (line: 360) — ⚠️ scene override (Profile A default is 1.3x/312; contracts use 1.5x for readability and annotation space)
|
||||
- **Body**: Justified, first-line indent 480 twips
|
||||
- **Color**: pure black "000000" throughout — no colored text
|
||||
|
||||
---
|
||||
|
||||
## Scene-Specific Quality Checks
|
||||
|
||||
In addition to universal checks (see `references/common-rules.md`):
|
||||
|
||||
### Format
|
||||
- [ ] Party information complete (full name / address / legal representative / contact)
|
||||
- [ ] Signature block properly formatted, symmetrical, all fields present
|
||||
- [ ] Monetary amounts shown in both uppercase and numeric format
|
||||
- [ ] Clause numbering sequential with no gaps
|
||||
- [ ] No cover page (title page is first page)
|
||||
- [ ] No Markdown list markers mixed into clause hierarchy
|
||||
|
||||
### Content
|
||||
- [ ] Clause numbering system consistent, no mixing
|
||||
- [ ] Transaction closure complete (subject → consideration → performance → acceptance → breach → dispute)
|
||||
- [ ] Breach liability corresponds to main obligations
|
||||
- [ ] Dispute resolution explicitly stated (or placeholder for confirmation)
|
||||
- [ ] All unconfirmed variables use `【】` placeholders consistently
|
||||
- [ ] Language is formal, restrained, subjects are explicit
|
||||
- [ ] No fabricated statute numbers or overreaching legal conclusions
|
||||
- [ ] High-risk clauses include manual review notes
|
||||
- [ ] Terminology consistent throughout
|
||||
- [ ] Appendix-contract relationship explicitly stated
|
||||
|
||||
### Closure
|
||||
- [ ] Performance deadline → delay consequences specified
|
||||
- [ ] Payment milestones → conditions and invoice requirements specified
|
||||
- [ ] Delivery obligation → acceptance rules and objection period specified
|
||||
- [ ] Termination right → conditions and post-termination handling specified
|
||||
- [ ] Confidentiality obligation → scope, exceptions, duration, breach consequences specified
|
||||
- [ ] Force majeure → notice and mitigation duties specified
|
||||
139
skills/docx/scenes/copywriting.md
Executable file
139
skills/docx/scenes/copywriting.md
Executable file
@@ -0,0 +1,139 @@
|
||||
# Scene: Copywriting / Script
|
||||
|
||||
## Scope
|
||||
|
||||
Broadcast scripts, product promotion copy, livestream scripts, presentation scripts, speeches, hosting scripts, short video scripts — any document where the goal is **spoken delivery**.
|
||||
|
||||
→ Placeholder convention & universal prohibitions — see `references/common-rules.md`
|
||||
→ Font profile: **B (Visual)** — see `references/common-rules.md`
|
||||
|
||||
---
|
||||
|
||||
## 1. Core Principles
|
||||
|
||||
⚠️ **A broadcast script is NOT a report, NOT a spec sheet, NOT an encyclopedia.**
|
||||
|
||||
The goal is for the audience to **understand on first listen, remember key points, and take action.** Therefore:
|
||||
|
||||
1. **Highlight selling points, don't pile specs:** Each paragraph covers only 1–2 core points with relatable scenario descriptions
|
||||
2. **Conversational tone:** Use "you" not "the user"; use natural speech, not corporate jargon
|
||||
3. **Rhythm:** Alternate long and short sentences, insert pause markers, avoid wall-of-text paragraphs
|
||||
4. **Length discipline:** ~250–300 words per minute of speech; a 5-minute script should not exceed 1500 words
|
||||
5. **Information consistency:** All data, model numbers, prices must be consistent throughout — no self-contradiction
|
||||
|
||||
---
|
||||
|
||||
## 2. Document Structure
|
||||
|
||||
Completely different from reports:
|
||||
|
||||
```
|
||||
Title (centered, short and punchy)
|
||||
────────────────────
|
||||
[Opening] ← Grab attention, 1–2 sentences
|
||||
[Core Para 1] ← One selling point/opinion + scenario
|
||||
[Core Para 2] ← One selling point/opinion + scenario
|
||||
[Core Para 3] ← One selling point/opinion + scenario (max 3–5 paras)
|
||||
[Closing] ← Summary + Call to Action (CTA)
|
||||
────────────────────
|
||||
[Notes] ← Supplementary info, data sources (optional, small grey text)
|
||||
```
|
||||
|
||||
### Decisions
|
||||
- **Cover:** ❌ Not needed
|
||||
- **TOC:** ❌ Not needed
|
||||
- **Header/footer:** Optional, minimal
|
||||
- **Sections:** Single section sufficient
|
||||
- **Line spacing:** `line: 400` (slightly larger than standard 1.5x for reading/marking ease)
|
||||
|
||||
---
|
||||
|
||||
## 3. Layout Standards
|
||||
|
||||
### Font Specifications
|
||||
|
||||
| Element | Font | Size | Style |
|
||||
|---------|------|------|-------|
|
||||
| Title | SimHei | 18pt (size:36) | Bold, centered |
|
||||
| Section heading / highlight | SimHei | 14pt (size:28) | Bold |
|
||||
| Body | Microsoft YaHei | 12pt (size:24) | Left-aligned |
|
||||
| Rhythm markers | Microsoft YaHei | 10.5pt (size:21) | Grey 999999, italic |
|
||||
| Notes | Microsoft YaHei | 10pt (size:20) | Grey 666666 |
|
||||
|
||||
### Paragraph Spacing
|
||||
```js
|
||||
// Generous spacing between paragraphs for reading/breathing pauses
|
||||
spacing: { before: 200, after: 200, line: 400 }
|
||||
// Larger gap between core sections
|
||||
sectionGap: { before: 400, after: 200 }
|
||||
```
|
||||
|
||||
### Key Point Highlighting
|
||||
Use **bold** or **accent-colored text** to mark key selling points:
|
||||
```js
|
||||
new TextRun({ text: "Key selling point", bold: true, color: c(P.accent) })
|
||||
```
|
||||
|
||||
### Rhythm Markers (optional)
|
||||
Insert small grey markers where pauses, emphasis, or tone changes are needed:
|
||||
```js
|
||||
new Paragraph({ spacing: { before: 60, after: 60 },
|
||||
children: [new TextRun({ text: "[Pause 2 sec]", size: 21, color: "999999", italics: true })] })
|
||||
// Or inline: new TextRun({ text: " [emphasis] ", size: 18, color: "999999", italics: true })
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Content Quality Rules
|
||||
|
||||
### Information Density Guide
|
||||
|
||||
| Script Type | Duration | Word Count | Core Paragraphs |
|
||||
|-------------|----------|-----------|----------------|
|
||||
| Short video | 30–60 sec | 150–300 | 1–2 |
|
||||
| Product promotion | 2–3 min | 500–800 | 3–4 |
|
||||
| Presentation / Speech | 5–10 min | 1200–2500 | 5–8 |
|
||||
| Hosting script | Per agenda | Per segment | Per segment |
|
||||
|
||||
### Scene-Specific Prohibitions
|
||||
|
||||
1. **No spec dumping:** Do not list all product specifications in tables. Select 2–3 most persuasive data points and express them through scenarios
|
||||
2. **No information contradiction:** Model numbers, prices, data appearing multiple times must be perfectly consistent
|
||||
3. **No report tone:** No "in conclusion", "research indicates", "as mentioned above" — this is spoken word
|
||||
4. **No lengthy citations:** Broadcast scripts do not need quotes, footnotes, or references
|
||||
5. **No dense layout:** Paragraphs must have visible spacing — no screen-filling text walls
|
||||
|
||||
### Product Promotion Specific Rules
|
||||
- **Opening:** Lead with pain point / scenario ("Does your washing machine still smell after a cycle?"), not self-introduction
|
||||
- **Product intro:** Compare only 1–2 competitive dimensions at a time — not a full review
|
||||
- **Price anchor:** State original/market price first, then discount price — create contrast
|
||||
- **CTA:** Explicitly state the action ("Click the link below", "Type 1 in comments")
|
||||
|
||||
---
|
||||
|
||||
## 5. Palette
|
||||
|
||||
Broadcast scripts use clean, simple colors — no complex visual design needed:
|
||||
|
||||
```js
|
||||
const P = {
|
||||
primary: "#1A1A1A", // Title
|
||||
body: "#333333", // Body
|
||||
secondary: "#666666", // Notes
|
||||
accent: "#E85D3A", // Key highlight (warm, energetic)
|
||||
surface: "#FFF8F5", // Background (if needed)
|
||||
};
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Scene-Specific Quality Checks
|
||||
|
||||
In addition to universal checks (see `references/common-rules.md`):
|
||||
|
||||
- [ ] Total word count within target range (not exceeding)
|
||||
- [ ] Each core paragraph has only 1–2 selling points (no dumping)
|
||||
- [ ] Conversational tone present (not report/formal style)
|
||||
- [ ] Information consistent throughout (model, price, data — no contradictions)
|
||||
- [ ] Paragraph spacing sufficient (visually not crowded)
|
||||
- [ ] Clear attention-grabbing opening + closing CTA
|
||||
698
skills/docx/scenes/exam.md
Executable file
698
skills/docx/scenes/exam.md
Executable file
@@ -0,0 +1,698 @@
|
||||
# Scene: Exam Paper
|
||||
|
||||
## Overview
|
||||
|
||||
Exam papers are among the most critical document types in education. Unlike general documents, they require high precision in layout, print compatibility, and subject-specific formatting. This specification covers the complete workflow from page framework to subject-specific features.
|
||||
|
||||
→ Universal prohibitions — see `references/common-rules.md`
|
||||
→ **Note:** Exam papers use their OWN font/layout specs (not Profile A defaults). All text is pure black/white/grey for photocopy clarity.
|
||||
|
||||
---
|
||||
|
||||
## 1. Page Setup & Framework
|
||||
|
||||
### Paper Specifications
|
||||
|
||||
| Type | Paper | Orientation | Use Case |
|
||||
|------|-------|-------------|----------|
|
||||
| Practice / Unit quiz | A4 | Portrait | Daily practice, homework, quizzes |
|
||||
| Formal exam | A3 | Landscape + 2-column | Midterm / final / standardized (requires OOXML) |
|
||||
| Answer sheet | A4 | Portrait | Standalone answer card |
|
||||
|
||||
### Margins
|
||||
|
||||
```js
|
||||
// A4 portrait — no seal line
|
||||
page: { size: { width: 11906, height: 16838 },
|
||||
margin: { top: 850, bottom: 850, left: 1200, right: 1200 } }
|
||||
|
||||
// A4 portrait — with seal line (left binding area reserved)
|
||||
page: { size: { width: 11906, height: 16838 },
|
||||
margin: { top: 850, bottom: 850, left: 2200, right: 850 } }
|
||||
|
||||
// A3 landscape dual-column (requires OOXML)
|
||||
// ⚠️ A3 dual-column may render slightly differently in WPS vs Word. Test in both before batch printing.
|
||||
page: { size: { width: 23812, height: 16838, orientation: PageOrientation.LANDSCAPE },
|
||||
margin: { top: 850, bottom: 850, left: 2200, right: 850 } }
|
||||
```
|
||||
|
||||
### Section Handling
|
||||
|
||||
Different parts should use section breaks (`SectionType.NEXT_PAGE`):
|
||||
- **Header area (full-width):** Title, instructions, score table (no columns)
|
||||
- **Content area:** Questions (may use columns)
|
||||
- **Composition / answer sheet:** Independent section, independent format
|
||||
- **Attachment pages:** Large maps/diagrams for geography/biology can be separate pages
|
||||
|
||||
```js
|
||||
sections: [
|
||||
{ properties: { /* Header section — no columns */ }, children: [...] },
|
||||
{ properties: { type: SectionType.CONTINUOUS, column: { count: 2, space: 720 } }, children: [...] },
|
||||
{ properties: { type: SectionType.NEXT_PAGE }, children: [...] }, // Composition
|
||||
]
|
||||
```
|
||||
|
||||
### Template-First Principle
|
||||
|
||||
⚠️ **Build framework first, fill content second.** Before writing questions, determine:
|
||||
1. Paper size + margins
|
||||
2. Whether seal line is needed
|
||||
3. Whether columns are used
|
||||
4. Question type structure and point allocation
|
||||
5. Whether composition grid / answer sheet is needed
|
||||
|
||||
---
|
||||
|
||||
## 2. Seal Line & Student Information Area
|
||||
|
||||
### When to Use Seal Line
|
||||
|
||||
| Scenario | Seal Line | Student Info Position |
|
||||
|----------|-----------|---------------------|
|
||||
| Formal standardized exam | ✅ Required | Left vertical info column |
|
||||
| Midterm / Final | ✅ Recommended | Left vertical info column |
|
||||
| Unit quiz | ❌ Optional | Header horizontal info row |
|
||||
| Daily practice | ❌ Skip | Header horizontal info row |
|
||||
|
||||
### Seal Line Implementation
|
||||
|
||||
#### Method 1: Header horizontal prompt (simple)
|
||||
```js
|
||||
headers: { default: new Header({ children: [
|
||||
new Paragraph({ alignment: AlignmentType.CENTER,
|
||||
children: [new TextRun({
|
||||
text: ".............. Seal ...... Line ...... Do ...... Not ...... Answer ...... Inside ..............",
|
||||
size: 16, color: "999999", font: "SimSun" })] })
|
||||
] }) }
|
||||
```
|
||||
|
||||
#### Method 2: Vertical text box (OOXML advanced)
|
||||
```xml
|
||||
<w:txbxContent>
|
||||
<w:p><w:pPr><w:jc w:val="center"/></w:pPr>
|
||||
<w:r><w:rPr><w:sz w:val="18"/><w:color w:val="999999"/></w:rPr>
|
||||
<w:t>Name:________ Class:________ ID:________</w:t></w:r>
|
||||
</w:p>
|
||||
<w:p><w:r><w:rPr><w:sz w:val="16"/><w:color w:val="CCCCCC"/></w:rPr>
|
||||
<w:t>- - - - - - - - - Seal Line - - - - - - - - -</w:t></w:r>
|
||||
</w:p>
|
||||
</w:txbxContent>
|
||||
```
|
||||
|
||||
### Student Info Row
|
||||
|
||||
```js
|
||||
// Horizontal info row (when no seal line) — borderless 3-column table
|
||||
new Table({
|
||||
alignment: AlignmentType.CENTER, columnWidths: [2800, 2800, 2800],
|
||||
rows: [new TableRow({ children: [
|
||||
cell("Name: ______________"),
|
||||
cell("Class: ______________", AlignmentType.CENTER),
|
||||
cell("ID: ______________", AlignmentType.RIGHT),
|
||||
] })]
|
||||
})
|
||||
```
|
||||
|
||||
Fill lines should be moderate length (10–14 underscore chars). Label order: Name → Class → Student ID.
|
||||
|
||||
---
|
||||
|
||||
## 3. Paper Header & Title Area
|
||||
|
||||
### Structure
|
||||
|
||||
```
|
||||
School name (16pt SimHei, centered)
|
||||
Exam title (14pt SimHei, centered) — e.g., "2025–2026 Academic Year Second Semester Midterm"
|
||||
Subject title (14pt SimHei, centered) — e.g., "Grade 7 Mathematics"
|
||||
Student info row
|
||||
Instructions (10pt SimSun, centered, grey)
|
||||
Score table (as needed)
|
||||
```
|
||||
|
||||
### Font Specifications
|
||||
|
||||
| Element | Font | Size | Style |
|
||||
|---------|------|------|-------|
|
||||
| School name | SimHei | 16pt (size:32) | Bold, centered |
|
||||
| Exam title | SimHei | 14pt (size:28) | Bold, centered |
|
||||
| Subject title | SimHei | 14pt (size:28) | Bold, centered |
|
||||
| Instructions | SimSun | 10pt (size:20) | Grey 333333, centered |
|
||||
| Student info | SimSun | 10.5pt (size:21) | Normal |
|
||||
|
||||
### Instructions Content
|
||||
|
||||
Should include: total score, exam duration, answer method, special requirements (e.g., calculator allowed).
|
||||
|
||||
### Score Table
|
||||
- Header row: light grey background F0F0F0, centered
|
||||
- Columns: Question type | Section names... | Total
|
||||
- Rows: Points | Section points... | Total points
|
||||
- Row: Score | blank... | blank
|
||||
- Table centered, 80% page width
|
||||
|
||||
⚠️ **Header area should not be too full** — title + info + instructions + score table should not exceed 1/3 of the page.
|
||||
|
||||
---
|
||||
|
||||
## 4. Content Layout Rules
|
||||
|
||||
### Color Palette
|
||||
|
||||
```js
|
||||
// Exam papers use only black/white/grey for clear photocopying
|
||||
const C = {
|
||||
title: "000000", body: "000000", section: "333333",
|
||||
seal: "999999", answerLine: "CCCCCC", headerBg: "F0F0F0", gridLine: "DDDDDD",
|
||||
};
|
||||
```
|
||||
|
||||
### Column Usage
|
||||
|
||||
| Subject / Question Type | Recommendation |
|
||||
|------------------------|----------------|
|
||||
| Math multiple choice + fill-in | ✅ Suitable for columns |
|
||||
| Physics multiple choice | ✅ Suitable for columns |
|
||||
| Chinese reading / composition | ❌ Not suitable |
|
||||
| English cloze / reading | ❌ Not suitable |
|
||||
| History source-based | ❌ Not suitable |
|
||||
| Geography map reading | ❌ Not suitable |
|
||||
|
||||
### Question Numbering
|
||||
|
||||
Entire paper uses consistent three-level numbering:
|
||||
- **Major sections:** I, II, III, IV... (Chinese: 一、二、三、四…)
|
||||
- **Questions:** 1. 2. 3. ... (Arabic + period)
|
||||
- **Sub-questions:** (1) (2) (3) ... (parenthesized)
|
||||
|
||||
⚠️ **No extra symbols before question numbers** (no `•`, `▸`, `▪`, `-`, `*`). The number itself is the only marker. **Never use docx numbering/bullet list styles** for question numbers — must use plain TextRun manual numbering.
|
||||
|
||||
```js
|
||||
// ✅ Correct — plain TextRun manual numbering
|
||||
new Paragraph({ spacing: { before: 120, after: 60, line: 360 },
|
||||
children: [new TextRun({ text: `${i+1}. ${question}`, size: 21, font: { eastAsia: "SimSun" } })] })
|
||||
|
||||
// ❌ Wrong — numbering causes Word to add bullets
|
||||
new Paragraph({ numbering: { reference: "xxx", level: 0 }, // ← Forbidden!
|
||||
children: [new TextRun({ text: question })] })
|
||||
```
|
||||
|
||||
### Question Spacing
|
||||
|
||||
```js
|
||||
sectionTitle: { before: 300, after: 150 } // Major section headers
|
||||
question: { before: 120, after: 80 } // Between questions
|
||||
subQuestion: { before: 60, after: 40 } // Between sub-questions
|
||||
```
|
||||
|
||||
### Page Break Control
|
||||
|
||||
⚠️ Key principles:
|
||||
- **Question stem and answer area must not split** across pages
|
||||
- **Source material and questions on same page**
|
||||
- **Figures adjacent to their questions**
|
||||
- **Avoid orphan lines** — question stem, options, answer area appear as a group
|
||||
|
||||
```js
|
||||
new Paragraph({ keepNext: true, keepLines: true, children: [...] })
|
||||
```
|
||||
|
||||
⚠️ **Answer question page break rule (mandatory):**
|
||||
|
||||
Complete combination (stem + figure + answer lines) must be considered as a unit. If remaining space cannot fit stem + figure + at least 3 answer lines, push entire question to next page.
|
||||
|
||||
Use `keepNext: true` to chain: stem → figure → first 3 answer lines.
|
||||
|
||||
---
|
||||
|
||||
## 5. Font & Paragraph Standards
|
||||
|
||||
### Underline Formatting for "Underlined Parts" (Mandatory)
|
||||
|
||||
When a question references "underlined part" (划线部分), the relevant text MUST use actual underline formatting (`underline: { type: UnderlineType.SINGLE }`). **Never** show "划线部分为 XXX" as plain text annotation — the underline must be visually rendered.
|
||||
|
||||
```js
|
||||
// ✅ Correct — actual underline on the referenced text
|
||||
new Paragraph({ children: [
|
||||
new TextRun({ text: "1. It is ", size: 21, font: { ascii: "Times New Roman" } }),
|
||||
new TextRun({ text: "a butterfly", size: 21, font: { ascii: "Times New Roman" },
|
||||
underline: { type: UnderlineType.SINGLE, color: "000000" } }),
|
||||
new TextRun({ text: ". (Ask about the underlined part)", size: 21, font: { ascii: "Times New Roman" } }),
|
||||
]})
|
||||
|
||||
// ❌ Wrong — underlined part described as annotation text
|
||||
new TextRun({ text: "1. It is a butterfly. (对划线部分提问) 注：划线部分为 a butterfly" })
|
||||
```
|
||||
|
||||
### Font Hierarchy
|
||||
|
||||
| Element | Font | Size | Style |
|
||||
|---------|------|------|-------|
|
||||
| Section title | SimHei | 11pt (size:22) | Bold |
|
||||
| Question content | SimSun | 10.5pt (size:21) | Normal |
|
||||
| Points annotation | SimSun | 10pt (size:20) | In parentheses |
|
||||
| Reading material | KaiTi/SimSun | 10.5pt (size:21) | KaiTi to differentiate |
|
||||
| Notes/source | SimSun | 9pt (size:18) | Grey 666666 |
|
||||
| Seal line | SimSun | 8pt (size:16) | Grey 999999 |
|
||||
| Page number | SimSun | 9pt (size:18) | Centered |
|
||||
|
||||
### Line Spacing
|
||||
```js
|
||||
line: 360 // ~1.5x for readability
|
||||
answerLine: 500 // Answer line spacing for writing room
|
||||
```
|
||||
|
||||
### Paragraph Rules
|
||||
- ⚠️ **Never use consecutive returns for whitespace** — use `spacing.before/after`
|
||||
- Chinese questions use Chinese punctuation; English materials use English punctuation
|
||||
- Mixed CN/EN: use Times New Roman or Calibri for English text
|
||||
|
||||
---
|
||||
|
||||
## 6. Multiple Choice Layout
|
||||
|
||||
### Core Rule
|
||||
|
||||
⚠️ **Options must NEVER be aligned with spaces!** Must use borderless tables.
|
||||
|
||||
### Option Layout — Borderless Table
|
||||
|
||||
```js
|
||||
// Short options: 4 columns in 1 row
|
||||
new Table({
|
||||
columnWidths: [2200, 2200, 2200, 2200],
|
||||
rows: [new TableRow({ children: ["A","B","C","D"].map((label, i) =>
|
||||
new TableCell({ borders: NBs, width: { size: 2200, type: WidthType.DXA },
|
||||
margins: { top: 0, bottom: 0, left: 60, right: 60 },
|
||||
children: [new Paragraph({ spacing: { before: 0, after: 0 },
|
||||
children: [new TextRun({ text: `${label}. ${options[i]}`, size: 21, font: "SimSun" })] })]
|
||||
})
|
||||
) })]
|
||||
})
|
||||
// Medium options: 2 columns, 2 rows
|
||||
// Long options: 1 column, 4 rows
|
||||
```
|
||||
|
||||
### Option Length Detection
|
||||
```js
|
||||
function getOptionLayout(options) {
|
||||
const maxLen = Math.max(...options.map(o => o.length));
|
||||
if (maxLen <= 6) return "4col";
|
||||
if (maxLen <= 15) return "2col";
|
||||
return "1col";
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. Fill-in-the-Blank Layout
|
||||
|
||||
```js
|
||||
// Blank line length matches expected answer:
|
||||
// Short answer (number/word): 8 underscores
|
||||
// Medium (phrase): 14 underscores
|
||||
// Long (sentence): 20 underscores
|
||||
new Paragraph({ spacing: { before: 140, after: 80, line: 400 },
|
||||
children: [new TextRun({ text: `${num}. Question text ________________.`, size: 21, font: "SimSun" })] })
|
||||
```
|
||||
|
||||
⚠️ Fill-in lines must not break across lines — if line is too long, put the blank on the next line.
|
||||
|
||||
---
|
||||
|
||||
## 8. Short Answer / Problem-Solving Layout
|
||||
|
||||
### Question + Points
|
||||
```js
|
||||
new Paragraph({ spacing: { before: 200, after: 60, line: 360 }, keepNext: true,
|
||||
children: [new TextRun({ text: `${num}. (${points} pts) ${question}`, size: 21, font: "SimSun" })] })
|
||||
```
|
||||
|
||||
### Answer Lines
|
||||
```js
|
||||
// Light grey answer lines (CCCCCC), NOT black
|
||||
// ⚠️ Answer lines are ONLY for writing space within each question — never as dividers between questions
|
||||
function answerLines(count) {
|
||||
return Array(count).fill(null).map(() =>
|
||||
new Paragraph({ spacing: { before: 0, after: 0, line: 500 },
|
||||
borders: { bottom: { style: BorderStyle.SINGLE, size: 1, color: "CCCCCC" } },
|
||||
children: [new TextRun({ text: " ", size: 21 })] })
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
⚠️ **Separation between questions:**
|
||||
|
||||
Use **only spacing** (`spacing.before: 200`) for visual separation between questions. **Forbidden:**
|
||||
- ❌ Grey horizontal lines (borders)
|
||||
- ❌ Color block dividers (Table-simulated separators)
|
||||
- ❌ Symbol dividers (e.g., `───────`)
|
||||
- ❌ Any visual separator decoration
|
||||
|
||||
### Answer Space vs. Points
|
||||
|
||||
| Points | Suggested Lines | Description |
|
||||
|--------|----------------|-------------|
|
||||
| 2–4 | 3–4 lines | Simple calculation / short answer |
|
||||
| 5–8 | 6–8 lines | Medium problem |
|
||||
| 10–12 | 8–10 lines | Complex problem |
|
||||
| 14–20 | 10–14 lines | Comprehensive / essay question |
|
||||
|
||||
---
|
||||
|
||||
## 9. Source-Based / Reading Question Layout
|
||||
|
||||
### Material vs. Question Separation
|
||||
|
||||
```js
|
||||
// Material area — indented + KaiTi to differentiate
|
||||
new Paragraph({ indent: { left: 420, right: 420 }, spacing: { before: 100, after: 100, line: 380 },
|
||||
children: [new TextRun({ text: materialText, size: 21, font: "KaiTi" })] })
|
||||
// Source attribution
|
||||
new Paragraph({ alignment: AlignmentType.RIGHT, indent: { right: 420 },
|
||||
children: [new TextRun({ text: "— from \"XXX\"", size: 18, color: "666666", font: "SimSun" })] })
|
||||
```
|
||||
|
||||
### Key Principles
|
||||
- Material title, source, body, and notes use different fonts
|
||||
- Long materials: increase line spacing (line: 380–400)
|
||||
- Material and corresponding questions on same page
|
||||
- Sub-question numbers (1)(2)(3) clearly correspond to material
|
||||
- **Data tables in materials MUST use proper docx `Table` objects** — never render tabular data as Markdown plain text (`| col | col |`). This includes statistics tables, climate data tables, comparison tables, and any structured data within question materials. Use bordered tables (see § 13 Table Usage Standards) with appropriate header row styling.
|
||||
|
||||
---
|
||||
|
||||
## 10. Composition / Writing Area
|
||||
|
||||
### Grid Count Calculation
|
||||
|
||||
⚠️ **Grid count must exceed required word count by 20–30%** (for title, paragraph indents, line breaks).
|
||||
|
||||
| Required Words | Min Grid Count | Recommended Layout |
|
||||
|---------------|---------------|-------------------|
|
||||
| 400 | 500 | 25 rows × 20 cols |
|
||||
| 600 | 750 | 38 rows × 20 cols |
|
||||
| 800 | 1000 | 50 rows × 20 cols |
|
||||
| 1000 | 1250 | 63 rows × 20 cols |
|
||||
|
||||
```js
|
||||
function calcGridSize(requiredWords, colsPerRow = 20) {
|
||||
const totalCells = Math.ceil(requiredWords * 1.25);
|
||||
const rows = Math.ceil(totalCells / colsPerRow);
|
||||
return { rows, colsPerRow, totalCells: rows * colsPerRow };
|
||||
}
|
||||
```
|
||||
|
||||
### Chinese Composition Grid
|
||||
|
||||
```js
|
||||
function compositionGrid(rows, colsPerRow) {
|
||||
const cellSize = Math.floor(8800 / colsPerRow);
|
||||
return new Table({
|
||||
columnWidths: Array(colsPerRow).fill(cellSize),
|
||||
rows: Array(rows).fill(null).map(() =>
|
||||
new TableRow({
|
||||
height: { value: cellSize, rule: HeightRule.EXACT },
|
||||
children: Array(colsPerRow).fill(null).map(() =>
|
||||
new TableCell({ borders: thinBs("DDDDDD"), width: { size: cellSize, type: WidthType.DXA },
|
||||
children: [new Paragraph({ children: [] })] })
|
||||
)
|
||||
})
|
||||
)
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
### English Writing Area (Horizontal Lines) — MANDATORY for English Writing Questions
|
||||
|
||||
⚠️ **Every English writing/composition question MUST include ruled horizontal lines.** A blank area without lines is FORBIDDEN — students need lines to write on.
|
||||
|
||||
```js
|
||||
function writingLines(count) {
|
||||
return Array(count).fill(null).map(() =>
|
||||
new Paragraph({ spacing: { before: 0, after: 0, line: 560 },
|
||||
borders: { bottom: { style: BorderStyle.SINGLE, size: 1, color: "CCCCCC" } },
|
||||
children: [new TextRun({ text: " ", size: 21 })] })
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
**Line count by word requirement:**
|
||||
| Required Words | Lines |
|
||||
|---------------|-------|
|
||||
| ≤50 | 8 |
|
||||
| 50–80 | 10 |
|
||||
| 80–120 | 12 |
|
||||
| 120+ | 15 |
|
||||
|
||||
**Rules:**
|
||||
1. Lines must appear immediately after the writing prompt paragraph
|
||||
2. Line color: light grey `CCCCCC` (print-friendly, not visually heavy)
|
||||
3. Line spacing: `line: 560` (provides adequate writing room)
|
||||
4. Chinese composition uses grid (`compositionGrid`), English uses lines (`writingLines`) — never mix them up
|
||||
```
|
||||
|
||||
### Composition Area Requirements
|
||||
- Independent section or clear separation
|
||||
- Title space reserved (for self-chosen topics)
|
||||
- Word count prompt visible ("No fewer than 800 words" / "About 120 words")
|
||||
- Grid/line colors light — must not interfere with writing
|
||||
- Pages continuous, not split
|
||||
|
||||
---
|
||||
|
||||
## 11. Answer Key (参考答案)
|
||||
|
||||
### Output Rules
|
||||
|
||||
1. **Default (user does not request answers in the same file):** Generate the answer key as a **separate .docx file** (e.g., `exam.docx` + `exam_answers.docx`). This prevents students from accidentally seeing answers.
|
||||
2. **User explicitly requests answers in the same file:** Place the answer key on an **independent page** using `SectionType.NEXT_PAGE`. Answer key MUST NOT appear on the same page as any exam question.
|
||||
|
||||
### Separate File Format (Default)
|
||||
|
||||
The answer key file should include:
|
||||
- Title: "《{exam title}》参考答案" (SimHei, 14pt/size:28, bold, centered)
|
||||
- Same question numbering as the exam
|
||||
- Concise answers (letter choices, key words, short solutions)
|
||||
- Font: SimSun 10.5pt (size: 21)
|
||||
|
||||
### Same File Format (When User Requests)
|
||||
|
||||
```js
|
||||
// Answer key as a separate section — MUST use SectionType.NEXT_PAGE
|
||||
{
|
||||
properties: { type: SectionType.NEXT_PAGE,
|
||||
page: { margin: { top: 850, bottom: 850, left: 1200, right: 1200 } } },
|
||||
children: [
|
||||
new Paragraph({
|
||||
alignment: AlignmentType.CENTER, spacing: { after: 300 },
|
||||
children: [new TextRun({ text: "参考答案", size: 28, bold: true,
|
||||
font: { eastAsia: "SimHei" } })],
|
||||
}),
|
||||
// ... answer content paragraphs
|
||||
],
|
||||
}
|
||||
```
|
||||
|
||||
### Rules
|
||||
1. ⚠️ **Never place answer content directly after the last question without a page/section break**
|
||||
2. Answer content should be concise — no answer lines, no grid, plain text only
|
||||
3. Calculation/proof questions: show key steps, not just final answer
|
||||
4. If the exam has figures, answers may reference "see Figure X" without re-embedding
|
||||
|
||||
---
|
||||
|
||||
## 12. Figures & Illustrations
|
||||
|
||||
### Image Insertion
|
||||
```js
|
||||
new Paragraph({ alignment: AlignmentType.CENTER, spacing: { before: 100, after: 60 },
|
||||
children: [new ImageRun({ data: imageBuffer, transformation: { width: 300, height: 200 }, type: "png" })] })
|
||||
new Paragraph({ alignment: AlignmentType.CENTER, spacing: { after: 100 },
|
||||
children: [new TextRun({ text: "(Figure 1)", size: 18, color: "666666", font: "SimSun" })] })
|
||||
```
|
||||
|
||||
### Key Principles
|
||||
- Images set as inline (default) to prevent floating
|
||||
- Resolution sufficient for print clarity
|
||||
- **B&W print compatible:** images must remain distinguishable when printed in grayscale
|
||||
- Figure numbers and captions complete
|
||||
- Figures adjacent to corresponding questions
|
||||
- Maps must have: scale bar, north arrow, legend
|
||||
- Coordinate graphs must have: axis labels, tick marks, units
|
||||
|
||||
### ⚠️ Figure-Text Order (Strictly Enforced)
|
||||
|
||||
**For questions with figures, element order must be:**
|
||||
```
|
||||
1. Question stem (keepNext: true)
|
||||
2. Figure (centered, keepNext: true)
|
||||
3. Answer lines / answer area
|
||||
```
|
||||
|
||||
**Forbidden:** answer lines between stem and figure, or figure after answer lines.
|
||||
|
||||
### Figure Content Matching
|
||||
- **Figures must be semantically consistent with question stem:** if question says "triangle ABC", figure must label vertices A, B, C
|
||||
- Geometry annotations must match described angles, side lengths
|
||||
- Function graphs must mark key points mentioned in the question
|
||||
- Physics experiment diagrams must match described apparatus
|
||||
- Figure width: geometry ≤ 50% page width, data/experiment ≤ 70%
|
||||
|
||||
### ⚠️ Figure Diversity Rule (Mandatory)
|
||||
|
||||
**No duplicate figures in the entire paper.** Even if two questions involve the same type (e.g., both triangles), each must have a distinct figure:
|
||||
1. Different labels (different vertex letters, angles, side lengths)
|
||||
2. Different shapes (acute vs. right vs. obtuse triangle)
|
||||
3. Different styling (if applicable)
|
||||
|
||||
If using matplotlib, each call must use **different parameters and data** — never copy the same generation code.
|
||||
|
||||
### Subject-Specific Figure Requirements
|
||||
|
||||
| Subject | Common Types | Special Requirements |
|
||||
|---------|-------------|---------------------|
|
||||
| Math | Geometry, functions, coordinates | No distortion, clear labels |
|
||||
| Physics | Circuits, mechanics, apparatus | Standard symbols, correct arrows |
|
||||
| Chemistry | Apparatus, molecular structures | Reagent names labeled |
|
||||
| Biology | Cell, organ, ecosystem diagrams | Labels not too small |
|
||||
| Geography | Maps, contour lines, statistics | Legend + scale + north arrow |
|
||||
|
||||
---
|
||||
|
||||
## 13. Formulas & Special Symbols
|
||||
|
||||
### Formulas
|
||||
Math/physics/chemistry formulas use **LaTeX → docx-js Math mapping** (see `references/math-formulas.md`):
|
||||
- Basic (fractions, sub/superscript, roots) → docx-js Math components
|
||||
- Complex (3+ nesting, matrices) → matplotlib PNG fallback
|
||||
- Never hand-type Unicode formula approximations
|
||||
|
||||
### Common Unicode Math Symbols
|
||||
```
|
||||
× ÷ ± ∓ ≠ ≈ ≤ ≥ ∞ √ ∑ ∏ ∫ ∂ ∆ ∇
|
||||
α β γ δ ε θ λ μ π σ φ ω
|
||||
⊂ ⊃ ∈ ∉ ∪ ∩ ∅ ∀ ∃
|
||||
→ ← ↑ ↓ ⇒ ⇔ ° ′ ″ ‰ ² ³ ⁴ ⁿ ₁ ₂ ₃
|
||||
```
|
||||
|
||||
### Chemical Formulas
|
||||
Subscripts/superscripts must be correct: H₂O, CO₂, Fe₂O₃, Ca(OH)₂
|
||||
Reaction arrows: → ⇌ ↑ ↓
|
||||
|
||||
---
|
||||
|
||||
## 14. Table Usage Standards
|
||||
|
||||
### Borderless Tables (for alignment)
|
||||
For: option alignment, info rows, question number + points alignment
|
||||
```js
|
||||
const NB = { style: BorderStyle.NONE, size: 0, color: "FFFFFF" };
|
||||
const NBs = { top: NB, bottom: NB, left: NB, right: NB };
|
||||
```
|
||||
|
||||
### Bordered Tables (for data display)
|
||||
For: score tables, data tables, statistics
|
||||
```js
|
||||
const thinB = (c="000000") => ({ style: BorderStyle.SINGLE, size: 1, color: c });
|
||||
const thinBs = (c="000000") => ({ top: thinB(c), bottom: thinB(c), left: thinB(c), right: thinB(c) });
|
||||
```
|
||||
|
||||
### Table Standards
|
||||
- Cell padding moderate (margins: top/bottom 40–60, left/right 60–80)
|
||||
- Consistent border thickness
|
||||
- Header row: light grey F0F0F0 background
|
||||
- Avoid cross-page tables
|
||||
- Tables centered (`alignment: AlignmentType.CENTER`)
|
||||
|
||||
---
|
||||
|
||||
## 15. Headers & Footers
|
||||
|
||||
### Page Numbers
|
||||
```js
|
||||
footers: { default: new Footer({ children: [
|
||||
new Paragraph({ alignment: AlignmentType.CENTER,
|
||||
children: [
|
||||
new TextRun({ children: [PageNumber.CURRENT], size: 18, font: "SimSun" }),
|
||||
] })
|
||||
] }) }
|
||||
```
|
||||
|
||||
⚠️ **Denominator FORBIDDEN** — never use `PageNumber.TOTAL_PAGES` or "Page X of Y". Show only current page number.
|
||||
|
||||
### Headers
|
||||
- May contain seal line prompt or subject name
|
||||
- Small font (8–9pt), grey color (999999)
|
||||
- Should not be visually heavy — must not compete with content
|
||||
|
||||
---
|
||||
|
||||
## 16. Subject-Specific Standards
|
||||
|
||||
### Chinese Language
|
||||
- Reading, classical poetry, composition: **no columns**
|
||||
- Poetry preserves original line breaks
|
||||
- Classical text needs annotation area (smaller font, indented)
|
||||
- Composition grid in independent section, grid count via `calcGridSize` (800 words → 50×20 = 1000 cells)
|
||||
- Dictation questions: horizontal lines, moderate length
|
||||
- Reading materials: use KaiTi to differentiate
|
||||
|
||||
### Mathematics
|
||||
- Multiple choice, fill-in: suitable for neat layout
|
||||
- Formulas: Unicode symbols or OOXML
|
||||
- Geometry/function graphs must be clear, undistorted
|
||||
- Problem-solving: sufficient working space
|
||||
- Coordinate graphs: labeled axes, tick marks
|
||||
|
||||
### English
|
||||
- English font: Times New Roman, moderate character spacing
|
||||
- Cloze: numbers in text, options after passage
|
||||
- Reading comprehension: material + questions as groups
|
||||
- Writing area: horizontal lines, not grid
|
||||
- Listening (if any): numbers aligned with options
|
||||
|
||||
### Physics / Chemistry / Biology
|
||||
- Experiment/apparatus diagrams must be clear and accurate
|
||||
- Unit symbols standardized (m/s, kg, mol/L, etc.)
|
||||
- Chemical formula subscripts correct
|
||||
- Calculation and experiment analysis: sufficient answer space
|
||||
- Biology structure diagrams: labels not too small
|
||||
|
||||
### History / Politics
|
||||
- Source-based questions are lengthy — **no columns**
|
||||
- Dates, figures, events clearly labeled
|
||||
- Essay questions: more whitespace than multiple choice
|
||||
- Historical sources cite provenance
|
||||
- Chart materials in logical order
|
||||
|
||||
### Geography
|
||||
- Maps are the focus — must be clear
|
||||
- Legend, scale bar, north arrow required
|
||||
- Map and question close together — avoid page turns
|
||||
- Map reading questions: balance figure and text space
|
||||
- Contour line values clearly labeled
|
||||
|
||||
---
|
||||
|
||||
## Final Review Checklist
|
||||
|
||||
After generating an exam paper, check every item:
|
||||
|
||||
- [ ] Question numbers sequential, points correct, total correct
|
||||
- [ ] Question stems match options / materials / illustrations one-to-one
|
||||
- [ ] **Figures come after stem, before answer area** (strict order)
|
||||
- [ ] **Figure content matches question semantics** (labels, symbols match)
|
||||
- [ ] **Composition grid count ≥ required words × 1.25** (800 words → at least 1000 cells)
|
||||
- [ ] Options aligned with borderless tables (not spaces)
|
||||
- [ ] No wrong pages, missing pages, **no extra blank pages**
|
||||
- [ ] Images / tables / formulas positioned correctly
|
||||
- [ ] **No Markdown table syntax in document** — all data tables use proper docx Table objects
|
||||
- [ ] Fonts, sizes, line spacing consistent
|
||||
- [ ] Answer space matches difficulty and point value
|
||||
- [ ] Clear when printed in B&W
|
||||
- [ ] Subject-specific layout handled properly
|
||||
- [ ] Seal line / page numbers / headers formatted correctly
|
||||
- [ ] Header info complete (school, subject, duration, total score)
|
||||
- [ ] **No extra PageBreak at end of last section**
|
||||
- [ ] **Answer key is either a separate file (default) or on a separate page (if user requested in same file)** — never on the same page as questions
|
||||
411
skills/docx/scenes/official-doc.md
Executable file
411
skills/docx/scenes/official-doc.md
Executable file
@@ -0,0 +1,411 @@
|
||||
# Scene: Official Document (Government Notice / Letter / Reply / Minutes)
|
||||
|
||||
## Goal
|
||||
|
||||
Generate a complete, formal, properly structured official document ready for Word delivery. Must simultaneously meet:
|
||||
- Correct document type, complete structure, clear elements
|
||||
- Formal government register, stable hierarchy, reliable layout
|
||||
- Ready for approval, circulation, filing, issuance, or formal internal communication
|
||||
|
||||
**Forbidden:** Producing outlines-only / sample paragraphs / writing advice / half-finished drafts; outputting chat-style explanations.
|
||||
|
||||
→ Placeholder convention & universal prohibitions — see `references/common-rules.md`
|
||||
→ **Note:** This scene uses its OWN font and layout specs (not Profile A defaults), because official documents follow GB/T 9704 standards.
|
||||
|
||||
---
|
||||
|
||||
## Scope & Document Type Boundaries
|
||||
|
||||
This scene covers:
|
||||
1. **Notice** — assigning work, communicating requirements, forwarding documents
|
||||
2. **Official Letter** — between non-subordinate organizations: negotiation, inquiry, assistance requests, replies
|
||||
3. **Reply (to Request)** — superior authority answering a subordinate's formal request
|
||||
4. **Meeting Minutes** — recording key outcomes and agreed items
|
||||
|
||||
**Important boundaries:**
|
||||
- "Red header" is a format/layout, not a document type — it typically carries notices, letters, or replies
|
||||
- **Not all official documents need red headers / document numbers / colophons** — only enable when user explicitly requests "red header format", "GB/T 9704 format", or "formal issuance format"
|
||||
- Internal enterprise notices, business letters, meeting minutes often do NOT use full GB/T standard format
|
||||
- This scene does NOT cover: speeches, press releases, promotional materials, papers, summary reports, contracts, or legal opinions
|
||||
|
||||
---
|
||||
|
||||
## Document Type Routing
|
||||
|
||||
```js
|
||||
function selectOfficialType(keywords, purpose) {
|
||||
if (/minutes|meeting/.test(keywords)) return "minutes";
|
||||
if (/reply|respond to request/.test(keywords)) return "reply";
|
||||
if (/letter|inquiry|negotiation/.test(keywords)) return "letter";
|
||||
return "notice"; // default
|
||||
}
|
||||
```
|
||||
|
||||
### Red Header Activation
|
||||
|
||||
```js
|
||||
function needsRedHeader(userRequest) {
|
||||
// Only activate when explicitly requested
|
||||
return /red header|GB\/T 9704|formal issuance|official format/.test(userRequest);
|
||||
}
|
||||
```
|
||||
|
||||
**Rules:**
|
||||
- `needsRedHeader = true` → Enable red header, document number, colophon (full formal elements)
|
||||
- `needsRedHeader = false` → Maintain formal style but no mandatory red header; keep only title + addressee + body + signature
|
||||
|
||||
---
|
||||
|
||||
## Standard Template Structures
|
||||
|
||||
### Template A: Notice
|
||||
1. Red header area (if applicable)
|
||||
2. Document number (if applicable)
|
||||
3. Title
|
||||
4. Addressee
|
||||
5. Reason for issuance
|
||||
6. "The relevant matters are hereby notified as follows:"
|
||||
7. Notice items (expanded by hierarchy)
|
||||
8. Requirements
|
||||
9. Attachment notes (if any)
|
||||
10. Signature (if applicable)
|
||||
11. Date (if applicable)
|
||||
12. Colophon (if applicable)
|
||||
|
||||
**Closing phrase:** "This notice is hereby given." or "Please implement accordingly."
|
||||
|
||||
### Template B: Official Letter
|
||||
1. Red header area (if applicable)
|
||||
2. Document number (if applicable)
|
||||
3. Title
|
||||
4. Addressee
|
||||
5. Reason / reference to incoming letter
|
||||
6. Negotiation / inquiry / reply items
|
||||
7. Closing
|
||||
8. Signature (if applicable)
|
||||
9. Date (if applicable)
|
||||
10. Colophon (if applicable)
|
||||
|
||||
**Closing phrases:** "Please reply by letter." / "This letter is hereby sent." / "This is in reply."
|
||||
|
||||
### Template C: Reply
|
||||
1–11. Similar to Notice structure
|
||||
- Addressee is typically the single requesting organization
|
||||
- Must reference the incoming request document
|
||||
- "After review, the reply is as follows:"
|
||||
- Closing: "This is the reply."
|
||||
|
||||
### Template D: Meeting Minutes
|
||||
1. Title (meeting name + "Minutes")
|
||||
2. Meeting overview (time, place, chair, attendees)
|
||||
3. Agreed items
|
||||
4. Responsibility assignments / follow-up requirements (if applicable)
|
||||
5. Distribution scope (if applicable)
|
||||
|
||||
**Notes:**
|
||||
- Minutes record "agreed items", not a transcript of speeches
|
||||
- Minutes generally do NOT follow standard red header format
|
||||
- Unless user explicitly requests organizational template compliance
|
||||
|
||||
---
|
||||
|
||||
## Input Recognition & Completion
|
||||
|
||||
### Processing Rules
|
||||
1. If user provides a template, historical document, or organizational standard → **always follow it first**
|
||||
2. If information is incomplete → fill conservatively, formally, and appropriately for the government context
|
||||
3. **Never fabricate** policy bases, incoming document numbers, leadership directives, meeting decisions, or official organization names
|
||||
4. If critical info is missing → use standardized placeholders
|
||||
5. Never present a draft as if it were already formally issued
|
||||
|
||||
---
|
||||
|
||||
## Title Drafting Rules
|
||||
|
||||
The title is the most critical identifying element — must accurately, concisely reflect the issuing body, subject matter, and document type.
|
||||
|
||||
| Type | Format | Example |
|
||||
|------|--------|---------|
|
||||
| Notice | Issuing body + "regarding" + subject + "notice" | XX Municipal Government Notice on Issuing the XX Management Measures |
|
||||
| Letter | Issuing body + "regarding" + subject + "letter" | XX Company Letter Regarding Land Use for XX Project |
|
||||
| Reply | Issuing body + "regarding" + subject + "reply" | XX Bureau Reply on Approving Establishment of XX Branch |
|
||||
| Minutes | Meeting name + "minutes" | XX Company Third General Manager Meeting Minutes |
|
||||
|
||||
**Rules:**
|
||||
1. Title must specify the subject — no vague titles ("Notice on Relevant Matters")
|
||||
2. Titles generally do not use periods
|
||||
3. Title length should be moderate — avoid excessive length
|
||||
|
||||
---
|
||||
|
||||
## Addressee & CC
|
||||
|
||||
### Addressee
|
||||
1. The primary recipient of the document
|
||||
2. On its own line, between title and body
|
||||
3. Followed by full-width colon
|
||||
4. Replies typically address only one requesting organization
|
||||
5. Meeting minutes generally do not have a standard addressee
|
||||
|
||||
### CC (Carbon Copy)
|
||||
1. CC recipients are NOT addressees — do not mix them
|
||||
2. CC information typically appears in the colophon area
|
||||
3. Non-red-header documents should not mechanically add "CC:" lines
|
||||
|
||||
---
|
||||
|
||||
## Writing Style & Register
|
||||
|
||||
### Language Style
|
||||
1. Must be **solemn, plain, precise, rigorous, concise**
|
||||
2. **Forbidden:** Literary devices (metaphor, personification, hyperbole, rhetorical questions, exclamations)
|
||||
3. **Forbidden:** Vague expressions ("approximately", "recently", "relevant departments", "as soon as possible") — unless user explicitly requires vague wording
|
||||
4. Time, location, organization, scope, milestones should be as specific as possible
|
||||
5. No sloganeering filler or obvious "AI boilerplate" feel
|
||||
|
||||
### Common Phrase Patterns
|
||||
|
||||
**Purpose phrases:**
|
||||
- "In order to implement..."
|
||||
- "To further standardize..."
|
||||
- "To effectively carry out..."
|
||||
|
||||
**Basis phrases:**
|
||||
- "In accordance with the provisions of..."
|
||||
- "As required by..."
|
||||
- "Pursuant to relevant regulations"
|
||||
|
||||
**Transition phrases:**
|
||||
- Notice: "The relevant matters are hereby notified as follows:"
|
||||
- Letter: "The following is hereby communicated:"
|
||||
- Reply: "After review, the reply is as follows:"
|
||||
- Minutes: "The agreed items of the meeting are recorded as follows:"
|
||||
|
||||
**Closing phrases (must match document type):**
|
||||
- Notice: "This notice is hereby given."
|
||||
- Letter: "Please reply." / "This is hereby communicated." / "This is in reply."
|
||||
- Reply: "This is the reply."
|
||||
- Minutes: generally no fixed closing phrase
|
||||
|
||||
### Conciseness
|
||||
1. Use "because" not "due to the reason that..."
|
||||
2. Use "to" not "for the purpose of..."
|
||||
3. Name specific entities — not "relevant parties" or "related departments"
|
||||
4. Name responsible units — not "all units should ensure implementation" (vague ending)
|
||||
|
||||
---
|
||||
|
||||
## Body Hierarchy & Numbering
|
||||
|
||||
Official document body must strictly follow the standard Chinese government numbering system:
|
||||
|
||||
```
|
||||
I. General matters
|
||||
(1) Sub-items
|
||||
1. Specific points
|
||||
(1) Detail supplements
|
||||
```
|
||||
|
||||
Original Chinese numbering:
|
||||
```
|
||||
一、General matters
|
||||
（一）Sub-items
|
||||
1. Specific points
|
||||
（1）Detail supplements
|
||||
```
|
||||
|
||||
**Rules:**
|
||||
1. No level-skipping
|
||||
2. **Forbidden:** Markdown list markers (`-` `*`)
|
||||
3. No switching between numbering styles at the same level
|
||||
4. Level 1: major tasks; Level 2: sub-items; Levels 3–4: only when truly necessary
|
||||
|
||||
---
|
||||
|
||||
## Truthfulness & Caution
|
||||
1. **Never fabricate** issuing bodies, incoming organizations, document numbers, leadership directives, meeting decisions, or policy bases
|
||||
2. **Never** write "per the spirit of XX meeting" or "per XX directive" unless user explicitly provides these
|
||||
3. **Never** fabricate titles and numbers of referenced documents in replies or letters
|
||||
4. **Never** present a draft as already formally issued
|
||||
5. When information is insufficient → use placeholders, never pretend elements are complete
|
||||
|
||||
---
|
||||
|
||||
## Attachment Notes
|
||||
1. Placed after body text, before signature
|
||||
2. "Attachment:" followed by attachment name
|
||||
3. Multiple attachments: numbered sequentially (Attachment 1, Attachment 2...)
|
||||
4. Attachment names must be clear and specific — never fabricate unknown attachments
|
||||
|
||||
---
|
||||
|
||||
## Signature & Date
|
||||
|
||||
1. Document types requiring signatures should have issuing body name and date
|
||||
2. Not all types mechanically require signatures (minutes typically do not)
|
||||
3. Formal document dates must use Chinese numeral format with proper "〇" character
|
||||
- Example: March 31, 2026 → 二〇二六年三月三十一日
|
||||
4. Document numbers use tortoiseshell brackets "〔〕" (not square brackets "[]")
|
||||
- Example: X政发〔2026〕1号
|
||||
5. Date format must be consistent throughout
|
||||
|
||||
---
|
||||
|
||||
## Palette
|
||||
|
||||
**NO decorative colors.** Pure black text on white background. The only color is red header text.
|
||||
|
||||
```js
|
||||
const palette = { primary:"#000000", body:"#000000", accent:"#000000", surface:"#FFFFFF" };
|
||||
const RED_HEADER = "FF0000"; // Only for red header text
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Page Layout (GB/T 9704-2012 Standard)
|
||||
|
||||
**Only for formal GB/T red-header documents.** Non-GB/T scenarios may use standard margins.
|
||||
|
||||
| Property | Value | Twips |
|
||||
|----------|-------|-------|
|
||||
| Top margin | 3.7 cm | 2098 |
|
||||
| Bottom margin | 3.5 cm | 1984 |
|
||||
| Left margin | 2.8 cm | 1588 |
|
||||
| Right margin | 2.6 cm | 1474 |
|
||||
|
||||
```js
|
||||
// GB/T red header layout
|
||||
page: { size: { width: 11906, height: 16838 }, margin: { top: 2098, bottom: 1984, left: 1588, right: 1474 } }
|
||||
// Non-GB/T formal documents may use standard margins:
|
||||
// margin: { top: 1440, bottom: 1440, left: 1701, right: 1417 }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Font Specifications (GB/T 9704)
|
||||
|
||||
| Element | Font | Size | Style |
|
||||
|---------|------|------|-------|
|
||||
| Red header org name | STXiaoBiaoSong / SimSun Bold | As determined by org | Red (#FF0000), centered |
|
||||
| Document title | STXiaoBiaoSong / SimSun Bold | Er Hao 22pt (size: 44) | Centered |
|
||||
|
||||
**Font fallback for STXiaoBiaoSong:** This font is not installed by default on all systems. WPS ships FZXiaoBiaoSong-S13 instead. Use this fallback chain:
|
||||
- Preferred: `STXiaoBiaoSong` (华文小标宋)
|
||||
- Fallback 1: `FZXiaoBiaoSong-S13` (方正小标宋, available in WPS)
|
||||
- Fallback 2: `SimSun` with Bold (宋体加粗, universally available)
|
||||
|
||||
In code, set primary font and note the fallback:
|
||||
```js
|
||||
font: { eastAsia: "STXiaoBiaoSong" }
|
||||
// Fallback: FZXiaoBiaoSong-S13 → SimSun Bold. User may need to install STXiaoBiaoSong for exact rendering.
|
||||
```
|
||||
| Addressee | FangSong | San Hao 16pt (size: 32) | Left-aligned |
|
||||
| Body | FangSong | San Hao 16pt (size: 32) | Justified, indent 640 |
|
||||
| Level 1 heading | SimHei | San Hao 16pt (size: 32) | Bold |
|
||||
| Level 2 heading | KaiTi | San Hao 16pt (size: 32) | Normal |
|
||||
| Level 3 heading | FangSong | San Hao 16pt (size: 32) | Bold |
|
||||
| Attachment notes | FangSong | San Hao 16pt (size: 32) | Left-aligned |
|
||||
| Signature/date | FangSong | San Hao 16pt (size: 32) | Right-aligned |
|
||||
| Page number | FangSong | Si Hao 14pt (size: 28) | Centered, "— X —" |
|
||||
|
||||
```js
|
||||
styles: {
|
||||
default: {
|
||||
document: {
|
||||
run: { font: { ascii: "Times New Roman", eastAsia: "FangSong" }, size: 32, color: "000000" },
|
||||
paragraph: { spacing: { line: 560 } }, // Fixed 28pt line spacing
|
||||
},
|
||||
heading1: {
|
||||
run: { font: { eastAsia: "SimHei" }, size: 32, bold: true, color: "000000" },
|
||||
},
|
||||
heading2: {
|
||||
run: { font: { eastAsia: "KaiTi" }, size: 32, color: "000000" },
|
||||
},
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
**Note:** For "formal administrative style" (not strict GB/T), retain the style logic but do not rigidly require every GB/T element.
|
||||
|
||||
---
|
||||
|
||||
## Code Examples
|
||||
|
||||
### Red Header (red-header documents only)
|
||||
|
||||
```js
|
||||
new Paragraph({ alignment: AlignmentType.CENTER, spacing: { before: 0, after: 200, line: Math.ceil(26 * 23), lineRule: "atLeast" },
|
||||
children: [new TextRun({ text: "XX Municipal Government", font: { eastAsia: "SimSun" },
|
||||
size: 52, bold: true, color: "FF0000" })] })
|
||||
new Paragraph({ border: { bottom: { style: BorderStyle.SINGLE, size: 4, color: "FF0000" } },
|
||||
spacing: { after: 40 }, children: [] })
|
||||
```
|
||||
|
||||
### Page Number Footer
|
||||
|
||||
```js
|
||||
footers: { default: new Footer({ children: [new Paragraph({
|
||||
alignment: AlignmentType.CENTER,
|
||||
children: [
|
||||
new TextRun({ text: "\u2014 ", size: 28 }),
|
||||
new TextRun({ children: [PageNumber.CURRENT], size: 28 }),
|
||||
new TextRun({ text: " \u2014", size: 28 }),
|
||||
],
|
||||
})] }) }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Style Rules
|
||||
|
||||
1. **Strictly follow official document format — no decorative elements**
|
||||
2. NO cover page
|
||||
3. NO TOC
|
||||
4. NO headers (only page numbers in footer)
|
||||
5. NO colors except red header (red-header documents only)
|
||||
6. NO images or charts (unless integral to document content)
|
||||
7. NO fancy fonts — only FangSong, SimHei, KaiTi, STXiaoBiaoSong
|
||||
8. Line spacing: fixed 28pt (`line: 560`) — **NOT** the default 1.5x
|
||||
|
||||
---
|
||||
|
||||
## Scene-Specific Prohibitions
|
||||
|
||||
In addition to universal prohibitions (see `references/common-rules.md`):
|
||||
|
||||
1. Must not write official documents as chat replies, promotional copy, speeches, or papers
|
||||
2. Must not use Markdown headings/lists/bold/italic for document hierarchy
|
||||
3. Must not apply red header/document number/colophon to all document types indiscriminately
|
||||
4. Must not format meeting minutes as a standard red-header notice
|
||||
5. Must not use literary rhetoric, colloquial expressions, or strongly emotional language
|
||||
6. Must not fabricate incoming documents, policies, document numbers, meeting decisions, or superior directives
|
||||
7. Must not use excessive blank lines to create "formal appearance"
|
||||
8. Must not let the document read like a report, paper, or marketing copy
|
||||
|
||||
---
|
||||
|
||||
## Scene-Specific Quality Checks
|
||||
|
||||
In addition to universal checks (see `references/common-rules.md`):
|
||||
|
||||
### Format
|
||||
- [ ] Red header text is #FF0000 and only red header uses color (red-header scenarios)
|
||||
- [ ] Line spacing fixed at 28pt (line: 560)
|
||||
- [ ] FangSong / SimHei / KaiTi correctly applied
|
||||
- [ ] Signature right-aligned, date format correct
|
||||
- [ ] No cover page, no TOC, no header
|
||||
- [ ] Page number format "— X —"
|
||||
- [ ] Red header / document number / colophon only where appropriate
|
||||
|
||||
### Content
|
||||
- [ ] Document type correctly identified, structure matches
|
||||
- [ ] Title is accurate, specific, document type clear (not vague)
|
||||
- [ ] Addressee, attachments, signature, colophon used appropriately
|
||||
- [ ] Closing phrase matches document type
|
||||
- [ ] Body hierarchy strictly follows: 一、(Level 1) →（一）(Level 2) → 1. (Level 3) →（1）(Level 4)
|
||||
- [ ] No Markdown headings/lists/bold/italic mixed in
|
||||
- [ ] Meeting minutes not incorrectly given standard document signature and colophon
|
||||
- [ ] Date uses Chinese numerals with proper "〇" character
|
||||
- [ ] Document number uses tortoiseshell brackets "〔〕"
|
||||
- [ ] No fabricated incoming documents / policy bases / organizational elements
|
||||
- [ ] Register is solemn and plain — no colloquial / literary / promotional tone
|
||||
340
skills/docx/scenes/report.md
Executable file
340
skills/docx/scenes/report.md
Executable file
@@ -0,0 +1,340 @@
|
||||
# Scene: Report / Proposal
|
||||
|
||||
## Goal
|
||||
|
||||
Generate a complete, formal, well-structured report ready for Word delivery. Must simultaneously meet:
|
||||
- Complete structure, clear logic, formal language, definitive conclusions
|
||||
- Objective data presentation, proper Word formatting
|
||||
- Ready for presentation, filing, review, submission, or internal communication
|
||||
|
||||
**Forbidden:** Producing outlines-only / summaries / template annotations / half-finished drafts; outputting chat-style explanations or filler phrases like "here is the report content".
|
||||
|
||||
→ Font profile: **A (Formal)** — see `references/common-rules.md`
|
||||
→ Default layout: standard margins — see `references/common-rules.md`
|
||||
→ Placeholder convention — see `references/common-rules.md`
|
||||
→ Universal prohibitions & quality checks — see `references/common-rules.md`
|
||||
|
||||
---
|
||||
|
||||
## Report Type Routing
|
||||
|
||||
Auto-select structure and expression style based on user intent. If not explicit, infer from topic.
|
||||
|
||||
```js
|
||||
function selectReportType(keywords, topic) {
|
||||
if (/analysis|competitor|industry|operations|data/.test(keywords)) return "analysis";
|
||||
if (/experiment|lab|algorithm|engineering/.test(keywords)) return "experiment";
|
||||
if (/test|QA|performance|security|compatibility/.test(keywords)) return "testing";
|
||||
if (/survey|questionnaire|interview|market research/.test(keywords)) return "research";
|
||||
if (/review|retrospective|post-mortem|summary/.test(keywords)) return "review";
|
||||
if (/proposal|feasibility|implementation|optimization/.test(keywords)) return "proposal";
|
||||
return "analysis"; // default
|
||||
}
|
||||
```
|
||||
|
||||
### 6 Report Types
|
||||
|
||||
| Type | Use Case | Structure Focus | Expression Focus |
|
||||
|------|----------|----------------|-----------------|
|
||||
| analysis | Industry/competitor/operations/data analysis | Background → Dimensions → Findings → Diagnosis → Recommendations | Conclusion-first, clear dimensions, chart-supported, actionable advice |
|
||||
| experiment | Scientific/academic/algorithm/engineering experiments | Objective → Environment → Method → Results → Error → Conclusion | Precise process, clear conditions, objective results, conclusion ties to hypothesis |
|
||||
| testing | Functional/performance/security/compatibility testing | Overview → Scope → Plan → Results → Defects → Risks → Conclusion | Data-driven, traceable, reproducible, supports go/no-go decisions |
|
||||
| research | User/market/survey/interview research | Background → Subjects & Method → Sample → Findings → Synthesis → Recommendations | Clear sample boundaries, layered findings, recommendations match findings |
|
||||
| review | Project/incident retrospective, phase summary | Goals → Review → Results → Issues → Lessons → Actions | Clear facts, restrained attribution, specific action items |
|
||||
| proposal | Project/optimization proposal, feasibility study | Status → Goals → Solution → Roadmap → Resources → Risks → Benefits | Strong argumentation, executable plan, clear boundaries |
|
||||
|
||||
---
|
||||
|
||||
## Standard Template Structures
|
||||
|
||||
### Template A: Analysis Report
|
||||
1. Executive Summary
|
||||
2. Background & Objectives
|
||||
3. Scope, Data Sources & Methodology
|
||||
4. Core Findings
|
||||
5. Problem Diagnosis & Root Cause
|
||||
6. Conclusions & Recommendations
|
||||
7. Appendices (if needed)
|
||||
|
||||
### Template B: Experiment Report
|
||||
1. Abstract
|
||||
2. Objective & Hypothesis
|
||||
3. Environment & Materials
|
||||
4. Procedure & Method
|
||||
5. Data & Results
|
||||
6. Error Analysis & Discussion
|
||||
7. Conclusions
|
||||
8. Appendices (if needed)
|
||||
|
||||
### Template C: Testing Report
|
||||
1. Test Overview
|
||||
2. Test Scope & Environment
|
||||
3. Test Plan & Case Design
|
||||
4. Test Results Summary
|
||||
5. Defect Analysis & Distribution
|
||||
6. Risk Assessment & Outstanding Issues
|
||||
7. Test Conclusions
|
||||
8. Appendices (if needed)
|
||||
|
||||
### Template D: Research Report
|
||||
1. Research Summary
|
||||
2. Background & Objectives
|
||||
3. Subjects & Methodology
|
||||
4. Sample & Data Description
|
||||
5. Core Findings
|
||||
6. Problem Synthesis
|
||||
7. Recommendations & Action Direction
|
||||
8. Appendices (if needed)
|
||||
|
||||
### Template E: Review / Summary Report
|
||||
1. Overview
|
||||
2. Goals & Scope
|
||||
3. Process Review
|
||||
4. Results Summary
|
||||
5. Issues & Root Cause Analysis
|
||||
6. Lessons Learned
|
||||
7. Follow-up Action Plan
|
||||
8. Appendices (if needed)
|
||||
|
||||
### Template F: Proposal / Feasibility Report
|
||||
1. Executive Summary
|
||||
2. Current State & Problem Analysis
|
||||
3. Goals & Expected Outcomes
|
||||
4. Solution Design
|
||||
5. Implementation Roadmap & Milestones
|
||||
6. Resource Requirements & Budget
|
||||
7. Risk Analysis & Mitigation
|
||||
8. Expected Benefits & Evaluation
|
||||
9. Appendices (if needed)
|
||||
|
||||
**If the user provides a company/school/course template or fixed chapter requirements, always follow those first.**
|
||||
|
||||
---
|
||||
|
||||
## Input Recognition & Completion
|
||||
|
||||
### User May Provide
|
||||
Report topic, type, use case, audience, industry, length requirements, data sources, structure requirements, output purpose (presentation/filing/audit/review/external submission/coursework), template files, company/department/project/author/date, etc.
|
||||
|
||||
### Processing Rules
|
||||
1. If the user provides a template, existing document, company standard, or format example, **always follow it first**
|
||||
2. If information is incomplete, fill in conservatively — completions must be **restrained, natural, credible, professional**
|
||||
3. **Never fabricate** unrealistic data, conclusions, test results, business metrics, project statuses, policy backgrounds, or customer feedback
|
||||
4. If critical information is missing and cannot be safely inferred, use standardized placeholders
|
||||
5. If no real data is available, prefer low-hallucination approaches: "status description → analysis framework → problem synthesis → recommendations"
|
||||
|
||||
---
|
||||
|
||||
## Content Quality Constraints
|
||||
|
||||
### Logic & Structure
|
||||
1. Report must revolve around a clear topic, objective, audience, and through-line
|
||||
2. Must not just pile up background/concepts/vague statements — must demonstrate analysis, synthesis, judgment, comparison, or review value
|
||||
3. Terminology must be consistent throughout — concepts must not drift
|
||||
4. Abstract, body, conclusions, and recommendations must be consistent — no self-contradiction
|
||||
5. Must form a complete loop: "background → objective → method/basis → process/status → findings/results → problems/judgment → recommendations/conclusions"
|
||||
6. Each major chapter must have a clear core conclusion or topic sentence — no information dump
|
||||
|
||||
### Language Style
|
||||
1. Formal, objective, restrained, professional
|
||||
2. No colloquial expressions, chat tone, hyperbole, emotional language, or propaganda style
|
||||
3. For management/decision-maker audience: conclusion-first, highlight key points, actionable recommendations
|
||||
4. For technical/testing reports: clear basis, reproducible process, verifiable results, stated risks
|
||||
|
||||
### Data Expression
|
||||
1. Never use vague expressions as main conclusions: "significantly improved", "obviously optimized", "performed well", "has certain issues"
|
||||
2. If data exists, express quantitatively (e.g., "average response time under 200 ms" not "fast response")
|
||||
3. First occurrence of a term: write full name with abbreviation, e.g., "Application Programming Interface (API)"
|
||||
4. Without real data backing, never fabricate precise figures
|
||||
5. Statements about facts, data, status, and results must be internally consistent
|
||||
|
||||
### Truthfulness & Conservative Generation
|
||||
1. Never fabricate test results, experiment data, growth rates, customer counts, interview conclusions, sample distributions, or launch decisions
|
||||
2. Never present speculation as proven fact
|
||||
3. Never fabricate meeting minutes, regulatory bases, customer feedback, or system logs
|
||||
4. When information is insufficient, use placeholders — never pretend information is complete
|
||||
5. Conclusions must be restrained — do not overstate effects, risks, or value
|
||||
6. Recommendations must be grounded in preceding analysis — no conclusions from thin air
|
||||
|
||||
---
|
||||
|
||||
## Chapter Content Requirements
|
||||
|
||||
### (1) Cover
|
||||
1. Formal reports should have a cover page
|
||||
2. Cover includes: title, subtitle (if any), organization/department, author, date, classification (if requested)
|
||||
3. Cover must be a separate section
|
||||
4. Cover does not display page numbers
|
||||
5. Use `selectCoverRecipe()` for recipe + palette (see design-system.md)
|
||||
6. Common recipes: general report R1, whitepaper R2, consulting R3, proposal R4
|
||||
|
||||
### (2) Executive Summary
|
||||
1. Formal reports **must have** a summary opening — never jump directly into details
|
||||
2. Summary should briefly state: background, objective, key methodology, key findings, main recommendations
|
||||
3. Suitable for quick reading by management — generally 200–400 words
|
||||
4. Must not read like a TOC description or pile of background filler
|
||||
|
||||
### (3) Table of Contents
|
||||
1. Medium-to-long formal reports should include a TOC
|
||||
2. TOC must be generated from real heading styles (Heading + TOC field) — never write a fake TOC
|
||||
3. TOC page is typically a separate page
|
||||
4. TOC depth: usually 2–3 levels
|
||||
|
||||
### (4) Background & Objectives
|
||||
1. Must explain why this report exists
|
||||
2. Must state what problem/scenario/audience the report serves
|
||||
3. If scope boundaries exist, state what the report does NOT cover
|
||||
4. Must not be vague/grand background — must relate directly to this report's task
|
||||
|
||||
### (5) Methodology / Scope / Basis
|
||||
1. Must state what materials, criteria, methods, and time range the report is based on
|
||||
2. Analysis: data sources, analysis dimensions, criteria definitions
|
||||
3. Experiment: environment, materials, samples, procedure principles
|
||||
4. Testing: scope, version, environment, methods, coverage/rounds
|
||||
5. Research: sample source, sample size, research method, time range
|
||||
6. Reader must understand how conclusions were derived
|
||||
|
||||
### (6) Core Content / Process / Status / Results
|
||||
1. Organized by logical or dimensional order — no chaotic piling
|
||||
2. Each section should lead with its conclusion, then expand with evidence
|
||||
3. Results must be specific — never just "performed well" or "has certain issues"
|
||||
4. Data, metrics, phenomena, and comparisons must be clearly stated
|
||||
5. If charts are needed but cannot be generated, use chart placeholders (see below)
|
||||
|
||||
### (7) Analysis / Discussion / Problem Diagnosis
|
||||
1. Must not merely repeat earlier results
|
||||
2. Must explain what results mean, what patterns they reveal, what problems they expose
|
||||
3. May include: comparative analysis, root cause analysis, mechanism analysis, anomaly explanation, limitations, risk boundaries
|
||||
4. Analysis must be consistent with preceding data and facts
|
||||
|
||||
### (8) Conclusions / Recommendations / Next Steps
|
||||
1. Conclusions must respond to report objectives
|
||||
2. Recommendations must be executable — not just principle slogans
|
||||
3. Recommendations should state: who executes, what to do, when, expected improvement
|
||||
4. Testing/review: clear verdict (pass / conditional pass / fail)
|
||||
5. Retrospective/summary: specific follow-up action items
|
||||
|
||||
### (9) Appendices
|
||||
1. Supplementary material valuable to the report but not suitable for the main body
|
||||
2. Includes: raw data excerpts, detailed parameters, supplementary tables, sample screenshots
|
||||
3. Appendices should be on separate pages with proper headings
|
||||
|
||||
---
|
||||
|
||||
## Chart Placeholder Convention
|
||||
|
||||
When charts are needed but cannot be directly generated:
|
||||
|
||||
```
|
||||
[Chart Placeholder: Bar chart; Topic: Q1-Q4 2025 revenue comparison; X-axis: Quarter; Y-axis: Revenue (10K CNY); Style: clean business]
|
||||
```
|
||||
|
||||
**Rules:**
|
||||
- Specify: chart type, topic, axis meanings, key dimensions, optional palette suggestion
|
||||
- Placeholder must be a standalone paragraph — never inline
|
||||
- Never use vague placeholders like "insert chart here"
|
||||
|
||||
**Prefer direct generation:** Charts that can be produced via matplotlib should be generated as embedded PNGs. Placeholders are a fallback only.
|
||||
|
||||
---
|
||||
|
||||
## Content-to-Word Mapping
|
||||
|
||||
### Heading Levels
|
||||
1. Strict hierarchy — no level-skipping
|
||||
2. Headings must be informative — never "Background", "Content", "Other" (use "Project Background & Report Objectives" instead)
|
||||
3. Do not mix multiple numbering systems
|
||||
4. Normal paragraphs must not masquerade as headings
|
||||
|
||||
### Paragraphs
|
||||
1. Do not use consecutive blank lines for visual spacing
|
||||
2. Each paragraph should be a complete semantic unit — not too long or too fragmented
|
||||
|
||||
### Lists
|
||||
1. Use lists only when genuinely needed — an entire report must not be bullet points
|
||||
2. Nesting depth ≤ 3 levels
|
||||
3. Consistent punctuation within a list (all complete sentences or all fragments)
|
||||
4. Combine "key points" with "analysis paragraphs" — never just list without explaining
|
||||
|
||||
### Tables
|
||||
1. Use tables only for structured data (statistics, comparisons, parameter lists)
|
||||
2. Every table must have a header row — headers must not be blank
|
||||
3. Avoid heavily merged-cell complex nested tables
|
||||
4. Tables must have introductory and explanatory text before/after
|
||||
5. Cell content should be concise — avoid long paragraphs inside cells
|
||||
|
||||
### Emphasis
|
||||
1. Bold only for key conclusions, critical metrics, first occurrence of key terms
|
||||
2. Never bold entire paragraphs
|
||||
3. Avoid italic, strikethrough, and other unstable styles
|
||||
|
||||
---
|
||||
|
||||
## Palette Selection
|
||||
|
||||
| Report Type | Suggested Palette |
|
||||
|-------------|-------------------|
|
||||
| General | Neutral calm (primary: #101820) |
|
||||
| Consulting | Warm terracotta |
|
||||
| Tech | Cool dawn mist |
|
||||
| Environment / Education | Warm sunshine |
|
||||
| Medical | Cool mint |
|
||||
|
||||
See `references/design-system.md` for full palette definitions.
|
||||
|
||||
---
|
||||
|
||||
## Document Structure
|
||||
|
||||
1. **Cover** — via `selectCoverRecipe()` (see design-system.md)
|
||||
- Separate section, page margin typically 0
|
||||
- Common: general R1, whitepaper R2, consulting R3, proposal R4
|
||||
|
||||
2. **Table of Contents** — H1–H3, separate section
|
||||
|
||||
3. **Executive Summary** — 1 page max
|
||||
|
||||
4. **Body** — Chapters per selected template (A–F)
|
||||
|
||||
5. **Conclusions & Recommendations**
|
||||
|
||||
6. **Appendices** — Raw data, detailed tables
|
||||
|
||||
---
|
||||
|
||||
## Professional Elements
|
||||
|
||||
- **Page numbers**: bottom center, size 18, color "808080"
|
||||
- **Header**: report title (abbreviated), size 18, color "808080"
|
||||
- **Figure/table numbering**: sequential (Figure 1 / Table 1)
|
||||
- **Cover**: no page number, no header/footer
|
||||
- **TOC**: optional Roman numerals or no page numbers
|
||||
- **Body**: Arabic numerals, continuous
|
||||
|
||||
---
|
||||
|
||||
## Scene-Specific Quality Checks
|
||||
|
||||
In addition to universal checks (see `references/common-rules.md`):
|
||||
|
||||
### Format
|
||||
- [ ] Executive summary ≤ 1 page
|
||||
- [ ] Figures/tables have captions ("Figure X: description" / "Table X: description")
|
||||
- [ ] Cover recipe matches report type
|
||||
- [ ] Data charts use palette accent color
|
||||
|
||||
### Content
|
||||
- [ ] Has executive summary — not starting directly with details
|
||||
- [ ] Heading names are specific and meaningful
|
||||
- [ ] Complete loop: background → basis → content → analysis → conclusions/recommendations
|
||||
- [ ] No fabricated or exaggerated details
|
||||
- [ ] Abstract and conclusions are consistent
|
||||
- [ ] Terminology consistent throughout
|
||||
- [ ] Data expressions are quantified, not vague
|
||||
- [ ] Recommendations are actionable with owners and timeline
|
||||
|
||||
### Structure
|
||||
- [ ] Heading hierarchy has no level-skipping
|
||||
- [ ] List nesting ≤ 3 levels
|
||||
- [ ] Tables have headers with intro/explanation text
|
||||
- [ ] Bold used sparingly for emphasis only
|
||||
534
skills/docx/scenes/resume.md
Executable file
534
skills/docx/scenes/resume.md
Executable file
@@ -0,0 +1,534 @@
|
||||
# Scene: Resume / CV
|
||||
|
||||
## Goal
|
||||
|
||||
Generate a complete, authentic, well-structured, position-targeted resume with stable Word formatting. Must simultaneously meet:
|
||||
- Authentic and credible content, clear position targeting
|
||||
- ATS-friendly, stable Word layout
|
||||
- Clean structure, professional visual design, easy to scan
|
||||
|
||||
**Execution priority** (when conflicting): Position relevance > Information readability > ATS compatibility > Visual decoration
|
||||
|
||||
**Forbidden:** Producing advice-only / fragments / half-finished drafts; outputting chat-style explanations.
|
||||
|
||||
→ Font profile: **B (Visual)** — see `references/common-rules.md`
|
||||
→ Placeholder convention & universal prohibitions — see `references/common-rules.md`
|
||||
|
||||
---
|
||||
|
||||
## Scope
|
||||
|
||||
Default: generate a position-oriented general resume. Switch to English resume, academic CV, international format, or design portfolio style only when explicitly requested by the user.
|
||||
|
||||
---
|
||||
|
||||
## Resume Type Routing
|
||||
|
||||
Auto-select module order based on user background and target:
|
||||
|
||||
### General Resume (default)
|
||||
Name & Contact → Target Position → Profile Summary (optional) → Core Skills → Work Experience → Projects → Education → Certifications / Awards
|
||||
|
||||
### New Graduate Resume
|
||||
Name & Contact → Target Position → Education → Internship Experience → Projects → Campus Activities / Competitions / Awards → Skills & Certifications
|
||||
|
||||
### Technical Role Resume
|
||||
Name & Contact → Target Direction → Profile Summary (optional) → Tech Stack / Core Skills → Work Experience → Projects → Education → Open Source / Papers / Patents / Competitions
|
||||
|
||||
### Academic CV
|
||||
Name & Contact → Research Direction / Target → Education → Research Experience → Papers / Patents / Projects / Grants → Teaching / Academic Service → Awards / Skills / Languages
|
||||
|
||||
---
|
||||
|
||||
## Input Processing Rules
|
||||
|
||||
1. If user provides a target position or JD → **must reorganize and rewrite content around position requirements**
|
||||
2. If user provides a raw draft → prioritize restructuring, phrasing refinement, and priority reordering; do not rewrite into an unfamiliar career
|
||||
3. **Never fabricate** companies, positions, degrees, projects, certifications, awards, papers, patents, data results, or achievements
|
||||
4. If critical data is missing → use conservative expressions or placeholder `【Please fill in: ______】`; never fabricate precise numbers
|
||||
5. A single resume should generally serve only one primary career direction
|
||||
|
||||
---
|
||||
|
||||
## Content Quality Constraints
|
||||
|
||||
### Core Principles
|
||||
1. Resume must revolve around the target position — do not spread all experiences equally
|
||||
2. Most relevant experiences, projects, and skills must be **placed first and detailed**
|
||||
3. Terminology, company names, position titles, date formats, and skill names must be consistent
|
||||
4. Must demonstrate: **personal positioning → capability tags → relevant experience → provable results**
|
||||
5. No piling of vague self-praise; no inspirational writing or chronological dumps
|
||||
|
||||
### Experience Writing Standards
|
||||
|
||||
Each experience bullet should demonstrate: **Action + Object/Context + Method + Result/Impact**
|
||||
|
||||
**Recommended verbs:** Led, built, drove, optimized, refactored, designed, delivered, coordinated, improved, reduced, achieved
|
||||
|
||||
**Rules:**
|
||||
- "Responsible for" / "participated in" are not absolutely forbidden, but must include scope and results
|
||||
- Each bullet is concise — one core contribution per bullet
|
||||
- Quantify when possible, but do not force-bold all numbers
|
||||
- Recent experience gets detail; low-relevance/low-value experience gets compressed or removed
|
||||
- Reverse chronological order — most recent and relevant first
|
||||
- Expand the most recent 2 experiences; compress earlier ones
|
||||
|
||||
### Profile Summary / Self-Assessment
|
||||
1. Not mandatory
|
||||
2. If included, frame as "Profile Summary" — **3–4 lines max**
|
||||
3. Focus on: years of experience, career direction, core capabilities, representative achievements, position fit
|
||||
4. **Forbidden** as main content: "hardworking", "strong sense of responsibility", "team player", "quick learner", "outgoing personality"
|
||||
|
||||
### Truthfulness & Risk Control
|
||||
1. Never fabricate experiences, achievements, education, awards, or certifications
|
||||
2. Never upgrade "participated in" to "led" unless user information supports it
|
||||
3. Never attribute team results entirely to the individual
|
||||
4. Never fabricate revenue, conversion rates, headcount, budgets, or technical metrics
|
||||
5. If no data available, use restrained expressions: "improved delivery efficiency", "shortened processing cycle", "supported core business launch"
|
||||
|
||||
---
|
||||
|
||||
## Length Control
|
||||
|
||||
| Candidate Type | Target Pages |
|
||||
|---------------|-------------|
|
||||
| New graduate / <3 years experience | **1 page** |
|
||||
| 3–10 years experience | 1–2 pages |
|
||||
| Senior manager / researcher / academic CV | May exceed 2 pages, but must maintain information density |
|
||||
|
||||
**Compression rules:**
|
||||
- Experiences >5 years old with low relevance should be compressed
|
||||
- Experiences >10 years old and irrelevant may be omitted
|
||||
- Never pad low-value experiences just to "look comprehensive"
|
||||
|
||||
---
|
||||
|
||||
## ATS & Structure Constraints
|
||||
|
||||
1. Core information must be plain text — never rely on images, icons, text boxes, or headers/footers for key content
|
||||
2. No embedded charts, objects, SmartArt, or WordArt
|
||||
3. Experience descriptions use consistent bullet symbols — no complex auto-numbering
|
||||
4. Bullets within the same position should be compact — no excess blank lines
|
||||
|
||||
**Table layout vs. ATS balance:** The 3 visual templates (A/B/C) use Table-based layouts for Word visual quality. In strict ATS scenarios (user explicitly says "ATS priority"), prefer Template B (single-column) with reduced table dependency. Default: visual quality first.
|
||||
|
||||
---
|
||||
|
||||
## Module Naming
|
||||
|
||||
Use only standard, universal, recruiter-familiar names:
|
||||
- Personal Info, Target Position, Profile Summary, Core Skills, Work Experience, Projects, Education, Certifications, Awards, Languages
|
||||
|
||||
**Forbidden fancy names:** "My Growth Journey", "Self-Appreciation", "Shining Moments", "Life Motto"
|
||||
|
||||
---
|
||||
|
||||
## Template Disease Prevention
|
||||
|
||||
1. Do not include irrelevant identity tags (political affiliation, hometown, etc.) unless user explicitly requests
|
||||
2. Do not place low-priority modules (hobbies, languages, personality traits) before work experience
|
||||
3. Do not combine cover letter and resume in one document (unless user explicitly requests)
|
||||
4. Do not let template feel overpower actual personal information
|
||||
5. Do not let "self-assessment" occupy the golden area of the page (should come after core skills/experience)
|
||||
|
||||
---
|
||||
|
||||
## Template Selection
|
||||
|
||||
Three templates are provided, auto-selected based on user needs:
|
||||
|
||||
| Template | Layout | Best For | Color Style |
|
||||
|----------|--------|----------|-------------|
|
||||
| A | Left sidebar + right body | General purpose, tech roles | Dark grey sidebar + blue bar headings |
|
||||
| B | Dark header banner + single column | Content-heavy / senior candidates | Dark blue header + underline headings |
|
||||
| C | Left sidebar + vertical-line headings | International / bilingual / foreign companies | Blue sidebar + left-border headings |
|
||||
|
||||
**Selection logic:**
|
||||
- Default: Template A
|
||||
- Lots of content (expected > 1 page) → Template B (no sidebar, better space utilization)
|
||||
- User explicitly requests bilingual / English → Template C
|
||||
|
||||
### Industry Color Suggestions
|
||||
|
||||
| Career Direction | Sidebar BG | Accent Color | Recommended Template |
|
||||
|-----------------|-----------|-------------|---------------------|
|
||||
| Tech / Internet | `#1A1F36` (deep blue-purple) | `#667eea` (amethyst) | A or C |
|
||||
| Finance / Consulting | `#0F2027` (deep sea blue) | `#D4AF37` (gold) | A or B |
|
||||
| Design / Creative | `#2D1B30` (deep purple) | `#f5576c` (coral pink) | A or C |
|
||||
| Education / Training | `#1A3A3A` (dark green) | `#3CB4A0` (mint green) | A |
|
||||
| Medical / Health | `#0E2030` (dark cyan) | `#3888A8` (medical blue) | B |
|
||||
| General / Default | `#303030` (warm dark neutral) | `#B89870` (warm accent) | A |
|
||||
|
||||
When industry is unspecified, use default warm neutral palette. This aligns with the Visual Profile warm-neutral guidance in `design-system.md`.
|
||||
|
||||
## Key Rules
|
||||
|
||||
- **NO cover page / NO TOC**
|
||||
- **Target: 1 page** (2 pages max for senior roles)
|
||||
- **Compact spacing**: `line: 276` (1.15x)
|
||||
- All templates use **bilingual section headings** (e.g., "Work Experience 工作经历")
|
||||
|
||||
---
|
||||
|
||||
## Template A: Left Sidebar + Color Bar Headings
|
||||
|
||||
### Color Palette
|
||||
```js
|
||||
const S = {
|
||||
bg: "3B4F5C", // sidebar background (dark grey-blue)
|
||||
text: "D8E2E8", // sidebar text
|
||||
label: "8BA0AD", // sidebar secondary text
|
||||
accent: "2F97B8", // accent color (blue-cyan)
|
||||
title: "1A2D38", // body heading
|
||||
body: "2C3E4A", // body content
|
||||
sec: "6B8592", // secondary info (dates etc.)
|
||||
};
|
||||
```
|
||||
|
||||
### Layout Structure
|
||||
```
|
||||
┌──────────┬──────────────────────┐
|
||||
│ [Photo] │ ██ Profile ██ │ ← Blue bar heading
|
||||
│ │ Summary text... │
|
||||
│ Name │ │
|
||||
│ Title │ ██ Work Experience ██│
|
||||
│ │ Company Role Date │
|
||||
│ ──────── │ ▸ Achievement... │
|
||||
│ Basic │ ▸ Achievement... │
|
||||
│ Info │ │
|
||||
│ │ ██ Projects ██ │
|
||||
│ ──────── │ ... │
|
||||
│ Contact │ │
|
||||
│ │ ██ Education ██ │
|
||||
│ ──────── │ ... │
|
||||
│ Skills │ │
|
||||
│ Java ●●●●○│ │
|
||||
│ Go ●●●○○│ │
|
||||
│ │ │
|
||||
│ ──────── │ │
|
||||
│ Certs │ │
|
||||
└──────────┴──────────────────────┘
|
||||
30% 70%
|
||||
```
|
||||
|
||||
### Implementation Notes
|
||||
|
||||
**Page setup:**
|
||||
```js
|
||||
page: { margin: { top: 0, bottom: 0, left: 0, right: 0 } }
|
||||
// Use Table to simulate columns: columnWidths: [3400, 8506]
|
||||
// ⚠️ Row height must use "exact" with safety margin to prevent overflow blank pages
|
||||
// Row height: height: { value: 16038, rule: "exact" }
|
||||
// 16038 = 16838(A4 height) - 1200(safety margin for cross-engine compatibility)
|
||||
```
|
||||
|
||||
**Sidebar element order:**
|
||||
1. Photo placeholder (rectangle + border, width 2400 DXA, height 1800)
|
||||
2. Name (32pt bold white SimHei) + Title (18pt accent)
|
||||
3. Basic info (DOB / degree / school)
|
||||
4. Contact info (phone / email / address)
|
||||
5. Skill ratings (name + ●○ dot rating, 5 levels each)
|
||||
6. Certificates list
|
||||
|
||||
**Right-side section headings (color bar style):**
|
||||
```js
|
||||
// Full-width bar background + white Chinese text + lighter English text
|
||||
new Table({ columnWidths:[7600], rows:[new TableRow({ children:[
|
||||
new TableCell({
|
||||
shading: { fill: S.accent, type: ShadingType.CLEAR },
|
||||
margins: { top:40, bottom:40, left:200, right:100 },
|
||||
children: [new Paragraph({ children: [
|
||||
new TextRun({ text: "Work Experience ", size:22, bold:true, color:"FFFFFF", font:"SimHei" }),
|
||||
new TextRun({ text: "Experience", size:18, color:"C8E8F0", font:"Times New Roman", italics:true }),
|
||||
] })],
|
||||
})
|
||||
] })] });
|
||||
```
|
||||
|
||||
**Experience entry format:**
|
||||
```js
|
||||
// Line 1: Company(bold) + Title(accent) + Date(right-aligned)
|
||||
new Paragraph({
|
||||
tabStops: [{ type: TabStopType.RIGHT, position: 7200 }],
|
||||
children: [
|
||||
new TextRun({ text: "Company Name", size:22, bold:true, color:S.title }),
|
||||
new TextRun({ text: " Role Title", size:20, color:S.accent }),
|
||||
new TextRun({ text: "\t2023.06 — Present", size:17, color:S.sec }),
|
||||
]
|
||||
});
|
||||
// Line 2+: ▸ bullet points
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template B: Dark Header Banner + Single Column
|
||||
|
||||
### Color Palette
|
||||
```js
|
||||
const C = {
|
||||
dark: "1A3352", // header background (dark blue)
|
||||
accent: "2980B9", // accent color
|
||||
title: "1A2636", // heading
|
||||
body: "2C3E50", // body text
|
||||
sec: "6B8599", // secondary info
|
||||
light: "E8EFF5", // light background
|
||||
};
|
||||
```
|
||||
|
||||
### Layout Structure
|
||||
```
|
||||
┌────────────────────────────────┐
|
||||
│ ██████████████████████████████ │ ← Dark blue background banner
|
||||
│ █ Name Title █ │ Contains name / title /
|
||||
│ █ Phone | Email | Location █ │ contact / basic info
|
||||
│ █ DOB | Degree | School █ │
|
||||
│ ██████████████████████████████ │
|
||||
│ │
|
||||
│ Profile │ ← Underline heading
|
||||
│ ───────────────────────────── │
|
||||
│ Summary text... │
|
||||
│ │
|
||||
│ Work Experience │
|
||||
│ ───────────────────────────── │
|
||||
│ Company | Role Date │
|
||||
│ • Achievement... │
|
||||
│ ... │
|
||||
│ │
|
||||
│ Skills │
|
||||
│ ───────────────────────────── │
|
||||
│ Programming ●●●●○ Java/Go/...│ ← Rating + details
|
||||
└────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Implementation Notes
|
||||
|
||||
**Header banner:**
|
||||
```js
|
||||
// Table single row single column, dark background, height 2400 DXA
|
||||
new Table({ columnWidths:[11906], rows:[new TableRow({
|
||||
height: { value:2400, rule:"exact" },
|
||||
children:[new TableCell({
|
||||
shading: { fill: C.dark },
|
||||
margins: { top:300, bottom:200, left:800, right:800 },
|
||||
verticalAlign: VerticalAlign.TOP, // Never use CENTER in exact-height rows (WPS incompatible)
|
||||
children: [
|
||||
// Line 1: Name(48pt white) + Title
|
||||
// Line 2: Phone | Email | Location
|
||||
// Line 3: DOB | Degree | School
|
||||
]
|
||||
})]
|
||||
})] });
|
||||
```
|
||||
|
||||
**Section headings (underline style):**
|
||||
```js
|
||||
new Paragraph({
|
||||
borders: { bottom: { style: BorderStyle.SINGLE, size: 2, color: C.accent } },
|
||||
children: [
|
||||
new TextRun({ text: "Work Experience", size:24, bold:true, color:C.accent, font:"SimHei" }),
|
||||
new TextRun({ text: " Experience", size:18, color:C.sec, italics:true }),
|
||||
]
|
||||
});
|
||||
```
|
||||
|
||||
**Skills display (rating + details):**
|
||||
```js
|
||||
// Name(bold) + ●○ rating + specific tools list
|
||||
new Paragraph({ children: [
|
||||
new TextRun({ text: "Programming ", size:19, bold:true, color:C.title }),
|
||||
new TextRun({ text: "●●●●○ ", size:13, color:C.accent }),
|
||||
new TextRun({ text: "Java / Go / Python / TypeScript", size:18, color:C.sec }),
|
||||
] });
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template C: Blue Sidebar + Vertical-Line Headings
|
||||
|
||||
### Color Palette
|
||||
```js
|
||||
const C = {
|
||||
side: "4A7C8F", // sidebar background (teal-blue)
|
||||
text: "FFFFFF", // sidebar text
|
||||
label: "A0C4D0", // sidebar secondary text
|
||||
accent: "357A8F", // accent color
|
||||
dot: "2F8FAD", // skill dot fill color
|
||||
dotDim: "B8D4DE", // skill dot empty color
|
||||
title: "1A3040", // body heading
|
||||
body: "2C4050", // body content
|
||||
sec: "6B8A98", // secondary info
|
||||
};
|
||||
```
|
||||
|
||||
### Sidebar-Specific Elements
|
||||
|
||||
**Circular photo placeholder:**
|
||||
```js
|
||||
new Paragraph({ alignment: AlignmentType.CENTER,
|
||||
children: [new TextRun({ text: "◯", size:80, color:C.label })]
|
||||
});
|
||||
```
|
||||
|
||||
**Language proficiency matrix:**
|
||||
```js
|
||||
"English ● ● ● ● ○"
|
||||
"Japanese ● ● ○ ○ ○"
|
||||
```
|
||||
|
||||
**Right-side section headings (left-border style):**
|
||||
```js
|
||||
new Paragraph({
|
||||
borders: { left: { style: BorderStyle.SINGLE, size:8, color:C.accent, space:8 } },
|
||||
indent: { left: 120 },
|
||||
children: [
|
||||
new TextRun({ text: "Work Experience", size:24, bold:true, color:C.title, font:"SimHei" }),
|
||||
new TextRun({ text: " Experience", size:18, color:C.sec, italics:true }),
|
||||
]
|
||||
});
|
||||
```
|
||||
|
||||
**Experience entry format (differs from A):**
|
||||
```js
|
||||
// Line 1: Company name (bold)
|
||||
// Line 2: Role (accent color) + Date
|
||||
// Line 3+: ▸ bullet points
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Universal Rules
|
||||
|
||||
### Font Specifications
|
||||
| Element | Font | Size | Style |
|
||||
|---------|------|------|-------|
|
||||
| Name (sidebar) | SimHei | 32pt (size:64) | Bold, white |
|
||||
| Name (header) | SimHei | 24pt (size:48) | Bold, white |
|
||||
| Section heading | SimHei | 11pt (size:22) | Bold |
|
||||
| Company / School | Microsoft YaHei | 11pt (size:22) | Bold |
|
||||
| Role title | Microsoft YaHei | 10pt (size:20) | accent color |
|
||||
| Date range | Microsoft YaHei | 8.5pt (size:17) | sec color |
|
||||
| Bullet description | Microsoft YaHei | 9.5pt (size:19) | body color |
|
||||
| Skill dots | Default | 6.5pt (size:13) | accent / dimColor |
|
||||
|
||||
### Bullet Symbols
|
||||
- Template A / C: `▸` (small triangle)
|
||||
- Template B: `•` (round dot)
|
||||
|
||||
### Skill Rating Rules
|
||||
- 1–5 levels using filled ● and empty ○ dots
|
||||
- One skill per line, name on the left, dots on the right
|
||||
- Filled dot color: accent; empty dot color: dimColor
|
||||
|
||||
### JD Matching Logic
|
||||
When user provides a job description:
|
||||
1. Extract key requirements (skills, experience, education)
|
||||
2. Prioritize matching experience items to the top
|
||||
3. Naturally incorporate JD keywords into descriptions
|
||||
4. Highlight relevant skills
|
||||
|
||||
### Multi-Page Handling
|
||||
|
||||
- 1 page content: Sidebar templates (A/C) or single-column template (B)
|
||||
- Over 1 page: Prefer Template B; if using A/C, switch page 2 to full-width layout with a name bar at the top (Name | Title)
|
||||
|
||||
⚠️ **Multi-page resumes must use multi-section structure:**
|
||||
|
||||
Page 1 and Page 2 must be **different sections** for independent margin and layout control:
|
||||
|
||||
```js
|
||||
sections: [
|
||||
{
|
||||
// Page 1 section — margin 0 (sidebar layout needs full-page)
|
||||
properties: { page: { margin: { top: 0, bottom: 0, left: 0, right: 0 } } },
|
||||
children: [page1Table],
|
||||
},
|
||||
{
|
||||
// Page 2 section — normal margins with header bar
|
||||
properties: { page: { margin: { top: 800, bottom: 600, left: 800, right: 800 } } },
|
||||
children: [pageHeader(name, title), ...page2Content],
|
||||
},
|
||||
]
|
||||
```
|
||||
|
||||
⚠️ **Template B multi-page handling:**
|
||||
|
||||
Template B header banner uses Table simulation:
|
||||
1. Banner `columnWidths` must equal **page content area width** (pageWidth - marginLeft - marginRight), not full page width
|
||||
2. If banner needs full page width → set page 1 section margin to 0, banner columnWidths to 11906
|
||||
3. Page 2+ must be independent sections, margin.top ≥ 800
|
||||
|
||||
⚠️ **Page 2+ top spacing rules (mandatory):**
|
||||
|
||||
1. **Page margin.top must be ≥ 800 twips** (~1.4 cm), never 0
|
||||
2. **Page 2+ needs a header info bar:** concise `Name | Title` bar, height ~400–600 twips, separated from body with light background or bottom line
|
||||
3. **200–300 twips spacing between header bar and body content**
|
||||
4. **Forbidden: content touching the very top of page 2**
|
||||
|
||||
```js
|
||||
// Concise header bar for page 2+
|
||||
function pageHeader(name, title) {
|
||||
return new Table({
|
||||
width: { size: 100, type: WidthType.PERCENTAGE },
|
||||
borders: { top: NB, left: NB, right: NB, insideHorizontal: NB, insideVertical: NB,
|
||||
bottom: { style: BorderStyle.SINGLE, size: 1, color: "D0D0D0" } },
|
||||
rows: [new TableRow({
|
||||
cantSplit: true,
|
||||
height: { value: 500, rule: "atLeast" },
|
||||
children: [new TableCell({
|
||||
margins: { top: 60, bottom: 60, left: 200, right: 200 },
|
||||
borders: { top: NB, left: NB, right: NB, bottom: NB },
|
||||
children: [new Paragraph({
|
||||
children: [
|
||||
new TextRun({ text: name, size: 20, bold: true, color: S.title || C.title }),
|
||||
new TextRun({ text: ` | ${title}`, size: 18, color: S.sec || C.sec }),
|
||||
]
|
||||
})],
|
||||
})],
|
||||
})],
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Scene-Specific Quality Checks
|
||||
|
||||
In addition to universal checks (see `references/common-rules.md`):
|
||||
|
||||
### Format
|
||||
- [ ] Fits within 1 page (senior ≤ 2 pages)
|
||||
- [ ] **Single-page fill rate ≥ 85%** (bottom whitespace ≤ 15%, ~2500 twips)
|
||||
- [ ] Section headings are bilingual
|
||||
- [ ] Skill rating dots correct (●○)
|
||||
- [ ] Experience in reverse chronological order
|
||||
- [ ] No cover page, no TOC
|
||||
- [ ] Line spacing 1.15x (line: 276)
|
||||
- [ ] No extra blank pages
|
||||
- [ ] **Table row height uses `rule: "exact"` with value ≤ 16038** (prevent overflow blank pages)
|
||||
- [ ] **Multi-page: page 2+ has header info bar + proper top spacing**
|
||||
|
||||
### Content
|
||||
- [ ] Clearly organized around target position
|
||||
- [ ] No vague self-assessments ("hardworking", "responsible", "team player")
|
||||
- [ ] No fabricated data or exaggerated results
|
||||
- [ ] Most relevant experience placed first and detailed
|
||||
- [ ] Each bullet demonstrates action + object + method + result
|
||||
- [ ] No long narrative blocks / excessive long sentences / information density imbalance
|
||||
- [ ] Module names are standardized
|
||||
- [ ] Contact info is plain text, clearly positioned
|
||||
- [ ] Header area forms visual center
|
||||
- [ ] Work experience and projects are the visual main body
|
||||
- [ ] Page count matches candidate seniority
|
||||
|
||||
### Single-Page Fill Rules
|
||||
|
||||
Single-page resumes must fully utilize page space — **large bottom whitespace is forbidden:**
|
||||
|
||||
1. If content is insufficient → **proactively expand:**
|
||||
- Add project details, skill keywords, achievement data
|
||||
- Add supplementary modules: profile summary, interests, awards
|
||||
2. Use section spacing (`spacing.before/after`) to **distribute content evenly**
|
||||
3. Sidebar templates (A/C): sidebar height should approach full page
|
||||
- If sidebar content is sparse, increase element spacing
|
||||
- Or add supplementary modules: "Languages", "Interests"
|
||||
4. Assessment: after generation, check last content element position; if >2500 twips from page bottom, adjust
|
||||
Reference in New Issue
Block a user