@colin4k1024/tsp 2.4.0

package/skills/prompt-optimizer/SKILL.md

@@ -0,0 +1,397 @@
+---
+name: prompt-optimizer
+description: >-
+  Analyze raw prompts, identify intent and gaps, match ECC components
+  (skills/commands/agents/hooks), and output a ready-to-paste optimized
+  prompt. Advisory role only — never executes the task itself.
+  TRIGGER when: user says "optimize prompt", "improve my prompt",
+  "how to write a prompt for", "help me prompt", "rewrite this prompt",
+  or explicitly asks to enhance prompt quality. Also triggers on Chinese
+  equivalents: "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令".
+  DO NOT TRIGGER when: user wants the task executed directly, or says
+  "just do it" / "直接做". DO NOT TRIGGER when user says "优化代码",
+  "优化性能", "optimize performance", "optimize this code" — those are
+  refactoring/performance tasks, not prompt optimization.
+origin: community
+metadata:
+  author: YannJY02
+  version: "1.0.0"
+---
+
+# Prompt Optimizer
+
+Analyze a draft prompt, critique it, match it to ECC ecosystem components,
+and output a complete optimized prompt the user can paste and run.
+
+## When to Use
+
+- User says "optimize this prompt", "improve my prompt", "rewrite this prompt"
+- User says "help me write a better prompt for..."
+- User says "what's the best way to ask Claude Code to..."
+- User says "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令"
+- User pastes a draft prompt and asks for feedback or enhancement
+- User says "I don't know how to prompt for this"
+- User says "how should I use ECC for..."
+- User explicitly invokes `/prompt-optimize`
+
+### Do Not Use When
+
+- User wants the task done directly (just execute it)
+- User says "优化代码", "优化性能", "optimize this code", "optimize performance" — these are refactoring tasks, not prompt optimization
+- User is asking about ECC configuration (use `configure-ecc` instead)
+- User wants a skill inventory (use `skill-stocktake` instead)
+- User says "just do it" or "直接做"
+
+## How It Works
+
+**Advisory only — do not execute the user's task.**
+
+Do NOT write code, create files, run commands, or take any implementation
+action. Your ONLY output is an analysis plus an optimized prompt.
+
+If the user says "just do it", "直接做", or "don't optimize, just execute",
+do not switch into implementation mode inside this skill. Tell the user this
+skill only produces optimized prompts, and instruct them to make a normal
+task request if they want execution instead.
+
+Run this 6-phase pipeline sequentially. Present results using the Output Format below.
+
+### Analysis Pipeline
+
+### Phase 0: Project Detection
+
+Before analyzing the prompt, detect the current project context:
+
+1. Check if a `CLAUDE.md` exists in the working directory — read it for project conventions
+2. Detect tech stack from project files:
+   - `package.json` → Node.js / TypeScript / React / Next.js
+   - `go.mod` → Go
+   - `pyproject.toml` / `requirements.txt` → Python
+   - `Cargo.toml` → Rust
+   - `build.gradle` / `pom.xml` → Java / Kotlin / Spring Boot
+   - `Package.swift` → Swift
+   - `Gemfile` → Ruby
+   - `composer.json` → PHP
+   - `*.csproj` / `*.sln` → .NET
+   - `Makefile` / `CMakeLists.txt` → C / C++
+   - `cpanfile` / `Makefile.PL` → Perl
+3. Note detected tech stack for use in Phase 3 and Phase 4
+
+If no project files are found (e.g., the prompt is abstract or for a new project),
+skip detection and flag "tech stack unknown" in Phase 4.
+
+### Phase 1: Intent Detection
+
+Classify the user's task into one or more categories:
+
+| Category | Signal Words | Example |
+|----------|-------------|---------|
+| New Feature | build, create, add, implement, 创建, 实现, 添加 | "Build a login page" |
+| Bug Fix | fix, broken, not working, error, 修复, 报错 | "Fix the auth flow" |
+| Refactor | refactor, clean up, restructure, 重构, 整理 | "Refactor the API layer" |
+| Research | how to, what is, explore, investigate, 怎么, 如何 | "How to add SSO" |
+| Testing | test, coverage, verify, 测试, 覆盖率 | "Add tests for the cart" |
+| Review | review, audit, check, 审查, 检查 | "Review my PR" |
+| Documentation | document, update docs, 文档 | "Update the API docs" |
+| Infrastructure | deploy, CI, docker, database, 部署, 数据库 | "Set up CI/CD pipeline" |
+| Design | design, architecture, plan, 设计, 架构 | "Design the data model" |
+
+### Phase 2: Scope Assessment
+
+If Phase 0 detected a project, use codebase size as a signal. Otherwise, estimate
+from the prompt description alone and mark the estimate as uncertain.
+
+| Scope | Heuristic | Orchestration |
+|-------|-----------|---------------|
+| TRIVIAL | Single file, < 50 lines | Direct execution |
+| LOW | Single component or module | Single command or skill |
+| MEDIUM | Multiple components, same domain | Command chain + /verify |
+| HIGH | Cross-domain, 5+ files | /plan first, then phased execution |
+| EPIC | Multi-session, multi-PR, architectural shift | Use blueprint skill for multi-session plan |
+
+### Phase 3: ECC Component Matching
+
+Map intent + scope + tech stack (from Phase 0) to specific ECC components.
+
+#### By Intent Type
+
+| Intent | Commands | Skills | Agents |
+|--------|----------|--------|--------|
+| New Feature | /plan, /tdd, /code-review, /verify | tdd-workflow, verification-loop | planner, tdd-guide, code-reviewer |
+| Bug Fix | /tdd, /build-fix, /verify | tdd-workflow | tdd-guide, build-error-resolver |
+| Refactor | /refactor-clean, /code-review, /verify | verification-loop | refactor-cleaner, code-reviewer |
+| Research | /plan | search-first, iterative-retrieval | — |
+| Testing | /tdd, /e2e, /test-coverage | tdd-workflow, e2e-testing | tdd-guide, e2e-runner |
+| Review | /code-review | security-review | code-reviewer, security-reviewer |
+| Documentation | /update-docs, /update-codemaps | — | doc-updater |
+| Infrastructure | /plan, /verify | docker-patterns, deployment-patterns, database-migrations | architect |
+| Design (MEDIUM-HIGH) | /plan | — | planner, architect |
+| Design (EPIC) | — | blueprint (invoke as skill) | planner, architect |
+
+#### By Tech Stack
+
+| Tech Stack | Skills to Add | Agent |
+|------------|--------------|-------|
+| Python / Django | django-patterns, django-tdd, django-security, django-verification, python-patterns, python-testing | python-reviewer |
+| Go | golang-patterns, golang-testing | go-reviewer, go-build-resolver |
+| Spring Boot / Java | springboot-patterns, springboot-tdd, springboot-security, springboot-verification, java-coding-standards, jpa-patterns | code-reviewer |
+| Kotlin / Android | kotlin-coroutines-flows, compose-multiplatform-patterns, android-clean-architecture | kotlin-reviewer |
+| TypeScript / React | frontend-patterns, backend-patterns, coding-standards | code-reviewer |
+| Swift / iOS | swiftui-patterns, swift-concurrency-6-2, swift-actor-persistence, swift-protocol-di-testing | code-reviewer |
+| PostgreSQL | postgres-patterns, database-migrations | database-reviewer |
+| Perl | perl-patterns, perl-testing, perl-security | code-reviewer |
+| C++ | cpp-coding-standards, cpp-testing | code-reviewer |
+| Other / Unlisted | coding-standards (universal) | code-reviewer |
+
+### Phase 4: Missing Context Detection
+
+Scan the prompt for missing critical information. Check each item and mark
+whether Phase 0 auto-detected it or the user must supply it:
+
+- [ ] **Tech stack** — Detected in Phase 0, or must user specify?
+- [ ] **Target scope** — Files, directories, or modules mentioned?
+- [ ] **Acceptance criteria** — How to know the task is done?
+- [ ] **Error handling** — Edge cases and failure modes addressed?
+- [ ] **Security requirements** — Auth, input validation, secrets?
+- [ ] **Testing expectations** — Unit, integration, E2E?
+- [ ] **Performance constraints** — Load, latency, resource limits?
+- [ ] **UI/UX requirements** — Design specs, responsive, a11y? (if frontend)
+- [ ] **Database changes** — Schema, migrations, indexes? (if data layer)
+- [ ] **Existing patterns** — Reference files or conventions to follow?
+- [ ] **Scope boundaries** — What NOT to do?
+
+**If 3+ critical items are missing**, ask the user up to 3 clarification
+questions before generating the optimized prompt. Then incorporate the
+answers into the optimized prompt.
+
+### Phase 5: Workflow & Model Recommendation
+
+Determine where this prompt sits in the development lifecycle:
+
+```
+Research → Plan → Implement (TDD) → Review → Verify → Commit
+```
+
+For MEDIUM+ tasks, always start with /plan. For EPIC tasks, use blueprint skill.
+
+**Model recommendation** (include in output):
+
+| Scope | Recommended Model | Rationale |
+|-------|------------------|-----------|
+| TRIVIAL-LOW | Sonnet 4.6 | Fast, cost-efficient for simple tasks |
+| MEDIUM | Sonnet 4.6 | Best coding model for standard work |
+| HIGH | Sonnet 4.6 (main) + Opus 4.6 (planning) | Opus for architecture, Sonnet for implementation |
+| EPIC | Opus 4.6 (blueprint) + Sonnet 4.6 (execution) | Deep reasoning for multi-session planning |
+
+**Multi-prompt splitting** (for HIGH/EPIC scope):
+
+For tasks that exceed a single session, split into sequential prompts:
+- Prompt 1: Research + Plan (use search-first skill, then /plan)
+- Prompt 2-N: Implement one phase per prompt (each ends with /verify)
+- Final Prompt: Integration test + /code-review across all phases
+- Use /save-session and /resume-session to preserve context between sessions
+
+---
+
+## Output Format
+
+Present your analysis in this exact structure. Respond in the same language
+as the user's input.
+
+### Section 1: Prompt Diagnosis
+
+**Strengths:** List what the original prompt does well.
+
+**Issues:**
+
+| Issue | Impact | Suggested Fix |
+|-------|--------|---------------|
+| (problem) | (consequence) | (how to fix) |
+
+**Needs Clarification:** Numbered list of questions the user should answer.
+If Phase 0 auto-detected the answer, state it instead of asking.
+
+### Section 2: Recommended ECC Components
+
+| Type | Component | Purpose |
+|------|-----------|---------|
+| Command | /plan | Plan architecture before coding |
+| Skill | tdd-workflow | TDD methodology guidance |
+| Agent | code-reviewer | Post-implementation review |
+| Model | Sonnet 4.6 | Recommended for this scope |
+
+### Section 3: Optimized Prompt — Full Version
+
+Present the complete optimized prompt inside a single fenced code block.
+The prompt must be self-contained and ready to copy-paste. Include:
+- Clear task description with context
+- Tech stack (detected or specified)
+- /command invocations at the right workflow stages
+- Acceptance criteria
+- Verification steps
+- Scope boundaries (what NOT to do)
+
+For items that reference blueprint, write: "Use the blueprint skill to..."
+(not `/blueprint`, since blueprint is a skill, not a command).
+
+### Section 4: Optimized Prompt — Quick Version
+
+A compact version for experienced ECC users. Vary by intent type:
+
+| Intent | Quick Pattern |
+|--------|--------------|
+| New Feature | `/plan [feature]. /tdd to implement. /code-review. /verify.` |
+| Bug Fix | `/tdd — write failing test for [bug]. Fix to green. /verify.` |
+| Refactor | `/refactor-clean [scope]. /code-review. /verify.` |
+| Research | `Use search-first skill for [topic]. /plan based on findings.` |
+| Testing | `/tdd [module]. /e2e for critical flows. /test-coverage.` |
+| Review | `/code-review. Then use security-reviewer agent.` |
+| Docs | `/update-docs. /update-codemaps.` |
+| EPIC | `Use blueprint skill for "[objective]". Execute phases with /verify gates.` |
+
+### Section 5: Enhancement Rationale
+
+| Enhancement | Reason |
+|-------------|--------|
+| (what was added) | (why it matters) |
+
+### Footer
+
+> Not what you need? Tell me what to adjust, or make a normal task request
+> if you want execution instead of prompt optimization.
+
+---
+
+## Examples
+
+### Trigger Examples
+
+- "Optimize this prompt for ECC"
+- "Rewrite this prompt so Claude Code uses the right commands"
+- "帮我优化这个指令"
+- "How should I prompt ECC for this task?"
+
+### Example 1: Vague Chinese Prompt (Project Detected)
+
+**User input:**
+```
+帮我写一个用户登录页面
+```
+
+**Phase 0 detects:** `package.json` with Next.js 15, TypeScript, Tailwind CSS
+
+**Optimized Prompt (Full):**
+```
+使用项目现有技术栈（Next.js 15 + TypeScript + Tailwind CSS）实现用户登录页面。
+
+技术要求：
+- 沿用项目现有的组件结构和路由约定
+- 表单验证使用项目中已有的验证方案（检查是否已用 Zod/Yup/其他）
+- 认证方式：沿用项目现有认证方案（如无，默认 JWT）
+- 包含：邮箱/密码登录表单、表单验证、错误提示、加载状态、响应式布局
+
+工作流：
+1. /plan 先规划组件结构和认证流程，参考现有页面的模式
+2. /tdd 测试先行：编写登录表单的单元测试和认证流程的集成测试
+3. 实现登录页面和认证逻辑
+4. /code-review 审查实现
+5. /verify 验证所有测试通过且页面正常渲染
+
+安全要求：
+- 密码不明文传输
+- 防止暴力破解（rate limiting）
+- XSS 防护
+- CSRF token
+
+验收标准：
+- 所有测试通过，覆盖率 80%+
+- 页面在移动端和桌面端正常渲染
+- 登录成功跳转到 dashboard，失败显示错误信息
+
+不要做：
+- 不要实现注册页面
+- 不要实现忘记密码功能
+- 不要修改现有的路由结构
+```
+
+### Example 2: Moderate English Prompt
+
+**User input:**
+```
+Add a REST API endpoint for user profile updates with validation
+```
+
+**Phase 0 detects:** `go.mod` with Go 1.22, Chi router
+
+**Optimized Prompt (Full):**
+```
+Add a REST API endpoint for user profile updates (PATCH /api/users/:id).
+
+Tech stack: Go 1.22 + Chi router (detected from project)
+
+Requirements:
+- PATCH /api/users/:id — partial update of user profile
+- Input validation for fields: name, email, avatar_url, bio
+- Auth: require valid token, users can only update own profile
+- Return 200 with updated user on success
+- Return 400 with validation errors on invalid input
+- Return 401/403 for auth failures
+- Follow existing API patterns in the codebase
+
+Workflow:
+1. /plan the endpoint structure, middleware chain, and validation logic
+2. /tdd — write table-driven tests for success, validation failure, auth failure, not-found
+3. Implement following existing handler patterns
+4. /go-review
+5. /verify — run full test suite, confirm no regressions
+
+Do not:
+- Modify existing endpoints
+- Change the database schema (use existing user table)
+- Add new dependencies without checking existing ones first (use search-first skill)
+```
+
+### Example 3: EPIC Project
+
+**User input:**
+```
+Migrate our monolith to microservices
+```
+
+**Optimized Prompt (Full):**
+```
+Use the blueprint skill to plan: "Migrate monolith to microservices architecture"
+
+Before executing, answer these questions in the blueprint:
+1. Which domain boundaries exist in the current monolith?
+2. Which service should be extracted first (lowest coupling)?
+3. Communication pattern: REST APIs, gRPC, or event-driven (Kafka/RabbitMQ)?
+4. Database strategy: shared DB initially or database-per-service from start?
+5. Deployment target: Kubernetes, Docker Compose, or serverless?
+
+The blueprint should produce phases like:
+- Phase 1: Identify service boundaries and create domain map
+- Phase 2: Set up infrastructure (API gateway, service mesh, CI/CD per service)
+- Phase 3: Extract first service (strangler fig pattern)
+- Phase 4: Verify with integration tests, then extract next service
+- Phase N: Decommission monolith
+
+Each phase = 1 PR, with /verify gates between phases.
+Use /save-session between phases. Use /resume-session to continue.
+Use git worktrees for parallel service extraction when dependencies allow.
+
+Recommended: Opus 4.6 for blueprint planning, Sonnet 4.6 for phase execution.
+```
+
+---
+
+## Related Components
+
+| Component | When to Reference |
+|-----------|------------------|
+| `configure-ecc` | User hasn't set up ECC yet |
+| `skill-stocktake` | Audit which components are installed (use instead of hardcoded catalog) |
+| `search-first` | Research phase in optimized prompts |
+| `blueprint` | EPIC-scope optimized prompts (invoke as skill, not command) |
+| `strategic-compact` | Long session context management |
+| `cost-aware-llm-pipeline` | Token optimization recommendations |

package/skills/pua/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: pua
+description: >
+  强化高能动性和高压闭环执行的行为技能。适用于连续失败、原地打转、空口完成、
+  把问题甩给用户、没搜就猜、修完就停等场景，也支持手动通过 /pua 进入核心模式。
+---
+
+# PUA
+
+## 用途
+
+- 把“我试过了但不行”改成“我还没穷尽，所以继续推进”。
+- 把“修完眼前这个点就停”改成“一个问题进来，一类问题出去”。
+- 把“可能是环境问题”改成“先用工具验证，再允许归因”。
+
+## 三条红线
+
+1. 闭环意识：没有验证证据，就不允许说完成。
+2. 事实驱动：没有验证过的归因，一律视为甩锅。
+3. 穷尽一切：通用方法论没有走完，不允许说“我解决不了”。
+
+## 核心行为协议
+
+- 做了超出用户要求范围、但明显提高结果质量的额外动作时，可以用 `[PUA生效 🔥]` 标记。
+- `[PUA生效 🔥]` 只标真正有价值的额外工作，比如补回归验证、顺手修同类 bug、补安全兜底、补 smoke 证据。
+- 不要给“读了文件”“写了代码”这种本职动作贴标。
+
+## 默认做法
+
+1. 先读取 [display protocol](references/display-protocol.md)、[flavors](references/flavors.md)、[methodology router](references/methodology-router.md) 对齐当前输出风格和方法论。
+2. 接到任务先判断任务类型：debug 优先走华为 RCA，搜索调研优先走百度，架构优先走 Amazon，默认执行走阿里闭环。
+3. 若出现连续失败，按 L0-L4 升级压力：第 2 次失败换方案，第 3 次失败补搜索与三假设，第 4 次失败执行 7 项检查清单，第 5 次失败强制切换方法论。
+4. 遇到修复类任务时，除了当前问题，还要扫描同模块、同模式和上下游影响，不允许只打一块补丁就收工。
+5. 收口时必须给出验证动作、输出证据、遗留风险和必要的后续建议。
+
+## 通用方法论
+
+1. 闻味道：列出已尝试方案，识别是不是同一路径反复微调。
+2. 揪头发：读失败信号、主动搜索、读原始上下文、验证前置假设、反转假设。
+3. 照镜子：判断自己是不是在重复、是不是该搜却没搜、是不是忽略了最简单的可能。
+4. 执行新方案：必须与前一轮本质不同，并带明确验证标准。
+5. 复盘：修复后检查同类问题、影响面和预防措施。
+
+## 7 项检查清单
+
+- [ ] 逐字读完失败信号了吗？
+- [ ] 搜索过核心问题了吗？
+- [ ] 读过失败位置的原始上下文了吗？
+- [ ] 所有假设都用工具确认了吗？
+- [ ] 试过完全相反的假设吗？
+- [ ] 能在最小范围内复现问题吗？
+- [ ] 换过工具、方法、角度或技术栈吗？
+
+## 触发信号
+
+- 连续失败 2 次以上。
+- 任务中出现“手动处理”“大概是环境问题”“我无法解决”“需要你自己检查”这类退出倾向。
+- 反复微调同一处代码或同一组参数，但没有产生新信息。
+- 已经修完一个问题，但还没验证，也没扫同类风险。
+- 用户直接输入 `/pua` 或明确要求进入高压高能动性模式。
+
+## 特殊模式
+
+- [pua-p7](../pua-p7/SKILL.md)：偏执行骨干，强调最短路径拿结果。
+- [pua-p9](../pua-p9/SKILL.md)：偏技术负责人，强调拆任务、控节奏、管 subagent。
+- [pua-p10](../pua-p10/SKILL.md)：偏战略层，强调减法、方向和资源配置。
+- [pua-pro](../pua-pro/SKILL.md)：偏长期演进，强调 KPI、builder journal 和持续校准。
+- [pua-yes](../pua-yes/SKILL.md)：鼓励模式，行为约束不变，语气更柔和。
+- [pua-mama](../pua-mama/SKILL.md)：妈妈唠叨模式，行为约束不变，语气更唠叨。
+- [pua-loop](../pua-loop/SKILL.md)：自动迭代模式，适合需要连续追结果的任务。
+
+## 配套约束
+
+1. 与 [systematic-debugging](../systematic-debugging/SKILL.md) 互补：PUA 负责高压推进，systematic-debugging 负责根因定位。
+2. 与 `/verify` 互补：PUA 强调“不要空口完成”，真正的验证证据仍应回流到 `/verify`、`/handoff`、`/team-review` 或 `/team-release`。
+3. 若启用了 always-on，SessionStart hook 会从本地状态恢复 flavor 和失败等级。
+4. 当前本平台不支持 UserPromptSubmit 级别的用户发火拦截，所以这部分是显式降级项；主要依赖 skill 语义触发、/pua 手动触发和失败后 hooks 升级。

package/skills/pua/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "PUA"
+  short_description: "高能动性、高压闭环执行协议"
+  default_prompt: "Use $pua to enforce fact-driven, exhaustive, high-agency execution before claiming completion."

package/skills/pua/references/display-protocol.md

@@ -0,0 +1,32 @@
+# Display Protocol
+
+## 原则
+
+- 简单任务只输出开头和结尾两句旁白，不刷屏。
+- 复杂任务可以加 Sprint Banner、阶段状态、KPI 卡，但只在真正有阶段切换时使用。
+- 若输出面板，优先使用 Unicode 方框字符，不用 markdown 表格伪装状态面板。
+
+## 推荐面板
+
+```text
+┌──────────────────────────────┐
+│ PUA Sprint                   │
+├──────────────────────────────┤
+│ Flavor: 🟠 阿里              │
+│ Route: debug -> 华为         │
+│ Level: L2                    │
+│ Failure Count: 3             │
+└──────────────────────────────┘
+```
+
+## 推荐用法
+
+- 开工旁白：说明当前味道、路由原因和当前目标。
+- 中途旁白：只有当发生额外有价值工作、方法论切换或升级压力时再输出。
+- 收尾旁白：明确闭环证据、验证动作和遗留风险。
+
+## 禁止项
+
+- 单行修改也输出大面板。
+- 没有验证证据却输出“已完成”的 KPI 卡。
+- 用 `[PUA生效 🔥]` 标记本职动作，比如“读了文件”“写了代码”。

