@monoes/monomindcli 2.15.3 → 2.15.5

package/org-skills/product-marketing-context/SKILL.md

@@ -0,0 +1,258 @@
+---
+name: product-marketing-context
+description: "When the user wants to create or update their product marketing context document. Also use when the user mentions 'product context,' 'marketing context,' 'set up context,' 'positioning,' 'who is my target audience,' 'describe my product,' 'ICP,' 'ideal customer profile,' or wants to avoid repeating foundational information across marketing tasks."
+tags: ["marketing","product"]
+tools: []
+license: MIT
+source: https://github.com/coreyhaines31/marketingskills
+source_path: "skills/product-marketing"
+source_commit: 5b2c0007766c6a1cf1d53fd8fc73e979e0821022
+---
+# Product Marketing Context
+
+You help users create and maintain a product marketing context document. This captures foundational positioning and messaging information that other marketing skills reference, so users don't repeat themselves.
+
+The document is stored at `.agents/product-marketing.md`.
+
+## Workflow
+
+### Step 1: Check for Existing Context
+
+First, check if `.agents/product-marketing.md` already exists. Also check `.claude/product-marketing.md` and the legacy filename `product-marketing-context.md` (in either `.agents/` or `.claude/`) for older setups — if found anywhere other than `.agents/product-marketing.md`, offer to move it to the canonical location.
+
+**If it exists:**
+- Read it and summarize what's captured — note its current **Document version** and the last few **Changelog** entries so the user sees where the doc stands and what's changed recently
+- Ask which sections they want to update
+- Only gather info for those sections
+- On any substantive save, bump the version and add a changelog entry (see Step 4). This doc is the shared context every other marketing skill reads, so a dated paper trail of *what changed and why* is worth keeping.
+
+**If it doesn't exist, offer two options:**
+
+1. **Auto-draft from codebase** (recommended): You'll study the repo—README, landing pages, marketing copy, package.json, etc.—and draft a V1 of the context document. The user then reviews, corrects, and fills gaps. This is faster than starting from scratch.
+
+2. **Start from scratch**: Walk through each section conversationally, gathering info one section at a time.
+
+Most users prefer option 1. After presenting the draft, ask: "What needs correcting? What's missing?"
+
+### Step 2: Gather Information
+
+**If auto-drafting:**
+1. Read the codebase: README, landing pages, marketing copy, about pages, meta descriptions, package.json, any existing docs
+2. Draft all sections based on what you find
+3. Present the draft and ask what needs correcting or is missing
+4. Iterate until the user is satisfied
+
+**If starting from scratch:**
+Walk through each section below conversationally, one at a time. Don't dump all questions at once.
+
+For each section:
+1. Briefly explain what you're capturing
+2. Ask relevant questions
+3. Confirm accuracy
+4. Move to the next
+
+Push for verbatim customer language — exact phrases are more valuable than polished descriptions because they reflect how customers actually think and speak, which makes copy more resonant.
+
+---
+
+## Sections to Capture
+
+### 1. Product Overview
+- One-line description
+- What it does (2-3 sentences)
+- Product category (what "shelf" you sit on—how customers search for you)
+- Product type (SaaS, marketplace, e-commerce, service, etc.)
+- Business model and pricing
+
+### 2. Target Audience
+- Target company type (industry, size, stage)
+- Target decision-makers (roles, departments)
+- Primary use case (the main problem you solve)
+- Jobs to be done (2-3 things customers "hire" you for)
+- Specific use cases or scenarios
+
+### 3. Personas (B2B only)
+If multiple stakeholders are involved in buying, capture for each:
+- User, Champion, Decision Maker, Financial Buyer, Technical Influencer
+- What each cares about, their challenge, and the value you promise them
+
+### 4. Problems & Pain Points
+- Core challenge customers face before finding you
+- Why current solutions fall short
+- What it costs them (time, money, opportunities)
+- Emotional tension (stress, fear, doubt)
+
+### 5. Competitive Landscape
+- **Direct competitors**: Same solution, same problem (e.g., Calendly vs SavvyCal)
+- **Secondary competitors**: Different solution, same problem (e.g., Calendly vs Superhuman scheduling)
+- **Indirect competitors**: Conflicting approach (e.g., Calendly vs personal assistant)
+- How each falls short for customers
+
+### 6. Differentiation
+- Key differentiators (capabilities alternatives lack)
+- How you solve it differently
+- Why that's better (benefits)
+- Why customers choose you over alternatives
+
+### 7. Objections & Anti-Personas
+- Top 3 objections heard in sales and how to address them
+- Who is NOT a good fit (anti-persona)
+
+### 8. Switching Dynamics
+The JTBD Four Forces:
+- **Push**: What frustrations drive them away from current solution
+- **Pull**: What attracts them to you
+- **Habit**: What keeps them stuck with current approach
+- **Anxiety**: What worries them about switching
+
+### 9. Customer Language
+- How customers describe the problem (verbatim)
+- How they describe your solution (verbatim)
+- Words/phrases to use
+- Words/phrases to avoid
+- Glossary of product-specific terms
+
+### 10. Brand Voice
+- Tone (professional, casual, playful, etc.)
+- Communication style (direct, conversational, technical)
+- Brand personality (3-5 adjectives)
+
+### 11. Proof Points
+- Key metrics or results to cite
+- Notable customers/logos
+- Testimonial snippets
+- Main value themes and supporting evidence
+
+### 12. Goals
+- Primary business goal
+- Key conversion action (what you want people to do)
+- Current metrics (if known)
+
+---
+
+## Step 3: Create the Document
+
+After gathering information, create `.agents/product-marketing.md` with this structure:
+
+```markdown
+# Product Marketing Context
+
+**Document version:** v1
+**Last updated:** [date]
+
+## Product Overview
+**One-liner:**
+**What it does:**
+**Product category:**
+**Product type:**
+**Business model:**
+
+## Target Audience
+**Target companies:**
+**Decision-makers:**
+**Primary use case:**
+**Jobs to be done:**
+-
+**Use cases:**
+-
+
+## Personas
+| Persona | Cares about | Challenge | Value we promise |
+|---------|-------------|-----------|------------------|
+| | | | |
+
+## Problems & Pain Points
+**Core problem:**
+**Why alternatives fall short:**
+-
+**What it costs them:**
+**Emotional tension:**
+
+## Competitive Landscape
+**Direct:** [Competitor] — falls short because...
+**Secondary:** [Approach] — falls short because...
+**Indirect:** [Alternative] — falls short because...
+
+## Differentiation
+**Key differentiators:**
+-
+**How we do it differently:**
+**Why that's better:**
+**Why customers choose us:**
+
+## Objections
+| Objection | Response |
+|-----------|----------|
+| | |
+
+**Anti-persona:**
+
+## Switching Dynamics
+**Push:**
+**Pull:**
+**Habit:**
+**Anxiety:**
+
+## Customer Language
+**How they describe the problem:**
+- "[verbatim]"
+**How they describe us:**
+- "[verbatim]"
+**Words to use:**
+**Words to avoid:**
+**Glossary:**
+| Term | Meaning |
+|------|---------|
+| | |
+
+## Brand Voice
+**Tone:**
+**Style:**
+**Personality:**
+
+## Proof Points
+**Metrics:**
+**Customers:**
+**Testimonials:**
+> "[quote]" — [who]
+**Value themes:**
+| Theme | Proof |
+|-------|-------|
+| | |
+
+## Goals
+**Business goal:**
+**Conversion action:**
+**Current metrics:**
+
+## Changelog
+*Newest first. One line per revision: what changed and why.*
+- v1 ([date]) — Initial context.
+```
+
+---
+
+## Step 4: Confirm, Version, and Save
+
+- Show the completed document
+- Ask if anything needs adjustment
+- **Set the version and changelog** — this is the paper trail for a doc every other skill reads:
+  - **New document:** set `Document version: v1` and a single Changelog entry — `- v1 ([today]) — Initial context.`
+  - **Updating an existing document:** increment the version (v2 → v3 …), update `Last updated` to today, and **prepend a new Changelog entry** at the top of the list (newest first) summarizing *what changed and why* in one line. Never rewrite or reorder past entries.
+  - A good entry names the sections touched and the reason, not "updated the doc." Examples:
+    - `- v3 (2026-07-16) — Repositioned from "email tool" to "deliverability platform"; added RevOps to the ICP.`
+    - `- v2 (2026-06-02) — Rewrote value prop and objections after 5 customer interviews; added competitor Acme.`
+  - Use today's date in ISO form (YYYY-MM-DD) for the entry and `Last updated`.
+  - **Pure typo-only fix:** don't bump the version or add a changelog entry — just save the correction. Every other change bumps the version and gets an entry. When the change is a real repositioning, say so plainly — downstream skills will now generate against the new context.
+- Save to `.agents/product-marketing.md`
+- Tell them: "Other marketing skills will now use this context automatically. The Changelog at the bottom tracks every revision — check it to see how your positioning has evolved. Run `/product-marketing` anytime to update it."
+
+---
+
+## Tips
+
+- **Be specific**: Ask "What's the #1 frustration that brings them to you?" not "What problem do they solve?"
+- **Capture exact words**: Customer language beats polished descriptions
+- **Ask for examples**: "Can you give me an example?" unlocks better answers
+- **Validate as you go**: Summarize each section and confirm before moving on
+- **Skip what doesn't apply**: Not every product needs all sections (e.g., Personas for B2C)

