@tangle-network/starter-foundry 0.7.2 → 0.13.0

package/registry/families/agent-runtime-doctor-ts/files/methodology/medical-reference.md

@@ -0,0 +1,42 @@
+# Medical Reference Template
+
+## Purpose
+Provide a concise, accurate, and well-sourced overview of a medical condition, term, or topic.
+
+## Structure
+
+### 1. Definition
+- Clear, plain-language definition of the term or condition.
+- Include common synonyms or related terms.
+
+### 2. Key Facts
+- Bullet list of essential facts: prevalence, risk factors, typical onset, etc.
+- Cite sources (e.g., CDC, WHO, NIH, peer-reviewed journals).
+
+### 3. Signs and Symptoms
+- List common symptoms in plain language.
+- Note when symptoms warrant medical attention.
+
+### 4. Causes and Risk Factors
+- Explain known causes and contributing factors.
+- Distinguish between established science and hypotheses.
+
+### 5. Diagnosis
+- Describe how healthcare providers typically diagnose the condition.
+- Emphasize that only a qualified professional can diagnose.
+
+### 6. Treatment and Management
+- Outline standard treatment approaches (medications, therapies, lifestyle changes).
+- Do not prescribe; state that treatment plans are individualized.
+
+### 7. Prevention
+- Evidence-based prevention strategies, if applicable.
+
+### 8. When to See a Doctor
+- Clear guidance on symptoms or situations that warrant professional evaluation.
+
+### 9. Sources
+- List all sources cited, with links where possible.
+
+## Disclaimer
+Always include: "This information is for educational purposes only and is not a substitute for professional medical advice, diagnosis, or treatment. Always seek the advice of your physician or other qualified health provider with any questions you may have regarding a medical condition."

package/registry/families/agent-runtime-doctor-ts/files/methodology/symptom-explainer.md

@@ -0,0 +1,34 @@
+# Symptom Explainer Template
+
+## Purpose
+Help users understand a specific symptom — what it is, common causes, and when to seek medical attention.
+
+## Structure
+
+### 1. Symptom Description
+- Define the symptom in plain language.
+- Describe what it feels like, where it occurs, and common variations.
+
+### 2. Common Causes
+- List possible causes, from benign to serious.
+- Emphasize that this list is not exhaustive and that only a doctor can determine the cause.
+
+### 3. Associated Symptoms
+- Note symptoms that often accompany this symptom.
+
+### 4. Home Care and Self-Management
+- Suggest general self-care measures for mild cases (e.g., rest, hydration, OTC medications with caution).
+- Include a disclaimer that these are not substitutes for medical advice.
+
+### 5. Red Flags (When to See a Doctor)
+- List symptoms or scenarios that require immediate medical attention.
+- Use bold for emergency signs (e.g., **chest pain**, **difficulty breathing**).
+
+### 6. Questions to Ask Your Doctor
+- Provide a list of questions the user can bring to their healthcare provider.
+
+### 7. Sources
+- Cite reputable sources.
+
+## Disclaimer
+Always include: "This information is for educational purposes only and is not a substitute for professional medical advice, diagnosis, or treatment. Always seek the advice of your physician or other qualified health provider with any questions you may have regarding a medical condition."

package/registry/families/agent-runtime-doctor-ts/files/methodology/treatment-overview.md

@@ -0,0 +1,36 @@
+# Treatment Overview Template
+
+## Purpose
+Provide an evidence-based overview of standard treatments for a specific condition, including how they work, their efficacy, and potential side effects.
+
+## Structure
+
+### 1. Condition Summary
+- Brief recap of the condition being treated.
+
+### 2. Treatment Goals
+- What the treatment aims to achieve (e.g., symptom relief, remission, prevention).
+
+### 3. Standard Treatment Options
+- List each major treatment category (medications, therapies, surgery, lifestyle changes).
+- For each option:
+  - How it works
+  - Typical duration or regimen
+  - Efficacy (cite evidence)
+  - Common side effects or risks
+  - Who it is typically for
+
+### 4. Emerging or Investigational Treatments
+- Briefly mention treatments still under study, with a note that they are not yet standard.
+
+### 5. Lifestyle and Supportive Care
+- Complementary approaches that may help (diet, exercise, support groups).
+
+### 6. Questions to Ask Your Doctor
+- Suggested questions about treatment options, risks, and what to expect.
+
+### 7. Sources
+- Cite all sources.
+
+## Disclaimer
+Always include: "This information is for educational purposes only and is not a substitute for professional medical advice, diagnosis, or treatment. Always seek the advice of your physician or other qualified health provider with any questions you may have regarding a medical condition."

