briefing-first-startup

Imported from Yuancircle/smart-agent-startup (briefing-first-startup/SKILL.md). Install upstream with npx skills add Yuancircle/smart-agent-startup --skill briefing-first-startup. Copyright stays with the author.

Briefing-First Startup

Use this skill when you need to improve an agent's session startup discipline.

The goal is not to create a giant memory system. The goal is to ensure the agent starts each session with enough context to act well, but not so much that startup becomes bloated and noisy.

What this skill optimizes for

• Fast startup: recover useful context in a few reads, not dozens
• Stable recall: active work and core rules should still be recoverable
• Low context waste: avoid loading large files by default
• Safety against silent regressions: removing always-loaded rules must not remove the capability those rules protected

Core pattern

Use a three-layer startup model:

1. Identity + briefing layer

   • Read a short identity / user / role packet
   • Read one compact BRIEFING.md style file as the main entry point

2. Active work layer

   • Scan task files for markers like in progress, waiting, blocked, doing
   • Recover the 1-3 most relevant active items

3. On-demand expansion layer

   • If the incoming message clearly references a task, read that task file
   • If it continues a recent conversation, read only the relevant recent memory slice
   • If it asks about policy, mechanism, or prior decisions, read the relevant rule / memory file
   • Do not load everything by default

Recommended startup sequence

When the first user message arrives:

1. Read SOUL.md / identity file
2. Read USER.md / user profile file
3. Read BRIEFING.md / startup briefing
4. Scan active tasks
5. Route by message intent
6. Read only the next most relevant file(s)
7. Answer or execute

Message routing heuristics

If the message clearly points to a task

Read the matching task file first.

Examples:

• “continue the A11 work”
• “what happened with the deployment task?”
• “finish yesterday’s prompt optimization”

If the message is about prior discussion

Read recent memory slices or the relevant summary, not an entire day dump.

Examples:

• “what were we discussing yesterday?”
• “continue from where we left off”

If the message is about rules / mechanisms / why something changed

Read the relevant requirements, operating rules, or task log that documented the change.

Examples:

• “what is the startup flow now?”
• “why did we stop loading yesterday’s full memory by default?”

If the message is a new assignment

Create or update a task file before execution.

Guardrail: never delete protection without replacement

When slimming startup context, do not simply remove a rule because it is expensive.

For every removed default-loaded rule, ask:

1. What failure did this rule prevent?
2. What new mechanism now prevents that same failure?
3. How will we verify the replacement works?
4. How will we roll back if performance improves but capability drops?

If you cannot answer these, the rule should not be removed from the default path yet.

Validation after startup changes

After changing startup behavior, validate with real scenarios:

• Can the agent still identify current active work quickly?
• Can it continue a recent conversation without forcing the user to repeat context?
• Can it explain why a process changed by citing the right file?
• Has prompt size dropped meaningfully?
• Did startup speed improve without an increase in confusion or “amnesia”?

Use the checklist in references/validation-checks.md.

Files in this skill

• references/startup-patterns.md — design patterns and anti-patterns
• references/validation-checks.md — post-change checks and regression signals
• scripts/scan_active_tasks.sh — quick task scanning helper
• scripts/briefing_lint.py — checks whether a briefing file is compact and useful

When to read references

• Read references/startup-patterns.md when designing or refactoring a startup flow
• Read references/validation-checks.md after changing rules, startup file order, or memory loading behavior

Default stance

Prefer:

• briefing over full logs
• task files over memory archaeology
• recent slices over whole-day dumps
• measured validation over intuition

Avoid:

• loading all requirements up front
• loading yesterday’s full memory by default
• using long-term memory as a substitute for active task state
• assuming “shorter prompt” automatically means “better startup”