_context-ack

_context-ack

Goal

Let users quickly confirm whether Iactually referenced/followedthe instructions and files in this session.

Output conventions that must be followed

1) Fixed prefix (first line of every reply)

• Uniformly start with ✨ 已启用上下文校验 .
• This prefix is used to let users determine whether this skill is in effect.

2) Honorific address (on a separate line)

• After the first line, add a separate line with an honorific address, for example:
  • 尊敬的主人：
• The honorific line must be on its own line, avoiding mixing it with the body text.

3) Reference list (at the end of every reply)

Append two lines at the end of the reply:

已读指令：<指令文件及其核心要求>
已启用技能：<技能名与简要功能>

List rules:

• Only list the instructions/skills actually read or actually relied on this time。
• Instructions read line: list the instruction file names that were read and their correspondingcore requirements or applied parts
• Enabled skills line: list the skill names used and theiractual contribution in this reply，one skill per line, in the format:
  • 已启用技能：技能名 - 技能说明
• If no files or skills were referenced this time, you must write:
  • 已读指令：无
  • 已启用技能：无

3.1) Reference verification checklist (mandatory)

• Instructions readmust come from explicit reading this time (such as read_file）。
• It is forbidden to fill in files that were "not actually read but guessed to exist".
• If no instruction files were read, you must write 已读指令：无。

3.2) Skill usage evidence collection (optional enhancement)

To enhance transparency and traceability, when listing an enabled skill, the actual usage evidence of that skill should be reflected in the reply body:

Skill name	Usage evidence	Verification method
_git-commit	There is a signature line at the end of the commit message file	Search for "🤖 This commit was made by _git-commit"
_file-output-guard	The file contains [Part X/?] section markers	View the section markers in the file content
_change-summary	The PR description contains a "Commit Summary" section (from git log --oneline）	Check the PR or PR_DESCRIPTION.local.md
_traceability-check	The commit message covers all files listed in git diff --name-only --cached All listed files	Check against the checklist
_code-health-check	The reply mentions verification results such as tests passing and compilation succeeding	View the reply content or console output
_instruction-guard	The "Instructions read" section of this reply lists the instruction files that were read	See the "Instructions read" line

Best practices：

• When listing a skill, mention at least one key step or output of that skill in the reply body
• For example: when listing _git-commit - 格式化提交说明 , the reply should mention "Conventional Commits format has been used" or "a signature line has been added"
• This allows users to quickly verify whether the skill was actually executed, rather than merely being listed in the checklist

4) Repository information prompt (at the end of every reply, on the line below "Enabled skills")

Append one line:

仓库状态：分支=<branch> | 未提交=<count_uncommitted> | 未跟踪=<count_untracked>

Filling rules:

• Branch:git rev-parse --abbrev-ref HEAD
• Uncommitted:git status --porcelain the number of tracked and changed entries in
• Untracked:git status --porcelain entries starting with ?? in

5) Output style (diff code block format)

Place the session ending information in a diff-format code block, using syntax highlighting to distinguish different types of information:

─────────────────────────────────────────────
+ ✅ 已读指令：[文件名]
- 🔧 已启用技能：技能名 A - 技能说明
- 🔧 已启用技能：技能名 B - 技能说明
! 📦 仓库状态：分支=<branch>
!   └─ 未提交：<n> (仅当>0时显示)
!   └─ 未跟踪：<m> (仅当>0时显示)
─────────────────────────────────────────────

Format description：

• Use diff syntax highlighting; each type of information has a different color:
  • + Green: read instructions
  • - Red: enabled skills
  • ! Orange: repository status
• Use └─ tree structure to show details
• Use a thinner separator line ─（U+2500）
• If the uncommitted/untracked numbers in the repository status are 0, do not show that line
• If both are 0, show only the branch information

Scope

• All conversationsandall replies。
• Only if the user specifies "no prefix/list this time" may it be temporarily ignored.

Notes

• Do not fabricate references.
• Do not list files that are only "already in context but unused".
• Keep it concise; list only the items actually used.