update-parker-skill

Update Parker Skill (v1)

Goal

Make a correct update to Parker's context-engineering system — prompts, system docs, rubrics, knowledge docs, training corpus, skills, or brand outputs — without introducing drift, breaking cross-references, or missing downstream impact.

The skill is not for making changes that live entirely inside one file with no dependents. If the change is local to one prompt and that prompt is not referenced by anything else, just edit the prompt. The skill is for changes whose blast radius extends past the file the user pointed at, which in Parker's system is almost any rule, principle, or pattern change.

Before proposing a system update, check self-improvement/ for reasoning traces or patterns that explain why similar changes were previously accepted, rejected, rerouted, or left in review. If the current request creates a new durable lesson, create or update a reasoning trace through self-improvement-intake.

Global changes require human-in-the-loop. Always.

This is the most important rule in this skill. Global changes — anything touching the canonical system docs, rubrics, knowledge docs, templates, prompts, skills, or training corpus — require explicit human approval before any edits land. The skill always proposes the change first, waits for approval, then executes. No exceptions.

The reason: global changes have wide blast radius. A system-doc edit propagates to every prompt that loads it at runtime. A rubric change reshapes every open-loops generation across the system. A prompt edit affects every brand that runs that prompt. The cost of catching a wrong update at proposal time is one extra message in chat. The cost of catching it after propagation is undoing the change across many files and re-running affected brand outputs.

What counts as global

• Any edit to a system doc, rubric, knowledge doc, methodology doc, or template at the parker-v2/ top level (e.g., system/open-loops-system.md, creative-strategy-context/creative-strategy-fundamentals.md, creative-strategy-context/public-ad-library-analysis.md, templates/voc-design.md, templates/personas-template.md).
• Any edit to a prompt at prompts/**.
• Any edit to a skill at skills/** — including this one.
• Any new entry to the reasoning library at parker-v2/reasoning-layer-notes/.
• Any change to master index docs (parker-v2/README.md, prompt-category READMEs, training-corpus README).
• Any change to the master file structure.

What is not global (and the skill can act more autonomously on)

• Brand sub-context-doc re-runs that apply an already-approved rule change to the brand's outputs. (Re-running is propagation of an already-approved rule, not a new global change.)
• Running-notes entries for a brand session.
• Source-pulls additions for a brand.
• Brand-specific README updates that index brand-only content.
• Brand-specific persona-profile or open-loops roll-up updates that follow from already-approved methodology.

When in doubt, treat the change as global and propose.

The propose-then-execute pattern

The skill produces a structured proposal before any edits. The proposal includes:

1. Canonical doc(s) being edited — by path.
2. Current content — the relevant section quoted or summarized so the user can see what is being changed.
3. Proposed new content — the new wording or structure, complete enough that the user can give a yes/no without further questions.
4. Why — what is wrong with the current and how the proposed fix changes behavior. If a failure-mode diagnosis is part of the fix, name it.
5. Propagation scope — which dependent docs need updates, what kind (reference-paragraph edit vs full re-write), and how many files are affected.
6. Training corpus updates — which cases or reasoning entries need to change and how.
7. Brand outputs flagged for re-run — which outputs will need re-running after this change lands, with the impact named explicitly.
8. Index doc updates — which READMEs need new entries or updated entries.
9. Migration impact — every release ships its migrations/vN.md in the same change, per migrations/README.md and the Releases And Migrations rules in CLAUDE.md; the proposal decides what goes inside. Real steps when the change reshapes the brand repo itself (a renamed or moved path a brain references, a new standing file outside the copied bundle, an edit to brand-authored content, a brand-brain layout change); a one-liner no-op ("Nothing to do; record vN.") when the change is method-only or lives entirely in the copied bundle the pin bump's re-sync delivers.

The user then approves, redirects, or rejects. The skill executes only after explicit approval. If the user asks for changes to the proposal, the skill re-proposes — it does not start editing and assume the user will catch the differences.

What counts as approval

A clear yes. "Go ahead," "do it," "yes," "approved," "execute," "ship it." If the user says "looks good but..." that is not approval — the "but" is the redirect, and the skill re-proposes.

Silence is not approval. If you can't tell whether the user approved, ask.

Why this skill exists

Parker's docs are an inheritance graph, not a flat directory. A rule lives in one canonical place. Prompts reference the rule by loading the canonical doc alongside themselves at runtime. Training cases document how the rule was derived. Brand outputs are the consequence of the rule running. A change to the canonical rule has implications at every layer.

When updates happen ad-hoc, three failure modes recur:

• Drift: a rule is added to some prompts but not others, and runtime behavior diverges.
• Stale references: a knowledge doc is added but the prompts that should reference it aren't updated, so runtime model never loads it.
• Stale outputs: a rule changes but the brand outputs that were generated under the old rule are not flagged for re-run, so production state silently violates the new rule.

This skill exists to catch all three at update time.

How this skill runs

The skill runs in two phases: propose (always, for global changes) and execute (only after explicit user approval). Steps 1–5 below produce the proposal. Steps 6–10 are the execution.

Phase 1 — Propose (no edits yet)

1. Identify what kind of update this is. The propagation pattern depends on the update type. See the process index in processes/INDEX.md for the major types and which process to load. If the update doesn't match a named type, use the general-update process as a starting point.

1a. Check prior reasoning traces. Search self-improvement/ for related corrections, approvals, rejections, product rules, taste boundaries, or prompt rules. These traces are not automatically canonical, but they explain the user's prior reasoning and should shape the proposal.

2. Identify the canonical location. Every rule, principle, knowledge piece, or template has one canonical home. The canonical home is where the change goes first. See references/canonical-locations.md for the full map.

3. Identify the dependency graph. Which docs reference the canonical doc? Two kinds of dependencies matter:

   • Runtime references — docs that say "load alongside this prompt" or "see [X] for the methodology." These inherit at runtime.
   • Logical references — docs that don't formally reference the canonical doc but encode the same rule in their own language. These drift if not updated.

   Use grep -r to find both kinds across the relevant directories.

4. Decide the propagation scope. Three patterns:

   • Inherit via reference — change only the canonical doc; runtime references propagate automatically. Use when the canonical doc is loaded alongside at runtime and the prompts already reference it correctly. Lowest-effort, lowest-drift-risk option.
   • Inherit via reference + tighten prompt reference paragraphs — change the canonical doc; update the short reference paragraph each prompt carries so the new rule is invoked by name at runtime. Use when the rule needs to be explicitly named in each prompt's section to be reliably invoked.
   • Direct edit each affected file — when the inheritance pattern doesn't exist for this rule, or when the rule is encoded in each prompt's own language. Highest-effort, highest-drift-risk; use only when the inheritance pattern can't be added.

5. Write the proposal and wait. Use the structure defined under "The propose-then-execute pattern" above. The proposal must include all nine elements (canonical doc, current content, proposed content, why, propagation scope, training corpus updates, brand-output re-runs, index updates, migration impact). Then stop. Do not edit. Wait for the user to approve, redirect, or reject.

   If the user redirects, revise the proposal and present again. Do not start editing and assume the user will catch the differences.

   If the user rejects, the skill ends. No edits.

Phase 2 — Execute (only after explicit approval)

6. Make the canonical change. Edit the canonical doc first. Write it as the new source of truth.

7. Propagate per the approved scope. If inheriting via reference, verify each dependent prompt actually loads the canonical doc by name. If updating reference paragraphs, make the same edit consistently across all affected prompts.

8. Capture the reasoning per the approved scope. If the change is a new open-loops reasoning move or prior, add it to creative-strategy-context/creative-strategy-fundamentals.md. If the change reshapes how a prompt should work, add a new entry to reasoning-layer-notes/ documenting the move.

9. Update index docs per the approved scope. READMEs that list affected docs need to reflect new files, new sections, or new references. Common ones: parker-v2/README.md, prompts/brand-profile/README.md, brand README files.

10. Output the diff summary.

Content truncated.