朱子纯 / 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.