aw-ecc 1.4.32 → 1.4.47

package/.cursor/skills/git-workflow-and-versioning/SKILL.md

@@ -1,75 +0,0 @@
----
-name: git-workflow-and-versioning
-description: Keeps work reviewable, reversible, and well-scoped. Use for any code change that needs branches, save points, commit hygiene, or parallel work isolation.
-origin: ECC
----
-
-# Git Workflow and Versioning
-
-## Overview
-
-Git is the safety system for fast-moving engineering work.
-Treat branches as sandboxes, commits as save points, and history as operational documentation for humans, reviewers, and future agents.
-
-## When to Use
-
-- making any code, config, docs, or migration change
-- deciding branch or worktree strategy
-- choosing commit boundaries
-- preparing changes for review or rollback
-- organizing parallel agent or multi-slice work
-
-**When NOT to use**
-
-- only when no repository-backed change is being made at all
-
-## Workflow
-
-1. Start from the smallest isolated workspace that fits the change.
-   Prefer short-lived feature branches.
-   For parallel work or risky experiments, use worktrees instead of branch thrash.
-2. Size the work before committing.
-   Break the change into logical slices that can be explained, reviewed, and reverted independently.
-   Use `../../references/git-save-points.md` when save-point discipline matters.
-3. Commit each successful increment.
-   The pattern is:
-   implement slice -> verify slice -> commit slice.
-   Do not wait for one giant final commit.
-4. Keep concerns separate.
-   Avoid mixing formatting, refactors, dependency churn, and feature behavior in the same commit unless they are inseparable.
-   Reviewable history is part of engineering quality.
-5. Run pre-commit hygiene.
-   Check the staged diff, run the smallest relevant validation, and verify secrets or generated junk are not being committed.
-6. Leave a scope map for the next human or agent.
-   Name:
-   - what changed
-   - what did not change
-   - what still needs follow-up
-   In AW flows, keep this aligned with the stage artifacts and change summaries.
-
-## Common Rationalizations
-
-| Rationalization | Reality |
-|---|---|
-| "I'll clean up the history later." | Messy history is harder to split and explain after the fact. |
-| "One big commit is faster." | Giant commits are slower to review, debug, and revert. |
-| "This cleanup can ride along with the feature." | Mixed concerns make scope, blame, and rollback harder. |
-| "I don't need an isolated branch for a small change." | Isolation is cheap; accidental overlap is expensive. |
-
-## Red Flags
-
-- one commit mixes unrelated concerns
-- the diff is too large to explain in one sentence
-- no save point exists between meaningful slices
-- generated output, secrets, or local-only noise are staged
-- branch or worktree discipline is vague during multi-agent work
-
-## Verification
-
-After using git workflow discipline, confirm:
-
-- [ ] the work is isolated in the right branch or worktree
-- [ ] commit boundaries match real progress
-- [ ] staged content excludes secrets and unrelated noise
-- [ ] the history is reviewable and reversible
-- [ ] the change summary makes scope boundaries explicit

package/.cursor/skills/idea-refine/SKILL.md