package/registry/families/agent-runtime-doctor-ts/manifest.json

@@ -0,0 +1,143 @@
+{
+  "id": "agent-runtime-doctor-ts",
+  "description": "Medical reference agent bundle \u2014 provides general health information, explains medical terminology, and helps users understand conditions and treatments. NOT a licensed physician, NOT a substitute for professional medical advice, diagnosis, or treatment. Always includes a disclaimer and escalation block for serious concerns. Composes the agent-runtime substrate with structured-output-blocks on the Tangle floor.",
+  "tags": [
+    "agent-runtime",
+    "medical-reference",
+    "health-information",
+    "advisory-agent",
+    "cloudflare-worker"
+  ],
+  "taxonomy": {
+    "language": "markdown",
+    "runtime": "cloudflare-worker",
+    "surface": "agent-runtime"
+  },
+  "includes": [
+    "agent-base:tangle",
+    "agent-base:secure",
+    "agent-base:privacy",
+    "agent-output:blocks",
+    "agent-base:memory",
+    "agent-base:scheduler",
+    "agent-base:mcp-registry",
+    "agent-channels:telegram",
+    "agent-channels:discord",
+    "agent-channels:slack",
+    "agent-channels:whatsapp",
+    "agent-channels:imessage",
+    "agent-channels:gmail",
+    "agent-channels:linear"
+  ],
+  "defaults": {
+    "projectType": "agent-runtime-doctor",
+    "agentName": "doctor",
+    "publicVars": [
+      "AGENT_NAME"
+    ],
+    "routes": [
+      {
+        "path": "/api/chat",
+        "auth": "bearer",
+        "callsTools": [
+          "medical-reference",
+          "symptom-explainer",
+          "treatment-overview"
+        ]
+      },
+      {
+        "path": "/api/health",
+        "auth": "none",
+        "callsTools": []
+      }
+    ],
+    "declaredCapabilities": [
+      "medical-reference",
+      "symptom-explainer",
+      "treatment-overview"
+    ],
+    "runtime": {
+      "sandbox": "tangle",
+      "noNewPrivileges": true,
+      "capDrop": "ALL"
+    },
+    "stakes": "high",
+    "advisoryOnly": true,
+    "outboundDomains": [
+      "api.tangle.tools"
+    ],
+    "secrets": [
+      "TANGLE_API_KEY"
+    ]
+  },
+  "files": [
+    {
+      "source": "files/agent.json",
+      "target": "agent.json"
+    },
+    {
+      "source": "files/AGENTS.md",
+      "target": "AGENTS.md"
+    },
+    {
+      "source": "files/methodology/index.json",
+      "target": "methodology/index.json"
+    },
+    {
+      "source": "files/methodology/medical-reference.md",
+      "target": "methodology/medical-reference.md"
+    },
+    {
+      "source": "files/methodology/symptom-explainer.md",
+      "target": "methodology/symptom-explainer.md"
+    },
+    {
+      "source": "files/methodology/treatment-overview.md",
+      "target": "methodology/treatment-overview.md"
+    },
+    {
+      "source": "files/README.md",
+      "target": "README.md"
+    },
+    {
+      "source": "files/TOOLS.md",
+      "target": "TOOLS.md"
+    }
+  ],
+  "contextHints": {
+    "commands": [],
+    "entrypoints": [
+      "AGENTS.md"
+    ],
+    "extensionPoints": [
+      "templates/",
+      "src/lib/tools/"
+    ]
+  },
+  "tieredKeywords": {
+    "tier1": [
+      "medical-reference-agent",
+      "medical reference agent",
+      "health-info-agent",
+      "health info agent",
+      "doctor-agent",
+      "doctor agent"
+    ],
+    "tier2": [
+      "symptom-explainer",
+      "symptom explainer",
+      "treatment-overview",
+      "treatment overview",
+      "medical-terminology",
+      "medical terminology",
+      "health-literacy",
+      "health literacy"
+    ],
+    "tier3": [],
+    "archetypes": [
+      "agent-in-sandbox",
+      "advisory-agent",
+      "regulated-medical"
+    ]
+  }
+}

package/registry/families/agent-runtime-engineering-manager-ts/files/AGENTS.md

@@ -0,0 +1,64 @@
+---
+name: eng-manager
+role: Engineering manager advisor — 1:1 cadence, sprint planning, incident post-mortems, tech-debt triage. Not a substitute for the operator's own judgment, team, or HR processes.
+domain: eng-mgmt
+allowedDomains:
+  - api.tangle.tools
+allowedEnv:
+  - TANGLE_API_KEY
+advisoryOnly: true
+escalationRequired: true
+version: 0.1.0
+---
+
+## Role
+
+You are an engineering manager advisor. You work alongside a team lead, director, or operator on four things: running a **1:1 cadence** that builds trust and surfaces blockers, **sprint planning** that balances delivery with sustainable pace, **incident post-mortems** that produce real systemic fixes, and **tech-debt triage** that separates the critical from the cosmetic.
+
+You are **not a substitute for the operator's own judgment, team, or HR processes**. You do not see the team's actual capacity, the org chart, the performance reviews, or the interpersonal dynamics the operator lives with daily. State this once, early, when the user asks for high-stakes calls (promotions, terminations, reorgs).
+
+## Authoritative skills
+
+When the user's request maps to one of these capabilities, load the corresponding template *before* responding. The templates are the methodology source of truth; trust them over training.
+
+- `1:1-cadence` → `templates/one-on-one-cadence.md`
+- `sprint-planning` → `templates/sprint-planning.md`
+- `incident-postmortem` → `templates/incident-postmortem.md`
+- `tech-debt-triage` → `templates/tech-debt-triage.md`
+
+## Output blocks
+
+Wrap structured deliverables in parseable blocks the host UI renders distinctly:
+
+- `:::artifact` — 1:1 templates, sprint plans, post-mortem write-ups, tech-debt registers, and any other persisted record. Always tag the producing template (e.g. `template: one-on-one-cadence`).
+- `:::escalation` — emitted whenever a request crosses into territory that requires a real professional (see "Mandatory escalation"). The block names the kind of professional the operator should bring in and the question to bring them.
+- `:::analysis` — short interpretive readouts (e.g. "what this sprint plan risks") that aren't the artifact itself but inform the user's next move.
+
+## Mandatory escalation (advisory boundary)
+
+Run the escalation pattern and emit a `:::escalation` block whenever ANY of these fire:
+
+1. **HR / personnel actions** — termination, performance-improvement plans, harassment investigations, accommodations. → operator's HR business partner or employment lawyer.
+2. **Compensation decisions** — salary adjustments, equity grants, bonuses for named individuals. → operator's HR + compensation team.
+3. **Legal / compliance territory** — regulatory exposure, contractual obligations, IP disputes. → operator's legal counsel.
+4. **Mental health crises** — team member expressing suicidal ideation, severe burnout, or other acute mental health concerns. → operator's EAP or crisis resources.
+5. **Anything triggering "I should ask my manager / HR / legal"** — if the operator is reaching for a professional, escalate before advising.
+
+Do not silently rationalize past any of these. State the escalation, name the professional, and offer to help the operator **prepare** for that conversation (frame the question, list the documents, draft the ask) — preparation is on-scope; the HR / legal / compensation opinion itself is not.
+
+## What you WILL do
+
+- Help structure 1:1s that balance tactical updates, career growth, and psychological safety.
+- Pressure-test sprint plans against team capacity, historical velocity, and dependency risk.
+- Run incident post-mortems with a blameless, systemic lens — find the process gap, not the person.
+- Triage tech debt by impact-to-value ratio, not by how annoying it is.
+- Name the trade-off behind every recommendation. A faster sprint burns out the team; a tech-debt freeze slows feature delivery; say which.
+
+## What you WON'T do
+
+- Make decisions the operator is accountable for.
+- Pretend to know the team's actual morale, capacity, or interpersonal dynamics without asking.
+- Recommend specific promotions, terminations, or compensation changes.
+- Diagnose team dysfunction from a single anecdote — ask for patterns.
+- Fabricate metrics, velocity data, or industry benchmarks.
+- Replace the operator's manager, HR, or legal counsel.

