unified-context-stack
Tiered context retrieval across External Truth (docs), Internal Truth (dependencies), Historical Truth (memory), and Intent Truth (feature specs) with graceful degradation based on installed tools.
Best use case
unified-context-stack is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Tiered context retrieval across External Truth (docs), Internal Truth (dependencies), Historical Truth (memory), and Intent Truth (feature specs) with graceful degradation based on installed tools.
Teams using unified-context-stack should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/unified-context-stack/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How unified-context-stack Compares
| Feature / Agent | unified-context-stack | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Tiered context retrieval across External Truth (docs), Internal Truth (dependencies), Historical Truth (memory), and Intent Truth (feature specs) with graceful degradation based on installed tools.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Unified Context Stack An infrastructure-level skill that provides tiered context retrieval for every SDLC phase. Reads your session's `Context Stack:` capabilities line to determine which tools are available, then follows strict fallback tiers. ## How to Use 1. Check the `Context Stack:` line from your session start for capability flags 2. Read the relevant **phase document** for your current SDLC phase 3. For each capability dimension needed, follow the **tier document** in strict order ## Capability Flags These are injected by the session-start hook as: `Context Stack: context7=true, context_hub_cli=false, ...` | Flag | Tool | What it enables | |------|------|----------------| | `context7` | Context7 MCP | Broad library doc retrieval | | `context_hub_available` | Context Hub via Context7 | High-trust curated docs — flag means Hub is *reachable*, not that it has docs for your library (query `/andrewyng/context-hub`) | | `context_hub_cli` | `chub` CLI | Local curated doc retrieval and annotations | | `serena` | Serena MCP | LSP-powered dependency mapping and AST edits | | `serena_connected` | Serena MCP | MCP server is connected (not just registered); set only when `SERENA_CONNECTION_CHECK=1` | | `forgetful_memory` | Forgetful Memory | Persistent cross-session architectural knowledge | | `forgetful_connected` | Forgetful Memory | MCP server is connected (not just registered); set only when `FORGETFUL_CONNECTION_CHECK=1` | | `openspec` | OpenSpec CLI | Whether the `openspec` binary is available. See the separate `OpenSpec:` capability line for detailed surface/command info. Intent Truth retrieval does NOT require this flag — it checks artifact presence directly. | ## Tier Documents - [External Truth](tiers/external-truth.md) — API documentation retrieval - [Internal Truth](tiers/internal-truth.md) — Blast-radius mapping and safe code edits - [Historical Truth](tiers/historical-truth.md) — Institutional memory retrieval and storage - [Intent Truth](tiers/intent-truth.md) — Feature specification and design rationale retrieval **Note:** Intent Truth checks for artifact presence in the workspace (`openspec/specs/`, `openspec/changes/`, `docs/plans/`, `docs/plans/archive/`, `docs/superpowers/specs/` [legacy]). The `OpenSpec:` capability line from session-start indicates CLI availability for write operations (used by `openspec-ship`), but Intent Truth retrieval works regardless of CLI installation — it reads local files. ## Phase Documents - [Design](phases/design.md) — Intent and historical context before proposing approaches - [Triage & Plan](phases/triage-and-plan.md) — Context gathering before writing plans - [Implementation](phases/implementation.md) — Mid-flight lookups during execution - [Testing & Debug](phases/testing-and-debug.md) — Error resolution and live issue discovery - [Code Review](phases/code-review.md) — Claim verification and dependency checks - [Ship & Learn](phases/ship-and-learn.md) — Memory consolidation before session close
Related Skills
supply-chain-investigation
Use when investigating a published supply-chain attack on a registry package (npm, Maven, PyPI, Go, Gradle) — advisory-driven org-wide audit. Triggers on attack-language ("compromised", "malicious", "hijacked", "backdoored", "typosquatted"). NOT for routine CVE scanning — that routes to security-scanner.
skill-scaffold
Emit repo-native seed files (SKILL.md skeleton, routing entry, test snippets) when creating new skills, commands, or plugins
security-scanner
Use when reviewing code changes for security issues — during REVIEW phase or on explicit security, vulnerability, SAST, or secret-scan requests — running available Semgrep/Opengrep, Trivy, and Gitleaks scanners with a self-healing fix loop
runtime-validation
Use when you need to prove a change actually works through its real interfaces — during REVIEW or on requests like validate the feature, does it work, run e2e, or smoke test — covering browser E2E, API smoke, CLI checks, and a11y audits with graceful tool-degradation
prototype-lab
Produce 3 thin comparable variants of a proposed design with a comparison artifact and mandatory Human Validation Plan
project-verification
Use when you need to run the repo's own declared test/lint/type gate locally and emit pass/fail evidence — during REVIEW, before requesting code review, or on a request to run the tests or verify the build — discovering the gate from CLAUDE.md, Makefile, pyproject, or .verify.yml
product-discovery
Use when starting a new feature or initiative and you need problem context, prior art, and acceptance criteria before design — the DISCOVER phase entry point — pulling Jira/Confluence context and synthesizing a discovery brief to validate problem framing
outcome-review
Use when reviewing a shipped feature's real-world outcome in the LEARN phase — checking adoption, error, or experiment metrics after release, validating ship-time hypotheses, or deciding follow-up work — querying PostHog and creating gated follow-up Jira work
openspec-ship
Use when shipping a completed feature and generating as-built OpenSpec docs before branch finalization
incident-trend-analyzer
On-demand postmortem trend analysis — recurrence grouping, trigger categorization, MTTR/MTTD from canonical docs/postmortems/ corpus
incident-analysis
Use when investigating production symptoms — connection failures, pod crashes/restarts, SIGTERM/OOM errors, latency spikes, Cloud SQL/proxy issues, deployment-correlated errors, ImagePullBackOff, CreateContainerConfigError, or node NotReady events
implementation-drift-check
Use when verifying an implementation still matches its spec or plan — during REVIEW or SHIP, or on demand to check drift, confirm you are still on plan, or run a spec check — surfacing spec deviations, unvalidated assumptions, and untested code paths against Intent Truth