@leejungkiin/awkit 1.1.2 → 1.1.4

package/skill-packs/superpowers/skills/requesting-code-review/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: requesting-code-review
+description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
+---
+
+# Requesting Code Review
+
+Run a structured review pass to catch issues before they cascade.
+
+**Core principle:** Review early, review often.
+
+## When to Request Review
+
+**Mandatory:**
+
+- After each task in single-flow task execution
+- After completing major feature
+- Before merge to main
+
+**Optional but valuable:**
+
+- When stuck (fresh perspective)
+- Before refactoring (baseline check)
+- After fixing complex bug
+
+## How to Request
+
+**1. Get git SHAs:**
+
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Run structured code review checklist:**
+
+Use `requesting-code-review/code-reviewer.md` template and review the diff against requirements. In Antigravity single-flow mode, do not dispatch generic coding agents.
+
+**Placeholders:**
+
+- `{WHAT_WAS_IMPLEMENTED}` - What you just built
+- `{PLAN_OR_REQUIREMENTS}` - What it should do
+- `{BASE_SHA}` - Starting commit
+- `{HEAD_SHA}` - Ending commit
+- `{DESCRIPTION}` - Brief summary
+
+**3. Act on feedback:**
+
+- Fix Critical issues immediately
+- Fix Important issues before proceeding
+- Note Minor issues for later
+- Push back if reviewer is wrong (with reasoning)
+
+## Example
+
+```
+[Just completed Task 2: Add verification function]
+
+You: Let me request code review before proceeding.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Run checklist-based review]
+  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
+  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+
+[Review returns]:
+  Strengths: Clean architecture, real tests
+  Issues:
+    Important: Missing progress indicators
+    Minor: Magic number (100) for reporting interval
+  Assessment: Ready to proceed
+
+You: [Fix progress indicators]
+[Continue to Task 3]
+```
+
+## Integration with Workflows
+
+**Single-Flow Task Execution:**
+
+- Review after EACH task
+- Catch issues before they compound
+- Fix before moving to next task
+
+**Executing Plans:**
+
+- Review after each batch (3 tasks)
+- Get feedback, apply, continue
+
+**Ad-Hoc Development:**
+
+- Review before merge
+- Review when stuck
+
+## Red Flags
+
+**Never:**
+
+- Skip review because "it's simple"
+- Ignore Critical issues
+- Proceed with unfixed Important issues
+- Argue with valid technical feedback
+
+**If reviewer wrong:**
+
+- Push back with technical reasoning
+- Show code/tests that prove it works
+- Request clarification
+
+See template at: requesting-code-review/code-reviewer.md

package/skill-packs/superpowers/skills/requesting-code-review/code-reviewer.md

