cangjie

Cangjie Skill

The goal of this skill is not to write answers as a Cangjie syntax encyclopedia, but to help the model use as few tokens as possible to reliably produce Cangjie code, project structures, and analysis conclusions that are closer to the constraints of the official documentation.

Default optimization goals:

1. Give the correct structure first, then provide in-depth explanation.
2. Take the shortest documentation path first, then decide whether to drill down further.
3. Prioritize reducing fabricated APIs, incorrect package structures, and ineffective lengthy output.
4. When encountering a large project, first do a structured inventory, then make design recommendations.

When to use

When the user expresses any of the following intentions, prioritize using this skill:

• Generate Cangjie functions, types, modules, classes, interfaces, generics, pattern matching, and exception handling code
• Rewrite other languages, pseudocode, or design ideas into Cangjie
• Generate cjpm projects, workspaces, multi-module directory structures, and cjpm.toml
• Fix Cangjie compilation errors, entry function errors, package declaration errors, and dependency configuration errors
• Design Cangjie package boundaries, module layering, local path dependencies, and organization name naming schemes
• Analyze the src/ levels,package.package-configuration、workspace、output-type
• Answer cjpm、cjfmt、cjdb, LSP, cross-compilation, central repository dependencies, and other toolchain questions
• Involving stdx, macros, FFI, concurrency, networking, multi-platform, and other special topics

Knowledge source priority

Acquire knowledge in the following order, and do not skip levels:

1. Workspace original documentation
   • references/dev-guide/source_zh_cn/
   • references/tools/source_zh_cn/
   • release-notes/
2. Workspace English original text
   • references/dev-guide/source_en/
   • references/tools/source_en/
3. This skill's index and summaries
   • references/pattern-index.md
   • references/syntax-essentials.md
   • references/path-index.md
   • references/doc-map.md
   • references/codegen-guidelines.md
   • references/version-notes.md
   • references/online-fallback.md
4. bundled original text
   • references/dev-guide/
   • references/tools/
5. Official online documentation and central repository
   • https://cangjie-lang.cn/docs
   • https://docs.cangjie-lang.cn/
   • https://pkg.cangjie-lang.cn/index
6. Model memory

Principles:

• For common tasks, read the pattern first; do not scan the entire document right away.
• When Chinese is sufficient, do not switch to English; fall back to English only when details are missing or terminology is unstable.
• release-notes Read it again only for issues such as version differences, the central repository, organization names, Common/Specific, cross-compilation, and tool behavior changes.
• Local references/ When it is sufficient, do not go online immediately.
• Only fall back to the official online documentation and central repository when local materials do not match, information is clearly missing, or the user explicitly requests a repository lookup.
• When online, prioritize querying only official domains; do not use third-party blogs as the main basis.

Dependency tools

Tool	Purpose	Required
WebSearch	Search official documentation pages and central repository entries	Yes
WebFetch	Obtain in-depth content of matched pages	Yes
Bash	Local rg search, script execution, and necessary auxiliary fetching	Yes

Task triage

First classify the request into the closest category, then read the minimum amount of documentation.

1. Syntax examples / small functions / small algorithms

Applicable:

• Single function
• Single-file syntax example
• struct / enum / class / match / generic skeleton

Default reading:

1. references/syntax-essentials.md
2. Read 1 related source file if necessary

Default delivery:

• Single .cj file
• cjc compile command

2. Single-module cjpm project

Applicable:

• Command-line arguments
• Minimal project skeleton
• Multiple files but still a single module

Default reading:

1. references/patterns/cjpm-project-minimal.md
2. Read if necessary
   • references/dev-guide/source_zh_cn/package/entry.md
   • references/tools/source_zh_cn/cmd-tools/cjpm_manual.md

Default delivery:

1. Directory structure
2. cjpm.toml
3. src/main.cj
4. Other key source code
5. cjpm build / cjpm run

3. workspace / package design / multi-module project

Applicable:

• app dependency core
• Local path dependency
• Workspace root configuration
• Organization name design

Default reading:

1. references/patterns/package-workspace-design.md
2. Read if necessary
   • references/tools/source_zh_cn/cmd-tools/cjpm_manual.md
   • references/dev-guide/source_zh_cn/package/

Default delivery:

1. workspace directory structure
2. Root cjpm.toml
3. Submodule cjpm.toml
4. Key package declarations and import examples
5. Package responsibility description

4. Compilation error / structural error / configuration error fixes

Applicable:

• main(): String
• package / import error
• cjpm.toml field conflict
• path/git/version configuration error

Default reading:

1. Code or configuration provided by the user
2. If it involves dependency sources, organization names, or workspace constraints, first read references/patterns/version-config-fix.md
3. Then read 1 related tool or package document
4. If it clearly involves version changes, then read references/version-notes.md

Default delivery:

1. First point out the most likely structural error
2. Then provide the corrected code or configuration
3. Finally provide the verification command

5. Concurrency / networking / macros / FFI / multi-platform

Applicable:

• spawn
• stdx.net.http
• macro package
• foreign func
• Cross-compilation / Android / iOS

Default reading:

1. Corresponding pattern
2. Read 1 to 2 source files if necessary
3. If it involves tool parameters or version behavior, then read the tool documentation or release notes

Default delivery:

• Minimal runnable example first
• Clearly state dependency prerequisites, compilation order, and risk points

6. Large real repository analysis

Applicable:

• The user provides a real repository path
• Need to analyze layering, module responsibilities, and dependency direction
• Need to add a new module or package

Default reading order:

1. Root cjpm.toml
2. src/ first-level and second-level directory tree
3. Open only a small number of representative files:
   • Top-level pkg.cj
   • Entry main.cj
   • Files named by the user
4. If needed, then look at 1 to 3 specific source files

Tool selection:

• Prefer Glob / Read / Grep -style tools for directory trees and exact files
• Fall back to shell only when these tools are insufficient
• Do not use Bash ls/find

Default delivery:

1. Project overview
2. Module layering
3. Dependency direction
4. Distinguish library modules / dynamic modules / executable modules
5. New module suggestions
6. Configuration snippets and source code skeleton

If the user explicitly asks to "directly generate a new module/new file based on this real repository," first read:

1. references/patterns/existing-large-repo-module-codegen.md
2. root cjpm.toml
3. target-layer directory tree
4. 1 to 3 adjacent existing module files

Tool selection:

• First use structured file-reading tools to get the directory tree and adjacent files
• Avoid calling the shell for simple directory viewing

Then output only:

1. Placement location
2. cjpm.toml configuration snippet
3. 3 to 6 key new files
4. Integration point description

Do not:

• Start by reading a large number of .cj files
• Invent layers before confirming the real structure
• Write a large chunk of new code first, then supplement it with analysis of the current repository

7. Toolchain / version differences

Applicable:

• cjpm field explanation
• cjfmt / cjdb / LSP
• version / central repository / organization name
• Common/Specific
• TrustALL

Default reading:

1. Minimal snippets from relevant tool manuals
2. references/version-notes.md

Default delivery:

• First state the current constraints
• Then state the version differences
• Finally give the corrected configuration or command

8. Online documentation fallback / central repository search

Applicable:

• Local references/ not found
• Local materials lack a certain API, tool parameter, or new-version detail
• Need to search whether a related Cangjie library already exists in the central repository

Default reading:

1. First look at references/online-fallback.md
2. Preferred tools:
   • WebSearch
   • WebFetch
   • If necessary Bash
3. Then check the official online documentation:
   • cangjie-lang.cn/docs
   • docs.cangjie-lang.cn
4. If it is a library/dependency issue, then check:
   • pkg.cangjie-lang.cn/index

Default delivery:

• First explain that "local materials were not found, so switch to checking official online materials"
• Then give leads found in the official documentation or central repository
• Finally give conservative advice, and do not package online search results as absolutely certain API promises

Token budget

Unless the user explicitly requests in-depth analysis, follow the documentation-reading budget below:

• Small syntax question: at most 1 pattern or 1 syntax quick-reference file, plus 1 source file if necessary
• Single-module project: at most 1 pattern + 1 package/tool file
• workspace design: at most 1 pattern + 1 cjpm_manual snippet + 1 package document
• Configuration fix / version differences: at most 1 pattern + 1 tool documentation snippet + 1 release note
• Advanced topic: at most 1 pattern + 1 to 2 source files
• Large repository analysis: root cjpm.toml + src directory tree + at most 6 representative files
• Direct module generation in a large repository: 1 codegen pattern + root configuration + target-layer directory tree + at most 3 adjacent module files
• Version differences: at most 1 release note + 1 tool documentation snippet
• Online fallback: at most 3 official pages + at most 5 central repository leads

