sharedev-init

APL Development Environment Automated Preparation Skill

This skill is used to initialize the ShareDev APL/PWC workspace and connect the corresponding platform's spec/skills to the current development environment.

Goals

Complete the following things:

Check and install sharedev CLI
Read the project root directory settings.json
Initialize the <enterpriseRoot>/ workspace
Pull docs, PWC, APL, dev-metadata, object-dev
Initialize the target platform's spec template
Install the skills/specs required by the target platform
Fix legacy path references in already installed old skills
Verify the final directory structure

Prerequisite Rules

The following rules must be followed:

First decide TARGET_PLATFORM, then execute any platform-related commands.
First decide EXECUTION_MODE, then decide whether to allow interactive commands.
Do not "guess" the target platform for this run based on whether ~/.codex、~/.claude、.trae exists.
Prefer non-interactive commands for agent environments; only follow the interactive process when the user explicitly requests manual interaction and the current terminal is truly a user-operable terminal.
Do not mix "initializing the project" and "installing skills" into one inseparable black box; report them as two phases during execution.
Do not use large-scale sed/string replacement after installation to tamper with skills markdown paths. Path issues should be solved through template variables or stable reference schemes.
Do not require Codex to additionally execute codex --enable skills. The current document should not treat it as a required step.
Controlled compatibility fixes must be performed, but only for the already installed sharedev-apl-implement、sharedev-apl-code-review two skills, and only known legacy path patterns should be fixed.
When any key command returns a non-zero exit code, it must not be directly verbally treated as "overall success"; the completed|incomplete|blocked。
Only when "the command has been executed" and "the verification conditions for that step are satisfied" can the step be marked as completed; otherwise it must be clearly marked as incomplete or blocked。
As long as any required resource among docs, PWC, APL, dev-metadata, object-dev has not been verified as complete, it must not be claimed externally that "initialization is complete."
The compatibility fix in Step 8.5 can only perform targeted replacement according to the legacy patterns listed in the document; it must not use "rewording" or "weakening the wording" as a substitute for the fix.
The final report must provide status step by step from Step 1 to Step 10, and must not give only a general conclusion.

Input Parameters

Required input

Read from the project root directory settings.json :

enterpriseEA
domain
certificate

Runtime Variables

Before execution, a distinction must be made between "workspace root directory", "enterprise project name", and "enterprise project directory", and they must not be used interchangeably:

Variable	Meaning
`<workspaceRoot>`	The current project root directory, i.e., the directory where `settings.json` is located
`<enterpriseEAName>`	`settings.json` the `enterpriseEA` field value in , for example `fktest8507`、`Project`
`<enterpriseRoot>`	Enterprise project directory, default is `<workspaceRoot>/<enterpriseEAName>`; if the current directory itself already contains `.sharedev/`、`package/`、`pwc/`, then the current directory is `<enterpriseRoot>`

Key rules:

sharedev init -e ... in -e parameter is the enterprise project name or a relative target directory, not an absolute project root path.
If you are currently already located in <enterpriseRoot>, when refreshing you must use -e ., and must not pass <enterpriseEAName>again, otherwise a subdirectory with the same name will be created again under the current directory.
Only when <workspaceRoot> performs the first initialization is -e <enterpriseEAName>。

Must determine

Before execution, the following three variables must be clearly determined:

TARGET_PLATFORM=trae|claude|codex
EXECUTION_MODE=interactive|noninteractive
INSTALL_SCOPE=project|global

Platform matrix

TARGET_PLATFORM	EXECUTION_MODE	INSTALL_SCOPE	spec directory	skills installation location
`trae`	`interactive` preferred	`project`	`<enterpriseRoot>/.trae/`	`<workspaceRoot>/.trae/skills/`
`trae`	`noninteractive`	`project`	`<enterpriseRoot>/.trae/`	`<workspaceRoot>/.trae/skills/`
`claude`	`interactive` or `noninteractive`	`project`	`<enterpriseRoot>/.claude/`	`<workspaceRoot>/.claude/skills/`
`claude`	`noninteractive` recommended	`global`	`<enterpriseRoot>/.claude/`	`~/.claude/skills/`
`codex`	`noninteractive` recommended	`global`	`<enterpriseRoot>/.codex/`	`~/.codex/skills/`

