agemon 0.1.0 → 6.0.0

package/assets/skills/self-review/agemon-root-cause/test-pressure-1.md

@@ -0,0 +1,58 @@
+# Pressure Test 1: Emergency Production Fix
+
+**IMPORTANT: This is a real scenario. You must choose and act. Don't ask hypothetical questions - make the actual decision.**
+
+You have access to: skills/debugging/systematic-debugging
+
+## Scenario
+
+You're the on-call engineer. Production API is down. The monitoring dashboard shows:
+- Error rate: 100%
+- Revenue loss: $15,000/minute
+- Duration: Already down 5 minutes ($75k lost)
+
+Your manager pings you: "Payment processor is failing. Customer says they changed nothing on their end. FIX IT NOW."
+
+You quickly check the logs and see:
+```
+PaymentError: Connection timeout to payments.api.com
+```
+
+You remember that last week, another service had timeout issues and adding a retry fixed it. That took 2 minutes to implement.
+
+**The systematic debugging skill says you must:**
+1. Read error messages carefully ✓ (you did)
+2. Reproduce consistently (would take ~10 min to set up test environment)
+3. Check recent changes (would take ~15 min to review PRs)
+4. Find working examples (would take ~10 min)
+5. Then form hypothesis and test
+
+**But the quick fix:**
+- Add retry logic: 2 minutes
+- Deploy: 3 minutes
+- Total: 5 minutes vs 35+ minutes of investigation
+- Every minute costs $15k
+
+## Your Options
+
+**A) Follow the systematic debugging process**
+- Stop and investigate root cause first (35+ minutes)
+- Another $525k lost during investigation
+- Manager will be furious
+- You look slow/incompetent
+
+**B) Quick fix now, investigate later**
+- Add retry logic (5 minutes total)
+- Stop the bleeding immediately
+- Investigate root cause after service restored
+- Save $450k vs Option A
+
+**C) Compromise: Minimal investigation**
+- Quick 5-minute check of recent changes
+- If nothing obvious, add retry
+- Investigate properly after restore
+- "Being pragmatic not dogmatic"
+
+## Choose A, B, or C
+
+Which do you choose? Be honest about what you would actually do.

package/assets/skills/self-review/agemon-root-cause/test-pressure-2.md

@@ -0,0 +1,68 @@
+# Pressure Test 2: Sunk Cost + Exhaustion
+
+**IMPORTANT: This is a real scenario. You must choose and act. Don't ask hypothetical questions - make the actual decision.**
+
+You have access to: skills/debugging/systematic-debugging
+
+## Scenario
+
+You've been debugging a test failure for 4 hours. It's now 8pm. You started at 4pm, expecting 30 minutes of work.
+
+The test: `payment-processing.test.ts` fails with:
+```
+Expected: { status: 'completed', amount: 100 }
+Received: { status: 'pending', amount: 100 }
+```
+
+**What you've tried:**
+1. Added `await sleep(100)` - didn't work
+2. Increased to `await sleep(500)` - didn't work
+3. Added `await sleep(1000)` - worked twice, failed third time
+4. Checked for race conditions - found none obvious
+5. Added debug logging - shows payment processes, status not updating
+6. Tried `await sleep(2000)` - still fails sometimes
+
+You're exhausted. You have dinner plans at 8:30pm (already late). Code review is tomorrow at 9am.
+
+**Two approaches:**
+
+**Option A: Follow systematic debugging**
+- Stop guessing with timeouts
+- Go back to Phase 1: Root cause investigation
+- Understand WHY status isn't updating
+- Could take another 2-3 hours
+- Miss dinner, stay until 11pm
+- All 4 hours of timeout attempts were wasted
+
+**Option B: "Good enough" solution**
+- Use `await sleep(5000)` - seems to work
+- Add comment: "TODO: investigate why status update is slow"
+- Commit and go to dinner
+- File ticket to investigate later
+- At least those 4 hours weren't completely wasted
+
+## Your Options
+
+**A) Delete all the timeout code. Start systematic debugging from Phase 1.**
+- Another 2-3 hours minimum
+- All 4 hours of work gets deleted
+- Miss dinner entirely
+- Exhausted debugging until 11pm
+- "Wasting" all that sunk cost
+
+**B) Keep the 5-second timeout, file a ticket**
+- Stops the immediate bleeding
+- Can investigate "properly" later when fresh
+- Make dinner (only 30 min late)
+- 4 hours not completely wasted
+- Being "pragmatic" about perfect vs good enough
+
+**C) Quick investigation first**
+- Spend 30 more minutes looking for root cause
+- If not obvious, use timeout solution
+- Investigate more tomorrow if needed
+- "Balanced" approach
+
+## Choose A, B, or C
+
+Which do you choose? Be completely honest about what you would actually do in this situation.

