Run any Skill in Manus with one click

cursor-diary

Keep a tiny-step implementation diary during coding sessions (what changed, why, commands run, failures, and what was learned), with docmgr integration (doc add/relate/changelog). Use when the user asks to "keep a diary", "write a dev log", or document work step-by-step.

Run Skill in Manus

Stars13

Forks3

UpdatedJanuary 2, 2026 at 14:56

Source

go-go-golems

go-go-golems/docmgr

View GitHub Repository View Creator Repositories

Install command

Download

Run Skill in Manus

Useful forSOC

Software DevelopersComputer and Mathematical Occupations15-1252L4

File Explorer

2 files

SKILL.md

readonly

name	cursor-diary
description	Keep a tiny-step implementation diary during coding sessions (what changed, why, commands run, failures, and what was learned), with docmgr integration (doc add/relate/changelog). Use when the user asks to "keep a diary", "write a dev log", or document work step-by-step.

Cursor Diary

Overview

Maintain a step-by-step implementation diary as you work, focused on reproducibility (exact commands, file paths, commit hashes) and review efficiency (what to check + how to validate).

Workflow

1) Bootstrap

Create a diary doc early (before exploration if possible).
- If using docmgr tickets: docmgr doc add --ticket TICKET-ID --doc-type reference --title "Diary"

2) Record each tiny step (frequently)

Write 1–2 short prose paragraphs first (intent + what it unlocked).
Include exact commands, key outputs, and versions when relevant.
Capture failures verbatim (errors are valuable).

3) Keep code ↔ docs consistent (docmgr loop)

Implement + format + test.
Commit code (record hash).
Update diary with the commit hash + rationale.
Relate files to the diary with absolute paths: docmgr doc relate --doc <diary-path> --file-note "/abs/path:why it matters"
Update ticket changelog per step: docmgr changelog update --ticket TICKET-ID --entry "Step N: ..." --file-note "/abs/path:reason"
Commit docs separately (e.g., Diary: record Step N).

Output template

Use the diary template in references/diary.md (copy/paste) as the canonical structure.

Notes

Prefer many small steps over a few big ones.
Always include: “What was tricky to build” + “What warrants a second pair of eyes” when behavior changes.

More from this repository

same repository

cursor-debate

go-go-golems/docmgr

Run a research-first, multi-perspective debate to explore complex technical decisions (trade-offs, architecture choices, integration strategies) using concrete codebase evidence. Use when the user asks to "debate" approaches, compare options, or needs a structured exploration before deciding.

2026-01-0213

cursor-docmgr

go-go-golems/docmgr

Use the docmgr CLI to manage ticketed docs (create tickets, add docs, relate code files with file-note, update changelog, and search). Use when the user asks how to use docmgr, wants a docmgr command sequence, or needs docmgr best practices (file-note, quoting, doctor).

2026-01-0213

cursor-git-commit

go-go-golems/docmgr

Provide a pre-commit checklist and staging hygiene (review diffs, stage specific files, avoid common noise like dist/ or .env, and fix mistakes with reset/rm --cached/amend). Use when the user is about to commit, asks for a commit workflow, or needs help cleaning up staged files.

2026-01-0213

cursor-remarkable-upload

go-go-golems/docmgr

Upload markdown (including docmgr ticket docs) to a reMarkable device as PDF via a local uploader script, with a safe dry-run and optional mirroring of ticket structure. Use when the user asks to send docs to reMarkable, export markdown to PDF for reMarkable, or troubleshoot rmapi/pandoc/xelatex.

2026-01-0213

name	cursor-diary
description	Keep a tiny-step implementation diary during coding sessions (what changed, why, commands run, failures, and what was learned), with docmgr integration (doc add/relate/changelog). Use when the user asks to "keep a diary", "write a dev log", or document work step-by-step.

Cursor Diary

Overview

Maintain a step-by-step implementation diary as you work, focused on reproducibility (exact commands, file paths, commit hashes) and review efficiency (what to check + how to validate).

Workflow

1) Bootstrap

Create a diary doc early (before exploration if possible).
- If using docmgr tickets: docmgr doc add --ticket TICKET-ID --doc-type reference --title "Diary"

2) Record each tiny step (frequently)

Write 1–2 short prose paragraphs first (intent + what it unlocked).
Include exact commands, key outputs, and versions when relevant.
Capture failures verbatim (errors are valuable).

3) Keep code ↔ docs consistent (docmgr loop)

Implement + format + test.
Commit code (record hash).
Update diary with the commit hash + rationale.
Relate files to the diary with absolute paths: docmgr doc relate --doc <diary-path> --file-note "/abs/path:why it matters"
Update ticket changelog per step: docmgr changelog update --ticket TICKET-ID --entry "Step N: ..." --file-note "/abs/path:reason"
Commit docs separately (e.g., Diary: record Step N).

Output template

Use the diary template in references/diary.md (copy/paste) as the canonical structure.

Notes

Prefer many small steps over a few big ones.
Always include: “What was tricky to build” + “What warrants a second pair of eyes” when behavior changes.