HanZephyr Maintain Decision Records
Reduce obsolete active material while preserving decisions that still guide work. Use this skill for a requested assessment or maintenance of decision records. Adding a new record does not itself authorize archiving, rejecting, or deleting others. An assessment reports recommendations; execute changes covered by the current task and existing authorization without requesting the same permission again.
Establish the record's role
Read the project's record lifecycle, retention, archive, and linking conventions when they exist. Inspect the records in scope together with relevant current code, configuration, documentation, newer decisions, and inbound references. Status labels, age, and word count help discovery but do not establish whether a record is obsolete.
Do not impose a new archive directory, frozen-archive policy, translation scheme, hash mechanism, or status vocabulary. Where the project has no convention, explain the proposed disposition in the assessment; a requested archival operation can use a simple reversible move consistent with the existing layout. Ask only when a missing retention or deletion decision materially affects what may be lost.
Assess future decision value
- Still useful: retain rationale that governs current ownership, security, durability, compatibility, alternatives, or conditions for reintroducing a capability. Even a short rejected proposal can prevent a plausible repeated mistake.
- Completed with little current value: consider archiving an implemented decision whose remaining content concerns completed work or superseded mechanics, subject to the project's retention policy.
- Live proposal: keep it distinguishable from settled history. Lack of recent activity is not proof that it was rejected; a status change needs evidence and authorization within the task.
- Superseded or obsolete: identify the replacement and any surviving obligations. Rejection or supersession does not by itself make deletion appropriate; project retention rules or the requested scope determine whether to retain, archive, consolidate, or delete.
Do not seek an archive quota. For borderline records, state the surviving decision value and missing evidence rather than using size as a tiebreaker.
Distinguish full and partial supersession
A record is only fully superseded when no independently current decision or obligation remains outside the replacement. Check surviving behavior, stored or wire formats, migrations, compatibility support, and rejected alternatives. Removing one implementation or default does not necessarily remove the capability.
Before a requested consolidation, preserve unique rationale, alternatives, consequences, verification evidence, and known coverage gaps in the appropriate surviving record. Label historical evidence as historical; do not present tests of a removed implementation as proof of the current system. Preserve why a capability was removed and any meaningful conditions for its return. Keep partially superseded records cross-linked where the project permits it.
Deletion requires that the task permits it, retention conventions allow it, and the material has no remaining value that would be lost. Git history alone is not an adequate replacement for rationale that current maintainers still need.
Carry out authorized maintenance
- Establish the source and destination of each affected record and check inbound file and section links before moving it.
- Include associated language copies, indexes, attachments, or metadata only where they exist and belong to the record. Preserve the content during a simple archival move; perform substantive consolidation only when it is part of the task.
- Use the project's archive markers or verification mechanism if present. Respect an existing immutable archive; do not create sealing requirements for a project that has none.
- Repair affected active references. Point descriptions of current behavior to current authority and historical citations to preserved history. Check outbound links affected by a move when the archive is editable; if frozen-record rules prevent repair, report relevant broken references without rewriting the snapshot.
- Inspect the final diff and run applicable link, record, or documentation checks. Do not claim link validity or hash verification unless it was actually checked.
Report what was assessed or changed, why records were retained or retired, where preserved material now lives, and any unresolved retention or reference issue. An unchanged assessment is a valid outcome when the records still carry useful decisions.