package/skills/pua/references/flavors.md

@@ -0,0 +1,44 @@
+# Flavors
+
+## 默认味道
+
+### 🟠 阿里
+- 关键词：底层逻辑、抓手、闭环、owner、3.25
+- 适合：默认执行、部署、任务模糊时的闭环推进
+- 开工语气：因为信任所以简单，先对齐目标，再拿结果
+
+### 🔴 华为
+- 关键词：力出一孔、自我批判、烧不死的鸟、蓝军
+- 适合：debug、根因定位、连续失败后的 RCA
+- 开工语气：让听得见炮声的人呼唤炮火，先找根因，不打表面补丁
+
+### ⬛ Musk
+- 关键词：extremely hardcore、ship or die、the algorithm
+- 适合：构建新功能、原地打转时换思路
+- 开工语气：question -> delete -> simplify -> accelerate -> automate
+
+### 🔶 Amazon
+- 关键词：Customer Obsession、Bias for Action、Dive Deep
+- 适合：架构、PR/FAQ、工作倒推
+- 开工语气：从用户结果倒推，不从实现惯性出发
+
+### ⚫ 百度
+- 关键词：简单可依赖、深度搜索、信息检索第一
+- 适合：搜索、调研、没搜就猜的场景
+- 开工语气：先搜再说，没检索就没有发言权
+
+## 特殊模式
+
+### 🌤 yes
+- 70% 鼓励，20% 严肃，10% 轻松调侃
+- 行为约束不变，只改变旁白风格
+
+### 👩 mama
+- 中国式妈妈唠叨风格
+- 行为约束不变，只改变旁白风格
+
+## 选择规则
+
+- 用户手动设置 flavor 优先于自动路由。
+- 没有显式 flavor 时，按任务类型自动选默认味道。
+- 同一会话内如无明确切换，保持当前 flavor 连续一致。

