configuration-source-trace
Skill0 starsChanged 2 months agoMITView on GitHub
Trace behavior-changing configuration from its external/source definition through loader, key/default/override precedence, runtime state, consumer branch, and resulting behavior; use to close configuration-origin unknowns.
In this repository33 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- adversarial-baseline-auditSkill
- architecture-drift-detectionSkill
- architecture-reconstruction-and-diagramsSkill
- artifact-detailed-designSkill
- baseline-source-of-truth-maintenanceSkill
- claim-verification-and-promotionSkill
- contract-impact-test-designSkill
- current-state-tdd-synthesisSkill
- design-artifact-decompositionSkill
- design-artifact-decomposition-verificationSkill
- detailed-design-verificationSkill
- full-reverse-engineeringSkill
- implementation-readiness-certificationSkill
- incident-root-cause-analysisSkill
- integration-selection-analysisSkill
- observability-traceability-analysisSkill
- patch-impact-reviewSkill
- persistence-schema-reverse-engineeringSkill
- post-readiness-adversarial-auditSkill
- regression-test-designSkill
- requirement-compliance-reviewSkill
- resolve-high-impact-unknownsSkill
- resume-reverse-engineeringSkill
- reverse-engineering-bootstrapSkill
- reverse-engineering-coverage-auditSkill
- run-engineering-workflowSkill
- runtime-binding-verificationSkill
- runtime-flow-analysisSkill
- technical-design-proposalSkill
- technical-design-verificationSkill
- wbs-generationSkill
- wbs-verificationSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 37
Search from BOTH ends:
- Distinctive: line 88
If the actual deployed VALUE is unavailable but source proves the injection mechanism, separate:
- Distinctive: line 95
Do not mark the entire configuration architecture UNKNOWN.
- Distinctive: line 117
Update open questions/evidence ledger as appropriate.
- Distinctive: line 133
Prefer the settings that change architecture, routing, concurrency, integration selection, lifecycle, persistence, security, or externally …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Configuration Source Trace
Mission
Answer precisely:
Where does this configuration value come from?
How is it overridden?
How does it reach runtime behavior?Required Trace
For each material setting:
source
→ file/env/system property/DB/CLI/default
→ key/schema
→ loader/parser
→ validation/conversion
→ precedence/override
→ runtime object/state
→ consumer
→ branch/selection
→ behavioral effectSearch Strategy
Search from BOTH ends:
Consumer backward
branch/getter/field
→ assignment
→ constructor/setter/config object
→ loader
→ external source/keySource forward
key/property/env/schema
→ parser
→ config object
→ consumer
→ runtime behaviorInspect:
- property/yaml/json/xml files
- environment variables
- system properties
- command-line args
- DB-backed settings
- config defaults/constants
- profiles/overlays
- startup/bootstrap
- tests showing override precedence
Required Findings
| Setting | External Source | Key | Default | Override Precedence | Loader | Runtime Holder | Consumer | Behavioral Effect | Evidence | Status |
Status:
VERIFIED
PARTIALLY_VERIFIED
EXTERNALLY_INJECTED
NOT_APPLICABLE
UNRESOLVEDExternal Values
If the actual deployed VALUE is unavailable but source proves the injection mechanism, separate:
configuration mechanism = VERIFIED
runtime deployed value = EXTERNALLY_BLOCKEDDo not mark the entire configuration architecture UNKNOWN.
Counterexample Search
Search for:
- duplicate keys
- deprecated keys
- alternate loaders
- profile-specific overrides
- defaults that bypass external configuration
- DB/runtime overrides
- test-only configuration
Output
Create/update:
docs/reverse-engineering/configuration/<scope>.mdUpdate open questions/evidence ledger as appropriate.
Canonical Configuration Model
For full-baseline execution, consolidate behavior-changing settings into:
docs/reverse-engineering/models/configuration_model.mdRequired fields:
| Setting/Selector | Source | Default | Override Precedence | Runtime Holder | Consumer | Behavioral Effect | Variant Selected | Evidence |
Prefer the settings that change architecture, routing, concurrency, integration selection, lifecycle, persistence, security, or externally observable behavior. Do not bury these selectors in an exhaustive property dump.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