package/registry/families/agent-runtime-engineering-manager-ts/files/README.md

@@ -0,0 +1,18 @@
+# Engineering Manager Agent Runtime
+
+An advisory agent for engineering managers: 1:1 cadence, sprint planning, incident post-mortems, and tech-debt triage.
+
+## Usage
+
+Deploy as a Cloudflare Worker. Set `TANGLE_API_KEY` environment variable.
+
+## Capabilities
+
+- **1:1 Cadence** — Structured weekly conversations with direct reports.
+- **Sprint Planning** — Realistic scope commitment with capacity checks.
+- **Incident Post-Mortem** — Blameless, systemic root-cause analysis.
+- **Tech Debt Triage** — Prioritize by impact-to-value ratio.
+
+## Advisory Only
+
+This agent provides structured guidance and templates. It does not make personnel decisions, compensation changes, or legal judgments. Always consult your HR, legal, and management chain for high-stakes actions.

package/registry/families/agent-runtime-engineering-manager-ts/files/TOOLS.md

@@ -0,0 +1,24 @@
+# TOOLS — agent-runtime-engineering-manager-ts
+
+The bundle inherits all primitives from `agent-base:secure`: `secrets`, `workspace`, `webhook-in`, `webhook-out`, `schedule`, `identity`, `audit`. Plus generic agent tools: `Read`, `Write`, `Edit`, `Glob`, `Grep`, `Bash`, `WebFetch`.
+
+This file lists **domain-specific tools the operator MAY add** if the deployment needs them. Each entry is intent — not implementation. The agent itself can build any of these on demand using `Bash`/`Write` if the operator hasn't.
+
+## Domain tools the operator may want
+
+Stub list — replace with role-specific entries. Keep ≤10 domain tools per deployment; more is fragmentation. Each tool should be:
+- Single-purpose
+- JSON output
+- ≤100 LOC
+- Listed here when added
+
+| Tool | Intent | Notes |
+|---|---|---|
+| `1:1-cadence` | Concrete tool implementing the `1:1-cadence` capability | Operator implements when needed |
+| `sprint-planning` | Concrete tool implementing the `sprint-planning` capability | Operator implements when needed |
+| `incident-postmortem` | Concrete tool implementing the `incident-postmortem` capability | Operator implements when needed |
+| `tech-debt-triage` | Concrete tool implementing the `tech-debt-triage` capability | Operator implements when needed |
+
+## Build a new tool when you need it
+
+The agent's job includes building tools when the measurement doesn't exist. New tools should be small, JSON-output, single-purpose. Add an entry here via PR after shipping.

package/registry/families/agent-runtime-engineering-manager-ts/files/agent.json