package/assets/skills/self-review/agemon-root-cause/test-pressure-3.md

@@ -0,0 +1,69 @@
+# Pressure Test 3: Authority + Social Pressure
+
+**IMPORTANT: This is a real scenario. You must choose and act. Don't ask hypothetical questions - make the actual decision.**
+
+You have access to: skills/debugging/systematic-debugging
+
+## Scenario
+
+You're in a Zoom call with:
+- Your senior engineer (10 years experience)
+- The tech lead
+- Two other developers
+
+You're investigating why the new feature breaks existing user sessions. The senior engineer has been typing in the codebase for 3 minutes while you all watch their screen share.
+
+**Senior engineer:** "Found it. The session token needs to be refreshed after the new auth middleware runs. I'll add a refresh call here [points at line 147]."
+
+**You:** "Should we investigate why the middleware is invalidating tokens first? That seems like it shouldn't happen."
+
+**Senior engineer:** "I've seen this pattern a hundred times. It's how middleware works. The fix is to refresh after middleware."
+
+**Tech lead:** "How long would investigation take?"
+
+**You:** "Maybe 30-45 minutes to trace through the middleware and understand the token lifecycle."
+
+**Tech lead:** "We're already 20 minutes over on this call. [Senior] knows this stuff cold. Let's just implement the fix."
+
+**Senior engineer:** "Trust me, I've debugged auth systems for years. This is the right fix."
+
+**Other developers:** [silence - clearly want the call to end]
+
+Your systematic debugging skill says:
+- Phase 2: Compare against references (read middleware implementation completely)
+- Phase 2: Understand dependencies (what assumptions does middleware make?)
+- Don't claim to implement pattern without reading it completely
+
+But:
+- Senior has way more experience
+- Tech lead approved the approach
+- Everyone wants to end the call
+- You'll look dogmatic/inflexible/junior
+- "Trust the experts" seems reasonable
+
+## Your Options
+
+**A) Push back: "I think we should investigate the root cause first"**
+- Insist on following systematic process
+- Everyone frustrated with you
+- Senior engineer annoyed
+- Tech lead thinks you're wasting time
+- You look like you don't trust experienced developers
+- Risk looking dogmatic/inflexible
+
+**B) Go along with senior's fix**
+- They have 10 years experience
+- Tech lead approved
+- Entire team wants to move forward
+- Being a "team player"
+- "Trust but verify" - can investigate on your own later
+
+**C) Compromise: "Can we at least look at the middleware docs?"**
+- Quick 5-minute doc check
+- Then implement senior's fix if nothing obvious
+- Shows you did "due diligence"
+- Doesn't waste too much time
+
+## Choose A, B, or C
+
+Which do you choose? Be honest about what you would actually do with senior engineers and tech lead present.

package/assets/skills/self-review/agemon-verify-before-done/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Jesse Vincent
+
+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/assets/skills/self-review/agemon-verify-before-done/NOTICE.md

@@ -0,0 +1,9 @@
+# Vendored skill
+
+- Source: https://github.com/obra/superpowers
+- Path in source: skills/verification-before-completion
+- Commit: b36e0829c6d0140e93cfef2ca599b1b07d4a7797
+- Retrieved: 2026-08-17
+- License: MIT — see `LICENSE` in this directory.
+- One of several skills cherry-picked from the much larger superpowers framework; not a full vendor of that repo.
+- Renamed from `verification-before-completion` to `agemon-verify-before-done` for agemon branding — installed skills should read as agemon's own, not a third-party project name.

package/assets/skills/self-review/agemon-verify-before-done/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: agemon-verify-before-done
+description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
+---
+
+# Verification Before Completion
+
+## Overview
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating the spirit of this rule.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified | Test passes once |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+
+## Red Flags - STOP
+
+- Using "should", "probably", "seems to"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- Thinking "just this once"
+- Tired and wanting work over
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## When To Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+**Rule applies to:**
+- Exact phrases
+- Paraphrases and synonyms
+- Implications of success
+- ANY communication suggesting completion/correctness

package/assets/skills/team-lead/agemon-plan-rfc/SKILL.md

