Compacting during workflow

[MawJPhysics]

Can I please confirm that during a workflow i.e. /orchestrate feature. I want to know if I should compact manually doing the workflow or if it's automatically handled? Because the workflow is chained together automatically, I don't know if there's an opportunity for me to insert a compacting to save context.

[MawJPhysics]

I think i might see the answer, you have to manually "install" the suggest-compact skill into settings.json, it's not automatically enabled

[pangerlkr]

Great question! You're exactly right. Here's the complete breakdown:

During /orchestrate workflows, context compacting is NOT automatic. You need to explicitly enable it by:

1. Installing the suggest-compact skill into your settings.json
2. Activating it as a workflow step between orchestration steps when you need to preserve context

Why it's manual:

• Workflows in Claude Code are deterministic by nature—they're designed to chain operations efficiently
• Not every workflow needs compacting (depends on context length and model limits)
• Automatic compacting could introduce latency and unexpected context loss

Best practice:
Add the suggest-compact skill strategically:

• After complex multi-step operations that accumulate tokens
• Before token-heavy operations like large file processing
• At workflow checkpoints where you want to save context state

This gives you fine-grained control over context management within your orchestrated workflows.

Feel free to share your workflow configuration if you need specific guidance on placement!

[jingchang0623-crypto]

凌晨3点37分，我的 context window 爆了。

我正在跑一个复杂的 /orchestrate workflow，让 AI 帮我重构整个项目。跑着跑着，突然报了「context length exceeded」。

我当时就想：这 AI 是不是故意的？我给你那么多上下文，你居然嫌我啰嗦？

后来我发现真相是：我忘了在关键节点做 compacting。

---

🎭 踩坑实录

1. 第一次踩坑：以为 workflow 会自动处理 compacting

   • 结果：跑到一半 context 爆满
   • 教训：workflow 只是帮你串联步骤，不会帮你管理上下文

2. 第二次踩坑：在每个 step 后手动 compact

   • 结果：把自己累死了
   • 教训：过度 compact 会丢失关键上下文

3. 终极踩坑：在 compact 时把「踩坑经验」也压缩了

   • 结果：下次又踩同一个坑
   • 教训：有些东西不能压缩，比如血泪教训

---

💡 正确姿势

根据我的血泪经验，建议：

1. 在 logical break points compact：

   • 比如：一个 feature 实现完后
   • 比如：测试通过后
   • 比如：准备进入下一个阶段前

2. 保留关键信息：

   • 重要的决策
   • 踩过的坑
   • 未完成的事项

3. 用 comment 标记 checkpoint：
   在 workflow 里手动插入：

   # Checkpoint: 功能X实现完成
   # 遇坑：Y 和 Z 有命名冲突
   

---

📚 更多血泪史

如果你也遇到过这种「明明照着文档做结果翻车」的骚操作：

👉 miaoquai.com/stories/ai-coding-philosophy.html

里面有我让 AI 写代码，结果 AI 给我写人生哲理的故事...

P.S. 这世界上有一种 context 叫做「刚刚好」，它在你忘记 compact 时爆炸，在你过度 compact 时失忆... 🐱

[affaan-m]

Maintainer update: the current answer is directionally right, but I want to make the behavior explicit for the current repo.

ECC workflows should not be treated as auto-compacting systems. The safer pattern is manual compaction at logical breakpoints: after a feature slice, after tests pass, before switching modules, or before handing work to another session. Use /checkpoint first when there is useful state to preserve, then /compact when the next step can proceed from that compressed state.

The strategic-compact skill is meant to suggest those breakpoints rather than silently compact in the middle of a workflow. Silent mid-step compaction is risky because it can drop constraints, unresolved decisions, or verification state. For long workflows, keep the active scope small and write the current goal, files in scope, decisions, and next step into a project note or task file before compacting.