{"id":"c560a7bc-74b2-4e84-872d-48ec7c63a042","entityType":"agent","slug":"clawhub-foamtor-software-copyright-skill","name":"software-copyright-skill","canonicalUrl":"https://www.xpersona.co/agent/clawhub-foamtor-software-copyright-skill","canonicalPath":"/agent/clawhub-foamtor-software-copyright-skill","generatedAt":"2026-10-10T21:41:25.263Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T17:22:36.058Z","emptyReason":null},"description":"生成中国软件著作权（软著）登记申请文档。LLM驱动：分析项目代码、生成内容；Python脚本辅助：模板填充、格式保持。 Skill: software-copyright-skill Owner: foamtor Summary: 生成中国软件著作权（软著）登记申请文档。LLM驱动：分析项目代码、生成内容；Python脚本辅助：模板填充、格式保持。 Tags: latest:0.1.0 Version history: v0.1.0 | 2026-08-20T07:58:25.184Z | auto software-copyright-skill 0.1.0 - Initial release with comprehensive documentation for generating Chinese software copyright registration documents. - Supports LLM-driven content generation and Python scripts for template fillin","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.3K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17c2d6kbk24xbejszy9gc0bm98cta4s:software-copyright-skill","sourceUrl":"https://clawhub.ai/foamtor/software-copyright-skill","homepage":"https://clawhub.ai/foamtor/skills/software-copyright-skill","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/foamtor/software-copyright-skill","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/foamtor/skills/software-copyright-skill","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":62,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"生成中国软件著作权（软著）登记申请文档。LLM驱动：分析项目代码、生成内容；Python脚本辅助：模板填充、格式保持。 Skill: software-copyright-skill Owner: foamtor Summary: 生成中国软件著作权（软著）登记申请文档。LLM驱动：分析项目代码、生成内容；Python"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T17:22:36.058Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T17:22:36.058Z","emptyReason":null},"stars":null,"forks":null,"downloads":1320,"packageName":null,"latestVersion":"0.1.0","tractionLabel":"1.3K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T17:22:36.058Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T17:22:36.058Z","lastCrawledAt":"2026-10-10T17:22:36.058Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T17:22:36.058Z","lastVerifiedAt":null,"highlights":[{"version":"0.1.0","createdAt":"2026-08-20T07:58:25.184Z","changelog":"software-copyright-skill 0.1.0 - Initial release with comprehensive documentation for generating Chinese software copyright registration documents. - Supports LLM-driven content generation and Python scripts for template filling and format control. - Provides detailed workflow, architecture, content quality standards, and style guidelines. - Includes configuration options for \"brand profile\" and legacy formats. - Offers command-line instructions and template management for word document generation. - Addresses picture insertion, document specifications, and quality validation processes.","fileCount":118,"zipByteSize":1540674}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17c2d6kbk24xbejszy9gc0bm98cta4s:software-copyright-skill","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-foamtor-software-copyright-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-foamtor-software-copyright-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-foamtor-software-copyright-skill/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-foamtor-software-copyright-skill/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-foamtor-software-copyright-skill/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-foamtor-software-copyright-skill/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T21:41:25.262Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-foamtor-software-copyright-skill/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-foamtor-software-copyright-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-foamtor-software-copyright-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-foamtor-software-copyright-skill/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T17:22:36.058Z","emptyReason":null},"readme":"Skill: software-copyright-skill\n\nOwner: foamtor\n\nSummary: 生成中国软件著作权（软著）登记申请文档。LLM驱动：分析项目代码、生成内容；Python脚本辅助：模板填充、格式保持。\n\nTags: latest:0.1.0\n\nVersion history:\n\nv0.1.0 | 2026-08-20T07:58:25.184Z | auto\n\nsoftware-copyright-skill 0.1.0\n\n- Initial release with comprehensive documentation for generating Chinese software copyright registration documents.\n- Supports LLM-driven content generation and Python scripts for template filling and format control.\n- Provides detailed workflow, architecture, content quality standards, and style guidelines.\n- Includes configuration options for \"brand profile\" and legacy formats.\n- Offers command-line instructions and template management for word document generation.\n- Addresses picture insertion, document specifications, and quality validation processes.\n\nArchive index:\n\nArchive v0.1.0: 118 files, 1540674 bytes\n\nFiles: .gitignore (96b), CHANGELOG.md (761b), config (0b), config/brand_profile.json (8306b), config/format_spec.json (4395b), defaults (0b), defaults/信息采集表填写要求.md (4874b), defaults/要求说明.md (4495b), defaults/说明书格式规范.md (2775b), examples (0b), examples/demo (0b), examples/demo/README.md (877b), LICENSE (1064b), phases (0b), phases/phase0-template.md (2368b), phases/phase1-scan.md (1874b), phases/phase2-info.md (2647b), phases/phase3-outline.md (2115b), phases/phase4-content.md (10169b), phases/phase5-generate.md (3583b), phases/phase6-review.md (5100b), prompts (0b), prompts/代码提取.md (2686b), prompts/大纲生成.md (1417b), prompts/章节审阅.md (1791b), prompts/章节生成.md (2595b), README.md (4333b), references (0b), references/brand-profile-design.md (1885b), references/brand-profile-pattern.md (1823b), references/docxtpl-post-processing-pitfalls.md (4032b), references/docxtpl渲染陷阱.md (3248b), references/excalidraw-diagram (0b), references/excalidraw-diagram/color-palette.md (2116b), references/excalidraw-diagram/element-templates.md (4088b), references/excalidraw-diagram/json-schema.md (1958b), references/excalidraw-diagram/lib (0b), references/excalidraw-diagram/lib/chunk-6U3AYISY.js (22458b), references/excalidraw-diagram/lib/chunk-EIO257PC.js (1824966b), references/excalidraw-diagram/lib/chunk-K2UTITRG.js (439257b), references/excalidraw-diagram/lib/chunk-SRAX5OIU.js (603b), references/excalidraw-diagram/lib/chunk-Z3N5DIM6.js (640b), references/excalidraw-diagram/lib/chunk-ZUYEQ4TG.js (1572b), references/excalidraw-diagram/lib/excalidraw-entry.js (78b), references/excalidraw-diagram/lib/excalidraw.bundle.js (1440b), references/excalidraw-diagram/lib/excalidraw.full.js (1440b), references/excalidraw-diagram/lib/excalidraw.js (502077b), references/excalidraw-diagram/lib/index.js (502077b), references/excalidraw-diagram/lib/subset-shared.chunk.js (174b), references/excalidraw-diagram/lib/subset-worker.chunk.js (376b), references/excalidraw-diagram/package-lock.json (115438b), references/excalidraw-diagram/package.json (382b), references/excalidraw-diagram/pyproject.toml (127b), references/excalidraw-diagram/render_excalidraw.py (6631b), references/excalidraw-diagram/render_template.html (1692b), references/excalidraw-diagram/SKILL.md (27198b), references/excalidraw-diagram/uv.lock (27141b), references/image-strategy-simplified.md (2390b), references/iterative-quality-workflow.md (4036b), references/phase4-content-detail.md (12740b), references/python-docx操作要点.md (1924b), references/V4.3验证问题清单.md (3525b), references/Word格式规范.md (2560b), references/word输出强制规则.md (2344b), references/wsl2截图技巧.md (2702b), references/信息采集表填写要求.md (4874b), references/内容生成策略.md (1762b), references/内容质量保障规范.md (5715b), references/写作规范.md (2636b), references/参考模板分析.md (5069b), references/图片插入逻辑.md (4332b), references/图表工具调研报告.md (5898b), references/多前端项目分析策略.md (4413b), references/常见问题.md (3015b), references/截图功能使用示例.md (9375b), references/截图功能规范.md (10872b), references/提交清单模板.md (3061b), references/文档验证脚本.md (6306b), references/格式规范.md (13268b), references/模型与脚本职责分工.md (3876b)\n\nFile v0.1.0:references/excalidraw-diagram/SKILL.md\n\n---\nname: excalidraw-diagram\ndescription: Create Excalidraw diagram JSON files that make visual arguments. Use when the user wants to visualize workflows, architectures, or concepts.\n---\n\n# Excalidraw Diagram Creator\n\nGenerate `.excalidraw` JSON files that **argue visually**, not just display information.\n\n**Setup:** If the user asks you to set up this skill (renderer, dependencies, etc.), see `README.md` for instructions.\n\n## Customization\n\n**All colors and brand-specific styles live in one file:** `references/color-palette.md`. Read it before generating any diagram and use it as the single source of truth for all color choices — shape fills, strokes, text colors, evidence artifact backgrounds, everything.\n\nTo make this skill produce diagrams in your own brand style, edit `color-palette.md`. Everything else in this file is universal design methodology and Excalidraw best practices.\n\n---\n\n## Core Philosophy\n\n**Diagrams should ARGUE, not DISPLAY.**\n\nA diagram isn't formatted text. It's a visual argument that shows relationships, causality, and flow that words alone can't express. The shape should BE the meaning.\n\n**The Isomorphism Test**: If you removed all text, would the structure alone communicate the concept? If not, redesign.\n\n**The Education Test**: Could someone learn something concrete from this diagram, or does it just label boxes? A good diagram teaches—it shows actual formats, real event names, concrete examples.\n\n---\n\n## Depth Assessment (Do This First)\n\nBefore designing, determine what level of detail this diagram needs:\n\n### Simple/Conceptual Diagrams\nUse abstract shapes when:\n- Explaining a mental model or philosophy\n- The audience doesn't need technical specifics\n- The concept IS the abstraction (e.g., \"separation of concerns\")\n\n### Comprehensive/Technical Diagrams\nUse concrete examples when:\n- Diagramming a real system, protocol, or architecture\n- The diagram will be used to teach or explain (e.g., YouTube video)\n- The audience needs to understand what things actually look like\n- You're showing how multiple technologies integrate\n\n**For technical diagrams, you MUST include evidence artifacts** (see below).\n\n---\n\n## Research Mandate (For Technical Diagrams)\n\n**Before drawing anything technical, research the actual specifications.**\n\nIf you're diagramming a protocol, API, or framework:\n1. Look up the actual JSON/data formats\n2. Find the real event names, method names, or API endpoints\n3. Understand how the pieces actually connect\n4. Use real terminology, not generic placeholders\n\nBad: \"Protocol\" → \"Frontend\"\nGood: \"AG-UI streams events (RUN_STARTED, STATE_DELTA, A2UI_UPDATE)\" → \"CopilotKit renders via createA2UIMessageRenderer()\"\n\n**Research makes diagrams accurate AND educational.**\n\n---\n\n## Evidence Artifacts\n\nEvidence artifacts are concrete examples that prove your diagram is accurate and help viewers learn. Include them in technical diagrams.\n\n**Types of evidence artifacts** (choose what's relevant to your diagram):\n\n| Artifact Type | When to Use | How to Render |\n|---------------|-------------|---------------|\n| **Code snippets** | APIs, integrations, implementation details | Dark rectangle + syntax-colored text (see color palette for evidence artifact colors) |\n| **Data/JSON examples** | Data formats, schemas, payloads | Dark rectangle + colored text (see color palette) |\n| **Event/step sequences** | Protocols, workflows, lifecycles | Timeline pattern (line + dots + labels) |\n| **UI mockups** | Showing actual output/results | Nested rectangles mimicking real UI |\n| **Real input content** | Showing what goes IN to a system | Rectangle with sample content visible |\n| **API/method names** | Real function calls, endpoints | Use actual names from docs, not placeholders |\n\n**Example**: For a diagram about a streaming protocol, you might show:\n- The actual event names from the spec (not just \"Event 1\", \"Event 2\")\n- A code snippet showing how to connect\n- What the streamed data actually looks like\n\n**Example**: For a diagram about a data transformation pipeline:\n- Show sample input data (actual format, not \"Input\")\n- Show sample output data (actual format, not \"Output\")\n- Show intermediate states if relevant\n\nThe key principle: **show what things actually look like**, not just what they're called.\n\n---\n\n## Multi-Zoom Architecture\n\nComprehensive diagrams operate at multiple zoom levels simultaneously. Think of it like a map that shows both the country borders AND the street names.\n\n### Level 1: Summary Flow\nA simplified overview showing the full pipeline or process at a glance. Often placed at the top or bottom of the diagram.\n\n*Example*: `Input → Processing → Output` or `Client → Server → Database`\n\n### Level 2: Section Boundaries\nLabeled regions that group related components. These create visual \"rooms\" that help viewers understand what belongs together.\n\n*Example*: Grouping by responsibility (Backend / Frontend), by phase (Setup / Execution / Cleanup), or by team (User / System / External)\n\n### Level 3: Detail Inside Sections\nEvidence artifacts, code snippets, and concrete examples within each section. This is where the educational value lives.\n\n*Example*: Inside a \"Backend\" section, you might show the actual API response format, not just a box labeled \"API Response\"\n\n**For comprehensive diagrams, aim to include all three levels.** The summary gives context, the sections organize, and the details teach.\n\n### Bad vs Good\n\n| Bad (Displaying) | Good (Arguing) |\n|------------------|----------------|\n| 5 equal boxes with labels | Each concept has a shape that mirrors its behavior |\n| Card grid layout | Visual structure matches conceptual structure |\n| Icons decorating text | Shapes that ARE the meaning |\n| Same container for everything | Distinct visual vocabulary per concept |\n| Everything in a box | Free-floating text with selective containers |\n\n### Simple vs Comprehensive (Know Which You Need)\n\n| Simple Diagram | Comprehensive Diagram |\n|----------------|----------------------|\n| Generic labels: \"Input\" → \"Process\" → \"Output\" | Specific: shows what the input/output actually looks like |\n| Named boxes: \"API\", \"Database\", \"Client\" | Named boxes + examples of actual requests/responses |\n| \"Events\" or \"Messages\" label | Timeline with real event/message names from the spec |\n| \"UI\" or \"Dashboard\" rectangle | Mockup showing actual UI elements and content |\n| ~30 seconds to explain | ~2-3 minutes of teaching content |\n| Viewer learns the structure | Viewer learns the structure AND the details |\n\n**Simple diagrams** are fine for abstract concepts, quick overviews, or when the audience already knows the details. **Comprehensive diagrams** are needed for technical architectures, tutorials, educational content, or when you want the diagram itself to teach.\n\n---\n\n## Container vs. Free-Floating Text\n\n**Not every piece of text needs a shape around it.** Default to free-floating text. Add containers only when they serve a purpose.\n\n| Use a Container When... | Use Free-Floating Text When... |\n|------------------------|-------------------------------|\n| It's the focal point of a section | It's a label or description |\n| It needs visual grouping with other elements | It's supporting detail or metadata |\n| Arrows need to connect to it | It describes something nearby |\n| The shape itself carries meaning (decision diamond, etc.) | Typography alone creates sufficient hierarchy |\n| It represents a distinct \"thing\" in the system | It's a section title, subtitle, or annotation |\n\n**Typography as hierarchy**: Use font size, weight, and color to create visual hierarchy without boxes. A 28px title doesn't need a rectangle around it.\n\n**The container test**: For each boxed element, ask \"Would this work as free-floating text?\" If yes, remove the container.\n\n---\n\n## Design Process (Do This BEFORE Generating JSON)\n\n### Step 0: Assess Depth Required\nBefore anything else, determine if this needs to be:\n- **Simple/Conceptual**: Abstract shapes, labels, relationships (mental models, philosophies)\n- **Comprehensive/Technical**: Concrete examples, code snippets, real data (systems, architectures, tutorials)\n\n**If comprehensive**: Do research first. Look up actual specs, formats, event names, APIs.\n\n### Step 1: Understand Deeply\nRead the content. For each concept, ask:\n- What does this concept **DO**? (not what IS it)\n- What relationships exist between concepts?\n- What's the core transformation or flow?\n- **What would someone need to SEE to understand this?** (not just read about)\n\n### Step 2: Map Concepts to Patterns\nFor each concept, find the visual pattern that mirrors its behavior:\n\n| If the concept... | Use this pattern |\n|-------------------|------------------|\n| Spawns multiple outputs | **Fan-out** (radial arrows from center) |\n| Combines inputs into one | **Convergence** (funnel, arrows merging) |\n| Has hierarchy/nesting | **Tree** (lines + free-floating text) |\n| Is a sequence of steps | **Timeline** (line + dots + free-floating labels) |\n| Loops or improves continuously | **Spiral/Cycle** (arrow returning to start) |\n| Is an abstract state or context | **Cloud** (overlapping ellipses) |\n| Transforms input to output | **Assembly line** (before → process → after) |\n| Compares two things | **Side-by-side** (parallel with contrast) |\n| Separates into phases | **Gap/Break** (visual separation between sections) |\n\n### Step 3: Ensure Variety\nFor multi-concept diagrams: **each major concept must use a different visual pattern**. No uniform cards or grids.\n\n### Step 4: Sketch the Flow\nBefore JSON, mentally trace how the eye moves through the diagram. There should be a clear visual story.\n\n### Step 5: Generate JSON\nOnly now create the Excalidraw elements. **See below for how to handle large diagrams.**\n\n### Step 6: Render & Validate (MANDATORY)\nAfter generating the JSON, you MUST run the render-view-fix loop until the diagram looks right. This is not optional — see the **Render & Validate** section below for the full process.\n\n---\n\n## Large / Comprehensive Diagram Strategy\n\n**For comprehensive or technical diagrams, you MUST build the JSON one section at a time.** Do NOT attempt to generate the entire file in a single pass. This is a hard constraint — Claude Code has a ~32,000 token output limit per response, and a comprehensive diagram easily exceeds that in one shot. Even if it didn't, generating everything at once leads to worse quality. Section-by-section is better in every way.\n\n### The Section-by-Section Workflow\n\n**Phase 1: Build each section**\n\n1. **Create the base file** with the JSON wrapper (`type`, `version`, `appState`, `files`) and the first section of elements.\n2. **Add one section per edit.** Each section gets its own dedicated pass — take your time with it. Think carefully about the layout, spacing, and how this section connects to what's already there.\n3. **Use descriptive string IDs** (e.g., `\"trigger_rect\"`, `\"arrow_fan_left\"`) so cross-section references are readable.\n4. **Namespace seeds by section** (e.g., section 1 uses 100xxx, section 2 uses 200xxx) to avoid collisions.\n5. **Update cross-section bindings** as you go. When a new section's element needs to bind to an element from a previous section (e.g., an arrow connecting sections), edit the earlier element's `boundElements` array at the same time.\n\n**Phase 2: Review the whole**\n\nAfter all sections are in place, read through the complete JSON and check:\n- Are cross-section arrows bound correctly on both ends?\n- Is the overall spacing balanced, or are some sections cramped while others have too much whitespace?\n- Do IDs and bindings all reference elements that actually exist?\n\nFix any alignment or binding issues before rendering.\n\n**Phase 3: Render & validate**\n\nNow run the render-view-fix loop from the Render & Validate section. This is where you'll catch visual issues that aren't obvious from JSON — overlaps, clipping, imbalanced composition.\n\n### Section Boundaries\n\nPlan your sections around natural visual groupings from the diagram plan. A typical large diagram might split into:\n\n- **Section 1**: Entry point / trigger\n- **Section 2**: First decision or routing\n- **Section 3**: Main content (hero section — may be the largest single section)\n- **Section 4-N**: Remaining phases, outputs, etc.\n\nEach section should be independently understandable: its elements, internal arrows, and any cross-references to adjacent sections.\n\n### What NOT to Do\n\n- **Don't generate the entire diagram in one response.** You will hit the output token limit and produce truncated, broken JSON. Even if the diagram is small enough to fit, splitting into sections produces better results.\n- **Don't use a coding agent** to generate the JSON. The agent won't have sufficient context about the skill's rules, and the coordination overhead negates any benefit.\n- **Don't write a Python generator script.** The templating and coordinate math seem helpful but introduce a layer of indirection that makes debugging harder. Hand-crafted JSON with descriptive IDs is more maintainable.\n\n---\n\n## Visual Pattern Library\n\n### Fan-Out (One-to-Many)\nCentral element with arrows radiating to multiple targets. Use for: sources, PRDs, root causes, central hubs.\n```\n        ○\n       ↗\n  □ → ○\n       ↘\n        ○\n```\n\n### Convergence (Many-to-One)\nMultiple inputs merging through arrows to single output. Use for: aggregation, funnels, synthesis.\n```\n  ○ ↘\n  ○ → □\n  ○ ↗\n```\n\n### Tree (Hierarchy)\nParent-child branching with connecting lines and free-floating text (no boxes needed). Use for: file systems, org charts, taxonomies.\n```\n  label\n  ├── label\n  │   ├── label\n  │   └── label\n  └── label\n```\nUse `line` elements for the trunk and branches, free-floating text for labels.\n\n### Spiral/Cycle (Continuous Loop)\nElements in sequence with arrow returning to start. Use for: feedback loops, iterative processes, evolution.\n```\n  □ → □\n  ↑     ↓\n  □ ← □\n```\n\n### Cloud (Abstract State)\nOverlapping ellipses with varied sizes. Use for: context, memory, conversations, mental states.\n\n### Assembly Line (Transformation)\nInput → Process Box → Output with clear before/after. Use for: transformations, processing, conversion.\n```\n  ○○○ → [PROCESS] → □□□\n  chaos              order\n```\n\n### Side-by-Side (Comparison)\nTwo parallel structures with visual contrast. Use for: before/after, options, trade-offs.\n\n### Gap/Break (Separation)\nVisual whitespace or barrier between sections. Use for: phase changes, context resets, boundaries.\n\n### Lines as Structure\nUse lines (type: `line`, not arrows) as primary structural elements instead of boxes:\n- **Timelines**: Vertical or horizontal line with small dots (10-20px ellipses) at intervals, free-floating labels beside each dot\n- **Tree structures**: Vertical trunk line + horizontal branch lines, with free-floating text labels (no boxes needed)\n- **Dividers**: Thin dashed lines to separate sections\n- **Flow spines**: A central line that elements relate to, rather than connecting boxes\n\n```\nTimeline:           Tree:\n  ●─── Label 1        │\n  │                   ├── item\n  ●─── Label 2        │   ├── sub\n  │                   │   └── sub\n  ●─── Label 3        └── item\n```\n\nLines + free-floating text often creates a cleaner result than boxes + contained text.\n\n---\n\n## Shape Meaning\n\nChoose shape based on what it represents—or use no shape at all:\n\n| Concept Type | Shape | Why |\n|--------------|-------|-----|\n| Labels, descriptions, details | **none** (free-floating text) | Typography creates hierarchy |\n| Section titles, annotations | **none** (free-floating text) | Font size/weight is enough |\n| Markers on a timeline | small `ellipse` (10-20px) | Visual anchor, not container |\n| Start, trigger, input | `ellipse` | Soft, origin-like |\n| End, output, result | `ellipse` | Completion, destination |\n| Decision, condition | `diamond` | Classic decision symbol |\n| Process, action, step | `rectangle` | Contained action |\n| Abstract state, context | overlapping `ellipse` | Fuzzy, cloud-like |\n| Hierarchy node | lines + text (no boxes) | Structure through lines |\n\n**Rule**: Default to no container. Add shapes only when they carry meaning. Aim for <30% of text elements to be inside containers.\n\n---\n\n## Color as Meaning\n\nColors encode information, not decoration. Every color choice should come from `references/color-palette.md` — the semantic shape colors, text hierarchy colors, and evidence artifact colors are all defined there.\n\n**Key principles:**\n- Each semantic purpose (start, end, decision, AI, error, etc.) has a specific fill/stroke pair\n- Free-floating text uses color for hierarchy (titles, subtitles, details — each at a different level)\n- Evidence artifacts (code snippets, JSON examples) use their own dark background + colored text scheme\n- Always pair a darker stroke with a lighter fill for contrast\n\n**Do not invent new colors.** If a concept doesn't fit an existing semantic category, use Primary/Neutral or Secondary.\n\n---\n\n## Modern Aesthetics\n\nFor clean, professional diagrams:\n\n### Roughness\n- `roughness: 0` — Clean, crisp edges. Use for modern/technical diagrams.\n- `roughness: 1` — Hand-drawn, organic feel. Use for brainstorming/informal diagrams.\n\n**Default to 0** for most professional use cases.\n\n### Stroke Width\n- `strokeWidth: 1` — Thin, elegant. Good for lines, dividers, subtle connections.\n- `strokeWidth: 2` — Standard. Good for shapes and primary arrows.\n- `strokeWidth: 3` — Bold. Use sparingly for emphasis (main flow line, key connections).\n\n### Opacity\n**Always use `opacity: 100` for all elements.** Use color, size, and stroke width to create hierarchy instead of transparency.\n\n### Small Markers Instead of Shapes\nInstead of full shapes, use small dots (10-20px ellipses) as:\n- Timeline markers\n- Bullet points\n- Connection nodes\n- Visual anchors for free-floating text\n\n---\n\n## Layout Principles\n\n### Hierarchy Through Scale\n- **Hero**: 300×150 - visual anchor, most important\n- **Primary**: 180×90\n- **Secondary**: 120×60\n- **Small**: 60×40\n\n### Whitespace = Importance\nThe most important element has the most empty space around it (200px+).\n\n### Flow Direction\nGuide the eye: typically left→right or top→bottom for sequences, radial for hub-and-spoke.\n\n### Connections Required\nPosition alone doesn't show relationships. If A relates to B, there must be an arrow.\n\n---\n\n## Text Rules\n\n**CRITICAL**: The JSON `text` property contains ONLY readable words.\n\n```json\n{\n  \"id\": \"myElement1\",\n  \"text\": \"Start\",\n  \"originalText\": \"Start\"\n}\n```\n\nSettings: `fontSize: 16`, `fontFamily: 3`, `textAlign: \"center\"`, `verticalAlign: \"middle\"`\n\n---\n\n## JSON Structure\n\n```json\n{\n  \"type\": \"excalidraw\",\n  \"version\": 2,\n  \"source\": \"https://excalidraw.com\",\n  \"elements\": [...],\n  \"appState\": {\n    \"viewBackgroundColor\": \"#ffffff\",\n    \"gridSize\": 20\n  },\n  \"files\": {}\n}\n```\n\n## Element Templates\n\nSee `references/element-templates.md` for copy-paste JSON templates for each element type (text, line, dot, rectangle, arrow). Pull colors from `references/color-palette.md` based on each element's semantic purpose.\n\n---\n\n## Render & Validate (MANDATORY)\n\nYou cannot judge a diagram from JSON alone. After generating or editing the Excalidraw JSON, you MUST render it to PNG, view the image, and fix what you see — in a loop until it's right. This is a core part of the workflow, not a final check.\n\n### How to Render\n\n```bash\ncd .claude/skills/excalidraw-diagram/references && uv run python render_excalidraw.py <path-to-file.excalidraw>\n```\n\nThis outputs a PNG next to the `.excalidraw` file. Then use the **Read tool** on the PNG to actually view it.\n\n### The Loop\n\nAfter generating the initial JSON, run this cycle:\n\n**1. Render & View** — Run the render script, then Read the PNG.\n\n**2. Audit against your original vision** — Before looking for bugs, compare the rendered result to what you designed in Steps 1-4. Ask:\n- Does the visual structure match the conceptual structure you planned?\n- Does each section use the pattern you intended (fan-out, convergence, timeline, etc.)?\n- Does the eye flow through the diagram in the order you designed?\n- Is the visual hierarchy correct — hero elements dominant, supporting elements smaller?\n- For technical diagrams: are the evidence artifacts (code snippets, data examples) readable and properly placed?\n\n**3. Check for visual defects:**\n- Text clipped by or overflowing its container\n- Text or shapes overlapping other elements\n- Arrows crossing through elements instead of routing around them\n- Arrows landing on the wrong element or pointing into empty space\n- Labels floating ambiguously (not clearly anchored to what they describe)\n- Uneven spacing between elements that should be evenly spaced\n- Sections with too much whitespace next to sections that are too cramped\n- Text too small to read at the rendered size\n- Overall composition feels lopsided or unbalanced\n\n**4. Fix** — Edit the JSON to address everything you found. Common fixes:\n- Widen containers when text is clipped\n- Adjust `x`/`y` coordinates to fix spacing and alignment\n- Add intermediate waypoints to arrow `points` arrays to route around elements\n- Reposition labels closer to the element they describe\n- Resize elements to rebalance visual weight across sections\n\n**5. Re-render & re-view** — Run the render script again and Read the new PNG.\n\n**6. Repeat** — Keep cycling until the diagram passes both the vision check (Step 2) and the defect check (Step 3). Typically takes 2-4 iterations. Don't stop after one pass just because there are no critical bugs — if the composition could be better, improve it.\n\n### When to Stop\n\nThe loop is done when:\n- The rendered diagram matches the conceptual design from your planning steps\n- No text is clipped, overlapping, or unreadable\n- Arrows route cleanly and connect to the right elements\n- Spacing is consistent and the composition is balanced\n- You'd be comfortable showing it to someone without caveats\n\n### First-Time Setup\nIf the render script hasn't been set up yet:\n```bash\ncd .claude/skills/excalidraw-diagram/references\nuv sync\nuv run playwright install chromium\n```\n\n---\n\n## Batch Generation\n\nWhen generating multiple related diagrams with consistent styling (e.g., a series of article illustrations):\n\n1. **Load color palette once** — Read `references/color-palette.md` at the start and keep the color assignments in mind for all diagrams.\n2. **Use consistent seed namespacing** — Prefix seeds with the diagram number (e.g., `160xxx` for diagram 16, `170xxx` for diagram 17) to avoid collisions across files.\n3. **Create all `.excalidraw` files first, then batch render** — Write each diagram JSON, then render all in sequence. This is more efficient than the create-render-validate loop per diagram when working at scale.\n4. **When vision is unavailable** — If the current model lacks vision capability, you cannot execute the render-validate loop. In this case:\n   - Still render each diagram (the PNG is the deliverable).\n   - Rely on careful JSON construction: verify element coordinates don't overlap, text fits within container bounds (compare `width`/`height` against `text` length × `fontSize`), and arrows connect to valid element IDs.\n   - Inform the user that visual validation was skipped and they should review the PNGs.\n   - Return to validate once vision is available.\n5. **Maintain a shared style vocabulary** — When diagrams are part of a series, use the same color semantic mapping across all (e.g., always use Decision yellow for questions, Success green for solutions).\n\n---\n\n## Pitfalls\n\n1. **Parallel hierarchy error**: When drawing classification/taxonomy diagrams, ensure child nodes are truly parallel (same level). Common mistake: placing some children as grandchildren of other children. Example: In a \"Bad Case Error Types\" diagram, \"format error\" and \"safety issue\" were incorrectly drawn as children of \"hallucination\" and \"retrieval failure\" — they should all be direct children of the root node. **Test**: Every arrow from the root should go to a sibling, not to a child of another sibling.\n\n2. **Count mismatch**: When the title specifies a count (e.g., \"Four Stages\"), ensure the diagram actually shows that many elements. Common mistake: title says \"four stages\" but diagram only shows three boxes. **Test**: Count the top-level elements and compare to the title.\n\n3. **Color coding without legend**: If using different colors for different categories, either add a legend or ensure the color mapping is obvious from context. Don't use 5 different colors without explaining what each means.\n\n4. **Fan-out arrows from root**: For classification diagrams, use fan-out pattern (arrows radiating from center) not tree pattern (sequential branching). Fan-out shows parallel siblings clearly; tree pattern implies hierarchy that may not exist.\n\n## Quality Checklist\n\n### Depth & Evidence (Check First for Technical Diagrams)\n1. **Research done**: Did you look up actual specs, formats, event names?\n2. **Evidence artifacts**: Are there code snippets, JSON examples, or real data?\n3. **Multi-zoom**: Does it have summary flow + section boundaries + detail?\n4. **Concrete over abstract**: Real content shown, not just labeled boxes?\n5. **Educational value**: Could someone learn something concrete from this?\n\n### Conceptual\n6. **Isomorphism**: Does each visual structure mirror its concept's behavior?\n7. **Argument**: Does the diagram SHOW something text alone couldn't?\n8. **Variety**: Does each major concept use a different visual pattern?\n9. **No uniform containers**: Avoided card grids and equal boxes?\n\n### Container Discipline\n10. **Minimal containers**: Could any boxed element work as free-floating text instead?\n11. **Lines as structure**: Are tree/timeline patterns using lines + text rather than boxes?\n12. **Typography hierarchy**: Are font size and color creating visual hierarchy (reducing need for boxes)?\n\n### Structural\n13. **Connections**: Every relationship has an arrow or line\n14. **Flow**: Clear visual path for the eye to follow\n15. **Hierarchy**: Important elements are larger/more isolated\n\n### Technical\n16. **Text clean**: `text` contains only readable words\n17. **Font**: `fontFamily: 3`\n18. **Roughness**: `roughness: 0` for clean/modern (unless hand-drawn style requested)\n19. **Opacity**: `opacity: 100` for all elements (no transparency)\n20. **Container ratio**: <30% of text elements should be inside containers\n\n### Visual Validation (Render Required)\n21. **Rendered to PNG**: Diagram has been rendered and visually inspected\n22. **No text overflow**: All text fits within its container\n23. **No overlapping elements**: Shapes and text don't overlap unintentionally\n24. **Even spacing**: Similar elements have consistent spacing\n25. **Arrows land correctly**: Arrows connect to intended elements without crossing others\n26. **Readable at export size**: Text is legible in the rendered PNG\n27. **Balanced composition**: No large empty voids or overcrowded regions\n\nFile v0.1.0:SKILL.md\n\n---\nname: software-copyright-skill\ndescription: 生成中国软件著作权（软著）登记申请文档。LLM驱动：分析项目代码、生成内容；Python脚本辅助：模板填充、格式保持。\nversion: 4.7.0\nauthor: hermes-agent\nhomepage: https://github.com/Foamtor/software-copyright-skill\nlicense: MIT\ntags: [软著, 软件著作权, 文档生成, python-docx, Word, 版权登记, 模板填充]\n---\n\n# 软著文档生成 Skill（模板驱动版）\n\n**核心原则**：模型输出JSON内容，脚本根据模板生成Word。格式100%由模板控制。\n\n**版本**：V4.7（2026-06-27更新）\n\n## 触发条件\n\n用户提到：软著、软件著作权、软著申请、软著文档、信息采集表、使用说明书、设计说明、源代码文档\n\n## 前置依赖\n\n```bash\npip install python-docx docxtpl lxml Pillow\n```\n\n## 网络代理配置（WSL环境）\n\n在WSL环境下，如果需要访问GitHub等外部服务，可能需要配置代理。\n\n### 自动检测代理\n\n```bash\n# 使用代理管理脚本自动检测并配置\n~/.hermes/scripts/proxy_manager.sh auto\n```\n\n### 手动配置代理\n\n```bash\n# 设置代理环境变量\nexport http_proxy=http://172.22.240.1:7897\nexport https_proxy=http://172.22.240.1:7897\n\n# 配置Git代理\ngit config --global http.proxy http://172.22.240.1:7897\ngit config --global http.version HTTP/1.1\n```\n\n### 代理不可用时\n\n如果代理不可用，可以：\n1. 启动宿主机Clash并开启\"Allow LAN\"\n2. 使用直连模式：`~/.hermes/scripts/proxy_manager.sh direct`\n3. 参考故障排除指南：`~/.hermes/scripts/proxy_troubleshooting.md`\n\n## 架构设计\n\n```\n┌─────────────┐     ┌─────────────────┐     ┌─────────────┐\n│  LLM 生成   │ ──→ │   content.json  │ ──→ │ docxtpl 渲染│\n│  JSON 内容   │     │  (结构化数据)    │     │  生成.docx  │\n└─────────────┘     └─────────────────┘     └─────────────┘\n                                                  ↑\n                                          templates/*.docx\n                                          (格式由模板控制)\n```\n\n**关键原则**：\n- 模型只输出JSON（内容），不接触格式\n- 格式由Word模板（.docx）控制\n- 用户给参考文档 → 提取格式 → 生成模板\n- 格式变化 = 换模板，不需要改代码\n\n## 配置格式\n\n**支持两种配置格式**（`generate_manual.py` 自动检测）：\n\n1. **Brand Profile**（推荐）：`config/brand_profile.json`\n   - 包含样式定义、内容规则、写作风格\n   - 可复用于多文档，易于版本控制\n   - 详见 `references/brand-profile-design.md`\n\n2. **旧格式**（兼容）：`config/format_spec.json`\n   - 扁平的样式定义\n   - 仍然支持，但建议迁移\n\n```bash\n# 使用Brand Profile\npython3 scripts/generate_manual.py --config config/brand_profile.json ...\n\n# 使用旧格式\npython3 scripts/generate_manual.py --config config/format_spec.json ...\n```\n\n## ⚠️ 职责分工：模型 vs 脚本\n\n**核心设计：模型负责生成和审阅，脚本负责验证和控制。**\n\n| 任务 | 执行者 | 说明 |\n|------|--------|------|\n| 扫描项目结构 | 🐍 脚本 | `scan_project.py` |\n| 生成大纲 | 🤖 模型 | 使用 `prompts/大纲生成.md` |\n| 生成章节内容 | 🤖 模型 | 使用 `prompts/章节生成.md` |\n| 审阅章节质量 | 🤖 模型 | 使用 `prompts/章节审阅.md` |\n| 检查基础质量 | 🐍 脚本 | `review_chapter.py`（字数、数量） |\n| 合并章节 | 🐍 脚本 | `merge_chapters.py` |\n| 验证内容质量 | 🐍 脚本 | `validate_content_quality.py` |\n| 生成Word文档 | 🐍 脚本 | `generate_manual.py` |\n| 验证格式 | 🐍 脚本 | `validate_output.py` |\n| 生成架构图 | 🤖+🐍 | excalidraw skill 生成JSON → render为PNG |\n| 插入图片 | 🐍 脚本 | `generate_manual.py --image-dir` |\n\n## ⚠️ 内容质量规范\n\n### 写作风格\n\n**软著说明书是用户操作指南，不是技术文档！**\n\n#### 正确写法\n```\n在系统首页，点击\"新建项目\"按钮，弹出新建项目对话框。如下图。\n图3 新建项目按钮\n\n在对话框中填写项目名称和项目描述，点击\"确定\"按钮，即可创建新项目。如下图。\n图4 新建项目对话框\n```\n\n#### 错误写法\n```\n一、项目管理功能：支持创建和管理项目，提供项目状态监控和版本控制能力。\n```\n\n### 内容质量要求\n\n| 要求 | 标准 | 检查方式 |\n|------|------|----------|\n| **总字数** | ≥15000字 | 🐍 `validate_content_quality.py` |\n| **章节数** | 6-10章 | 🐍 `validate_content_quality.py` |\n| **图片标记** | ≥13张（精简版） | 🐍 `validate_content_quality.py` |\n| **每章字数** | ≥1500字 | 🐍 `review_chapter.py` |\n| **每节字数** | ≥300字 | 🐍 `review_chapter.py` |\n| **每节images** | ≥1张 | 🐍 `review_chapter.py` |\n| **写作风格** | 用户操作指南 | 🤖 模型审阅（第一章跳过） |\n\n### 写作要点\n\n1. **面向用户操作**：描述用户点击什么按钮、填写什么内容、看到什么结果\n2. **语言简洁**：面向普通用户，不使用技术术语\n3. **必须有\"平台总体介绍\"章节**：第一章必须是平台总体介绍，包含：功能概述、总体架构、技术实现、数据流向\n   - ⚠️ 第一章是介绍性内容，不适用\"用户操作指南\"风格检查\n   - ⚠️ 第一章使用 `review_chapter.py --is-chapter1` 跳过写作风格检查\n\n### 配图策略（精简版）\n\n**核心原则**：只配必要的图，不配装饰性图\n\n#### 配图数量标准\n| 类型 | 数量 | 来源 |\n|------|------|------|\n| 系统总体架构图 | 1张 | 绘制（excalidraw） |\n| 功能模块截图 | 12-15张 | 截图（实际系统） |\n| **总计** | **13-16张** | - |\n\n#### 配图规则\n1. **每个功能模块配1-2张代表性截图**，不要为细节操作配图\n2. **不要配图的情况**：重复界面、弹窗提示、辅助功能\n3. **第一章使用excalidraw生成架构图**，不要用matplotlib\n4. **图名格式**：14pt字体、居中对齐（由post_process.py自动处理）\n5. **图片位置**：图片插入到图名**上方**（不是下方）\n\n#### 架构图生成命令\n```bash\n# 首次使用需安装依赖\ncd references/excalidraw-diagram\nuv sync && uv run playwright install chromium\n\n# 渲染架构图\nuv run python render_excalidraw.py <path>.excalidraw  # 输出同名.png\n```\n\n详细设计规范见 `references/excalidraw-diagram/SKILL.md`\n\n#### 各章配图建议\n| 章节 | 必须配图 | 可选配图 |\n|------|----------|----------|\n| 第一章：总体介绍 | 架构图、首页截图 | 功能入口截图 |\n| 第二章：登录与首页 | 登录页面、首页布局 | 搜索功能 |\n| 第三章：展览展会 | 展会列表、展会详情 | 展品详情 |\n| 第四章：帮扶服务 | 帮扶列表、帮扶申请 | 帮扶记录 |\n| 第五章：AI顾问 | AI对话页面、聊天历史 | 推荐内容 |\n| 第六章：地图查询 | 地图页面、位置搜索 | 导航功能 |\n| 第七章：个人中心 | 个人中心、设置页面 | 收藏管理 |\n\n#### 配图位置规则\n```\n✅ 正确：正文描述 → \"如下图。\" → 图片 → 图名\n❌ 错误：图片列表、图片在图名下方、图片与正文分离\n```\n\n**详细说明**：见 `references/image-strategy-simplified.md`（精简版）和 `references/配图生成最佳实践.md`（完整版）\n\n### JSON输出格式\n\n**content.json必须包含以下字段**：\n\n```json\n{\n  \"software_name\": \"国农臻汇APP\",\n  \"version\": \"V1.0\",\n  \"company\": \"农业农村部乡村振兴监测中心\",\n  \"cover\": {\n    \"title\": \"国农臻汇APPV1.0\",\n    \"subtitle\": \"用户使用手册\",\n    \"company\": \"农业农村部乡村振兴监测中心\",\n    \"date\": \"2025年9月\"\n  },\n  \"sections\": [\n    {\n      \"heading\": \"一、平台总体介绍\",\n      \"content\": \"\",\n      \"images\": [],\n      \"subsections\": [\n        {\n          \"heading\": \"（一）平台功能概述\",\n          \"content\": \"正文内容（不要包含图名）...\",\n          \"images\": [\n            {\"ref\": \"图8\", \"description\": \"系统总体架构图\", \"path\": \"系统总体架构图.png\"}\n          ]\n        }\n      ]\n    }\n  ]\n}\n```\n\n**⚠️ 关键规则**：\n\n1. **sections必须是层级结构**：一级标题（一、二、三...）→ subsections（（一）（二）...）\n2. **不要把图名写在content字段中** — 图名由脚本从images字段自动生成\n3. **images字段只保留有实际图片的图号** — 没有图片的不要写进去\n4. **不需要notes字段** — 注意事项已去掉\n5. **images中的path字段** — 指向实际图片文件名（在image-dir目录中）\n\n**⚠️ 模板结构**\n\n模板只包含heading和content，**不要**包含图片列表和注意事项循环：\n\n```\n✅ 正确模板：\n{% for section in sections %}\n{{section.heading}}\n{{section.content}}\n{% for sub in section.subsections %}\n{{sub.heading}}\n{{sub.content}}\n{% endfor %}\n{% endfor %}\n\n❌ 错误模板（不要用）：\n{% for img in section.images %}\n{{img.ref}} {{img.description}}   ← 这会生成图片列表\n{% endfor %}\n{% for note in section.notes %}\n注意：{{note}}                    ← 这会生成注意事项列表\n{% endfor %}\n```\n❌ 错误模板（不要用）：\n{% for img in section.images %}\n{{img.ref}} {{img.description}}   ← 这会生成图片列表\n{% endfor %}\n{% for note in section.notes %}\n注意：{{note}}                    ← 这会生成注意事项列表\n{% endfor %}\n```\n\n## 三份文档规格\n\n### 1. 信息采集表\n- 使用 `fill_template.py` 填充模板\n- 模板：`templates/info_template.docx`\n\n### 2. 使用说明书\n- 使用 `generate_manual.py` 生成\n- 模板：`templates/manual_template_standard.docx`\n- 模型输出：`content.json`\n- **⚠️ 内容字数要求：≥15000字**\n\n### 3. 源代码文档\n- 使用 `generate_code_doc.py` 生成\n- 每页≥50行，前30页+后30页，共60页\n\n## 工作流程\n\n### 阶段0：模板准备\n1. 检查是否有用户提供的参考文档\n2. 如果有：运行 create_template.py 提取格式，生成模板\n3. 如果没有：使用默认模板 `templates/manual_template_standard.docx`\n\n### 阶段1：项目分析\n1. 运行 scan_project.py 扫描项目结构\n2. 阅读关键文件（README、路由、主入口）\n3. 理解功能模块和业务逻辑\n\n### 阶段2：信息采集\n1. 从项目中提取软件名称、版本号、功能模块\n2. 展示给用户确认\n3. 生成 info.json\n\n### 阶段3：大纲生成\n1. 🤖 模型根据功能模块生成三级目录大纲\n2. 用户审阅确认\n3. 生成 outline.json\n\n### 阶段4：内容生成（迭代循环）\n\n**⚠️ 核心流程：生成 → 验证 → 修改 → 再验证（直到通过）**\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│ 第1轮：生成                                                  │\n│  1. 🤖 模型按章节分步生成JSON内容（使用 prompts/章节生成.md） │\n│  2. 🐍 脚本检查每章基础质量（review_chapter.py）              │\n│  3. 🐍 脚本验证整体内容质量（validate_content_quality.py）    │\n└─────────────────────────────────────────────────────────────┘\n                            ↓\n┌─────────────────────────────────────────────────────────────┐\n│ 第2轮：修改（如果验证不通过）                                 │\n│  4. 🤖 模型根据验证报告补充内容                               │\n│     - 字数不足：补充详细描述                                  │\n│     - 配图不足：补充图片标记                                  │\n│  5. 🐍 脚本再次验证内容质量                                   │\n└─────────────────────────────────────────────────────────────┘\n                            ↓\n┌─────────────────────────────────────────────────────────────┐\n│ 第N轮：重复修改直到验证通过                                   │\n│  6. 🐍 脚本合并所有章节（merge_chapters.py）                  │\n│  7. 🐍 生成架构图（excalidraw skill → render_excalidraw.py）  │\n└─────────────────────────────────────────────────────────────┘\n```\n\n**验证标准（精简版）：**\n| 指标 | 要求 | 检查脚本 |\n|------|------|----------|\n| 总字数 | ≥15000字 | validate_content_quality.py |\n| 章节数 | 6-10章 | validate_content_quality.py |\n| 配图数量 | ≥13张 | validate_content_quality.py |\n| 每章字数 | ≥1500字 | review_chapter.py |\n| 每节字数 | ≥300字 | review_chapter.py |\n\n**修改策略：**\n1. **字数不足**：补充详细描述，增加操作步骤、注意事项\n2. **配图不足**：在关键操作处添加\"如下图\"和图片标记\n3. **章节不足**：拆分或合并章节，保持6-10章\n\n**详细说明**：见 `phases/phase4-content.md` 和 `references/iterative-quality-workflow.md`\n\n### 阶段5：文档生成\n```bash\n# 一步完成：生成+后处理\npython3 scripts/generate_manual.py \\\n  --content content.json \\\n  --template templates/manual_template_standard.docx \\\n  --output output/说明书.docx \\\n  --config config/brand_profile.json \\\n  --image-dir images/\n```\n\n**generate_manual.py 已集成后处理**，自动完成：\n1. 分割长段落（确保首行缩进）\n2. 分割图名成独立段落（14pt居中）\n3. 在图名上方插入图片\n4. 删除连续空行\n5. 替换页眉页脚占位符，添加页码\n6. 应用格式（跳过封面段落）\n\n**⚠️ 独立后处理脚本**：`post_process.py` 仍然可用，用于对已有文档进行后处理。\n\n### 阶段6：审阅提交\n1. 检查三份文档完整性\n2. 统计页数、字数\n3. 🐍 检查内容质量指标\n4. 生成提交清单\n\n## 脚本清单\n\n| 脚本 | 功能 | 输入 | 输出 |\n|------|------|------|------|\n| `generate_manual.py` | 生成说明书（含后处理） | content.json + 模板 | 说明书.docx |\n| `post_process.py` | 独立后处理脚本 | 说明书_raw.docx + content.json | 说明书.docx |\n| `review_chapter.py` | 单章质量检查 | chapter.json | 检查结果（支持 `--is-chapter1`） |\n| `validate_content_quality.py` | 内容质量验证 | content.json 或 chapters/ | 验证报告 |\n| `validate_output.py` | 格式验证 | 说明书.docx | 验证报告 |\n| `merge_chapters.py` | 合并章节 | chapters/ | content.json |\n| `scan_project.py` | 扫描项目结构 | 项目路径 | project_info.json |\n| `create_template.py` | 从参考文档创建模板 | 参考.docx | 模板.docx |\n| `create_standard_template.py` | 创建标准模板 | format_spec.json | 模板.docx |\n| `fill_template.py` | 填充信息采集表 | info.json + 模板.docx | 采集表.docx |\n| `generate_code_doc.py` | 生成代码文档 | 项目路径 | 代码文档.docx |\n| `utils.py` | 公共工具函数库 | - | 被其他脚本导入 |\n| `test_generate.py` | TDD测试套件 | - | 测试结果 |\n\n### 测试脚本\n\n| 脚本 | 功能 | 运行方式 |\n|------|------|----------|\n| `scripts/test_generate.py` | TDD测试套件 | `python3 scripts/test_generate.py` |\n\n**测试覆盖**：\n- 单元测试：count_chars, extract_figure_refs, has_figure_caption, validate_content, brand_profile_loading, brand_profile_to_format_spec\n- 集成测试：generate_manual.py完整流程\n- 验收测试：文档符合Brand Profile规范\n\n## 使用示例\n\n```bash\n# 1. 扫描项目\npython3 scripts/scan_project.py --path /path/to/project --output project_info.json\n\n# 2. 生成文档（一步完成：生成+后处理）\npython3 scripts/generate_manual.py \\\n  --content content.json \\\n  --template templates/manual_template_standard.docx \\\n  --output output/说明书.docx \\\n  --config config/brand_profile.json \\\n  --image-dir images/\n\n# 3. 验证格式\npython3 scripts/validate_output.py --docx output/说明书.docx\n\n# 4. 验证内容质量\npython3 scripts/validate_content_quality.py --content content.json\n\n# 5. 检查单章质量（第一章使用 --is-chapter1 标志）\npython3 scripts/review_chapter.py --chapter chapters/chapter1.json --is-chapter1\npython3 scripts/review_chapter.py --chapter chapters/chapter2.json\n\n# 6. 运行TDD测试\npython3 tests/test_generate.py\n```\n\n## ⚠️ 关键规则（按优先级排序）\n\n### P0：绝对规则\n1. **必须输出.docx** — 绝对不要输出.md文件\n2. **模型只输出JSON** — 不要让模型直接生成Word内容\n3. **格式由模板控制** — 不要在JSON中包含格式信息\n4. **content.json必须包含cover字段** — 否则封面标题为空\n5. **模板不要有图片列表和注意事项循环** — 使用 `manual_template_standard.docx`\n\n### P1：内容质量规则\n6. **写作风格** — 必须是用户操作指南风格，不是技术文档\n7. **分步生成** — 说明书必须按章节分步生成，每章自动审阅后再继续\n\n### P2：流程规则\n8. **上下文传递** — 每章生成时传入前几章摘要，保持内容一致性\n9. **断点续传** — 每章保存到独立JSON文件，中断后可从上次位置继续\n10. **验证输出** — 生成后必须用validate_output.py验证格式\n\n## ⚠️ 致命陷阱（必须避免）\n\n这些是手动验证中发现的真实bug，每个都会导致文档格式崩溃：\n\n### P0：绝对致命\n\n| # | 陷阱 | 后果 | 正确做法 |\n|---|------|------|----------|\n| 1 | **模板有图片列表循环** `{% for img %}` | 文档出现\"图1 xxx\"文字列表 | 模板不要有图片循环，图名由脚本生成 |\n| 2 | **模板有注意事项循环** `{% for note %}` | 文档出现\"注意事项：xxx\" | 模板不要有注意事项循环 |\n| 3 | **content字段中写图名** | 图名重复两行 | 图名只在images字段，不在content中 |\n| 4 | **content字段中写注意事项** | 注意事项无法删除 | content中不要写\"注意事项：\" |\n| 5 | **sections没有层级** | 缺少\"一、平台总体介绍\"标题 | sections必须是一、→（一）→（二）层级 |\n| 6 | **图片插入到图名下方** | 图片位置错误 | 用 `addprevious()` 在图名**上方**插入 |\n| 7 | **apply_formatting覆盖封面** | 封面格式被破坏 | 跳过第一个Heading 1之前的段落 |\n\n### P1：格式问题\n\n| # | 陷阱 | 后果 | 正确做法 |\n|---|------|------|----------|\n| 8 | **Jinja2标记变空行** | 标题间有多余空行 | `post_process.py` 删除连续空行 |\n| 9 | **长段落不分割** | 首行缩进丢失 | `post_process.py` 分割长段落 |\n| 10 | **图名混在正文中** | 无法单独设置格式 | `post_process.py` 分割图名成独立段落 |\n| 11 | **两端对齐** | 中文字间距被拉大 | 正文用左对齐(left)，不用justify |\n| 12 | **页眉页脚占位符未替换** | 显示\"{software_name}\" | `replace_header_footer()` 替换 |\n\n### P2：内容问题\n\n| # | 陷阱 | 后果 | 正确做法 |\n|---|------|------|----------|\n| 13 | **图片只保留有实际文件的** | 空图片标记 | images字段只放有path的图号 |\n| 14 | **用matplotlib生成架构图** | 样式不专业 | 用excalidraw skill生成 |\n| 15 | **为小板块单独配图** | 图片过多 | 按功能模块整体配图，精简到13-16张 |\n| 16 | **content.json缺少software_name** | 封面标题为空 | 必须有cover.title或software_name |\n\n**详见**：`references/V4.3验证问题清单.md` — 16个问题的完整修复方案\n\n## 常见问题与解决方案\n\n详见 `references/常见问题与解决方案.md`\n\n## 参考文档\n\n- `references/brand-profile-design.md` — **新增**：Brand Profile设计（借鉴brand-docs）\n- `references/专业审阅报告-V4.4.md` — **必读**：专业审阅报告，设计评分、优化路线图\n- `references/短期优化结果.md` — 短期优化完成情况，utils.py函数清单\n- `references/docxtpl后处理必知必会.md` — **必读**：后处理逻辑、content.json规则、模板设计原则\n- `references/V4.3验证问题清单.md` — 手动验证发现的16个问题及修复方案\n- `references/常见问题与解决方案.md` — 所有已知问题和修复方案\n- `references/配图生成最佳实践.md` — 配图方案（excalidraw > matplotlib）\n- `references/模板驱动架构设计.md` — docxtpl方案详解\n- `references/内容质量保障规范.md` — 内容质量指标、写作风格\n\nFile v0.1.0:examples/demo/README.md\n\n# 示例项目\n\n这是一个示例项目结构，用于演示 `software-copyright-skill` 的使用。\n\n## 使用方法\n\n1. 将此目录替换为你的实际项目\n2. 在AI Agent中说：\"帮我为当前项目生成软著文档\"\n3. 按照Agent引导完成信息确认和文档生成\n\n## 示例项目结构\n\n```\nmy-project/\n├── README.md\n├── package.json\n├── src/\n│   ├── main.ts\n│   ├── router/\n│   │   └── index.ts\n│   ├── views/\n│   │   ├── Home.vue\n│   │   ├── Login.vue\n│   │   └── Dashboard.vue\n│   ├── components/\n│   │   └── ...\n│   └── api/\n│       └── index.ts\n├── backend/\n│   └── src/\n│       ├── main.py\n│       ├── routes/\n│       ├── services/\n│       └── models/\n└── docs/\n    └── ...\n```\n\nFile v0.1.0:README.md\n\n# 📋 软件著作权文档生成 Skill\n\n> AI Agent 驱动的中国软著申请文档自动生成工具。分析项目代码，自动生成信息采集表、使用说明书和源代码文档。\n\n## ✨ 功能特性\n\n- 🔍 **智能扫描** — 自动识别项目技术栈、功能模块、业务逻辑\n- 📝 **采集表生成** — 交互式确认信息，自动填充Word模板\n- 📖 **说明书撰写** — 分章节生成用户操作指南风格的说明书\n- 💻 **代码提取** — 按优先级提取核心代码，生成前30页+后30页\n- 🎯 **格式合规** — 严格遵循版权中心的字号、字体、排版要求\n- 🎨 **Brand Profile** — JSON格式的样式定义，支持复用和版本控制\n- 📊 **内容质量验证** — 自动检查字数、配图、格式等质量指标\n- 🔄 **迭代优化** — 支持\"生成→验证→修改→再验证\"循环\n- 🧪 **TDD测试** — 完整的测试套件，确保代码质量\n\n## 🚀 快速开始\n\n### 安装\n\n```bash\n# 通用安装（支持所有主流AI Agent）\nnpx skills add Foamtor/software-copyright-skill\n\n# OpenClaw（龙虾）用户\nopenclaw skills install Foamtor/software-copyright-skill\n```\n\n### 安装Python依赖\n\n```bash\npip install python-docx docxtpl lxml Pillow\n```\n\n### 安装架构图渲染依赖（可选，生成架构图时需要）\n\n```bash\ncd references/excalidraw-diagram\nuv sync\nuv run playwright install chromium\n```\n\n### 使用\n\n在你的AI Agent中输入：\n\n```\n帮我为当前项目生成软著文档\n```\n\nAgent会自动：\n1. 扫描项目结构\n2. 确认软件信息\n3. 生成使用说明书大纲\n4. 分章节撰写内容\n5. 提取源代码文档\n6. 输出三份Word文档\n\n## 🤖 支持的AI Agent\n\n| Agent | 安装方式 | 状态 |\n|-------|---------|------|\n| [Hermes Agent](https://hermes-agent.nousresearch.com) | `npx skills add` | ✅ |\n| [Claude Code](https://docs.anthropic.com/claude-code) | `npx skills add` | ✅ |\n| [Cursor](https://cursor.sh) | `npx skills add` | ✅ |\n| [Codex CLI](https://github.com/openai/codex) | `npx skills add` | ✅ |\n| [OpenClaw（龙虾）](https://openclaw.ai) | `openclaw skills install` | ✅ |\n\n所有平台使用同一个 `SKILL.md` 文件，遵循 [AgentSkills](https://github.com/vercel-labs/skills) 规范。\n\n## 📁 生成文档说明\n\n### 信息采集表\n- 软件基本信息（名称、版本号、开发方式等）\n- 开发与运行环境（硬件、操作系统、编程语言等)\n- 功能特点描述（每项50字以内）\n\n### 使用说明书\n- 用户操作指南风格（不是技术文档）\n- 按功能模块组织，含截图占位\n- 每页≥30行，前30页+后30页\n- 第一章必须是平台总体介绍\n\n### 源代码文档\n- 按优先级提取：主入口→路由→核心→公共→API→工具\n- 每页≥50行，前30页+后30页\n- 自动排除第三方库和构建产物\n\n## 🔧 独立使用（不通过Agent）\n\n```bash\n# 扫描项目\npython3 scripts/scan_project.py --path ./my-project --output ./output/project_info.json\n\n# 填充信息采集表\npython3 scripts/fill_template.py \\\n  --template templates/信息采集表模板.docx \\\n  --content ./output/采集表内容.json \\\n  --output ./output/信息采集表.docx\n\n# 生成说明书章节\npython3 scripts/generate_manual.py \\\n  --content ./output/第1章内容.json \\\n  --output ./output/说明书_第1章.docx\n\n# 生成代码文档\npython3 scripts/generate_code_doc.py \\\n  --project ./my-project \\\n  --files ./output/文件列表.json \\\n  --output ./output/代码文档.docx \\\n  --software-name \"我的系统V1.0\" \\\n  --version \"V1.0\"\n\n# 合并章节\npython3 scripts/merge_chapters.py \\\n  --chapters ./output/说明书_第*.docx \\\n  --output ./output/使用说明书.docx \\\n  --software-name \"我的系统V1.0\" \\\n  --version \"V1.0\"\n```\n\n## 📚 参考文档\n\n- [格式规范](references/格式规范.md) — Word排版格式 + 写作风格要求\n- [信息采集表填写要求](references/信息采集表填写要求.md) — 各字段字数限制和填写规范\n- [常见问题](references/常见问题.md) — 实际使用中的问题和解决方案\n\n## 📄 许可证\n\n[MIT License](LICENSE)\n\n## 🙏 致谢\n\n- [python-docx](https://github.com/python-openxml/python-docx) — Word文档操作\n- [AgentSkills](https://github.com/vercel-labs/skills) — 统一的AI Agent Skill标准\n\nFile v0.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn75e2jfgr4k98gjc69je6j8dx8ct6tf\",\n  \"slug\": \"software-copyright-skill\",\n  \"version\": \"0.1.0\",\n  \"publishedAt\": 1787212705184\n}\n\nFile v0.1.0:references/brand-profile-design.md\n\n# Brand Profile 设计文档\n\n## 概念来源\n\n借鉴 [brand-docs](https://github.com/brand-docs)（195⭐）的核心概念：\n- **IntermediateDocument**：纯语义JSON，不含格式信息\n- **Brand Profile**：JSON格式的样式定义，可复用、可版本控制\n- **确定性引擎**：相同输入 → 相同输出\n\n## 与旧格式对比\n\n| 维度 | 旧格式 (format_spec.json) | Brand Profile |\n|------|---------------------------|---------------|\n| 结构 | 扁平的样式定义 | 分层的样式+规则+风格 |\n| 复用性 | 低（每个项目独立） | 高（可跨项目复用） |\n| 可读性 | 中 | 高 |\n| 扩展性 | 低 | 高（可添加新字段） |\n\n## Brand Profile 结构\n\n```json\n{\n  \"brand_info\": {\n    \"name\": \"农业农村部乡村振兴监测中心\",\n    \"description\": \"软著说明书标准格式\"\n  },\n  \"styles\": {\n    \"cover_title\": { \"font\": {...}, \"paragraph\": {...} },\n    \"heading1\": { \"font\": {...}, \"paragraph\": {...} },\n    \"body\": { \"font\": {...}, \"paragraph\": {...} },\n    \"figure_caption\": { \"font\": {...}, \"paragraph\": {...} }\n  },\n  \"content_rules\": {\n    \"min_total_chars\": 15000,\n    \"min_chapter_chars\": 1500,\n    \"min_images\": 13\n  },\n  \"writing_style\": {\n    \"type\": \"user_guide\",\n    \"rules\": [...]\n  }\n}\n```\n\n## 使用方式\n\n```bash\n# generate_manual.py 自动检测配置格式\npython3 scripts/generate_manual.py \\\n  --config config/brand_profile.json \\\n  --content content.json \\\n  --output output.docx\n```\n\n## 转换函数\n\n`utils.py` 提供 `brand_profile_to_format_spec()` 函数，将Brand Profile转换为旧格式以保持兼容。\n\n## 设计原则\n\n1. **样式与内容分离** — Brand Profile只定义样式，不包含内容\n2. **可复用** — 同一品牌的多文档可以共享Brand Profile\n3. **可版本控制** — JSON格式易于diff和merge\n4. **向后兼容** — 自动检测格式，支持旧格式\n\nFile v0.1.0:references/brand-profile-pattern.md\n\n# Brand Profile 设计模式\n\n## 概念来源\n\n借鉴 [brand-docs](https://github.com/brand-docs) (195⭐) 的核心概念：\n- **IntermediateDocument**: 纯语义JSON，不含格式信息\n- **Brand Profile**: JSON格式的样式定义，可复用、可版本控制\n- **确定性引擎**: 相同输入 → 相同输出\n\n## 与 docxtpl 的对比\n\n| 维度 | docxtpl (当前) | Brand Profile (借鉴) |\n|------|----------------|---------------------|\n| 格式定义 | Word模板 (.docx) | JSON配置文件 |\n| 渲染引擎 | Jinja2模板引擎 | 确定性引擎 |\n| 格式一致性 | 依赖模板质量 | 100%确定性 |\n| 可版本控制 | 二进制文件diff困难 | JSON文本diff容易 |\n\n## 实现方式\n\n我们**部分借鉴**了Brand Profile概念：\n- ✅ 将格式定义从Word模板迁移到JSON (`config/brand_profile.json`)\n- ✅ 支持Brand Profile和旧格式两种配置\n- ❌ 没有实现确定性引擎（继续使用docxtpl）\n\n## Brand Profile 结构\n\n```json\n{\n  \"brand_info\": { \"name\": \"...\", \"version\": \"...\" },\n  \"styles\": {\n    \"cover_title\": { \"font\": {...}, \"paragraph\": {...} },\n    \"heading1\": { \"font\": {...}, \"paragraph\": {...} },\n    \"body\": { \"font\": {...}, \"paragraph\": {...} },\n    \"figure_caption\": { \"font\": {...}, \"paragraph\": {...} }\n  },\n  \"content_rules\": {\n    \"min_total_chars\": 15000,\n    \"min_chapter_chars\": 1500,\n    \"min_images\": 13\n  },\n  \"writing_style\": {\n    \"type\": \"user_guide\",\n    \"rules\": [...]\n  }\n}\n```\n\n## 使用方式\n\n```bash\n# 使用Brand Profile\npython3 scripts/generate_manual.py \\\n  --config config/brand_profile.json ...\n\n# 使用旧格式（兼容）\npython3 scripts/generate_manual.py \\\n  --config config/format_spec.json ...\n```\n\n## 兼容性\n\n`brand_profile_to_format_spec()` 函数将Brand Profile转换为旧的format_spec格式，确保向后兼容。\n\nFile v0.1.0:references/docxtpl-post-processing-pitfalls.md\n\n# docxtpl Post-Processing Pitfalls\n\n## Why Post-Processing is Needed\n\ndocxtpl renders Jinja2 templates into Word documents, but several issues require post-processing:\n\n## Pitfall 1: Long Paragraphs with `\\n`\n\n**Problem**: When `content` field contains `\\n` (newlines), docxtpl puts the entire text into a single paragraph. Only the first line gets first-line indent.\n\n**Solution**: `split_long_paragraphs()` — split each `\\n` into a separate paragraph, copying format from the original.\n\n```python\n# In content.json:\n\"content\": \"第一段内容。\\n第二段内容。\\n第三段内容。\"\n\n# After docxtpl render: ONE paragraph with all text\n# After post_process: THREE paragraphs, each with proper indent\n```\n\n## Pitfall 2: Jinja2 Tags Become Empty Lines\n\n**Problem**: `{% for %}` and `{% endfor %}` tags in the template become empty paragraphs after rendering.\n\n**Solution**: `remove_consecutive_empty_lines()` — delete consecutive empty paragraphs, keeping only one.\n\n```\nBefore: [Heading 1] → [empty] → [empty] → [Heading 2]\nAfter:  [Heading 1] → [empty] → [Heading 2]\n```\n\n## Pitfall 3: Figure Captions Embedded in Content\n\n**Problem**: Figure captions (e.g., \"图8 系统总体架构图\") are part of the `content` text, not separate paragraphs. This prevents:\n- Setting different font size (14pt for captions vs 16pt for body)\n- Centering captions\n- Inserting images above captions\n\n**Solution**: `split_paragraph_at_figure_captions()` — extract figure captions into separate paragraphs with 14pt, centered alignment.\n\n## Pitfall 4: Image Insertion Position\n\n**Problem**: Images should be inserted ABOVE the figure caption, not below.\n\n**Wrong**: `doc.add_paragraph()` — appends to end of document\n**Correct**: `para._element.addprevious(new_p)` — inserts before the caption paragraph\n\n```python\n# Wrong way (appends to end):\nnew_para = doc.add_paragraph()\n\n# Correct way (inserts before caption):\nnew_p = OxmlElement('w:p')\ncaption_para._element.addprevious(new_p)\nnew_para = Paragraph(new_p, caption_para._parent)\n```\n\n## Pitfall 5: Cover Formatting Overwritten\n\n**Problem**: `apply_formatting()` iterates all paragraphs and applies styles. This overwrites the cover page formatting (title should be 22pt centered, not body style).\n\n**Solution**: Find the first `Heading 1` paragraph index, skip all paragraphs before it.\n\n```python\nfirst_heading_idx = 0\nfor i, para in enumerate(doc.paragraphs):\n    if para.style.name == 'Heading 1':\n        first_heading_idx = i\n        break\n\n# Skip cover paragraphs\nif para_idx < first_heading_idx:\n    continue\n```\n\n## Pitfall 6: Page Header/Footer Placeholders\n\n**Problem**: docxtpl does NOT replace text in headers/footers. The `{software_name}{version}` placeholder remains as-is.\n\n**Solution**: After rendering, load the document with python-docx and manually replace header text + add PAGE field code to footer.\n\n## Pitfall 7: `apply_formatting` Must Use Document Object\n\n**Problem**: `replace_header_footer()` was called with file path string instead of Document object.\n\n**Solution**: Load document first, then pass to function.\n\n```python\n# Wrong:\nreplace_header_footer(output_path, software_name, version)\n\n# Correct:\ndoc = Document(output_path)\nreplace_header_footer(doc, software_name, version)\ndoc.save(output_path)\n```\n\n## Pitfall 8: Figure Caption Detection\n\n**Problem**: Regex `r'^图\\d+\\s+'` only matches captions at start of paragraph. After splitting long paragraphs, captions may be at start of new paragraphs.\n\n**Solution**: Split long paragraphs FIRST, then split figure captions.\n\n## Processing Order\n\nThe order of post-processing steps matters:\n\n1. **Split long paragraphs** — ensures each line is a separate paragraph\n2. **Split figure captions** — extracts captions into separate paragraphs\n3. **Insert images** — inserts images above caption paragraphs\n4. **Remove empty lines** — cleans up Jinja2 artifacts\n5. **Replace header/footer** — adds page numbers\n6. **Apply formatting** — applies body/heading styles (skip cover)\n\nFile v0.1.0:references/docxtpl渲染陷阱.md\n\n# docxtpl 渲染陷阱（实战经验）\n\n## 背景\n\ndocxtpl 使用 Jinja2 模板引擎渲染 Word 文档，但渲染后的行为与预期有多个差异。这些是在手动验证中逐个发现的真实问题。\n\n## 陷阱清单\n\n### 1. Jinja2 标记变成空行\n\n**现象**：`{% for section in sections %}` 等标记渲染后变成空段落，导致标题间有多余空行。\n\n**根因**：docxtpl 删除 Jinja2 标记内容，但保留段落本身。\n\n**修复**：`post_process.py` 的 `remove_consecutive_empty_lines()` 删除连续空行。\n\n### 2. 长段落首行缩进丢失\n\n**现象**：content 字段中有 `\\n` 换行，docxtpl 把整个内容放在一个段落中，只有第一行有首行缩进。\n\n**根因**：docxtpl 不会根据 `\\n` 自动分割段落。\n\n**修复**：`post_process.py` 的 `split_long_paragraphs()` 按 `\\n` 分割成独立段落，每个段落复制原段落格式。\n\n### 3. 图名混在正文中无法单独设置格式\n\n**现象**：图名（如\"图8 系统总体架构图\"）和正文在同一个段落中，无法单独设置 14pt 居中。\n\n**根因**：content 字段中的图名是正文的一部分。\n\n**修复**：`post_process.py` 的 `split_paragraph_at_figure_captions()` 用正则 `r'(图\\d+\\s+[^\\n]+)'` 提取图名，创建独立段落并设置 14pt 居中。\n\n### 4. 图片必须用 addprevious() 插入到图名上方\n\n**现象**：用 `add_paragraph_after()` 插入图片，图片出现在图名下方。\n\n**根因**：需求是\"图片在图名上方\"。\n\n**修复**：用 `paragraph._element.addprevious(new_p)` 在图名段落**前**插入图片段落。\n\n### 5. apply_formatting() 覆盖封面格式\n\n**现象**：封面标题的居中、黑体、22pt 被正文格式覆盖。\n\n**根因**：apply_formatting 遍历所有段落，没有跳过封面。\n\n**修复**：找到第一个 Heading 1 的位置，之前的段落全部跳过。\n\n### 6. 两端对齐导致中文字间距拉大\n\n**现象**：正文字间距不均匀，某些行字间距很大。\n\n**根因**：`align: justify`（两端对齐）在中文排版中会拉大字间距。\n\n**修复**：正文使用 `align: left`（左对齐），图名使用 `align: center`（居中）。\n\n### 7. content 字段中的图名导致重复\n\n**现象**：图名出现两行（content 中一行，images 生成一行）。\n\n**根因**：content 字段写入了图名，images 字段也生成图名。\n\n**修复**：content 字段中**不要**写图名，图名只由脚本从 images 字段生成。\n\n### 8. 模板中的图片列表循环生成文字列表\n\n**现象**：文档中出现\"图1 xxx\\n图2 xxx\\n...\"的文字列表。\n\n**根因**：模板中有 `{% for img in section.images %}{{img.ref}} {{img.description}}{% endfor %}`。\n\n**修复**：模板中**不要**有图片列表循环，图名由 `post_process.py` 自动生成。\n\n## 关键教训\n\n1. **docxtpl 渲染后必须后处理** — 不能假设渲染结果就是最终结果\n2. **段落格式要在渲染后应用** — 渲染会破坏模板中的格式\n3. **封面段落要特殊保护** — apply_formatting 必须跳过封面\n4. **图名必须独立段落** — 否则无法单独设置格式\n5. **图片插入位置要精确** — 用 addprevious() 不是 addnext()\n\nFile v0.1.0:references/excalidraw-diagram/color-palette.md\n\n# Color Palette & Brand Style\n\n**This is the single source of truth for all colors and brand-specific styles.** To customize diagrams for your own brand, edit this file — everything else in the skill is universal.\n\n---\n\n## Shape Colors (Semantic)\n\nColors encode meaning, not decoration. Each semantic purpose has a fill/stroke pair.\n\n| Semantic Purpose | Fill | Stroke |\n|------------------|------|--------|\n| Primary/Neutral | `#3b82f6` | `#1e3a5f` |\n| Secondary | `#60a5fa` | `#1e3a5f` |\n| Tertiary | `#93c5fd` | `#1e3a5f` |\n| Start/Trigger | `#fed7aa` | `#c2410c` |\n| End/Success | `#a7f3d0` | `#047857` |\n| Warning/Reset | `#fee2e2` | `#dc2626` |\n| Decision | `#fef3c7` | `#b45309` |\n| AI/LLM | `#ddd6fe` | `#6d28d9` |\n| Inactive/Disabled | `#dbeafe` | `#1e40af` (use dashed stroke) |\n| Error | `#fecaca` | `#b91c1c` |\n\n**Rule**: Always pair a darker stroke with a lighter fill for contrast.\n\n---\n\n## Text Colors (Hierarchy)\n\nUse color on free-floating text to create visual hierarchy without containers.\n\n| Level | Color | Use For |\n|-------|-------|---------|\n| Title | `#1e40af` | Section headings, major labels |\n| Subtitle | `#3b82f6` | Subheadings, secondary labels |\n| Body/Detail | `#64748b` | Descriptions, annotations, metadata |\n| On light fills | `#374151` | Text inside light-colored shapes |\n| On dark fills | `#ffffff` | Text inside dark-colored shapes |\n\n---\n\n## Evidence Artifact Colors\n\nUsed for code snippets, data examples, and other concrete evidence inside technical diagrams.\n\n| Artifact | Background | Text Color |\n|----------|-----------|------------|\n| Code snippet | `#1e293b` | Syntax-colored (language-appropriate) |\n| JSON/data example | `#1e293b` | `#22c55e` (green) |\n\n---\n\n## Default Stroke & Line Colors\n\n| Element | Color |\n|---------|-------|\n| Arrows | Use the stroke color of the source element's semantic purpose |\n| Structural lines (dividers, trees, timelines) | Primary stroke (`#1e3a5f`) or Slate (`#64748b`) |\n| Marker dots (fill + stroke) | Primary fill (`#3b82f6`) |\n\n---\n\n## Background\n\n| Property | Value |\n|----------|-------|\n| Canvas background | `#ffffff` |\n\nFile v0.1.0:references/excalidraw-diagram/element-templates.md\n\n# Element Templates\n\nCopy-paste JSON templates for each Excalidraw element type. The `strokeColor` and `backgroundColor` values are placeholders — always pull actual colors from `color-palette.md` based on the element's semantic purpose.\n\n## Free-Floating Text (no container)\n```json\n{\n  \"type\": \"text\",\n  \"id\": \"label1\",\n  \"x\": 100, \"y\": 100,\n  \"width\": 200, \"height\": 25,\n  \"text\": \"Section Title\",\n  \"originalText\": \"Section Title\",\n  \"fontSize\": 20,\n  \"fontFamily\": 3,\n  \"textAlign\": \"left\",\n  \"verticalAlign\": \"top\",\n  \"strokeColor\": \"<title color from palette>\",\n  \"backgroundColor\": \"transparent\",\n  \"fillStyle\": \"solid\",\n  \"strokeWidth\": 1,\n  \"strokeStyle\": \"solid\",\n  \"roughness\": 0,\n  \"opacity\": 100,\n  \"angle\": 0,\n  \"seed\": 11111,\n  \"version\": 1,\n  \"versionNonce\": 22222,\n  \"isDeleted\": false,\n  \"groupIds\": [],\n  \"boundElements\": null,\n  \"link\": null,\n  \"locked\": false,\n  \"containerId\": null,\n  \"lineHeight\": 1.25\n}\n```\n\n## Line (structural, not arrow)\n```json\n{\n  \"type\": \"line\",\n  \"id\": \"line1\",\n  \"x\": 100, \"y\": 100,\n  \"width\": 0, \"height\": 200,\n  \"strokeColor\": \"<structural line color from palette>\",\n  \"backgroundColor\": \"transparent\",\n  \"fillStyle\": \"solid\",\n  \"strokeWidth\": 2,\n  \"strokeStyle\": \"solid\",\n  \"roughness\": 0,\n  \"opacity\": 100,\n  \"angle\": 0,\n  \"seed\": 44444,\n  \"version\": 1,\n  \"versionNonce\": 55555,\n  \"isDeleted\": false,\n  \"groupIds\": [],\n  \"boundElements\": null,\n  \"link\": null,\n  \"locked\": false,\n  \"points\": [[0, 0], [0, 200]]\n}\n```\n\n## Small Marker Dot\n```json\n{\n  \"type\": \"ellipse\",\n  \"id\": \"dot1\",\n  \"x\": 94, \"y\": 94,\n  \"width\": 12, \"height\": 12,\n  \"strokeColor\": \"<marker dot color from palette>\",\n  \"backgroundColor\": \"<marker dot color from palette>\",\n  \"fillStyle\": \"solid\",\n  \"strokeWidth\": 1,\n  \"strokeStyle\": \"solid\",\n  \"roughness\": 0,\n  \"opacity\": 100,\n  \"angle\": 0,\n  \"seed\": 66666,\n  \"version\": 1,\n  \"versionNonce\": 77777,\n  \"isDeleted\": false,\n  \"groupIds\": [],\n  \"boundElements\": null,\n  \"link\": null,\n  \"locked\": false\n}\n```\n\n## Rectangle\n```json\n{\n  \"type\": \"rectangle\",\n  \"id\": \"elem1\",\n  \"x\": 100, \"y\": 100, \"width\": 180, \"height\": 90,\n  \"strokeColor\": \"<stroke from palette based on semantic purpose>\",\n  \"backgroundColor\": \"<fill from palette based on semantic purpose>\",\n  \"fillStyle\": \"solid\",\n  \"strokeWidth\": 2,\n  \"strokeStyle\": \"solid\",\n  \"roughness\": 0,\n  \"opacity\": 100,\n  \"angle\": 0,\n  \"seed\": 12345,\n  \"version\": 1,\n  \"versionNonce\": 67890,\n  \"isDeleted\": false,\n  \"groupIds\": [],\n  \"boundElements\": [{\"id\": \"text1\", \"type\": \"text\"}],\n  \"link\": null,\n  \"locked\": false,\n  \"roundness\": {\"type\": 3}\n}\n```\n\n## Text (centered in shape)\n```json\n{\n  \"type\": \"text\",\n  \"id\": \"text1\",\n  \"x\": 130, \"y\": 132,\n  \"width\": 120, \"height\": 25,\n  \"text\": \"Process\",\n  \"originalText\": \"Process\",\n  \"fontSize\": 16,\n  \"fontFamily\": 3,\n  \"textAlign\": \"center\",\n  \"verticalAlign\": \"middle\",\n  \"strokeColor\": \"<text color — match parent shape's stroke or use 'on light/dark fills' from palette>\",\n  \"backgroundColor\": \"transparent\",\n  \"fillStyle\": \"solid\",\n  \"strokeWidth\": 1,\n  \"strokeStyle\": \"solid\",\n  \"roughness\": 0,\n  \"opacity\": 100,\n  \"angle\": 0,\n  \"seed\": 11111,\n  \"version\": 1,\n  \"versionNonce\": 22222,\n  \"isDeleted\": false,\n  \"groupIds\": [],\n  \"boundElements\": null,\n  \"link\": null,\n  \"locked\": false,\n  \"containerId\": \"elem1\",\n  \"lineHeight\": 1.25\n}\n```\n\n## Arrow\n```json\n{\n  \"type\": \"arrow\",\n  \"id\": \"arrow1\",\n  \"x\": 282, \"y\": 145, \"width\": 118, \"height\": 0,\n  \"strokeColor\": \"<arrow color — typically matches source element's stroke from palette>\",\n  \"backgroundColor\": \"transparent\",\n  \"fillStyle\": \"solid\",\n  \"strokeWidth\": 2,\n  \"strokeStyle\": \"solid\",\n  \"roughness\": 0,\n  \"opacity\": 100,\n  \"angle\": 0,\n  \"seed\": 33333,\n  \"version\": 1,\n  \"versionNonce\": 44444,\n  \"isDeleted\": false,\n  \"groupIds\": [],\n  \"boundElements\": null,\n  \"link\": null,\n  \"locked\": false,\n  \"points\": [[0, 0], [118, 0]],\n  \"startBinding\": {\"elementId\": \"elem1\", \"focus\": 0, \"gap\": 2},\n  \"endBinding\": {\"elementId\": \"elem2\", \"focus\": 0, \"gap\": 2},\n  \"startArrowhead\": null,\n  \"endArrowhead\": \"arrow\"\n}\n```\n\nFor curves: use 3+ points in `points` array.\n\nFile v0.1.0:references/excalidraw-diagram/json-schema.md\n\n# Excalidraw JSON Schema\n\n## Element Types\n\n| Type | Use For |\n|------|---------|\n| `rectangle` | Processes, actions, components |\n| `ellipse` | Entry/exit points, external systems |\n| `diamond` | Decisions, conditionals |\n| `arrow` | Connections between shapes |\n| `text` | Labels inside shapes |\n| `line` | Non-arrow connections |\n| `frame` | Grouping containers |\n\n## Common Properties\n\nAll elements share these:\n\n| Property | Type | Description |\n|----------|------|-------------|\n| `id` | string | Unique identifier |\n| `type` | string | Element type |\n| `x`, `y` | number | Position in pixels |\n| `width`, `height` | number | Size in pixels |\n| `strokeColor` | string | Border color (hex) |\n| `backgroundColor` | string | Fill color (hex or \"transparent\") |\n| `fillStyle` | string | \"solid\", \"hachure\", \"cross-hatch\" |\n| `strokeWidth` | number | 1, 2, or 4 |\n| `strokeStyle` | string | \"solid\", \"dashed\", \"dotted\" |\n| `roughness` | number | 0 (smooth), 1 (default), 2 (rough) |\n| `opacity` | number | 0-100 |\n| `seed` | number | Random seed for roughness |\n\n## Text-Specific Properties\n\n| Property | Description |\n|----------|-------------|\n| `text` | The display text |\n| `originalText` | Same as text |\n| `fontSize` | Size in pixels (16-20 recommended) |\n| `fontFamily` | 3 for monospace (use this) |\n| `textAlign` | \"left\", \"center\", \"right\" |\n| `verticalAlign` | \"top\", \"middle\", \"bottom\" |\n| `containerId` | ID of parent shape |\n\n## Arrow-Specific Properties\n\n| Property | Description |\n|----------|-------------|\n| `points` | Array of [x, y] coordinates |\n| `startBinding` | Connection to start shape |\n| `endBinding` | Connection to end shape |\n| `startArrowhead` | null, \"arrow\", \"bar\", \"dot\", \"triangle\" |\n| `endArrowhead` | null, \"arrow\", \"bar\", \"dot\", \"triangle\" |\n\n## Binding Format\n\n```json\n{\n  \"elementId\": \"shapeId\",\n  \"focus\": 0,\n  \"gap\": 2\n}\n```\n\n## Rectangle Roundness\n\nAdd for rounded corners:\n```json\n\"roundness\": { \"type\": 3 }\n```","readmeExcerpt":"Skill: software-copyright-skill Owner: foamtor Summary: 生成中国软件著作权（软著）登记申请文档。LLM驱动：分析项目代码、生成内容；Python脚本辅助：模板填充、格式保持。 Tags: latest:0.1.0 Version history: v0.1.0 | 2026-08-20T07:58:25.184Z | auto software-copyright-skill 0.1.0 - Initial release with comprehensive documentation for generating Chinese software copyright registration documents. - Supports LLM-driven content generation and Python scripts for template fillin","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"○\n       ↗\n  □ → ○\n       ↘\n        ○"},{"language":"text","snippet":"○ ↘\n  ○ → □\n  ○ ↗"},{"language":"text","snippet":"label\n  ├── label\n  │   ├── label\n  │   └── label\n  └── label"},{"language":"text","snippet":"□ → □\n  ↑     ↓\n  □ ← □"},{"language":"text","snippet":"○○○ → [PROCESS] → □□□\n  chaos              order"},{"language":"text","snippet":"Timeline:           Tree:\n  ●─── Label 1        │\n  │                   ├── item\n  ●─── Label 2        │   ├── sub\n  │                   │   └── sub\n  ●─── Label 3        └── item"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"references/excalidraw-diagram/SKILL.md","content":"---\nname: excalidraw-diagram\ndescription: Create Excalidraw diagram JSON files that make visual arguments. Use when the user wants to visualize workflows, architectures, or concepts.\n---\n\n# Excalidraw Diagram Creator\n\nGenerate `.excalidraw` JSON files that **argue visually**, not just display information.\n\n**Setup:** If the user asks you to set up this skill (renderer, dependencies, etc.), see `README.md` for instructions.\n\n## Customization\n\n**All colors and brand-specific styles live in one file:** `references/color-palette.md`. Read it before generating any diagram and use it as the single source of truth for all color choices — shape fills, strokes, text colors, evidence artifact backgrounds, everything.\n\nTo make this skill produce diagrams in your own brand style, edit `color-palette.md`. Everything else in this file is universal design methodology and Excalidraw best practices.\n\n---\n\n## Core Philosophy\n\n**Diagrams should ARGUE, not DISPLAY.**\n\nA diagram isn't formatted text. It's a visual argument that shows relationships, causality, and flow that words alone can't express. The shape should BE the meaning.\n\n**The Isomorphism Test**: If you removed all text, would the structure alone communicate the concept? If not, redesign.\n\n**The Education Test**: Could someone learn something concrete from this diagram, or does it just label boxes? A good diagram teaches—it shows actual formats, real event names, concrete examples.\n\n---\n\n## Depth Assessment (Do This First)\n\nBefore designing, determine what level of detail this diagram needs:\n\n### Simple/Conceptual Diagrams\nUse abstract shapes when:\n- Explaining a mental model or philosophy\n- The audience doesn't need technical specifics\n- The concept IS the abstraction (e.g., \"separation of concerns\")\n\n### Comprehensive/Technical Diagrams\nUse concrete examples when:\n- Diagramming a real system, protocol, or architecture\n- The diagram will be used to teach or explain (e.g., YouTube video)\n- The audience needs to understand what things actually look like\n- You're showing how multiple technologies integrate\n\n**For technical diagrams, you MUST include evidence artifacts** (see below).\n\n---\n\n## Research Mandate (For Technical Diagrams)\n\n**Before drawing anything technical, research the actual specifications.**\n\nIf you're diagramming a protocol, API, or framework:\n1. Look up the actual JSON/data formats\n2. Find the real event names, method names, or API endpoints\n3. Understand how the pieces actually connect\n4. Use real terminology, not generic placeholders\n\nBad: \"Protocol\" → \"Frontend\"\nGood: \"AG-UI streams events (RUN_STARTED, STATE_DELTA, A2UI_UPDATE)\" → \"CopilotKit renders via createA2UIMessageRenderer()\"\n\n**Research makes diagrams accurate AND educational.**\n\n---\n\n## Evidence Artifacts\n\nEvidence artifacts are concrete examples that prove your diagram is accurate and help viewers learn. Include them in technical diagrams.\n\n**Types of evidence artifacts** (choose what's relevant to your diagram):\n\n| Artifact "},{"path":"SKILL.md","content":"---\nname: software-copyright-skill\ndescription: 生成中国软件著作权（软著）登记申请文档。LLM驱动：分析项目代码、生成内容；Python脚本辅助：模板填充、格式保持。\nversion: 4.7.0\nauthor: hermes-agent\nhomepage: https://github.com/Foamtor/software-copyright-skill\nlicense: MIT\ntags: [软著, 软件著作权, 文档生成, python-docx, Word, 版权登记, 模板填充]\n---\n\n# 软著文档生成 Skill（模板驱动版）\n\n**核心原则**：模型输出JSON内容，脚本根据模板生成Word。格式100%由模板控制。\n\n**版本**：V4.7（2026-06-27更新）\n\n## 触发条件\n\n用户提到：软著、软件著作权、软著申请、软著文档、信息采集表、使用说明书、设计说明、源代码文档\n\n## 前置依赖\n\n```bash\npip install python-docx docxtpl lxml Pillow\n```\n\n## 网络代理配置（WSL环境）\n\n在WSL环境下，如果需要访问GitHub等外部服务，可能需要配置代理。\n\n### 自动检测代理\n\n```bash\n# 使用代理管理脚本自动检测并配置\n~/.hermes/scripts/proxy_manager.sh auto\n```\n\n### 手动配置代理\n\n```bash\n# 设置代理环境变量\nexport http_proxy=http://172.22.240.1:7897\nexport https_proxy=http://172.22.240.1:7897\n\n# 配置Git代理\ngit config --global http.proxy http://172.22.240.1:7897\ngit config --global http.version HTTP/1.1\n```\n\n### 代理不可用时\n\n如果代理不可用，可以：\n1. 启动宿主机Clash并开启\"Allow LAN\"\n2. 使用直连模式：`~/.hermes/scripts/proxy_manager.sh direct`\n3. 参考故障排除指南：`~/.hermes/scripts/proxy_troubleshooting.md`\n\n## 架构设计\n\n```\n┌─────────────┐     ┌─────────────────┐     ┌─────────────┐\n│  LLM 生成   │ ──→ │   content.json  │ ──→ │ docxtpl 渲染│\n│  JSON 内容   │     │  (结构化数据)    │     │  生成.docx  │\n└─────────────┘     └─────────────────┘     └─────────────┘\n                                                  ↑\n                                          templates/*.docx\n                                          (格式由模板控制)\n```\n\n**关键原则**：\n- 模型只输出JSON（内容），不接触格式\n- 格式由Word模板（.docx）控制\n- 用户给参考文档 → 提取格式 → 生成模板\n- 格式变化 = 换模板，不需要改代码\n\n## 配置格式\n\n**支持两种配置格式**（`generate_manual.py` 自动检测）：\n\n1. **Brand Profile**（推荐）：`config/brand_profile.json`\n   - 包含样式定义、内容规则、写作风格\n   - 可复用于多文档，易于版本控制\n   - 详见 `references/brand-profile-design.md`\n\n2. **旧格式**（兼容）：`config/format_spec.json`\n   - 扁平的样式定义\n   - 仍然支持，但建议迁移\n\n```bash\n# 使用Brand Profile\npython3 scripts/generate_manual.py --config config/brand_profile.json ...\n\n# 使用旧格式\npython3 scripts/generate_manual.py --config config/format_spec.json ...\n```\n\n## ⚠️ 职责分工：模型 vs 脚本\n\n**核心设计：模型负责生成和审阅，脚本负责验证和控制。**\n\n| 任务 | 执行者 | 说明 |\n|------|--------|------|\n| 扫描项目结构 | 🐍 脚本 | `scan_project.py` |\n| 生成大纲 | 🤖 模型 | 使用 `prompts/大纲生成.md` |\n| 生成章节内容 | 🤖 模型 | 使用 `prompts/章节生成.md` |\n| 审阅章节质量 | 🤖 模型 | 使用 `prompts/章节审阅.md` |\n| 检查基础质量 | 🐍 脚本 | `review_chapter.py`（字数、数量） |\n| 合并章节 | 🐍 脚本 | `merge_chapters.py` |\n| 验证内容质量 | 🐍 脚本 | `validate_content_quality.py` |\n| 生成Word文档 | 🐍 脚本 | `generate_manual.py` |\n| 验证格式 | 🐍 脚本 | `validate_output.py` |\n| 生成架构图 | 🤖+🐍 | excalidraw skill 生成JSON → render为PNG |\n| 插入图片 | 🐍 脚本 | `generate_manual.py --image-dir` |\n\n## ⚠️ 内容质量规范\n\n### 写作风格\n\n**软著说明书是用户操作指南，不是技术文档！**\n\n#### 正确写法\n```\n在系统首页，点击\"新建项目\"按钮，弹出新建项目对话框。如下图。\n图3 新建项目按钮\n\n在对话框中填写项目名称和项目描述，点击\"确定\"按钮，即可创建新项目。如下图。\n图4 新建项目对话框\n```\n\n#### 错误写法\n```\n一、项目管理功能：支持创建和管理项目，提供项目状态监控和版本控制能力。\n```\n\n### 内容质量要求\n\n| 要求 | 标准 | 检查方式 |\n|------|------|----------|\n| **总字数** | ≥15000字 | 🐍 `validate_content_quality.py` |\n| **章节数** | 6-10章 | 🐍 `validate_content_quality.py` |\n| **图片标记** | ≥13张（精简版） | 🐍 `vali"},{"path":"examples/demo/README.md","content":"# 示例项目\n\n这是一个示例项目结构，用于演示 `software-copyright-skill` 的使用。\n\n## 使用方法\n\n1. 将此目录替换为你的实际项目\n2. 在AI Agent中说：\"帮我为当前项目生成软著文档\"\n3. 按照Agent引导完成信息确认和文档生成\n\n## 示例项目结构\n\n```\nmy-project/\n├── README.md\n├── package.json\n├── src/\n│   ├── main.ts\n│   ├── router/\n│   │   └── index.ts\n│   ├── views/\n│   │   ├── Home.vue\n│   │   ├── Login.vue\n│   │   └── Dashboard.vue\n│   ├── components/\n│   │   └── ...\n│   └── api/\n│       └── index.ts\n├── backend/\n│   └── src/\n│       ├── main.py\n│       ├── routes/\n│       ├── services/\n│       └── models/\n└── docs/\n    └── ...\n```"},{"path":"README.md","content":"# 📋 软件著作权文档生成 Skill\n\n> AI Agent 驱动的中国软著申请文档自动生成工具。分析项目代码，自动生成信息采集表、使用说明书和源代码文档。\n\n## ✨ 功能特性\n\n- 🔍 **智能扫描** — 自动识别项目技术栈、功能模块、业务逻辑\n- 📝 **采集表生成** — 交互式确认信息，自动填充Word模板\n- 📖 **说明书撰写** — 分章节生成用户操作指南风格的说明书\n- 💻 **代码提取** — 按优先级提取核心代码，生成前30页+后30页\n- 🎯 **格式合规** — 严格遵循版权中心的字号、字体、排版要求\n- 🎨 **Brand Profile** — JSON格式的样式定义，支持复用和版本控制\n- 📊 **内容质量验证** — 自动检查字数、配图、格式等质量指标\n- 🔄 **迭代优化** — 支持\"生成→验证→修改→再验证\"循环\n- 🧪 **TDD测试** — 完整的测试套件，确保代码质量\n\n## 🚀 快速开始\n\n### 安装\n\n```bash\n# 通用安装（支持所有主流AI Agent）\nnpx skills add Foamtor/software-copyright-skill\n\n# OpenClaw（龙虾）用户\nopenclaw skills install Foamtor/software-copyright-skill\n```\n\n### 安装Python依赖\n\n```bash\npip install python-docx docxtpl lxml Pillow\n```\n\n### 安装架构图渲染依赖（可选，生成架构图时需要）\n\n```bash\ncd references/excalidraw-diagram\nuv sync\nuv run playwright install chromium\n```\n\n### 使用\n\n在你的AI Agent中输入：\n\n```\n帮我为当前项目生成软著文档\n```\n\nAgent会自动：\n1. 扫描项目结构\n2. 确认软件信息\n3. 生成使用说明书大纲\n4. 分章节撰写内容\n5. 提取源代码文档\n6. 输出三份Word文档\n\n## 🤖 支持的AI Agent\n\n| Agent | 安装方式 | 状态 |\n|-------|---------|------|\n| [Hermes Agent](https://hermes-agent.nousresearch.com) | `npx skills add` | ✅ |\n| [Claude Code](https://docs.anthropic.com/claude-code) | `npx skills add` | ✅ |\n| [Cursor](https://cursor.sh) | `npx skills add` | ✅ |\n| [Codex CLI](https://github.com/openai/codex) | `npx skills add` | ✅ |\n| [OpenClaw（龙虾）](https://openclaw.ai) | `openclaw skills install` | ✅ |\n\n所有平台使用同一个 `SKILL.md` 文件，遵循 [AgentSkills](https://github.com/vercel-labs/skills) 规范。\n\n## 📁 生成文档说明\n\n### 信息采集表\n- 软件基本信息（名称、版本号、开发方式等）\n- 开发与运行环境（硬件、操作系统、编程语言等)\n- 功能特点描述（每项50字以内）\n\n### 使用说明书\n- 用户操作指南风格（不是技术文档）\n- 按功能模块组织，含截图占位\n- 每页≥30行，前30页+后30页\n- 第一章必须是平台总体介绍\n\n### 源代码文档\n- 按优先级提取：主入口→路由→核心→公共→API→工具\n- 每页≥50行，前30页+后30页\n- 自动排除第三方库和构建产物\n\n## 🔧 独立使用（不通过Agent）\n\n```bash\n# 扫描项目\npython3 scripts/scan_project.py --path ./my-project --output ./output/project_info.json\n\n# 填充信息采集表\npython3 scripts/fill_template.py \\\n  --template templates/信息采集表模板.docx \\\n  --content ./output/采集表内容.json \\\n  --output ./output/信息采集表.docx\n\n# 生成说明书章节\npython3 scripts/generate_manual.py \\\n  --content ./output/第1章内容.json \\\n  --output ./output/说明书_第1章.docx\n\n# 生成代码文档\npython3 scripts/generate_code_doc.py \\\n  --project ./my-project \\\n  --files ./output/文件列表.json \\\n  --output ./output/代码文档.docx \\\n  --software-name \"我的系统V1.0\" \\\n  --version \"V1.0\"\n\n# 合并章节\npython3 scripts/merge_chapters.py \\\n  --chapters ./output/说明书_第*.docx \\\n  --output ./output/使用说明书.docx \\\n  --software-name \"我的系统V1.0\" \\\n  --version \"V1.0\"\n```\n\n## 📚 参考文档\n\n- [格式规范](references/格式规范.md) — Word排版格式 + 写作风格要求\n- [信息采集表填写要求](references/信息采集表填写要求.md) — 各字段字数限制和填写规范\n- [常见问题](references/常见问题.md) — 实际使用中的问题和解决方案\n\n## 📄 许可证\n\n[MIT License](LICENSE)\n\n## 🙏 致谢\n\n- [python-docx](https://github.com/python-openxml/python-docx) — Word文档操作\n- [AgentSkills](https://github.com/vercel-labs/skills) — 统一的AI Agent Skill标准"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn75e2jfgr4k98gjc69je6j8dx8ct6tf\",\n  \"slug\": \"software-copyright-skill\",\n  \"version\": \"0.1.0\",\n  \"publishedAt\": 1787212705184\n}"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"生成中国软件著作权（软著）登记申请文档。LLM驱动：分析项目代码、生成内容；Python脚本辅助：模板填充、格式保持。 Skill: software-copyright-skill Owner: foamtor Summary: 生成中国软件著作权（软著）登记申请文档。LLM驱动：分析项目代码、生成内容；Python脚本辅助：模板填充、格式保持。 Tags: latest:0.1.0 Version history: v0.1.0 | 2026-08-20T07:58:25.184Z | auto software-copyright-skill 0.1.0 - Initial release with comprehensive documentation for generating Chinese software copyright registration documents. - Supports LLM-driven content generation and Python scripts for template fillin","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1035,"uniquenessScore":55,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T17:22:36.058Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T17:22:36.058Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T21:41:25.263Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}