Add agenda, learnings, and task commands

2026-06-23 20:21:31 +02:00
parent a08ee3d5c8
commit 302d43a262
3 changed files with 240 additions and 0 deletions
@@ -0,0 +1,61 @@
 # /agenda
 Produce a prioritized overview of all open tasks with agent-assist inference.
 ## Behavior
 1. **Read all task files** in `todo/`, `ongoing/`, and `blocked/` folders at `~/Workspace/Personal/Tasks/`
 2. **Read all recurring definitions** in `meta/recurring/`
 3. **Sort tasks:**
   - Priority: High > Medium > Low
   - Within same priority: overdue first, then soonest due date, then TBD last
 4. **Infer agent-assistability** for each task based on description and context:
   - `Yes` -- task involves research, writing, analysis, code, document creation, data gathering
   - `Partial` -- task has agent-doable components mixed with human-only parts (meetings, decisions, calls)
   - `No` -- purely human tasks (meetings, calls, approvals, external dependencies with no prep work)
 5. **Output the agenda** in the format below
 ## Output Format
 ```
 ## High Priority
 | Task | Initiative | Due | Effort | Agent |
 |------|-----------|-----|--------|-------|
 | [task title] | [initiative] | [due or OVERDUE] | [effort] | [Yes/Partial/No] |
 ## Other Open Tasks
 | Task | Initiative | Due | Priority | Effort | Agent |
 |------|-----------|-----|----------|--------|-------|
 | [task title] | [initiative] | [due] | [priority] | [effort] | [Yes/Partial/No] |
 ## Blocked
 | Task | Initiative | Blocker | Agent |
 |------|-----------|---------|-------|
 | [task title] | [initiative] | [blocker summary from Notes] | [Yes/Partial/No] |
 ## Recurring
 | Task | Frequency | Next | Agent |
 |------|-----------|------|-------|
 | [task title] | [frequency] | [next occurrence] | [Yes/Partial/No] |
 ## Summary
 - X open tasks (Y high priority, Z overdue)
 - A in progress, B blocked
 - N tasks where agent can assist
 ```
 ## Rules
 - **High Priority table** includes all tasks with Priority: High from `todo/` and `ongoing/`
 - **Other Open Tasks table** includes Medium and Low priority tasks from `todo/` and `ongoing/`
 - **Blocked table** shows all tasks in `blocked/` regardless of priority
 - Tasks in `ongoing/` show their folder status as context (mention "in progress" in the row or table header)
 - **Overdue detection:** if Due date is before today's date, mark as OVERDUE in the Due column
 - Do NOT read `done/` or `cancelled/` folders
 - Keep output concise -- no descriptions, just the table fields
 - If a task's due date is relative (e.g., "Before integration testing"), display it as-is
