Trading Journal

Use this skill when the task is recording durable trading knowledge, not just discussing a trade.

What this skill is for

This skill handles the recording workflow after a trade lesson, execution mistake, or repeatable rule is identified.

It exists to make sure trade wisdom is not trapped in chat history.

Primary goals:

1. Save the lesson into workspace memory for local persistence and fast future retrieval.
2. Save the rule into knowledge files so future trading discussions can reference it.
3. Optionally mirror the lesson into a synced repository (e.g. an Obsidian vault or shared notes repo) for multi-device access.
4. After recording, commit and push the relevant changes.

When to use

Use this skill when the user says things like:

• "record this"
• "add to trading rules"
• "write a review"
• "update the journal"
• "sync to my notes repo"
• "commit and push"

Do not use this skill for normal market commentary or live trading opinions unless the user explicitly wants the lesson recorded.

Required workflow

When triggered, follow this order.

1) Classify the note

Decide which of these it is:

• Daily journal note: one-off timeline, context, or raw event log
• Repeatable rule: should become discipline / checklist / anti-FOMO / risk rule
• Formal review: worthy of a standalone case-study
• Knowledge principle: reusable concept deserving its own strategy page

A single lesson may need more than one destination.

2) Update workspace memory

Always write at least one of:

• memory/YYYY-MM-DD.md — raw event + context + what happened
• Trading rules file (e.g. strategy/trading-rules.md) — canonical trading rules
• Durable memory index — only if this is a long-term recurring lesson

Guidance:

• Daily file = raw event + context + what happened
• Rules file = compact evergreen trading lessons
• Memory index = only if this is durable and likely to recur

3) Update knowledge files

If the lesson is actionable and reusable, update one or more files in your strategy directory.

Likely targets include:

• Trading rules document
• Pre-trade checklist
• Entry strategy rules (e.g. staged-entry framework)
• Event risk reduction principles
• Options selling rules

If no suitable file exists and the lesson is clearly reusable, create a focused new strategy file instead of dumping everything into one file.

4) Mirror to synced repository (optional)

If the user maintains a separate synced repository (e.g. Obsidian vault, shared notes), mirror the durable lesson there.

Likely destinations:

• strategy/ — for rules and checklists
• reviews/ — for concrete trade case studies
• holdings/<TICKER>.md — for position-specific execution notes

Rule of thumb:

• Specific case → reviews/
• Reusable rule → strategy/
• Ticker-specific execution note → holdings/<TICKER>.md

5) Keep compact doctrine current

The canonical compact doctrine lives in your trading rules file. Keep it aligned with the latest core lessons and extracted rules. If the file is outdated, refresh it with the latest durable rules rather than appending endless clutter.

Source annotation rule: When adding or updating a rule, always include a one-line source annotation: _Source: TICKER event description, YYYY-MM-DD_ This makes rules concrete under pressure — traders need to remember WHY a rule exists when tempted to break it.

5b) Update trade journal

When recording a trade lesson or review, also check if a corresponding entry should be added to a trade journal log file (e.g. trade_journal.md). This file tracks per-trade annotations (classification, logic, checklist compliance) and feeds into periodic execution quality audits.

6) Commit and push after recording

After file updates are complete:

1. Check git status in the relevant repo(s)
2. Create a concise commit message
3. Commit only the intended journaling/rules/review files
4. Push to the remote branch

If changes happened in multiple repos, commit and push each separately.

Writing rules

• Prefer blunt, compact rules over long emotional recaps.
• Preserve concrete examples when they clarify the lesson.
• Extract the rule, not just the story.
• Do not water down mistakes into "bad luck" if execution was flawed.
• Keep titles stable and searchable.

Standard outputs

Daily note structure

• Setup / original plan
• What changed intraday
• Actual result
• Lesson extracted

Rule structure

• Principle
• Wrong behavior
• Correct behavior
• One concrete example

Review structure

• Summary
• Timeline
• What went wrong / right
• Root mistake
• Rule extracted

Commit conventions

Suggested commit message patterns:

• journal: record <lesson>
• trading: sync <rule>
• review: add <case-name>

References

If you need examples or target-file guidance, read:

• references/file-map.md
• references/review-template.md