package/org-skills/production-audit/LICENSE.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Affaan Mustafa
+
+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/org-skills/production-audit/SKILL.md

@@ -0,0 +1,210 @@
+---
+name: production-audit
+description: "Local-evidence production readiness audit for shipped apps, pre-launch reviews, post-merge checks, and \"what breaks in prod?\" questions without sending repo data to an external audit service. Use when auditing production readiness before launch, after a merge, or when asked what breaks in prod."
+tags: ["engineering","devops","security"]
+tools: ["monograph_query","monograph_suggest"]
+license: MIT
+source: https://github.com/affaan-m/ECC
+source_path: "skills/production-audit"
+source_commit: bf70150eb2df8070024e5bdf08e4aa08959e2735
+---
+# Production Audit
+
+Use this skill when the user asks whether an application is ready to ship, what
+could break in production, or what must be fixed before a launch. This is a
+maintainer-safe rewrite of the stale community production-audit idea: it keeps
+the useful production-readiness lens and removes unpinned external execution and
+third-party data sharing.
+
+## When to Use
+
+- The user asks "is this production-ready", "what would break in prod", "what
+  did we miss", "audit this repo", or "ready to ship?"
+- A feature was merged and needs a pre-deploy or post-merge risk pass.
+- A public launch, demo, customer rollout, or investor walkthrough is close.
+- CI is green but the user wants production risk, not only test status.
+- A deployed URL, release branch, PR, or current checkout is available for
+  evidence gathering.
+
+## When Not to Use
+
+- During active implementation when the right lens is line-level secure coding;
+  use `security-review` first.
+- For pure libraries, templates, docs-only repos, or scaffolds unless the user
+  wants packaging/release readiness rather than application readiness.
+- When the user asks for a formal compliance audit. This skill is engineering
+  triage, not legal, financial, medical, or regulatory certification.
+- When the only available evidence is a product idea with no repo, deployment,
+  CI, or runtime surface.
+
+## How It Works
+
+Build the audit from local and user-authorized evidence. Do not run unpinned
+remote code, upload repository contents to third-party services, or call
+external scanners unless the user explicitly approves that specific tool and
+data flow.
+
+Use this order:
+
+1. Establish the release surface.
+2. Read recent changes and current branch state.
+3. Inspect runtime, auth, data, payment, background-job, AI, and deployment
+   boundaries that actually exist in the repo.
+4. Check CI, tests, migrations, environment documentation, and rollback path.
+5. Produce a short ship/block recommendation with specific fixes.
+
+## Evidence Checklist
+
+Start with cheap, local signals:
+
+```text
+git status --short --branch
+git log --oneline --decorate -20
+git diff --stat origin/main...HEAD
+```
+
+Then inspect the project-specific surface:
+
+- Package scripts, CI workflows, release scripts, Docker files, and deployment
+  manifests.
+- API routes, webhooks, auth middleware, background workers, cron jobs, and
+  database migrations.
+- Environment variable documentation and startup checks.
+- Observability hooks, error reporting, logs, health checks, and dashboards.
+- Rollback, seed, migration, and backfill instructions.
+- E2E coverage for the user paths that matter most.
+
+If a deployed URL is in scope, use browser or HTTP checks only against that URL
+and avoid credentialed actions unless the user supplies a safe test account.
+
+## Risk Lenses
+
+### Security And Auth
+
+- Are public routes, API routes, and admin routes clearly separated?
+- Are auth and authorization enforced server-side?
+- Are secrets kept out of client bundles, logs, example output, and checked-in
+  files?
+- Are rate limits, CSRF protections, CORS policy, and upload validation present
+  where the app needs them?
+- Does the AI or agent surface defend against prompt injection, tool abuse, and
+  untrusted content crossing into privileged actions?
+
+### Data Integrity
+
+- Do migrations run forward cleanly and have a rollback or recovery plan?
+- Are destructive migrations, backfills, and data imports staged safely?
+- Do database policies, grants, and service-role boundaries match the app's
+  tenancy model?
+- Are retries idempotent for writes, jobs, and webhook handlers?
+
+### Payments And Webhooks
+
+- Are webhook signatures verified before parsing trusted payload fields?
+- Is each payment, subscription, or fulfillment webhook idempotent?
+- Are replay, duplicate delivery, and out-of-order delivery handled?
+- Are test-mode and live-mode credentials separated?
+
+### Operations
+
+- Can the app start from a clean checkout using documented commands?
+- Are required environment variables named, validated, and fail-fast?
+- Is there a health check that proves dependencies are reachable?
+- Are deploy, rollback, and incident-owner paths documented?
+- Are logs useful without leaking secrets or personal data?
+
+### User Experience
+
+- Are the launch-critical paths covered on desktop and mobile?
+- Are forms usable on mobile without input zoom, layout overlap, or blocked
+  submission states?
+- Do loading, empty, error, and permission-denied states tell the user what
+  happened?
+- Is there a support or recovery path when a critical operation fails?
+
+## Scoring
+
+Use scores to force prioritization, not to imply mathematical certainty.
+
+| Band | Score | Meaning |
+| --- | --- | --- |
+| Blocked | 0-49 | Do not ship until the top risks are fixed |
+| Risky | 50-69 | Ship only behind a small rollout or internal beta |
+| Launchable With Caveats | 70-84 | Ship if owners accept the listed risks |
+| Strong | 85-100 | No obvious launch blockers from available evidence |
+
+Cap the score at `69` if any of these are true:
+
+- Authentication or authorization is missing on sensitive data.
+- Payment or fulfillment webhooks are not idempotent.
+- Required migrations cannot be run safely.
+- Secrets are exposed in client bundles, logs, or committed files.
+- There is no rollback path for a high-impact release.
+
+Cap the score at `84` if CI is not green or the launch-critical path was not
+tested end to end.
+
+## Output Format
+
+Lead with one sentence:
+
+```text
+Production audit: 76/100, launchable with caveats, with webhook idempotency and rollback docs as the two risks to fix before public launch.
+```
+
+Then list:
+
+- `Blockers`: must-fix items before deploy.
+- `High-value fixes`: next fixes if the user wants to improve the score.
+- `Evidence checked`: files, commands, CI, deployed URL, or PRs inspected.
+- `Evidence missing`: what would change confidence if provided.
+- `Next action`: one concrete fix or verification step.
+
+Keep strengths short. The user asked for readiness, so the useful answer is the
+remaining risk and the next action.
+
+## Example
+
+User:
+
+```text
+is this ready to ship?
+```
+
+Response:
+
+```text
+Production audit: 68/100, risky, because Stripe webhooks are verified but not idempotent and there is no rollback note for the pending migration.
+
+Blockers:
+- Add idempotency for `checkout.session.completed` before fulfilling orders.
+- Write and test the rollback path for `20260511_add_billing_state.sql`.
+
+High-value fixes:
+- Add a health check that verifies database and payment-provider reachability.
+- Add one E2E path for upgrade, webhook fulfillment, and billing-page refresh.
+
+Evidence checked:
+- `api/stripe/webhook.ts`
+- `db/migrations/20260511_add_billing_state.sql`
+- GitHub Actions run for the release branch
+
+Next action: Want me to patch webhook idempotency first?
+```
+
+## Anti-Patterns
+
+- Running `npx <package>@latest` or a remote scanner as the default audit path.
+- Uploading source, secrets, customer data, or private topology to an external
+  audit service without explicit approval.
+- Producing a score without naming the evidence checked.
+- Treating green CI as production readiness.
+- Ending with a generic "let me know what you want to do."
+
+## See Also
+
+- Skill: `security-review`
+- Skill: `deployment-patterns`
+- Skill: `e2e-testing`
+- Skill: `tdd-workflow`
+- Skill: `verification-loop`