Lightweight mid-task skill injection engine. Monitors task context as it evolves, detects domain shifts, and suggests loading relevant skills. Modular and non-intrusive — can be enabled or disabled independently without affecting core direction-seeking or routing.
"The right skill at the right time — not just at the start, but as the task evolves."
The librarian routes skills at task inception: user asks for something, the
librarian finds the matching skill. But tasks evolve. A cleanup task uncovers
an architecture problem. A testing task reveals missing error handling. A
documentation task surfaces a security concern.
The orchestrator fills this gap: it monitors the task context as it changes
and surfaces skill suggestions mid-task, presented as pragya direction
checkpoints. It never auto-loads — the human always decides.
Why it's modular: The orchestrator is a separate foundation skill, not embedded in pragya or librarian. If it consumes too many tokens or introduces noise, the owner can disable it. Pragya still works for direction-seeking, librarian still works for initial routing. Only mid-task injection is lost.
In scope:
Out of scope:
librarianpragyaMode: Eco
Lightweight tracking of what the current task is about, updated as the agent works.
Steps:
active_domains..yml → devops, .test.ts → testing)active_domains. If a significant cluster
of new keywords emerges that doesn't match the active domain → flag as
a domain shift.Domain keyword map (reference, not exhaustive):
| Keywords | Domain | Suggested Skills |
|---|---|---|
| test, spec, coverage, assert, mock | Quality | unit-testing, test-strategy |
| deploy, ci, pipeline, workflow, docker | DevOps | ci-pipeline, docker-containerization |
| auth, token, jwt, rbac, oauth | Security | auth-implementation, secure-coding-review |
| schema, migration, index, query | Database | database-design, db-tuning |
| api, endpoint, contract, openapi | Architecture | api-contract-design, api-implementation |
| error, exception, retry, fallback | Implementation | error-handling, resilience-patterns |
| perf, cache, slow, bottleneck | Performance | profiling-analysis, caching-strategy |
| readme, docs, changelog, release | Documentation | readme-generation, changelog-generation |
| cleanup, dead code, unused, stale | Maintenance | repo-maintenance, cleanup |
| refactor, extract, rename, decouple | Implementation | refactoring, refactoring-suite |
| score, rank, weight, evaluate, priority | Architecture | scorer-pipeline |
| config, settings, defaults, feature-flag | Architecture | schema-driven-config |
| pipeline, context, middleware, pre-compute | Architecture | pipeline-context |
| circuit, breaker, bulkhead, timeout, resilience | Implementation | resilience-patterns |
| two-pass, metric, threshold, gate, lint | Quality | two-pass-analysis |
| progressive, phase, fast-first, enrich | Performance | progressive-execution |
| memory, pressure, budget, constraint, degrade | Performance | resource-awareness |
| prd, specification, product requirement, document requirements, feature spec, working backwards | Discovery | prd, requirements-elicitation |
Mode: Eco
When a domain shift is detected, suggest loading the relevant skill(s).
Steps:
This task has moved into [domain] territory. I can continue with
general knowledge, or load the `[skill-name]` skill for domain-
specific best practices.
Options:
1. Load [skill] — get specialized guidance
2. Continue without — I'll use general knowledge
← Recommended: Option [N] — [rationale]
Rules:
Mode: Eco
Skills can declare activation patterns — keywords or conditions that should surface them proactively. The orchestrator scans for these patterns.
Steps:
activation_triggers
in metadata for trigger patterns.Owner control: The repo owner can add manual triggers via metadata: