igapyon-miku-daybook

Files (22)

• SKILL.md
• openai.yaml · agents/
• day-plan-notify.yml · assets/daybook/.github/workflows/
• package-lock.json · assets/daybook/
• package.json · assets/daybook/
• day-plan.mjs · assets/daybook/scripts/
• day-plan.test.mjs · assets/daybook/scripts/
• generate-day-plan.mjs · assets/daybook/scripts/
• import-issues.mjs · assets/daybook/scripts/
• import-issues.test.mjs · assets/daybook/scripts/
• issue-import.mjs · assets/daybook/scripts/
• issue-import.test.mjs · assets/daybook/scripts/
• post-day-plan.mjs · assets/daybook/scripts/
• post-day-plan.test.mjs · assets/daybook/scripts/
• issue-import.md · references/
• notification.md · references/
• operations.md · references/
• records.md · references/
• task-date-migration.md · references/
• task-planning-migration.md · references/
• url-task-lookup.md · references/
• waypoints.md · references/

SKILL.md (first lines)

# igapyon-miku-daybook

Manage the Markdown records in a daybook repository. The records are the source of truth; generated day-plans and GitHub notifications are derived views.

The task/activity recording policy is informed by both the user's practical daybook experience and MIT OpenCourseWare's [Guidelines for Keeping a Laboratory Notebook](https://ocw.mit.edu/courses/7-16-experimental-molecular-biology-biotechnology-ii-spring-2005/b4c64ac11fc0a68466af7e025e29bf3e_lab_notebook.pdf), a course resource for *7.16 Experimental Molecular Biology: Biotechnology II* (Spring 2005). Use the material's guidance on prompt recording, observations and results, and review and next steps as supporting rationale for recording decisions. The preference for activity capture followed by task consolidation when needed is a daybook-specific judgment developed from that guidance and experience.

Keep a task's latest conclusion, state, and next actions with a brief history; keep dated work, trials, observations, and decision reasons in activities. See [task and activity responsibilities](references/operations.md#task-and-activity-responsibilities) for the editing rules.

Unless the user specifies another style, write narrative prose in daybook records in Japanese polite form (です・ます調). Bullet items may use concise plain-form sentences or noun phrases; do not force polite endings on every bullet.

## Terminology

`task-id` (task ID) is a task's persistent identifier: its front matter `id` value in `task-YYYYMM-NNNNN` format, for example `task-202610-00014`. The same value forms the task filename's ID prefix and its attachment folder name. Use `task-id` when referring to this identifier; keep the YAML field name as `id`.

## Activation and boundaries

Use this skill when the user says `igapyon-miku-daybook`, `miku-daybook`, or clearly asks to add, update, list, or summarize records in the daybook repository, including saving or resuming a `waypoint`. Also use it when the user explicitly asks to check or find existing daybook tasks related to a supplied URL. A URL alone or a request only to read or summarize it does not start task lookup. Use the Issue-intake procedure only when the user explicitly asks to import named GitHub Issue(s) into daybook. Also use it when the user explicitly asks to generate or update the daybook GitHub Actions notification workflow. Do not activate for a generic TODO request, an igapyon diary entry, an Issue inspection that does not ask for related daybook tasks, or a question about this skill itself.

This skill edits daybook records, local documentation, and an explicitly requested notification workflow. It does not automatically commit, push, create pull requests, dispatch workflows, send email, or synchronize Issues with tasks. Explicit Issue intake is a narrow exception: follow [issue-import.md](references/issue-import.md) to prepare local records, then use the existing miku-scm comment and close workflows for the intake receipt and verified intake close. The daybook request authorizes that bounded workflow, but does not bypass miku-scm's current Issue snapshot, preflight, approval, apply, and attempt-recovery requirements. Do not post comments or close Issues for an Issue read, candidate list, ordinary daybook update, or resumed import unless the user's request covers that action.

Weekly recurrence is maintained only for an explicit weekly-task registration or rollover request, following [operations.md](references/operations.md). Ordinary record edits and migrations do not trigger recurrence-field initialization, an additional weekly-task scan, or rollover. For rollover, process only the requested tasks; process all active weekly tasks only when the user explicitly requests that scope. The skill does not run in the background. Keep read-only task lists and explanations non-mutating. Day-plan generation may write or overwrite its generated snapshot, but must not modify source task or schedule records.

## Required first checks

1. Identify the target daybook repository from the current working directory or the user's path. Do not assume a fixed absolute path.
2. Read the target repository's `README.md` and current Git status. Preserve unrelated user changes.
3. Read only the reference needed for the current operation:
   - [records.md](references/records.md) for schemas, paths, IDs, and dates.
   - [operations.md](references/operations.md) for add, update, list, activity, schedule, and day-plan workflows.
   - [attachments.md](references/attachments.md) before retaining supplied material, generated results, or supporting files; it defines activity-first recording, durable external storage, deliberate use of attachments, temporary work files, and the extremely rare binary exception.
   - [notification.md](references/notification.md) for GitHub Actions workflow generation or email notification troubleshooting.
   - [issue-import.md](references/issue-import.md) only for an explicit request to import GitHub Issue(s).
   - [url-task-lookup.md](references/url-task-lookup.md) only for an explicit request to find daybook tasks related to a URL.
   - [waypoints.md](references/waypoints.md) for an explicit request to save, list, update, or resume a waypoint.

## Core workflow

Classify the request before editing: task, schedule, activity, task list, day-plan, waypoint, explicit URL-to-task lookup, explicit Issue import, notification, explanation, or explicit weekly-task maintenance. When choosing between activity and task for a recording request, prefer an activity unless the request clearly calls for registering future work or editing a task. If only that classification is unclear, choose an activity without a classification question. Resolve an existing record by its full ID/path/title before creating a new one. When record identity is ambiguous, use the available date, month, title, and links to narrow it; do not create a duplicate silently. Keep checks and edits within the requested records and information directly needed for their consistency.

For an explicit waypoint request, follow [waypoints.md](references/waypoints.md). A waypoint is a short resume entry that points to canonical task and activity records; it does not replace them. Numbered entries are for independently resumable subwork, not a second task plan.

For an explicit URL-to-task relationship request, follow [url-task-lookup.md](references/url-task-lookup.md). Treat lookup as read-only: report candidate tasks and the evidence for each, without creating or changing records. A URL alone or a request only to read or summarize a page does not start this lookup. If the user also asks to update records, apply only that requested scope and follow [Task completion and scope](references/operations.md#task-completion-and-scope).

For a concrete task request, create or update a `tasks/task-YYYYMM-NNNNN-name.md` record even when the user says “TODO”. Keep a vague idea in `TODO.md` only when it is genuinely not actionable. Write `planning_state: planned` for a new task unless the user asks to keep it as Backlog; then write `planning_state: backlog`. Do not infer Backlog from missing dates, low priority, a long period, or `todo` status. A Backlog task may omit either or both planned dates and must not receive a provisional date just to fill them. For a planned task, include both `planned_start_date` and `planned_end_date`; use the same date for a one-day plan. Set `planned_dates_status: confirmed` only when both endpoints are explicit or the user confirms the complete period; any date filled by an assumption is `provisional`. If the user leaves planned-task dates open, use the provisional-date rules in [operations.md](references/operations.md) and identify the assumed dates in the record and response. An unbounded weekly recurring rule is exempt and must not use `planned_dates_status`; its dated occurrences use schedules. When a task becomes `done` or `cancelled`, update its status in place and keep the file in its creation-month directory; do not move it to an archive or closed folder. For a task list, show `ID / Priority / Status / Planning state / Planned start / Planned end / Title`, grouping Backlog separately from planned tasks. Add a `Next` value for weekly tasks from `next_occurrence`; do not substitute it for the rule's planned dates or use it as a sort key.

When the user explicitly registers a weekly recurring task, keep one active task as the recurring rule and create its first dated schedule when the date and details are known. Mark it with `recurrence: weekly` and store its next date in `next_occurrence`; do not invent an end date for a recurring rule that has no planned end. Limit registration to that task and its occurrence schedule. Editing an existing weekly task does not itself request rollover. Read [records.md](references/records.md) and [operations.md](references/operations.md) for the record and explicit rollover rules.

For schedules, use `status: scheduled` or `status: cancelled`. Keep cancellation separate from the user's participation decision; cancelled events stay in the source records but are omitted from generated day-plans. Read [records.md](references/records.md) for legacy handling.

For a report of work or investigation actually performed, update the activity file for the Asia/Tokyo date. Keep one coherent event or work episode in one activity item, including a readable account of trial and error and decision reasons when known. An investigation without a conclusion is also an activity. Keep detailed accounts in activities; when task editing is in scope, consolidate the current conclusions, state, and next actions into the task with links to the activities, without copying the detailed account. An activity-only request does not add a task edit; update a task only when task editing is in scope, and use [Task completion and scope](references/operations.md#task-completion-and-scope) to decide whether completion is established.

Before retaining supplied material or generated results, follow [attachments.md](references/attachments.md). Prefer keeping the work account and necessary findings in the activity itself. For separate materials, prefer a user-designated durable location outside the daybook repository, including another Git repository, and record a stable reference. Use text attachments deliberately when preserving a supporting artifact with daybook has a concrete benefit, such as a dated evidence snapshot or a reproduction script. Preserve valuable final or human-edited results as well as originals; `workplace/` is temporary working storage, not evidence of durable retention. If long-term storage is undecided, state that in the in-scope record. Retaining a binary in daybook Git remains an extremely rare, file-specific exception. For retained text attachments, use the primary record's month: tasks use `attachments/<task-id>/`, while activities and schedules use the filename stem under `attachments/`. Link relatively, keep one copy of shared material, and do not copy attachments into generated day-plans.

For day-plan generation, use the target repository's updated `scripts/generate-day-plan.mjs` with its default output root so the file is written to the canonical `YYYY/YYYYMM/day-plan/day-plan-YYYYMMDD.md` path under the target repository root. Use today's Asia/Tokyo date unless the user specifies another date. Set `--output-root` only when a separate staging directory is explicitly needed. The target date plus six days is the display window. The generated plan separates today's work and other date-based task groups from a dedicated Backlog section. Active `planning_state: backlog` tasks from all months appear only in Backlog, regardless of dates or priority; completed/cancelled tasks stay excluded. Schedules remain date-based. Display both ends of each planned task period. Sort today's tasks by priority, and sort dated task sections by date then priority, using full task ID as the final tie-breaker. Priority affects ordering only, not task selection. Regeneration overwrites the existing day-plan for that date; treat it as a generated snapshot and do not edit it as a source record. Do not reimplement this selection in the skill.

When a user asks to change existing task date fields or migrate a daybook, read [task-date-migration.md](references/task-date-migration.md). When they ask to classify tasks as Backlog or adopt the separate planning-state field, read [task-planning-migration.md](references/task-planning-migration.md). These guides cover user-run data edits, old-record handling, and verification.

For an explicit notification workflow generation or update, read `references/notification.md` and use its exact bundled runnable file list from [assets/daybook](assets/daybook/). Adapt repository-specific values after inspecting the target repository. Preserve existing package scripts and dependencies. Do not create a YAML-only workflow that refers to scripts absent from the target repository. Issue-intake helper scripts are a separate local setup described in [issue-import.md](references/issue-import.md); do not add them merely to install notifications.

## After editing

Validate front matter, ID and filename agreement, required priority and planned date range on newly created ordinary tasks, any present priority values (`1`–`9`), date ordering, status checkboxes, and relative links. Keep source email or event URLs when supplied. Record provisional dates and their basis in the Markdown instead of presenting them as user-confirmed. Run `git diff --check` and report changed files and any remaining ambiguity. Do not commit or push unless explicitly requested.

From igapyon/igapyon-agent-skills, Apache-2.0.

More from igapyon/igapyon-agent-skills