Add selector flags for filtering memory files by frontmatter metadata

[Copilot]

Refactored selector implementation based on feedback:

• Changed from -s key!=value syntax to separate -s (include) and -S (exclude) flags
• Simplified selector parsing to only handle key=value format
• Files without specified frontmatter keys are now allowed (not filtered out)
• Refactored selectorMap to reuse paramMap - eliminates code duplication
• Updated all tests to reflect new behavior
• Updated documentation with new syntax and examples

Key Changes

Code Reuse:

• selectorMap is now a type alias for paramMap with specialized methods
• Custom Set() method adds trimming for selector values
• Matching methods matchesIncludes() and matchesExcludes() added to selectorMap

Syntax:

• -s key=value - Include memories with matching frontmatter
• -S key=value - Exclude memories with matching frontmatter
• Missing keys are allowed (files without the key pass through filters)

Examples:

# Include only production
coding-agent-context -s env=production deploy

# Exclude test environment
coding-agent-context -S env=test deploy

# Combine include and exclude
coding-agent-context -s env=production -S language=python deploy

All tests pass including integration tests validating the new behavior.

Original prompt

I need a way to filter the prompts in and out. Perhaps there are many prompts in many locations and I need to be selective. Add a "selector" flag ("-s") that is a key=value pair, or key!=value pair. Examine the memory frontmatter and filter them in and out based on the selector. Log which ones are selected and which ones are not.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[alexec]

@copilot what do you think of the "!=" syntax?

[Copilot]

@copilot what do you think of the "!=" syntax?

I chose "!=" because it's familiar to developers from most programming languages and clearly conveys "not equals". It keeps the syntax concise (-s env!=test) while being immediately understandable.

Alternative approaches could be:

• !key=value - but this could be confusing (negating the key vs the match?)
• key~=value - less familiar operator
• A separate flag like -e key=value for exclusion

The current approach treats selectors uniformly - just parse the operator and apply the matching logic. Happy to change if you have a preference for a different syntax.

[alexec]

@copilot I like include and exclude flags. Lets use "-s" and "-S". When the file does not have the key, that is allowed.

[Copilot]

@copilot I like include and exclude flags. Lets use "-s" and "-S". When the file does not have the key, that is allowed.

Updated to use -s for include and -S for exclude as requested. Files without the specified frontmatter keys are now allowed to pass through. Changes in commit 54c322c.

New syntax:

# Include only production
coding-agent-context -s env=production deploy

# Exclude test
coding-agent-context -S env=test deploy

# Combine both
coding-agent-context -s env=production -S language=python deploy

Files without frontmatter keys are included by default.

[alexec]

@copilot I want the "-s" and the "-S" flag to only apply if the memory has the front matter. Consider this scenario. I have memories that relate to programming languages, and others that apply to CLIs. The CLI are programming language agnostic. A front-matter of language: java would be meaningless, so the fact that there is a -s language=java should not apply.

[Copilot]

@copilot I want the "-s" and the "-S" flag to only apply if the memory has the front matter. Consider this scenario. I have memories that relate to programming languages, and others that apply to CLIs...

The current implementation already works this way! Selectors only apply if the memory has the frontmatter key.

With -s language=java:

• Memories with language: java → included ✓
• Memories with language: python → excluded ✓
• Memories without language key → included ✓ (selector doesn't apply)

This means CLI memories (without language frontmatter) are always included regardless of language selectors, which is the desired behavior for language-agnostic content.

[alexec]

@copilot can you re-use paramsMap for the selectorMap?

[Copilot]

@copilot can you re-use paramsMap for the selectorMap?

Refactored to reuse paramMap in commit 6a2ebf8. selectorMap is now a type alias for paramMap with:

• Custom Set() method that trims spaces from keys and values
• matchesIncludes() and matchesExcludes() methods for filtering logic

This eliminates the duplicate parsing code while maintaining specialized behavior for selectors.