@only1btayy/g2w 1.0.23 → 1.0.25

package/README.md

@@ -118,7 +118,7 @@ Each Foundation agent is also a direct slash command. The normal flow runs throu
 | `/g2w:the-challenger` | You wrote your own plan outside G2W and want it stress-tested before building |
 | `/g2w:the-builder` | Plan is already locked — skip straight to building |
 | `/g2w:the-inspector` | Code is already written — just verify it against a plan |
-| `/g2w:the-leader` | Kick off the full pipeline without the identity, brainstorm, and research phases |
+| `/g2w:the-leader` | Kick off the full pipeline — includes automatic code audit before Challenger reviews |
 
 These are escape hatches for engineers who don't need the ceremony. G2W has no ceiling.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@only1btayy/g2w",
-  "version": "1.0.23",
+  "version": "1.0.25",
   "description": "G2W — a relationship protocol for building trust with AI",
   "bin": {
     "g2w": "bin/g2w.js"

package/skills/bring2life.md

@@ -99,6 +99,68 @@ Generate all 11:
 - `CURRENT.md`
 - `PLAN.md` (leave empty — written by The Visionary when a task begins)
 
+## Phase 2b — Code Audit
+
+After generating draft docs, run a deep audit of the actual code. Do not wait for the user to ask — this happens automatically. The goal is to show the user the real health of their codebase before they start building on top of it.
+
+Scan for:
+
+**Bugs & crashes:**
+- Race conditions, thread safety issues
+- Null/undefined access paths
+- Logic errors (duplicate checks, unreachable code, off-by-one)
+- State that can get out of sync
+
+**Dead code:**
+- Files with zero references
+- Functions/classes never called
+- Directories that aren't compiled or imported
+- For each: list the file, size, and verdict (delete / flag / verify first)
+
+**Anti-patterns:**
+- Copy-pasted logic that should be shared
+- Hardcoded values that should be configurable
+- Missing error handling at system boundaries
+- Overly complex functions that do too many things
+
+**Security:**
+- Exposed secrets, API keys, credentials
+- Unvalidated user input
+- Unsafe file operations
+
+**Flags worth checking:**
+- Things that work in dev but would break in production
+- Assumptions about paths, environments, or dependencies
+
+Write everything to `ERRORS.md` in the project's G2W doc folder. Use this format:
+
+```
+# Errors & Issues — [project-name]
+Generated by bring2life: [date]
+
+## Critical Bugs
+### ERR-XX — [short title]
+**File:** `path/to/file.ext:line-range`
+**What's wrong:** [explain what the code actually does vs what it should do]
+**The fix:** [specific fix, not vague advice]
+
+## Dead Code
+| File | Size | Verdict |
+|------|------|---------|
+| `file.ext` | XXkb | Delete — [reason] |
+
+## Anti-Patterns
+[list with file references]
+
+## Security
+[list with file references]
+
+## Flags
+[things that need human verification before acting on]
+```
+
+Be specific. File paths, line numbers, what's actually broken and why. No vague "consider improving" — either it's a real issue or don't list it.
+
 ## Phase 3 — Gap Interview
 
 After generating drafts, ask the questions you couldn't answer from the code alone. Ask them conversationally — no more than 3 at a time. Cover:

package/skills/ready2save.md

@@ -9,14 +9,19 @@ You are closing out this session. Leave the project in a state where any future
 
 ## Steps
 
-1. **Read `~/.g2w/CURRENT.md`** to confirm the active project. All writes go to `~/.g2w/projects/[active-project]/`. If no active project is set, ask the user which project to save to.
+1. **Capture decisions** — Review the conversation history and extract:
+   - What was built or changed
+   - Key decisions made and the reasoning behind them
+   - Any "don't do this again" lessons learned
 
-2. **Capture decisions** — Ask the user:
-   > "What key decisions did we make this session that future-me needs to know? (reasoning behind choices, not just what was done)"
+   Do NOT ask the user to recall this — you have the full conversation. Only ask if something is genuinely ambiguous.
 
-   Wait for their answer. Do not skip this.
+2. **Confirm the active project** — List all folders inside `projects/` and ask:
+   > "Which project are we saving? (pick one)"
 
-3. **Update `~/.g2w/projects/[active-project]/CURRENT.md`** with exactly three sections:
+   Wait for the user to confirm. Do not assume based on what was discussed — the user decides.
+
+3. **Update `.g2w/CURRENT.md`** in the confirmed project folder with exactly three sections:
    ```
    ## Last Completed
    [What was finished and verified this session — be specific]
@@ -28,13 +33,19 @@ You are closing out this session. Leave the project in a state where any future
    [The single most important next task]
    ```
 
-4. **Write a handoff note** at the bottom of `~/.g2w/projects/[active-project]/CURRENT.md` under `## Session Notes — [date]`:
+   Then write (or overwrite) `.g2w/CURRENT.md` in the **`Claudes Brain` root** with a single line:
+   ```
+   active: projects/[confirmed-project-folder-name]
+   ```
+   This is the pointer `back2it` uses to find the right project next session.
+
+4. **Write a handoff note** at the bottom of `.g2w/CURRENT.md` under `## Session Notes — [date]`:
    - What was built
    - Key decisions made AND the reasoning behind them (the WHY matters more than the WHAT)
    - Any gotchas or "don't do this again" lessons
    - What to read first next session
 
-4b. **Mine into MemPalace (if installed):** Run `/3.0.12:mine` on `~/.g2w/projects/[active-project]/CURRENT.md` to index this session's decisions into MemPalace. This makes them searchable across future sessions even after context clears. If MemPalace isn't installed, skip this step silently.
+4b. **Mine into MemPalace (if installed):** Run `/mempalace:mine` on the project's `.g2w/CURRENT.md` to index this session's decisions into MemPalace. This makes them searchable across future sessions even after context clears. If MemPalace isn't installed, skip this step silently.
 
 5. **Commit** everything that was verified this session:
    ```
@@ -54,5 +65,5 @@ You are closing out this session. Leave the project in a state where any future
 
 - Never commit unverified work — if something wasn't tested, say so and don't include it
 - The handoff note must capture WHY decisions were made, not just what was done
-- If the user skips the decisions question, prompt once more — this is the most important part
+- Extract decisions from the conversation — never make the user recall work you already witnessed
 - Do not clear context or close anything — that's the user's call

package/skills/the-challenger.md

@@ -42,7 +42,9 @@ Attack every dimension:
 
 1. **Read `PLAN.md`** from `~/.g2w/projects/[active-project]/`
 
-1b. **Invoke Superpowers (Claude users only):** If `superpowers:requesting-code-review` is available, invoke it now to sharpen adversarial analysis before reading the plan. If not available, proceed with native capabilities.
+1b. **Read `ERRORS.md`** from `~/.g2w/projects/[active-project]/` — this is the code audit generated by The Leader. Use it as context: if the plan touches code with known bugs, flag it. If the plan ignores critical issues that should be addressed first, call it out. If ERRORS.md doesn't exist, note it as a finding ("no code audit was run").
+
+1c. **Invoke Superpowers (Claude users only):** If `superpowers:requesting-code-review` is available, invoke it now to sharpen adversarial analysis before reading the plan. If not available, proceed with native capabilities.
 
 2. **Read the actual codebase** — don't review a plan in a vacuum. Check that file paths exist, that functions referenced exist, that data structures match reality.
 

package/skills/the-inspector.md

@@ -60,10 +60,12 @@ There is no partial pass. The build either passes inspection or it goes back to
 ## Process
 
 1. Read `PLAN.md` — know the contract
-2. Read every file that was modified
-3. Work through the test matrix item by item
-4. Report: PASS (all items verified, user confirmed) or FAIL (specific items failing + fix list)
-5. On PASS → tell The Leader: inspection complete, ready for handoff
+2. Read `ERRORS.md` — know the pre-existing issues
+3. Read every file that was modified
+4. Work through the test matrix item by item
+5. **Update `ERRORS.md`** — mark any issues that were fixed this session as resolved. Add any new issues discovered during verification. Never delete old entries — mark them with `[RESOLVED — date]`.
+6. Report: PASS (all items verified, user confirmed) or FAIL (specific items failing + fix list)
+7. On PASS → tell The Leader: inspection complete, ready for handoff
 
 ## Rules
 

package/skills/the-leader.md

@@ -24,8 +24,16 @@ You are The Leader. You own the pipeline from task definition to handoff. Every
 - Verify PLAN.md exists and has no TBD/TODO/❓ markers before passing to Challenger
 - If markers exist → send back to Visionary. Do not pass incomplete plans.
 
+**Phase 1b — Code Audit (auto):**
+- Check if `ERRORS.md` exists in `~/.g2w/projects/[active-project]/`
+- If it doesn't exist OR is older than 7 days → run a full code audit now
+- Scan the codebase for: bugs, crashes, race conditions, dead code, anti-patterns, security issues
+- Write findings to `ERRORS.md` with file paths, line numbers, and specific descriptions
+- This runs automatically — never ask the user if they want an audit. They always do.
+- If `ERRORS.md` already exists and is current → skip, move on
+
 **Phase 2 — Challenge:**
-- Hand plan to The Challenger
+- Hand plan AND `ERRORS.md` to The Challenger
 - Receive findings
 - If FAIL → return to Visionary with findings. Loop until Challenger gives PASS.
 - On PASS → LOCK the plan. Announce: "Plan is locked. No modifications after this point."