Knowledge Compact
| This documentation was generated with the assistance of AI. Please report any inaccuracies. |
Keep knowledge/pending and knowledge/agreements honest: one pending file per distinct piece of outstanding
work, and nothing still marked open once its tracked issue says it’s done.
Purpose
iru-knowledge-compact compacts the knowledge base that iru-knowledge-process-inbox
builds up meeting after meeting. Two kinds of cruft accumulate there naturally, and neither is a bug in how the
base was filed: the same action item gets re-raised in a later meeting and is deliberately filed as its own
pending task rather than judged in isolation, and work that has actually shipped stays marked open because
nothing was watching its tracker issue. This skill sweeps both.
It groups pending tasks that describe the same piece of work — not merely the same words — and for each group
keeps a single survivor: the one member that already carries a tracker issue, or the earliest task id when none
do, folding whatever extra context the removed members carried (a deadline, a named owner, a narrowed scope, an
extra meeting that re-raised it) into the survivor before deleting them. A group where more than one member
has a tracker issue is deliberately left untouched and reported for a human decision, since collapsing it would
orphan a tracked issue. It then reads the current state of every GitHub issue / Jira ticket recorded on a
pending task or agreement item by iru-knowledge-to-issue /
iru-knowledge-to-jira, and closes out the ones already closed as
completed — delegating each to iru-knowledge-complete where a
pending file still exists. An issue closed as not planned is treated as not completed and put to the user,
never checked off as if it shipped. Finally it repairs drift between the two directories.
The skill only ever reduces the base. It never creates or rewords an agreement, never touches
knowledge/meetings or knowledge/people (a meeting record is history), and never closes, reopens, or
comments on a tracker issue — it reads issue state, it doesn’t drive it. Every deletion and edit is presented
for confirmation first, because the duplicate judgement is the skill’s own reading of the text rather than
something the files state outright.
Inputs
| Argument | Required | Description | Default |
|---|---|---|---|
(none) |
No |
This skill takes no arguments — it sweeps the whole of |
Not applicable. |
Tracker access is checked but never required: gh (authenticated, on a GitHub-hosted repository) for
- GitHub issue: references, and a connected Jira MCP tool for - Jira ticket: references. If neither is
reachable the run continues with duplicate detection and drift repair, skipping the completion checks rather
than guessing whether anything is done.
Outputs
-
Duplicate pending files deleted, with the extra context they carried appended to the surviving
knowledge/pending/pending-<timestamp>-<n>.mdalong with a- Supersedes: <task-id>note. The removed members' agreement items stay unchecked and gain a(superseded by task <survivor-id>)note — a duplicate is still outstanding work, just tracked elsewhere. -
Completed items closed out: the pending file removed and its numbered agreement item checked off (via
iru-knowledge-complete), or the item’s[ ]flipped to[x]directly where no pending file remained. -
Approved drift repairs: a pending file whose agreement item is already
[x]deleted. -
Approved closed-as-not-planned items handled as the user chose — annotated
(not planned — <issue url>)with the checkbox left[ ], since the work was abandoned rather than delivered. -
A grouped report: duplicates collapsed (and those deliberately left alone, plus borderline pairs it declined to merge), items closed out and the issue that proved each one, closed-as-not-planned items, drift repairs, untracked open agreement items, and everything skipped with its reason — closing with pending/open-item counts before and after.
-
Nothing at all, if the user cancels at the confirmation step.
Execution flow
Dependencies
Invokes
-
iru-knowledge-complete— Step 6, once per completed item that still has a pending file, to delete that file and check off its agreement item. If it stops on an inconsistency (a missing agreement file, an item not found, an item already checked),iru-knowledge-compactrecords the message and carries it into its report rather than working around it by hand.
Invoked by
-
iru-knowledge-process-inbox— as its Step 11, once for the whole run after every meeting group has been filed, so the newly created pending tasks are reconciled against what earlier meetings already produced. Skipped there if the run created no agreements at all, or if this skill isn’t installed in the repository (the catalog’s skills are adopted individually).
It is also a top-level entry point, run directly by a person as periodic housekeeping.
Source
SKILL.md on GitHub — the file this page was generated from.