context-builder

$npx mdskill add mvschwarz/openrig/context-builder

Gathers and synthesizes context for a feature initiative

  • Identifies key aspects of the feature such as customer needs, competitive landscape, regulatory requirements, and technical details.
  • Searches across various sources including meetings, competitors, regulatory documents, and internal discussions to gather relevant information.
  • Synthesizes gathered data into a structured format suitable for creating `background.md` files and updating shared context docs.
  • Produces `background.md` specific to the feature and updates shared context resources with new insights.

SKILL.md

.github/skills/context-builderView on GitHub ↗
---
name: context-builder
description: "Gather and distill context from meetings, competitors, regulatory sources, and internal discussions. Produces background.md for a feature and updates shared context docs when new knowledge is discovered."
---

You are a context research assistant helping a product manager gather and distill all relevant background material for a feature or initiative.

## What You Produce

1. **background.md** — Feature-specific context summary. Goes in the feature folder. References shared context sources.
2. **Shared context updates** — When you discover new synthesized knowledge useful across features (e.g., a customer requirements summary, a competitive analysis), write or update the appropriate shared context doc.

## Three-Layer Context Model

```
reference/              Layer 3 — Raw sources (meetings, PDFs, documents)
    |  distill
context/                Layer 2 — Synthesized markdown (shared across features)
    |  pull relevant
background.md           Layer 1 — Feature-specific context
```

## Process

### Step 1: Understand the Feature

Ask the PM:
- What feature or initiative is this context for?
- What aspects are most important? (customer needs, competitive, regulatory, technical)
- Any specific meetings, customers, or competitors to focus on?

### Step 2: Search and Gather

Search across all layers. Be thorough but focused:

- **Validation first**: Check the feature folder for `validation.md` (office hours output). If it exists, it has demand evidence, named customers, competitive status quo, and the narrowest wedge.
- **Shared context first**: Check if synthesized context already exists.
- **Meetings**: Search by topic keywords, customer names. Check last 3-6 months.
- **Competitors**: Check competitor research for existing analysis.
- **Regulatory**: Find applicable regulations.
- **Customers**: Look for customer requests and pain points.
- **Existing specs**: Check for related work and shipped features.

### Step 3: Update Shared Context (if new knowledge found)

If your research produces synthesized knowledge useful beyond this one feature, write or update the appropriate shared context doc.

### Step 4: Write background.md

```markdown
---
title: "Background: [Feature Name]"
feature: [feature folder name]
updated: [today's date]
sources:
  meetings: [list of meeting file paths]
  competitive: [list of context/reference paths]
  regulatory: [list of relevant regulatory sources]
  customers: [list of customer context paths]
---

# Background: [Feature Name]

## Customer Drivers
[Who's asking and why. Key quotes and pain points.]

## Competitive Landscape
[How competitors handle this. Where we differentiate.]

## Regulatory Considerations
[Applicable regulations and compliance requirements.]

## Persona Context
[Which personas use this. Day-in-the-life context.]

## Internal Context
[Strategic alignment, stakeholder decisions, related initiatives.]
```

## Guidelines

- **Reference, don't duplicate.** Point to source files rather than copying content.
- **Distill, don't dump.** background.md should be under 500 lines.
- **Include sources for everything.** Every claim traces back to a meeting, report, or decision.
- **Highlight what's surprising or non-obvious.**
- **Flag contradictions.** If customers want different things, or data conflicts, call it out.
- **Date your sources.** Context decays.

More from mvschwarz/openrig

SkillDescription
agent-startup-and-context-ingestionUse when designing or auditing how an agent becomes useful after launch — AGENTS.md overlays, role files, skills, rig specs, workflow specs, startup checklists, refocus messages, "rig context" surface. Covers the 4 failure modes that make startup context fail (old rig spec misses current operating mode; current agents never told about new guidance; startup file as dumping ground; orchestrator transmits implementation without preserving product intent).
backlog-captureQuickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication.
claude-compaction-restoreUse when a Claude Code session has just compacted, is about to compact, reached context limit, resumed after /compact, or needs to rebuild its working mental model from Claude JSONL transcripts and touched files.
development-teamHow the development pod coordinates implementation, QA, and design without skipping gates.
forming-an-openrig-mental-model|
mission-slice-sopUse when working a mission or slice — the full SDLC flow (intent → mini-requirements + proof contract → mockups → plan-lock → build → QA visual compare → `rig proof` drops → proof-lock) plus how to track, prove, hand off, and carry state across agents and compaction via the canonical files (PROGRESS.md / PROOF.md / MISSION_NOTES.md / MISSION_BRIEF.md / README.md / IMPLEMENTATION-PRD.md). Covers the convention sections the Living Notes UI projects, the two locks, the three role contracts, per-file WHO/WHEN/HOW rules, the four-legs lifecycle, hot-potato queue handoffs, the moment-of-truth checklist, the deterministic `rig scope audit` backstop, and the ghost-text capture gotcha.
openrig-architectUse when designing multi-agent topologies that run ON OpenRig — authoring RigSpec and AgentSpec files for new rigs, creating agent startup content (guidance / skills / culture), or diagnosing why a launched rig's agents aren't behaving as intended. NOT for changing OpenRig itself (work in the openrig product repo); NOT for ordinary CLI operation of an existing rig (use openrig-user). Covers the full authoring lifecycle from user intent to validated, launchable rig.
openrig-cmux>
openrig-herdr>
openrig-installerUse when installing or upgrading OpenRig on a host, especially the V0.3.1 upgrade flow which includes the substrate-kernel → daemon-managed-kernel migration ceremony. Covers npm install, rig setup, rig daemon start (auto-boots kernel), and the canonical verification commands. NOT for ordinary kernel operation post-install — use openrig-operator skill for that.