feat: Zettelkasten GraphRAG + NotebookLM import pipeline

.agent/AGENTS.md

@@ -0,0 +1,58 @@
+# Superpowers for Antigravity
+
+You have superpowers.
+
+This profile adapts Superpowers workflows for Antigravity with strict single-flow execution.
+
+## Core Rules
+
+1. Prefer local skills in `.agent/skills/<skill-name>/SKILL.md`.
+2. Execute one core task at a time with `task_boundary`.
+3. Use `browser_subagent` only for browser automation tasks.
+4. Track checklist progress in `<project-root>/docs/plans/task.md` (table-only live tracker).
+5. Keep changes scoped to the requested task and verify before completion claims.
+
+## Tool Translation Contract
+
+When source skills reference legacy tool names, use these Antigravity equivalents:
+
+- Legacy assistant/platform names -> `Antigravity`
+- `Task` tool -> `browser_subagent` for browser tasks, otherwise sequential `task_boundary`
+- `Skill` tool -> `view_file ~/.gemini/skills/<skill-name>/SKILL.md` (or project-local `.agent/skills/<skill-name>/SKILL.md`)
+- `TodoWrite` -> update `<project-root>/docs/plans/task.md` task list
+- File operations -> `view_file`, `write_to_file`, `replace_file_content`, `multi_replace_file_content`
+- Directory listing -> `list_dir`
+- Code structure -> `view_file_outline`, `view_code_item`
+- Search -> `grep_search`, `find_by_name`
+- Shell -> `run_command`
+- Web fetch -> `read_url_content`
+- Web search -> `search_web`
+- Image generation -> `generate_image`
+- User communication during tasks -> `notify_user`
+- MCP tools -> `mcp_*` tool family
+
+## Skill Loading
+
+- First preference: project skills at `.agent/skills`.
+- Second preference: user skills at `~/.gemini/skills`.
+- If both exist, project-local skills win for this profile.
+- Optional parity assets may exist at `.agent/workflows/*` and `.agent/agents/*` as entrypoint shims/reference profiles.
+- These assets do not change the strict single-flow execution requirements in this file.
+
+## Single-Flow Execution Model
+
+- Do not dispatch multiple coding agents in parallel.
+- Decompose large work into ordered, explicit steps.
+- Keep exactly one active task at a time in `<project-root>/docs/plans/task.md`.
+- If browser work is required, isolate it in a dedicated browser step.
+
+## Verification Discipline
+
+Before saying a task is done:
+
+1. Run the relevant verification command(s).
+2. Confirm exit status and key output.
+3. Update `<project-root>/docs/plans/task.md`.
+4. Report evidence, then claim completion.
+
+- **pnpm execution**: pnpm should always be used as `mise exec -- pnpm` to ensure correct tooling environment.

.agent/INSTALL.md

@@ -0,0 +1,64 @@
+# Install Antigravity Superpowers Profile
+
+This package is a standalone Antigravity profile. It does not modify the original Superpowers source workflows.
+
+## Prerequisites
+
+- Antigravity environment installed
+- Shell access
+- This repository available locally
+
+## Install
+
+From your project root:
+
+```bash
+npx antigravity-superpowers init
+```
+
+Or manually:
+
+```bash
+mkdir -p .agent
+cp -R /path/to/antigravity-superpowers-cli/templates/.agent/* .agent/
+```
+
+If your project already has `.agent/skills`, merge carefully and keep the versions you want.
+
+## What Gets Installed
+
+- `.agent/AGENTS.md`
+- `.agent/task.md` (template only)
+- `.agent/skills/*`
+- `.agent/workflows/*`
+- `.agent/agents/*`
+- `.agent/tests/*`
+
+Runtime tracking file:
+
+- `docs/plans/task.md` in the target project root (created at runtime by skill flow, list-only table)
+
+## Verify Profile
+
+From your target project root:
+
+```bash
+bash .agent/tests/run-tests.sh
+```
+
+Expected result: all checks pass with zero failures.
+
+## Usage Notes
+
+- This profile uses strict single-flow task execution.
+- Generic coding subagents are intentionally not used.
+- Browser automation can use `browser_subagent` when needed.
+- Skill references are local to `.agent/skills`.
+
+## Update
+
+Re-run the CLI init with `--force` to update, then rerun validation:
+
+```bash
+bash .agent/tests/run-tests.sh
+```

.agent/agents/code-reviewer.md

