一、command
codex貌似不支持？？？
如我之前在cursor建过Multi-Control的command 工具Cursor（六）Rules&Skill&Commands（3）commands_cusor skill-CSDN博客
到codex中对应到skill，可以让codex帮忙转化。如这是我转化后的：
SKILL.md
---
name: multi-control
description: Add or update wtyy-api-web multi-control features in for system and user levels from a parent feature key plus child feature definitions. Use when the user wants to batch add or extend a multi-control feature, asks to modify feature_rule.yml, FeatureOptionEnum, FeatureConstant, FeatureFeatchService, DTO/BOs, or user-template processors for a parent feature with multiple children.
---
# Multi-Control
Use this skill to implement or extend a multi-control feature in `wtyy-api-web`.
## Gather input first
Require:
- parent feature key in camelCase
- parent feature type when provided; otherwise default to `Boolean`
- every child `featureKey`
- every child `type` as `Boolean`, `Integer`, or `String`
If children are missing, or any child is missing a key or type, stop and ask the user to fill the gap before editing code.
## Scope and source of truth
- Treat `/src/main/resources/feature_rule.yml` as the source of truth.
- Limit changes to `` and any module the user explicitly names.
- Do not modify `wtyy-api-common` unless the user explicitly asks for it or the team requires the same PR.
## Workflow
1. Convert the parent key to `snake_case`, then inspect `/src/main/resources/feature_rule.yml`.
2. Determine whether the parent already exists as a top-level key.
3. Determine whether `<parent_snake>_for_upgrade` also exists.
4. Read [editing-rules.md](references/editing-rules.md) and apply the correct new-vs-update path.
5. If the user later says user template changes are needed, read [user-template.md](references/user-template.md) and implement that part too.
## Execution rules
- Append at the relevant trailing position; do not reorder unrelated content.
- Match existing naming, enum placement, DTO placement, and `ForUpgrade` conventions already used for that parent.
- Only add enum items for Boolean children.
- Only update `FeatureConstant` and `Constants.FEATURE_LOAD_LIST` when this change introduces `ext_value`.
- Keep `_for_upgrade` handling aligned with the project's existing sibling patterns instead of inventing a new shape.
## Finish
- Run the relevant validation or compile flow that the repo already uses.
- Summarize what changed, whether `_for_upgrade` was involved, and which DTO, enum, constant, or service files were touched.
- Ask whether user template changes are also needed. Only do that work after an explicit yes./references/editing-rules.md
# Editing Rules
Follow these rules when implementing the parent feature and its children.
## Step 0: Parse input and inspect parent state
- Parse parent key, parent type, and each child key and type.
- Default parent type to `Boolean` when the user does not specify one.
- In `/src/main/resources/feature_rule.yml`, check whether the parent `snake_case` key already exists as a top-level key.
- In the same file, check whether `<parent_snake>_for_upgrade` exists.
- If the parent does not exist, take the new-feature path.
- If the parent exists, only append under that parent's existing locations; do not create a second parent block.
## Step 1: Update `feature_rule.yml`
### New parent
- Add the parent top-level block at the end of the file.
- Define only system and user branches.
### Existing parent
- Append only under that parent's `system.children` and `user.children`.
- Append at the end of the `children` list.
- Do not leave extra blank lines between the last existing child and the new child.
### `_for_upgrade`
- If `<parent_snake>_for_upgrade` exists, update both the main parent tree and the `_for_upgrade` tree.
- In the main parent tree, append the plain child name.
- In the `_for_upgrade` tree, follow existing sibling patterns for:
- child key naming
- `feature_key` naming such as `xxxForUpgrade`
- enum names
- `ext_value`
- user-side `bit_value_enum`
## Step 2: Update `FeatureOptionEnum.java`
- Only add enum items in the system and User sections.
- Only Boolean children get enum entries.
- Append to the end of the relevant section rather than inserting into the middle.
- Continue the current bit progression and field progression used by the file.
- Preserve the file's spacing conventions: no blank lines inside a section, one blank line between major sections.
- If user `_for_upgrade` entries already exist for this parent and the file pattern expects `user_xxx_FOR_UPGRADE`, append those too.
## Step 3: Update DTO and BO classes
Typical targets include:
- `systemUpdateInBO`
- `userUpdateDTO`
Rules:
- Map types directly: `Boolean -> Boolean`, `Integer -> Integer`, `String -> String`.
- For a new parent, append the parent and child fields near the end of the class, after the last related field and before `}`.
- For an existing parent, insert new child fields immediately after the last existing field related to that parent.
- Match existing user permission annotations and field annotations.
- Only add `ForUpgrade` fields when that class already uses `ForUpgrade` fields for the same parent.
## Step 4: Update `FeatureFeatchService` when the parent is Boolean
- Add the parent constant when needed.
- If this parent already has a DTO-returning getter, append new fields to that DTO and keep the current data-shaping style.
- If the parent has no dedicated getter and this is a new Boolean parent, add the getter and DTO using the existing service patterns.
- If the current return type is a primitive or simple type, do not force a DTO conversion unless the new-parent path already requires it.
## Step 5: Handle `ext_value`
- Only do this when the new system-side children introduce `ext_value`.
- Add constants in `FeatureConstant` for each new `ext_value`.
- In `Constants.java`, append the corresponding constant references to `FEATURE_LOAD_LIST`.
- Never hardcode the string in `FEATURE_LOAD_LIST`.
- If user `_for_upgrade` also introduces load-list-managed `ext_value`, mirror the same treatment there.
## Step 6: Validate and summarize
- Keep changes limited to files directly related to this multi-control task.
- If unrelated local changes already exist, mention that they predated this task.
- Run the repo's compile or validation path for the touched modules.
- Report:
- parent key and type
- added or updated children
- whether `_for_upgrade` was involved
- enum additions
- DTO and BO insertion points
- `FeatureConstant` and `FEATURE_LOAD_LIST` updates
- `FeatureFeatchService` changes
- Ask whether user template work is also needed. Do not do Step 7 without explicit approval./references/queue-template.md
# User Template
Read this file only after the user explicitly says User template changes are needed.
## Locate the processor
- Work inside `UserTemplate.processor` and confirm the actual package path from the repo.
- Start from the parent top-level key in `feature_rule.yml`.
- Search for likely processor names such as `{ParentPascalCase}AccessProcessor`.
- Also search by:
- parent `FeatureConstant`
- `UserTemplateSection`
- existing processor registrations
If no matching processor exists, create one by following the project's existing processor and registration pattern. Use `UserProfileProcessor` as a style reference when that file exists.
## Update behavior
- Match the current section and settings structure used for sibling children of the same parent.
- If the parent has `_for_upgrade` handling in the processor, mirror that shape for the new children.
- Do not assume `UserTemplateUpdateDTO` inheritance is enough; verify template patching, copy, defaulting, save, and apply-to-User flows.
## Validate
- Run compile or the team's standard build path for touched modules.
- Run lints or equivalent checks when available.
- Self-check that template save, read-back, and User application remain consistent with the feature rule and DTO changes.