@@ -0,0 +1,41 @@
+{
+  "name": "engineering-manager",
+  "description": "Engineering manager agent bundle — 1:1 cadence, sprint planning, incident post-mortems, and technical-debt triage. Composes the agent-runtime substrate with structured-output-blocks on the Tangle floor. Advisory only — never replaces the operator's own judgment, team, or HR processes.",
+  "version": "0.1.0",
+  "tags": [
+    "agent-runtime",
+    "engineering-manager",
+    "advisory-agent",
+    "1:1-cadence",
+    "sprint-planning",
+    "incident-postmortem",
+    "tech-debt",
+    "cloudflare-worker"
+  ],
+  "prompt": {
+    "systemPromptFile": "AGENTS.md"
+  },
+  "tools": {
+    "filesystem": true,
+    "shell": true,
+    "router": true
+  },
+  "permissions": {
+    "filesystem.write": "ask",
+    "shell.exec": "ask",
+    "network": "ask"
+  },
+  "resources": {
+    "files": [
+      {
+        "source": "methodology/"
+      },
+      {
+        "source": "README.md"
+      },
+      {
+        "source": "TOOLS.md"
+      }
+    ]
+  }
+}

package/registry/families/agent-runtime-engineering-manager-ts/files/methodology/incident-postmortem.md

@@ -0,0 +1,124 @@
+# Incident Post-Mortem Template
+
+## Principles
+- **Blameless**: focus on systems, not people. The person who pushed the
+  button is *information*, not the root cause. Replace "X did Y" with
+  "the system allowed Y, with no guardrail."
+- **Actionable**: every finding produces a concrete change to code,
+  config, runbook, alert, or process — with an owner and a date.
+- **Timely**: draft within 48 hours of resolution, while memory is
+  fresh and the on-call still has context.
+- **Honest about severity**: don't downgrade post-hoc to make the
+  scorecard look better; the org's job is to learn, not to report
+  green.
+
+## Sections (use this skeleton)
+
+### 1. Summary
+
+- One paragraph: what broke, when, who was affected, how it was
+  resolved.
+- Severity: (SEV1 = customer-impacting outage / SEV2 = degraded /
+  SEV3 = internal / SEV4 = near-miss)
+- Detection latency, resolution latency, total duration.
+- Customer impact: count of affected users / requests / dollars.
+
+### 2. Timeline (UTC)
+
+Bullet each material event:
+- T-0: change merged / deploy started
+- T+x: first error signal (which alert / dashboard / customer report)
+- T+y: on-call paged
+- T+z: hypothesis formed
+- T+a: mitigation applied (rollback / feature flag / scaling)
+- T+b: resolution confirmed (which dashboard recovered)
+
+For each entry, record who saw it (role, not name), how they saw it
+(channel), and what they did. The timeline shows where minutes were
+lost — usually in detection or in hypothesis-formation.
+
+### 3. Root cause
+
+Write a single specific sentence describing the systemic failure.
+Examples:
+- "Bad: the engineer pushed a wrong config." Good: "config rollouts
+  bypassed the staging environment because the rollout flag was set
+  to `force=true` for an unrelated experiment from 6 weeks ago, and
+  the bypass was undocumented."
+- "Bad: cache miss." Good: "the cache key included a timestamp that
+  changed every minute, causing 100% miss rate at peak; the key
+  shape was introduced in PR #1234 without a hit-rate alert."
+
+### 4. Contributing factors
+
+What made this incident *possible* or *worse* than it had to be:
+- Monitoring: the alert fired late / not at all / on the wrong
+  channel / went to the wrong rotation.
+- Process: rollback playbook was missing / outdated / required
+  privileged access only one engineer had.
+- Knowledge: oncall didn't know the system, no runbook, no
+  architecture diagram, ownership unclear.
+- Tooling: the deploy tool didn't surface the regression metric in
+  the rollout UI; the rollback required a 30-minute custom script.
+- Capacity / dependencies: an upstream dep was at 95% before the
+  incident; we were one event away from saturation.
+
+### 5. Action items
+
+Each item must have:
+- A specific change (code, config, alert threshold, runbook, RBAC)
+- An owner (named team or named role, not "we")
+- A due date
+- A type tag: **preventive** (stops recurrence), **detective**
+  (catches it earlier next time), **mitigative** (reduces blast
+  radius), **process** (changes how the team operates)
+- Severity tag: P0 / P1 / P2
+
+| ID | Action | Owner | Type | Due | Sev |
+|----|--------|-------|------|-----|-----|
+| A1 | Add hit-rate alert at <threshold> | Cache team | Detective | 2026-05-10 | P0 |
+| A2 | Block force-flag rollouts on prod without 2-person review | Deploy team | Preventive | 2026-05-15 | P0 |
+
+### 6. Went well / didn't go well
+
+- What was *positive* in the response (clear comms, clean rollback,
+  helpful alert) — name it so the team keeps doing it.
+- What was *negative* (slow paging, confused ownership, missing
+  runbook) — feeds the action items.
+- "Lucky" calls explicitly: "we got lucky that the bug only affected
+  10% of traffic; without that, blast radius would have been 10x" —
+  luck-cases need pre-emptive action items because next time we
+  may not be lucky.
+
+### 7. Open questions
+
+What we don't know yet — for follow-up investigation. Don't pretend
+the post-mortem has all the answers.
+
+## Follow-up discipline
+
+- Track every action item to completion in the team's actual
+  backlog with the post-mortem ID. A post-mortem with stalled action
+  items is theatre.
+- Read prior post-mortems in the same area before writing the next
+  one — repeat findings indicate the action items aren't landing.
+- Share with the relevant stakeholders (eng, ops, product, support,
+  legal/compliance if customer-impacting).
+- Run a 15-minute review meeting where the team can ask questions
+  about the cause. The doc alone is not enough.
+
+## Output block
+
+Wrap in `:::artifact` with `template: incident-postmortem`. Tag
+severity, customer impact, and the count of preventive / detective
+action items so the org can roll up to a learning-system metric.
+
+## Refusal triggers
+
+The agent will *not*:
+- Name individual engineers as causes (blameless culture is hard to
+  maintain; the agent will not undermine it)
+- Approve a post-mortem that has zero preventive or detective action
+  items — that's a status report, not learning
+- Sign off on customer comms or legal disclosure language without
+  the human in the loop

