按要求测试了重新交了，希望通过。。。
## What problem are you trying to solve?
Trae users currently do not have a native Superpowers installation entrypoint comparable to `.codex` and `.opencode`. In practice this means users must manually recreate `.trae/rules`, transform nested skills into a flat `.trae/skills/` layout, and remember to persist project workflow constraints through Trae memory. That setup is easy to get wrong, hard to repeat, and does not match the repository's existing editor-specific entrypoint pattern.
## What does this PR change?
This PR adds `.trae/INSTALL.md` and `.trae/rules/superpowers.md` as a Trae-native installation path. The installer prompt creates the runtime `.trae` layout from the project root, flattens `superpowers-skills`, renames `using-skills` to `using-superpowers`, refreshes project-level memory first and falls back to creating it if no matching entry exists, preserves non-conflicting existing content, and stops safely on risky existing `.trae` entries.
## Is this change appropriate for the core library?
I believe it is appropriate if the repository intends `.codex` and `.opencode` to define an editor-specific installation surface for first-party usage. This PR follows that same pattern for another widely used harness rather than adding a project-specific skill or third-party service integration.
If maintainers prefer Trae support to live outside the core repository, I am happy to adapt this into a separate companion repository instead. I chose the in-repo approach because the existing repo already contains editor-specific entrypoints and because the adaptation stays close to the core Superpowers workflow rather than introducing a separate product integration layer.
## What alternatives did you consider?
1. Maintain a separate Trae-only fork or template repository. I rejected this because it increases drift and makes Trae support harder to discover than the existing `.codex` / `.opencode` entrypoints.
2. Copy the full skills tree directly into `.trae`. I rejected this because it duplicates upstream content and makes updates harder to manage than pulling from `superpowers-skills`.
3. Block installation whenever `.trae` contains anything other than `rules/` and `skills/`. I rejected this after evaluation because it was too strict for real projects. The current installer uses a lax mode that preserves empty extra directories, but still blocks on unexpected files or non-empty directories that may require manual review.
## Does this PR contain multiple unrelated changes?
No. All changes are scoped to adding and validating a Trae-native installation entrypoint.
## Existing PRs
- [ ] I have reviewed all open AND closed PRs for duplicates or prior art
- Related PRs: #672, #811
I did review the existing Trae-related prior art I could find in this repository. The main differences in this PR are:
- It uses `.trae/rules/superpowers.md` plus project memory rather than relying on a bootstrap rule or symlink-only setup.
- It explicitly adapts nested `superpowers-skills` into Trae's flatter runtime layout.
- It evaluates safety boundaries around existing `.trae` content, including custom rules, custom skills, empty extra directories, and unexpected risky entries.
## Environment tested
| Harness (e.g. Claude Code, Cursor) | Harness version | Model | Model version/ID |
|-------------------------------------|-----------------|-------|------------------|
| Trae IDE | not recorded | GPT | GPT-5.4 |
| Trae IDE | not recorded | Codex | 5.3 |
| Trae IDE | not recorded | Gemini Pro | 3.1 |
## Evaluation
- Initial prompt: "Add a native `.trae` installation entrypoint for Superpowers that mirrors the `.codex` / `.opencode` pattern, initializes `.trae/rules` and `.trae/skills`, adapts nested skills to Trae's flat resolution model, and persists the project workflow through Trae project memory."
- Eval sessions after the change: 4 major eval rounds plus follow-up reruns while tightening installer safety and lax-mode behavior.
- Outcome changes compared to before:
- Before: no native Trae entrypoint; setup was manual, inconsistent, and could regress into nested skill layouts or unsafe cleanup behavior.
- After: the installation flow is documented and repeatedly evaluated across clean init, existing project content, extra rule files, custom skills with same-name and different-name conflicts, lax-mode empty-directory handling, and safe blocking on unexpected files or non-empty directories.
- The current evaluated behavior is: refresh existing project memory first, add it only if refresh is not possible; preserve custom non-conflicting content; preserve empty unexpected directories in lax mode; and stop safely for manual review when unexpected risky content is present.
- For pre-merge evaluation, the equivalent rule file was exercised from the PR branch / fork path. The submitted PR content switches the published installer reference to the canonical upstream repository path expected after merge.
## Rigor
- [ ] If this is a skills change: I used `superpowers:writing-skills` and completed adversarial pressure testing (paste results below)
- [x] This change was tested adversarially, not just on the happy path
- [x] I did not modify carefully-tuned content (Red Flags table, rationalizations, "human partner" language) without extensive evals showing the change is an improvement
Adversarial evaluation included:
- clean init
- existing project files already present
- extra `.trae/rules/*.md` content preserved
- existing custom skills preserved when names do not conflict
- existing same-name skills replaced by the Superpowers version
- unexpected empty `.trae` directories preserved in lax mode
- unexpected non-empty directories and unexpected files blocked for manual review
## Human review
- [x] A human has reviewed the COMPLETE proposed diff before submission
Hi, I'm a community contributor. I noticed that many Trae users are trying to adopt this framework, so I prepared this native adaptation. If maintainers want a different structure or narrower scope, I am happy to revise the PR.
### Additional notes for Trae maintainers
- **No Hooks Required**: This adaptation uses Trae memory and workspace rules rather than external shell hooks.
- **Flattened Skills Directory**: Trae currently resolves skills more reliably from a flat `.trae/skills/` layout.
- **Flowcharts -> Todo List**: Guided workflows map well to Trae's Todo List experience rather than terminal-only checklists.
- **Project Memory Update First**: The installer asks Trae to refresh an existing project-level Superpowers memory first and only create a new entry if refresh is not possible. This takes advantage of Trae IDE's memory update mechanism rather than treating memory as write-once state.
- **Solo Builder Recommendation**: This workflow is best suited to Trae's Builder / Solo Builder experience.
- **Context Consumption Warning**: Dynamic skill loading and continuous memory usage can consume context faster than usual, so the installation guide warns users about that tradeoff.
## What problem are you trying to solve?
Trae users currently do not have a native Superpowers installation entrypoint comparable to `.codex` and `.opencode`. In practice this means users must manually recreate `.trae/rules`, transform nested skills into a flat `.trae/skills/` layout, and remember to persist project workflow constraints through Trae memory. That setup is easy to get wrong, hard to repeat, and does not match the repository's existing editor-specific entrypoint pattern.
## What does this PR change?
This PR adds `.trae/INSTALL.md` and `.trae/rules/superpowers.md` as a Trae-native installation path. The installer prompt creates the runtime `.trae` layout from the project root, flattens `superpowers-skills`, renames `using-skills` to `using-superpowers`, refreshes project-level memory first and falls back to creating it if no matching entry exists, preserves non-conflicting existing content, and stops safely on risky existing `.trae` entries.
## Is this change appropriate for the core library?
I believe it is appropriate if the repository intends `.codex` and `.opencode` to define an editor-specific installation surface for first-party usage. This PR follows that same pattern for another widely used harness rather than adding a project-specific skill or third-party service integration.
If maintainers prefer Trae support to live outside the core repository, I am happy to adapt this into a separate companion repository instead. I chose the in-repo approach because the existing repo already contains editor-specific entrypoints and because the adaptation stays close to the core Superpowers workflow rather than introducing a separate product integration layer.
## What alternatives did you consider?
1. Maintain a separate Trae-only fork or template repository. I rejected this because it increases drift and makes Trae support harder to discover than the existing `.codex` / `.opencode` entrypoints.
2. Copy the full skills tree directly into `.trae`. I rejected this because it duplicates upstream content and makes updates harder to manage than pulling from `superpowers-skills`.
3. Block installation whenever `.trae` contains anything other than `rules/` and `skills/`. I rejected this after evaluation because it was too strict for real projects. The current installer uses a lax mode that preserves empty extra directories, but still blocks on unexpected files or non-empty directories that may require manual review.
## Does this PR contain multiple unrelated changes?
No. All changes are scoped to adding and validating a Trae-native installation entrypoint.
## Existing PRs
- [ ] I have reviewed all open AND closed PRs for duplicates or prior art
- Related PRs: #672, #811
I did review the existing Trae-related prior art I could find in this repository. The main differences in this PR are:
- It uses `.trae/rules/superpowers.md` plus project memory rather than relying on a bootstrap rule or symlink-only setup.
- It explicitly adapts nested `superpowers-skills` into Trae's flatter runtime layout.
- It evaluates safety boundaries around existing `.trae` content, including custom rules, custom skills, empty extra directories, and unexpected risky entries.
## Environment tested
| Harness (e.g. Claude Code, Cursor) | Harness version | Model | Model version/ID |
|-------------------------------------|-----------------|-------|------------------|
| Trae IDE | not recorded | GPT | GPT-5.4 |
| Trae IDE | not recorded | Codex | 5.3 |
| Trae IDE | not recorded | Gemini Pro | 3.1 |
## Evaluation
- Initial prompt: "Add a native `.trae` installation entrypoint for Superpowers that mirrors the `.codex` / `.opencode` pattern, initializes `.trae/rules` and `.trae/skills`, adapts nested skills to Trae's flat resolution model, and persists the project workflow through Trae project memory."
- Eval sessions after the change: 4 major eval rounds plus follow-up reruns while tightening installer safety and lax-mode behavior.
- Outcome changes compared to before:
- Before: no native Trae entrypoint; setup was manual, inconsistent, and could regress into nested skill layouts or unsafe cleanup behavior.
- After: the installation flow is documented and repeatedly evaluated across clean init, existing project content, extra rule files, custom skills with same-name and different-name conflicts, lax-mode empty-directory handling, and safe blocking on unexpected files or non-empty directories.
- The current evaluated behavior is: refresh existing project memory first, add it only if refresh is not possible; preserve custom non-conflicting content; preserve empty unexpected directories in lax mode; and stop safely for manual review when unexpected risky content is present.
- For pre-merge evaluation, the equivalent rule file was exercised from the PR branch / fork path. The submitted PR content switches the published installer reference to the canonical upstream repository path expected after merge.
## Rigor
- [ ] If this is a skills change: I used `superpowers:writing-skills` and completed adversarial pressure testing (paste results below)
- [x] This change was tested adversarially, not just on the happy path
- [x] I did not modify carefully-tuned content (Red Flags table, rationalizations, "human partner" language) without extensive evals showing the change is an improvement
Adversarial evaluation included:
- clean init
- existing project files already present
- extra `.trae/rules/*.md` content preserved
- existing custom skills preserved when names do not conflict
- existing same-name skills replaced by the Superpowers version
- unexpected empty `.trae` directories preserved in lax mode
- unexpected non-empty directories and unexpected files blocked for manual review
## Human review
- [x] A human has reviewed the COMPLETE proposed diff before submission
Hi, I'm a community contributor. I noticed that many Trae users are trying to adopt this framework, so I prepared this native adaptation. If maintainers want a different structure or narrower scope, I am happy to revise the PR.
### Additional notes for Trae maintainers
- **No Hooks Required**: This adaptation uses Trae memory and workspace rules rather than external shell hooks.
- **Flattened Skills Directory**: Trae currently resolves skills more reliably from a flat `.trae/skills/` layout.
- **Flowcharts -> Todo List**: Guided workflows map well to Trae's Todo List experience rather than terminal-only checklists.
- **Project Memory Update First**: The installer asks Trae to refresh an existing project-level Superpowers memory first and only create a new entry if refresh is not possible. This takes advantage of Trae IDE's memory update mechanism rather than treating memory as write-once state.
- **Solo Builder Recommendation**: This workflow is best suited to Trae's Builder / Solo Builder experience.
- **Context Consumption Warning**: Dynamic skill loading and continuous memory usage can consume context faster than usual, so the installation guide warns users about that tradeoff.
还好啦还好啦 啥都搞搞