Agent Skills: Kriya (क्रिया) — Materialise Soul Discoveries into Code

Kriya (क्रिया) — Materialise Soul Discoveries into Code

Kriya means "action, practice" — the applied counterpart to jnana (knowledge). Sadhanas and dreams accumulate findings; kriya turns them into shipped code.

Usage

/kriya              # Review all pending fixes and improvements
/kriya --dry-run    # Show pending findings without implementing anything
/kriya --all        # Apply all without interactive review (still asks before release)

How It Works

1. Surface — recall [fix], [solution], [improvement], [correction] memories not yet tagged [applied]
2. Review — present each finding; user accepts, skips, or stops
3. Implement — for accepted findings, read the relevant source and apply the change
4. Build — cmake --build build --parallel
5. Deploy — the orchestrator follows canonical CLAUDE.md after review; implementation streams stop at a verified commit
6. Verify — health_check confirms the daemon is live
7. Release — ask whether to release (patch / minor / skip)
8. Mark — tag all applied memories [applied] so they don't resurface

Instructions

Step 0 — Load tools

ToolSearch({ query: "chitta recall smart_recall remember" })

Step 1 — Surface pending findings

Call mcp__chitta__smart_recall with a targeted query:

mcp__chitta__smart_recall({
  query: "fix solution improvement correction bug gotcha",
  limit: 20
})

Filter the results to memories whose tags or title contain any of: [fix], [solution], [improvement], [correction], [gotcha], [bug] AND do not contain [applied].

If --dry-run flag: print the findings list and stop.

If no pending findings found:

"No pending fixes found. The soul is clean. Run a sadhana or dream to surface new discoveries." Stop.

Step 2 — Present findings summary

Display a numbered list of all findings:

Pending findings (N):

  1. [fix]    daemon: ETXTBSY when copying binary while running
               File: chitta/src/simple_cli.cpp  Confidence: 92%

  2. [correction]  build order: kill daemon BEFORE cp
               File: CLAUDE.md  Confidence: 95%

  3. [improvement]  TimeoutYantra: unbounded embedding threads
               File: chitta/include/chitta/vak_timeout.hpp  Confidence: 88%
  ...

Step 3 — Ask review mode

AskUserQuestion({
  questions: [{
    question: "Found N pending findings. How do you want to proceed?",
    header: "Review mode",
    multiSelect: false,
    options: [
      { label: "Review individually", description: "Go through each finding one by one" },
      { label: "Apply all",           description: "Accept every finding without reviewing" },
      { label: "Cancel",              description: "Exit without making changes" }
    ]
  }]
})

Step 4 — Review loop (if "Review individually")

For each finding, ask:

AskUserQuestion({
  questions: [{
    question: "[fix] #{title}\n\n#{content}\n\nFile: #{file_ref}",
    header: "Finding #N",
    multiSelect: false,
    options: [
      { label: "Apply",  description: "Implement this fix" },
      { label: "Skip",   description: "Leave for later" },
      { label: "Stop",   description: "Stop reviewing, apply what's accepted so far" }
    ]
  }]
})

Collect the list of accepted findings. If "Stop" → break loop early.

If nothing was accepted: confirm and exit.

Step 5 — Implement each accepted finding

For each accepted finding:

1. Read the cited file(s) from the memory's citation references
2. Understand the existing code
3. Apply the fix — use Edit (targeted, precise, no extra changes)
4. Log: ✓ Applied: {title}

If a finding is ambiguous or the file doesn't exist: skip it and log ⚠ Skipped (unclear): {title}.

Step 6 — Build

Set WORKTREE to the assigned implementation checkout and follow its canonical CLAUDE.md (Codex: codex-plugin/AGENTS.md) for required build and test gates.

cmake --build "$WORKTREE/chitta/build" --parallel

If build fails:

• Show the error
• Ask:

  AskUserQuestion({
    questions: [{
      question: "Build failed. What now?",
      header: "Build error",
      options: [
        { label: "Try to fix",    description: "Attempt to fix the build error" },
        { label: "Revert all",    description: "Git checkout the changed files and abort" },
        { label: "Abort",         description: "Stop here, leave files as-is" }
      ]
    }]
  })
  

  • "Try to fix": diagnose and fix the compile error, then rebuild
  • "Revert all": git checkout -- . and stop
  • "Abort": stop, leave changes uncommitted

Step 7 — Reviewed deployment

Implementation streams commit the verified change and report the build/test results; they do not install, restart services or modify live state. The orchestrator follows the canonical CLAUDE.md deployment procedure after review. Use install, never cp, over running binaries, and never pkill the --http MCP transport. Steps 8–9 apply only to the orchestrator's authorized deployment.

Step 8 — Verify

mcp__chitta__health_check({})

If the daemon responds healthy: ✓ Daemon is live If not: wait 2 seconds and retry once. If still failing, warn but continue.

Step 9 — Ask about release

AskUserQuestion({
  questions: [{
    question: "Build and install succeeded. Release a new version?",
    header: "Release",
    options: [
      { label: "Patch (x.x.+1)",  description: "Bug fixes only" },
      { label: "Minor (x.+1.0)",  description: "New features or significant changes" },
      { label: "Skip release",    description: "Keep changes local for now" }
    ]
  }]
})

If patch or minor:

cd "$WORKTREE" && ./scripts/release.sh <patch|minor> -y

Step 10 — Mark applied memories

For each successfully applied finding, add [applied] to its tags:

mcp__chitta__set_memory_type({ id: <id>, ... })

Or use mcp__chitta__remember to store a brief record:

mcp__chitta__remember({
  content: "[applied] #{title} — applied in session #{date}, released in v#{version}",
  tags: "applied,kriya,fix"
})

Then connect the new "applied" memory to the original finding:

mcp__chitta__connect_temporal({
  from: "<applied-memory-id>",
  relation: "resolves",
  to: "<original-finding-id>"
})

Step 11 — Report summary

Kriya complete ✓

  Applied:  3 fixes
  Skipped:  1
  Build:    ✓ successful
  Daemon:   ✓ live
  Released: v3.44.0

  Fixes applied:
    ✓ daemon: ETXTBSY build order fix
    ✓ TimeoutYantra: bounded embedding threads
    ✓ socket_is_active: EACCES treated as stale
    ↷ is_pid_alive zombie detection (skipped)

Anti-patterns

• Never skip the build step — applying a fix that doesn't compile is worse than not applying it
• Never release without a successful health_check
• Never mark [applied] if the build failed
• Never apply a finding to a file that hasn't been read first — always read before editing