@@ -0,0 +1,98 @@
 ---
 description: Extract learnings, domain knowledge, and decisions from the session and propose updates to context files
 ---
 Review the current conversation and summarize everything learned about Sam's preferences, workflows, decisions, domain knowledge, and way of working that is NOT already captured in the existing context files.
 ## Instructions
 1. Read the relevant context files to understand what is already documented:
   - ~/.config/opencode/AGENTS.md (global preferences)
   - The current project's AGENTS.md (if one exists)
   - ~/LLM Context/AGENTS.md (context system and file organization)
   - Any initiative-specific AGENTS.md files that were referenced in this session
   - Any other context files that were loaded during this session
   - ~/.config/opencode/skills/*/SKILL.md (existing skill definitions)
   - ~/.config/opencode/commands/*.md (existing command definitions)
   - ~/LLM Context/.opencode/commands/*.md (project-local command definitions)
   - Knowledge/ directories at relevant scopes (initiative, company/personal, global)
   - Decisions/ directories at relevant scopes (initiative, company/personal, global)
   - ~/LLM Context/Shared/Templates/decision-template.md (for decision format)
 2. Compare what was learned during this conversation against what is already documented. Identify NEW learnings only -- skip anything already captured. Before proposing any change, read the current content of the target file to verify a previous session has not already applied the same learning.
   Determine which scopes are relevant to this session (e.g., Business/Monizze/, a specific initiative). If ambiguous, ask Sam to confirm the scope before proceeding.
 3. Categorize each learning:
   - **Preference** -- how Sam likes to work (communication, review style, tooling choices)
   - **Decision** -- a concrete choice made during this session (tech stack, architecture, process)
   - **Workflow** -- how Sam interacts with agents, reviews work, iterates
   - **Correction** -- something the agent got wrong that Sam corrected
   - **Domain Knowledge** -- a fact, pattern, or observation about a specific domain (pricing, onboarding, competitors, etc.)
   - **Domain Rule** -- a confirmed pattern that should be applied by default (promoted from hypothesis after 3+ confirmations, or stated directly by Sam)
   - **Domain Hypothesis** -- a pattern that needs more data before becoming a rule
   - **Scoped Decision** -- a decision that affects more than today's task and should be logged for future reference
 4. Determine the correct target file for each learning:
   - Global preferences (apply everywhere) -> `~/.config/opencode/AGENTS.md`
   - Project-specific rules -> current project's `AGENTS.md`
   - Context system changes -> `~/LLM Context/AGENTS.md`
   - Domain context -> appropriate file in `~/LLM Context/`
   - Domain Knowledge / Rules / Hypotheses -> `Knowledge/[domain].md` at the appropriate scope
     - If the file exists, add to the correct section (## Rules, ## Hypotheses, or ## Knowledge)
     - If the file does not exist, create it using the format from LLM Context/AGENTS.md
     - Check if any existing hypothesis has now been confirmed 3+ times -- propose promotion to Rule
     - Check if any existing rule was contradicted in this session -- propose demotion to Hypothesis
   - Scoped Decisions -> `Decisions/YYYY-MM-DD-{topic}.md` at the appropriate scope
     - Use the template at `Shared/Templates/decision-template.md`
     - Search existing Decisions/ for prior decisions on the same topic
     - If replacing a prior decision, populate the ## Supersedes field
 5. Present learnings for review:
 # Learnings - [Date]
 ## Summary
 [1-2 sentence overview of what was learned]
 ## Proposed Updates
 ### [n]. [Short description]
 - **Type:** [Preference / Decision / Workflow / Correction / Domain Knowledge / Domain Rule / Domain Hypothesis / Scoped Decision]
 - **Scope:** [Global / Business/[Company] / Business/[Company]/Initiatives/[Name] / Personal / Personal/Initiatives/[Name]]
 - **Domain:** [domain name, if applicable -- e.g., pricing, onboarding]
 - **Learning:** [What was learned]
 - **Target file:** [Path to the file that should be updated]
 - **Proposed change:**
  ```
  [The specific text to add or modify in the target file]
  ```
 - **Status:** Pending review
 [Repeat for each learning]
 ## No Update Needed
 [List any learnings that are already captured in existing files -- confirm they match]
 6. After presenting the full summary, walk through each proposed change ONE AT A TIME. For each:
   - Show the change (target file, what will be added/modified)
   - Ask: "Accept, reject, or modify?"
   - Wait for Sam's response before moving to the next
   - Only apply the change after explicit acceptance
 7. For each accepted change, update the target file immediately, then present the next one.
 8. After all changes are reviewed, add a "Last Updated" entry to each modified file with the date and a brief description.
 IMPORTANT:
 - Never apply changes without Sam's explicit approval
 - Always go one at a time -- never batch approvals
 - Be specific -- show exact text to add/modify, not vague suggestions
 - If a learning contradicts an existing rule, flag the conflict and ask which is correct
 - Include the source of each learning (what Sam said or did that revealed it)
 - Skills and commands are valid target files -- if a session revealed a gap or correction in a skill or command, propose an update to that file directly
 - For knowledge items, always specify which section (Rules / Hypotheses / Knowledge) the entry belongs in
 - When promoting a hypothesis to a rule, remove it from ## Hypotheses and add it to ## Rules with a note like "Promoted from hypothesis -- confirmed in [sessions/dates]"
 - When demoting a rule to a hypothesis, remove it from ## Rules and add it to ## Hypotheses with a note like "Demoted -- contradicted by [what happened]"
 - For scoped decisions, always use the decision template format
 - When scope is ambiguous, ask Sam before proceeding -- one topic at a time
@@ -0,0 +1,81 @@
 # /task
 Create, update, complete, or list tasks. Single command for all task CRUD operations.
 ## Subcommands
 ### /task add [details]
 ### /task (no args -- defaults to add)
 Create a new task.
 **Shortcut mode:** `/task add "Title" high due:2026-04-15 initiative:Messaging-System effort:medium`
 **Guided mode** (no args or incomplete): Ask these questions one at a time:
 1. **Task title** -- short, action-oriented
 2. **Initiative** -- which initiative does this belong to? (list active initiatives from AGENTS.md, or "Personal", or "None")
 3. **Priority** -- High / Medium / Low
 4. **Due date** -- YYYY-MM-DD or TBD
 5. **Effort** -- Quick (<30 min) / Medium (30 min - 2h) / Deep (2h+)
 6. **Context** -- paths to context files in ~/LLM Context/ (or "none")
 7. **Description** -- what needs to be done
 **After gathering info:**
 - Create file at `todo/YYYY-MM-DD-short-slug.md` using today's date
 - Use the template from `meta/templates/task-template.md`
 - Remove the Completed field (not applicable in todo/)
 - Confirm creation with: "Created: `todo/YYYY-MM-DD-slug.md`"
 ### /task update [search-term]
 Modify an existing task.
 1. Search across `todo/`, `ongoing/`, and `blocked/` for a task matching the search term (title match, fuzzy is fine)
 2. If multiple matches, show them and ask which one
 3. Show the current task state
 4. Ask what to update -- offer these options:
   - Priority
   - Due date
   - Effort
   - Description
   - Notes (append)
   - Move to a different status folder
   - Multiple fields at once
 5. Apply the update and confirm
 **If status changes:** move the file to the new folder. If moving to `done/`, add Completed date (use `/task done` flow).
 ### /task done [search-term]
 Mark a task as completed.
 1. Search across `todo/`, `ongoing/`, and `blocked/` for the task
 2. Show the current task and ask for confirmation
 3. Ask: "Any notes to add before closing?"
 4. Add Completed date (today) to the task file
 5. Move file to `done/`
 6. Confirm: "Completed: moved to `done/YYYY-MM-DD-slug.md`"
 ### /task list
 Quick flat listing of all open tasks. Lightweight -- no inference, no analysis.
 1. Read all files in `todo/`, `ongoing/`, and `blocked/`
 2. Output a simple table:
 ```
 | Task | Initiative | Priority | Due | Folder |
 |------|-----------|----------|-----|--------|
 | ... | ... | ... | ... | todo/ongoing/blocked |
 ```
 Sorted by priority then due date (same rules as /agenda).
 ## Rules
 - All task files live in `~/Workspace/Personal/Tasks/`
 - Use `meta/templates/task-template.md` as the canonical format
 - Filename convention: `YYYY-MM-DD-short-slug.md`
 - When creating: date = today. When moving: keep the original filename (created date doesn't change)
 - The Completed field only appears in files inside `done/`
 - When cancelling: move to `cancelled/`, add reason in Notes