---

name: log-dev-note description: Create a structured development note from the current Codex session when and only when the user explicitly invokes $log-dev-note. Use this skill only for the literal $log-dev-note command, optionally followed by a title override. Do not use this skill for semantic matches, paraphrases, or general requests to summarize work.

Log Dev Note

Overview

Use this skill only when the user's message explicitly includes the literal invocation $log-dev-note.

The skill turns the current Codex session context into a concise engineering log and returns it in a clean, paste-friendly format for manual copy.

Trigger Contract

• Trigger only on the literal command $log-dev-note.
• Do not trigger from semantic matching, paraphrases, or general note-taking requests.
• Treat any non-empty text after $log-dev-note on the same line as an optional title override.
• Ignore this skill entirely when the command is absent.

Examples:

• $log-dev-note
• $log-dev-note Built OneNote Logging Skill v1

Inputs

Use these inputs for every invocation:

• the full current Codex conversation context for this session
• the current system timestamp from the active environment
• the optional user-provided title override, if present after $log-dev-note

Prefer the recent session context when identifying the primary topic, but use the full conversation to capture important earlier decisions or constraints.

Output

The default destination is the conversation response only.

Execution rules:

1. Generate a brand-new note for every invocation.
2. Return the final title and note body in a clean, paste-friendly format.
3. Do not attempt browser automation, API writes, or clipboard integration.
4. Do not fabricate any external side effects. The skill only generates the note text.

Title Rules

The note title must use this format exactly:

[YYYY-MM-DD] – <title>

Title construction rules:

• Use the current system date for YYYY-MM-DD.
• If the user supplied a title override, use it verbatim after the dash.
• Otherwise generate a specific descriptive title based on the session's primary topic or milestone.
• Favor concrete milestones such as Built OneNote Logging Skill v1 over vague titles such as Worked on project.
• If a project name is obvious from context, include it when it improves specificity.

Note Structure

Format the note body using these markdown-style headings exactly as written:

Summary

Progress Made

Key Decisions

Current State

Open Questions / Issues

Next Steps

Relevant Context

Section rules:

• Summary: 2 to 4 sentences summarizing the meaningful outcome of the session.
• Progress Made: bullet points for features implemented, important changes, decisions enacted, and problems solved.
• Key Decisions: bullet points with the decision and brief reasoning.
• Current State: bullet points describing what is true at the end of the session.
• Open Questions / Issues: bullet points for unresolved issues, risks, blockers, or ambiguities.
• Next Steps: bullet points for immediate follow-up actions and short-term priorities.
• Relevant Context: bullet points for constraints, assumptions, architecture notes, tooling limitations, or environment details that matter later.

Content Rules

• Target roughly 150 to 400 words total.
• Keep the note concise, specific, and documentation-focused.
• Use bullets wherever possible outside the Summary.
• Summarize intelligently; do not restate the conversation verbatim.
• Prioritize progress, decisions, blockers, and current state over incidental discussion.
• Ignore small talk and irrelevant back-and-forth.
• If little progress was made, record what was attempted and why it stalled.
• If multiple topics were discussed, focus on the primary objective and group secondary items only if they materially matter.
• If context is ambiguous, infer the most likely primary focus from the most recent high-signal messages.

Optional enhancements when clearly supported by context:

• add concise keyword tags such as AI, Backend, Frontend, Codex Skill, or a project name
• include a session duration if timestamps are available
• mention the repository, service, or feature name when that materially improves future readability

Generation Workflow

1. Confirm that the invocation is the literal $log-dev-note command.
2. Parse any trailing text as the optional title override.
3. Review the current session context and identify the primary project objective, meaningful progress, decisions, blockers, and next steps.
4. Generate the note title using the required date format.
5. Draft the note using the exact section headings and concise bullet-heavy structure.
6. Return the note directly in the response for manual copy.

Edge Cases

• If the session has little useful information, create a minimal note that explicitly states limited progress.
• If the note would otherwise be empty, include at least the attempted objective, present state, and next step.

Response Format

After generating the note, respond briefly with:

• the final note title
• the generated note content