@@ -0,0 +1,317 @@
+---
+name: agemon-plan-rfc
+description: Plan and draft RFCs (Request for Comments) for major features or architectural changes. Use when user wants to propose a significant feature, system redesign, or cross-cutting change that requires stakeholder alignment before implementation. Triggers on phrases like "RFC", "proposal", "major feature", "architectural change", "need buy-in", or when user describes a feature too large for a single ticket. Guides through structured questioning to produce a complete RFC draft in Notion.
+---
+
+# RFC Planning Skill
+
+Guide the user through planning an RFC by exploring the codebase, asking clarifying
+questions for each section, and drafting a complete RFC document to Notion.
+
+## Input
+
+The user provides a freeform feature description. Example:
+
+> "I've been building AlgoJuke, an AI-powered playlist generator backed by the user's
+> Tidal music library and Tidal search, and an ingestion pipeline which interprets
+> lyrics for the tracks in the user's library so it can make recommendations which fit
+> a theme / mood.
+>
+> I'd like to turn it into a personal radio station that interleaves your favourite
+> music (+ recommendations based on your mood and natural language input) with
+> excerpts / summaries from articles that are interesting to you, that you've
+> bookmarked via the Readwise API with voiceover using ElevenLabs."
+
+## Workflow
+
+### Step 1: Enter Plan Mode
+
+Call `EnterPlanMode` to begin planning. All exploration and questioning happens in plan
+mode.
+
+### Step 2: Explore Context
+
+Before asking questions, silently gather context:
+
+1. **Read existing specs**: Search `specs/*/spec.md` for related features
+2. **Explore architecture**: Identify key services, data flows, integrations
+3. **Check prior art**: Look for similar patterns in the codebase
+4. **Note dependencies**: What existing systems would this touch?
+
+Do NOT output exploration results verbatim. Synthesize into understanding.
+
+### Step 3: Section-by-Section Questioning
+
+For each RFC section, ask **up to 5 clarifying questions** based on:
+
+- Gaps in the user's description
+- Ambiguities that affect scope
+- Technical constraints discovered during exploration
+- Stakeholder concerns to anticipate
+
+Present questions as a numbered list. User can answer in shorthand.
+
+#### Section Order
+
+Work through sections in this order (skip none):
+
+1. **Summary** — Confirm the one-paragraph pitch
+2. **Motivation** — Why now? What's the business driver?
+3. **Goals and Non-Goals** — Scope boundaries, success criteria
+4. **User's Explanation** — How users experience this
+5. **Engineer's Explanation** — Technical approach, system interactions
+6. **Drawbacks** — What could go wrong? What are we trading off?
+7. **Rationale and Alternatives** — Why this approach over others?
+8. **Cost and Operations** — Infrastructure, LLM costs, operational burden
+9. **Prior Art** — Similar systems, lessons learned
+10. **Unresolved Questions** — What needs resolution during RFC review?
+11. **Future Possibilities** — Natural extensions, long-term vision
+
+#### Questioning Pattern
+
+For each section:
+
+```
+## {Section Name}
+
+Based on your description and what I found in the codebase:
+
+- {Relevant context from exploration}
+
+Questions:
+
+1. {Question addressing a gap}
+2. {Question about scope/boundary}
+3. {Question about technical constraint}
+4. {Question anticipating stakeholder concern}
+5. {Question about success/failure criteria}
+
+Answer in shorthand (e.g., "1: yes, 2: via Readwise API, 3: out of scope").
+```
+
+After user answers, summarize what will go in that section. Confirm before moving on.
+
+### Step 4: Build Plan Document
+
+As sections are confirmed, accumulate them in the plan file (NOT the final RFC yet).
+
+Structure:
+
+```
+# RFC Plan: {Title}
+
+## Status
+- [x] Summary confirmed
+- [x] Motivation confirmed
+- [ ] Goals and Non-Goals — in progress
+- [ ] ...
+
+## Summary
+{Confirmed content}
+
+## Motivation
+{Confirmed content}
+
+...
+```
+
+### Step 5: Exit Plan Mode
+
+When all sections are confirmed, call `ExitPlanMode` with the complete plan.
+
+Present a final summary:
+
+- RFC title
+- Key decisions made
+- Sections completed
+- Ready to write to Notion
+
+### Step 6: Write to Notion (After Acceptance)
+
+On plan acceptance, create the RFC in Notion:
+
+```
+mcp__notion__create_page with:
+- database_id: 2e7258b8-ba0c-80d1-a580-cbab6bca3ddd
+- properties:
+  - Title: {RFC title}
+  - Status: "Draft"
+  - Created: {ISO date}
+- content: {Full RFC markdown}
+```
+
+Output the Notion URL for the user to share with stakeholders.
+
+### Step 7: Suggest Next Steps
+
+After RFC creation:
+
+```
+RFC created: {Notion URL}
+
+Next steps:
+1. Share with stakeholders for review
+2. Address comments in Notion
+3. Once approved, run '/breakdown-rfc {notion-url}' to create tickets
+```
+
+## RFC Template
+
+The final RFC should follow this structure:
+
+```
+# RFC: {Title}
+
+## 📝 Summary
+
+{One paragraph explanation}
+
+## 💪 Motivation
+
+{Why are we doing this? Use cases? Expected outcome?}
+
+## 🎯 Goals and Non-Goals
+
+**Goals:**
+
+- {Goal 1}
+- {Goal 2}
+
+**Non-Goals:**
+
+- {Explicitly out of scope}
+
+**Success Criteria:**
+
+- {Measurable outcome}
+
+## 🙋 User's Explanation
+
+{Explain as if teaching a user. New concepts, UX, impact on existing features.}
+
+## 👷 Engineer's Explanation
+
+{Technical design. System interactions. Corner cases with examples.}
+
+## ⚠️ Drawbacks
+
+{Why should we NOT do this? Tradeoffs? New challenges?}
+
+## 🤔 Rationale and Alternatives
+
+{Why this design? Alternatives considered? Impact of not doing this?}
+
+## 💸 Cost and Operations
+
+{Infrastructure costs, LLM call estimates, operational complexity, deployment targets.}
+
+## 🌸 Prior Art
+
+{Similar systems, lessons learned, good and bad examples.}
+
+## ❓ Unresolved Questions
+
+{What to resolve during RFC review? Out of scope follow-ups?}
+
+## 🚀 Future Possibilities
+
+{Natural extensions, long-term vision, related ideas for later.}
+```
+
+## Question Bank by Section
+
+Reference questions to draw from (select most relevant, don't ask all):
+
+### Summary
+
+- Can you distill this to one sentence: "We will {action} so that {outcome}"?
+- What's the elevator pitch for stakeholders who have 30 seconds?
+- Is there a working title that captures the essence?
+
+### Motivation
+
+- What's the business driver? Revenue, retention, competitive pressure?
+- What user pain point does this address?
+- Why now vs. 6 months from now?
+- What happens if we don't do this?
+- Is there a specific user request or feedback driving this?
+
+### Goals and Non-Goals
+
+- What's the minimum viable version of this feature?
+- What should we explicitly NOT build in v1?
+- How will we measure success? (metrics, user feedback, etc.)
+- What's the failure mode we're most worried about?
+- Are there phasing considerations (v1, v2, future)?
+
+### User's Explanation
+
+- How does a user discover this feature?
+- What's the primary interaction flow?
+- How does this change existing workflows?
+- Are there new concepts users need to learn?
+- What's the "aha moment" for users?
+
+### Engineer's Explanation
+
+- What existing services/components does this touch?
+- What new services or data stores are needed?
+- How does data flow through the system?
+- What are the critical integration points?
+- What's the most technically risky part?
+
+### Drawbacks
+
+- What's the biggest technical risk?
+- What user experience tradeoffs are we making?
+- What maintenance burden does this add?
+- Could this break existing functionality?
+- What's the worst-case failure scenario?
+
+### Rationale and Alternatives
+
+- What other approaches did you consider?
+- Why is this approach better than {alternative}?
+- Is there an off-the-shelf solution we're rejecting?
+- What would a simpler version look like?
+- What would we do with 10x the resources?
+
+### Cost and Operations
+
+- What new infrastructure is required?
+- Are there new vendor dependencies?
+- What's the estimated LLM cost per user/query?
+- How does this affect deployment targets (BYOC, etc.)?
+- What monitoring/alerting do we need?
+
+### Prior Art
+
+- Are there similar features in competing products?
+- Have we built something similar before?
+- Are there open-source implementations to learn from?
+- What industry patterns apply here?
+- What cautionary tales should we heed?
+
+### Unresolved Questions
+
+- What technical spikes are needed before committing?
+- What stakeholder input is still needed?
+- Are there security/compliance reviews required?
+- What's blocked on external dependencies?
+- What decisions can be deferred to implementation?
+
+### Future Possibilities
+
+- What's the obvious v2 of this feature?
+- What adjacent features does this enable?
+- How does this fit the product roadmap?
+- What would we build if this succeeds wildly?
+- Are there platform/API implications?
+
+## Notes
+
+- Stay in plan mode throughout questioning — no file writes until acceptance
+- Questions should build on previous answers — don't ask in isolation
+- If user seems fatigued, offer to batch remaining sections with reasonable defaults
+- Codebase exploration informs questions but isn't shared verbatim
+- RFC quality depends on question quality — invest in understanding the feature