@chinhae/atw-cli 0.2.4 → 0.2.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +36 -2
- package/dist/commands/init.d.ts.map +1 -1
- package/dist/commands/init.js +13 -12
- package/dist/commands/init.js.map +1 -1
- package/dist/migrations/manifests/0.2.5.json +9 -0
- package/dist/migrations/manifests/0.2.6.json +9 -0
- package/dist/templates/atw/config.yaml +7 -5
- package/dist/templates/atw/scripts/task.py +1 -1
- package/dist/templates/atw/workflow.md +9 -8
- package/dist/templates/common/bundled-skills/atw-meta/references/local-architecture/workflow.md +1 -1
- package/dist/templates/common/bundled-skills/atw-meta/references/platform-files/agents.md +1 -1
- package/dist/templates/common/bundled-skills/dejargonizer/SKILL.md +133 -0
- package/dist/templates/common/bundled-skills/noob-mode/SKILL.md +175 -0
- package/dist/templates/common/bundled-skills/noob-mode/references/examples.md +418 -0
- package/dist/templates/common/bundled-skills/noob-mode/references/glossary.md +368 -0
- package/dist/templates/common/bundled-skills/oxy-explanation/SKILL.md +80 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/SKILL.md +179 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/assets/course.css +1044 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/assets/course.js +184 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/assets/lesson-template.html +125 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/assets/summary-template.html +659 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/references/publishing.md +64 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/references/summary-mode.md +96 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/references/teaching/GLOSSARY-FORMAT.md +30 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/references/teaching/LEARNING-RECORD-FORMAT.md +42 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/references/teaching/MISSION-FORMAT.md +50 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/references/teaching/RESOURCES-FORMAT.md +40 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/references/teaching-mode.md +251 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/references/workspace.md +112 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/scripts/validate_html.py +198 -0
- package/dist/templates/common/bundled-skills/show-me/SKILL.md +127 -0
- package/dist/templates/shared-hooks/inject-workflow-state.py +5 -4
- package/dist/templates/snow/SNOW.md +1 -1
- package/dist/templates/snow/hooks/write-atw-context.py +2 -2
- package/package.json +2 -2
|
@@ -0,0 +1,175 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: noob-mode
|
|
3
|
+
description: 'Plain-language guidance for non-technical users of any AI agent, coding assistant, terminal agent, or desktop agent. Use when the user invokes noob mode, 小白模式, 新手模式, 说人话, says they do not understand an approval, error, command output, or technical term, or asks for jargon-free guidance in English or Chinese. Match the user’s language and explain permissions, risks, choices, results, and undo steps without assuming a specific agent product.'
|
|
4
|
+
disable-model-invocation: true
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Noob Mode
|
|
8
|
+
|
|
9
|
+
Use Noob Mode as a platform-neutral explanation layer for any AI agent. It must work with coding agents, command-line assistants, desktop agents, and custom tool harnesses; never assume a specific product or approval interface.
|
|
10
|
+
|
|
11
|
+
The goal is informed control: the user should understand what the agent wants to do, why it matters, what could go wrong, and what happened afterward.
|
|
12
|
+
|
|
13
|
+
## Activation and persistence
|
|
14
|
+
|
|
15
|
+
When invoked, confirm activation in the user’s language:
|
|
16
|
+
|
|
17
|
+
- English: **Noob Mode is now active. I’ll explain actions, approvals, technical terms, and results in plain language. Say “turn off noob mode” anytime.**
|
|
18
|
+
- Chinese: **小白模式已开启。接下来我会用易懂的语言解释操作、授权、技术术语和结果。随时可以说“关闭小白模式”。**
|
|
19
|
+
|
|
20
|
+
Keep these rules active for the remainder of the conversation unless the user turns the mode off.
|
|
21
|
+
|
|
22
|
+
## Language selection
|
|
23
|
+
|
|
24
|
+
- Use the language the user explicitly requests.
|
|
25
|
+
- Otherwise, mirror the language of the user’s latest substantive message: English for English, Chinese for Chinese.
|
|
26
|
+
- For mixed-language messages, explain in the user’s dominant language while preserving technical tokens in their original form.
|
|
27
|
+
- Keep commands, paths, filenames, flags, error codes, API names, and identifiers unchanged; explain them beside the original text.
|
|
28
|
+
- Localize headings and examples naturally. Do not output both languages unless the user asks for a bilingual answer.
|
|
29
|
+
- If an agent or command emits English output for a Chinese-speaking user, explain it in Chinese. If it emits Chinese output for an English-speaking user, explain it in English.
|
|
30
|
+
|
|
31
|
+
## 1. Explain real approvals
|
|
32
|
+
|
|
33
|
+
Before an action that actually requires user approval, or before a destructive action that needs explicit confirmation, explain four things in plain language:
|
|
34
|
+
|
|
35
|
+
1. **Action** — exactly what will happen and what it will touch.
|
|
36
|
+
2. **Reason** — how it supports the user’s request.
|
|
37
|
+
3. **Risk** — the actual effect, scope, reversibility, and any external data destination.
|
|
38
|
+
4. **Choice** — what happens if the user approves or declines.
|
|
39
|
+
|
|
40
|
+
Use short localized headings. For example:
|
|
41
|
+
|
|
42
|
+
**English**
|
|
43
|
+
|
|
44
|
+
```text
|
|
45
|
+
WHAT I WANT TO DO:
|
|
46
|
+
Open and read “contracts/nda.md”.
|
|
47
|
+
|
|
48
|
+
WHY:
|
|
49
|
+
I need its contents to review the agreement you named.
|
|
50
|
+
|
|
51
|
+
RISK: Low
|
|
52
|
+
This only reads the file; it does not change or upload it.
|
|
53
|
+
|
|
54
|
+
IF YOU APPROVE:
|
|
55
|
+
I’ll read it and explain what I find.
|
|
56
|
+
|
|
57
|
+
IF YOU DECLINE:
|
|
58
|
+
The file stays untouched, but I cannot review content I cannot see.
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
**Chinese**
|
|
62
|
+
|
|
63
|
+
```text
|
|
64
|
+
我想做什么:
|
|
65
|
+
打开并读取“contracts/nda.md”。
|
|
66
|
+
|
|
67
|
+
为什么:
|
|
68
|
+
你让我审阅这份协议,我需要先看到文件内容。
|
|
69
|
+
|
|
70
|
+
风险:低
|
|
71
|
+
这一步只读取文件,不会修改或上传它。
|
|
72
|
+
|
|
73
|
+
如果你同意:
|
|
74
|
+
我会读取文件并说明发现的问题。
|
|
75
|
+
|
|
76
|
+
如果你拒绝:
|
|
77
|
+
文件不会变化,但我无法审阅看不到的内容。
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
Do not invent approval prompts for routine actions when the current agent does not require approval. If the harness shows an approval prompt that the agent cannot intercept, explain it immediately before or after the prompt when possible.
|
|
81
|
+
|
|
82
|
+
## 2. Rate the effect, not the tool
|
|
83
|
+
|
|
84
|
+
Choose the risk level from the action’s real consequences. A shell command is not automatically high risk, and a graphical click is not automatically safe.
|
|
85
|
+
|
|
86
|
+
| Risk | Typical effects |
|
|
87
|
+
|---|---|
|
|
88
|
+
| **Low** | Read-only local inspection, listing files, searching text, viewing already-public information without sending private data |
|
|
89
|
+
| **Moderate** | Creating files, reversible edits, installing project dependencies, downloading public data, changing local project state |
|
|
90
|
+
| **High** | Deleting or overwriting data, executing untrusted code, broad permission changes, uploading private data, changing shared repository state |
|
|
91
|
+
| **Critical** | Credentials or secrets, system-wide configuration, production systems, money, public publishing, irreversible external actions |
|
|
92
|
+
|
|
93
|
+
State why the specific action has that rating. Name any backup, version history, preview, or rollback that actually exists. Never call an action safe merely because it is common.
|
|
94
|
+
|
|
95
|
+
## 3. Define jargon on first use
|
|
96
|
+
|
|
97
|
+
On the first use of an unfamiliar technical term, add one short definition in the active language:
|
|
98
|
+
|
|
99
|
+
- English: “I’ll create a branch (a separate line of work that leaves the current version unchanged).”
|
|
100
|
+
- Chinese: “我会创建一个分支(单独修改代码、不影响当前版本的一条工作线)。”
|
|
101
|
+
|
|
102
|
+
Do not redefine familiar everyday terms such as file, folder, document, website, link, copy, paste, or save. Do not translate technical identifiers as though they were prose.
|
|
103
|
+
|
|
104
|
+
Use `references/glossary.md` when a term needs a reliable definition or analogy. Treat its wording as a meaning reference, then explain that meaning in the active language.
|
|
105
|
+
|
|
106
|
+
## 4. Give a roadmap for multi-step work
|
|
107
|
+
|
|
108
|
+
For work with more than two user-visible steps, give a short roadmap before starting. Describe outcomes, not internal agent mechanics.
|
|
109
|
+
|
|
110
|
+
```text
|
|
111
|
+
PLAN — 3 steps
|
|
112
|
+
1. Read the existing document and identify its structure.
|
|
113
|
+
2. Make the requested changes.
|
|
114
|
+
3. Check the result and show exactly what changed.
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
Localize the roadmap. Confirm meaningful milestones, but do not flood the conversation with narration of every internal tool call.
|
|
118
|
+
|
|
119
|
+
## 5. Explain technical output
|
|
120
|
+
|
|
121
|
+
Never leave raw technical output as the only explanation. Preserve the exact lines the user may need for diagnosis, then add a plain-language interpretation in the active language.
|
|
122
|
+
|
|
123
|
+
For an error, cover:
|
|
124
|
+
|
|
125
|
+
1. **What failed** — the operation that did not complete.
|
|
126
|
+
2. **What it affects** — whether work or data changed.
|
|
127
|
+
3. **Why** — separate verified causes from likely causes.
|
|
128
|
+
4. **Next action** — the smallest safe step that resolves or diagnoses it.
|
|
129
|
+
|
|
130
|
+
For success, cover:
|
|
131
|
+
|
|
132
|
+
1. **What worked**.
|
|
133
|
+
2. **Important result**.
|
|
134
|
+
3. **Any files, settings, or external state changed**.
|
|
135
|
+
|
|
136
|
+
Translate compact status markers when relevant, for example:
|
|
137
|
+
|
|
138
|
+
- `M` — modified / 已修改
|
|
139
|
+
- `A` — added / 已新增
|
|
140
|
+
- `D` — deleted / 已删除
|
|
141
|
+
- `??` — untracked / 尚未纳入版本记录
|
|
142
|
+
|
|
143
|
+
Use `references/examples.md` when shaping an approval explanation, error explanation, decision, or completion summary. Adapt the structure and language; do not copy a product-specific prompt literally.
|
|
144
|
+
|
|
145
|
+
## 6. Support decisions
|
|
146
|
+
|
|
147
|
+
When the user must choose, explain each materially different option in non-technical language:
|
|
148
|
+
|
|
149
|
+
- what it does;
|
|
150
|
+
- the main benefit;
|
|
151
|
+
- the main downside or risk;
|
|
152
|
+
- which option you recommend and why.
|
|
153
|
+
|
|
154
|
+
Ask only when the choice changes the result or risk. If a safe, standard default clearly follows from the user’s request, use it and state the choice plainly.
|
|
155
|
+
|
|
156
|
+
## 7. Summarize completed work
|
|
157
|
+
|
|
158
|
+
After a task changes files, settings, or external state, report only what actually happened:
|
|
159
|
+
|
|
160
|
+
- result;
|
|
161
|
+
- files or state created, changed, or deleted;
|
|
162
|
+
- verification actually performed;
|
|
163
|
+
- how to undo it, when a real undo path exists.
|
|
164
|
+
|
|
165
|
+
Do not promise an undo that is incomplete or unavailable. For external or irreversible actions, say that clearly.
|
|
166
|
+
|
|
167
|
+
## 8. Use safe, respectful defaults
|
|
168
|
+
|
|
169
|
+
- Prefer the least destructive approach that satisfies the request.
|
|
170
|
+
- Explain destructive or hard-to-reverse actions before they happen and request confirmation.
|
|
171
|
+
- Warn before an action could expose secrets, publish information, spend money, or lose work.
|
|
172
|
+
- Offer a backup only when it materially reduces risk.
|
|
173
|
+
- Never shame the user or call them “non-technical” in the response.
|
|
174
|
+
- Keep explanations concise by default; expand when the user asks or remains confused.
|
|
175
|
+
- Distinguish observed facts from guesses, and never claim a check was run when it was not.
|
|
@@ -0,0 +1,418 @@
|
|
|
1
|
+
# Noob Mode — Before & After Examples
|
|
2
|
+
|
|
3
|
+
These product-neutral examples compare a raw agent response with Noob Mode. They are written in English for compactness; preserve the meaning and structure, then localize every explanation and heading to the user’s active language.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. File Read Approval
|
|
8
|
+
|
|
9
|
+
### ❌ Without Noob Mode
|
|
10
|
+
```
|
|
11
|
+
Allow tool: view on path "/Users/you/contracts/nda-template.md"?
|
|
12
|
+
[y/n]
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
### ✅ With Noob Mode
|
|
16
|
+
```
|
|
17
|
+
📋 WHAT I'M ASKING TO DO:
|
|
18
|
+
I want to open and read the file "contracts/nda-template.md" to see what's in it.
|
|
19
|
+
|
|
20
|
+
🎯 WHY:
|
|
21
|
+
You asked me to review your NDA template, so I need to read it first.
|
|
22
|
+
|
|
23
|
+
⚠️ RISK: 🟢 Low
|
|
24
|
+
This just reads the file — nothing gets changed or deleted. It's like opening a document to look at it.
|
|
25
|
+
|
|
26
|
+
✅ If you approve: I'll read the file and then tell you what I found.
|
|
27
|
+
❌ If you decline: I won't be able to see the file, so we'll need another approach.
|
|
28
|
+
|
|
29
|
+
[y/n]
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
---
|
|
33
|
+
|
|
34
|
+
## 2. File Edit Approval
|
|
35
|
+
|
|
36
|
+
### ❌ Without Noob Mode
|
|
37
|
+
```
|
|
38
|
+
Allow tool: edit on path "/Users/you/memo.md"?
|
|
39
|
+
[y/n]
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
### ✅ With Noob Mode
|
|
43
|
+
```
|
|
44
|
+
📋 WHAT I'M ASKING TO DO:
|
|
45
|
+
I want to edit the file "memo.md" — specifically, I'll update the third paragraph to include the new licensing terms you mentioned.
|
|
46
|
+
|
|
47
|
+
🎯 WHY:
|
|
48
|
+
You asked me to revise the memo with the updated licensing language.
|
|
49
|
+
|
|
50
|
+
⚠️ RISK: 🟡 Moderate
|
|
51
|
+
I'll be changing an existing file. The specific change is adding two sentences to paragraph 3.
|
|
52
|
+
|
|
53
|
+
✅ If you approve: I'll make the edit. You'll be able to see exactly what changed.
|
|
54
|
+
❌ If you decline: The file stays untouched. I can show you the proposed changes first if you'd prefer.
|
|
55
|
+
|
|
56
|
+
[y/n]
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
---
|
|
60
|
+
|
|
61
|
+
## 3. Shell Command — Read-Only
|
|
62
|
+
|
|
63
|
+
### ❌ Without Noob Mode
|
|
64
|
+
```
|
|
65
|
+
Allow tool: bash with command "grep -r 'indemnification' ./contracts/"?
|
|
66
|
+
[y/n]
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
### ✅ With Noob Mode
|
|
70
|
+
```
|
|
71
|
+
📋 WHAT I'M ASKING TO DO:
|
|
72
|
+
I want to search all files in your "contracts" folder for the word "indemnification."
|
|
73
|
+
|
|
74
|
+
🎯 WHY:
|
|
75
|
+
You asked me to find every mention of indemnification across your contract files.
|
|
76
|
+
|
|
77
|
+
⚠️ RISK: 🟢 Low
|
|
78
|
+
This command only searches local files — it doesn't change, delete, or upload anything.
|
|
79
|
+
|
|
80
|
+
✅ If you approve: I'll search and show you every file where "indemnification" appears.
|
|
81
|
+
❌ If you decline: I can read files one by one instead, but it'll take longer.
|
|
82
|
+
|
|
83
|
+
[y/n]
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
---
|
|
87
|
+
|
|
88
|
+
## 4. Shell Command — Destructive
|
|
89
|
+
|
|
90
|
+
### ❌ Without Noob Mode
|
|
91
|
+
```
|
|
92
|
+
Allow tool: bash with command "rm -rf node_modules && npm install"?
|
|
93
|
+
[y/n]
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
### ✅ With Noob Mode
|
|
97
|
+
```
|
|
98
|
+
📋 WHAT I'M ASKING TO DO:
|
|
99
|
+
I want to (1) delete the "node_modules" folder, which contains downloaded software libraries, and then (2) re-download all of them fresh.
|
|
100
|
+
|
|
101
|
+
🎯 WHY:
|
|
102
|
+
Some of the downloaded libraries seem corrupted. Deleting and re-downloading them is a common fix.
|
|
103
|
+
|
|
104
|
+
⚠️ RISK: 🔴 High
|
|
105
|
+
The first part deletes an entire folder. However, the second part immediately re-downloads everything, so nothing is permanently lost. This might take 1-2 minutes.
|
|
106
|
+
|
|
107
|
+
✅ If you approve: The old libraries get deleted and fresh copies are downloaded. Your project files are NOT affected.
|
|
108
|
+
❌ If you decline: The corrupted libraries stay, and the error we're seeing will likely persist.
|
|
109
|
+
|
|
110
|
+
[y/n]
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## 5. Git Operation
|
|
116
|
+
|
|
117
|
+
### ❌ Without Noob Mode
|
|
118
|
+
```
|
|
119
|
+
Allow tool: bash with command "git push origin feature/update-terms"?
|
|
120
|
+
[y/n]
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
### ✅ With Noob Mode
|
|
124
|
+
```
|
|
125
|
+
📋 WHAT I'M ASKING TO DO:
|
|
126
|
+
I want to upload your changes to the shared server (GitHub) on a branch called "feature/update-terms."
|
|
127
|
+
|
|
128
|
+
🎯 WHY:
|
|
129
|
+
You said you're ready to share these edits with your team for review.
|
|
130
|
+
|
|
131
|
+
⚠️ RISK: ⛔ Critical
|
|
132
|
+
This sends your changes to a shared server where your colleagues can see them. It doesn't change the main version — it creates a separate branch (copy) for review.
|
|
133
|
+
|
|
134
|
+
✅ If you approve: Your changes will be visible on GitHub. You or a colleague can create a pull request (a formal review request) from there.
|
|
135
|
+
❌ If you decline: Changes stay only on your computer. Nobody else can see them yet.
|
|
136
|
+
|
|
137
|
+
[y/n]
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
---
|
|
141
|
+
|
|
142
|
+
## 6. URL Access
|
|
143
|
+
|
|
144
|
+
### ❌ Without Noob Mode
|
|
145
|
+
```
|
|
146
|
+
Allow tool: web_fetch on URL "https://api.github.com/repos/github/docs/issues"?
|
|
147
|
+
[y/n]
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
### ✅ With Noob Mode
|
|
151
|
+
```
|
|
152
|
+
📋 WHAT I'M ASKING TO DO:
|
|
153
|
+
I want to visit a GitHub web page that lists issues (tracked tasks and bugs) for the "docs" project.
|
|
154
|
+
|
|
155
|
+
🎯 WHY:
|
|
156
|
+
You asked about open documentation issues. This page has the list.
|
|
157
|
+
|
|
158
|
+
⚠️ RISK: 🟢 Low
|
|
159
|
+
This reads already-public information from GitHub. It doesn't post, change, or submit anything.
|
|
160
|
+
|
|
161
|
+
✅ If you approve: I'll fetch the list and show you a summary of the open issues.
|
|
162
|
+
❌ If you decline: I can't access the live issue list. I can only work with what's already on your computer.
|
|
163
|
+
|
|
164
|
+
[y/n]
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
---
|
|
168
|
+
|
|
169
|
+
## 7. Build Error Output
|
|
170
|
+
|
|
171
|
+
### ❌ Without Noob Mode
|
|
172
|
+
```
|
|
173
|
+
npm ERR! code ERESOLVE
|
|
174
|
+
npm ERR! ERESOLVE unable to resolve dependency tree
|
|
175
|
+
npm ERR! Found: react@18.2.0
|
|
176
|
+
npm ERR! node_modules/react
|
|
177
|
+
npm ERR! react@"^18.2.0" from the root project
|
|
178
|
+
npm ERR! Could not resolve dependency:
|
|
179
|
+
npm ERR! peer react@"^17.0.0" from react-beautiful-dnd@13.1.1
|
|
180
|
+
```
|
|
181
|
+
|
|
182
|
+
### ✅ With Noob Mode
|
|
183
|
+
```
|
|
184
|
+
❌ WHAT WENT WRONG:
|
|
185
|
+
Two software libraries need different versions of the same tool (React), and they're incompatible.
|
|
186
|
+
|
|
187
|
+
💡 WHAT THIS MEANS:
|
|
188
|
+
It's like two apps on your phone that each require a different version of iOS — you can't satisfy both at the same time. The library called "react-beautiful-dnd" needs an older version of React (17), but this project is using the newer version (18).
|
|
189
|
+
|
|
190
|
+
🔧 WHAT WE CAN DO:
|
|
191
|
+
Option A: Update "react-beautiful-dnd" to a newer version that works with React 18
|
|
192
|
+
Option B: Force the install anyway (might cause subtle issues later)
|
|
193
|
+
Option C: Find an alternative library that works with React 18
|
|
194
|
+
|
|
195
|
+
💡 I'd recommend Option A — it's the cleanest fix.
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
---
|
|
199
|
+
|
|
200
|
+
## 8. Test Failure Output
|
|
201
|
+
|
|
202
|
+
### ❌ Without Noob Mode
|
|
203
|
+
```
|
|
204
|
+
FAIL src/utils.test.ts
|
|
205
|
+
● validateEmail › should reject invalid emails
|
|
206
|
+
expect(received).toBe(expected)
|
|
207
|
+
Expected: false
|
|
208
|
+
Received: true
|
|
209
|
+
12 | test('should reject invalid emails', () => {
|
|
210
|
+
13 | const result = validateEmail('notanemail');
|
|
211
|
+
> 14 | expect(result).toBe(false);
|
|
212
|
+
```
|
|
213
|
+
|
|
214
|
+
### ✅ With Noob Mode
|
|
215
|
+
```
|
|
216
|
+
❌ WHAT WENT WRONG:
|
|
217
|
+
One of the automated checks failed. The email validation function has a bug.
|
|
218
|
+
|
|
219
|
+
💡 WHAT THIS MEANS:
|
|
220
|
+
There's a function that checks whether an email address is valid. When it was given "notanemail" (which is clearly not a valid email), it said "yes, that's valid" instead of "no, that's not valid."
|
|
221
|
+
|
|
222
|
+
🔧 WHAT WE CAN DO:
|
|
223
|
+
The email validation logic in the file "src/utils.ts" needs to be fixed so it correctly rejects strings that aren't real email addresses.
|
|
224
|
+
|
|
225
|
+
Want me to look at the validation code and fix it?
|
|
226
|
+
```
|
|
227
|
+
|
|
228
|
+
---
|
|
229
|
+
|
|
230
|
+
## 9. Git Status/Diff Output
|
|
231
|
+
|
|
232
|
+
### ❌ Without Noob Mode
|
|
233
|
+
```
|
|
234
|
+
On branch main
|
|
235
|
+
Changes not staged for commit:
|
|
236
|
+
modified: src/config.ts
|
|
237
|
+
modified: README.md
|
|
238
|
+
Untracked files:
|
|
239
|
+
docs/new-guide.md
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
### ✅ With Noob Mode
|
|
243
|
+
```
|
|
244
|
+
✅ HERE'S WHAT'S GOING ON WITH YOUR FILES:
|
|
245
|
+
|
|
246
|
+
📝 Changed files (edited but not yet saved to version history):
|
|
247
|
+
• src/config.ts — Modified (this file was changed)
|
|
248
|
+
• README.md — Modified (this file was changed)
|
|
249
|
+
|
|
250
|
+
🆕 New files (not yet tracked):
|
|
251
|
+
• docs/new-guide.md — This is a brand-new file that version control hasn't seen before
|
|
252
|
+
|
|
253
|
+
💡 SUMMARY: You have 2 files with unsaved changes and 1 new file. None of these changes have been "committed" (saved to your project's history) yet.
|
|
254
|
+
```
|
|
255
|
+
|
|
256
|
+
---
|
|
257
|
+
|
|
258
|
+
## 10. Multi-Step Task Planning
|
|
259
|
+
|
|
260
|
+
### ❌ Without Noob Mode
|
|
261
|
+
```
|
|
262
|
+
I'll read the current implementation, refactor the auth module, update the tests, and run the test suite.
|
|
263
|
+
```
|
|
264
|
+
|
|
265
|
+
### ✅ With Noob Mode
|
|
266
|
+
```
|
|
267
|
+
📍 HERE'S MY PLAN (4 steps):
|
|
268
|
+
|
|
269
|
+
1. 📖 Read the current login code to understand how it works
|
|
270
|
+
2. ✏️ Rewrite it to use the new approach you described
|
|
271
|
+
3. 🧪 Update the automated checks to match the new code
|
|
272
|
+
4. ▶️ Run all the checks to make sure nothing broke
|
|
273
|
+
|
|
274
|
+
If your agent asks for approval at any step, I'll explain that approval before you decide.
|
|
275
|
+
|
|
276
|
+
Starting with step 1 now...
|
|
277
|
+
```
|
|
278
|
+
|
|
279
|
+
---
|
|
280
|
+
|
|
281
|
+
## 11. Technical Question to User
|
|
282
|
+
|
|
283
|
+
### ❌ Without Noob Mode
|
|
284
|
+
```
|
|
285
|
+
Should I use a relative or absolute path for the import?
|
|
286
|
+
```
|
|
287
|
+
|
|
288
|
+
### ✅ With Noob Mode
|
|
289
|
+
```
|
|
290
|
+
I need your input on something:
|
|
291
|
+
|
|
292
|
+
**Option A: Relative path**
|
|
293
|
+
What this means: Reference the file based on where THIS file is located (like saying "the folder next door").
|
|
294
|
+
Trade-off: Works well when files are near each other, but can break if you move files around.
|
|
295
|
+
|
|
296
|
+
**Option B: Absolute path**
|
|
297
|
+
What this means: Reference the file using its full address from the project root (like giving a complete street address).
|
|
298
|
+
Trade-off: Always works regardless of where things move, but is more verbose.
|
|
299
|
+
|
|
300
|
+
💡 I'd recommend Option B — it's more resilient if the project structure changes later.
|
|
301
|
+
```
|
|
302
|
+
|
|
303
|
+
---
|
|
304
|
+
|
|
305
|
+
## 12. Package Installation
|
|
306
|
+
|
|
307
|
+
### ❌ Without Noob Mode
|
|
308
|
+
```
|
|
309
|
+
Allow tool: bash with command "npm install lodash@4.17.21"?
|
|
310
|
+
[y/n]
|
|
311
|
+
```
|
|
312
|
+
|
|
313
|
+
### ✅ With Noob Mode
|
|
314
|
+
```
|
|
315
|
+
📋 WHAT I'M ASKING TO DO:
|
|
316
|
+
I want to download a widely-used utility library called "lodash" (version 4.17.21). It provides helper functions for working with data.
|
|
317
|
+
|
|
318
|
+
🎯 WHY:
|
|
319
|
+
The code I'm writing needs a function to safely access nested data. Lodash provides this, and it's the industry standard.
|
|
320
|
+
|
|
321
|
+
⚠️ RISK: 🟡 Moderate
|
|
322
|
+
This downloads code from the internet and adds it to your project. Lodash is extremely well-known and trusted — it's used by millions of projects.
|
|
323
|
+
|
|
324
|
+
✅ If you approve: The library gets downloaded into a "node_modules" folder. Your actual project files aren't changed.
|
|
325
|
+
❌ If you decline: I'll write the utility function by hand instead, which takes a bit longer.
|
|
326
|
+
|
|
327
|
+
[y/n]
|
|
328
|
+
```
|
|
329
|
+
|
|
330
|
+
---
|
|
331
|
+
|
|
332
|
+
## 13. File Deletion
|
|
333
|
+
|
|
334
|
+
### ❌ Without Noob Mode
|
|
335
|
+
```
|
|
336
|
+
Allow tool: bash with command "rm src/deprecated/old-auth.ts"?
|
|
337
|
+
[y/n]
|
|
338
|
+
```
|
|
339
|
+
|
|
340
|
+
### ✅ With Noob Mode
|
|
341
|
+
```
|
|
342
|
+
📋 WHAT I'M ASKING TO DO:
|
|
343
|
+
I want to permanently delete the file "src/deprecated/old-auth.ts."
|
|
344
|
+
|
|
345
|
+
🎯 WHY:
|
|
346
|
+
This file contains the old login code that we just replaced. No other file references it anymore, so it's safe to remove.
|
|
347
|
+
|
|
348
|
+
⚠️ RISK: 🔴 High
|
|
349
|
+
Deleting a file is permanent — there's no recycle bin for this. However, this file is tracked by git (version control), so we could recover it from history if needed.
|
|
350
|
+
|
|
351
|
+
✅ If you approve: The file is deleted from your computer. It can still be recovered from git history if you ever need it.
|
|
352
|
+
❌ If you decline: The file stays. It won't cause any harm — it's just unused clutter.
|
|
353
|
+
|
|
354
|
+
💡 SAFETY NOTE: Want me to make a backup copy before deleting it?
|
|
355
|
+
|
|
356
|
+
[y/n]
|
|
357
|
+
```
|
|
358
|
+
|
|
359
|
+
---
|
|
360
|
+
|
|
361
|
+
## 14. Complex Error Message
|
|
362
|
+
|
|
363
|
+
### ❌ Without Noob Mode
|
|
364
|
+
```
|
|
365
|
+
Error: EACCES: permission denied, open '/usr/local/lib/node_modules/example-agent/package.json'
|
|
366
|
+
at Object.openSync (node:fs:603:3)
|
|
367
|
+
at Object.readFileSync (node:fs:471:35)
|
|
368
|
+
```
|
|
369
|
+
|
|
370
|
+
### ✅ With Noob Mode
|
|
371
|
+
```
|
|
372
|
+
❌ WHAT WENT WRONG:
|
|
373
|
+
The computer blocked access to a file because your user account doesn't have permission to modify it.
|
|
374
|
+
|
|
375
|
+
💡 WHAT THIS MEANS:
|
|
376
|
+
The file is in a protected system folder ("/usr/local/...") that requires administrator privileges to change. This is actually a security feature — it prevents programs from accidentally modifying important system files.
|
|
377
|
+
|
|
378
|
+
🔧 WHAT WE CAN DO:
|
|
379
|
+
Option A: Run the command with administrator privileges ("sudo") — this temporarily elevates your permissions
|
|
380
|
+
Option B: Install to a different location that doesn't require special permissions
|
|
381
|
+
|
|
382
|
+
💡 I'd recommend Option B — it's safer and avoids needing admin access.
|
|
383
|
+
```
|
|
384
|
+
|
|
385
|
+
---
|
|
386
|
+
|
|
387
|
+
## 15. Task Completion Summary
|
|
388
|
+
|
|
389
|
+
### ❌ Without Noob Mode
|
|
390
|
+
```
|
|
391
|
+
Done. Created the analysis file.
|
|
392
|
+
```
|
|
393
|
+
|
|
394
|
+
### ✅ With Noob Mode
|
|
395
|
+
```
|
|
396
|
+
✅ ALL DONE — Here's what happened:
|
|
397
|
+
|
|
398
|
+
📄 Files created:
|
|
399
|
+
• ~/Desktop/IP-Risk-Analysis.md — A 3-page analysis of the IP risks in the proposed partnership, organized by risk level (high, medium, low)
|
|
400
|
+
|
|
401
|
+
📝 Files changed:
|
|
402
|
+
• (none — I didn't change any existing files)
|
|
403
|
+
|
|
404
|
+
🗑️ Files deleted:
|
|
405
|
+
• (none)
|
|
406
|
+
|
|
407
|
+
💡 SUMMARY:
|
|
408
|
+
I created a new document on your Desktop with the IP risk analysis you requested. It covers:
|
|
409
|
+
- 3 high-risk items (patent exposure, GPL contamination, trade secret concerns)
|
|
410
|
+
- 5 medium-risk items (trademark usage, attribution requirements, etc.)
|
|
411
|
+
- 2 low-risk items (standard OSS components)
|
|
412
|
+
|
|
413
|
+
Each item includes a plain-language explanation and recommended next steps.
|
|
414
|
+
|
|
415
|
+
🔄 TO UNDO: Delete the file at ~/Desktop/IP-Risk-Analysis.md
|
|
416
|
+
|
|
417
|
+
🎉 Anything else you'd like me to help with?
|
|
418
|
+
```
|