@crewpilot/agent 1.0.0

package/prompts/skills/daily-digest/SKILL.md

@@ -0,0 +1,167 @@
+# Daily Digest
+
+> **Pillar**: Orchestrate | **ID**: `daily-digest`
+
+## Purpose
+
+Generate a comprehensive daily/weekly work summary by aggregating git activity, board changes, PR status, workflow completions, and knowledge entries — then deliver it via SMTP email or display in chat. Replaces manual status reporting entirely.
+
+## Activation Triggers
+
+- digest, daily report, daily summary, end of day, eod report, what did I do today, status report, send update, update PM, weekly summary, send email, standup report
+
+## Tools Required
+
+- `catalyst_git_log` — get commits for the time period
+- `catalyst_board_my_items` — get board items (opened, closed, in-progress)
+- `catalyst_worker_dashboard` — workflow completions and stats
+- `catalyst_knowledge_timeline` — decisions made in the period
+- `catalyst_exec` — run git/gh commands for additional data
+- `catalyst_notify_send` — deliver the report via email
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph daily_digest {
+    rankdir=LR;
+    node [shape=box];
+
+    collect [label="Phase 1\nData Collection\n(git, board, PRs,\nworkflows, knowledge)"];
+    generate [label="Phase 2\nReport Generation"];
+    deliver [label="Phase 3\nDelivery\n(email or chat)", shape=doublecircle];
+
+    collect -> generate;
+    generate -> deliver;
+}
+```
+
+### Phase 1 — Data Collection
+
+Gather from all sources for the requested time period (default: today):
+
+**Git Activity:**
+1. Call `catalyst_git_log` with `--since="today 00:00"` (or requested range)
+2. Extract: commit count, files changed, insertions/deletions, branches touched
+3. Group commits by scope/type (feat, fix, refactor, test, docs)
+
+**Board Activity:**
+1. Call `catalyst_exec` with `gh issue list --author=@me --state=all --json number,title,state,updatedAt,labels`
+2. Filter to items updated in the time period
+3. Categorize: created, moved to in-progress, closed/done, commented on
+
+**PR Activity:**
+1. Call `catalyst_exec` with `gh pr list --author=@me --state=all --json number,title,state,createdAt,mergedAt,reviewDecision`
+2. Filter to time period
+3. Categorize: opened, merged, review pending, changes requested
+
+**Workflow Activity:**
+1. Call `catalyst_worker_dashboard` for digital worker stats
+2. Filter completed/failed workflows in the period
+
+**Knowledge:**
+1. Call `catalyst_knowledge_timeline` for decisions and lessons stored today
+
+### Phase 2 — Report Generation
+
+Compose the report in this structure:
+
+```
+📊 Daily Digest — {date} — @{username}
+═══════════════════════════════════════
+
+📝 COMMITS ({count})
+  feat:     {count} — {summary of features}
+  fix:      {count} — {summary of fixes}
+  refactor: {count}
+  test:     {count}
+  other:    {count}
+  
+  Files changed: {N} | +{insertions} / -{deletions}
+
+📋 BOARD ACTIVITY
+  Created:     {N} items ({titles})
+  In Progress: {N} items ({titles})
+  Completed:   {N} items ({titles})
+  Blocked:     {N} items ({titles + reason})
+
+🔀 PULL REQUESTS
+  Opened:   {N} — {PR titles with numbers}
+  Merged:   {N} — {PR titles}
+  Pending:  {N} — {waiting on review / changes requested}
+
+🤖 DIGITAL WORKER
+  Workflows completed: {N}
+  Workflows in progress: {N}
+  Workflows failed: {N}
+
+💡 DECISIONS MADE
+  - {decision 1}
+  - {decision 2}
+
+───────────────────────────────────────
+Tomorrow's focus:
+  - {open items in-progress}
+  - {PRs waiting for review}
+  - {blockers to resolve}
+```
+
+### Phase 3 — Delivery
+
+Based on notification configuration:
+
+**Email (default when recipients configured):**
+1. Call `catalyst_notify_send` with subject: "Daily Digest — {date} — {project name}", body: full report
+2. Email sent automatically via SMTP (no manual interaction needed)
+3. Requires SMTP env vars or `catalyst_notify_configure` to be set up
+
+**Console (fallback when no recipients configured):**
+1. Just display the report in chat
+2. User can copy-paste to email manually
+
+### Phase 4 — Preview & Send
+
+**ALWAYS preview before sending:**
+
+```
+📊 Digest Preview:
+
+{full report}
+
+──────────────
+Send to: {recipient} via email?
+(yes / edit / just show)
+```
+
+- **yes** → send via email (opens mail client with pre-filled content)
+- **edit** → user modifies, re-preview
+- **just show** → output only, don't send (default if no recipients configured)
+
+## Weekly Summary Mode
+
+When triggered with "weekly summary" or "weekly digest":
+
+1. Aggregate across the full week (Mon-Fri)
+2. Add a "Week Highlights" section at the top
+3. Add trend comparison: "vs last week: +3 commits, +2 PRs, -1 blocker"
+4. Include sprint velocity trend chart (text-based)
+
+## Output Format
+
+- Use the structured template shown in Phase 2
+- Numbers first, details second
+- Emoji prefixes for quick scanning
+- Keep total report under 100 lines — summarize, don't enumerate every commit
+
+## Anti-Patterns
+
+- Do NOT send email without showing preview first
+- Do NOT include sensitive data (secrets, tokens, passwords found in code)
+- Do NOT fabricate activity — if nothing happened, say "quiet day"
+- Do NOT include full commit messages — summarize by category
+- Do NOT send to recipients not configured via catalyst_notify_configure
+
+## Chains To
+
+- `knowledge-base` — the digest itself can be stored as a daily record

package/prompts/skills/deliver-change-management/SKILL.md

@@ -0,0 +1,132 @@
+# Change Management
+
+> **Pillar**: Deliver | **ID**: `deliver-change-management`
+
+## Purpose
+
+Structured commit and release workflow. Enforces conventional commits, generates changelogs, manages semantic versioning, and ensures every change is traceable.
+
+## Activation Triggers
+
+- "commit this", "write a commit message", "what should the commit be"
+- "changelog", "release notes", "version bump"
+- Automatically chained after any skill that modifies code
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph change_management {
+    rankdir=TB;
+    node [shape=box];
+
+    analyze [label="Phase 1\nChange Analysis"];
+    message [label="Phase 2\nCommit Message Generation"];
+    group [label="Phase 3\nCommit Grouping", shape=diamond];
+    release [label="Phase 4\nRelease Notes", style=dashed];
+    done [label="Committed", shape=doublecircle];
+
+    analyze -> message;
+    message -> group;
+    group -> message [label="split into\nseparate commits"];
+    group -> done [label="single commit"];
+    done -> release [label="release requested"];
+}
+```
+
+### Phase 1 — Change Analysis
+1. Run `git status` and `git diff --staged` to understand what's changed
+2. If nothing is staged, analyze the working tree diff
+3. Categorize changes:
+   - **feat**: New functionality
+   - **fix**: Bug fix
+   - **refactor**: Code restructuring (no behavior change)
+   - **test**: Adding/modifying tests
+   - **docs**: Documentation only
+   - **perf**: Performance improvement
+   - **chore**: Build, CI, dependencies
+   - **security**: Security fix
+
+### Phase 2 — Commit Message Generation
+Follow the conventional commit format configured in `commit_format`:
+
+```
+{type}({scope}): {description}
+
+{body — what and why, not how}
+
+{footer — breaking changes, issue references}
+```
+
+Rules:
+- Subject line ≤ 72 characters
+- Scope is the affected module/component (inferred from file paths)
+- Body explains motivation if the change isn't obvious
+- `BREAKING CHANGE:` footer for breaking changes
+- Reference issues: `Closes #123`, `Fixes #456`
+
+### Phase 3 — Commit Grouping
+If multiple logical changes are staged:
+1. Suggest splitting into separate commits
+2. Provide the staging commands (`git add -p` guidance)
+3. Generate a commit message for each logical unit
+
+### Phase 4 — Release Notes (when requested)
+1. Parse commits since last tag
+2. Group by type (Features, Fixes, Breaking Changes, etc.)
+3. Generate human-readable release notes
+4. Suggest version bump based on commit types:
+   - `BREAKING CHANGE` → major
+   - `feat` → minor
+   - `fix`, `perf` → patch
+
+## Tools Required
+
+- `terminal` — Run git commands
+- `catalyst_git_status` — Get current state
+- `catalyst_git_diff` — Get detailed diff
+- `catalyst_git_log` — Parse commit history
+- `catalyst_git_stage` — Stage files
+- `catalyst_git_commit` — Execute commit
+
+## Output Format
+
+```
+## [Catalyst → Change Management]
+
+### Changes Detected
+| Type | Scope | Files |
+|---|---|---|
+| {type} | {scope} | {file list} |
+
+### Suggested Commit
+\`\`\`
+{type}({scope}): {description}
+
+{body}
+
+{footer}
+\`\`\`
+
+### Release Notes (if requested)
+## v{X.Y.Z}
+### Features
+- {description} ({hash})
+### Fixes
+- {description} ({hash})
+### Breaking Changes
+- {description} ({hash})
+```
+
+## Chains To
+
+- `doc-governance` — Check if changed code needs doc updates
+- `deploy-guard` — Pre-deployment safety after committing
+
+## Anti-Patterns
+
+- Do NOT write generic commit messages ("update code", "fix things")
+- Do NOT combine unrelated changes in one commit
+- Do NOT skip the body for non-obvious changes
+- Do NOT version bump without analyzing the commit history

