update-current-state

name	update-current-state
description	Update BRIEFING-CURRENT-STATE.md when work changes project status. Any agent can use this after closing issues, completing gates, filing findings, or shipping features. Keeps the briefing fresh without waiting for Docs.
scope	all-agents
version	1
created	"2026-04-07T00:00:00.000Z"

update-current-state

Update docs/briefing/BRIEFING-CURRENT-STATE.md to reflect current project status.

When to Use

Any agent should use this skill when their work changes project state:

• Issue closed or filed
• Gate status changed (passed, failed, re-test ready)
• Test count changed significantly
• New skill, pattern, or ADR created
• Sprint/milestone status changed
• Blocker resolved or discovered

Standing request (PM 2026-04-22): Any agent who notices the briefing is stale — the Last Updated footer or STATUS BANNER date is more than a few days behind the current date, or the stated sprint/gate/metric status is visibly out of sync with the last few days' session logs — should refresh it without waiting for Docs or CIO to own the task. Update what you can confidently attest to, leave unverified sections alone, and commit. A partially-current briefing is strictly better than a fully-stale one.

Which Section to Update

Only update the section(s) relevant to your work. Do not rewrite the whole file.

What changed	Section to update
Gate pass/fail/re-test	STATUS BANNER + Gate Status table
Issue closed/filed	Recent Progress (add bullet to current week)
Tests added/fixed	Metrics Snapshot (test count)
New pattern/ADR/skill	Metrics Snapshot + System Capability
Sprint milestone	STATUS BANNER + Inchworm Position
Blocker found/resolved	Open Items by Priority
New infrastructure	Metrics → Infrastructure

Procedure

Step 1: Read the Current File

cat docs/briefing/BRIEFING-CURRENT-STATE.md

Identify which section(s) need updating based on your work.

Step 2: Update Relevant Section(s)

Use the Edit tool to modify only the affected section. Preserve everything else.

STATUS BANNER format (always update Last Updated):

**Current Position**: [inchworm position]
**Version**: [version from pyproject.toml]
**Last Updated**: [today's date]
**Current Focus**: [one-line summary]
**Next Phase**: [what follows]

Recent Progress format (prepend new week, keep 4 most recent):

### [Date range] ([Theme])
- **[Date]**: **[Key event].** [Details with issue numbers, commit hashes, role names.]

Gate Status format:

- **Gate N** (Name): ✅/❌/🔲 [status] [details]

Step 3: Update the Timestamp

Always update both:

• STATUS BANNER **Last Updated**: line
• Footer *Last Updated:* line

Step 4: Commit

git add docs/briefing/BRIEFING-CURRENT-STATE.md
git commit -m "briefing: update CURRENT-STATE — [what changed]"

Rules

• Only update what you know. Don't guess at other agents' work.
• Preserve history. Don't delete Recent Progress entries — add new ones at the top, trim old ones at the bottom (keep 4 most recent week sections).
• Use evidence. Include issue numbers, commit hashes, test counts — not vague claims.
• Keep it scannable. One bullet per event. Bold the key fact. Details after.
• Don't duplicate the omnibus. The briefing is a status snapshot, not a narrative. Point to omnibus logs for details.

Anti-Patterns

Don't	Do Instead
Rewrite the whole file	Update only your section
Add vague "progress made" bullets	Cite specific issues, commits, counts
Update without reading first	Always read current state to avoid conflicts
Skip the timestamp update	Both timestamps must match today's date
Wait for Docs to update it	Any agent can and should update after significant work