titan-agent 6.5.3 → 7.0.0

package/assets/agent-skills/continuous-learning/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: continuous-learning
+description: "[DEPRECATED - use continuous-learning-v2] Legacy v1 stop-hook skill extractor. v2 is a strict superset with instinct-based, project-scoped, hook-reliable learning. Do not invoke v1; route continuous learning, session learning, and pattern extraction requests to continuous-learning-v2."
+origin: ECC
+---
+
+# Continuous Learning Skill - DEPRECATED
+
+> **DEPRECATED 2026-04-28.** Use `continuous-learning-v2` instead. v2 is a strict superset: stop-hook observation becomes PreToolUse/PostToolUse observation, full skills become atomic instincts with confidence scoring, and global-only storage becomes project-scoped plus global promotion.
+>
+> This file is kept for archival reference and backward compatibility with existing installs.
+
+---
+
+## Original v1 Documentation (archival)
+
+Automatically evaluates TITAN sessions on end to extract reusable patterns that can be saved as learned skills.
+
+## When to Activate
+
+- Setting up automatic pattern extraction from TITAN sessions
+- Configuring the Stop hook for session evaluation
+- Reviewing or curating learned skills in `~/.claude/skills/learned/`
+- Adjusting extraction thresholds or pattern categories
+- Comparing v1 (this) vs v2 (instinct-based) approaches
+
+## Status
+
+This v1 skill is still supported, but `continuous-learning-v2` is the preferred path for new installs. Keep v1 when you explicitly want the simpler Stop-hook extraction flow or need compatibility with older learned-skill workflows.
+
+## How It Works
+
+This skill runs as a **Stop hook** at the end of each session:
+
+1. **Session Evaluation**: Checks if session has enough messages (default: 10+)
+2. **Pattern Detection**: Identifies extractable patterns from the session
+3. **Skill Extraction**: Saves useful patterns to `~/.claude/skills/learned/`
+
+## Configuration
+
+Edit `config.json` to customize:
+
+```json
+{
+  "min_session_length": 10,
+  "extraction_threshold": "medium",
+  "auto_approve": false,
+  "learned_skills_path": "~/.claude/skills/learned/",
+  "patterns_to_detect": [
+    "error_resolution",
+    "user_corrections",
+    "workarounds",
+    "debugging_techniques",
+    "project_specific"
+  ],
+  "ignore_patterns": [
+    "simple_typos",
+    "one_time_fixes",
+    "external_api_issues"
+  ]
+}
+```
+
+## Pattern Types
+
+| Pattern | Description |
+|---------|-------------|
+| `error_resolution` | How specific errors were resolved |
+| `user_corrections` | Patterns from user corrections |
+| `workarounds` | Solutions to framework/library quirks |
+| `debugging_techniques` | Effective debugging approaches |
+| `project_specific` | Project-specific conventions |
+
+## Hook Setup
+
+Add to your `~/.claude/settings.json`:
+
+```json
+{
+  "hooks": {
+    "Stop": [{
+      "matcher": "*",
+      "hooks": [{
+        "type": "command",
+        "command": "~/.claude/skills/continuous-learning/evaluate-session.sh"
+      }]
+    }]
+  }
+}
+```
+
+## Why Stop Hook?
+
+- **Lightweight**: Runs once at session end
+- **Non-blocking**: Doesn't add latency to every message
+- **Complete context**: Has access to full session transcript
+
+## Related
+
+- [The Longform Guide](https://x.com/affaanmustafa/status/2014040193557471352) - Section on continuous learning
+- `/learn` command - Manual pattern extraction mid-session
+
+---
+
+## Comparison Notes (Research: Jan 2025)
+
+### vs Homunculus
+
+Homunculus v2 takes a more sophisticated approach:
+
+| Feature | Our Approach | Homunculus v2 |
+|---------|--------------|---------------|
+| Observation | Stop hook (end of session) | PreToolUse/PostToolUse hooks (100% reliable) |
+| Analysis | Main context | Background agent (Haiku) |
+| Granularity | Full skills | Atomic "instincts" |
+| Confidence | None | 0.3-0.9 weighted |
+| Evolution | Direct to skill | Instincts → cluster → skill/command/agent |
+| Sharing | None | Export/import instincts |
+
+**Key insight from homunculus:**
+> "v1 relied on skills to observe. Skills are probabilistic—they fire ~50-80% of the time. v2 uses hooks for observation (100% reliable) and instincts as the atomic unit of learned behavior."
+
+### Potential v2 Enhancements
+
+1. **Instinct-based learning** - Smaller, atomic behaviors with confidence scoring
+2. **Background observer** - Haiku agent analyzing in parallel
+3. **Confidence decay** - Instincts lose confidence if contradicted
+4. **Domain tagging** - code-style, testing, git, debugging, etc.
+5. **Evolution path** - Cluster related instincts into skills/commands
+
+See: `docs/continuous-learning-v2-spec.md` for full spec.

package/assets/agent-skills/continuous-learning/config.json

@@ -0,0 +1,18 @@
+{
+  "min_session_length": 10,
+  "extraction_threshold": "medium",
+  "auto_approve": false,
+  "learned_skills_path": "~/.claude/skills/learned/",
+  "patterns_to_detect": [
+    "error_resolution",
+    "user_corrections",
+    "workarounds",
+    "debugging_techniques",
+    "project_specific"
+  ],
+  "ignore_patterns": [
+    "simple_typos",
+    "one_time_fixes",
+    "external_api_issues"
+  ]
+}

package/assets/agent-skills/continuous-learning/evaluate-session.sh

@@ -0,0 +1,69 @@
+#!/bin/bash
+# Continuous Learning - Session Evaluator
+# Runs on Stop hook to extract reusable patterns from Claude Code sessions
+#
+# Why Stop hook instead of UserPromptSubmit:
+# - Stop runs once at session end (lightweight)
+# - UserPromptSubmit runs every message (heavy, adds latency)
+#
+# Hook config (in ~/.claude/settings.json):
+# {
+#   "hooks": {
+#     "Stop": [{
+#       "matcher": "*",
+#       "hooks": [{
+#         "type": "command",
+#         "command": "~/.claude/skills/continuous-learning/evaluate-session.sh"
+#       }]
+#     }]
+#   }
+# }
+#
+# Patterns to detect: error_resolution, debugging_techniques, workarounds, project_specific
+# Patterns to ignore: simple_typos, one_time_fixes, external_api_issues
+# Extracted skills saved to: ~/.claude/skills/learned/
+
+set -e
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+CONFIG_FILE="$SCRIPT_DIR/config.json"
+LEARNED_SKILLS_PATH="${HOME}/.claude/skills/learned"
+MIN_SESSION_LENGTH=10
+
+# Load config if exists
+if [ -f "$CONFIG_FILE" ]; then
+  if ! command -v jq &>/dev/null; then
+    echo "[ContinuousLearning] jq is required to parse config.json but not installed, using defaults" >&2
+  else
+    MIN_SESSION_LENGTH=$(jq -r '.min_session_length // 10' "$CONFIG_FILE")
+    LEARNED_SKILLS_PATH=$(jq -r '.learned_skills_path // "~/.claude/skills/learned/"' "$CONFIG_FILE" | sed "s|~|$HOME|")
+  fi
+fi
+
+# Ensure learned skills directory exists
+mkdir -p "$LEARNED_SKILLS_PATH"
+
+# Get transcript path from stdin JSON (Claude Code hook input)
+# Falls back to env var for backwards compatibility
+stdin_data=$(cat)
+transcript_path=$(echo "$stdin_data" | grep -o '"transcript_path":"[^"]*"' | head -1 | cut -d'"' -f4)
+if [ -z "$transcript_path" ]; then
+  transcript_path="${CLAUDE_TRANSCRIPT_PATH:-}"
+fi
+
+if [ -z "$transcript_path" ] || [ ! -f "$transcript_path" ]; then
+  exit 0
+fi
+
+# Count messages in session
+message_count=$(grep -c '"type":"user"' "$transcript_path" 2>/dev/null || echo "0")
+
+# Skip short sessions
+if [ "$message_count" -lt "$MIN_SESSION_LENGTH" ]; then
+  echo "[ContinuousLearning] Session too short ($message_count messages), skipping" >&2
+  exit 0
+fi
+
+# Signal to Claude that session should be evaluated for extractable patterns
+echo "[ContinuousLearning] Session has $message_count messages - evaluate for extractable patterns" >&2
+echo "[ContinuousLearning] Save learned skills to: $LEARNED_SKILLS_PATH" >&2

package/assets/agent-skills/production-audit/SKILL.md

@@ -0,0 +1,206 @@
+---
+name: production-audit
+description: Local-evidence production readiness audit for shipped apps, pre-launch reviews, post-merge checks, and "what breaks in prod?" questions without sending repo data to an external audit service.
+origin: community
+---
+
+# Production Audit
+
+Use this skill when the user asks whether an application is ready to ship, what
+could break in production, or what must be fixed before a launch. This is a
+maintainer-safe rewrite of the stale community production-audit idea: it keeps
+the useful production-readiness lens and removes unpinned external execution and
+third-party data sharing.
+
+## When to Use
+
+- The user asks "is this production-ready", "what would break in prod", "what
+  did we miss", "audit this repo", or "ready to ship?"
+- A feature was merged and needs a pre-deploy or post-merge risk pass.
+- A public launch, demo, customer rollout, or investor walkthrough is close.
+- CI is green but the user wants production risk, not only test status.
+- A deployed URL, release branch, PR, or current checkout is available for
+  evidence gathering.
+
+## When Not to Use
+
+- During active implementation when the right lens is line-level secure coding;
+  use `security-review` first.
+- For pure libraries, templates, docs-only repos, or scaffolds unless the user
+  wants packaging/release readiness rather than application readiness.
+- When the user asks for a formal compliance audit. This skill is engineering
+  triage, not legal, financial, medical, or regulatory certification.
+- When the only available evidence is a product idea with no repo, deployment,
+  CI, or runtime surface.
+
+## How It Works
+
+Build the audit from local and user-authorized evidence. Do not run unpinned
+remote code, upload repository contents to third-party services, or call
+external scanners unless the user explicitly approves that specific tool and
+data flow.
+
+Use this order:
+
+1. Establish the release surface.
+2. Read recent changes and current branch state.
+3. Inspect runtime, auth, data, payment, background-job, AI, and deployment
+   boundaries that actually exist in the repo.
+4. Check CI, tests, migrations, environment documentation, and rollback path.
+5. Produce a short ship/block recommendation with specific fixes.
+
+## Evidence Checklist
+
+Start with cheap, local signals:
+
+```text
+git status --short --branch
+git log --oneline --decorate -20
+git diff --stat origin/main...HEAD
+```
+
+Then inspect the project-specific surface:
+
+- Package scripts, CI workflows, release scripts, Docker files, and deployment
+  manifests.
+- API routes, webhooks, auth middleware, background workers, cron jobs, and
+  database migrations.
+- Environment variable documentation and startup checks.
+- Observability hooks, error reporting, logs, health checks, and dashboards.
+- Rollback, seed, migration, and backfill instructions.
+- E2E coverage for the user paths that matter most.
+
+If a deployed URL is in scope, use browser or HTTP checks only against that URL
+and avoid credentialed actions unless the user supplies a safe test account.
+
+## Risk Lenses
+
+### Security And Auth
+
+- Are public routes, API routes, and admin routes clearly separated?
+- Are auth and authorization enforced server-side?
+- Are secrets kept out of client bundles, logs, example output, and checked-in
+  files?
+- Are rate limits, CSRF protections, CORS policy, and upload validation present
+  where the app needs them?
+- Does the AI or agent surface defend against prompt injection, tool abuse, and
+  untrusted content crossing into privileged actions?
+
+### Data Integrity
+
+- Do migrations run forward cleanly and have a rollback or recovery plan?
+- Are destructive migrations, backfills, and data imports staged safely?
+- Do database policies, grants, and service-role boundaries match the app's
+  tenancy model?
+- Are retries idempotent for writes, jobs, and webhook handlers?
+
+### Payments And Webhooks
+
+- Are webhook signatures verified before parsing trusted payload fields?
+- Is each payment, subscription, or fulfillment webhook idempotent?
+- Are replay, duplicate delivery, and out-of-order delivery handled?
+- Are test-mode and live-mode credentials separated?
+
+### Operations
+
+- Can the app start from a clean checkout using documented commands?
+- Are required environment variables named, validated, and fail-fast?
+- Is there a health check that proves dependencies are reachable?
+- Are deploy, rollback, and incident-owner paths documented?
+- Are logs useful without leaking secrets or personal data?
+
+### User Experience
+
+- Are the launch-critical paths covered on desktop and mobile?
+- Are forms usable on mobile without input zoom, layout overlap, or blocked
+  submission states?
+- Do loading, empty, error, and permission-denied states tell the user what
+  happened?
+- Is there a support or recovery path when a critical operation fails?
+
+## Scoring
+
+Use scores to force prioritization, not to imply mathematical certainty.
+
+| Band | Score | Meaning |
+| --- | --- | --- |
+| Blocked | 0-49 | Do not ship until the top risks are fixed |
+| Risky | 50-69 | Ship only behind a small rollout or internal beta |
+| Launchable With Caveats | 70-84 | Ship if owners accept the listed risks |
+| Strong | 85-100 | No obvious launch blockers from available evidence |
+
+Cap the score at `69` if any of these are true:
+
+- Authentication or authorization is missing on sensitive data.
+- Payment or fulfillment webhooks are not idempotent.
+- Required migrations cannot be run safely.
+- Secrets are exposed in client bundles, logs, or committed files.
+- There is no rollback path for a high-impact release.
+
+Cap the score at `84` if CI is not green or the launch-critical path was not
+tested end to end.
+
+## Output Format
+
+Lead with one sentence:
+
+```text
+Production audit: 76/100, launchable with caveats, with webhook idempotency and rollback docs as the two risks to fix before public launch.
+```
+
+Then list:
+
+- `Blockers`: must-fix items before deploy.
+- `High-value fixes`: next fixes if the user wants to improve the score.
+- `Evidence checked`: files, commands, CI, deployed URL, or PRs inspected.
+- `Evidence missing`: what would change confidence if provided.
+- `Next action`: one concrete fix or verification step.
+
+Keep strengths short. The user asked for readiness, so the useful answer is the
+remaining risk and the next action.
+
+## Example
+
+User:
+
+```text
+is this ready to ship?
+```
+
+Response:
+
+```text
+Production audit: 68/100, risky, because Stripe webhooks are verified but not idempotent and there is no rollback note for the pending migration.
+
+Blockers:
+- Add idempotency for `checkout.session.completed` before fulfilling orders.
+- Write and test the rollback path for `20260511_add_billing_state.sql`.
+
+High-value fixes:
+- Add a health check that verifies database and payment-provider reachability.
+- Add one E2E path for upgrade, webhook fulfillment, and billing-page refresh.
+
+Evidence checked:
+- `api/stripe/webhook.ts`
+- `db/migrations/20260511_add_billing_state.sql`
+- GitHub Actions run for the release branch
+
+Next action: Want me to patch webhook idempotency first?
+```
+
+## Anti-Patterns
+
+- Running `npx <package>@latest` or a remote scanner as the default audit path.
+- Uploading source, secrets, customer data, or private topology to an external
+  audit service without explicit approval.
+- Producing a score without naming the evidence checked.
+- Treating green CI as production readiness.
+- Ending with a generic "let me know what you want to do."
+
+## See Also
+
+- Skill: `security-review`
+- Skill: `deployment-patterns`
+- Skill: `e2e-testing`
+- Skill: `tdd-workflow`
+- Skill: `verification-loop`

package/assets/agent-skills/recursive-decision-ledger/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: recursive-decision-ledger
+description: Use when the user asks for repeated rollouts, marked decision processes, high-dimensional search, stochastic optimization, local-optima exploration, ensemble comparison, or recursive reasoning with a visible evidence trail.
+origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Recursive Decision Ledger
+
+Use this skill when the user is trying to force deeper computation through
+repeated rollouts or "Prime Gauss" style recursive prompting. Preserve the useful
+part: repeated trials, prior memory, fresh information, and explicit marks.
+Remove the unsafe part: pretending the loop proves certainty.
+
+## Ledger Contract
+
+Every rollout should record:
+
+- rollout id and timestamp;
+- prior accepted winner and prior watchlist;
+- fresh information ingested;
+- search space size;
+- model families or heuristics used;
+- trial count and effective trial count;
+- top candidates;
+- decision marks;
+- coherence marks against the prior ledger;
+- promotion gate result.
+
+Prefer JSONL for append-only ledgers and Markdown for human summaries.
+
+## Rollout Loop
+
+1. Load the prior ledger.
+2. Capture new information at time-step zero.
+3. Run the bounded search.
+4. Mark each candidate: accept, watch, reject, decay watch, or needs replay.
+5. Compare winners against prior winners and latest marked rollout.
+6. Downgrade candidates when drift, tail risk, stale data, or failed replay
+   invalidates the previous mark.
+7. Append artifacts before summarizing.
+
+## Coherence Mark
+
+Include a compact coherence mark:
+
+```text
+Ensemble matches prior winner: true
+Recursive matches prior winner: false
+Latest rollout match: true
+Live promotion allowed: false
+Reason: replay and freshness gates not satisfied
+```
+
+## Promotion Rules
+
+For trading, capital allocation, production deploys, migrations, or destructive
+ops, recursive confidence is not approval.
+
+Default to paper, dry-run, read-only, preview, or staged mode unless the user
+explicitly approves the live action and the repo/service gate supports it.
+
+Promote only when:
+
+- the candidate beats the prior accepted winner on the chosen metric;
+- correctness and replay checks pass;
+- risk limits are explicit;
+- the evidence is durable;
+- the user has approved the live step when needed.
+
+## Summary Shape
+
+Lead with the decision, not the drama:
+
+```text
+Rollout 15 complete. The prior winner still holds, but edge deteriorated 17%.
+Status: watch, not live. Next gate: 20 replay fills with fresh orderbook age
+below threshold.
+```

package/assets/agent-skills/scientific-thinking-literature-review/SKILL.md

@@ -0,0 +1,192 @@
+---
+name: literature-review
+description: Systematic literature-review workflow for academic, biomedical, technical, and scientific topics, including search planning, source screening, synthesis, citation checks, and evidence logging.
+origin: community
+---
+
+# Literature Review
+
+Use this skill when the task is to find, screen, synthesize, and cite a body of
+academic or technical literature.
+
+## When to Use
+
+- Building a systematic, scoping, or narrative literature review.
+- Synthesizing the state of the art for a research question.
+- Finding gaps, contradictions, or future-work directions.
+- Preparing citation-backed background sections for papers or reports.
+- Comparing evidence across peer-reviewed papers, preprints, patents, and
+  technical reports.
+
+## Review Types
+
+- **Narrative review**: broad synthesis; useful for orientation.
+- **Scoping review**: maps concepts, methods, and evidence gaps.
+- **Systematic review**: predefined protocol, reproducible search, explicit
+  screening and exclusion.
+- **Meta-analysis**: systematic review plus quantitative effect aggregation.
+
+Ask the user which level of rigor is needed. If unspecified, default to a
+scoping review for exploratory work and a systematic review for publication or
+clinical claims.
+
+## Workflow
+
+### 1. Define the Question
+
+Convert the prompt into a searchable research question.
+
+For clinical or biomedical work, use PICO:
+
+- Population
+- Intervention or exposure
+- Comparator
+- Outcome
+
+For technical work, use:
+
+- system or domain
+- method or intervention
+- comparison baseline
+- evaluation metric
+
+### 2. Plan the Search
+
+Create a search protocol before collecting sources:
+
+- databases to search
+- date range
+- languages
+- publication types
+- inclusion criteria
+- exclusion criteria
+- exact search strings
+
+Minimum useful database set:
+
+- PubMed for biomedical and life-sciences literature.
+- arXiv for CS, math, physics, quantitative biology, and preprints.
+- Semantic Scholar or Crossref for broad academic discovery.
+- Domain-specific sources when relevant, such as clinical-trial registries,
+  patent databases, standards bodies, or official technical docs.
+
+### 3. Search and Log Evidence
+
+Keep a search log that makes the review reproducible:
+
+```markdown
+| Database | Date searched | Query | Filters | Results | Export |
+| --- | --- | --- | --- | ---: | --- |
+| PubMed | 2026-05-11 | `("CRISPR"[tiab] OR "Cas9"[tiab]) AND "sickle cell"[tiab]` | 2020:2026, English | 86 | PMID list |
+| arXiv | 2026-05-11 | `CRISPR sickle cell gene editing` | q-bio, 2020:2026 | 9 | BibTeX |
+```
+
+Save raw IDs, URLs, DOIs, abstracts, and notes separately from the final prose.
+
+### 4. Deduplicate
+
+Deduplicate in this order:
+
+1. DOI
+2. PMID or arXiv ID
+3. exact title
+4. normalized title plus first author and year
+
+Record how many duplicates were removed.
+
+### 5. Screen Sources
+
+Screen in stages:
+
+1. title
+2. abstract
+3. full text
+
+For systematic work, record exclusion reasons:
+
+- wrong population
+- wrong intervention
+- wrong outcome
+- not primary research
+- duplicate
+- unavailable full text
+- outside date range
+
+### 6. Extract Data
+
+Use a structured extraction table:
+
+```markdown
+| Study | Design | Population/Data | Method | Comparator | Outcome | Key finding | Limitations |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| Author Year | RCT/cohort/review/etc. | sample or corpus | method | baseline | measured outcome | result | caveat |
+```
+
+For technical papers, include dataset, benchmark, metric, baseline, and
+reproducibility notes.
+
+### 7. Synthesize
+
+Group evidence by theme rather than summarizing papers one by one.
+
+Useful synthesis lenses:
+
+- strongest evidence
+- conflicting evidence
+- methodological weaknesses
+- population or dataset limits
+- recency and replication
+- practical implications
+- unanswered questions
+
+Separate claims by confidence:
+
+- **High confidence**: replicated, high-quality evidence across sources.
+- **Medium confidence**: plausible but limited by sample, method, or recency.
+- **Low confidence**: early, speculative, single-source, or weakly measured.
+
+### 8. Verify Citations
+
+Before finalizing:
+
+- verify DOI, PMID, arXiv ID, or official URL
+- check author names and publication year
+- do not cite a paper for a claim it does not make
+- mark preprints as preprints
+- distinguish reviews from primary evidence
+
+## Output Template
+
+```markdown
+# Literature Review: <Topic>
+
+Generated: <date>
+Review type: <narrative | scoping | systematic | meta-analysis>
+Search window: <dates>
+Databases: <list>
+
+## Research Question
+
+## Search Strategy
+
+## Inclusion and Exclusion Criteria
+
+## Evidence Summary
+
+## Thematic Synthesis
+
+## Gaps and Limitations
+
+## References
+
+## Search Log
+```
+
+## Pitfalls
+
+- Do not treat search snippets as evidence.
+- Do not mix preprints, reviews, and primary studies without labeling them.
+- Do not omit negative or conflicting findings.
+- Do not claim systematic-review rigor without a reproducible protocol.
+- Do not use a single database for a broad claim unless the scope is explicitly
+  limited to that database.