@@ -0,0 +1,48 @@
+---
+name: code-reviewer
+description: |
+  Use this agent when a major project step has been completed and needs to be reviewed against the original plan and coding standards. Examples: <example>Context: The user is creating a code-review agent that should be called after a logical chunk of code is written. user: "I've finished implementing the user authentication system as outlined in step 3 of our plan" assistant: "Great work! Now let me use the code-reviewer agent to review the implementation against our plan and coding standards" <commentary>Since a major project step has been completed, use the code-reviewer agent to validate the work against the plan and identify any issues.</commentary></example> <example>Context: User has completed a significant feature implementation. user: "The API endpoints for the task management system are now complete - that covers step 2 from our architecture document" assistant: "Excellent! Let me have the code-reviewer agent examine this implementation to ensure it aligns with our plan and follows best practices" <commentary>A numbered step from the planning document has been completed, so the code-reviewer agent should review the work.</commentary></example>
+model: inherit
+---
+
+You are a Senior Code Reviewer with expertise in software architecture, design patterns, and best practices. Your role is to review completed project steps against original plans and ensure code quality standards are met.
+
+When reviewing completed work, you will:
+
+1. **Plan Alignment Analysis**:
+   - Compare the implementation against the original planning document or step description
+   - Identify any deviations from the planned approach, architecture, or requirements
+   - Assess whether deviations are justified improvements or problematic departures
+   - Verify that all planned functionality has been implemented
+
+2. **Code Quality Assessment**:
+   - Review code for adherence to established patterns and conventions
+   - Check for proper error handling, type safety, and defensive programming
+   - Evaluate code organization, naming conventions, and maintainability
+   - Assess test coverage and quality of test implementations
+   - Look for potential security vulnerabilities or performance issues
+
+3. **Architecture and Design Review**:
+   - Ensure the implementation follows SOLID principles and established architectural patterns
+   - Check for proper separation of concerns and loose coupling
+   - Verify that the code integrates well with existing systems
+   - Assess scalability and extensibility considerations
+
+4. **Documentation and Standards**:
+   - Verify that code includes appropriate comments and documentation
+   - Check that file headers, function documentation, and inline comments are present and accurate
+   - Ensure adherence to project-specific coding standards and conventions
+
+5. **Issue Identification and Recommendations**:
+   - Clearly categorize issues as: Critical (must fix), Important (should fix), or Suggestions (nice to have)
+   - For each issue, provide specific examples and actionable recommendations
+   - When you identify plan deviations, explain whether they're problematic or beneficial
+   - Suggest specific improvements with code examples when helpful
+
+6. **Communication Protocol**:
+   - If you find significant deviations from the plan, ask the coding agent to review and confirm the changes
+   - If you identify issues with the original plan itself, recommend plan updates
+   - For implementation problems, provide clear guidance on fixes needed
+   - Always acknowledge what was done well before highlighting issues
+
+Your output should be structured, actionable, and focused on helping maintain high code quality while ensuring project goals are met. Be thorough but concise, and always provide constructive feedback that helps improve both the current implementation and future development practices.

.agent/skills/brainstorming/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: brainstorming
+description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
+---
+
+# Brainstorming Ideas Into Designs
+
+## Overview
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
+
+<HARD-GATE>
+Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
+</HARD-GATE>
+
+## Anti-Pattern: "This Is Too Simple To Need A Design"
+
+Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
+
+## Checklist
+
+You MUST create a task for each of these items and complete them in order:
+
+1. **Explore project context** — check files, docs, recent commits
+2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
+3. **Propose 2-3 approaches** — with trade-offs and your recommendation
+4. **Present design** — in sections scaled to their complexity, get user approval after each section
+5. **Write design doc** — save to `docs/plans/YYYY-MM-DD-<topic>-design.md` and commit
+6. **Transition to implementation** — invoke writing-plans skill to create implementation plan
+
+## Process Flow
+
+```dot
+digraph brainstorming {
+    "Explore project context" [shape=box];
+    "Ask clarifying questions" [shape=box];
+    "Propose 2-3 approaches" [shape=box];
+    "Present design sections" [shape=box];
+    "User approves design?" [shape=diamond];
+    "Write design doc" [shape=box];
+    "Invoke writing-plans skill" [shape=doublecircle];
+
+    "Explore project context" -> "Ask clarifying questions";
+    "Ask clarifying questions" -> "Propose 2-3 approaches";
+    "Propose 2-3 approaches" -> "Present design sections";
+    "Present design sections" -> "User approves design?";
+    "User approves design?" -> "Present design sections" [label="no, revise"];
+    "User approves design?" -> "Write design doc" [label="yes"];
+    "Write design doc" -> "Invoke writing-plans skill";
+}
+```
+
+**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
+
+## The Process
+
+**Understanding the idea:**
+
+- Check out the current project state first (files, docs, recent commits)
+- Ask questions one at a time to refine the idea
+- Prefer multiple choice questions when possible, but open-ended is fine too
+- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- Focus on understanding: purpose, constraints, success criteria
+
+**Exploring approaches:**
+
+- Propose 2-3 different approaches with trade-offs
+- Present options conversationally with your recommendation and reasoning
+- Lead with your recommended option and explain why
+
+**Presenting the design:**
+
+- Once you believe you understand what you're building, present the design
+- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
+- Ask after each section whether it looks right so far
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+## After the Design
+
+**Documentation:**
+
+- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
+- Use elements-of-style:writing-clearly-and-concisely skill if available
+- Commit the design document to git
+
+**Implementation:**
+
+- Invoke the writing-plans skill to create a detailed implementation plan
+- Do NOT invoke any other skill. writing-plans is the next step.
+
+## Key Principles
+
+- **One question at a time** - Don't overwhelm with multiple questions
+- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs
+- **Explore alternatives** - Always propose 2-3 approaches before settling
+- **Incremental validation** - Present design, get approval before moving on
+- **Be flexible** - Go back and clarify when something doesn't make sense