package/registry/families/agent-runtime-engineering-manager-ts/files/methodology/index.json

@@ -0,0 +1,32 @@
+{
+  "entries": [
+    {
+      "id": "one-on-one-cadence",
+      "capability": "1:1-cadence",
+      "path": "./one-on-one-cadence.md",
+      "tags": ["cadence", "1:1", "team-management"],
+      "version": "0.1.0"
+    },
+    {
+      "id": "sprint-planning",
+      "capability": "sprint-planning",
+      "path": "./sprint-planning.md",
+      "tags": ["methodology", "sprint", "agile"],
+      "version": "0.1.0"
+    },
+    {
+      "id": "incident-postmortem",
+      "capability": "incident-postmortem",
+      "path": "./incident-postmortem.md",
+      "tags": ["methodology", "incident", "postmortem", "blameless"],
+      "version": "0.1.0"
+    },
+    {
+      "id": "tech-debt-triage",
+      "capability": "tech-debt-triage",
+      "path": "./tech-debt-triage.md",
+      "tags": ["methodology", "tech-debt", "triage"],
+      "version": "0.1.0"
+    }
+  ]
+}

package/registry/families/agent-runtime-engineering-manager-ts/files/methodology/one-on-one-cadence.md

@@ -0,0 +1,109 @@
+# 1:1 Cadence Template
+
+## Purpose
+Build trust, surface blockers, align on growth, and detect early
+warning signs (burnout, attrition risk, cross-team friction). A 1:1 is
+not a status update — managers can read Jira; status meetings are
+where status goes. The 1:1 is the conversation that has to happen
+between two people for it to matter.
+
+## Frequency
+
+- **Weekly, 30 minutes**, default.
+- **Bi-weekly, 45 minutes** for senior ICs who explicitly prefer
+  longer-less-frequent (acceptable, but not the default).
+- **Skip-level once per quarter** with each team member's manager's
+  manager (only for the EM, not for the agent to schedule).
+- **Never cancel** the 1:1. Reschedule within 5 business days. A
+  cancelled 1:1 with no reschedule is a trust signal — the report
+  will read it as "I matter less than this other thing."
+
+## Agenda (suggested 30 min split)
+
+1. **Check-in (2–3 min).**
+   - "How are you doing — not work, just generally?"
+   - Read energy: tone, posture (in person), pacing of speech (remote).
+   - This is not throat-clearing. The signal you'll catch here often
+     doesn't surface in the tactical block.
+2. **Their agenda (10–12 min).**
+   - The report sets the agenda 24h before in a shared doc. If empty,
+     the manager prompts: "What's on your mind?" Do *not* fill the
+     space with the manager's items first.
+   - Common topics: blockers, decisions needed from the manager,
+     interpersonal friction, frustration with priorities.
+3. **Manager's agenda (5–7 min).**
+   - Feedback (specific, recent — never save it for review season).
+   - Direction / context the report needs ("here's what leadership
+     is thinking about for next quarter").
+   - Cross-team coordination asks.
+4. **Growth (5–7 min).**
+   - "What did you learn this week?" or "What's a skill you want to
+     build?"
+   - Specific stretch assignments tied to the report's growth area.
+   - Career framing once per month minimum: where they want to be
+     in 12 months, what evidence the org needs to see.
+5. **Close (2 min).**
+   - Action items captured (theirs and yours), with owners.
+   - Confirm next 1:1.
+   - "Anything else you want to put on next week's agenda?"
+
+## Topic rotation
+
+Across a month, every 1:1 should touch:
+- Tactical / blockers (every week)
+- Career / growth (≥1 of 4)
+- Feedback (≥1 of 4 — feedback is not annual)
+- Personal check-in beyond work (≥1 of 4 — relationship grounding)
+- Direction / strategy (≥1 of 4)
+
+Don't run all 4 weeks tactical-only. The relationship goes shallow,
+and the first you'll hear of a real problem is a resignation.
+
+## Listening discipline
+
+- **Talk-time target: 70/30** — report does 70% of the talking.
+- **Reflect before responding.** "It sounds like the hardest part is …"
+- **Don't fix in the room.** Coach, don't rescue. "What would you
+  try first?" before "here's what I'd do."
+- **Note the words you didn't say.** If the report mentions a peer
+  three times negatively, that's a pattern worth a follow-up — but
+  the 1:1 is not the place to litigate it on the spot.
+
+## Signals to escalate (from a 1:1 to a real action)
+
+- Burnout language: "I haven't taken a real weekend in …" / "I'm
+  tired all the time" / "I don't know if I can keep doing this."
+- Attrition risk: "I've been thinking about my next move" / "I'm
+  not sure this is the right place for me" / "I had coffee with a
+  friend who's hiring."
+- Cross-team conflict: same name comes up negatively across multiple
+  reports.
+- Compensation concern: market data references, "I haven't had a
+  raise in …", peer-comparison language.
+- Health / family: should trigger an offer of flexibility (PTO,
+  reduced hours, leave) before they ask.
+
+## Notes hygiene
+
+- Shared doc, dated entries. Both parties can edit.
+- Action items at the top of each entry, struck through when done.
+- Don't put feedback in a private-only doc — that's how it gets
+  forgotten before review season. Put it in the shared 1:1 doc.
+
+## Output block
+
+If the agent is asked to draft a 1:1 agenda or summarize a 1:1 round
+across the team, wrap in `:::artifact` with
+`template: one-on-one-cadence`. Never put real names of reports in
+generated artifacts unless the user has provided them and consented
+to that scope.
+
+## Refusal
+
+The agent will not:
+- Generate a "performance issue" memo from a 1:1 transcript without
+  HR involvement.
+- Recommend firing or PIP-placing a named report — that's a human +
+  HR + skip-level decision.
+- Surface a 1:1 transcript to anyone other than the manager and
+  report without explicit consent.