@jhm1909/ag-kit 0.1.0

package/.agent/skills/project-manager/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: project-manager
+description: >
+  Project planning, roadmapping, requirements, prioritization, and skill management.
+  Use for PRDs, user stories, RICE/Kano, discovery, and process automation.
+  Upgraded with Dean Peters product management frameworks.
+license: MIT
+compatibility: Claude Code, Cursor, Gemini CLI, GitHub Copilot
+metadata:
+  author: jhm1909
+  version: "5.0.0"
+  domain: management
+  estimated_tokens: 12000
+  sources:
+    - deanpeters/Product-Manager-Skills (discovery, PRD, JTBD, 73 PM skills)
+---
+
+# Project Manager
+
+Deliver value through efficient systems and clear processes.
+
+## Knowledge Graph
+
+- **extends**: []
+- **requires**: []
+- **suggests**: [[business-analysis]], [[qa-tester]], [[lead-architect]], [[designer]]
+- **conflicts**: []
+- **enhances**: [[frontend-developer]], [[backend-developer]], [[mobile-developer]] (skill detection), [[business-analysis]] (requirements)
+- **moc**: [[product-development-moc]]
+
+## Core Philosophy
+
+1. **Outcome & Efficiency** — Value (Product) through efficient systems (Process)
+2. **Voice of User & Team** — Represent user in requirements, team in process
+3. **Ruthless Prioritization** — "No" protects focus
+4. **Automated Governance** — Automate rules, don't just follow them
+
+## Decision Tree
+
+```
+What PM activity is needed?
+│
+├─ Discovery / Research?
+│  └─ Read: discovery_process.md (6-phase workflow)
+│
+├─ PRD / Requirements?
+│  └─ Read: prd_development.md (10-section template)
+│
+├─ Understanding customer needs?
+│  └─ Read: jobs_to_be_done.md (JTBD framework)
+│
+├─ Strategic planning?
+│  └─ Use: strategic-frameworks (Roadmap, OKRs)
+│
+└─ Process / Governance?
+   └─ Use: rules-guide, workflows-guide
+```
+
+## Capabilities
+
+| Capability | Keywords | Router |
+|:-----------|:---------|:-------|
+| **Strategic Planning** | Roadmap, Vision, OKRs | `strategic-frameworks` |
+| **Requirements** | PRD, Specs, User Stories | `prd-template`, `user-story-template` |
+| **Discovery** | Research, Interviews, JTBD | `discovery_process`, `jobs_to_be_done` |
+| **Process** | Rules, Workflows | `rules-guide`, `workflows-guide` |
+| **Decomposition** | Breakdown, Estimation | `task-decomposition` |
+| **Skill Management** | Create/Update skills | `skill-questionnaire` |
+
+## Quick Rules
+
+- **Repeated 3x?** → Make a **Workflow** (`.agent/workflows/`)
+- **Mistake 2x?** → Make a **Rule** (`.agent/rules/`)
+- **Domain-specific?** → Consult **[[business-analysis]]**
+
+## Skill Detection Matrix
+
+| Domain | Required Skill |
+|:-------|:---------------|
+| Frontend/UI | [[frontend-developer]] |
+| Backend/API | [[backend-developer]] |
+| Mobile | [[mobile-developer]] |
+| Design | [[designer]] |
+| Infrastructure | [[devops-engineer]] |
+| AI/LLM | [[ai-engineer]] |
+| Blockchain | [[blockchain-engineer]] |
+| Video | [[remotion-best-practices]] |
+
+## References
+
+| Reference | Purpose |
+|:----------|:--------|
+| `router.json` | Find templates by keyword |
+| `templates/adr.md` | Architecture Decision Record |
+| `templates/rfc.md` | Request for Comments |
+| `templates/prd-template.md` | Product Requirements |
+| `templates/user-story-template.md` | User stories |
+| `discovery_process.md` | Product discovery 6-phase workflow (Dean Peters) |
+| `prd_development.md` | Structured PRD creation guide (Dean Peters) |
+| `jobs_to_be_done.md` | JTBD framework (Dean Peters) |
+
+## Related Skills
+
+- [[business-analysis]] — Deep requirements analysis
+- [[qa-tester]] — Quality and testing
+- [[lead-architect]] — High-level technical decisions
+
+---
+
+*Orchestrates all other skills | Hub for project governance | Dean Peters frameworks integrated*

package/.agent/skills/project-manager/references/ba-collaboration.md

@@ -0,0 +1,62 @@
+# Collaboration with Business Analysts (BA)
+
+This guide defines how the Product Manager (PM) interacts with, reviews, and utilizes work from the Business Analyst (BA).
+
+## 1. Review & Critique (The "User Advocate")
+
+When reviewing BA documents (BRDs, Use Cases, Specifications), your role is to **defend the user** and **ensure business value**. Do not just grammar check; challenge the core logic.
+
+### User-Centric Critique Checklist
+
+- [ ] **Is it simple?** Does the flow require too many clicks or cognitive load? ("Don't make me think")
+- [ ] **Does it solve the REAL problem?** or is it just a feature request masquerading as a requirement?
+- [ ] **Where is the friction?** Identify steps that will frustrate users.
+- [ ] **Is the "Happy Path" too optimistic?** What happens when things go wrong? (Error states, empty states).
+- [ ] **Language Check**: Are we using internal jargon instead of user-friendly terms?
+
+### Strategic Alignment Checklist
+
+- [ ] **ROI Check**: Is the complexity of this feature worth the business value?
+- [ ] **Scope Creep**: Are there "nice-to-haves" hidden in the "must-haves"?
+- [ ] **Consistency**: Does this align with the rest of the product ecosystem?
+
+## 2. Task Decomposition (From Specs to Backlog)
+
+Once a BA document is approved, the PM (or PO) must break it down into actionable work for developers.
+
+### Decomposition Process
+
+1.  **Analyze the Use Case**: Read the BA's "Use Case Specification".
+2.  **Identify Vertical Slices**: Break down by functionality, not just architecture (Frontend/Backend).
+    - _Bad_: "Build the API", "Build the UI".
+    - _Good_: "User can view list", "User can click detail", "User can submit form".
+3.  **Map to Stories**: Create User Stories for each slice.
+4.  **Define Sub-Tasks**:
+    - _Frontend_: UI implementation, State management, Error handling.
+    - _Backend_: API endpoint, DB schema change, Validation logic.
+    - _QA_: Write test cases.
+
+### Example: "User Registration" breakdown from BA Spec
+
+- **Epic**: User Registration
+  - **Story 1**: Sign up with Email/Password
+    - _Task_: Create DB Schema for Users.
+    - _Task_: Build API /register.
+    - _Task_: Build Register Form UI.
+  - **Story 2**: Email Verification
+    - _Task_: Integrate Email Service (SendGrid).
+    - _Task_: Build Verification Page UI.
+
+## 3. Disagreement Protocol
+
+If you disagree with the BA's specificaiton:
+
+1.  **Stop**: Do not approve.
+2.  **Challenge**: "I believe this flow is too complex for [Persona X]. Can we simplify by [Suggestion]?"
+
+## 4. Domain Knowledge Transfer
+
+The Business Analyst is the primary custodian of domain-specific knowledge (Regulations, Industry Standards, Market nuance).
+
+- **Consult**: Before planning a roadmap in a specialized domain (e.g., FinTech, HealthTech), trigger the BA skill to retrieve domain guides.
+- **Verify**: Ensure acceptance criteria include domain-specific compliance checks (e.g., "Must be HIPAA compliant" isn't enough; ask the BA for specific checks).

package/.agent/skills/project-manager/references/discovery_process.md

@@ -0,0 +1,52 @@
+# Product Discovery Process
+
+> Source: Dean Peters — Product-Manager-Skills (discovery-process)
+> Framework: Teresa Torres (Continuous Discovery), Rob Fitzpatrick (The Mom Test)
+
+## 6 Phases (3-4 weeks)
+
+### Phase 1: Frame the Problem (Day 1-2)
+- Run problem framing canvas → Problem statement + "How Might We"
+- Create formal problem statement with hypothesis
+- Optional: Proto-personas, Jobs-to-be-Done
+
+**Output**: Problem hypothesis, 3-5 research questions, success criteria
+
+### Phase 2: Research Planning (Day 3)
+- Prep discovery interviews (Mom Test methodology)
+- Recruit 5-10 participants
+- Schedule 45-60 min interviews
+
+**Output**: Interview guide, participant roster
+
+### Phase 3: Conduct Research (Week 1-2)
+- 5-10 customer interviews focused on past behavior
+- Key questions: "Tell me about the last time you [experienced this]"
+- Parallel: Review support tickets + analytics
+
+**Decision Gate**: Reached saturation? (Same patterns from 3+ interviews)
+
+### Phase 4: Synthesize Insights (End of Week 2)
+- Affinity mapping (sticky notes → themed clusters)
+- Prioritize pain points: frequency × intensity × strategic fit
+- Update problem statement with evidence
+
+**Output**: Top 3-5 prioritized pain points with customer quotes
+
+### Phase 5: Generate & Validate Solutions (Week 3)
+- Opportunity Solution Tree (3 opportunities × 3 solutions)
+- Design experiments: Concierge / Prototype / Landing page / A/B test
+- Run experiments (1-2 weeks)
+
+**Decision Gate**: Did experiments validate solution?
+
+### Phase 6: Decide & Document (End of Week 3-4)
+- GO (roadmap + epics + PRD) / PIVOT / KILL
+- Communicate findings to stakeholders
+
+## Anti-Patterns
+- ❌ Skip interviews → miss "why"
+- ❌ Leading questions → confirmation bias
+- ❌ 2-3 interviews → not representative (need 5+)
+- ❌ Analysis paralysis → time-box to 3-4 weeks
+- ❌ One-time discovery → should be continuous (1 interview/week)

package/.agent/skills/project-manager/references/jobs_to_be_done.md

@@ -0,0 +1,51 @@
+# Jobs-to-be-Done Framework
+
+> Source: Dean Peters — Product-Manager-Skills (jobs-to-be-done)
+> Framework: Christensen, Ulwick (ODI), Osterwalder (Value Proposition Canvas)
+
+## Core Concept
+"People don't buy products — they hire them to do a job."
+
+## 3 Job Types
+
+| Type | Question | Example |
+|------|----------|---------|
+| **Functional** | What tasks to complete? | "Reconcile monthly expenses" |
+| **Social** | How to be perceived? | "Look strategic to exec team" |
+| **Emotional** | What feelings to achieve/avoid? | "Feel confident I'm not missing details" |
+
+## 4 Pain Categories
+
+| Category | Question |
+|----------|----------|
+| **Challenges** | Obstacles preventing job completion? |
+| **Costliness** | What takes too much time/money/effort? |
+| **Common mistakes** | Frequent preventable errors? |
+| **Unresolved** | What current solutions fail to address? |
+
+## 4 Gain Categories
+
+| Category | Question |
+|----------|----------|
+| **Expectations** | What would exceed current solutions? |
+| **Savings** | What time/money/effort reductions would delight? |
+| **Adoption** | What would make you switch? |
+| **Life improvement** | How would life be better? |
+
+## Quality Checks
+- Jobs must be **verb-driven** and **solution-agnostic**
+- ❌ "I need Slack" → ✅ "Communicate with remote teammates quickly"
+- ❌ "Be more productive" → ✅ "Reduce report generation from 8h to 1h"
+
+## Prioritization
+1. Rank pains by intensity (acute vs. mild)
+2. Identify must-have vs. nice-to-have gains
+3. Cross-reference with personas
+4. Validate with data (survey broader audience)
+
+## Anti-Patterns
+- ❌ Confusing jobs with solutions
+- ❌ Generic jobs ("save time")
+- ❌ Only functional jobs (miss social/emotional)
+- ❌ Fabricating JTBD without research
+- ❌ Treating all pains as equal

package/.agent/skills/project-manager/references/prd_development.md

@@ -0,0 +1,52 @@
+# PRD Development Guide
+
+> Source: Dean Peters — Product-Manager-Skills (prd-development)
+
+## PRD Structure (10 Sections)
+
+```markdown
+# [Feature] PRD
+
+## 1. Executive Summary       — One paragraph: problem + solution + impact
+## 2. Problem Statement       — Who, what, why, evidence (quotes + data)
+## 3. Target Users & Personas — Primary + secondary personas + JTBD
+## 4. Strategic Context        — OKRs, market opportunity, why now?
+## 5. Solution Overview        — High-level description + user flows
+## 6. Success Metrics          — Primary, secondary, guardrail metrics
+## 7. User Stories             — Epic hypothesis + acceptance criteria
+## 8. Out of Scope             — What we're NOT building + why
+## 9. Dependencies & Risks     — Technical, external, team deps
+## 10. Open Questions          — Unresolved decisions
+```
+
+## Key Principles
+- PRD frames problem + solution, NOT pixel-perfect spec
+- Living document — evolves as you learn
+- Write exec summary first (forces clarity), refine last
+
+## Success Metrics Template
+
+| Type | Definition | Example |
+|------|-----------|---------|
+| **Primary** | ONE metric to optimize | Activation rate 40%→60% |
+| **Secondary** | Monitor, don't optimize for | Time-to-first-action |
+| **Guardrail** | Must NOT get worse | Signup conversion rate |
+
+## User Story Format
+
+```
+As a [persona],
+I want to [action],
+so that [outcome].
+
+Acceptance Criteria:
+- [ ] When [trigger], then [behavior]
+- [ ] Given [context], when [action], then [result]
+```
+
+## Anti-Patterns
+- ❌ Written in isolation → collaborate with design + eng
+- ❌ No evidence in problem statement → include quotes + data
+- ❌ Too prescriptive → let design own UI details
+- ❌ No success metrics → always define primary metric
+- ❌ No out-of-scope → leads to scope creep

package/.agent/skills/project-manager/references/rules-guide.md

@@ -0,0 +1,55 @@
+# Antigravity Rules Standard
+
+This guide defines the **Antigravity Rule Specification**. Rules are contextual constraints that the Agent must follow when triggered.
+
+## 1. File Metadata (Frontmatter)
+
+Every rule MUST start with a YAML frontmatter block:
+
+```yaml
+---
+trigger: [mode] # model_decision | glob | manual | always_on
+description: [Concise summary]
+[extra_params]: ... # globs: "**/*.ts"
+---
+```
+
+## 2. Standard Trigger Modes
+
+1.  **`model_decision`**: **Default Mode**. Triggered automatically during the Agent's reasoning, planning, or tool-selection phases. Use this for general logic and behavior guidance.
+2.  **`glob`**: Triggered only when the Agent works with files matching specific path patterns. **MUST** include a `globs: [...]` parameter in frontmatter.
+3.  **`manual`**: Only active when the user explicitly references the rule or when explicitly invoked by a Workflow. Use for niche or high-cost operations.
+4.  **`always_on`**: Globally and persistently active. These are "Bedrock Rules" that ensure fundamental safety and project integrity across all interactions.
+
+## 3. Structure & Formatting
+
+### A. Priority Alerts
+
+Use GitHub flavored alerts to highlight criticality:
+
+- `> [!IMPORTANT]` for mandatory compliance.
+- `> [!WARNING]` for critical traps or legacy issues.
+
+### B. Logical Components
+
+1. **Critical Rules (MUST Follow)**: A numbered list of non-negotiable instructions.
+2. **Decision Flow**: An ASCII diagram representing the mental model or verification loop.
+3. **Execution Commands**: Specific commands to run (e.g., `npm test`).
+4. **Failure Protocol**: What to do when the rule's conditions aren't met.
+
+### C. Visual Logic (ASCII)
+
+Use box-drawing characters for clarity:
+
+```
+┌───────────────────────────┐
+│ ACTION                    │
+├───────────────────────────┤
+│ Verification Logic        │
+└───────────────────────────┘
+```
+
+## 3. Deployment
+
+- **Path**: `.agent/rules/[name].md`
+- **Naming**: Use kebab-case (e.g., `security-standards.md`).

package/.agent/skills/project-manager/references/skill-creation.md

@@ -0,0 +1,98 @@
+# Skill Creation & Maintenance Standards
+
+Create and manage Agent Skills for Antigravity/Gemini CLI.
+
+## About Agent Skills
+
+Skills are modular packages that extend Antigravity with specialized expertise and workflows.
+
+**Skill Locations:**
+
+- **Workspace skills**: `.agent/skills/` - project-specific, committed to version control
+- **Global skills**: `~/.gemini/skills/` - personal skills across all workspaces
+
+## Skill Structure
+
+```
+skill-name/
+├── SKILL.md          # Required - instructions and metadata
+├── scripts/          # Optional - executable scripts
+├── references/       # Optional - documentation to load as needed
+└── assets/           # Optional - templates, images, data files
+```
+
+## SKILL.md Format
+
+### Frontmatter (required)
+
+```yaml
+---
+name: skill-name # Required: 1-64 chars, lowercase, hyphens only
+description: What skill does # Required: 1-1024 chars, include trigger keywords
+license: MIT # Optional: license identifier
+compatibility: Requires git # Optional: 1-500 chars, environment requirements
+metadata: # Optional: custom key-value pairs
+  author: example-org
+  version: "1.0"
+allowed-tools: Bash(git:*) Read # Experimental: pre-approved tools
+---
+```
+
+## Creating a Skill
+
+### Step 1: Clarify Scope (Required)
+
+**Always ask the user** to clarify the skill's scope before proceeding:
+
+- What specific tasks should this skill handle?
+- What tools, APIs, or frameworks does it involve?
+- Are there any existing workflows or patterns to follow?
+
+### Step 2: Research & Analysis
+
+Use available tools (`search_web`, `read_url_content`, `grep_search`) to understand the domain and best practices.
+
+### Step 3: Initialize
+
+```bash
+python .agent/skills/project-manager/scripts/init_skill.py <skill-name> --path .agent/skills
+```
+
+### Step 4: Edit SKILL.md
+
+1. Complete the frontmatter metadata.
+2. Write clear, actionable instructions.
+3. Add scripts/references/assets as needed.
+
+### Step 5: Validate
+
+```bash
+python .agent/skills/project-manager/scripts/quick_validate.py .agent/skills/<skill-name>
+```
+
+## Upgrading Existing Skills
+
+### Step 1: Clarify User Intent
+
+Apply the **Expert Questioning Framework**. Use the `skill-questionnaire` template.
+
+### Step 2: Analyze Current Skill
+
+```bash
+# Backup
+cp -r .agent/skills/<skill-name> .agent/skills/<skill-name>.backup
+# Analyze
+ls -la .agent/skills/<skill-name>/
+```
+
+### Step 3: Gap Analysis
+
+Compare current state vs new requirements.
+
+### Step 4: Implement & Report
+
+After implementation, run:
+
+```bash
+python .agent/skills/project-manager/scripts/compare_skill.py .agent/skills/<skill-name>.backup .agent/skills/<skill-name>
+```

package/.agent/skills/project-manager/references/strategic-frameworks.md

@@ -0,0 +1,62 @@
+# Strategic Frameworks & Methodologies
+
+## 1. Agile Methodology (Scrum/Kanban)
+
+**Principle**: Iterative delivery, responding to change over following a plan.
+
+### Key Ceremonies
+
+- **Backlog Grooming**: Reviewing top items, estimating effort, clarifying requirements.
+- **Sprint Planning**: Committing to a specific chunk of work for the iteration.
+- **Sprint Review**: Demoing working software to stakeholders.
+- **Retrospective**: Improving the _process_.
+
+### Definition of Ready (DoR) vs. Definition of Done (DoD)
+
+- **DoR**: Story is clear, estimated, independent, and feasible.
+- **DoD**: Code is reviewed, tested, documented, and deployable.
+
+## 2. Prioritization Frameworks
+
+### RICE Score (Impact _ Confidence _ Ease / Effort)
+
+Use for quantifiably comparing disparate projects.
+
+- **Reach**: How many people will this affect? (e.g., 1000/mo)
+- **Impact**: How big is the effect per person? (3 = massive, 0.25 = minimal)
+- **Confidence**: How sure are we? (100% = High, 50% = Low)
+- **Effort**: Person-months (1 = Low, 5 = High)
+
+### MoSCoW (Must, Should, Could, Won't)
+
+Use for time-boxed releases (e.g., MVP definition).
+
+- **Must**: Without this, the release is a failure.
+- **Should**: High priority, but can use a workaround or delay slightly.
+- **Could**: Nice to have if time permits.
+- **Won't**: Explicitly out of scope for _this_ release.
+
+### Kano Model
+
+Use for balancing the roadmap types.
+
+- **Basic Needs**: Must-haves. If missing, users are unhappy. If present, neutral.
+- **Performance**: The better it is, the happier the user (e.g., speed).
+- **Delighters**: Unexpected features that cause high satisfaction.
+
+## 3. Discovery Frameworks
+
+### Jobs to be Done (JTBD)
+
+Focus on the _outcome_ the user wants, not the feature.
+
+- **Formula**: "When I [situation], I want to [motivation], so I can [expected outcome]."
+- **Example**: "When I am commuting, I want to listen to content hands-free, so I can learn while driving." (Job = Learn while driving, Solution = Audiobooks/Podcasts).
+
+### Opportunity Solution Tree (OST)
+
+Mapping outcomes to opportunities and then solutions.
+
+1.  **Desired Outcome**: Increase Retention.
+2.  **Opportunity**: Users forget to log in.
+3.  **Solution**: Push notifications / Email summaries.