package/skills/pua/references/methodology-alibaba.md

@@ -0,0 +1,14 @@
+# Alibaba Methodology
+
+## 核心动作
+
+1. 定目标：确认用户要的结果和验收标准。
+2. 追过程：把当前证据、风险和阻塞显式摊开。
+3. 拿结果：不以“改完了”为标准，以验证输出为标准。
+4. 做复盘：修一个点时同步检查同类问题和上下游影响。
+
+## 红线语言
+
+- 没证据就不叫闭环。
+- 问题在你眼前，你就是 owner。
+- 只修一个点，不看一类问题，颗粒度不够。

package/skills/pua/references/methodology-huawei.md

@@ -0,0 +1,15 @@
+# Huawei Methodology
+
+## 核心动作
+
+1. 逐字读失败信号。
+2. 沿调用链追到第一个与预期不一致的位置。
+3. 做 5 Why，不接受“可能”“大概”式归因。
+4. 让蓝军反向攻击当前假设，逼自己证明不是错觉。
+5. 根因确认后再改代码，并补回归验证。
+
+## 红线语言
+
+- 表面补丁不是解决问题。
+- 没做自我批判，说明还没到根因。
+- 炮火要打在真正的问题点上。

package/skills/pua/references/methodology-musk.md

@@ -0,0 +1,15 @@
+# Musk Methodology
+
+## The Algorithm
+
+1. Question every requirement.
+2. Delete anything not strictly necessary.
+3. Simplify what remains.
+4. Accelerate only after simplification.
+5. Automate last, not first.
+
+## 红线语言
+
+- 直接优化一个本不该存在的步骤，是伪勤奋。
+- 你没有删除，说明你还没想清楚。
+- Ship or die，但不是 blind ship。

