@monoes/monomindcli 2.15.3 → 2.15.4

package/org-skills/product-capability/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: product-capability
+description: "Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose."
+tags: ["product","engineering"]
+tools: ["monograph_suggest"]
+license: MIT
+source: https://github.com/affaan-m/ECC
+source_path: "skills/product-capability"
+source_commit: bf70150eb2df8070024e5bdf08e4aa08959e2735
+---
+# Product Capability
+
+This skill turns product intent into explicit engineering constraints.
+
+Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?"
+
+## When to Use
+
+- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit
+- A feature crosses multiple services, repos, or teams and needs a capability contract before coding
+- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy
+- Senior engineers keep restating the same hidden assumptions during review
+- You need a reusable artifact that can survive across harnesses and sessions
+
+## Canonical Artifact
+
+If the repo has a durable product-context file such as `PRODUCT.md`, `docs/product/`, or a program-spec directory, update it there.
+
+If no capability manifest exists yet, create one using the template at:
+
+- `docs/examples/product-capability-template.md`
+
+The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.
+
+## Non-Negotiable Rules
+
+- Do not invent product truth. Mark unresolved questions explicitly.
+- Separate user-visible promises from implementation details.
+- Call out what is fixed policy, what is architecture preference, and what is still open.
+- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.
+- Prefer one reusable capability artifact over scattered ad hoc notes.
+
+## Inputs
+
+Read only what is needed:
+
+1. Product intent
+   - issue, discussion, PRD, roadmap note, founder message
+2. Current architecture
+   - relevant repo docs, contracts, schemas, routes, existing workflows
+3. Existing capability context
+   - `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs
+4. Delivery constraints
+   - auth, billing, compliance, rollout, backwards compatibility, performance, review policy
+
+## Core Workflow
+
+### 1. Restate the capability
+
+Compress the ask into one precise statement:
+
+- who the user or operator is
+- what new capability exists after this ships
+- what outcome changes because of it
+
+If this statement is weak, the implementation will drift.
+
+### 2. Resolve capability constraints
+
+Extract the constraints that must hold before implementation:
+
+- business rules
+- scope boundaries
+- invariants
+- trust boundaries
+- data ownership
+- lifecycle transitions
+- rollout / migration requirements
+- failure and recovery expectations
+
+These are the things that often live only in senior-engineer memory.
+
+### 3. Define the implementation-facing contract
+
+Produce an SRS-style capability plan with:
+
+- capability summary
+- explicit non-goals
+- actors and surfaces
+- required states and transitions
+- interfaces / inputs / outputs
+- data model implications
+- security / billing / policy constraints
+- observability and operator requirements
+- open questions blocking implementation
+
+### 4. Translate into execution
+
+End with the exact handoff:
+
+- ready for direct implementation
+- needs architecture review first
+- needs product clarification first
+
+If useful, point to the next ECC-native lane:
+
+- `project-flow-ops`
+- `workspace-surface-audit`
+- `api-connector-builder`
+- `dashboard-builder`
+- `tdd-workflow`
+- `verification-loop`
+
+## Output Format
+
+Return the result in this order:
+
+```text
+CAPABILITY
+- one-paragraph restatement
+
+CONSTRAINTS
+- fixed rules, invariants, and boundaries
+
+IMPLEMENTATION CONTRACT
+- actors
+- surfaces
+- states and transitions
+- interface/data implications
+
+NON-GOALS
+- what this lane explicitly does not own
+
+OPEN QUESTIONS
+- blockers or product decisions still required
+
+HANDOFF
+- what should happen next and which ECC lane should take it
+```
+
+## Good Outcomes
+
+- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.
+- Engineering review has a durable artifact instead of relying on memory or Slack context.
+- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.

package/org-skills/product-discovery/LICENSE.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Alireza Rezvani
+
+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/product-discovery/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: product-discovery
+description: "Use when validating product opportunities, mapping assumptions, planning discovery sprints, or testing problem-solution fit before committing delivery resources."
+tags: ["product","research"]
+tools: []
+license: MIT
+source: https://github.com/alirezarezvani/claude-skills
+source_path: "product-team/skills/product-discovery"
+source_commit: 19392f7a08264ed00486a251f5b2098321771f94
+---
+# Product Discovery
+
+Run structured discovery to identify high-value opportunities and de-risk product bets.
+
+## When To Use
+
+Use this skill for:
+- Opportunity Solution Tree facilitation
+- Assumption mapping and test planning
+- Problem validation interviews and evidence synthesis
+- Solution validation with prototypes/experiments
+- Discovery sprint planning and outputs
+
+## Core Discovery Workflow
+
+1. Define desired outcome
+- Set one measurable outcome to improve.
+- Establish baseline and target horizon.
+
+2. Build Opportunity Solution Tree (OST)
+- Outcome -> opportunities -> solution ideas -> experiments
+- Keep opportunities grounded in user evidence, not internal opinions.
+
+3. Map assumptions
+- Identify desirability, viability, feasibility, and usability assumptions.
+- Score assumptions by risk and certainty.
+
+Use:
+```bash
+python3 scripts/assumption_mapper.py assumptions.csv
+```
+
+4. Validate the problem
+- Conduct interviews and behavior analysis.
+- Confirm frequency, severity, and willingness to solve.
+- Reject weak opportunities early.
+
+5. Validate the solution
+- Prototype before building.
+- Run concept, usability, and value tests.
+- Measure behavior, not only stated preference.
+
+6. Plan discovery sprint
+- 1-2 week cycle with explicit hypotheses
+- Daily evidence reviews
+- End with decision: proceed, pivot, or stop
+
+## Opportunity Solution Tree (Teresa Torres)
+
+Structure:
+- Outcome: metric you want to move
+- Opportunities: unmet customer needs/pains
+- Solutions: candidate interventions
+- Experiments: fastest learning actions
+
+Quality checks:
+- At least 3 distinct opportunities before converging.
+- At least 2 experiments per top opportunity.
+- Tie every branch to evidence source.
+
+## Assumption Mapping
+
+Assumption categories:
+- Desirability: users want this
+- Viability: business value exists
+- Feasibility: team can build/operate it
+- Usability: users can successfully use it
+
+Prioritization rule:
+- High risk + low certainty assumptions are tested first.
+
+## Problem Validation Techniques
+
+- Problem interviews focused on current behavior
+- Journey friction mapping
+- Support ticket and sales-call synthesis
+- Behavioral analytics triangulation
+
+Evidence threshold examples:
+- Same pain repeated across multiple target users
+- Observable workaround behavior
+- Measurable cost of current pain
+
+## Solution Validation Techniques
+
+- Concept tests (value proposition comprehension)
+- Prototype usability tests (task success/time-to-complete)
+- Fake door or concierge tests (demand signal)
+- Limited beta cohorts (retention/activation signals)
+
+## Discovery Sprint Planning
+
+Suggested 10-day structure:
+- Day 1-2: Outcome + opportunity framing
+- Day 3-4: Assumption mapping + test design
+- Day 5-7: Problem and solution tests
+- Day 8-9: Evidence synthesis + decision options
+- Day 10: Stakeholder decision review
+
+## Tooling
+
+### `scripts/assumption_mapper.py`
+
+CLI utility that:
+- reads assumptions from CSV or inline input
+- scores risk/certainty priority
+- emits prioritized test plan with suggested test types
+
+See `references/discovery-frameworks.md` for framework details.

package/org-skills/product-discovery/references/discovery-frameworks.md

@@ -0,0 +1,72 @@
+# Discovery Frameworks
+
+## Opportunity Solution Tree (OST)
+
+Purpose: continuously connect product outcomes to validated opportunities and tested solutions.
+
+Core structure:
+- Outcome (metric)
+- Opportunity nodes (needs/pains)
+- Solution ideas
+- Experiments
+
+OST practice tips:
+- Keep tree live; update after each interview or test.
+- Separate opportunity evidence from solution proposals.
+- Avoid single-branch trees that force one solution.
+
+## Jobs-to-be-Done (JTBD)
+
+Use JTBD to understand progress users seek.
+
+JTBD template:
+"When [situation], I want to [motivation], so I can [expected outcome]."
+
+JTBD interview focus:
+- Trigger moments
+- Current alternatives and workarounds
+- Purchase/adoption anxieties
+- Desired progress and success criteria
+
+## Kano Model
+
+Classify features by impact on satisfaction:
+- Must-be: expected baseline features
+- Performance: more is better
+- Delighters: unexpected value multipliers
+- Indifferent: low impact
+- Reverse: can reduce satisfaction for some users
+
+Use Kano when prioritizing solution concepts after problem validation.
+
+## Design Sprint Methodology
+
+Typical phases:
+1. Understand
+2. Sketch
+3. Decide
+4. Prototype
+5. Test
+
+Discovery usage:
+- Compress learning cycle into one week.
+- Best for high-ambiguity opportunities requiring cross-functional alignment.
+
+## Assumption Prioritization Matrix
+
+Map assumptions on two axes:
+- Risk if wrong (low -> high)
+- Certainty (low -> high)
+
+Priority order:
+1. High risk, low certainty (test first)
+2. High risk, high certainty (validate quickly)
+3. Low risk, low certainty (defer)
+4. Low risk, high certainty (document)
+
+## Discovery Evidence Rules
+
+- One source is not enough for major decisions.
+- Triangulate qualitative and quantitative signals.
+- Predefine decision criteria before test execution.
+- Archive evidence with date, segment, and method.

package/org-skills/product-lens/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/product-lens/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: product-lens
+description: "Use this skill to validate the \"why\" before building, run product diagnostics, and pressure-test product direction before the request becomes an implementation contract."
+tags: ["product"]
+tools: []
+license: MIT
+source: https://github.com/affaan-m/ECC
+source_path: "skills/product-lens"
+source_commit: bf70150eb2df8070024e5bdf08e4aa08959e2735
+---
+# Product Lens — Think Before You Build
+
+This lane owns product diagnosis, not implementation-ready specification writing.
+
+If the user needs a durable PRD-to-SRS or capability-contract artifact, hand off to `product-capability`.
+
+## When to Use
+
+- Before starting any feature — validate the "why"
+- Weekly product review — are we building the right thing?
+- When stuck choosing between features
+- Before a launch — sanity check the user journey
+- When converting a vague idea into a product brief before engineering planning starts
+
+## How It Works
+
+### Mode 1: Product Diagnostic
+
+Like YC office hours but automated. Asks the hard questions:
+
+```
+1. Who is this for? (specific person, not "developers")
+2. What's the pain? (quantify: how often, how bad, what do they do today?)
+3. Why now? (what changed that makes this possible/necessary?)
+4. What's the 10-star version? (if money/time were unlimited)
+5. What's the MVP? (smallest thing that proves the thesis)
+6. What's the anti-goal? (what are you explicitly NOT building?)
+7. How do you know it's working? (metric, not vibes)
+```
+
+Output: a `PRODUCT-BRIEF.md` with answers, risks, and a go/no-go recommendation.
+
+If the result is "yes, build this," the next lane is `product-capability`, not more founder-theater.
+
+### Mode 2: Founder Review
+
+Reviews your current project through a founder lens:
+
+```
+1. Read README, CLAUDE.md, package.json, recent commits
+2. Infer: what is this trying to be?
+3. Score: product-market fit signals (0-10)
+   - Usage growth trajectory
+   - Retention indicators (repeat contributors, return users)
+   - Revenue signals (pricing page, billing code, Stripe integration)
+   - Competitive moat (what's hard to copy?)
+4. Identify: the one thing that would 10x this
+5. Flag: things you're building that don't matter
+```
+
+### Mode 3: User Journey Audit
+
+Maps the actual user experience:
+
+```
+1. Clone/install the product as a new user
+2. Document every friction point (confusing steps, errors, missing docs)
+3. Time each step
+4. Compare to competitor onboarding
+5. Score: time-to-value (how long until the user gets their first win?)
+6. Recommend: top 3 fixes for onboarding
+```
+
+### Mode 4: Feature Prioritization
+
+When you have 10 ideas and need to pick 2:
+
+```
+1. List all candidate features
+2. Score each on: impact (1-5) × confidence (1-5) ÷ effort (1-5)
+3. Rank by ICE score
+4. Apply constraints: runway, team size, dependencies
+5. Output: prioritized roadmap with rationale
+```
+
+## Output
+
+All modes output actionable docs, not essays. Every recommendation has a specific next step.
+
+## Integration
+
+Pair with:
+- `/browser-qa` to verify the user journey audit findings
+- `/design-system audit` for visual polish assessment
+- `/canary-watch` for post-launch monitoring
+- `product-capability` when the product brief needs to become an implementation-ready capability plan

package/{dist/src/orgrt/role-skills/product-manager.md → org-skills/product-manager/SKILL.md}

@@ -1,3 +1,11 @@
+---
+name: product-manager
+description: "Product Manager role best practices. Owns the \"why\" and \"what\" of a product: turning strategy into a prioritized roadmap, aligning stakeholders, and ensuring what ships actually solves a validated problem."
+tags: ["product"]
+tools: []
+license: Apache-2.0
+source: https://github.com/monoes/monomind
+---
 # Product Manager — Best Practices
 
 ## Focus

package/org-skills/product-marketing-context/LICENSE.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Corey Haines
+
+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.