ams-audit-memory

Category: Testing & Security | Uploader: LastEld | Downloads: 0 | Version: v1.0（Latest）

Operate AMS audit, memory, and proof flows. Use when the user asks for audit-proof execution, verifiable action trails, prompt-ready memory bundles, retrieval, or proof diagnostics.

Changelog: Source: GitHub https://github.com/LastEld/AMS

Directory Structure

Current level: .agents/skills/ams-audit-memory/

📁 agents/
- 📄 openai.yaml 256 B
📁 references/
- 📄 tools.md 1.8 KB
- 📄 workflows.md 1.8 KB
📄 SKILL.md 4.3 KB

SKILL.md

---
name: ams-audit-memory
description: Operate AMS audit, memory, and proof flows. Use when the user asks for audit-proof execution, verifiable action trails, prompt-ready memory bundles, retrieval, or proof diagnostics.
---

# AMS Audit Memory

Use this skill for evidence, memory, and proof workflows in the production AMS repo rooted at `E:/AMS`.

## Operating Baseline

- AMS is the source of truth.
- Default active project is `ams-core` unless the user explicitly scopes another retained project.
- Codex owns final PM memory consolidation.
- Claude execution facts are valid only after they are written back into AMS with task, branch, worktree, and proof context.

## Quick Start

Run this bootstrap sequence first:

1. `unified_init`
2. `unified_vitals`
3. `unified_help`
4. `context_create` or `context_ensure` if the work is roadmap-scoped

Trust runtime discovery over repo assumptions and treat `archive/` as reference only.

## Choose the Path

- Need immutable context state:
  - Use `context_create` or `context_ensure`
  - Use `context_latest`, `context_history`, `context_get`, `context_diff`, and `context_verify` for inspection

- Need an audit-proof work session:
  - Use `audit_session_start`
  - Use work tools
  - Use `audit_session_status`, `audit_get_actions`, `audit_session_stats`
  - Use `audit_verify_chain` before final proof output

- Need reasoning trace:
  - Use `thought_plan`, `thought_record`, or `thought_decide`
  - Use `thought_tree`, `thought_for_action`, or `thought_reasoning_trail` for review
  - Use `thought_verify` when chain integrity matters

- Need verifiable proof artifacts:
  - Use `merkle_finalize`
  - Use `merkle_root`, `merkle_attest`, `merkle_proof`, `merkle_verify`, or `merkle_audit`

- Need prompt-ready memory or retrieval:
  - Use `memory_pack` before `memory_bundle` when fresh audit or thought data must be visible
  - Use `memory_get`, `memory_map`, `memory_verify`, `memory_stats`
  - Use `memory_prioritize`, `memory_cross_session`, `memory_semantic_search`, `memory_smart_store`, and `memory_tier_migrate` when shaping or inspecting the longer-term memory surface
  - Use `analysis_rag_index` before `analysis_rag_search` when the retrieval corpus is stale or missing

## Operating Rules

1. Start from `context_create` or `context_ensure` before `audit_session_start` when the work is tied to roadmap state.
2. Carry forward `context_id`, `session_id`, and `action_id` instead of guessing them later.
3. Do not stop at `audit_verify_chain` when the user needs proof. Finish with `merkle_finalize` and the relevant Merkle output.
4. Use `memory_pack` before `memory_bundle` when recent actions or thoughts should influence the bundle.
5. Use `analysis_rag_index` before `analysis_rag_search` only when the corpus is stale. Do not rebuild reflexively.
6. Use `memory_gc` and `rag_gc` in dry-run mode until cleanup is explicitly desired.
7. For Claude completion claims, ensure the associated `thought_record` includes branch, worktree path, commit SHA, verification, and blockers.
8. Treat `memory_pack` as a PM review step, not as an automatic substitute for task verification.

## Sub-Agent Audit Trail

When sub-agents are spawned for execution (via Task tool), ensure audit trail captures:

1. **Before execution**: `thought_plan` with agent assignments
2. **During execution**: Sub-agent outputs logged to files
3. **After execution**: `thought_record` with:
   - Agent IDs and pool names
   - Files modified by each agent
   - Integration points between agents
   - Completion status

### Recording Sub-Agent Work

```
thought_plan { session_id, plan: "Spawn 3 agents for Phase 2..." }
  → Task {agent-1} + Task {agent-2} + Task {agent-3}
thought_record { 
  session_id, 
  content: "agent-xxx completed BidirectionalSyncEngine.ts..."
}
audit_verify_chain → merkle_finalize
```

## Typical Requests

- "Start an audit-proof session for this roadmap and return the final root."
- "Show me the action chain and verify whether the audit trail is intact."
- "Record the reasoning trail, then produce Merkle proof material."
- "Refresh memory for this session and build a prompt bundle with RAG evidence."
- "Investigate why the memory bundle is missing recent actions."

## Reference Loading

- Read `references/workflows.md` for deterministic sequences.
- Read `references/tools.md` for tool selection and failure handling.

Comments 0

Latest | Hot

Please login before commenting.

No comments yet. Be the first one!

ams-audit-memory

Directory Structure

SKILL.md

Report

Notice