reflect

Reflect

A skill named in bold or in backticks, or run as /<name>, is the file ../<name>/SKILL.md beside this skill's directory, and a principle named without its prefix is ../principle-<name>/SKILL.md. Read the file and follow it. Most pstack skills are user-only, so your skill tool cannot load them. Every delegate_task call follows the defaults in the Subagents section of ../poteto-mode/SKILL.md.

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

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

1. Locate the active transcript

Before fanning out, find this conversation's thread. Search this project with t3_thread_search for a distinctive phrase from the conversation's opening user prompt. Do not pass another project's projectId. That crosses workspace boundaries and reads private chats from unrelated projects.

For each candidate, read its first user message with t3_thread_read. Take the threadId whose first message is the conversation's opening user prompt. If none matches, pass a tight digest of the session instead.

2. Spawn three reviewers in parallel

One turn, three delegate_task calls, each with a title naming the lens and target from its role line below. Reviewers need MCP access to look up the tickets, chat threads, and observability traces the transcript references.

Each reviewer and the synthesizer name a role line in ~/.config/pstack/pstack-models.md. With no file or no line, the role runs on the parent model. Say so and suggest /setup-pstack. If orchestrator_capabilities does not list a configured entry, run that role on the parent model and say so. Pick each subagent's reasoning level and fast or standard speed for the job, per the Subagents section of the poteto-mode skill.

Lens	Role line	Prompt template
Judgment	reflect judgment, divergent, synthesizer	references/judgment-reviewer.md
Tooling	reflect tooling	references/tooling-reviewer.md
Divergent	reflect judgment, divergent, synthesizer	references/divergent-reviewer.md

Pass each template verbatim as the brief, substituting the thread id or digest where marked. Reviewers return findings as their task result.

3. Synthesize

One delegate_task call, title Reflect synthesizer, target from the reflect judgment, divergent, synthesizer line. It spot-verifies citations through MCP. Pass references/synthesizer.md verbatim, with each reviewer's full output inlined where marked. It returns an Accepted / Rejected / Backlog list.

4. Structural enforcement check

Move any Accepted item that a lint rule, script, metadata flag, or runtime check would enforce more reliably to Backlog. See the encode-lessons-in-structure principle skill.

5. Apply

Present the synthesizer's full Accepted / Rejected / Backlog output and wait for explicit approval before applying any Accepted edit. The user picks the subset and may redirect routings. Skill changes affect every future agent in the org. Do not auto-apply.

File each Backlog item to your team's devex or backlog tracker without waiting. Only the Accepted list waits for approval.

Never edit an installed pstack skill under ~/.agents/skills/ or ~/.claude/skills/, because npx skills update -g overwrites it. Before approval, show its destination: a copy under a new name in the project, at .agents/skills/<new-name>/ with the symlink .claude/skills/<new-name> -> ../../.agents/skills/<new-name>, since one name both global and in the project leaves Codex loading neither. After approval, copy the skill folder there, set its frontmatter name to the new name, and edit the copy. The copy no longer sits beside the other pstack skills, so rewrite each sibling reference in it, ../<name>/... and the skill-files sentence alike, to the installed sibling under ~/.agents/skills/<name>/, which both harnesses' installs resolve to. Check that every rewritten path exists before declaring the edit done. Never open a PR or push.

Follow each approved row's Routing exactly:

• Trivial existing-skill edit (a one-line bullet, a tightened sentence, a stale fact corrected): the parent does it 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.

Without skill-creator installed, follow the Authoring-a-skill playbook (../poteto-mode/playbooks/authoring-a-skill.md) wherever a routing names it.

If your environment ships a SKILL.md validator, run it on every touched skill before declaring done.

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.