@@ -1,84 +0,0 @@
----
-name: idea-refine
-description: Refines raw ideas into sharper, build-worthy directions. Use when a request starts as an idea, concept, or vague opportunity rather than an implementation-ready plan.
-origin: ECC
----
-
-# Idea Refine
-
-## Overview
-
-Refine ideas before turning them into specs.
-This skill takes a raw concept, pressure-tests it, and turns it into a concrete direction with explicit assumptions, MVP scope, and a clear "not doing" list.
-
-## When to Use
-
-- the user has a raw product, feature, or workflow idea
-- the request is still more concept than plan
-- multiple possible directions exist and the tradeoffs are not obvious
-- the team needs a sharper problem statement before `aw-plan`
-
-**When NOT to use**
-
-- the technical direction is already approved and the work is ready for `aw-plan`
-- the task is really implementation, testing, or review rather than idea shaping
-
-## Workflow
-
-1. Restate the idea as a sharp problem.
-   Convert the raw concept into a crisp problem statement or "How Might We" framing.
-   The goal is to name who the work is for and what better outcome it creates.
-2. Ask only the questions that change the direction.
-   Focus on:
-   - target user or operator
-   - success criteria
-   - real constraints
-   - timing or urgency
-   - what has already been tried
-3. Generate a small set of meaningful directions.
-   Explore 3-5 distinct options instead of polishing the first instinct.
-   Use lenses like simplification, inversion, audience shift, or "what would make this 10x more valuable?"
-4. Converge with pressure, not vibes.
-   Compare directions on:
-   - user value
-   - feasibility
-   - org fit and platform constraints
-   - differentiation
-   - rollout or maintenance risk
-5. Surface the bet explicitly.
-   Name:
-   - key assumptions
-   - what could kill the idea
-   - MVP scope
-   - what we are intentionally not doing
-6. Produce a one-pager that can move into planning.
-   The output should be easy to hand to `aw-plan` or `aw-brainstorm` without redoing the ideation.
-   In AW repos, keep this outcome inside planning artifacts or `state.json` instead of inventing a second artifact system.
-
-## Common Rationalizations
-
-| Rationalization | Reality |
-|---|---|
-| "We already know what to build." | If the problem statement and user are fuzzy, the plan will be fuzzy too. |
-| "More ideas is always better." | A few meaningful directions beat a long list of shallow variants. |
-| "We'll decide scope once we start building." | Scope discovered too late becomes rework and churn. |
-| "Not doing lists are negative." | Explicitly saying no is what makes a direction buildable. |
-
-## Red Flags
-
-- the output jumps to implementation without clarifying user value
-- only one direction is considered when real alternatives exist
-- no assumptions or risks are surfaced
-- the final direction has no MVP boundary or "not doing" list
-- ideation silently turns into coding or detailed task planning
-
-## Verification
-
-After refining an idea, confirm:
-
-- [ ] the problem statement is explicit
-- [ ] the target user or operator and success criteria are named
-- [ ] multiple viable directions were considered
-- [ ] key assumptions and failure risks are visible
-- [ ] MVP scope and "not doing" boundaries are clear
-- [ ] the output is ready to feed `aw-plan` without restarting discovery

package/.cursor/skills/incremental-implementation/SKILL.md

@@ -1,75 +0,0 @@
----
-name: incremental-implementation
-description: Delivers multi-file work in thin, reversible slices. Use when a change spans more than one file, when a task feels too large to land safely in one pass, or when rollback clarity matters.
-origin: ECC
----
-
-# Incremental Implementation
-
-## Overview
-
-Build in thin vertical slices.
-Each slice should leave the system in a working, testable, reviewable state before the next one begins, but a passing slice is only a checkpoint until the approved build scope is complete.
-
-## When to Use
-
-- a change touches more than one file
-- a feature is large enough to tempt one big patch
-- a migration, UI change, or rollout-sensitive task needs safe checkpoints
-- you want commit boundaries that reflect real progress
-
-**When NOT to use**
-
-- the work is already truly minimal and single-scope
-- the next step is still unclear and needs planning or investigation first
-
-## Workflow
-
-1. Select the next smallest slice.
-   Start from approved scope.
-   Choose one user-visible behavior, one boundary change, or one safe infrastructure increment.
-2. Define the proof for that slice.
-   Name the failing signal, acceptance check, or runtime evidence that will prove the slice is real.
-3. Implement only that slice.
-   Avoid adjacent cleanup and hidden follow-on work.
-   Use `../../references/build-increments.md` when sizing or rollback shape is fuzzy.
-4. Verify immediately.
-   Run the smallest relevant check:
-   - targeted test
-   - build or typecheck
-   - runtime/browser proof
-   - migration validation
-5. Save the progress cleanly.
-   Use `../../references/git-save-points.md` when the work benefits from explicit commit discipline.
-   A good save point is small, passing, and easy to explain.
-6. Decide whether to continue or hand off.
-   If more approved build slices remain, continue with the next slice.
-   If the approved build scope is complete and the next unsatisfied need is QA, review, or release work, stop and hand off.
-   Do not keep building just because speculative cleanup or unrelated improvements are possible.
-
-## Common Rationalizations
-
-| Rationalization | Reality |
-|---|---|
-| "I'll do the whole feature first, then test it." | Large unverified batches hide regressions and make rollback harder. |
-| "This extra cleanup is basically free." | Scope creep weakens slice boundaries and review quality. |
-| "I don't need a save point yet." | Save points matter most before the diff becomes hard to reason about. |
-| "The slice is too small to be worth validating." | Small slices are exactly what make validation cheap and reliable. |
-
-## Red Flags
-
-- one slice changes multiple unrelated behaviors
-- one passing slice is treated as the end of build even though approved build slices remain
-- rollback is unclear after the latest patch
-- tests are deferred instead of attached to the slice
-- commit/save-point boundaries no longer match meaningful progress
-
-## Verification
-
-After each increment, confirm:
-
-- [ ] the slice has one clear purpose
-- [ ] the slice has current proof, not assumed proof
-- [ ] the diff is still reversible and reviewable
-- [ ] the next slice is either the next approved build step or an explicit handoff boundary
-- [ ] save points reflect meaningful progress

