Agent-Skills.md

Agent Skills: Reflect

Spawn three parallel review subagents over the active transcript, surface learnings, and route each to a concrete edit on an existing skill. Use when the user says reflect.

UncategorizedID: pproenca/dot-claude/reflect

Repository

pproenca/dot-claude
pproenca
1

Install this agent skill to your local

pnpm dlx add-skill https://github.com/pproenca/dot-claude/tree/HEAD/plugins/pstack/skills/reflect

Skill Files

Browse the full folder contents for reflect.

Download Skill

Loading file tree…

plugins/pstack/skills/reflect/SKILL.md

Skill Metadata

Name
reflect
Description
Spawn three parallel review subagents over the active transcript, surface learnings, and route each to a concrete edit on an existing skill. Use when the user says reflect.

Reflect

Mine the current conversation for durable learnings, then route them into skill edits.

When to invoke

  • The user said "reflect" or "/reflect".
  • A complex task (5+ tool calls) just landed cleanly and the recipe is worth keeping.
  • The agent hit dead ends, found the working path, and the path generalizes.
  • The user corrected the agent's approach mid-task.
  • A non-trivial workflow emerged that isn't captured anywhere.

Skip when the conversation is trivial, off-topic, or already covered by an existing skill the parent followed correctly. One-offs are not learnings.

Process

1. Locate the active transcript

The parent finds its own transcript file before fanning out. Transcripts live at ~/.claude/projects/<slug>/<session-uuid>.jsonl, where <slug> is the workspace's absolute path with every "/" turned into "-" (so /Users/you/proj becomes -Users-you-proj). The layout is flat: one .jsonl per session, one JSON object per line, one line per message. Derive the slug from the current working directory and read only that directory. Never glob across ~/.claude/projects/*/; that crosses workspace boundaries and reads private chats from unrelated projects.

slug="$(pwd | tr '/' '-')"
ls -t "$HOME/.claude/projects/$slug"/*.jsonl 2>/dev/null | head -10

Order by real modification time, never by UUID name. The newest entry is usually the active session; confirm it by grepping for a phrase you know is in this conversation before you fan out on it.

For each candidate, read the first JSONL line and check that message.content[0].text contains the conversation's opening user prompt. Take the matching path. If no path resolves, write a tight digest of the session and pass that instead.

2. Spawn three reviewers in parallel

One message, three Agent calls, subagent_type: general-purpose, explicit model: on each, agent mode (read-only posture stated in the prompt). Reviewers need MCP access for context lookups (tickets, chat threads, observability traces referenced in the transcript); readonly strips MCPs. The prompt forbids file writes; the parent applies edits.

| Lens | model | Prompt template | |---|---|---| | Judgment | your configured reflect-judgment model (default fable[max]) | references/judgment-reviewer.md | | Tooling | your configured reflect-tooling model (default opus[high]) | references/tooling-reviewer.md | | Divergent | your configured reflect-judgment model (default fable[max]) | references/divergent-reviewer.md |

Pass each template verbatim, substituting the transcript path or digest where marked. Reviewers return findings in the Agent response body.

3. Synthesize

One Agent call, subagent_type: general-purpose, using your configured reflect-judgment model (default fable[max]), agent mode (read-only posture stated in the prompt). The synthesizer's quality check includes spot-verifying citations, which can require MCP access; readonly strips MCPs. Use references/synthesizer.md verbatim, with each reviewer's full output inlined where marked. The synthesizer returns a structured Accepted / Rejected / Backlog list.

4. Structural enforcement check

Sanity-check the synthesizer's Accepted list. For any item that would be enforced more reliably by a lint rule, script, metadata flag, or runtime check, move it from Accepted to Backlog. The synthesizer already applies this criterion; this is a final pass before edits land. See the encode-lessons-in-structure principle skill.

5. Apply

Before applying any Accepted edit, present the synthesizer's full Accepted/Rejected/Backlog output to the user and wait for explicit approval. The user picks which subset to apply and may redirect routings. Skill changes affect every future agent in the org; do not auto-apply.

Backlog items file to whatever devex / backlog tracker your team uses automatically. Those are tracker submissions, not skill edits. Only the Accepted list waits for approval.

For each approved Accepted item, follow the Routing field exactly:

  • Trivial existing-skill edit (a one-line bullet, a tightened sentence, a stale fact corrected): parent does directly.
  • Substantive existing-skill edit (a new section, a new pattern table, more than ~10 lines): hand to the skill-creator skill and run its draft / test / iterate loop.
  • tune description: <skill path> (the skill exists but didn't trigger when it should have): hand to skill-creator and run its description-optimization loop.
  • new skill via skill-creator: <kebab-name>: hand creation to skill-creator. Do not invent the shape ad hoc.

If your environment ships a SKILL.md validator, run it on every touched skill before declaring done. Skip this step if it doesn't.

6. Summarize for the user

Short list, no preamble:

  • Edits applied: <skill path>. What changed, one line each.
  • New skills created: <skill path>. One line each (rare).
  • Backlog filed to the devex tracker: <issue title> (<tags>). One line each.
  • Dropped: one line per rejected finding + reason from the synthesizer.