@@ -0,0 +1,146 @@
+# Code Review Agent
+
+You are reviewing code changes for production readiness.
+
+**Your task:**
+1. Review {WHAT_WAS_IMPLEMENTED}
+2. Compare against {PLAN_OR_REQUIREMENTS}
+3. Check code quality, architecture, testing
+4. Categorize issues by severity
+5. Assess production readiness
+
+## What Was Implemented
+
+{DESCRIPTION}
+
+## Requirements/Plan
+
+{PLAN_REFERENCE}
+
+## Git Range to Review
+
+**Base:** {BASE_SHA}
+**Head:** {HEAD_SHA}
+
+```bash
+git diff --stat {BASE_SHA}..{HEAD_SHA}
+git diff {BASE_SHA}..{HEAD_SHA}
+```
+
+## Review Checklist
+
+**Code Quality:**
+- Clean separation of concerns?
+- Proper error handling?
+- Type safety (if applicable)?
+- DRY principle followed?
+- Edge cases handled?
+
+**Architecture:**
+- Sound design decisions?
+- Scalability considerations?
+- Performance implications?
+- Security concerns?
+
+**Testing:**
+- Tests actually test logic (not mocks)?
+- Edge cases covered?
+- Integration tests where needed?
+- All tests passing?
+
+**Requirements:**
+- All plan requirements met?
+- Implementation matches spec?
+- No scope creep?
+- Breaking changes documented?
+
+**Production Readiness:**
+- Migration strategy (if schema changes)?
+- Backward compatibility considered?
+- Documentation complete?
+- No obvious bugs?
+
+## Output Format
+
+### Strengths
+[What's well done? Be specific.]
+
+### Issues
+
+#### Critical (Must Fix)
+[Bugs, security issues, data loss risks, broken functionality]
+
+#### Important (Should Fix)
+[Architecture problems, missing features, poor error handling, test gaps]
+
+#### Minor (Nice to Have)
+[Code style, optimization opportunities, documentation improvements]
+
+**For each issue:**
+- File:line reference
+- What's wrong
+- Why it matters
+- How to fix (if not obvious)
+
+### Recommendations
+[Improvements for code quality, architecture, or process]
+
+### Assessment
+
+**Ready to merge?** [Yes/No/With fixes]
+
+**Reasoning:** [Technical assessment in 1-2 sentences]
+
+## Critical Rules
+
+**DO:**
+- Categorize by actual severity (not everything is Critical)
+- Be specific (file:line, not vague)
+- Explain WHY issues matter
+- Acknowledge strengths
+- Give clear verdict
+
+**DON'T:**
+- Say "looks good" without checking
+- Mark nitpicks as Critical
+- Give feedback on code you didn't review
+- Be vague ("improve error handling")
+- Avoid giving a clear verdict
+
+## Example Output
+
+```
+### Strengths
+- Clean database schema with proper migrations (db.ts:15-42)
+- Comprehensive test coverage (18 tests, all edge cases)
+- Good error handling with fallbacks (summarizer.ts:85-92)
+
+### Issues
+
+#### Important
+1. **Missing help text in CLI wrapper**
+   - File: index-conversations:1-31
+   - Issue: No --help flag, users won't discover --concurrency
+   - Fix: Add --help case with usage examples
+
+2. **Date validation missing**
+   - File: search.ts:25-27
+   - Issue: Invalid dates silently return no results
+   - Fix: Validate ISO format, throw error with example
+
+#### Minor
+1. **Progress indicators**
+   - File: indexer.ts:130
+   - Issue: No "X of Y" counter for long operations
+   - Impact: Users don't know how long to wait
+
+### Recommendations
+- Add progress reporting for user experience
+- Consider config file for excluded projects (portability)
+
+### Assessment
+
+**Ready to merge: With fixes**
+
+**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
+```

package/skill-packs/superpowers/skills/single-flow-task-execution/SKILL.md

@@ -0,0 +1,359 @@
+---
+name: single-flow-task-execution
+description: Use when executing implementation plans, handling multiple independent tasks, or doing structured task-by-task development with review gates in Antigravity.
+---
+
+# Single-Flow Task Execution
+
+Execute plans by working through one task at a time with two-stage review after each: spec compliance review first, then code quality review.
+
+**Core principle:** One task at a time + two-stage review (spec then quality) = high quality, disciplined iteration.
+
+## Antigravity Execution Model
+
+Antigravity does NOT support parallel coding subagents. All work happens in a single execution thread.
+
+**Rules:**
+
+1. **One active task only** — never work on multiple tasks simultaneously.
+2. **One execution thread only** — no parallel dispatch.
+3. **No parallel coding subagents** — Antigravity does not have `Task(...)`.
+4. **Browser automation** may use `browser_subagent` in isolated steps.
+5. **Track progress** via Symphony task system. Update task status at each state change.
+6. **Use `task_boundary`** to clearly delineate each unit of work.
+
+## When to Use
+
+```dot
+digraph when_to_use {
+    "Have implementation plan?" [shape=diamond];
+    "Tasks mostly independent?" [shape=diamond];
+    "Multiple problems to solve?" [shape=diamond];
+    "single-flow-task-execution" [shape=box];
+    "executing-plans" [shape=box];
+    "Manual execution or brainstorm first" [shape=box];
+
+    "Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];
+    "Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];
+    "Tasks mostly independent?" -> "single-flow-task-execution" [label="yes"];
+    "Tasks mostly independent?" -> "Manual execution or brainstorm first" [label="no - tightly coupled"];
+    "Multiple problems to solve?" -> "single-flow-task-execution" [label="yes - work through them sequentially"];
+    "Multiple problems to solve?" -> "Manual execution or brainstorm first" [label="no - single task"];
+}
+```
+
+**Use when:**
+
+- You have an implementation plan with multiple independent tasks
+- 2+ test files failing with different root causes (work through them one at a time)
+- Multiple subsystems broken independently
+- Each problem can be understood without context from others
+- Structured execution with quality gates is needed
+
+**Don't use when:**
+
+- Failures are related (fix one might fix others) — investigate together first
+- Tasks are tightly coupled and need full system understanding
+- Single simple task that doesn't need review structure
+
+**vs. Executing Plans (worktree-based):**
+
+- Same session (no context switch)
+- Fresh `task_boundary` per task (clean scope)
+- Two-stage review after each task: spec compliance first, then code quality
+- Faster iteration (no human-in-loop between tasks)
+
+## The Process
+
+```dot
+digraph process {
+    rankdir=TB;
+
+    subgraph cluster_per_task {
+        label="Per Task";
+        "Execute implementation (./implementer-prompt.md)" [shape=box];
+        "Questions about requirements?" [shape=diamond];
+        "Answer questions, provide context" [shape=box];
+        "Implement, test, commit, self-review" [shape=box];
+        "Run spec compliance review (./spec-reviewer-prompt.md)" [shape=box];
+        "Spec confirms code matches spec?" [shape=diamond];
+        "Fix spec gaps" [shape=box];
+        "Run code quality review (./code-quality-reviewer-prompt.md)" [shape=box];
+        "Code quality approved?" [shape=diamond];
+        "Fix quality issues" [shape=box];
+        "Mark task complete via Symphony" [shape=box];
+    }
+
+    "Read plan, extract all tasks with full text, note context" [shape=box];
+    "More tasks remain?" [shape=diamond];
+    "Run final code review for entire implementation" [shape=box];
+    "Complete Symphony task and present next steps" [shape=box style=filled fillcolor=lightgreen];
+
+    "Read plan, extract all tasks with full text, note context" -> "Execute implementation (./implementer-prompt.md)";
+    "Execute implementation (./implementer-prompt.md)" -> "Questions about requirements?";
+    "Questions about requirements?" -> "Answer questions, provide context" [label="yes"];
+    "Answer questions, provide context" -> "Execute implementation (./implementer-prompt.md)";
+    "Questions about requirements?" -> "Implement, test, commit, self-review" [label="no"];
+    "Implement, test, commit, self-review" -> "Run spec compliance review (./spec-reviewer-prompt.md)";
+    "Run spec compliance review (./spec-reviewer-prompt.md)" -> "Spec confirms code matches spec?";
+    "Spec confirms code matches spec?" -> "Fix spec gaps" [label="no"];
+    "Fix spec gaps" -> "Run spec compliance review (./spec-reviewer-prompt.md)" [label="re-review"];
+    "Spec confirms code matches spec?" -> "Run code quality review (./code-quality-reviewer-prompt.md)" [label="yes"];
+    "Run code quality review (./code-quality-reviewer-prompt.md)" -> "Code quality approved?";
+    "Code quality approved?" -> "Fix quality issues" [label="no"];
+    "Fix quality issues" -> "Run code quality review (./code-quality-reviewer-prompt.md)" [label="re-review"];
+    "Code quality approved?" -> "Mark task complete via Symphony" [label="yes"];
+    "Mark task complete via Symphony" -> "More tasks remain?";
+    "More tasks remain?" -> "Execute implementation (./implementer-prompt.md)" [label="yes"];
+    "More tasks remain?" -> "Run final code review for entire implementation" [label="no"];
+    "Run final code review for entire implementation" -> "Complete Symphony task and present next steps";
+}
+```
+
+## Task Decomposition
+
+When facing multiple problems (e.g., 5 test failures across 3 files):
+
+### 1. Identify Independent Domains
+
+Group failures by what's broken:
+
+- File A tests: User authentication flow
+- File B tests: Data validation logic
+- File C tests: API response handling
+
+Each domain is independent — fixing authentication doesn't affect validation tests.
+
+### 2. Create Task Units
+
+Each task gets:
+
+- **Specific scope:** One test file or subsystem
+- **Clear goal:** Make these tests pass / implement this feature
+- **Constraints:** Don't change unrelated code
+- **Expected output:** Summary of what changed and verification results
+
+### 3. Execute Sequentially with Review
+
+Work through each task one at a time using the full review cycle.
+
+### 4. Review and Integrate
+
+After all tasks:
+
+- Run full test suite to verify no regressions
+- Check for conflicts between task changes
+- Run final code review on entire implementation
+
+## Task Brief Structure
+
+For each task, prepare:
+
+```
+task_boundary:
+  description: "Implement Task N: [task name]"
+  prompt: |
+    ## Task Description
+    [FULL TEXT of task from plan — paste it here]
+
+    ## Context
+    [Where this fits, dependencies, architectural context]
+
+    ## Constraints
+    - Only modify [specific files/directories]
+    - Follow existing patterns in the codebase
+    - Write tests for new functionality
+
+    ## Verification
+    - Run: [specific test command]
+    - Expected: [what success looks like]
+```
+
+**Key:** Provide full task text and context upfront. Don't make the task boundary re-read the plan file.
+
+## Review Templates
+
+This skill includes prompt templates for structured reviews:
+
+- **`./implementer-prompt.md`** — Template for implementation task boundaries
+- **`./spec-reviewer-prompt.md`** — Template for spec compliance review (did we build what was requested?)
+- **`./code-quality-reviewer-prompt.md`** — Template for code quality review (is it well-built?)
+
+**Review order matters:** Always run spec compliance FIRST, then code quality. There's no point reviewing code quality if the implementation doesn't match the spec.
+
+## Checkpoint Pattern
+
+At logical boundaries (after each task, at major milestones), report:
+
+- **What changed** — files modified, features implemented
+- **What verification ran** — test results, lint results
+- **What remains** — remaining tasks, known issues
+
+Update Symphony task progress with current status.
+
+## Common Mistakes
+
+**Task scoping:**
+
+- **Bad:** "Fix all the tests" — loses focus
+- **Good:** "Fix user-auth.test.ts failures" — clear scope
+
+**Context:**
+
+- **Bad:** "Fix the validation bug" — unclear where
+- **Good:** Paste error messages, test names, relevant code paths
+
+**Constraints:**
+
+- **Bad:** No constraints — task might refactor everything
+- **Good:** "Only modify src/auth/ directory"
+
+**Output:**
+
+- **Bad:** "Fix it" — no visibility into what changed
+- **Good:** "Report: root cause, changes made, test results"
+
+**Reviews:**
+
+- **Bad:** "It works, move on" — quality debt
+- **Good:** Implement then spec review then quality review then next task
+
+## Example Workflow
+
+```
+You: I'm using single-flow-task-execution to execute this plan.
+
+[Read plan file: docs/plans/feature-plan.md]
+[Extract all 5 tasks with full text and context]
+[Create Symphony tasks for tracking]
+
+--- Task 1: Hook installation script ---
+
+[Prepare task brief with full text + context]
+[Execute implementation following ./implementer-prompt.md structure]
+
+Questions: "Should the hook be installed at user or system level?"
+Answer: "User level (~/.config/superpowers/hooks/)"
+
+Implementation:
+  - Implemented install-hook command
+  - Added tests, 5/5 passing
+  - Self-review: Found I missed --force flag, added it
+  - Committed
+
+[Run spec compliance review following ./spec-reviewer-prompt.md]
+Spec review: Spec compliant — all requirements met, nothing extra
+
+[Run code quality review following ./code-quality-reviewer-prompt.md]
+Code review: Strengths: Good test coverage, clean. Issues: None. Approved.
+
+[Mark Task 1 complete in Symphony]
+
+--- Task 2: Recovery modes ---
+
+[Prepare task brief with full text + context]
+[Execute implementation]
+
+Implementation:
+  - Added verify/repair modes
+  - 8/8 tests passing
+  - Self-review: All good
+  - Committed
+
+[Run spec compliance review]
+Spec review: Issues found:
+  - Missing: Progress reporting (spec says "report every 100 items")
+  - Extra: Added --json flag (not requested)
+
+[Fix issues: remove --json flag, add progress reporting]
+[Run spec compliance review again]
+Spec review: Spec compliant now
+
+[Run code quality review]
+Code review: Issue (Important): Magic number (100) should be a constant
+
+[Fix: extract PROGRESS_INTERVAL constant]
+[Run code quality review again]
+Code review: Approved
+
+[Mark Task 2 complete in Symphony]
+
+... [Continue through remaining tasks] ...
+
+[After all tasks complete]
+[Run final code review on entire implementation]
+Final review: All requirements met, ready to merge
+
+[Complete Symphony task and present next steps]
+Done!
+```
+
+## Red Flags
+
+**Never:**
+
+- Start implementation on main/master branch without explicit user consent
+- Skip reviews (spec compliance OR code quality)
+- Proceed with unfixed review issues
+- Work on multiple tasks simultaneously
+- Skip scene-setting context (task needs to understand where it fits)
+- Accept "close enough" on spec compliance (reviewer found issues = not done)
+- Skip review loops (reviewer found issues = fix = review again)
+- Let self-review replace actual review (both are needed)
+- **Start code quality review before spec compliance passes** (wrong order)
+- Move to next task while either review has open issues
+
+**If you have questions about requirements:**
+
+- Ask clearly and wait for answers
+- Don't guess or make assumptions
+- Better to ask upfront than rework later
+
+**If reviewer finds issues:**
+
+- Fix them
+- Run reviewer again
+- Repeat until approved
+- Don't skip the re-review
+
+## Completion
+
+Before claiming all work is done:
+
+1. Ensure all Symphony tasks are marked `done` or `cancelled`
+2. Run full test/validation command
+3. Verify no regressions across all tasks
+4. Summarize evidence (test output, review approvals)
+
+## Advantages
+
+**Structured execution:**
+
+- Clear task boundaries prevent scope creep
+- Review gates catch issues early (cheaper than debugging later)
+- Progress tracking provides visibility
+
+**Quality gates:**
+
+- Self-review catches obvious issues before handoff
+- Two-stage review: spec compliance prevents over/under-building, code quality ensures maintainability
+- Review loops ensure fixes actually work
+
+**Efficiency:**
+
+- Provide full task text upfront (no re-reading plan files)
+- Controller curates exactly what context is needed
+- Questions surfaced before work begins (not after)
+- Sequential execution avoids conflicts between tasks
+
+## Integration
+
+**Required workflow skills:**
+
+- **`~/.gemini/antigravity/skills/symphony-orchestrator/SKILL.md`** — Task tracking and lifecycle
+- **`~/.gemini/antigravity/skills/symphony-enforcer/SKILL.md`** — Enforce task discipline
+
+**Should also use:**
+
+- **test-driven-development** — Follow TDD for each task
+- **verification-before-completion** — Final verification checklist

package/skill-packs/superpowers/skills/single-flow-task-execution/code-quality-reviewer-prompt.md

@@ -0,0 +1,20 @@
+# Code Quality Reviewer Prompt Template
+
+Use this template when running a code quality review step in single-flow mode.
+
+**Purpose:** Verify implementation is well-built (clean, tested, maintainable)
+
+**Only proceed after spec compliance review passes.**
+
+```
+task_boundary:
+  Use template at requesting-code-review/code-reviewer.md
+
+  WHAT_WAS_IMPLEMENTED: [from implementer's report]
+  PLAN_OR_REQUIREMENTS: Task N from [plan-file]
+  BASE_SHA: [commit before task]
+  HEAD_SHA: [current commit]
+  DESCRIPTION: [task summary]
+```
+
+**Code reviewer returns:** Strengths, Issues (Critical/Important/Minor), Assessment