manage-report-lifecycle

Installation
SKILL.md

Manage report lifecycle

Establish one authoritative hosted report while preserving every source item and predecessor. This skill coordinates lifecycle semantics here, shared-state authorization through preflight-mutations, and final acceptance through done.

1. Inventory the report set

Run one authoritative host or workspace discovery query broad enough to find every hosted analytical artifact matching the report's title, stable ID, source URLs, or subject. Record the exact query, every match's stable host ID and current guard, and classify each as source, canonical-candidate, or unrelated, with a rationale.

Fetch the rendered content and stable URL of every source and canonical candidate. For each, record its URL, title, write authority, current authority or supersession marker, and source-owned finding or item IDs with their direct evidence URLs. Preserve source-workflow IDs. When a report has none, assign artifact-scoped IDs without changing the source.

Keep this working record inline during read-only inventory and staging. Before the multi-write publication begins, persist it in an existing durable ledger that the user authorized this workflow to write. Record its stable URL or path and require it to remain outside every canonical and predecessor publication target for the full run. When no such ledger exists, stop and name authorization of a suitable existing artifact as the next action. Create no lifecycle registry.

The gate is that the exact discovery query and every classified match are recorded, every source, canonical candidate, and source item appears once, write authority is known, and competing authority claims are explicit.

2. Stage the canonical record

Choose one existing hosted, writable canonical candidate with a known stable URL and current write guard. When none exists, stop and name creation or selection of that hosted candidate as the next action. This skill does not create the first canonical object.

After election, reclassify every discovery match as canonical, writable-predecessor, unwritable-predecessor, or unrelated, with a rationale for every unrelated match. Every noncanonical match presenting itself as current authority must be one predecessor class and appear in the lifecycle record and publication plan.

Installs
19
GitHub Stars
2
First Seen
Aug 16, 2026
manage-report-lifecycle — bhagyamudgal/skills