added more commands.

This commit is contained in:
lsamc 2026-01-22 20:47:53 +08:00
parent 085097d19f
commit 88d3f8cdc5
3 changed files with 315 additions and 0 deletions

127
handoff.md Normal file
View File

@ -0,0 +1,127 @@
---
description: Generate an objective work handoff document (TRANSFER.md) so a new agent or fresh context can continue the task without inheriting subjective reasoning or strategy.
allowed-tools:
[
Bash(pwd),
Bash(ls:*),
Bash(find:*),
Bash(git status:*),
Bash(git diff:*),
Bash(git diff --cached:*),
Bash(cat:*),
Bash(date)
]
---
# /handoff — context transfer (objective only)
You are preparing a **context handoff** for a new agent or fresh session.
This command is for **state transfer only**, not reasoning transfer.
## Hard rules (STRICT)
- Be objective and factual.
- Do NOT include reasoning, decision rationale, or strategy.
- Do NOT tell the next agent what to do.
- Do NOT evaluate code quality or suggest improvements.
- Do NOT include secrets, tokens, passwords, or private keys.
- If something is uncertain, label it explicitly as *potential* or *suspected*.
---
## Output requirements
- Write the **full handoff content** to a file named `TRANSFER.md` in the project root.
- In chat, provide **only a short summary** of what was written (high-level bullets).
- Do NOT duplicate the full content in chat.
---
## TRANSFER.md structure (must follow)
### 1. Overall Goal
Describe the current task goal in neutral terms.
What the work is about, without justification or opinion.
---
### 2. Completed Work (Objective)
List completed actions or changes as facts:
- Files created / modified
- Features added or removed
- Refactors performed
No evaluation, no “why”.
---
### 3. Work in Progress
Describe what is currently being worked on:
- Active files
- Active modules
- Partial implementations
---
### 4. Potential Blockers / Open Issues
List **possible** blockers or unresolved items.
- Clearly mark them as *potential* or *suspected*
- Avoid conclusions or recommendations
Example phrasing:
- “Potential issue: …”
- “Suspected blocker: …”
---
### 5. Code & File Locations
Document where relevant code and materials are located:
- Primary working directory
- Key source files
- Related helper files
- Documentation files (if any)
Use explicit paths.
---
### 6. How to Run / Test / Reproduce
Document how to interact with the project:
- How to run the program
- How to run tests
- Important commands
- Entry points or scripts
Keep this factual and reproducible.
---
### 7. Environment, Config, and Logs
Document environment-related facts:
- Configuration files (paths + purpose)
- Required environment variable names (names only, no values)
- Log file locations
- What the logs are used for
---
## Execution steps
1) Gather the necessary information using allowed tools.
2) Generate `TRANSFER.md` following the exact structure above.
3) After writing the file, return to chat and provide:
- A brief summary (510 bullets max)
- The path to `TRANSFER.md`

103
intake.md Normal file
View File

@ -0,0 +1,103 @@
---
description: Intake an existing TRANSFER.md and build a clean, objective understanding of the current work state. Supports optional arguments to bias focus during intake. No planning or recommendations.
allowed-tools:
[
Bash(cat:*),
Bash(ls:*),
Bash(pwd)
]
---
# /intake — context intake (objective, no planning)
You are performing a **context intake** from a previous handoff.
Your role is to understand the current state, not to decide what to do next.
---
## Hard rules (STRICT)
- Read and interpret existing information only.
- Do NOT introduce new goals, plans, or strategies.
- Do NOT suggest next steps or improvements.
- Do NOT evaluate the quality of past decisions.
- Treat all “blockers” as *potential*, not confirmed.
- If information is missing, state that it is missing — do not infer.
---
## Optional focus input
The user may provide optional arguments after the command.
- Treat `$ARGUMENTS` as **intake focus hints only**.
- Use them to prioritize attention and structure in the summary.
- Do NOT turn them into tasks or recommendations.
User-provided intake focus (if any):
$ARGUMENTS
---
## Intake source
1) Locate and read `TRANSFER.md` from the project root.
2) If the file does not exist, clearly state that intake cannot proceed.
---
## Output requirements
- Do NOT modify any files.
- Do NOT generate plans or TODOs.
- Produce a **structured intake summary in chat** only.
---
## Intake summary structure (must follow)
### 1. Current Overall Goal
Restate the goal exactly as documented.
---
### 2. Current State Snapshot
Summarize:
- what is completed
- what is in progress
- what is not addressed yet (if stated)
---
### 3. Active Code & File Locations
List relevant paths and files as documented.
---
### 4. Environment, Config, and Logs
Summarize configuration files, environment variable names, and log locations.
---
### 5. Potential Blockers (as documented)
List potential or suspected blockers exactly as recorded.
---
### 6. Noted Gaps or Unknowns
Explicitly list:
- missing information
- unclear areas
- references to external systems not fully described
(No interpretation, no recommendations.)
---
## Final step
End the response with:
> “Context intake complete. Awaiting further instruction.”

85
ro-verify.md Normal file
View File

@ -0,0 +1,85 @@
---
description: Read-only verification for a given TASK. Must not modify local/remote code or environment. Temporary files in /tmp are allowed only if strictly necessary.
allowed-tools:
[
Bash(pwd),
Bash(ls:*),
Bash(find:*),
Bash(cat:*),
Bash(grep:*),
Bash(rg:*),
Bash(sed:*),
Bash(awk:*),
Bash(head:*),
Bash(tail:*),
Bash(wc:*),
Bash(diff:*),
Bash(git status:*),
Bash(git diff:*),
Bash(git diff --cached:*),
Bash(git log:*),
Bash(git rev-parse:*),
Bash(git show:*),
Bash(mktemp:*)
]
---
# /ro-verify — read-only verification
You are a **read-only verifier**. The user will provide a TASK via command arguments.
TASK:
$ARGUMENTS
## Hard rules (STRICT)
- You MUST NOT modify anything in the environment:
- No editing/creating files in the project workspace.
- No changing git state (no add/commit/checkout/reset/merge/rebase/clean).
- No installing dependencies, changing configs, starting services, or altering remote machines.
- You may only run **read-only inspection commands**.
- Exception: You MAY create temporary files under `/tmp` **only if strictly necessary** for the verification.
- If you do, explicitly list the temp paths you created.
- Do not write anywhere outside `/tmp`.
## If read-only is insufficient
If completing TASK requires any environment change (including creating scripts/files outside `/tmp`, or changing code/config):
- Clearly explain why it is required.
- STOP the verification immediately.
- Do not attempt a workaround that changes the environment.
---
## Verification procedure
1) Restate the TASK in one sentence (verbatim meaning, no added goals).
2) Identify what evidence is needed to verify it (files, commands, logs, outputs).
3) Collect evidence using allowed tools (read-only).
4) Produce a verification report.
---
## Output format (must follow)
### 1) TASK
(One sentence)
### 2) Evidence collected
- Commands run (exact)
- Files inspected (paths)
- Relevant excerpts (short)
### 3) Verification result
Choose exactly one:
- VERIFIED
- NOT VERIFIED
- INCONCLUSIVE
### 4) Notes (objective only)
- Any uncertainty must be stated as uncertainty.
- If potential blockers exist, label them as *potential*.
### 5) /tmp usage (if any)
- List temp files created under /tmp and their purpose.