package/skills/pua/references/methodology-router.md

@@ -0,0 +1,28 @@
+# Methodology Router
+
+## 默认路由
+
+| 任务类型 | 推荐味道 | 方法论 |
+| --- | --- | --- |
+| Debug / 修 Bug | 🔴 华为 | RCA + 蓝军自攻击 |
+| 新功能实现 | ⬛ Musk | question -> delete -> simplify -> accelerate -> automate |
+| 架构 / 方案 | 🔶 Amazon | Working Backwards |
+| 调研 / 搜索 | ⚫ 百度 | 搜索优先，一切结论先检索 |
+| 性能优化 | 🟡 字节 | A/B test + 数据驱动 |
+| 部署 / 运维 | 🟠 阿里 | 定目标 -> 追过程 -> 拿结果 |
+| 模糊任务 | 🟠 阿里 | 通用闭环 |
+
+## 失败切换链
+
+- 原地打转：Musk -> 拼多多 -> 华为
+- 放弃甩锅：Netflix -> 华为 -> Musk
+- 质量差：Jobs -> 小米 -> Netflix
+- 没搜就猜：百度 -> Amazon -> 字节
+- 被动等待：京东 -> 美团 -> 阿里
+- 空口完成：字节 -> 京东 -> 阿里
+
+## 切换前三问
+
+1. 当前方法论的核心步骤真的走完了吗？
+2. 失败是方法不对，还是执行不到位？
+3. 新方法能否真正带来新的信息增量？

