codeply-cli 0.3.1 → 0.4.1

package/skills/product-capability/SKILL.md

@@ -1,142 +1,142 @@
----
-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.
-metadata:
-  origin: ECC
----
-
-# 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.
+---
+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.
+metadata:
+  origin: ECC
+---
+
+# 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/skills/product-lens/SKILL.md

@@ -1,93 +1,93 @@
----
-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.
-metadata:
-  origin: ECC
----
-
-# 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
+---
+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.
+metadata:
+  origin: ECC
+---
+
+# 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