sync-tp-network-profile

name

sync-tp-network-profile

description

Sync newly-learned trading partner intel into the canonical Jira AOC network profile (the {PARTNER}_NETWORK_PROFILE document in project AOC). Pairs with trading-partner-playbook — after a deep dive surfaces fresh information from Confluence/Intercom/Slack/Orderful/Salesforce, this skill diffs that against what's already in the AOC profile and updates Jira with the additions, preserving the existing structure and using the AOC confidence-level scheme (VERIFIED / HIGH / MEDIUM / INFERRED). Use when a user says 'update the AOC profile for [partner]', 'push our new [partner] findings to Jira', 'sync the [partner] playbook with AOC-XXX', 'we just learned something new about [partner] — update the network', or 'after the playbook run, push deltas to Jira'. Always runs in propose-then-confirm mode: surface the proposed additions for human review before applying. Never overwrites existing AOC content; only adds, with source attribution and refreshed Last-Updated stamp.

Sync TP Network Profile

What this skill does

After a trading-partner deep dive (see trading-partner-playbook), this skill compares the freshly-synthesized intel against the existing AOC project network profile for that partner in Jira, and updates the Jira issue with only the genuinely new information — preserving the existing structure and confidence-tagging scheme.

The AOC project (AgentOrgContext) holds the canonical, organization-wide source of truth for what Orderful knows about each trading partner. Profiles follow the naming convention {PARTNER}_NETWORK_PROFILE (e.g. KEHE_DISTRIBUTORS_NETWORK_PROFILE = AOC-230). Keeping AOC fresh is how institutional knowledge compounds; this skill is the propagation step.

When this fires

After a trading-partner-playbook run that surfaced new intel, OR any time a user says we've learned something new about a trading partner that should be documented. Triggers:

• "Update the AOC profile for [partner]"
• "Push our new [partner] findings to Jira"
• "Sync the [partner] playbook with AOC-XXX"
• "We just learned something new about [partner] — update the network"
• "After the playbook run, push deltas to Jira"

Don't fire for:

• The partner has no existing AOC profile and no playbook to seed one from — point the user at trading-partner-playbook first.
• The user just wants to read the AOC profile (use getJiraIssue directly).
• One-off facts about a partner that don't fit the network-profile scope (e.g. "this specific customer's KeHE vendor number is X" — that's customer data, not network data).

The flow

1. Resolve the partner name → find the AOC issue
   (search project=AOC for "{partner} NETWORK_PROFILE" or "{partner} PROFILE")
   ↓
2. Read current AOC profile content in markdown format
   ↓
3. Read the freshly-synthesized playbook (from outputs/<partner>-trading-partner-playbook.md
   or from the most recent playbook in the conversation)
   ↓
4. Diff: identify items in the playbook that are absent from the AOC profile.
   Group them by AOC section (Identity, Setup, Transactions, Gotchas, etc.)
   ↓
5. Tag each new item with a confidence level (VERIFIED / HIGH / MEDIUM / INFERRED)
   based on the source it came from
   ↓
6. Surface the proposed additions to the user for review
   (always — never apply silently)
   ↓
7. On confirmation, update the Jira issue:
   - Append to the existing description in the right section
   - Refresh the "Last Updated" stamp
   - Append new sources to the source list
   ↓
8. Confirm to the user what was added, with a link to the updated Jira issue.

Inputs to gather

1. Partner name — required. Resolve to the AOC issue key by searching project = AOC AND summary ~ "{partner} NETWORK_PROFILE". If no exact match, search loosely (e.g., summary ~ "{partner}"). If multiple candidates, ask the user which one is canonical.

2. Source of the new intel — usually the most recent playbook in outputs/. If the user just gave you fresh facts in conversation (no playbook artifact), use the conversation as the source. Don't run a new playbook just to sync — that's trading-partner-playbook's job.

3. Dry-run vs. apply — default to dry-run (surface proposed additions for review). If the user says "just do it" / "apply directly" / "no need to review," skip the review step and write through.

Confidence-level rubric

The AOC profiles use this exact scheme. Match it precisely when tagging new items.

Tag	When to use	Examples
VERIFIED	From Orderful API, Orderful product/platform, or directly confirmed by an Orderful team member in Slack/Intercom	"KeHE org ID is 5017" (from get_account_context), "Auto-accept flow verified all PASS" (from Fantastic Fungi onboarding ticket note by Michael Wilson's bot)
HIGH	From Orderful docs (Confluence, Help Center), Intercom tickets with identifiable customer context, Slack with timestamp + author	"Onboarding forms expire after several months" (Haig's ticket, May 14), "Channel name pattern: 'To Kehe via SPS'" (Fantastic Fungi onboarding note)
MEDIUM	From public third-party sources (partner corporate site, SupplierWiki, GS1 docs, KeHE compliance program docs from KeHE itself)	"KeHE EDI Compliance Program effective July 1, 2026" (KeHE announcement forwarded by Dr. Squatch)
INFERRED	Synthesized from multiple partial sources or a single vendor's experience generalized	"Most KeHE relationships use 6-doc set, not 7" (inferred from comparing Fantastic Fungi and Reser's setups)

Rules:

• Never downgrade existing items (if AOC marks something HIGH and your new evidence is INFERRED, leave the existing HIGH alone — don't overwrite).
• Never upgrade without provenance (if you're upgrading something from INFERRED to VERIFIED, cite the verifying source).
• When uncertain, downgrade to INFERRED rather than over-claim.

Update format

When appending to a Jira AOC section, format new items like the existing ones in that section. Reference real tickets, dates, and sources. Examples:

Adding to a Gotchas section:

* **Onboarding forms expire**: If a trade request was created and never moved within ~3 months, the customer must resubmit a new onboarding form before testing can start. Saw this on Haig's Delicacies (May 14, 2026) — trade request from Jan 2026 had to be re-formed. `HIGH`

Adding to a Transactions section:

* **6-doc set variant**: Per recent Fantastic Fungi onboarding (May 13, 2026, partnership 154197), KeHE-via-SPS relationships configure six transactions in this shape: 850 in, 860 in, 812 in, 855 out, 856 out, 810 out. The 875/880 grocery flow (already documented) is an alternative — verify which applies per customer. `HIGH`

Adding to a Setup section:

* **Auto-accept verification flow** (`VERIFIED`): SPS-mediated KeHE trade requests auto-accept after form submission. Michael Wilson's verification bot runs ALL-PASS checks on partner-side relationship config matching the form, then binds the "To Kehe via SPS" channel to both live and test streams. Customer-side relationships then need contractor binding (e.g. `john.alley.cr` from Concurrent) during testing setup.

Updating the Last-Updated stamp + sources

Always:

1. Update the > **Last Updated:** YYYY-MM-DD line at the top of the profile to today's date.
2. Append your new source(s) to the existing **Sources:** list — don't replace, add.
3. Don't touch the Confidence Levels legend table — it's shared across all profiles.

How to apply the update

Two paths:

Path A — Edit Jira description directly (default for substantive additions):

Use editJiraIssue with the updated description (markdown). Preserve everything that existed before; only add. Confirm with the user before writing.

Path B — Post a comment instead (for minor or speculative additions):

Use addCommentToJiraIssue with a comment block describing the proposed addition. This is appropriate when:

• The new info is INFERRED-quality and the user wants to flag it but not commit it
• The AOC profile is in a heavy review state and edits would be disruptive
• The user explicitly says "comment first, edit later"

Default to Path A unless one of those conditions applies.

Anti-patterns to avoid

• Don't blow away existing content. This is propagation, not replacement. If you're tempted to rewrite a whole section, stop — that means the underlying playbook contradicts something in AOC, and humans need to reconcile that, not the skill.
• Don't add items without provenance. Every addition needs a source citation. "Reser's via Columbus Global, April 30 2026, conversation 215474134494479" is acceptable. "Some customers reported issues" is not.
• Don't add what's already there in different words. Read the existing AOC profile carefully before proposing additions. If it says "KeHE routes through SPS Commerce" and your playbook says the same in different words, that's not new — skip it.
• Don't propose updates the playbook hasn't actually justified. Your job is to propagate confirmed playbook findings, not invent. If the playbook says "INFERRED: probably X," don't mark it HIGH in Jira.
• Don't run silently. Even in apply-mode, summarize what changed to the user after writing. They need an audit trail of what landed in the canonical doc.
• Don't create a new AOC issue without explicit user permission. If no AOC profile exists for this partner, ask the user before creating one. Network profiles are owned by humans; the skill drafts but doesn't unilaterally publish.

Final sanity check before writing to Jira

• Have I read the existing AOC profile end-to-end? (Required — never skip this step.)
• Are the proposed additions genuinely absent from the existing profile?
• Does every addition have a source citation and a confidence tag?
• Does the addition format match the existing section's format (bullet style, indentation, marker placement)?
• Have I shown the user the proposed additions and gotten confirmation? (Default to yes — only skip if user explicitly waived review.)
• Will the resulting Jira description still parse cleanly as markdown? (Check for orphan list markers, broken tables, missing newlines.)

Pairing with trading-partner-playbook

Recommended user flow:

"deep dive on [partner]"
  → trading-partner-playbook produces outputs/<partner>-trading-partner-playbook.md

"update AOC for [partner]"
  → this skill diffs playbook vs. AOC-XXX and proposes additions

User reviews → "apply"
  → Jira issue updated with new items, tagged, sourced, Last-Updated bumped

Mention this pairing in the skill's first output so the user knows they have a continuous loop available, not a one-shot.