Stop rules:

• Once you have obtained a valid skeleton, key constraints, and key commands, answer immediately
• Do not casually globally search the entire references/
• Do not traverse all .cj files in large repository analysis
• Do not casually expand a configuration fix question into a long tutorial
• Do not casually search the entire web when local materials are already sufficient
• Do not repeatedly explain the same constraint twice

Output goals

The default output should satisfy:

1. Give the code or structure first, then the explanation.
2. Keep only the key constraints and assumptions in the explanation.
3. Explanatory comments in code use Chinese by default.
4. When writing to disk is not required, by default inline the key file contents directly in the answer.
5. When the user asks for a project, multiple files, or a workspace, you must provide the complete contents of the key files, not just a summary.

Project-type answers preferably use this order:

1. Directory structure
2. cjpm.toml
3. src/main.cj
4. Other key source code
5. Build / run / debug commands
6. 2 to 6 lines of key explanation

Large repository analysis preferably uses this order:

1. Project overview
2. Module layering
3. Dependency direction
4. Distinguish library / dynamic / executable modules
5. Suggestions for new modules
6. Configuration snippets

High-priority constraints

Entry point and package structure

• The program entry point must be top-level main
• main Parameters may only be parameterless or Array<String>
• main Return types may only be Unit or integer types
• cjpm In the project, source code is placed by default in src/
• Project examples explicitly write by default package
• workspace root cjpm.toml must not contain both [package] and [workspace]

Package design and multiple modules

• Entry point main is placed only in executable modules
• Reusable logic goes into independent modules
• public exposes only declarations necessary across modules
• For local multi-module relationships, preferably use path dependency expression
• If configured with organization, package declarations and imports must use the org::pkg form
• workspace members, even if they are in the same root directory, as long as module source code mutually import, must still explicitly declare [dependencies], unless you explicitly configure shared dependencies at the root workspace

Toolchain and versions

• If only one of 'git' or 'path' or 'version' fields can existappears, first think of the central repository version field being mutually exclusive with local/remote dependencies
• If the user asks about organization names, Common/Specific, the central repository, or cross-compilation, proactively check references/version-notes.md
• If the user does not give a specific version, answer by default according to the mainline documentation of the current workspace, and note "this point may be affected by the version"
• Distinguish cjpm.toml 's output-type and cjc --output-type
• In cjpm.toml preferably use static / dynamic / executable
• Do not cjc command line's staticlib / dylib directly into cjpm.toml

stdx

• stdx.net.*、stdx.log.* and similar capabilities should not be treated as necessarily built into the basic SDK
• You should remind the user to first download the corresponding software package, and in cjpm.toml configure dependencies

Macros

• Macro definitions and macro invocations should not be placed in the same package
• Macro definitions use public
• Compile the macro package first, then compile through --import-path compile the caller
• Minimal macro examples preferably give a split-package structure; do not expand into a complex project from the start

FFI

• foreign only declares, does not implement
• External calls are placed in unsafe block
• Do not use named parameters and default values
• When unsure about type mapping, do not invent complex signatures

Self-check checklist

Quickly self-check before answering:

1. Did I choose the right single-file / cjpm / workspace / large-repo analysis form?
2. Did I read only the minimum, most relevant documentation?
3. Did I clearly state stdx, macros, FFI, version differences, and other prerequisites?
4. Did I provide the complete contents of key files and verification commands?
5. Did I mark uncertain APIs as “needs to be checked against the local SDK”?
6. If this is large-repo analysis, did I first summarize based on the real directory and root configuration, and then give suggestions for new modules?

Reference materials

• references/pattern-index.md
• references/syntax-essentials.md
• references/path-index.md
• references/doc-map.md
• references/codegen-guidelines.md
• references/version-notes.md
• references/online-fallback.md
• references/patterns/

Continue reading only if the task actually involves this topic, to avoid turning the Cangjie skill into a high-token “all-in-one prompt.”