Decision

TrigMem Decision Skill

Classify input content against the 6 information categories, map to a destination, and return a structured decision.

Input

You receive a content description (text the user wants to store in Claude Code memory).

Decision Logic

Step 1: Classify Against the 6 Categories

Match the input to one category. If it clearly spans multiple, go to Step 4 (this is common — not an edge case).

If classification is unclear, Read ref-categories.md for self-assessment questions, Cat 4 vs 5 distinction, and ambiguous case resolution.

Step 2: Map Category to Destination

For categories that map to a single destination (1, 3, 4): return immediately.

For categories requiring refinement (2, 5, 6), apply these rules:

• Rules require specific file-pattern globs (e.g., *.ts, src/api/**). Rules with broad patterns (**/*) provide no token savings over CLAUDE.md.
• CLAUDE.md is for brief, always-needed context. If content is too long: when a Skill exists for the same topic, prefer a skill companion (.claude/skills/{name}/reference.md); otherwise use the pointer pattern (brief reference in CLAUDE.md, full content in docs/).
• Use AskUserQuestion to resolve ambiguity when classification depends on user intent:
  • Rules vs CLAUDE.md destination unclear
  • Cat 4 vs Cat 5 and portability depends on user intent ("Is this meant to be portable across projects?")
  • Content description too vague to classify ("Can you be more specific about what you want to store?")
  • Decomposition boundaries unclear ("Should X and Y be stored together or separately?")
• When uncertainty is between destinations with similar trade-offs (not intent-dependent), make a best-guess decision and return ambiguous output with a recommendation.

Step 2.5: Check Existing State

Before validating, scan all destination types for existing files that overlap with the proposed content.

• If existing file found: set Operation: update, populate Existing file: field, and (for CLAUDE.md) Section: field, and (for overlaps) Existing match rationale:
• If no existing file found: set Operation: create (default, backward compatible)

Step 3: Validate with Mechanism x Dimension Matrix (Tiebreaker)

If category classification alone does not resolve the destination, consult the matrix:

Ask: Does the content need to be always-loaded? Pattern-triggered? On-demand? User-controlled? Isolated? The mechanism whose dimension profile best matches the content's needs is the destination.

If the matrix alone doesn't resolve, Read ref-decision-support.md for dimension definitions, need→mechanism lookup, and trade-off comparisons.

Step 4: Check for Decomposition

If the content spans multiple categories, recommend decomposition. Common patterns:

Each component results in a separate file. Re-apply Steps 1-3 to each component individually to determine its specific destination. Split when aspects have different loading or invocation needs (e.g., always-loaded identity vs on-demand how-to).

Step 4b: Scan for Rule Candidates in Skill Components

After producing decomposition components, scan each Skill component's source content for enforceable constraints that should be extracted as separate Rules:

• Keyword constraints: Sentences containing NEVER, ALWAYS, ZERO, DO NOT, MUST NOT, MUST, or REQUIRED that state short enforceable rules scopeable to file globs
• File extension patterns: Paths like *.repository.ts, *.use-case.ts, *.controller.ts, or directory-scoped patterns from code blocks and file path comments

If any matches are found, append a Rule candidates detected section after the numbered components in the decomposition output (see Output Format below). Each candidate includes the constraint text and a suggested glob pattern.

If no matches are found, omit the section entirely (backward compatible — no extra output).

Step 4c: Route Reference Material to Skill Companion

After decomposition, check if a component pair exists: a Skill component AND a large reference/explanation component for the same topic.

If both exist:

• Route the reference component to .claude/skills/{name}/reference.md (a "Skill companion")
• The Skill's SKILL.md should reference the companion: "See reference.md in this directory for detailed documentation"
• CLAUDE.md should point to the skill path (.claude/skills/{name}/SKILL.md), not a separate docs/ subfile
• Companion files have NO frontmatter — plain markdown only

This replaces the External Docs + Pointer pattern when a Skill exists for the same topic.

Step 5: Fallback

If classification is uncertain after Steps 1-4, or when iterating on decomposed components, Read ref-decision-support.md for Phase 1 triage questions and Phase 2 per-destination refinement. This is an alternative classification path, not only a last resort.

If no category matches at all and no Skill exists for the same topic, recommend: External Docs + Pointer Pattern (store in docs/, add pointer in CLAUDE.md). When a Skill exists, prefer Skill companion (.claude/skills/{name}/reference.md).

Output Format

CRITICAL: Your output MUST be exactly one of the three structured variants below. Do NOT produce prose summaries, markdown tables, bullet-point recaps, or any other format. A downstream parser depends on the Decision: field appearing on its own line. If the output is not in the structured format below, the system will fail.

Produce exactly one of these three variants:

Clear Case (single destination, high confidence)

Decision: [CLAUDE.md | Rules | Skills | Commands | Sub-agents]
Operation: create | update
Existing file: [path or "none"]
Section: [section name]              ← CLAUDE.md only, omit otherwise
Existing match rationale: [reason]   ← only when Operation is update
Sub-destination: [if applicable, e.g., "pointer pattern" or "configurable skill"]
File path: [target path pattern]
Confidence: clear
Rationale: [1-2 sentences referencing the category and why this destination fits]

Ambiguous Case (multiple plausible destinations)

Decision: ambiguous
Options:
1. [destination A] — Operation: [create|update], Existing file: [path] — [rationale]
2. [destination B] — Operation: [create|update], Existing file: [path] — [rationale]
Recommended: [best guess if any]

If invoking interactively and user intent would resolve the ambiguity, use AskUserQuestion before returning output. Only return ambiguous when the choice is genuinely a preference between valid options.

Decomposition Case (content spans multiple categories)

Decision: decompose
Components:
1. [aspect] → [destination] ([file path]) — Operation: [create|update], Existing file: [path] — [rationale]
2. [aspect] → [destination] ([file path]) — Operation: [create|update], Existing file: [path] — [rationale]

Rule candidates detected in component N:
- "[constraint text]" → candidate glob: [pattern]
- "[constraint text]" → candidate glob: [pattern]

The Rule candidates detected section is optional — include it only when Step 4b found keyword constraints or file extension patterns in Skill component bodies. If nothing was detected, omit the section entirely.

Destination to File Path Mapping

Notes

• Placement is iterative. Initial placement can be refined later based on real usage.
• When recommending Skills for Cat 4 content that mixes universal pattern + project-specific paths:
  • Recommend the configurable skill pattern: separate pattern from config
  • Skill instructions reference config by name ("the domain directory"), not by path
  • Project-specific values go in a YAML # Configuration block in SKILL.md
  • The same skill works across projects — only the config block changes
  • Alternative: decompose into Skill (universal) + Rule/CLAUDE.md (project paths)
• Always include rationale referencing the decision framework.