Skip to content

Add reviewable brain-dump triage and GitHub backlog promotion skill #78

Description

@szmyty

Outcome

Create a reusable, provider-neutral Aether skill/workflow that lets a user freely brain dump project ideas in chat or another captured source, preserves immature thoughts without forcing them into tasks, and promotes only suitable reviewed items into deduplicated GitHub issue candidates.

The intended experience is deliberately low friction:

free-form brain dump
        ↓
faithful capture / normalized source
        ↓
atomic thought + relationship extraction
        ↓
maturity / actionability triage
        ↓
knowledge note | open question | experiment | architecture | issue candidate
        ↓
repository + duplicate review
        ↓
explicit user-approved GitHub issue creation

The user should be able to talk naturally while walking or thinking without having to structure the ideas first.

Architecture boundary

Compose existing ownership instead of creating a second knowledge or capture system:

  • Mindcap / conversation archives preserve faithful source material.
  • Mindgarden owns normalized sources, durable knowledge, synapses, gardenization plans, provenance, sensitivity, and routing.
  • Aether owns the agent skill, interaction workflow, tool orchestration, candidate formatting, repository inspection, and GitHub handoff.
  • GitHub remains the execution/backlog surface for work that is mature enough to become an issue.

Relevant existing work:

  • egohygiene/mindgarden#13 — reviewable gardenization plans
  • egohygiene/mindgarden#14 — knowledge routing and private fallback
  • egohygiene/mindgarden#15 — conversation archive ingestion
  • egohygiene/mindgarden#39 — inbox / chat-dump architecture skeleton
  • egohygiene/aether#51 — Mindgarden curator skill
  • egohygiene/aether#67 — repository-default skills, including GitHub issue authoring as a candidate capability
  • egohygiene/aether#69 — scoped agent-session capabilities

Interaction model

Capture first

During a brain-dump session the agent should:

  • allow fragmented, nonlinear, interrupted thoughts;
  • avoid asking the user to pre-classify or rewrite ideas;
  • preserve intent, rationale, connections, uncertainty, and unresolved questions;
  • distinguish user statements/decisions from assistant interpretations;
  • avoid prematurely solving or implementing every thought.

Triage later

After enough material exists, propose atomic items such as:

  • long-term vision;
  • raw synapse / idea worth retaining;
  • architecture or design direction;
  • experiment / spike;
  • durable knowledge;
  • reusable tool/workflow;
  • content/article candidate;
  • open question;
  • actionable GitHub issue candidate.

These labels are interaction aids, not a mandatory canonical Mindgarden taxonomy. The underlying canonical types must continue to use Mindgarden's versioned contracts.

GitHub promotion

For every issue candidate:

  1. identify the likely owning repository from current organization/repository evidence;
  2. search open and closed issues for duplicates, superseded work, or an existing parent issue;
  3. show matching/overlapping work in the review plan;
  4. create a new issue only when the candidate adds distinct work;
  5. produce a Copilot-ready issue body with outcome, context, scope, acceptance criteria, dependencies, validation expectations, and non-goals where useful;
  6. preserve safe provenance back to the originating knowledge/source record without copying private transcript content into a public issue;
  7. require explicit write authority/user approval before GitHub mutation.

If ownership, privacy, or duplication is ambiguous, keep the candidate reviewable rather than guessing or publishing it.

Candidate contract

Define a versioned backlog-promotion record containing at least:

  • stable candidate ID and revision;
  • source / Mindgarden node references;
  • concise title and problem/outcome statement;
  • maturity and actionability state;
  • proposed repository and ownership rationale;
  • related/duplicate/superseding issue matches;
  • dependencies and blockers;
  • proposed issue body;
  • sensitivity and public-safe transformation state;
  • user-review status;
  • external-write authorization state;
  • created issue reference when successfully applied;
  • no-op / skipped / duplicate reason when not created.

The record should be reusable across compatible agent hosts and should not embed credentials or provider-specific tool state.

Idempotency and reconciliation

  • Re-running the workflow against the same reviewed source must not manufacture duplicate issues.
  • Existing issue numbers/URLs become durable references after creation.
  • If an equivalent issue already exists, link the knowledge candidate to it rather than creating another issue.
  • Later refinement may update the candidate or propose an issue comment/edit, but must not silently rewrite a human-maintained issue.
  • Closed-as-completed, closed-as-not-planned, superseded, and duplicate issues must remain distinct states during matching.

Privacy and authority

  • Raw private brain dumps remain private by default.
  • A public GitHub issue may contain only content that passes the selected publication/sensitivity policy.
  • Private filenames, transcript excerpts, health/financial/personal details, or unrelated context must not leak merely because they motivated an engineering idea.
  • Tool availability does not grant mutation authority.
  • Issue creation is an explicit downstream action, not a side effect of capture or gardenization.

Acceptance criteria

  • A provider-neutral brain-dump triage skill/workflow is defined in Aether.
  • The skill composes Mindgarden contracts instead of defining a competing knowledge store or taxonomy.
  • Free-form capture works without requiring the user to structure thoughts while speaking.
  • Atomic items preserve source provenance, uncertainty, relationships, and decision status.
  • Non-actionable or immature ideas can remain durable notes/open questions without becoming GitHub issues.
  • A versioned backlog-promotion candidate contract exists.
  • Candidate repository routing is evidence-backed and ambiguity remains reviewable.
  • Open and closed GitHub issues are searched before creation to detect duplicates, supersession, and existing parent work.
  • Public issue bodies never require copying private raw transcript content.
  • GitHub mutation requires explicit user/write authorization.
  • Re-running an unchanged reviewed candidate is idempotent and does not create duplicate issues.
  • Successful application records the created issue identity back into the candidate/projection state.
  • Synthetic fixtures cover a raw idea, open question, architecture note, experiment, new issue, exact duplicate, partial overlap, wrong-repository proposal, private-source/public-safe issue, and denied-write session.
  • At least one end-to-end Ego Hygiene dogfood session proves brain dump → review → deduplicated issue creation.

Non-goals

  • Turning every captured thought into a task.
  • Autonomous backlog flooding.
  • Making the proposed UX categories canonical Mindgarden ontology.
  • Publishing raw private conversation archives to GitHub.
  • Automatically assigning priority, milestone, or assignee without current policy/evidence.
  • Replacing Mindgarden gardenization or GitHub's issue tracker.
  • Implementing the ideas contained in the brain dump as part of this issue.

Source

Captured from an Ego Hygiene project-vision brain-dump workflow discussion on 2026-09-07. The motivating interaction was intentionally capture-first: unload thoughts during a walk, preserve relationships, and queue mature items as GitHub issues later rather than forcing every thought directly into implementation.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions