| name | artifact-context |
| description | Generates a structured prompt for spawning Support-Librarian to gather relevant ADRs, logs, and design docs before a design, planning, or execution task. Use before starting any significant work — designing a feature, creating a plan, executing a plan, or reviewing code — to ensure prior decisions and dead ends are known. Trigger automatically in agents that have this skill, or manually when entering an unfamiliar area. |
Artifact Context Gathering
Before acting on any significant task, spawn Support-Librarian to search the artifact corpus for relevant constraints, warnings, and context. This skill templates the prompt.
When to Use
| You're about to... | Use this skill |
|---|
| Design a feature (DDAuthor) | Yes — before writing the design doc |
| Create an implementation plan (Exec-Planner) | Yes — before creating the plan |
| Route work to a department (Director, RnD-Manager) | Yes — before dispatching |
| Execute a plan phase (Exec-Executor) | No — the plan should already reflect artifact context |
| Do a quick fact check | No — overhead not worth it |
Threshold: If the task touches architecture, creates artifacts, or makes decisions that constrain future work — gather context first. If it's mechanical execution of an already-validated plan — skip.
How to Use
Step 1: Identify the Task Shape
Determine what you're about to do and what scope it touches:
task:
action: "design"
subject: "ML tagging pipeline redesign"
scope: "nomarr/components/ml, nomarr/workflows/processing"
Step 2: Spawn Support-Librarian
Use this prompt template, filling in the task details:
Search the artifact corpus for everything relevant to this task:
Task: {action} — {subject}
Scope: {scope}
Specific concerns:
- {any specific questions or areas of uncertainty}
Return a structured briefing with constraints (ADRs/decisions that must be respected),
warnings (dead ends, failed approaches), context (useful background), and open questions
(unresolved uncertainties from prior work).
Step 3: Incorporate the Briefing
The Librarian returns a structured briefing. Use it:
| Section | What to do |
|---|
constraints | These are non-negotiable. Your design/plan must comply. |
warnings | Avoid these approaches. If you must use one, document why. |
context | Consider this background. May influence your approach. |
open_questions | Surface these to the user or document your resolution. |
no_relevant_artifacts | Proceed with confidence — no prior work constrains you here. |
Example: DDAuthor Using This Skill
# Before writing the design doc:
1. Identify task: design — "notification system for scan completion"
Scope: nomarr/services, nomarr/workflows/processing, frontend/
2. Spawn Support-Librarian:
"Search the artifact corpus for everything relevant to this task:
Task: design — notification system for scan completion
Scope: nomarr/services, nomarr/workflows/processing, frontend/
Specific concerns:
- Are there existing ADRs about event-driven patterns?
- Has anyone tried WebSocket-based notifications before?
Return a structured briefing..."
3. Librarian returns:
- Constraint: ADR-003 requires state flags, not event pipelines
- Warning: Log shows WebSocket attempt was abandoned (connection pooling issues)
- Context: DD-schema-refactor-v1 added event tracking tables
4. DDAuthor writes design doc that:
- Uses state-flag polling instead of event pipeline (respects ADR-003)
- Avoids WebSockets (heeds warning)
- Leverages existing event tracking tables (uses context)
Example: Director Using This Skill
# Before routing a feature to R&D:
1. Identify task: design — "playlist generation from ML embeddings"
Scope: nomarr/components/ml, nomarr/workflows
2. Spawn Support-Librarian with task context
3. Librarian returns:
- Constraint: ADR-001 mandates ONNX for all ML inference
- Context: Prior design doc exists for embedding pipeline
4. Director includes in dispatch to RnD-Manager:
"Design playlist generation feature.
Constraints from artifact review:
- Must use ONNX runtime (ADR-001)
- Prior embedding pipeline design exists — build on it, don't redesign"
Anti-Patterns
- Don't skip this for "small" design decisions — Small decisions that contradict ADRs cause big problems.
- Don't re-search what the Librarian already found — Trust the briefing. Read cited artifacts only if you need more detail.
- Don't ignore
no_relevant_artifacts — An empty briefing is signal: you're in uncharted territory. Log your decisions for future sessions.
- Don't spawn Librarian during mechanical execution — If you're following a plan step-by-step, the plan author should have already gathered context.
