Conversation History Recorder

Conversation History Recorder

Use this skill for project work when durable memory across turns would help.

Goal

Maintain a durable, structured history per project so future turns remember:

• what problem or goal the project had
• the user's exact instruction
• Codex's feedback or recommendation
• what choice, correction, or follow-up the user made

Do not log command-by-command tooling, raw terminal output, patch details, or line-by-line code edits unless the user explicitly asks for that.

Storage

• For any project under /home/gguo/code, always store logs under:
  • /home/gguo/code/history/<project>.md
• If the task spans multiple /home/gguo/code projects or only concerns the shared workspace, use:
  • /home/gguo/code/history/_workspace.md
• For projects outside /home/gguo/code, create or use a history/ directory at that workspace root:
  • <workspace>/history/<project>.md
• If an outside-workspace task is not tied to a single project, use:
  • <workspace>/history/_workspace.md

<project> should normally be the top-level directory name for the repository or project being worked on.

When to write

Write or update the history file:

• once after each user request has been handled
• when the user changes direction, makes a decision, or corrects an assumption
• when Codex identifies a project problem, blocker, or recommended next step

If a turn is purely casual and unrelated to project work, no history entry is needed.

What to record

For each turn, append a new entry using this template:

## <timestamp in UTC>
- Context: <project/task context in 1-3 sentences>
- Problem_or_goal: <what the user needed or what issue was being worked on>
- User_instruction_full: <the user's instruction, kept verbatim when practical; if very long, keep the full meaning without dropping requirements>
- Codex_feedback: <Codex's answer, plan, diagnosis, or recommendation in concise prose>
- User_choice_or_followup: <the user's explicit decision, correction, preference, or next instruction; use "Pending" if the turn has not yet produced one>
- Status: <open | in_progress | resolved | redirected>

Required behavior

• Preserve all user requirements. Do not omit constraints that affect future work.
• Prefer exact wording for User_instruction_full when it is short enough to fit naturally.
• Summarize Codex_feedback at the issue/decision level, not at the implementation log level.
• If the user rejects a plan or corrects Codex, record that clearly in User_choice_or_followup.
• If a later user turn resolves a previous Pending choice, update the prior entry if that makes the history clearer; otherwise append a new entry that references the decision.

Project selection

Choose the history file using this priority:

1. If the project is under /home/gguo/code, write to /home/gguo/code/history/<project>.md.
2. Otherwise use the project directory explicitly named by the user.
3. Otherwise use the repository currently being edited or inspected.
4. _workspace if the request spans multiple projects or only concerns the shared workspace.

If more than one project is materially involved, either:

• append the same entry to each affected project file, or
• write a shared _workspace.md entry and mention the affected projects in Context.

Style rules

• Be concise but complete.
• Record facts, decisions, and constraints.
• Do not record sensitive secrets unless the user explicitly asks for that.
• Do not invent actions the user did not take.
• Do not describe tool calls unless they matter to the project decision itself.