package/.cursor/skills/investor-materials/SKILL.md

@@ -1,96 +0,0 @@
----
-name: investor-materials
-description: Create and update pitch decks, one-pagers, investor memos, accelerator applications, financial models, and fundraising materials. Use when the user needs investor-facing documents, projections, use-of-funds tables, milestone plans, or materials that must stay internally consistent across multiple fundraising assets.
-origin: ECC
----
-
-# Investor Materials
-
-Build investor-facing materials that are consistent, credible, and easy to defend.
-
-## When to Activate
-
-- creating or revising a pitch deck
-- writing an investor memo or one-pager
-- building a financial model, milestone plan, or use-of-funds table
-- answering accelerator or incubator application questions
-- aligning multiple fundraising docs around one source of truth
-
-## Golden Rule
-
-All investor materials must agree with each other.
-
-Create or confirm a single source of truth before writing:
-- traction metrics
-- pricing and revenue assumptions
-- raise size and instrument
-- use of funds
-- team bios and titles
-- milestones and timelines
-
-If conflicting numbers appear, stop and resolve them before drafting.
-
-## Core Workflow
-
-1. inventory the canonical facts
-2. identify missing assumptions
-3. choose the asset type
-4. draft the asset with explicit logic
-5. cross-check every number against the source of truth
-
-## Asset Guidance
-
-### Pitch Deck
-Recommended flow:
-1. company + wedge
-2. problem
-3. solution
-4. product / demo
-5. market
-6. business model
-7. traction
-8. team
-9. competition / differentiation
-10. ask
-11. use of funds / milestones
-12. appendix
-
-If the user wants a web-native deck, pair this skill with `frontend-slides`.
-
-### One-Pager / Memo
-- state what the company does in one clean sentence
-- show why now
-- include traction and proof points early
-- make the ask precise
-- keep claims easy to verify
-
-### Financial Model
-Include:
-- explicit assumptions
-- bear / base / bull cases when useful
-- clean layer-by-layer revenue logic
-- milestone-linked spending
-- sensitivity analysis where the decision hinges on assumptions
-
-### Accelerator Applications
-- answer the exact question asked
-- prioritize traction, insight, and team advantage
-- avoid puffery
-- keep internal metrics consistent with the deck and model
-
-## Red Flags to Avoid
-
-- unverifiable claims
-- fuzzy market sizing without assumptions
-- inconsistent team roles or titles
-- revenue math that does not sum cleanly
-- inflated certainty where assumptions are fragile
-
-## Quality Gate
-
-Before delivering:
-- every number matches the current source of truth
-- use of funds and revenue layers sum correctly
-- assumptions are visible, not buried
-- the story is clear without hype language
-- the final asset is defensible in a partner meeting

package/.cursor/skills/investor-outreach/SKILL.md