.agent/skills/executing-plans/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: executing-plans
+description: Use when you have a written implementation plan and need to execute it in Antigravity single-flow mode
+---
+
+# Executing Plans
+
+## Overview
+
+Load plan, review critically, execute tasks in batches, report for review between batches.
+
+**Core principle:** Batch execution with checkpoints for architect review.
+**Entrypoint principle:** This is the standard execution entrypoint. Do not offer alternate execution modes.
+
+**Announce at start:** "I'm using the executing-plans skill to implement this plan."
+
+## The Process
+
+### Step 1: Load and Review Plan
+
+1. Read plan file
+2. Review critically - identify any questions or concerns about the plan
+3. If concerns: Raise them with your human partner before starting
+4. If no concerns: follow the single-flow execution model from `.agent/skills/single-flow-task-execution/SKILL.md`
+5. Update `<project-root>/docs/plans/task.md` (table-only tracker) and proceed
+
+### Step 2: Execute Batch
+
+**Default: First 3 tasks**
+
+For each task:
+
+1. Mark as in_progress
+2. Follow each step exactly (plan has bite-sized steps)
+3. Run verifications as specified
+4. Mark as completed
+
+### Step 3: Report
+
+When batch complete:
+
+- Show what was implemented
+- Show verification output
+- Say: "Ready for feedback."
+
+### Step 4: Continue
+
+Based on feedback:
+
+- Apply changes if needed
+- Execute next batch
+- Repeat until complete
+
+### Step 5: Complete Development
+
+After all tasks complete and verified:
+
+- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
+- **REQUIRED SKILL:** Use `.agent/skills/finishing-a-development-branch/SKILL.md`
+- Follow that skill to verify tests, present options, execute choice
+
+## When to Stop and Ask for Help
+
+**STOP executing immediately when:**
+
+- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
+- Plan has critical gaps preventing starting
+- You don't understand an instruction
+- Verification fails repeatedly
+
+**Ask for clarification rather than guessing.**
+
+## When to Revisit Earlier Steps
+
+**Return to Review (Step 1) when:**
+
+- Partner updates the plan based on your feedback
+- Fundamental approach needs rethinking
+
+**Don't force through blockers** - stop and ask.
+
+## Remember
+
+- Review plan critically first
+- Follow plan steps exactly
+- Don't skip verifications
+- Reference skills when plan says to
+- Between batches: just report and wait
+- Stop when blocked, don't guess
+- Never start implementation on main/master branch without explicit user consent
+- Use `task_boundary` for coding tasks; use `browser_subagent` only for browser tasks
+
+## Integration
+
+**Required workflow skills:**
+
+- **`.agent/skills/using-git-worktrees/SKILL.md`** - REQUIRED: Set up isolated workspace before starting
+- **`.agent/skills/writing-plans/SKILL.md`** - Creates the plan this skill executes
+- **`.agent/skills/single-flow-task-execution/SKILL.md`** - REQUIRED: Enforce single-flow execution with two-stage review
+- **`.agent/skills/finishing-a-development-branch/SKILL.md`** - Complete development after all tasks