legacy-context

Legacy Context

Most context-engineering techniques assume layers 1 and 2 of tiered lookup (semantic memory and structured docs) already contain useful information. In consolidated codebases this assumption breaks. There are no ADRs, no post-mortems indexed, no runbooks, no skill memory. Tiered lookup collapses to layer 3 (raw code) and every session pays the full reading cost again.

This skill runs before context-engineering becomes useful. It does code archaeology and writes discovery notes, ADR candidates, and intent marker suggestions into the empty layers, so that the next sessions can use the cheaper layers as designed.

The skill is read-only for source code. It never edits source files. It writes only to memory/discoveries/, docs/architecture/_candidates/, and emits intent marker patches for human review.

Operating principle

Bias toward completeness. When in doubt, capture more, not less. In consolidated codebases, the contextual gem is usually the comment buried in a 6-year-old PR review or the issue closed as "wontfix" with three paragraphs of reasoning. Missing those is a worse failure than producing verbose discovery notes.

This bias is reflected in the defaults: the early-exit heuristic in Phase 3 is disabled by default, the trunk-based threshold is set conservatively (30% PR coverage), and commit message scans extend automatically when remote layers prove thin. Users who prefer speed over completeness can flip the relevant flags in the "Tuning" section of Phase 1.

Supported remote providers

Provider	Detection	Auth	Notes
GitHub	URL contains github.com	gh auth status	Full feature parity
Azure DevOps	URL contains dev.azure.com or .visualstudio.com	AZURE_DEVOPS_EXT_PAT env var (no az login needed)	No reactions on comments; releases mapped to git tags
Other (GitLab, Bitbucket, self-hosted)	Anything else	n/a	Phase 3 skipped with warning

Rules

1. Read source, write context. Never modify source files. All output goes to discovery notes, ADR candidates, or marker patches for review.
2. Discovery before implementation. This skill does not implement features. If implementation is needed, hand off to /implement after discovery completes.
3. Why, not what. Source code already shows what runs. Discovery captures why it exists, what depends on it, and what breaks if changed.
4. Cover the path entirely on remote. Remote discovery iterates every file in the path, not just the priority ones from the survey. A "warm" file with no commit pattern may still have a critical PR discussion attached to it.
5. Cap source-code reading depth, not remote breadth. If a single source file exceeds 2,000 lines, treat it as a sub-module and recurse. On remote, do not cap by top-N. Stratify by discussion density instead.
6. Outputs go to predictable paths. Other skills (memory, incoherence detector, ADR) consume the discovery output. Keep file naming consistent across providers.
7. Same output across providers. Phase 3 produces identical file structure whether running on GitHub or Azure DevOps. Downstream phases should not need to know which provider generated the data.