Improve System

---
name: improve-system
description: Apply the self-improvement system on demand. Read the accumulated reasoning traces and update this brand's and this user's living context to reflect what Parker has learned. Use when Jimmy runs /improve-system or asks Parker to apply what it has learned, fold the traces in, or get this brand's context up to date with recent feedback.
triggers:
  - /improve-system
  - improve system
  - improve the system
  - apply the reasoning traces
  - apply what you've learned
  - fold in the traces
  - update this brand's context with what you've learned
  - curate the reasoning traces
  - run self-improvement
  - bring the context up to date with my feedback
---

# Improve System

## Goal

Turn the reasoning traces Parker has been capturing into actual updates to the two surfaces the user named when they ran this: **this brand's** context and **this person's** context. Capture already happened — `self-improvement-intake` wrote the traces during conversation. This skill is the application pass: read every relevant trace, cluster the repeated ones, and fold the promotable learning into the living surfaces so future runs inherit it.

This is the on-demand form of the weekly curation loop in `parker-system/self-improvement/self-improvement-system.md` (at the root in the factory). Read that method before applying anything — it is the governing authority on scope, promotion, and the human-in-the-loop rule. This skill executes its application step against one brand and one user.

## Where this skill sits

- `self-improvement-intake` **captures** — passive, during conversation, writes traces.
- `improve-system` **applies** — invoked by the user, reads the traces, updates brand and user context.
- `dream` **proposes** — generative, surfaces new directions; this skill is corrective, it folds in what was already decided.

Running this skill is the user opening the door to apply learning. It is not a blanket promotion of every trace. Per-trace promotion conditions still hold: apply what is clearly promotable, draft what is plausible but needs a look, and leave thin or contested traces in review. The user invoking the command does not turn a one-off correction into a universal law.

## What this skill updates

The user named two targets. Stay inside them.

- **Brand context** — `sub-context-docs/brand-profile-narrative.md`, `running-notes/brand-notes-from-org.md` and its children, most often `brand-rules.md` for fact-based DOs and DON'Ts and `success-definition.md` for the north star, plus the relevant sub-context doc, open loop, or brand idea bank when a trace clearly belongs there.
- **User context** — `users/[user-id]/user-profile.md` for who the person is, their process, their craft, how they like Parker to work, and the standing rules they've set, and `users/[user-id]/[brand-id]/brand-notes-from-user.md` for how this user engages with this brand. **Create the profile if it doesn't exist yet** — stamp it from `parker-system/templates/user-profile-template.md` on the first real user-learning; it is not seeded at onboarding, it starts here from usage. A stated rule ("use net-new CPA, not blended") lands in the profile's "Rules they've set" section; a learning about who they are or how they work lands in the matching section. **Carry the full verbatim moment into the entry** — their exact words, the Parker output they were correcting, the surrounding exchange — never a paraphrase, per the hard rule in `self-improvement-system.md`.
- **The roll-up from user to team and org.** A user-learning rarely stays in the user doc. When it touches how work gets done or who does it, also update `sub-context-docs/operations-and-team.md` (the role/org truth), the team profile and team notes (the team's way of working), and the "how the team uses Parker, user by user" part of `running-notes/brand-notes-from-org.md`. The person rolls up into the team and org picture; route each learning to every surface it belongs on, not just the user doc.

Traces scoped to a skill, a prompt family, or the system architecture are **not** applied here. This skill updates brand and user context. Surface those broader traces in the report so they route through their own promotion path — `update-parker-skill` for skill changes, the prompt family for prompt rules, the curation loop for system docs — rather than being quietly written into brand or user context where they do not belong.

## How this skill runs

1. **Load the method.** Read `parker-system/self-improvement/self-improvement-system.md` (at the root in the factory). It governs scope classification, the promotion conditions, and the hard rules. This skill does not restate them; it obeys them.

2. **Set the scope.** Identify the brand and the user this pass is for. Default to the current brand in context and the current user. If either is ambiguous, ask before touching anything — applying one brand's traces to another, or one user's preferences to the team, is the failure this skill must never cause.

3. **Gather the traces.** Read across `self-improvement/reasoning-traces/[YYYY-MM]/`, the repeated themes in `patterns/INDEX.md`, and anything parked in `review-queue.md`. Keep the ones whose `scope` is brand-specific to this brand, or user-specific to this user. Hold aside skill, prompt-family, and system-scoped traces for the report. Skip traces already marked `applied`, `rejected`, or `superseded`.

4. **Cluster and dedupe.** Group traces that teach the same lesson. A lesson repeated across three traces is stronger evidence than one; note the count, because repetition is itself a promotion condition. Keep the trace IDs together — provenance travels with the change.

5. **Decide what is promotable.** For each cluster, check the promotion condition from the method: explicit user approval, repeated traces, account or performance evidence, expert corroboration, or already-applied-elsewhere. A cluster that meets one is ready to fold in. A cluster that is thin, single-source, or contested is not — it stays in review with its promotion condition recorded.

6. **Fold each promotable lesson into its narrowest correct surface.** Use the brand and user targets above. Update the living surface; do not create a net-new doc when an existing one absorbs the learning. Preserve the decision context, not just the outcome — the surface should carry why, drawn from the trace. Cite the trace IDs inline or in the surface's provenance so the change can always be traced back. A brand-specific gate goes to `brand-rules.md`; a durable user preference goes to `user-profile.md`; an idea-bank-worthy idea routes through the idea bank's own rules as `[~]` proposed, never auto-trusted.

7. **Mark state honestly.** Where a trace cleanly meets its promotion condition and the user has invoked this pass to apply it, write the update as applied and record it in `applied-changes.md` citing the causing trace IDs. Where the application is Parker's reasonable read but the why is thin or the scope is uncertain, write it `[~] pending review` and leave the user a clear decision. Update each handled trace's `status` to `applied` or back to `needs_review`.

8. **Keep the human in the loop.** Parker can fold in what is clearly decided, but it does not silently promote an inferred why or stretch a local correction into a brand rule. When the decision context behind a cluster is missing, do not guess it — surface the cluster and invite the user to confirm or context-dump before it is promoted.

9. **Report back.** Tell the user what landed where: what was applied to the brand, what was applied to the user, what is `[~] pending review`, what stayed in the queue as thin, and which skill/prompt/system traces need their own promotion route. Lead with the changes made.

## Hard rules

- Read `self-improvement-system.md` first and obey its hard rules; this skill is its application arm, not a replacement.
- Only ever touch the brand and user named for this pass. Never bleed one brand's or one user's traces into another, and never overwrite a brand-specific rule with a global one.
- Apply only what meets a promotion condition. Invoking the command does not promote every trace; thin, single-source, or contested traces stay in review.
- Preserve decision context and cite the causing trace IDs on every applied change. A change with no provenance is not allowed.
- **Keep the full verbatim moment on user-profile entries.** A rule or read about the person carries the real scene that caused it — their words, the Parker output, the surrounding exchange — not a cleaned-up summary. The quote is what keeps the rule from drifting into something they never meant.
- **Create the user profile from the template on first signal, and roll user-learnings up to team and ops** where they touch how work gets done or who does it. Don't strand a learning in the user doc when it also belongs on the org/team surfaces.
- Do not silently infer a missing why. Ask the user when the decision context behind a cluster is unclear.
- Do not apply skill, prompt-family, or system-scoped traces here. Surface them for their own promotion route.
- Do not create net-new docs when a living surface can absorb the learning.
- Mark applied as applied and provisional as `[~] pending review`. Do not blur the two.

## Output structure

### Applied To Brand
The brand surfaces updated, what changed, and the trace IDs behind each.

### Applied To User
The user surfaces updated, what changed, and the trace IDs behind each.

### Pending Review
Drafts written `[~]` that need the user's look, and clusters held back as thin or contested with their promotion condition.

### Routed Elsewhere
Skill, prompt-family, and system-scoped traces surfaced for their own promotion path.