follow-up
Check that prior work actually held — verify the claim landed, the consumer sees it, and nothing regressed.
- License 许可
- Apache-2.0
- 所属仓库
- usurobor/cnos
- 最近更新
- 2026-11-07
- Stars
- ★ 9
- Forks
- 0
01 前言 Front Matter
- name
- follow-up
- scope
- task-local
- triggers
- [ "follow up", "check", "verify", "confirm", "track" ]
- description
- Check that prior work actually held — verify the claim landed, the consumer sees it, and nothing regressed.
- governing_question
- How do we close the loop on prior work without leaving silent regressions or unverified claims?
02 资源文件 6
- 参考文档CHANGELOG.md41 B
- 许可证LICENSE1.0 KB
- 许可证LICENSE.md1.0 KB
- 参考文档references/authentication.md3.3 KB
- 参考文档SOURCE.md169 B
- 参考文档TRUST.auto.yaml2.2 KB
03 SKILL.md 正文
Follow-Up Skill
Purpose
Ensure Eng doesn't go dark. If no update for 1 hour on active work, ping for status.
Trigger
On heartbeat, check:
- Is there active work assigned to Eng?
- When was last update (commit, inbox message, or thread update)?
- If >1 hour since last update → ping Eng
How to Check
# Check Eng's last commit
cd <eng-hub-clone> && git fetch origin && git log -1 --format="%cr" origin/main
# Check Eng's inbox for responses
ls -lt <your-hub>/threads/inbox/ | head -5
# Check Eng's daily thread timestamp
stat <eng-hub-clone>/threads/daily/$(date +%Y%m%d).md
Ping Template
Write to threads/outbox/eng-status-check.md:
# Status Check
**To:** [Eng name]
**Re:** [Active work item]
No update in >1 hour. Status?
- Blocked?
- In progress?
- Need anything?
Then push:
cd <your-hub> && git add -A && git commit -m "outbox: status check to Eng" && git push
Escalation
Escalate to human immediately when:
- Eng is blocked on P0/P1 and not responding
- Work is stalled >1 hour with no update
- Multiple pings ignored
Don't wait for 2+ hours on blockers. Human attention is cheaper than stalled work.
How to escalate:
- State the blocker clearly
- State what you've tried (pings sent, inbox checked)
- Ask human to intervene
Anti-Patterns
| Smell | Fix |
|---|---|
| Pinging every 10 minutes | 1 hour minimum |
| Pinging when no active work | Only ping if work is assigned |
| Assuming blocked without asking | Ask first |
04 同仓库更多 Skills
issues/triage
Issue triage doctrine pointer. Use when classifying a new issue, deciding dispatch eligibility, or deciding whether to close/supersede/defer.
issues/taxonomy
Issue label taxonomy pointer. Use when classifying an issue's kind/area/priority/effort/status/protocol/dispatch labels, or when the board needs to interpret them.
issues/map
Issue-board (Issue Pivot) generation domain. Use when reasoning about `cn issues map`'s fetch, taxonomy-parse, effort-computation, and render pipeline, or about the board's JSON/HTML output contract.
issues
cnos.issues package entrypoint. Use when reasoning about issue taxonomy, the Issue Pivot / issue-board (`cn issues map`), the read-only CDS issue-state evaluator (`cn issues fsm evaluate`), or the current command-dispatch disposition of issue tooling.
receipt-stream
Cross-cycle receipt-stream doctrine for protocol-iteration. Use when γ closes a cycle and writes the per-cycle iteration artifact (`cdd-iteration.md`), when γ updates the cross-cycle aggregator at `.cdd/iterations/INDEX.md`, when ε reads the receipt stream across cycles to surface protocol-gap patterns, when a finding's disposition lands a cross-repo patch and the cross-repo trace bundle attaches, or when a courtesy empty-findings stub is written for a `protocol_gap_count == 0` cycle.
mid-flight
Mid-flight γ→in-flight-α rescue channel. Use when γ needs to change a load-bearing fact (pinned axis, scope, AC, blocker) after α has begun coding, when γ edits the cycle's GitHub issue body mid-cycle, or when a spec change lands on origin/main while α/β polling sessions are in-flight.