@only1btayy/g2w 1.0.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 ONLY1BTAYY
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,199 @@
+<div align="center">
+
+<img src="assets/logo.png" width="600" alt="G2W" />
+
+</div>
+
+# G2W
+
+The best relationships are built on trust. Trust comes from honesty, and honesty breeds clarity and understanding.
+
+I got tired of going in circles with Claude and others because the systems I was using were not set up in a way that builds trust between the user and the model. Some of the top CEOs and big business people who use AI are not concerned with the question — "can it build?" Instead they are focused on — "can we trust what it builds and can we ship it?"
+
+This is not a workflow system. Not a task runner. This is a protocol for building trust between you and your AI so what gets built is actually what you envisioned. No more back and forth and all the other bullshit that gets in the way.
+
+**G2W is a relationship protocol.**
+
+---
+
+[![npm version](https://img.shields.io/badge/npm-v0.1.0-CB3837?style=for-the-badge&logo=npm&logoColor=white)](https://www.npmjs.com/package/g2w)
+[![license](https://img.shields.io/badge/license-MIT-6e7681?style=for-the-badge)](LICENSE)
+[![platform](https://img.shields.io/badge/platform-Claude%20Code-8957e5?style=for-the-badge)](https://claude.ai/code)
+[![status](https://img.shields.io/badge/status-In%20Development-d29922?style=for-the-badge)]()
+
+---
+
+```bash
+npm install -g g2w
+```
+
+```bash
+g2w install
+```
+
+```
+  1. Global  ~/.claude/     available in all projects
+  2. Local   ./.claude/     this project only
+
+✅ G2W installed — 9 skills + hooks ready.
+```
+
+**Works on Mac, Windows, and Linux.**
+
+---
+
+[The Name](#the-name) · [The Problem](#the-problem) · [How It Works](#how-it-works) · [The Commands](#the-commands) · [How 2 Install](#how-2-install) · [Who It's For](#who-its-for) · [Philosophy](#the-philosophy)
+
+---
+
+## The Name
+
+I named G2W after my motto in life — "It's going to work or it's going to work." This is a perspective shift I had that allows me to view even the apparent losses in life as wins because the gems are in the data. Every loss, every mistake, every doubt and fear we have is data that is filled with gems. We just have to choose to look at it that way. The people who change the world are often considered crazy and delusional until they actually change it. Then the "crazy" becomes genius and the "delusional" becomes relentless. I want you to dare to be relentless in your approach to the challenges in life and remember — it's going to work or it's going to work — ain't no other options.
+
+No in-between. No failure as an option. Two paths and both lead to success.
+
+---
+
+## The Problem
+
+You've worked with AI before. You know how it goes.
+
+You say "make this button this size" and it does something else and explains why it was right. You spend an hour in a discussion session and then have to repeat everything again when it's time to plan. It makes a change that breaks three other things it never bothered to check. It commits code you didn't approve. It guesses instead of asking.
+
+G2W fixes all of that. Not by adding more rules but by building a system that genuinely earns trust.
+
+The problem was never intelligence. The problem was process.
+
+---
+
+## How It Works
+
+---
+
+### The Modular Doc System
+
+Every project gets a full set of living documents — `ARCHITECTURE.md`, `CONVENTIONS.md`, `ERRORS.md`, `CHANGELOG.md`, and more. The rule is simple: when you change code that any doc describes, update that doc in the same session. No separate documentation pass. No stale docs. The knowledge base stays current automatically.
+
+---
+
+### Talk Once. Plan Once. Build.
+
+You start a conversation. You describe your vision. G2W listens, asks smart questions, and runs research silently in the background — tech stack, existing solutions, the ecosystem. By the time you're done talking, the plan is already written and locked.
+
+No separate phases. No repeating yourself. Just a conversation that ends with something ready to build.
+
+---
+
+### The Foundation
+
+Once the plan locks, The Foundation takes over. Five roles. One mission. Get it right the first time.
+
+| Agent | Role |
+|---|---|
+| The Visionary | Writes a complete plan with real decisions and no placeholders |
+| The Challenger | Adversarial review — finds every way the plan could fail before coding starts |
+| The Builder | Builds exactly what the locked plan says, nothing extra |
+| The Inspector | Verifies everything against the plan and loops until it's clean |
+| The Leader | Manages the team and keeps everything on track |
+
+The plan is the contract. By the time The Builder touches a single line of code, every decision has already been made.
+
+---
+
+### The Trust Layer
+
+Delivered via hook so it runs every single session, not just when the AI remembers.
+
+- Your explicit instruction is a direct order. No agent may override it, rationalize it away, or route around it.
+- The AI answers your question first and then asks to proceed — never just acts.
+- No edits outside the declared scope.
+- No commits without your approval.
+- "I don't know" instead of guessing — always.
+- Uncertainty is labeled, not hidden. `[Inference]` and `[Unverified]` are used so you always know what's confirmed and what isn't.
+- If scope creeps, it stops and flags it before touching anything.
+
+---
+
+### The A-Game Hook
+
+Before any edit or bug fix, A-Game fires automatically.
+
+- What does this change touch?
+- What could break downstream?
+- Is this more complex than it looks?
+- Does every function, model, or method being referenced actually exist?
+
+Only after working through those questions does execution begin. Taking more time upfront is always better than going in circles.
+
+---
+
+### Git Without The Friction
+
+Safe git operations — add, commit, push, status, log — run without approval prompts. One command handles the whole thing. Add, commit, push. Done. No multi-step back and forth, no unnecessary interruptions. You stay in flow.
+
+---
+
+## The Commands
+
+| Command | What It Does |
+|---|---|
+| `/g2w:bring2life` | Onboard an existing codebase — scans it, generates your doc files, flags gaps |
+| `/g2w:build2gether` | Start a new project — brainstorm, research, and locked plan in one conversation |
+| `/g2w:back2it` | Pick up right where you left off |
+| `/g2w:get2work` | Execute the current task |
+| `/g2w:cut2it` | Fast mode — small tasks, no ceremony |
+| `/g2w:back2basics` | Strip context and start clean |
+| `/g2w:true2plan` | Verify that what was built actually matches the plan |
+| `/g2w:true2dagame` | Full system health check |
+| `/g2w:ready2save` | Wrap up the session — update CURRENT.md, capture key decisions and the reasoning behind them, hand off cleanly |
+
+---
+
+## How 2 Install
+
+```bash
+npm install -g g2w
+```
+
+Then `cd` into your project and run:
+
+```bash
+g2w install
+```
+
+You'll be asked:
+
+```
+  1. Global  ~/.claude/     available in all projects
+  2. Local   ./.claude/     this project only
+```
+
+Pick 1 to set it and forget it. Pick 2 if you want G2W in just one project.
+
+> **Tip:** The logo renders in **bright green** in any terminal. On Windows Terminal or iTerm2, enable Retro/Bloom effects for the full glow.
+
+---
+
+## Who It's For
+
+Everyone tired of the bullshit. Vibe coders who just want to ship. Senior engineers who want control. Solo builders with no team and no co-founder.
+
+If you've ever felt like your AI was working against you instead of with you, G2W is for you.
+
+G2W works in other models — the Modular Doc System and commands are model-agnostic. But Claude Code is where it's fully alive. The Trust Layer, A-Game Hook, and context warnings are all hook-delivered, which means they run every single session without relying on the AI to remember. Other models get the workflow. Claude Code gets the guarantees.
+
+---
+
+## The Philosophy
+
+Speed comes from simplicity. Control comes from clarity. If you need a system to manage your system, it's already broken. G2W is not a factory. It's a studio.
+
+---
+
+## Status
+
+Under active development. First real-world test case is Blackhole VST running through `/g2w:bring2life`.
+
+---
+
+*Built by ONLY1BTAYY · MIT License · Claude Code native*

package/bin/g2w.js

@@ -0,0 +1,20 @@
+#!/usr/bin/env node
+
+const [,, command = 'help'] = process.argv;
+
+if (command === 'install') {
+  require('../lib/install').run();
+} else if (command === 'update') {
+  require('../lib/install').update();
+} else if (command === 'uninstall') {
+  require('../lib/install').uninstall();
+} else {
+  console.log(`
+G2W — It's going to work or it's going to work.
+
+Usage:
+  g2w install    — set up G2W (choose global or local)
+  g2w update     — update skills to latest version
+  g2w uninstall  — remove G2W
+`);
+}

package/lib/install.js

@@ -0,0 +1,166 @@
+const fs = require('fs');
+const path = require('path');
+const os = require('os');
+const readline = require('readline');
+
+const SKILLS_SRC = path.join(__dirname, '../skills');
+
+const G2W_HOOKS = {
+  PreToolUse: [
+    {
+      matcher: 'Edit|Write|Bash',
+      hooks: [
+        {
+          type: 'prompt',
+          prompt: 'Trust Layer + A-Game check: answer the user\'s question first before acting. Declare scope (exact files you will touch). Stop if scope creeps beyond what was declared. Say "I don\'t know" instead of guessing. No commits without explicit user approval. A-Game: what does this change touch? What could break downstream? Is it more complex than it looks? If the user seems stuck or frustrated — remind them of their vision, not just fix the code.'
+        }
+      ]
+    }
+  ],
+  PostMessage: [
+    {
+      matcher: '.*',
+      hooks: [
+        {
+          type: 'prompt',
+          prompt: 'If the context window is at or above 80%, tell the user: "Hey — we\'re getting close to the context limit. Want me to run /g2w:ready2save to save progress and clear context?" If below 80%, do nothing.'
+        }
+      ]
+    }
+  ]
+};
+
+function prompt(question) {
+  const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
+  return new Promise(resolve => rl.question(question, answer => { rl.close(); resolve(answer.trim()); }));
+}
+
+function copySkills(targetBase) {
+  const dest = path.join(targetBase, '.claude', 'skills', 'g2w');
+  fs.mkdirSync(dest, { recursive: true });
+  const files = fs.readdirSync(SKILLS_SRC).filter(f => f.endsWith('.md'));
+  files.forEach(file => {
+    fs.copyFileSync(path.join(SKILLS_SRC, file), path.join(dest, file));
+  });
+  return { dest, count: files.length };
+}
+
+function mergeHooks(targetBase) {
+  const settingsPath = path.join(targetBase, '.claude', 'settings.json');
+  fs.mkdirSync(path.join(targetBase, '.claude'), { recursive: true });
+
+  let existing = {};
+  if (fs.existsSync(settingsPath)) {
+    try { existing = JSON.parse(fs.readFileSync(settingsPath, 'utf8')); } catch {}
+  }
+
+  if (!existing.hooks) existing.hooks = {};
+
+  // Merge PreToolUse — append if not already present
+  if (!existing.hooks.PreToolUse) existing.hooks.PreToolUse = [];
+  const alreadyHasPreHook = existing.hooks.PreToolUse.some(h =>
+    h.hooks && h.hooks.some(hh => hh.prompt && hh.prompt.includes('Trust Layer'))
+  );
+  if (!alreadyHasPreHook) {
+    existing.hooks.PreToolUse.push(...G2W_HOOKS.PreToolUse);
+  }
+
+  // Merge PostMessage — append if not already present
+  if (!existing.hooks.PostMessage) existing.hooks.PostMessage = [];
+  const alreadyHasPostHook = existing.hooks.PostMessage.some(h =>
+    h.hooks && h.hooks.some(hh => hh.prompt && hh.prompt.includes('ready2save'))
+  );
+  if (!alreadyHasPostHook) {
+    existing.hooks.PostMessage.push(...G2W_HOOKS.PostMessage);
+  }
+
+  fs.writeFileSync(settingsPath, JSON.stringify(existing, null, 2));
+  return settingsPath;
+}
+
+function removeSkills(targetBase) {
+  const dest = path.join(targetBase, '.claude', 'skills', 'g2w');
+  if (fs.existsSync(dest)) {
+    fs.rmSync(dest, { recursive: true, force: true });
+    return true;
+  }
+  return false;
+}
+
+function removeHooks(targetBase) {
+  const settingsPath = path.join(targetBase, '.claude', 'settings.json');
+  if (!fs.existsSync(settingsPath)) return;
+
+  let existing = {};
+  try { existing = JSON.parse(fs.readFileSync(settingsPath, 'utf8')); } catch { return; }
+
+  if (existing.hooks) {
+    if (existing.hooks.PreToolUse) {
+      existing.hooks.PreToolUse = existing.hooks.PreToolUse.filter(h =>
+        !(h.hooks && h.hooks.some(hh => hh.prompt && hh.prompt.includes('Trust Layer')))
+      );
+    }
+    if (existing.hooks.PostMessage) {
+      existing.hooks.PostMessage = existing.hooks.PostMessage.filter(h =>
+        !(h.hooks && h.hooks.some(hh => hh.prompt && hh.prompt.includes('ready2save')))
+      );
+    }
+  }
+
+  fs.writeFileSync(settingsPath, JSON.stringify(existing, null, 2));
+}
+
+async function getTarget() {
+  console.log(`
+G2W — Install
+
+Where should G2W be installed?
+
+  1. Global  ~/.claude/     available in all projects
+  2. Local   ./.claude/     this project only
+
+`);
+  const answer = await prompt('Enter 1 or 2: ');
+  if (answer === '1') return { base: os.homedir(), label: '~/.claude/' };
+  if (answer === '2') return { base: process.cwd(), label: `./.claude/` };
+  console.log('Invalid choice. Please enter 1 or 2.');
+  return getTarget();
+}
+
+async function run() {
+  const { base, label } = await getTarget();
+  const { dest, count } = copySkills(base);
+  const settingsPath = mergeHooks(base);
+
+  console.log(`
+✅ G2W installed at ${label}
+
+  ${count} skills → ${path.join(label, 'skills/g2w/')}
+  Hooks    → ${path.join(label, 'settings.json')}
+
+Open any project with Claude Code and type:
+  /g2w:bring2life    — onboard an existing codebase
+  /g2w:back2it       — resume a session
+  /g2w:build2gether  — start something new
+`);
+}
+
+async function update() {
+  const { base, label } = await getTarget();
+  copySkills(base);
+  console.log(`\n✅ G2W skills updated at ${label}\n`);
+}
+
+async function uninstall() {
+  const { base, label } = await getTarget();
+  const removed = removeSkills(base);
+  removeHooks(base);
+
+  if (removed) {
+    console.log(`\n✅ G2W removed from ${label}\n`);
+  } else {
+    console.log(`\nG2W was not found at ${label}\n`);
+  }
+}
+
+module.exports = { run, update, uninstall };

package/package.json

@@ -0,0 +1,27 @@
+{
+  "name": "@only1btayy/g2w",
+  "version": "1.0.0",
+  "description": "G2W — a relationship protocol for building trust with AI",
+  "bin": {
+    "g2w": "bin/g2w.js"
+  },
+  "files": [
+    "bin/",
+    "lib/",
+    "skills/"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/ONLY1BTAYY/G2W.git"
+  },
+  "keywords": [
+    "claude",
+    "ai",
+    "workflow",
+    "claude-code"
+  ]
+}

package/skills/back2basics.md

@@ -0,0 +1,48 @@
+---
+name: back2basics
+description: Strip context down to the minimum — when things are going in circles, reset and start clean
+---
+
+# /g2w:back2basics
+
+Things got complicated. Step back. Start clean. One thing at a time.
+
+## When to Use This
+
+- The session has gone in circles
+- Context is bloated with dead-ends and false starts
+- You're not sure what's actually true anymore
+- Something feels off and you need a clean read
+
+## Steps
+
+1. **Stop everything** — do not continue any current line of work.
+
+2. **Read only `CURRENT.md`** — nothing else yet.
+
+3. **Ask the user one question:**
+   > "What is the single most important thing we need to get working right now?"
+
+4. **Based on their answer, read exactly one doc:**
+   - Bug/error → `ERRORS.md`
+   - New feature → `ARCHITECTURE.md`
+   - Code style question → `CONVENTIONS.md`
+   - Unclear what's built → `FEATURES.md`
+
+5. **State what you know:**
+   ```
+   Current state: [what CURRENT.md says]
+   One doc read: [which doc, what's relevant]
+   Task: [the one thing the user named]
+   ```
+
+6. **Ask:** "Ready to work on just this one thing?"
+
+7. **Proceed with minimal context** — read additional files only as the task absolutely requires them.
+
+## Rules
+
+- Do not read more than one doc in this step — that defeats the purpose
+- Do not carry forward assumptions from earlier in the session — treat this as a fresh start
+- If the user's answer involves multiple things, ask them to pick one
+- Stay narrow until the one task is done, then re-assess

package/skills/back2it.md

@@ -0,0 +1,37 @@
+---
+name: back2it
+description: Resume the last G2W session — reads CURRENT.md and relevant docs, gets back up to speed in seconds
+---
+
+# /g2w:back2it
+
+You are resuming a G2W session. Get back up to speed fast. No fluff.
+
+## Steps
+
+1. **Read `CURRENT.md`** in the project root. This is your source of truth.
+
+2. **Read one supporting doc** based on what's In Progress:
+   - If In Progress involves code structure or a new feature → read `ARCHITECTURE.md`
+   - If In Progress involves a bug or error → read `ERRORS.md`
+   - If In Progress involves writing or modifying code → read `CONVENTIONS.md`
+   - If nothing is In Progress → no additional doc needed
+
+3. **Doc integrity check:** Does the doc you read still match the current state? If something looks stale, flag it before touching anything else.
+
+4. **Output a 4-line summary** (no more):
+   ```
+   Last done: [what was completed]
+   In progress: [what's active, or "nothing"]
+   Next: [immediate next task]
+   Blockers: [any known issues, or "none"]
+   ```
+
+5. Ask: "Ready to pick up where we left off?"
+
+## Rules
+
+- Do not read files beyond what's needed for the current task
+- Do not start executing anything — this is orientation only
+- If CURRENT.md is missing or empty, say so and ask the user to describe where things stand
+- If docs look out of sync with the code, fix the doc FIRST before touching anything else

package/skills/bring2life.md

@@ -0,0 +1,96 @@
+---
+name: bring2life
+description: Onboard an existing codebase into G2W — scan what's there, generate doc drafts, flag gaps, ask what it couldn't figure out
+---
+
+# /g2w:bring2life
+
+You are reverse-engineering a G2W doc system from an existing codebase. This is the killer feature for developers with messy, undocumented projects. By the end, they have a full G2W doc set that reflects reality — not wishful thinking.
+
+## Phase 1 — Silent Scan
+
+Read the codebase. Do not ask any questions yet. Your job right now is to understand what's actually there.
+
+Look for:
+- Language, framework, build tooling (package.json, Cargo.toml, pyproject.toml, Makefile, etc.)
+- Folder structure and what lives where
+- Key entry points (main file, index, server start, etc.)
+- Dependencies and versions
+- Any existing README, docs, or comments
+- Patterns in the code (naming conventions, file organization, common idioms)
+- Signs of known bugs or TODOs (grep for `TODO`, `FIXME`, `HACK`, `XXX`)
+- Signs of what's built vs in-progress vs broken
+
+Do not announce what you're reading. Just read.
+
+## Phase 2 — Generate Draft Docs
+
+Write first-draft versions of all 10 G2W docs based on what you found.
+
+For every field you're confident about: fill it in.
+For every field you're uncertain about: write `❓ [UNKNOWN — needs your input]`
+For every field that clearly doesn't apply: write `N/A`
+
+Generate all 10:
+- `CLAUDE.md`
+- `ARCHITECTURE.md`
+- `CONVENTIONS.md`
+- `FEATURES.md`
+- `ERRORS.md`
+- `CHANGELOG.md`
+- `TESTING.md`
+- `SCALING.md`
+- `SECURITY.md`
+- `CURRENT.md`
+
+## 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:
+
+**Vision questions:**
+- What is this project actually for? (The README might lie — I want your words.)
+- What's the end state you're building toward?
+
+**Known issues:**
+- What's the biggest thing that's broken right now?
+- Is there anything I should never touch without asking you first?
+
+**History:**
+- Are there any decisions in the codebase that look weird but are intentional? (Things I might "fix" that would break something.)
+
+**Testing:**
+- How do you currently verify something works before calling it done?
+- Is there a build step, deploy step, or environment I need to know about?
+
+**Future:**
+- What's the next thing you're going to build?
+
+Fill in the `❓ [UNKNOWN]` gaps based on their answers.
+
+## Phase 4 — Final Output
+
+Write the completed doc files to the project root.
+
+Output a summary:
+```
+bring2life complete.
+
+Docs generated: 10
+Auto-filled from code: [X fields]
+Filled from your answers: [X fields]
+Still needs input: [list any remaining ❓ items]
+```
+
+Then:
+> "Your G2W doc system is live. Next time you open this project, start with `/g2w:back2it`."
+
+If this is a Blackhole VST project (C++ / JUCE):
+> "Run Blackhole through the full pipeline next — `/g2w:build2gether` to start your first G2W task."
+
+## Rules
+
+- Read the actual code — do not generate docs from assumptions
+- Every `❓ [UNKNOWN]` is honest uncertainty — better than a confident wrong answer
+- Do not create `CURRENT.md` with "In Progress" items you invented — only use what the user confirms
+- Do not modify any existing code during this process — docs only
+- If the codebase is very large (100+ files), prioritize: entry points, core modules, known pain areas

package/skills/build2gether.md

@@ -0,0 +1,70 @@
+---
+name: build2gether
+description: Start a new project or feature — structured discussion, silent background research, locked plan. Talk once. Plan once. Build.
+---
+
+# /g2w:build2gether
+
+You are starting something new. This is the full intake flow: clarify vision → research in background → write plan → lock it. By the time this is done, there is nothing left to figure out before building.
+
+## Phase 0 — Requirements Clarification
+
+Ask the user these questions **conversationally** — not as a numbered list all at once. Ask 1-2 at a time, listen, follow up. This IS the brainstorm.
+
+Core questions to cover:
+- What are we building? Describe it like you're explaining to a smart friend.
+- What does "done" look like? What's the first thing you'll do to test it?
+- What are the hard constraints? (platform, tech stack, deadlines, budget)
+- What could go wrong? Walk me through the failure cases you're already worried about.
+- What's NOT in scope? What are we explicitly not building right now?
+- Any existing code, patterns, or docs I need to read first?
+
+Do not move to planning until you can answer all of these confidently. If an answer is vague, ask again.
+
+## Phase 1 — Silent Research (while talking)
+
+While the conversation is happening, spin background research agents for:
+- Existing solutions or libraries that solve part of this problem
+- Known pitfalls or edge cases in this tech area
+- Relevant patterns from the project's existing codebase (if any)
+
+Research is invisible to the user. It informs the plan — the user never feels it.
+
+## Phase 2 — Planning
+
+Once requirements are locked and research is complete:
+
+**Planner Agent** writes a complete plan:
+- No placeholders. Actual code, actual file names, actual decisions.
+- Declares exactly which files will be created or modified — nothing undeclared
+- Writes a concrete definition of done for this specific task
+- Estimates scope honestly: small / medium / large
+
+**Reviewer Agent** does an adversarial pass:
+- Job: find every way this plan could fail
+- Must answer: environment differences, edge cases, undeclared file touches, regressions, ambiguities a coder could resolve the wrong way
+- Loops with Planner until the Reviewer can find nothing wrong
+- Plan is then locked — no agent may modify it after this point
+
+## Phase 3 — Lock & Hand Off
+
+Present the locked plan to the user. Summary format:
+```
+Plan locked.
+
+What we're building: [1 sentence]
+Files touched: [list]
+Definition of done: [specific verification steps]
+Scope: [small / medium / large]
+```
+
+Then output:
+> "Plan's locked — ready to build? (`/g2w:get2work`)"
+
+## Rules
+
+- Never start planning until ambiguity is zero
+- Research happens silently — don't announce agents spinning up
+- The plan must be complete enough that a different Claude session could execute it cold
+- Once locked, the plan cannot be changed without re-running this command
+- If the user changes requirements mid-plan, restart Phase 0 — don't patch a partial plan

package/skills/cut2it.md

@@ -0,0 +1,43 @@
+---
+name: cut2it
+description: Fast mode — for clearly scoped, low-risk changes. Skip planning ceremony, declare scope, build, verify.
+---
+
+# /g2w:cut2it
+
+No ceremony. You know what you're doing, it's small, and it's low-risk. Get it done.
+
+## When to Use This
+
+Use `/g2w:cut2it` only when ALL of these are true:
+- The change is clearly scoped (you could describe it in one sentence)
+- It touches 1-3 files max
+- It's low risk (not touching auth, payments, core logic, or anything that could cascade)
+- No adversarial plan review is needed
+
+If you're unsure about any of these → use `/g2w:build2gether` instead.
+
+## Steps
+
+1. **User describes the task** — one sentence. If it takes more than one sentence, it's not `/g2w:cut2it` territory.
+
+2. **Declare scope** — immediately, before touching anything:
+   ```
+   Scope: [what you're changing and why]
+   Files: [exact list]
+   Not touching: [anything nearby that could be confused]
+   ```
+   Wait for approval.
+
+3. **Build** — fast, focused, exactly what was described. Nothing extra.
+
+4. **Verify** — show proof it works. Do not say "should work."
+
+5. **Done** — that's it. No formal commit ceremony unless the user asks. No `/g2w:true2plan` required.
+
+## Rules
+
+- If anything unexpected comes up mid-build → stop and flag it. Don't improvise.
+- If scope grows beyond what was declared → stop, re-declare, get re-approval
+- No "while I'm in here" improvements
+- If it turns out to be more complex than expected → say so and escalate to `/g2w:build2gether`

package/skills/get2work.md

@@ -0,0 +1,43 @@
+---
+name: get2work
+description: Execute the locked plan — declare scope, build exactly what was planned, nothing extra
+---
+
+# /g2w:get2work
+
+You are executing a locked plan. Build exactly what it says. Nothing extra. Nothing "improved."
+
+## Steps
+
+1. **Read the locked plan** — if no plan exists or it's not locked, stop and say:
+   > "No locked plan found. Run `/g2w:build2gether` first."
+
+2. **Read `CONVENTIONS.md`** — know the rules before touching code.
+
+3. **Declare scope** — before writing a single line, output:
+   ```
+   Scope declaration:
+   Files I will create: [list, or "none"]
+   Files I will modify: [list, or "none"]
+   Files I will NOT touch: [anything nearby that could be confused]
+   ```
+   Wait for the user to approve scope. Do not proceed without approval.
+
+4. **Build** — execute the plan in order:
+   - One logical unit at a time
+   - After each unit: brief status ("Done: [what was just built]")
+   - If anything unexpected comes up mid-build → STOP. Do not improvise. Flag it:
+     > "Unexpected: [what happened]. This wasn't in the plan. How do you want to handle it?"
+
+5. **Stay in scope** — if the work requires touching a file not in the declaration:
+   > "Scope creep: I need to touch [file] which wasn't declared. Stopping. Do you want me to re-declare scope?"
+
+6. **On completion** → automatically run `/g2w:true2plan`
+
+## Rules
+
+- Never add features, improvements, or "while I'm in here" changes
+- Never touch undeclared files without explicit re-approval
+- If something is ambiguous in the plan, ask — don't interpret
+- "Done" means verified, not just written — do not claim completion without proof
+- After `/g2w:true2plan` passes: run `/g2w:ready2save` to commit and hand off

package/skills/ready2save.md

@@ -0,0 +1,54 @@
+---
+name: ready2save
+description: Wrap up the current G2W session — save decisions, update CURRENT.md, commit verified work, hand off cleanly
+---
+
+# /g2w:ready2save
+
+You are closing out this session. Leave the project in a state where any future session can pick up instantly.
+
+## Steps
+
+1. **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)"
+
+   Wait for their answer. Do not skip this.
+
+2. **Update `CURRENT.md`** with exactly three sections:
+   ```
+   ## Last Completed
+   [What was finished and verified this session — be specific]
+
+   ## In Progress
+   [What is actively unfinished, or write "(none)"]
+
+   ## Next
+   [The single most important next task]
+   ```
+
+3. **Write a handoff note** at the bottom of `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
+
+4. **Commit** everything that was verified this session:
+   ```
+   type: short summary
+
+   - What changed
+   - What changed
+   - Verified: [how it was verified]
+   ```
+
+   Present the commit message to the user. Wait for approval before running.
+
+5. **Announce:**
+   > "Saved. Context is clean. Next session, type `/g2w:back2it` to pick up right where we left off."
+
+## Rules
+
+- 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
+- Do not clear context or close anything — that's the user's call

package/skills/true2dagame.md

@@ -0,0 +1,101 @@
+---
+name: true2dagame
+description: Full G2W system health check — are docs in sync, is the plan locked, are there unresolved critical errors?
+---
+
+# /g2w:true2dagame
+
+You are auditing the project's G2W health. No rubber-stamping. Find what's broken before it breaks you.
+
+## Checks
+
+Run each check and record ✅ PASS, ⚠️ WARNING, or ❌ FAIL.
+
+---
+
+### 1. Doc Sync Check
+
+For each G2W doc that exists in this project:
+- Does `ARCHITECTURE.md` reflect the current tech stack and structure?
+- Does `FEATURES.md` reflect what's actually built vs what's broken vs what's next?
+- Does `ERRORS.md` list the current known bugs with accurate severity?
+- Does `CONVENTIONS.md` match the patterns actually used in the code?
+- Does `CURRENT.md` reflect the actual current state (not last week's)?
+
+Flag any doc that looks stale or inconsistent with what you can observe.
+
+---
+
+### 2. Plan Status Check
+
+- Does a locked plan exist for the current task?
+- Is it locked (not a draft)?
+- Does it have a clear definition of done?
+- Are all declared files still accurate (none renamed, deleted, or added since locking)?
+
+---
+
+### 3. Error Status Check
+
+- Read `ERRORS.md`
+- Flag any CRITICAL or HIGH severity errors that are unresolved
+- Are any errors listed as "in progress" but stale (no recent activity)?
+
+---
+
+### 4. CURRENT.md Freshness
+
+- Does `CURRENT.md` reflect the last session accurately?
+- Is "In Progress" still actually in progress, or was it finished and not updated?
+- Is "Next" still the right next task?
+
+---
+
+### 5. Git Hygiene
+
+- Are there uncommitted verified changes sitting in the working tree?
+- Does the last commit message follow G2W format (type + summary + bullets + verified)?
+
+---
+
+## Output Format
+
+```
+G2W Health Check — [date]
+
+Docs:
+✅ ARCHITECTURE.md — in sync
+✅ FEATURES.md — in sync
+⚠️  ERRORS.md — ERR-01 marked critical, no activity in 3 sessions
+❌ CONVENTIONS.md — missing (not created yet)
+
+Plan:
+✅ Plan locked
+✅ Definition of done present
+⚠️  2 declared files may have been renamed since lock
+
+Errors:
+⚠️  ERR-01 — CRITICAL, unresolved
+✅ No stale "in progress" errors
+
+CURRENT.md:
+✅ Looks fresh
+
+Git:
+✅ No uncommitted verified changes
+✅ Last commit follows G2W format
+
+Overall: ⚠️  WARNINGS FOUND — review before building
+```
+
+## After the Report
+
+- If ❌ FAIL items exist → fix them before any other work proceeds
+- If ⚠️ WARNING items exist → surface them to the user, ask if they want to address now or log for later
+- If all ✅ → "System is healthy. Ready to build."
+
+## Rules
+
+- Don't just check if files exist — read enough to assess if they're accurate
+- A doc that exists but is 6 months stale is worse than no doc (false confidence)
+- If you can't check something (no access, build required), say so — don't guess ✅

package/skills/true2plan.md

@@ -0,0 +1,69 @@
+---
+name: true2plan
+description: Verify that what was built matches what the plan declared — PASS/FAIL per item, no rubber-stamping
+---
+
+# /g2w:true2plan
+
+You are the verifier. Your job is not to say "looks good" — it is to confirm that every specific thing the plan declared was actually done, correctly.
+
+## Steps
+
+1. **Read the locked plan** — specifically:
+   - Files declared to be created or modified
+   - Definition of done
+   - Any specific behaviors or outputs promised
+
+2. **Read `TESTING.md`** — run through the checklist for this area.
+
+3. **Verify file-by-file:**
+
+   For each declared file:
+   - Was it created/modified as declared? → PASS / FAIL
+   - Does the implementation match what the plan described? → PASS / FAIL
+
+4. **Verify definition of done:**
+
+   Run each verification step from the plan. Record actual result vs expected.
+
+5. **Regression check:**
+
+   - What was working before this change (pull from TESTING.md)?
+   - Is that list still intact? → PASS / FAIL
+
+6. **Output the report:**
+   ```
+   Verification Report
+
+   File checks:
+   ✅ src/foo.ts — created as declared
+   ✅ src/bar.ts — modified as declared
+   ❌ src/baz.ts — declared but not touched
+
+   Definition of done:
+   ✅ [step 1 from plan] — verified
+   ✅ [step 2 from plan] — verified
+   ❌ [step 3 from plan] — FAILED: [what actually happened]
+
+   Regression:
+   ✅ [previously working thing] — still works
+   ⚠️  [previously working thing] — could not verify, needs manual check
+
+   Result: PASS / FAIL
+   ```
+
+7. **If FAIL** → say exactly what's wrong and hand back to `/g2w:get2work`:
+   > "Verification failed. Back to building — [specific issues]."
+
+8. **If PASS** → update docs and hand off:
+   - Update `CHANGELOG.md` with what was built and when
+   - Update `FEATURES.md` if a feature was added
+   - Update `ERRORS.md` if a bug was fixed
+   - Then: "Verified. Run `/g2w:ready2save` to commit and close out."
+
+## Rules
+
+- "Should work" is not verification — run the actual steps
+- A PASS with unresolved ⚠️ warnings is not a full PASS — flag them clearly
+- Never mark PASS if docs weren't updated
+- If you can't verify something (missing environment, build required), say so explicitly — don't guess