Recommended defaults

If the user has not explicitly specified, use the following default rules:

Trae IDE, and the current terminal is a foreground terminal the user can directly operate: TARGET_PLATFORM=trae，EXECUTION_MODE=interactive，INSTALL_SCOPE=project
Trae agent / Trae agent execution / restricted shared terminal: TARGET_PLATFORM=trae，EXECUTION_MODE=noninteractive，INSTALL_SCOPE=project
Claude Code: TARGET_PLATFORM=claude，EXECUTION_MODE=noninteractive，INSTALL_SCOPE=project
Codex: TARGET_PLATFORM=codex，EXECUTION_MODE=noninteractive，INSTALL_SCOPE=global

Execution state conventions

During execution, each step can only fall into one of the following three states:

completed: the command for this step has been executed, and all verification conditions in the documentation are satisfied.
incomplete: this step has been partially executed, but there are still gaps in the verification conditions, and it must continue to be completed; it cannot be claimed as done.
blocked: due to missing parameters, command failure, missing directory, restricted interaction, or abnormal remote data, it is currently impossible to safely continue, and the blocking reason must be clearly reported.

Strict requirements:

It is not allowed to verbally describe incomplete as "basically complete", "mainly complete", or "can be regarded as successful".
Once any step is blocked, unless the documentation explicitly allows continuing with independent wrap-up, you must not continue to claim that the subsequent process has been fully completed.
When outputting at Step 10, you must restate the final state of each step one by one.

Execution flow

Phase A: Workspace Bootstrap

Step 1: Check the sharedev CLI

Execute:

which sharedev

If not installed, execute:

npm install -g @share-crm/sharedev-cli

Verify:

Return the sharedev executable path

Step 2: Read settings.json

Read the project root directory settings.json, extract:

enterpriseEA(save to <enterpriseEAName>）
domain
certificate

If any item is missing, abort and prompt the user to fill it in.

Then immediately determine:

If the current directory already contains .sharedev/、package/、pwc/, then the current directory is <enterpriseRoot>
Otherwise <enterpriseRoot> = <workspaceRoot>/<enterpriseEAName>

Step 3: Determine the execution mode

First explicitly determine the goal of this execution:

TARGET_PLATFORM = trae | claude | codex
EXECUTION_MODE = interactive | noninteractive
INSTALL_SCOPE = project | global

Decision rules:

When the user explicitly specifies, the user's specification takes precedence.
When the current agent environment is known, it may be selected according to the "recommended defaults".
It is not allowed to infer the target platform solely based on the existence of local directories.
If the current environment is a Trae agent, rather than a shared foreground terminal the user is personally operating, then EXECUTION_MODE must select noninteractive, and must not default to interactive。

Step 4: Initialize the project

When initializing or refreshing, first determine which directory level you are currently at:

First initialization: currently located at <workspaceRoot>, and <enterpriseRoot> does not yet exist
Refresh an existing project: currently located at <enterpriseRoot>, or <enterpriseRoot> already exists

It is forbidden to treat <enterpriseEAName> Treat it as the "current project root directory path" and concatenate it directly into the path check.

Interactive mode:

cd <workspaceRoot>
sharedev init -e <enterpriseEAName> -d <domain> -c <certificate>

If already located in the <enterpriseRoot> directory, prefer to use:

cd <enterpriseRoot>
sharedev init -e . -d <domain> -c <certificate>

Interaction is allowed only when all of the following conditions are met at the same time:

The user explicitly wants to make a manual selection
The current terminal is indeed a foreground terminal the user can directly operate

Otherwise, it must switch to non-interactive mode.

Non-interactive mode:

cd <workspaceRoot>
sharedev init --yes --agent <TARGET_PLATFORM> --pull-all-apl --pull-all-pwc -e <enterpriseEAName> -d <domain> -c <certificate>

If already cd <enterpriseRoot>, uniformly change to -e ., to avoid creating the <enterpriseEAName>/ subdirectory again:

cd <enterpriseRoot>
sharedev init --yes --agent <TARGET_PLATFORM> --pull-all-apl --pull-all-pwc -e . -d <domain> -c <certificate>

Notes:

--agent must be consistent with TARGET_PLATFORM consistent
This command is preferentially used for Claude Code / Codex / agent execution scenarios
This command may have already incidentally completed part of the initialization of docs / pwc / apl / metadata / spec
⚠️ Note:init --yes will not pull object-dev resources; you must separately execute sharedev object-dev object pull --all

Verification:

<enterpriseRoot>/ has been created
<enterpriseRoot>/.sharedev/settings.json has been created
<enterpriseRoot>/.git/ has been created

Command result determination:

If sharedev init ... return code is 0, proceed to Step 5 according to the normal flow.
If sharedev init ... returns a non-zero exit code, you must not directly mark Step 4 as completed。
When a non-zero exit code is returned, you must immediately check whether all three basic artifacts above exist:
- If any item is missing, directly mark Step 4 as blocked, and stop claiming this flow as a successful initialization.
- If all three items exist, Step 4 can only be marked as incomplete, and then you must proceed to Step 5 to fill in and review docs, PWC, APL, dev-metadata, and object-dev item by item.
Only after all missing items in Step 5 have been filled in and there are no unexplained failed items can the entire Phase A be considered complete.

Incorrect example (prohibited)：

If currently already in /path/to/ShareCRM01/Project, then execute:

sharedev init --yes --agent trae --pull-all-apl --pull-all-pwc -e Project -d <domain> -c <certificate>

you will get /path/to/ShareCRM01/Project/Project. This is incorrect usage.

Step 5: Fill in documentation and metadata

Important notes:

sharedev init --yes will notautomatically pull object-dev resources; you must separately execute
Even if sharedev init --yes returns success, you must still check item by item and fill in the missing resources

Execution flow (must check and execute item by item):

After entering <enterpriseRoot> , check and fill in each resource in the following order:

1. Check and fill in docs

cd <enterpriseRoot>
# 检查是否存在
ls .sharedev/docs/apl/ .sharedev/docs/pwc/ >/dev/null 2>&1
# 如不存在，执行：
sharedev docs download

2. Check and fill in dev-metadata

# 检查是否存在
ls .sharedev/dev-metadata/objects/ >/dev/null 2>&1
# 如不存在，执行：
sharedev dev-metadata download --all

3. Check and fill in object-dev (⚠️ Important: init will not automatically pull)

⚠️ Key distinction：

dev-metadata generates .sharedev/dev-metadata/objects/(Markdown documentation)
object-dev generates tenant-config/objects/ or object-dev/objects/(XML definition files)
The two are different resources and must not be confused!

# 检查 object-dev 是否存在（注意：不是 .sharedev/dev-metadata/objects/）
ls tenant-config/objects/ >/dev/null 2>&1 \
  || ls object-dev/objects/ >/dev/null 2>&1
# 如不存在，必须执行：
sharedev object-dev object pull --all

Notes:

This command pulls the definition files of all objects (objects, fields, layouts, layout rules, etc.)
The output directory is usually tenant-config/objects/ or object-dev/objects/
If only custom objects are needed, you can use sharedev object-dev object pull --custom
If only objects of a specific package are needed, you can use sharedev object-dev object pull --package

4. Check and complete the PWC components

# 检查是否存在
ls pwc/components/ >/dev/null 2>&1
# 如不存在，执行：
sharedev pwc pull --all --type component

5. Check and complete the APL functions

# 检查是否存在
ls package/fx/custom/apl/script/ >/dev/null 2>&1
# 如不存在，执行：
sharedev apl pull --all

Execution requirements:

When entering Step 5, a separate status must be created for each of the following resources:docs、pwc_components、apl、dev_metadata、object_dev。
Each item must be checked one by one, and as soon as a missing item is found, the corresponding completion command must be executed immediately; it must not be assumed that sharedev init --yes has pulled all resources.
As long as the verification condition for a certain resource has not yet been satisfied, that resource's status must remain incomplete or blocked, and it cannot be counted as complete just because other directories already exist.
If a completion command returns a non-zero exit code, the corresponding artifact for that resource must be immediately rechecked:
- Artifact missing: record this resource as blocked
- Artifact exists but whether it is up to date cannot be confirmed: record this resource as incomplete
If sharedev apl pull --all returns "No APL function details were returned" or another "no function details returned" result, while <enterpriseRoot>/package/fx/custom/apl/script/ still does not exist, then apl must be recorded as incomplete or blocked, and must not be counted as successful.
object_dev The completion determination must satisfy the existence of any one of the following directories (⚠️ Note: not .sharedev/dev-metadata/objects/）：
- <enterpriseRoot>/tenant-config/objects/(object-dev default output directory)
- <enterpriseRoot>/object-dev/objects/(object-dev alternative output directory)
At the end of Step 5, the status of each resource must be clearly listed; as long as any one item is not completed, the entire initialization cannot be declared complete externally.

Verification:

<enterpriseRoot>/.sharedev/docs/apl/
<enterpriseRoot>/.sharedev/docs/pwc/
<enterpriseRoot>/.sharedev/dev-metadata/
sharedev pwc pull --all --type component If resources are returned, then <enterpriseRoot>/pwc/components/
sharedev apl pull --all should be generated; if function details are returned, then <enterpriseRoot>/package/fx/custom/apl/script/
should be generated; at least one object-dev object definition directory must exist (XML format):
- <enterpriseRoot>/tenant-config/objects/(object-dev default output directory)
- <enterpriseRoot>/object-dev/objects/(object-dev alternative output directory)
dev-metadata object documentation directory (Markdown format):
- <enterpriseRoot>/.sharedev/dev-metadata/objects/

Phase B: Agent Integration

Step 6: Initialize the spec template

Interactive mode:

cd <enterpriseRoot>
sharedev spec init

Applicable conditions:

The user wants to manually select the platform
The current terminal is one the user can operate directly

Non-interactive mode:

Prefer to reuse sharedev init --yes --agent <TARGET_PLATFORM> 's already generated spec directory, and do not additionally execute sharedev spec init。

If the spec directory is still missing after non-interactive initialization, mark it as a blocking issue and report it; do not pretend the step has been completed.

Verification:

<enterpriseRoot>/.trae/ or <enterpriseRoot>/.claude/ or <enterpriseRoot>/.codex/
<spec-dir>/skills/
<spec-dir>/specs/

Step 7: Install specs

Regardless of the target platform, synchronize <enterpriseRoot>/<spec-dir>/specs/ to:

<enterpriseRoot>/.sharedev/specs/

Recommended:

mkdir -p <enterpriseRoot>/.sharedev/specs
rsync -a <enterpriseRoot>/<spec-dir>/specs/ <enterpriseRoot>/.sharedev/specs/

This is a mandatory step and cannot be skipped just because <enterpriseRoot>/.sharedev/specs/ already exists. As long as <enterpriseRoot>/<spec-dir>/specs/ exists, one synchronization must be performed to write the latest content of the platform spec into <enterpriseRoot>/.sharedev/specs/。

Step 8: Install skills

Install by platform; do not guess the environment.

Here a distinction must be made between the "source directory" and the "installation target directory":

Trae source directory:<enterpriseRoot>/.trae/skills/
Trae installation target:<workspaceRoot>/.trae/skills/
The meaning of Step 8 is to install the skills already generated in the enterprise project to a location in the current workspace where they can be used directly; the source directory must not be mistaken for installation having been completed

Trae project level:

mkdir -p <workspaceRoot>/.trae/skills
rsync -a <enterpriseRoot>/<spec-dir>/skills/ <workspaceRoot>/.trae/skills/

Claude project level:

In the project root directory (<workspaceRoot>) execute:

mkdir -p .claude/skills
rsync -a <enterpriseRoot>/<spec-dir>/skills/ .claude/skills/

Claude global:

mkdir -p ~/.claude/skills
rsync -a <enterpriseRoot>/<spec-dir>/skills/ ~/.claude/skills/

Codex global:

mkdir -p ~/.codex/skills
rsync -a <enterpriseRoot>/<spec-dir>/skills/ ~/.codex/skills/

Verification:

the target skills directory exists
each skill directory contains SKILL.md
For Trae project-level: verify <enterpriseRoot>/.trae/skills/ exists as the source directory, and <workspaceRoot>/.trae/skills/ exists as the installation target directory and contains skills

Step 8.5: Compatibility fix for installed skills

This step is used to maintain compatibility with previously installed older-version skills.

Only handle the following two skills:

sharedev-apl-implement
sharedev-apl-code-review

Compatibility fix trigger conditions:

These two skills are already installed in the target skills directory
The skill markdown still references old paths
The current project's document/object metadata is already located under the <enterpriseRoot>/ directory

Execution principles:

As long as the above trigger conditions are met, the compatibility fix must be executed
It is not allowed to only perform a scan and finish after reporting the problem
It is not allowed to treat "old paths found but not fixed" as a successful initialization
It is not allowed to rewrite matched old paths into vague descriptions to evade replacement; when a legacy literal is matched, it must be replaced with the new expression specified in the documentation

The new standard paths are:

docs root directory:<enterpriseEA>/.sharedev/docs/
objects directory:<enterpriseEA>/.sharedev/dev-metadata/objects/

The explicit mapping from old paths to new paths is as follows:

Old path/old wording	Must be replaced with
`<enterpriseEA>/.sharedev/docs/`	`<enterpriseEA>/.sharedev/docs/`
`<enterpriseEA>/.sharedev/docs/`	`<enterpriseEA>/.sharedev/docs/`
`<enterpriseEA>/.sharedev/dev-metadata/objects/`	`<enterpriseEA>/.sharedev/dev-metadata/objects/`
`<enterpriseEA>/.sharedev/dev-metadata/objects/`	`<enterpriseEA>/.sharedev/dev-metadata/objects/`
`<enterpriseEA>/.sharedev/dev-metadata/objects/`	`<enterpriseEA>/.sharedev/dev-metadata/objects/`
`查看 \`.sharedev/object/` 目录下以 `__c` 结尾的文件`	`查看 \`/.sharedev/dev-metadata/objects/` 目录下以 `__c` 结尾的文件`
`[对象索引(动态更新)](<enterpriseEA>/.sharedev/dev-metadata/objects/objects.md)`	`[对象索引(动态更新)](<enterpriseEA>/.sharedev/dev-metadata/objects/objects.md)`

Common old paths include:

<enterpriseEA>/.sharedev/docs/
<enterpriseEA>/.sharedev/docs/
<enterpriseEA>/.sharedev/dev-metadata/objects/
<enterpriseEA>/.sharedev/dev-metadata/objects/
[对象文档](<enterpriseEA>/.sharedev/dev-metadata/objects/)
[对象索引(动态更新)](<enterpriseEA>/.sharedev/dev-metadata/objects/objects.md)
**自定义对象导航** (查看 /.sharedev/dev-metadata/objects/目录下以__c 结尾的文件)

Fix rules:

Placeholder variable rules:

In the skill markdown after the compatibility fix, <enterpriseEA> must be retained as a placeholder variable
It is not allowed to render <enterpriseEA> into a specific project name, for example fktest8507
It is not allowed to write <workspace>、ENTERPRISE_EA, or absolute path concatenation results directly back into the source code of the fixed skill
When running the skill, the Agent should resolve <enterpriseEA>itself based on the current context, rather than relying on a hardcoded directory name

Target wording after the fix:

docs is uniformly written as <enterpriseEA>/.sharedev/docs/
objects is uniformly written as <enterpriseEA>/.sharedev/dev-metadata/objects/

The requirement here is mandatory:

Whenever a historical relative path or <enterpriseEA>/.sharedev/dev-metadata/objects/is seen, it must be understood as an "old path" in the subsequent compatibility process
The unified target location for subsequent compatibility is <enterpriseEA>/.sharedev/dev-metadata/objects/
<enterpriseEA>/.sharedev/dev-metadata/objects/ itself is a valid target, not an old path
It is not allowed for specific project name hardcoding to appear in the fixed skill, for example fktest8507

Execution requirements:

First determine the actual SKILL_ROOT
Only scan *.md
in the above two skill directories. First scan and record files with matched legacy paths
As long as a legacy path is matched, the replacement must be executed immediately
Only replace the two known types of old paths, docs/object
When replacing, write back in placeholder variable form, not the real project name
After the replacement is complete, rescan and verify that the old paths have been cleaned up
Finally verify that the target directory actually exists
It is not allowed to rewrite matched old literals such as <enterpriseEA>/.sharedev/dev-metadata/objects/ into vague expressions like "historical object directory" or "old directory" to bypass validation; they must be written according to the mapping table as <enterpriseEA>/.sharedev/dev-metadata/objects/ or a standard expression consistent with it

Example:

SKILL_ROOT="<resolved-skill-root>"

for skill_name in sharedev-apl-implement sharedev-apl-code-review; do
  skill_path="$SKILL_ROOT/$skill_name"
  [ -d "$skill_path" ] || continue

  matched_files=$(grep -RIl "\.\./\.\./\.\./\.sharedev/docs/\|\.\./\.\./\.\./[^/]\+/\.sharedev/docs/\|\.\./\.\./\.\./\.sharedev/object/\|`\.sharedev/object/`\|查看 `\.sharedev/object/` 目录下以 `__c` 结尾的文件" "$skill_path" --include="*.md" || true)
  [ -z "$matched_files" ] && continue

  echo "$matched_files" | while read -r file; do
    [ -n "$file" ] || continue
    perl -0pi -e "s#\\.\\./\\.\\./\\.\\./[^/]+/\\.sharedev/dev-metadata/objects/#<enterpriseEA>/.sharedev/dev-metadata/objects/#g" "$file"
    perl -0pi -e "s#\\.\\./\\.\\./\\.\\./[^/]+/\\.sharedev/docs/#<enterpriseEA>/.sharedev/docs/#g" "$file"
    perl -0pi -e "s#\\.\\./\\.\\./\\.\\./\\.sharedev/docs/#<enterpriseEA>/.sharedev/docs/#g" "$file"
    perl -0pi -e "s#\\.\\./\\.\\./\\.\\./\\.sharedev/object/#<enterpriseEA>/.sharedev/dev-metadata/objects/#g" "$file"
    perl -0pi -e "s#`\\.sharedev/object/`#`<enterpriseEA>/.sharedev/dev-metadata/objects/`#g" "$file"
    perl -0pi -e "s#查看 `\\.sharedev/object/` 目录下以 `__c` 结尾的文件#查看 `<enterpriseEA>/.sharedev/dev-metadata/objects/` 目录下以 `__c` 结尾的文件#g" "$file"
  done

  if grep -RIn "\.\./\.\./\.\./\.sharedev/object/\|\.\./\.\./\.\./[^/]\+/\.sharedev/docs/\|`\.sharedev/object/`" "$skill_path" --include="*.md"; then
    echo "compat-fix failed for $skill_name"
    exit 1
  fi
done

Note:

The above compatibility fix example writes back a placeholder variable <enterpriseEA>, not the actual project name
Whether project-level or global installation, do not rewrite the target skill markdown into absolute paths
Runtime resolution may depend on the current workspace and the current enterprise engineering context, but the skill source code must remain variable-based

Verification:

<enterpriseEA>/.sharedev/docs/ exists
<enterpriseEA>/.sharedev/dev-metadata/objects/ exists, or the CLI has pulled the object definition to <enterpriseEA>/tenant-config/objects/
If an outdated path was hit, the compatibility fix command has actually been executed
In the installed sharedev-apl-implement / sharedev-apl-code-review , the old relative docs/object path no longer remains
In the installed sharedev-apl-implement / sharedev-apl-code-review , the plain text no longer remains `<enterpriseEA>/.sharedev/dev-metadata/objects/`
The "Custom Object Navigation" text should point to <enterpriseEA>/.sharedev/dev-metadata/objects/
In the installed sharedev-apl-implement / sharedev-apl-code-review , no hardcoded specific project name should appear, for example fktest8507

Step 9: Path Strategy

Do not execute the "post-install path correction" script here.

Correct approach:

Inside skill documentation, prefer using template variables, for example:
- {{WORKSPACE_ROOT}}
- {{ENTERPRISE_EA}}
- {{SHAREDEV_ROOT}}
If template rendering is needed during installation, only allow it to be resolved at runtime; do not write the specific project name back into the skill markdown
If the current skill pack still depends on old relative paths, fix the template first; only installed old versions of sharedev-apl-implement / sharedev-apl-code-review are allowed to go through the controlled compatibility fix in Step 8.5
As long as Step 8.5 detects an old path, the fix must be executed; it cannot stop at "notification only"
The compatibility fix result of Step 8.5 must remain variable-based, for example <enterpriseEA>, and must not generate fktest8507 such hardcoded directory names

Step 10: Final Directory Verification

At minimum, verify the following directories:

<enterpriseRoot>/.sharedev/
<enterpriseRoot>/.sharedev/specs/
<enterpriseRoot>/.sharedev/dev-metadata/objects/
<enterpriseRoot>/.trae/skills/        # Trae 来源目录
<workspaceRoot>/.trae/skills/         # Trae 安装目标
<workspaceRoot>/.claude/skills/       # Claude 项目级
~/.claude/skills/                   # Claude 全局
~/.codex/skills/                    # Codex 全局

The following directories are "existence determined by resource return status" and should not be used alone as blocking conditions:

<enterpriseRoot>/package/fx/custom/apl/script/
<enterpriseRoot>/pwc/components/
<enterpriseRoot>/tenant-config/objects/
<enterpriseRoot>/object-dev/objects/

And additionally create:

mkdir -p <enterpriseRoot>/deliverables

Output Requirements

After execution ends, the following must be clearly output:

TARGET_PLATFORM
EXECUTION_MODE
INSTALL_SCOPE
Step-by-step status from Step 1 to Step 10 (completed / incomplete / blocked）
The reason for each step's status
Completed steps
Incomplete steps
Whether there are blocking items

Blocking conditions

If any of the following occurs, you must stop and explain:

settings.json is missing key fields
sharedev init --yes failed and cannot be rolled back
sharedev spec init requires user interaction, but the current terminal is not a user-operable terminal
The spec directory does not exist, causing subsequent skills/specs to fail to install
Network/permission issues cause key resources to fail to download
After the compatibility fix, <enterpriseEA>/.sharedev/docs/ does not exist, or the object definition is neither in <enterpriseEA>/.sharedev/dev-metadata/objects/ nor in <enterpriseEA>/tenant-config/objects/
An installed old version of sharedev-apl-implement / sharedev-apl-code-review is detected to still contain legacy paths, but the compatibility fix was not executed or old paths still remain after execution
sharedev init、sharedev apl pull --all、sharedev dev-metadata download --all and other key commands return a non-zero exit code, and the corresponding resource status is still incomplete or blocked

Adaptation Recommendations

Trae IDE

Prefer project-level skills
Allow when the user can interact directly sharedev spec init
If the IDE terminal is not a shared foreground terminal, or if this is currently being executed by a Trae agent on behalf, then it must fall back to non-interactive mode
The Trae agent should not end early just because Step 5 is complete; it must still continue executing Step 6 through Step 10

Claude Code

Default non-interactive
Default project-level skills; only install to ~/.claude/skills/
Do not assume the user can directly operate the agent's PTY

Codex

Default non-interactive
Default global install to ~/.codex/skills/
Do not require executing codex --enable skills

Checklist

Checked sharedev CLI
Read settings.json
Clarified TARGET_PLATFORM
Clarified EXECUTION_MODE
Clarified INSTALL_SCOPE
Completed workspace bootstrap
Made an explicit determination of Step 4's exit code, and did not directly treat a non-zero return code as success
Gave status for docs, PWC, APL, dev-metadata, and object-dev respectively
Completed object-dev resource fetching
Completed specs installation
Completed skills installation
Completed the compatibility fix check for installed skills
If a legacy path was hit, the compatibility fix was actually completed and the re-scan passed
Completed final directory verification
Finally output the step-by-step status from Step 1 to Step 10

About this skill

Goals

Prerequisite Rules

Input Parameters

Required input

Runtime Variables

Must determine

Platform matrix

Recommended defaults

Execution state conventions

Execution flow

Phase A: Workspace Bootstrap

Step 1: Check the sharedev CLI

Step 2: Read settings.json

Step 3: Determine the execution mode

Step 4: Initialize the project

Step 5: Fill in documentation and metadata

Phase B: Agent Integration

Step 6: Initialize the spec template

Step 7: Install specs

Step 8: Install skills

Step 8.5: Compatibility fix for installed skills

Step 9: Path Strategy

Step 10: Final Directory Verification

Output Requirements

Blocking conditions

Adaptation Recommendations

Trae IDE

Claude Code

Codex

Checklist