@@ -1,76 +0,0 @@
----
-name: investor-outreach
-description: Draft cold emails, warm intro blurbs, follow-ups, update emails, and investor communications for fundraising. Use when the user wants outreach to angels, VCs, strategic investors, or accelerators and needs concise, personalized, investor-facing messaging.
-origin: ECC
----
-
-# Investor Outreach
-
-Write investor communication that is short, personalized, and easy to act on.
-
-## When to Activate
-
-- writing a cold email to an investor
-- drafting a warm intro request
-- sending follow-ups after a meeting or no response
-- writing investor updates during a process
-- tailoring outreach based on fund thesis or partner fit
-
-## Core Rules
-
-1. Personalize every outbound message.
-2. Keep the ask low-friction.
-3. Use proof, not adjectives.
-4. Stay concise.
-5. Never send generic copy that could go to any investor.
-
-## Cold Email Structure
-
-1. subject line: short and specific
-2. opener: why this investor specifically
-3. pitch: what the company does, why now, what proof matters
-4. ask: one concrete next step
-5. sign-off: name, role, one credibility anchor if needed
-
-## Personalization Sources
-
-Reference one or more of:
-- relevant portfolio companies
-- a public thesis, talk, post, or article
-- a mutual connection
-- a clear market or product fit with the investor's focus
-
-If that context is missing, ask for it or state that the draft is a template awaiting personalization.
-
-## Follow-Up Cadence
-
-Default:
-- day 0: initial outbound
-- day 4-5: short follow-up with one new data point
-- day 10-12: final follow-up with a clean close
-
-Do not keep nudging after that unless the user wants a longer sequence.
-
-## Warm Intro Requests
-
-Make life easy for the connector:
-- explain why the intro is a fit
-- include a forwardable blurb
-- keep the forwardable blurb under 100 words
-
-## Post-Meeting Updates
-
-Include:
-- the specific thing discussed
-- the answer or update promised
-- one new proof point if available
-- the next step
-
-## Quality Gate
-
-Before delivering:
-- message is personalized
-- the ask is explicit
-- there is no fluff or begging language
-- the proof point is concrete
-- word count stays tight

package/.cursor/skills/market-research/SKILL.md

@@ -1,75 +0,0 @@
----
-name: market-research
-description: Conduct market research, competitive analysis, investor due diligence, and industry intelligence with source attribution and decision-oriented summaries. Use when the user wants market sizing, competitor comparisons, fund research, technology scans, or research that informs business decisions.
-origin: ECC
----
-
-# Market Research
-
-Produce research that supports decisions, not research theater.
-
-## When to Activate
-
-- researching a market, category, company, investor, or technology trend
-- building TAM/SAM/SOM estimates
-- comparing competitors or adjacent products
-- preparing investor dossiers before outreach
-- pressure-testing a thesis before building, funding, or entering a market
-
-## Research Standards
-
-1. Every important claim needs a source.
-2. Prefer recent data and call out stale data.
-3. Include contrarian evidence and downside cases.
-4. Translate findings into a decision, not just a summary.
-5. Separate fact, inference, and recommendation clearly.
-
-## Common Research Modes
-
-### Investor / Fund Diligence
-Collect:
-- fund size, stage, and typical check size
-- relevant portfolio companies
-- public thesis and recent activity
-- reasons the fund is or is not a fit
-- any obvious red flags or mismatches
-
-### Competitive Analysis
-Collect:
-- product reality, not marketing copy
-- funding and investor history if public
-- traction metrics if public
-- distribution and pricing clues
-- strengths, weaknesses, and positioning gaps
-
-### Market Sizing
-Use:
-- top-down estimates from reports or public datasets
-- bottom-up sanity checks from realistic customer acquisition assumptions
-- explicit assumptions for every leap in logic
-
-### Technology / Vendor Research
-Collect:
-- how it works
-- trade-offs and adoption signals
-- integration complexity
-- lock-in, security, compliance, and operational risk
-
-## Output Format
-
-Default structure:
-1. executive summary
-2. key findings
-3. implications
-4. risks and caveats
-5. recommendation
-6. sources
-
-## Quality Gate
-
-Before delivering:
-- all numbers are sourced or labeled as estimates
-- old data is flagged
-- the recommendation follows from the evidence
-- risks and counterarguments are included
-- the output makes a decision easier

package/.cursor/skills/mcp-server-patterns/SKILL.md

