Conversation History Recorder

Conversation History Recorder

Use this skill for any task related to a project under /home/gguo/code.

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 level of detail.

Storage

• Store logs under /home/gguo/code/history/.
• Keep one Markdown file per project:
  • /home/gguo/code/history/<project>.md
• If the task is not tied to a single project, use:
  • /home/gguo/code/history/_workspace.md

<project> should normally be the top-level directory name under /home/gguo/code, such as eye, verl-gf, or video-nerv.

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 workspace projects, 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. The project directory explicitly named by the user.
2. The repository currently being edited or inspected.
3. _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.