Project Memory Guard

Enforce project boundaries and memory writeback rules before anything enters project memory. Use before: writing notes into project memory, saving outputs/ta...

Security Scan

The skill is an instruction-only guard that is internally consistent with its stated purpose (validating memory writebacks) and requests no extra privileges or installs, though the instructions contain a few small ambiguities you should clarify before relying on it.

Purpose & Capability

Name, description, and required inputs all align with a memory-write validation/guard role. The skill requests no binaries, env vars, or installs that would be unnecessary for this purpose.

Instruction Scope

SKILL.md stays within the guard role and describes inputs, outputs, hard rules, normalization, and failure handling. Minor issues: rule table references 'project_id' while inputs use 'candidate_project_id' (inconsistent naming); 'Cross-project ambiguity' is referenced but not defined (no algorithm or detection criteria); normalized_record schema is underspecified (only some fields described). These should be clarified so implementations cannot misinterpret the guard.

Install Mechanism

No install spec and no code files — lowest disk/installation risk (instruction-only).

Credentials

No credentials, env vars, or config paths are requested; this is proportionate to the stated task.

Persistence & Privilege

always:false, no persistent/system-wide changes requested. The skill does not request autonomous elevation or modify other skills/configs.

Assessment

This instruction-only skill is coherent for enforcing memory writeback rules and is low-risk in itself because it requests no installs or credentials. Before installing or relying on it, verify these practical points: 1) Fix the small naming inconsistency (candidate_project_id vs project_id) so implementations don't treat missing fields incorrectly. 2) Define how 'cross-project ambiguity' is detected (rules/heuristics) and what 'cleanup' entails. 3) Provide an explicit normalized_record schema (which fields are allowed, types, max sizes) and document whether and how sensitive data in raw_content is redacted — storing raw_content can retain PII/sensitive secrets. 4) Ensure the guard is actually enforced in your agent pipeline (SKILL.md are instructions; an integration might not implement them correctly). 5) Expose configuration for the confidence threshold (0.6) and provide test vectors for accept/reroute/reject cases. 6) Add audit/logging guidance so decisions are traceable. If you need stronger guarantees, require the skill to be implemented as code with tests and explicit input validation rather than only prose instructions.

Validate every memory write against project and writeback rules. Prevent contamination and schema drift.

Input

Required fields:

• raw_content — the content attempting to enter project memory
• candidate_project_id — the project being written to
• memory_type — type of memory: note, finding, task, summary, record, etc.
• source — where this came from: user message, paper, tool output, etc.
• timestamp — ISO-8601 timestamp of when the content was created
• confidence — confidence score 0.0–1.0 for project assignment

Output Schema

decision: "accept" | "reject" | "reroute"
destination: string | null          # project_id or "inbox" or null
normalized_record: object | null    # cleaned record if accepted/rerouted
contamination_risk: "none" | "low" | "medium" | "high"
missing_fields: string[] | null
reason: string

Hard Rules

Condition	Decision
Missing project_id	reject — never enter formal project memory
Missing memory_type	reject — no formal writeback
Missing timestamp	reject — no formal writeback
Confidence < 0.6	reroute to inbox
Cross-project ambiguity	reroute to inbox or cleanup mode
All fields present + high confidence	accept

Reroute Destinations

• inbox — unverified content waiting for manual review
• cleanup — ambiguous content needing disambiguation
• Specific project_id — when rerouting to a known project

Normalization

When decision is accept or reroute, normalize the record:

• Strip identifying metadata not in schema
• Add validated_at timestamp
• Add guard_version = "1.0"
• Preserve original raw_content in normalized_record.raw

Failure Handling

If uncertain about any field:

• Do not guess project_id or memory_type
• Set decision = "reroute" with destination = "inbox"
• List missing_fields explicitly
• Explain in reason

Never force acceptance when validation fails.