package/prompts/skills/deliver-deploy-guard/SKILL.md

@@ -0,0 +1,144 @@
+# Deploy Guard
+
+> **Pillar**: Deliver | **ID**: `deliver-deploy-guard`
+
+## Purpose
+
+Pre-deployment safety validation. Runs a structured checklist of quality gates before any code ships — catches what CI/CD pipelines often miss. Acts as the last line of defense.
+
+## Activation Triggers
+
+- "ready to deploy?", "pre-deploy check", "can I ship this?"
+- "safety check", "deploy guard", "go/no-go"
+- Automatically chained after `change-management` when `phase_gates` is `strict`
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph deploy_guard {
+    rankdir=TB;
+    node [shape=box];
+
+    g1 [label="Gate 1\nCode Quality"];
+    g2 [label="Gate 2\nTest Integrity"];
+    g3 [label="Gate 3\nSecurity"];
+    g4 [label="Gate 4\nConfiguration"];
+    g5 [label="Gate 5\nBreaking Changes"];
+    g6 [label="Gate 6\nOperational Readiness"];
+    verdict [label="Verdict", shape=diamond, style=filled, fillcolor="#ffcccc"];
+    go [label="GO \u2705", shape=doublecircle, style=filled, fillcolor="#ccffcc"];
+    nogo [label="NO-GO \u274c", shape=octagon, style=filled, fillcolor="#ff9999"];
+    conditional [label="CONDITIONAL \u26a0\ufe0f", shape=box, style=filled, fillcolor="#ffffcc"];
+
+    g1 -> g2;
+    g2 -> g3;
+    g3 -> g4;
+    g4 -> g5;
+    g5 -> g6;
+    g6 -> verdict;
+    verdict -> go [label="all pass"];
+    verdict -> nogo [label="critical blocker"];
+    verdict -> conditional [label="non-critical\nwarnings"];
+}
+```
+
+### Gate 1 — Code Quality
+- [ ] All linting passes (zero errors)
+- [ ] No `TODO`/`FIXME`/`HACK` in files changed since last deploy
+- [ ] No `console.log`/`print`/debug statements in production paths
+- [ ] No commented-out code blocks
+- Run: `catalyst_metrics_complexity` on changed files — flag any high-complexity additions
+
+### Gate 2 — Test Integrity
+- [ ] All tests pass
+- [ ] Test coverage meets minimum threshold
+- [ ] No skipped tests (`.skip`, `@disabled`, `@pytest.mark.skip`)
+- [ ] No test files with zero assertions
+- Run: `catalyst_metrics_coverage` to validate
+
+### Gate 3 — Security
+- [ ] No new vulnerabilities from `vulnerability-scan`
+- [ ] No hardcoded secrets (API keys, passwords, tokens)
+- [ ] Dependencies have no critical CVEs
+- [ ] No `eval()`, `exec()`, `dangerouslySetInnerHTML` without sanitization
+- Run: `terminal` for `npm audit` / `pip audit` / equivalent
+
+### Gate 4 — Configuration
+- [ ] Environment variables documented and present
+- [ ] No development-only configuration in production paths
+- [ ] Database migrations are forward-compatible and reversible
+- [ ] Feature flags set correctly for this deployment
+
+### Gate 5 — Breaking Changes
+- [ ] API contract changes are backward-compatible (or versioned)
+- [ ] Database schema changes are additive (no column drops without migration)
+- [ ] No removed public exports/endpoints without deprecation period
+- [ ] Breaking changes documented in CHANGELOG
+
+### Gate 6 — Operational Readiness
+- [ ] Health check endpoint exists and responds
+- [ ] Logging is adequate for debugging production issues
+- [ ] Error handling returns appropriate HTTP status codes
+- [ ] Rate limiting is configured for public endpoints
+
+### Verdict
+
+<HARD-GATE>
+If the verdict is NO-GO, do NOT proceed with deployment, merge, or marking as ready.
+All critical blockers MUST be resolved and gates re-run before proceeding.
+Do NOT downgrade a NO-GO to CONDITIONAL without fixing the underlying issue.
+</HARD-GATE>
+
+Produce a clear GO / NO-GO / CONDITIONAL decision:
+- **GO**: All gates pass
+- **CONDITIONAL**: Non-critical issues found — list what to fix or accept
+- **NO-GO**: Critical blocker found — must fix before deployment
+
+## Tools Required
+
+- `terminal` — Run tests, linters, audit tools
+- `codebase` — Scan for anti-patterns, secrets, debug statements
+- `catalyst_metrics_coverage` — Coverage report
+- `catalyst_metrics_complexity` — Complexity scores
+- `catalyst_git_diff` — Changes since last deploy/tag
+
+## Output Format
+
+```
+## [Catalyst → Deploy Guard]
+
+### Gate Results
+
+| Gate | Status | Issues |
+|---|---|---|
+| Code Quality | {pass/warn/fail} | {count} |
+| Test Integrity | {pass/warn/fail} | {count} |
+| Security | {pass/warn/fail} | {count} |
+| Configuration | {pass/warn/fail} | {count} |
+| Breaking Changes | {pass/warn/fail} | {count} |
+| Operational Readiness | {pass/warn/fail} | {count} |
+
+### Blockers (if any)
+{critical issues that block deployment}
+
+### Warnings (if any)
+{non-critical issues to be aware of}
+
+### Verdict: {GO / NO-GO / CONDITIONAL}
+{reasoning}
+```
+
+## Chains To
+
+- `vulnerability-scan` — If security gate needs deeper analysis
+- `change-management` — Fix and recommit if issues found
+- `knowledge-base` — Record deployment decision and any exceptions made
+
+## Anti-Patterns
+
+- Do NOT always say GO — be honest about risks
+- Do NOT block on style issues — only on functional and security concerns
+- Do NOT check gates that aren't relevant (no DB gate for a pure frontend change)
+- Do NOT skip the verdict — always provide a clear decision

package/prompts/skills/deliver-doc-governance/SKILL.md

@@ -0,0 +1,130 @@
+# Doc Governance
+
+> **Pillar**: Deliver | **ID**: `deliver-doc-governance`
+
+## Purpose
+
+Documentation drift detection and synchronization. Ensures READMEs, API docs, and inline documentation stay accurate as code evolves. Treats documentation as a first-class deliverable.
+
+## Activation Triggers
+
+- "update docs", "docs are stale", "check documentation"
+- "sync README", "API docs", "documentation drift"
+- Automatically chained after `feature-builder` or `architecture-planner` when public APIs change
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph doc_governance {
+    rankdir=TB;
+    node [shape=box];
+
+    inventory [label="Phase 1\nDocumentation Inventory"];
+    drift [label="Phase 2\nDrift Detection"];
+    classify [label="Phase 3\nImpact Classification"];
+    fix [label="Phase 4\nRemediation"];
+    complete [label="Phase 5\nCompleteness Check", shape=doublecircle];
+
+    inventory -> drift;
+    drift -> classify [label="drift found"];
+    drift -> complete [label="no drift"];
+    classify -> fix;
+    fix -> complete;
+}
+```
+
+### Phase 1 — Documentation Inventory
+1. Locate all documentation files:
+   - `README.md` at root and in subdirectories
+   - `docs/` folder content
+   - API documentation (OpenAPI/Swagger, JSDoc, docstrings)
+   - Inline code comments in public interfaces
+   - `CHANGELOG.md`, `CONTRIBUTING.md`
+2. Map documentation → code relationships
+
+### Phase 2 — Drift Detection
+Compare documentation against current code:
+
+| Check | Method |
+|---|---|
+| **API signatures** | Compare documented function signatures vs. actual |
+| **Configuration** | Compare documented env vars/config vs. actual usage |
+| **Installation** | Verify documented install steps still work |
+| **Examples** | Check if code examples still compile/run |
+| **Architecture** | Compare documented structure vs. actual file tree |
+| **Dependencies** | Compare documented requirements vs. actual manifests |
+
+For each drift found:
+```
+DRIFT: {doc file}:{line} — {what's documented} ≠ {what's actual}
+```
+
+### Phase 3 — Impact Classification
+
+| Severity | Criteria |
+|---|---|
+| **Critical** | Wrong API usage instructions — will cause errors for users |
+| **High** | Missing documentation for new public features |
+| **Medium** | Outdated examples, stale screenshots, wrong file paths |
+| **Low** | Minor wording inaccuracies, formatting issues |
+
+### Phase 4 — Remediation
+For each drift:
+1. Generate the corrected documentation
+2. Preserve the existing documentation style and voice
+3. Add/update code examples that are verified to work
+4. Update any auto-generated content (table of contents, API reference)
+
+### Phase 5 — Completeness Check
+Verify minimum documentation exists:
+- [ ] README with project description, setup, usage
+- [ ] API documentation for all public interfaces
+- [ ] Configuration reference for all env vars/settings
+- [ ] Contributing guide (for open source)
+- [ ] Changelog (if releases are managed)
+
+## Tools Required
+
+- `codebase` — Read source code and documentation files
+- `terminal` — Verify install steps, run examples
+- `catalyst_knowledge_search` — Check if documentation decisions were previously recorded
+
+## Output Format
+
+```
+## [Catalyst → Doc Governance]
+
+### Documentation Map
+| Doc File | Covers | Status |
+|---|---|---|
+| {path} | {what it documents} | {current/stale/missing} |
+
+### Drift Detected
+#### [{severity}] {doc file}:{line}
+**Documented**: {what the doc says}
+**Actual**: {what the code does}
+**Fix**: {corrected content}
+
+---
+(repeat per drift)
+
+### Completeness
+{checklist with status}
+
+### Summary
+{N} drifts found: {critical}/{high}/{medium}/{low}
+```
+
+## Chains To
+
+- `change-management` — Commit documentation updates
+- `architecture-planner` — If architecture docs need major restructuring
+
+## Anti-Patterns
+
+- Do NOT rewrite documentation in a different voice/style
+- Do NOT add documentation for internal/private APIs unless asked
+- Do NOT remove valid documentation just because it's verbose
+- Do NOT generate placeholder documentation ("TODO: add docs")