@cregis-dev/cckit 0.4.1 → 0.6.1

package/templates/ecc/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/templates/ecc/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/templates/ecc/skills/iterative-retrieval/SKILL.md

@@ -1,211 +0,0 @@
----
-name: iterative-retrieval
-description: Pattern for progressively refining context retrieval to solve the subagent context problem
-origin: ECC
----
-
-# Iterative Retrieval Pattern
-
-Solves the "context problem" in multi-agent workflows where subagents don't know what context they need until they start working.
-
-## When to Activate
-
-- Spawning subagents that need codebase context they cannot predict upfront
-- Building multi-agent workflows where context is progressively refined
-- Encountering "context too large" or "missing context" failures in agent tasks
-- Designing RAG-like retrieval pipelines for code exploration
-- Optimizing token usage in agent orchestration
-
-## The Problem
-
-Subagents are spawned with limited context. They don't know:
-- Which files contain relevant code
-- What patterns exist in the codebase
-- What terminology the project uses
-
-Standard approaches fail:
-- **Send everything**: Exceeds context limits
-- **Send nothing**: Agent lacks critical information
-- **Guess what's needed**: Often wrong
-
-## The Solution: Iterative Retrieval
-
-A 4-phase loop that progressively refines context:
-
-```
-┌─────────────────────────────────────────────┐
-│                                             │
-│   ┌──────────┐      ┌──────────┐            │
-│   │ DISPATCH │─────▶│ EVALUATE │            │
-│   └──────────┘      └──────────┘            │
-│        ▲                  │                 │
-│        │                  ▼                 │
-│   ┌──────────┐      ┌──────────┐            │
-│   │   LOOP   │◀─────│  REFINE  │            │
-│   └──────────┘      └──────────┘            │
-│                                             │
-│        Max 3 cycles, then proceed           │
-└─────────────────────────────────────────────┘
-```
-
-### Phase 1: DISPATCH
-
-Initial broad query to gather candidate files:
-
-```javascript
-// Start with high-level intent
-const initialQuery = {
-  patterns: ['src/**/*.ts', 'lib/**/*.ts'],
-  keywords: ['authentication', 'user', 'session'],
-  excludes: ['*.test.ts', '*.spec.ts']
-};
-
-// Dispatch to retrieval agent
-const candidates = await retrieveFiles(initialQuery);
-```
-
-### Phase 2: EVALUATE
-
-Assess retrieved content for relevance:
-
-```javascript
-function evaluateRelevance(files, task) {
-  return files.map(file => ({
-    path: file.path,
-    relevance: scoreRelevance(file.content, task),
-    reason: explainRelevance(file.content, task),
-    missingContext: identifyGaps(file.content, task)
-  }));
-}
-```
-
-Scoring criteria:
-- **High (0.8-1.0)**: Directly implements target functionality
-- **Medium (0.5-0.7)**: Contains related patterns or types
-- **Low (0.2-0.4)**: Tangentially related
-- **None (0-0.2)**: Not relevant, exclude
-
-### Phase 3: REFINE
-
-Update search criteria based on evaluation:
-
-```javascript
-function refineQuery(evaluation, previousQuery) {
-  return {
-    // Add new patterns discovered in high-relevance files
-    patterns: [...previousQuery.patterns, ...extractPatterns(evaluation)],
-
-    // Add terminology found in codebase
-    keywords: [...previousQuery.keywords, ...extractKeywords(evaluation)],
-
-    // Exclude confirmed irrelevant paths
-    excludes: [...previousQuery.excludes, ...evaluation
-      .filter(e => e.relevance < 0.2)
-      .map(e => e.path)
-    ],
-
-    // Target specific gaps
-    focusAreas: evaluation
-      .flatMap(e => e.missingContext)
-      .filter(unique)
-  };
-}
-```
-
-### Phase 4: LOOP
-
-Repeat with refined criteria (max 3 cycles):
-
-```javascript
-async function iterativeRetrieve(task, maxCycles = 3) {
-  let query = createInitialQuery(task);
-  let bestContext = [];
-
-  for (let cycle = 0; cycle < maxCycles; cycle++) {
-    const candidates = await retrieveFiles(query);
-    const evaluation = evaluateRelevance(candidates, task);
-
-    // Check if we have sufficient context
-    const highRelevance = evaluation.filter(e => e.relevance >= 0.7);
-    if (highRelevance.length >= 3 && !hasCriticalGaps(evaluation)) {
-      return highRelevance;
-    }
-
-    // Refine and continue
-    query = refineQuery(evaluation, query);
-    bestContext = mergeContext(bestContext, highRelevance);
-  }
-
-  return bestContext;
-}
-```
-
-## Practical Examples
-
-### Example 1: Bug Fix Context
-
-```
-Task: "Fix the authentication token expiry bug"
-
-Cycle 1:
-  DISPATCH: Search for "token", "auth", "expiry" in src/**
-  EVALUATE: Found auth.ts (0.9), tokens.ts (0.8), user.ts (0.3)
-  REFINE: Add "refresh", "jwt" keywords; exclude user.ts
-
-Cycle 2:
-  DISPATCH: Search refined terms
-  EVALUATE: Found session-manager.ts (0.95), jwt-utils.ts (0.85)
-  REFINE: Sufficient context (2 high-relevance files)
-
-Result: auth.ts, tokens.ts, session-manager.ts, jwt-utils.ts
-```
-
-### Example 2: Feature Implementation
-
-```
-Task: "Add rate limiting to API endpoints"
-
-Cycle 1:
-  DISPATCH: Search "rate", "limit", "api" in routes/**
-  EVALUATE: No matches - codebase uses "throttle" terminology
-  REFINE: Add "throttle", "middleware" keywords
-
-Cycle 2:
-  DISPATCH: Search refined terms
-  EVALUATE: Found throttle.ts (0.9), middleware/index.ts (0.7)
-  REFINE: Need router patterns
-
-Cycle 3:
-  DISPATCH: Search "router", "express" patterns
-  EVALUATE: Found router-setup.ts (0.8)
-  REFINE: Sufficient context
-
-Result: throttle.ts, middleware/index.ts, router-setup.ts
-```
-
-## Integration with Agents
-
-Use in agent prompts:
-
-```markdown
-When retrieving context for this task:
-1. Start with broad keyword search
-2. Evaluate each file's relevance (0-1 scale)
-3. Identify what context is still missing
-4. Refine search criteria and repeat (max 3 cycles)
-5. Return files with relevance >= 0.7
-```
-
-## Best Practices
-
-1. **Start broad, narrow progressively** - Don't over-specify initial queries
-2. **Learn codebase terminology** - First cycle often reveals naming conventions
-3. **Track what's missing** - Explicit gap identification drives refinement
-4. **Stop at "good enough"** - 3 high-relevance files beats 10 mediocre ones
-5. **Exclude confidently** - Low-relevance files won't become relevant
-
-## Related
-
-- [The Longform Guide](https://x.com/affaanmustafa/status/2014040193557471352) - Subagent orchestration section
-- `continuous-learning` skill - For patterns that improve over time
-- Agent definitions in `~/.claude/agents/`

package/templates/ecc/skills/java-coding-standards/SKILL.md

@@ -1,147 +0,0 @@
----
-name: java-coding-standards
-description: "Java coding standards for Spring Boot services: naming, immutability, Optional usage, streams, exceptions, generics, and project layout."
-origin: ECC
----
-
-# Java Coding Standards
-
-Standards for readable, maintainable Java (17+) code in Spring Boot services.
-
-## When to Activate
-
-- Writing or reviewing Java code in Spring Boot projects
-- Enforcing naming, immutability, or exception handling conventions
-- Working with records, sealed classes, or pattern matching (Java 17+)
-- Reviewing use of Optional, streams, or generics
-- Structuring packages and project layout
-
-## Core Principles
-
-- Prefer clarity over cleverness
-- Immutable by default; minimize shared mutable state
-- Fail fast with meaningful exceptions
-- Consistent naming and package structure
-
-## Naming
-
-```java
-// ✅ Classes/Records: PascalCase
-public class MarketService {}
-public record Money(BigDecimal amount, Currency currency) {}
-
-// ✅ Methods/fields: camelCase
-private final MarketRepository marketRepository;
-public Market findBySlug(String slug) {}
-
-// ✅ Constants: UPPER_SNAKE_CASE
-private static final int MAX_PAGE_SIZE = 100;
-```
-
-## Immutability
-
-```java
-// ✅ Favor records and final fields
-public record MarketDto(Long id, String name, MarketStatus status) {}
-
-public class Market {
-  private final Long id;
-  private final String name;
-  // getters only, no setters
-}
-```
-
-## Optional Usage
-
-```java
-// ✅ Return Optional from find* methods
-Optional<Market> market = marketRepository.findBySlug(slug);
-
-// ✅ Map/flatMap instead of get()
-return market
-    .map(MarketResponse::from)
-    .orElseThrow(() -> new EntityNotFoundException("Market not found"));
-```
-
-## Streams Best Practices
-
-```java
-// ✅ Use streams for transformations, keep pipelines short
-List<String> names = markets.stream()
-    .map(Market::name)
-    .filter(Objects::nonNull)
-    .toList();
-
-// ❌ Avoid complex nested streams; prefer loops for clarity
-```
-
-## Exceptions
-
-- Use unchecked exceptions for domain errors; wrap technical exceptions with context
-- Create domain-specific exceptions (e.g., `MarketNotFoundException`)
-- Avoid broad `catch (Exception ex)` unless rethrowing/logging centrally
-
-```java
-throw new MarketNotFoundException(slug);
-```
-
-## Generics and Type Safety
-
-- Avoid raw types; declare generic parameters
-- Prefer bounded generics for reusable utilities
-
-```java
-public <T extends Identifiable> Map<Long, T> indexById(Collection<T> items) { ... }
-```
-
-## Project Structure (Maven/Gradle)
-
-```
-src/main/java/com/example/app/
-  config/
-  controller/
-  service/
-  repository/
-  domain/
-  dto/
-  util/
-src/main/resources/
-  application.yml
-src/test/java/... (mirrors main)
-```
-
-## Formatting and Style
-
-- Use 2 or 4 spaces consistently (project standard)
-- One public top-level type per file
-- Keep methods short and focused; extract helpers
-- Order members: constants, fields, constructors, public methods, protected, private
-
-## Code Smells to Avoid
-
-- Long parameter lists → use DTO/builders
-- Deep nesting → early returns
-- Magic numbers → named constants
-- Static mutable state → prefer dependency injection
-- Silent catch blocks → log and act or rethrow
-
-## Logging
-
-```java
-private static final Logger log = LoggerFactory.getLogger(MarketService.class);
-log.info("fetch_market slug={}", slug);
-log.error("failed_fetch_market slug={}", slug, ex);
-```
-
-## Null Handling
-
-- Accept `@Nullable` only when unavoidable; otherwise use `@NonNull`
-- Use Bean Validation (`@NotNull`, `@NotBlank`) on inputs
-
-## Testing Expectations
-
-- JUnit 5 + AssertJ for fluent assertions
-- Mockito for mocking; avoid partial mocks where possible
-- Favor deterministic tests; no hidden sleeps
-
-**Remember**: Keep code intentional, typed, and observable. Optimize for maintainability over micro-optimizations unless proven necessary.

package/templates/ecc/skills/jpa-patterns/SKILL.md

@@ -1,151 +0,0 @@
----
-name: jpa-patterns
-description: JPA/Hibernate patterns for entity design, relationships, query optimization, transactions, auditing, indexing, pagination, and pooling in Spring Boot.
-origin: ECC
----
-
-# JPA/Hibernate Patterns
-
-Use for data modeling, repositories, and performance tuning in Spring Boot.
-
-## When to Activate
-
-- Designing JPA entities and table mappings
-- Defining relationships (@OneToMany, @ManyToOne, @ManyToMany)
-- Optimizing queries (N+1 prevention, fetch strategies, projections)
-- Configuring transactions, auditing, or soft deletes
-- Setting up pagination, sorting, or custom repository methods
-- Tuning connection pooling (HikariCP) or second-level caching
-
-## Entity Design
-
-```java
-@Entity
-@Table(name = "markets", indexes = {
-  @Index(name = "idx_markets_slug", columnList = "slug", unique = true)
-})
-@EntityListeners(AuditingEntityListener.class)
-public class MarketEntity {
-  @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
-  private Long id;
-
-  @Column(nullable = false, length = 200)
-  private String name;
-
-  @Column(nullable = false, unique = true, length = 120)
-  private String slug;
-
-  @Enumerated(EnumType.STRING)
-  private MarketStatus status = MarketStatus.ACTIVE;
-
-  @CreatedDate private Instant createdAt;
-  @LastModifiedDate private Instant updatedAt;
-}
-```
-
-Enable auditing:
-```java
-@Configuration
-@EnableJpaAuditing
-class JpaConfig {}
-```
-
-## Relationships and N+1 Prevention
-
-```java
-@OneToMany(mappedBy = "market", cascade = CascadeType.ALL, orphanRemoval = true)
-private List<PositionEntity> positions = new ArrayList<>();
-```
-
-- Default to lazy loading; use `JOIN FETCH` in queries when needed
-- Avoid `EAGER` on collections; use DTO projections for read paths
-
-```java
-@Query("select m from MarketEntity m left join fetch m.positions where m.id = :id")
-Optional<MarketEntity> findWithPositions(@Param("id") Long id);
-```
-
-## Repository Patterns
-
-```java
-public interface MarketRepository extends JpaRepository<MarketEntity, Long> {
-  Optional<MarketEntity> findBySlug(String slug);
-
-  @Query("select m from MarketEntity m where m.status = :status")
-  Page<MarketEntity> findByStatus(@Param("status") MarketStatus status, Pageable pageable);
-}
-```
-
-- Use projections for lightweight queries:
-```java
-public interface MarketSummary {
-  Long getId();
-  String getName();
-  MarketStatus getStatus();
-}
-Page<MarketSummary> findAllBy(Pageable pageable);
-```
-
-## Transactions
-
-- Annotate service methods with `@Transactional`
-- Use `@Transactional(readOnly = true)` for read paths to optimize
-- Choose propagation carefully; avoid long-running transactions
-
-```java
-@Transactional
-public Market updateStatus(Long id, MarketStatus status) {
-  MarketEntity entity = repo.findById(id)
-      .orElseThrow(() -> new EntityNotFoundException("Market"));
-  entity.setStatus(status);
-  return Market.from(entity);
-}
-```
-
-## Pagination
-
-```java
-PageRequest page = PageRequest.of(pageNumber, pageSize, Sort.by("createdAt").descending());
-Page<MarketEntity> markets = repo.findByStatus(MarketStatus.ACTIVE, page);
-```
-
-For cursor-like pagination, include `id > :lastId` in JPQL with ordering.
-
-## Indexing and Performance
-
-- Add indexes for common filters (`status`, `slug`, foreign keys)
-- Use composite indexes matching query patterns (`status, created_at`)
-- Avoid `select *`; project only needed columns
-- Batch writes with `saveAll` and `hibernate.jdbc.batch_size`
-
-## Connection Pooling (HikariCP)
-
-Recommended properties:
-```
-spring.datasource.hikari.maximum-pool-size=20
-spring.datasource.hikari.minimum-idle=5
-spring.datasource.hikari.connection-timeout=30000
-spring.datasource.hikari.validation-timeout=5000
-```
-
-For PostgreSQL LOB handling, add:
-```
-spring.jpa.properties.hibernate.jdbc.lob.non_contextual_creation=true
-```
-
-## Caching
-
-- 1st-level cache is per EntityManager; avoid keeping entities across transactions
-- For read-heavy entities, consider second-level cache cautiously; validate eviction strategy
-
-## Migrations
-
-- Use Flyway or Liquibase; never rely on Hibernate auto DDL in production
-- Keep migrations idempotent and additive; avoid dropping columns without plan
-
-## Testing Data Access
-
-- Prefer `@DataJpaTest` with Testcontainers to mirror production
-- Assert SQL efficiency using logs: set `logging.level.org.hibernate.SQL=DEBUG` and `logging.level.org.hibernate.orm.jdbc.bind=TRACE` for parameter values
-
-**Remember**: Keep entities lean, queries intentional, and transactions short. Prevent N+1 with fetch strategies and projections, and index for your read/write paths.