@@ -1,67 +0,0 @@
----
-name: mcp-server-patterns
-description: Build MCP servers with Node/TypeScript SDK — tools, resources, prompts, Zod validation, stdio vs Streamable HTTP. Use Context7 or official MCP docs for latest API.
-origin: ECC
----
-
-# MCP Server Patterns
-
-The Model Context Protocol (MCP) lets AI assistants call tools, read resources, and use prompts from your server. Use this skill when building or maintaining MCP servers. The SDK API evolves; check Context7 (query-docs for "MCP") or the official MCP documentation for current method names and signatures.
-
-## When to Use
-
-Use when: implementing a new MCP server, adding tools or resources, choosing stdio vs HTTP, upgrading the SDK, or debugging MCP registration and transport issues.
-
-## How It Works
-
-### Core concepts
-
-- **Tools**: Actions the model can invoke (e.g. search, run a command). Register with `registerTool()` or `tool()` depending on SDK version.
-- **Resources**: Read-only data the model can fetch (e.g. file contents, API responses). Register with `registerResource()` or `resource()`. Handlers typically receive a `uri` argument.
-- **Prompts**: Reusable, parameterised prompt templates the client can surface (e.g. in Claude Desktop). Register with `registerPrompt()` or equivalent.
-- **Transport**: stdio for local clients (e.g. Claude Desktop); Streamable HTTP is preferred for remote (Cursor, cloud). Legacy HTTP/SSE is for backward compatibility.
-
-The Node/TypeScript SDK may expose `tool()` / `resource()` or `registerTool()` / `registerResource()`; the official SDK has changed over time. Always verify against the current [MCP docs](https://modelcontextprotocol.io) or Context7.
-
-### Connecting with stdio
-
-For local clients, create a stdio transport and pass it to your server’s connect method. The exact API varies by SDK version (e.g. constructor vs factory). See the official MCP documentation or query Context7 for "MCP stdio server" for the current pattern.
-
-Keep server logic (tools + resources) independent of transport so you can plug in stdio or HTTP in the entrypoint.
-
-### Remote (Streamable HTTP)
-
-For Cursor, cloud, or other remote clients, use **Streamable HTTP** (single MCP HTTP endpoint per current spec). Support legacy HTTP/SSE only when backward compatibility is required.
-
-## Examples
-
-### Install and server setup
-
-```bash
-npm install @modelcontextprotocol/sdk zod
-```
-
-```typescript
-import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
-import { z } from "zod";
-
-const server = new McpServer({ name: "my-server", version: "1.0.0" });
-```
-
-Register tools and resources using the API your SDK version provides: some versions use `server.tool(name, description, schema, handler)` (positional args), others use `server.tool({ name, description, inputSchema }, handler)` or `registerTool()`. Same for resources — include a `uri` in the handler when the API provides it. Check the official MCP docs or Context7 for the current `@modelcontextprotocol/sdk` signatures to avoid copy-paste errors.
-
-Use **Zod** (or the SDK’s preferred schema format) for input validation.
-
-## Best Practices
-
-- **Schema first**: Define input schemas for every tool; document parameters and return shape.
-- **Errors**: Return structured errors or messages the model can interpret; avoid raw stack traces.
-- **Idempotency**: Prefer idempotent tools where possible so retries are safe.
-- **Rate and cost**: For tools that call external APIs, consider rate limits and cost; document in the tool description.
-- **Versioning**: Pin SDK version in package.json; check release notes when upgrading.
-
-## Official SDKs and Docs
-
-- **JavaScript/TypeScript**: `@modelcontextprotocol/sdk` (npm). Use Context7 with library name "MCP" for current registration and transport patterns.
-- **Go**: Official Go SDK on GitHub (`modelcontextprotocol/go-sdk`).
-- **C#**: Official C# SDK for .NET.

package/.cursor/skills/nextjs-turbopack/SKILL.md

@@ -1,44 +0,0 @@
----
-name: nextjs-turbopack
-description: Next.js 16+ and Turbopack — incremental bundling, FS caching, dev speed, and when to use Turbopack vs webpack.
-origin: ECC
----
-
-# Next.js and Turbopack
-
-Next.js 16+ uses Turbopack by default for local development: an incremental bundler written in Rust that significantly speeds up dev startup and hot updates.
-
-## When to Use
-
-- **Turbopack (default dev)**: Use for day-to-day development. Faster cold start and HMR, especially in large apps.
-- **Webpack (legacy dev)**: Use only if you hit a Turbopack bug or rely on a webpack-only plugin in dev. Disable with `--webpack` (or `--no-turbopack` depending on your Next.js version; check the docs for your release).
-- **Production**: Production build behavior (`next build`) may use Turbopack or webpack depending on Next.js version; check the official Next.js docs for your version.
-
-Use when: developing or debugging Next.js 16+ apps, diagnosing slow dev startup or HMR, or optimizing production bundles.
-
-## How It Works
-
-- **Turbopack**: Incremental bundler for Next.js dev. Uses file-system caching so restarts are much faster (e.g. 5–14x on large projects).
-- **Default in dev**: From Next.js 16, `next dev` runs with Turbopack unless disabled.
-- **File-system caching**: Restarts reuse previous work; cache is typically under `.next`; no extra config needed for basic use.
-- **Bundle Analyzer (Next.js 16.1+)**: Experimental Bundle Analyzer to inspect output and find heavy dependencies; enable via config or experimental flag (see Next.js docs for your version).
-
-## Examples
-
-### Commands
-
-```bash
-next dev
-next build
-next start
-```
-
-### Usage
-
-Run `next dev` for local development with Turbopack. Use the Bundle Analyzer (see Next.js docs) to optimize code-splitting and trim large dependencies. Prefer App Router and server components where possible.
-
-## Best Practices
-
-- Stay on a recent Next.js 16.x for stable Turbopack and caching behavior.
-- If dev is slow, ensure you're on Turbopack (default) and that the cache isn't being cleared unnecessarily.
-- For production bundle size issues, use the official Next.js bundle analysis tooling for your version.

package/.cursor/skills/performance-optimization/SKILL.md

@@ -1,77 +0,0 @@
----
-name: performance-optimization
-description: Optimizes performance with a measure-first workflow. Use when performance requirements exist, when regressions are suspected, or when user-visible speed and efficiency matter.
-origin: ECC
----
-
-# Performance Optimization
-
-## Overview
-
-Measure first, optimize second.
-Performance work should improve a real bottleneck, not just produce clever code.
-
-## When to Use
-
-- a feature has explicit performance budgets or SLAs
-- users or monitoring report slow behavior
-- Core Web Vitals or endpoint timings are regressing
-- large datasets, hot paths, or expensive rendering are involved
-- review identifies likely performance risk that needs proof
-
-**When NOT to use**
-
-- there is no measurement and no evidence of a problem
-- the "optimization" is really a speculative rewrite
-
-## Workflow
-
-1. Choose the performance goal.
-   Name the metric that matters:
-   - browser responsiveness
-   - Core Web Vitals
-   - API latency
-   - query efficiency
-   - throughput or batch time
-2. Establish a baseline.
-   Use `../../references/performance-checklist.md`.
-   Capture the current measurement before touching code.
-3. Localize the bottleneck.
-   Identify whether the cost is in:
-   - network
-   - rendering
-   - computation
-   - data access
-   - bundle or startup cost
-4. Apply the smallest meaningful fix.
-   Optimize the proven bottleneck, not the whole subsystem.
-5. Measure again.
-   Confirm the change improved the chosen metric and did not create a regression elsewhere.
-6. Guard the gain.
-   Add follow-up monitoring, benchmark expectations, or review notes so the regression is less likely to return.
-
-## Common Rationalizations
-
-| Rationalization | Reality |
-|---|---|
-| "This looks slow, so I'll optimize it now." | Visual intuition is not measurement. |
-| "I'll rewrite it for performance just in case." | Premature optimization adds complexity and often misses the real bottleneck. |
-| "A micro-optimization is better than no optimization." | Small cleverness is noise if the dominant cost lives elsewhere. |
-| "The benchmark is enough; user experience will follow." | Good optimization improves the metric that matters to the user or operator, not just the easiest one to measure. |
-
-## Red Flags
-
-- no baseline exists before code changes
-- the optimization changes multiple subsystems at once
-- claimed improvements are not measured after the fix
-- the new code is much harder to maintain for marginal gain
-
-## Verification
-
-After optimizing, confirm:
-
-- [ ] the target metric was explicit
-- [ ] a before/after measurement exists
-- [ ] the fix targeted the actual bottleneck
-- [ ] no obvious regression was introduced elsewhere
-- [ ] the performance gain is documented in a form reviewers can verify