朱子纯 / erp-workflow-plugin

Commit cce987372566e391b1e1122bc6c40c409d327c64

Authored by zichun
1 parent 1357af3b

push

Inline Side-by-side
Showing 2 changed files with 0 additions and 236 deletions
skills/internal/superpower-brainstorming/SKILL.md deleted
View file @1357af3
1 ----  
2 -name: superpower-brainstorming  
3 -description: Internal fork of superpowers:brainstorming with approval gates stripped. Use when a parent skill needs structured Q&A + design + spec doc, without user "approve design / review spec" wait points.  
4 -user-invocable: false  
5 ----  
6 -  
7 -# Brainstorming Ideas Into Designs (Internal, Gate-Free)  
8 -  
9 -Help turn ideas into fully formed designs and specs through natural collaborative dialogue. This is an **internal fork** of `superpowers:brainstorming`: `<HARD-GATE>`, "approve design", "review spec", and Visual Companion have been removed so the flow can run without user-facing confirmation breaks. QA (AskUserQuestion) is still used freely for genuine ambiguity.  
10 -  
11 -**Caller contract:** the parent skill passes in (or this skill derives) a spec output path. Once the spec file is written and self-reviewed, control returns to the caller. This skill does NOT chain to any next skill itself.  
12 -  
13 -**No human-fill markers in output.** The spec you write is CC's internal reasoning artifact, not a user-review doc. Do NOT emit `【人工填写：...】` style placeholders — that convention belongs to A-phase docs (`docs/01~10`, `CLAUDE.md`, `.env.local`), not B-phase specs/plans. When a concrete value is needed:  
14 -  
15 -1. **Look up first** — check `.env.local`, `docs/07-环境配置.md`, `CLAUDE.md`, existing code. If the value is already resolved somewhere, cite that source in the spec (e.g., "JWT_SECRET 从 `.env.local` 读取，`application.yml` 用 `${JWT_SECRET}` 注入")  
16 -2. **Ask via `AskUserQuestion` second** — if no source exists, ask the user directly; record their answer in the spec  
17 -3. **Never leave a 【人工填写：】 placeholder** — if step 1 + 2 somehow can't resolve it, the spec must name the exact blocker (not a generic human-fill marker), and Q&A keeps going until it's resolved  
18 -  
19 -## Checklist  
20 -  
21 -Complete in order:  
22 -  
23 -1. **Explore project context** — check files, docs, recent commits relevant to the topic  
24 -2. **Ask clarifying questions** — one at a time, only for genuine ambiguity; understand purpose / constraints / success criteria  
25 -3. **Pick an approach** — if multiple viable approaches exist, briefly weigh trade-offs and pick the best; surface the choice only if the user's answer to a prior Q&A did not already decide it  
26 -4. **Write design doc** — save to the path provided by the caller (default `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` if none)  
27 -5. **Spec self-review** — inline check for placeholders, contradictions, ambiguity, scope; fix inline  
28 -6. **Return control to caller** — no further chaining  
29 -  
30 -## Process Flow  
31 -  
32 -```dot  
33 -digraph brainstorming {  
34 - "Explore project context" [shape=box];  
35 - "Ask clarifying questions\n(one at a time)" [shape=box];  
36 - "Pick approach\n(weigh trade-offs only if needed)" [shape=box];  
37 - "Write design doc" [shape=box];  
38 - "Spec self-review\n(fix inline)" [shape=box];  
39 - "Return to caller" [shape=doublecircle];  
40 -  
41 - "Explore project context" -> "Ask clarifying questions\n(one at a time)";  
42 - "Ask clarifying questions\n(one at a time)" -> "Pick approach\n(weigh trade-offs only if needed)";  
43 - "Pick approach\n(weigh trade-offs only if needed)" -> "Write design doc";  
44 - "Write design doc" -> "Spec self-review\n(fix inline)";  
45 - "Spec self-review\n(fix inline)" -> "Return to caller";  
46 -}  
47 -```  
48 -  
49 -## The Process  
50 -  
51 -**Understanding the idea:**  
52 -  
53 -- Check current project state first (files, docs, recent commits)  
54 -- Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), surface this immediately. Don't spend questions refining details of a project that needs to be decomposed first.  
55 -- If the project is too large for a single spec, help decompose: what are the independent pieces, how do they relate, what order to build? Then brainstorm the first sub-project through the normal design flow.  
56 -- For appropriately-scoped projects, ask questions one at a time  
57 -- Prefer multiple choice questions when possible, but open-ended is fine too  
58 -- Only one question per message  
59 -- Focus on understanding: purpose, constraints, success criteria  
60 -  
61 -**Approach selection:**  
62 -  
63 -- If there is a single obvious approach driven by the Q&A answers, just use it  
64 -- If trade-offs remain, briefly state 2-3 approaches + your recommendation inline in the spec (not as a confirmation gate)  
65 -  
66 -**Design for isolation and clarity:**  
67 -  
68 -- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently  
69 -- For each unit you should be able to answer: what does it do, how do you use it, what does it depend on  
70 -- Smaller, well-bounded units are easier to reason about and test; large files are a signal of doing too much  
71 -  
72 -**Working in existing codebases:**  
73 -  
74 -- Explore the current structure before proposing changes. Follow existing patterns.  
75 -- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design — the way a good developer improves code they're working in.  
76 -- Don't propose unrelated refactoring. Stay focused on what serves the current goal.  
77 -  
78 -## After Q&A  
79 -  
80 -**Write the design doc:**  
81 -  
82 -- Write the validated design (spec) to the caller-provided path (default `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`)  
83 -- Cover: goal, inputs/outputs, rules, constraints, schema/API refs, acceptance criteria — or match the template the caller expects  
84 -  
85 -**Spec self-review (no user wait):**  
86 -  
87 -1. **Placeholder scan:** any "TBD", "TODO", "【人工填写：...】", incomplete sections, vague requirements? Fix them — either resolve via file lookup, raise a `AskUserQuestion`, or rewrite the passage to be concrete.  
88 -2. **Internal consistency:** do any sections contradict? Does architecture match feature descriptions?  
89 -3. **Scope check:** focused enough for a single implementation plan, or needs decomposition?  
90 -4. **Ambiguity check:** could any requirement be interpreted two ways? Pick one, make it explicit.  
91 -  
92 -Fix inline. No re-review — just fix and move on.  
93 -  
94 -**Terminal state:**  
95 -  
96 -Return control to the caller. Do not invoke writing-plans, frontend-design, or any other skill from here.  
97 -  
98 -## Key Principles  
99 -  
100 -- **One question at a time** — don't overwhelm  
101 -- **Multiple choice preferred** — easier to answer  
102 -- **QA for ambiguity only** — don't fabricate confirmation questions  
103 -- **YAGNI ruthlessly** — remove unnecessary features from designs  
104 -- **Incremental understanding** — clarify when something doesn't make sense  
105 -- **No approval gates** — writing the spec is the commit; any disagreement surfaces as a concrete Q&A item  
skills/internal/superpower-writing-plans/SKILL.md deleted
View file @1357af3
1 ----  
2 -name: superpower-writing-plans  
3 -description: Internal fork of superpowers:writing-plans with the "Which execution approach?" handoff gate stripped. Use when a parent skill needs a bite-sized, TDD-ready implementation plan written to disk without user-facing confirmation breaks.  
4 -user-invocable: false  
5 ----  
6 -  
7 -# Writing Plans (Internal, Gate-Free)  
8 -  
9 -Write task-level implementation plans that tell the TDD executor **what to do**, not **how to write the code**. The executor is `feature-tdd` (Claude itself with full context), not a mechanical copy-paster — so the plan captures file boundaries, test intent, API shapes and completion criteria, and lets the executor produce the actual code in the red-green cycle. DRY. YAGNI. TDD. Frequent commits.  
10 -  
11 -**Do NOT dump full file contents (pom.xml, entity classes, config files) into the plan.** The plan and the code end up as two sources of truth that drift; 2000+ line plans also waste context. Code is produced during TDD, not pre-written here.  
12 -  
13 -**Caller contract:** the parent skill passes in (or this skill derives) a plan output path and a spec file path. Once the plan is written and self-reviewed, control returns to the caller. This skill does NOT ask the user to choose an execution mode; the caller decides.  
14 -  
15 -**Save plans to:** the caller-provided path (default `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`).  
16 -  
17 -## Scope Check  
18 -  
19 -If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, surface this to the caller — suggest breaking into separate plans, one per subsystem. Each plan should produce working, testable software on its own.  
20 -  
21 -## File Structure  
22 -  
23 -Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.  
24 -  
25 -- Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.  
26 -- Files that change together should live together. Split by responsibility, not by technical layer.  
27 -- In existing codebases, follow established patterns. Don't unilaterally restructure — but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.  
28 -  
29 -This structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.  
30 -  
31 -## Bite-Sized Task Granularity  
32 -  
33 -**Each step is one action (2-5 minutes):**  
34 -- "Write the failing test" — step  
35 -- "Run it to make sure it fails" — step  
36 -- "Implement the minimal code to make the test pass" — step  
37 -- "Run the tests and make sure they pass" — step  
38 -- "Commit" — step  
39 -  
40 -## Plan Document Header  
41 -  
42 -**Every plan MUST start with this header:**  
43 -  
44 -```markdown  
45 -# [Feature Name] Implementation Plan  
46 -  
47 -> **Execution:** Parent skill `feature-tdd` executes this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.  
48 -  
49 -**Goal:** [One sentence describing what this builds]  
50 -  
51 -**Architecture:** [2-3 sentences about approach]  
52 -  
53 -**Tech Stack:** [Key technologies/libraries]  
54 -  
55 ----  
56 -```  
57 -  
58 -## Task Structure  
59 -  
60 -Each task is a unit of red-green-commit. Capture intent and boundaries — leave code to TDD.  
61 -  
62 -````markdown  
63 -### Task N: [Component Name]  
64 -  
65 -**Files:**  
66 -- Create: `exact/path/to/File.java`  
67 -- Modify: `exact/path/to/Existing.java:123-145`  
68 -- Test: `tests/exact/path/to/FileTest.java`  
69 -  
70 -**API shape (只写需要约束实现的签名；内部实现留给 TDD):**  
71 -- `LoginService#login(LoginRequest req) : LoginResponse`  
72 -- `throws AccountLockedException when iLoginFailCount ≥ 5 within tLockUntil window`  
73 -  
74 -- [ ] **Step 1: 写失败测试**  
75 - - 测试名: `LoginServiceTest#loginWithBadPassword_incrementsFailCount_returns40101`  
76 - - 意图: 错误密码 → `iLoginFailCount += 1`；第 5 次 → 设置 `tLockUntil = now + 15min`；返回码 40101  
77 - - 子会话确认 FAIL（函数/类不存在）  
78 -  
79 -- [ ] **Step 2: 实现最小代码**  
80 - - 目标: 让 Step 1 测试通过；不多做  
81 - - 涉及文件: `LoginService.java`, `SftLoginInfoMapper.java`  
82 -  
83 -- [ ] **Step 3: 子会话验证 PASS**  
84 -  
85 -- [ ] **Step 4: Commit**  
86 - - `git add <文件>`  
87 - - `git commit -m "feat(sys): 登录失败计数 + 锁定 REQ-SYS-001"`  
88 -````  
89 -  
90 -**允许的代码块场景**（少数例外，需要写死而非让 TDD 自由发挥的内容）：  
91 -  
92 -- **DDL / migration 文件**：`V_n__*.sql` 的 ALTER/CREATE 语句——因为 schema 是事实源、不是 TDD 的"红绿"产物  
93 -- **合同级常量**：API 错误码表、JWT claim 名、Redis key 模式——这些跨模块被消费，必须在 plan 锁定  
94 -- **测试的断言形状**（可选）：如果一句话说不清"测什么"，给个 3-5 行断言 sketch 是 OK 的  
95 -  
96 -除此之外一律用散文+签名描述，**不贴完整文件**。  
97 -  
98 -## No Placeholders  
99 -  
100 -Every step must contain the actual content an engineer needs. These are **plan failures** — never write them:  
101 -- "TBD", "TODO", "implement later", "fill in details"  
102 -- **`【人工填写：...】`** — this marker is A-phase only (`docs/01~10`, `CLAUDE.md`, `.env.local`). It must NEVER appear in B-phase plans. If you need a concrete value: (a) look it up in `.env.local` / `docs/07` / `CLAUDE.md` / existing code and cite the source in the plan, or (b) ask the user via `AskUserQuestion` and record the answer. The plan is CC's executable artifact, not a user-review doc.  
103 -- "Add appropriate error handling" / "add validation" / "handle edge cases"（具体到哪些错误码 / 哪些字段）  
104 -- "Similar to Task N"（相似任务各自写清楚测试意图 + 完成判据，不互相链接）  
105 -- References to types, functions, or methods not defined in any task（类/方法首次出现的 task 要给出 API 签名）  
106 -  
107 -> 散文级"做什么"是 OK 的——执行器（feature-tdd）会在 TDD 循环里决定"怎么写"。plan 的义务是**约束范围**，不是**替 TDD 写代码**。  
108 -  
109 -## Remember  
110 -  
111 -- Exact file paths always  
112 -- Exact commands with expected output (for test runs and git ops)  
113 -- API signatures / class names / error codes / contract values — 必须写死  
114 -- Internal implementation code — 不写；留给 TDD 阶段  
115 -- DRY, YAGNI, TDD, frequent commits  
116 -  
117 -## Self-Review  
118 -  
119 -After writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself — not a subagent dispatch, not a user approval gate.  
120 -  
121 -**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.  
122 -  
123 -**2. Placeholder scan:** Search your plan for red flags — any of the patterns from the "No Placeholders" section above (including `【人工填写：...】`). Fix them: resolve by file lookup, raise a `AskUserQuestion`, or rewrite the step to be concrete.  
124 -  
125 -**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.  
126 -  
127 -If you find issues, fix them inline. No re-review — just fix and move on. If you find a spec requirement with no task, add the task.  
128 -  
129 -## Terminal State  
130 -  
131 -Once the plan file is written and self-reviewed, return control to the caller. Do NOT ask the user to pick an execution approach; the caller decides how to execute.