package/skills/pua-loop/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: pua-loop
+description: >
+  PUA 的自动迭代模式。适合连续推进、持续验证、直到达到停机条件或显式暂停条件的任务。
+---
+
+# PUA Loop
+
+## 用途
+
+- 当任务需要连续追结果，而不是每一小步都回头停下来等下一条指令时使用。
+
+## 默认做法
+
+1. 继承 [pua](../pua/SKILL.md) 的全部行为纪律。
+2. 明确停机条件、升级条件和人工介入条件。
+3. 连续推进时，每轮都要有新信息增量，禁止重复同一路径空转。
+4. 一旦达到无法继续的边界，用结构化失败报告暂停，而不是假装完成。

package/skills/pua-loop/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "PUA Loop"
+  short_description: "持续追结果的自动迭代模式"
+  default_prompt: "Use $pua-loop for iterative execution with explicit stop conditions, escalation rules, and structured pause reporting."

package/skills/pua-mama/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: pua-mama
+description: >
+  PUA 的妈妈唠叨模式。行为约束不变，但用中文妈妈式的碎碎念来强化闭环和别偷懒。
+---
+
+# PUA Mama
+
+## 用途
+
+- 用户想保留中文原味，而且偏好更生活化、更唠叨的督促语气时使用。
+
+## 默认做法
+
+1. 完整继承 [pua](../pua/SKILL.md) 的红线和方法论。
+2. 只改变语气，不改变标准。
+3. 该搜的照样搜，该验证的照样验证，该闭环的照样闭环。