@vextlabs/theron-cli 0.3.0 → 0.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/api.d.ts +8 -0
- package/dist/api.js +3 -0
- package/dist/api.js.map +1 -1
- package/dist/auth.js +51 -1
- package/dist/auth.js.map +1 -1
- package/dist/banner.js +3 -2
- package/dist/banner.js.map +1 -1
- package/dist/checkpoints.d.ts +32 -0
- package/dist/checkpoints.js +61 -0
- package/dist/checkpoints.js.map +1 -0
- package/dist/index.js +59 -4
- package/dist/index.js.map +1 -1
- package/dist/input.d.ts +61 -0
- package/dist/input.js +574 -0
- package/dist/input.js.map +1 -0
- package/dist/profiles/index.js +5 -0
- package/dist/profiles/index.js.map +1 -1
- package/dist/profiles/methodologies/operate_domains.d.ts +8 -0
- package/dist/profiles/methodologies/operate_domains.js +1239 -0
- package/dist/profiles/methodologies/operate_domains.js.map +1 -0
- package/dist/profiles/seeds.js +57 -36
- package/dist/profiles/seeds.js.map +1 -1
- package/dist/receipt.d.ts +17 -0
- package/dist/receipt.js +46 -0
- package/dist/receipt.js.map +1 -0
- package/dist/render.d.ts +4 -1
- package/dist/render.js +95 -28
- package/dist/render.js.map +1 -1
- package/dist/repl.d.ts +8 -1
- package/dist/repl.js +420 -62
- package/dist/repl.js.map +1 -1
- package/dist/sessions.d.ts +14 -0
- package/dist/sessions.js +100 -0
- package/dist/sessions.js.map +1 -1
- package/dist/ship.d.ts +2 -0
- package/dist/ship.js +62 -0
- package/dist/ship.js.map +1 -0
- package/dist/skills/catalog.d.ts +13 -0
- package/dist/skills/catalog.js +86 -0
- package/dist/skills/catalog.js.map +1 -0
- package/dist/tools/bash.js +81 -14
- package/dist/tools/bash.js.map +1 -1
- package/dist/tools/edit.js +21 -1
- package/dist/tools/edit.js.map +1 -1
- package/dist/tools/glob.js +4 -1
- package/dist/tools/glob.js.map +1 -1
- package/dist/tools/grep.d.ts +5 -0
- package/dist/tools/grep.js +101 -2
- package/dist/tools/grep.js.map +1 -1
- package/dist/tools/index.d.ts +22 -0
- package/dist/tools/index.js +177 -41
- package/dist/tools/index.js.map +1 -1
- package/dist/tools/ls.d.ts +3 -0
- package/dist/tools/ls.js +23 -12
- package/dist/tools/ls.js.map +1 -1
- package/dist/tools/multiedit.d.ts +12 -0
- package/dist/tools/multiedit.js +79 -0
- package/dist/tools/multiedit.js.map +1 -0
- package/dist/tools/stoa.d.ts +1 -1
- package/dist/tools/stoa.js +7 -3
- package/dist/tools/stoa.js.map +1 -1
- package/dist/tools/task.d.ts +9 -0
- package/dist/tools/task.js +166 -0
- package/dist/tools/task.js.map +1 -0
- package/dist/tools/todowrite.d.ts +12 -0
- package/dist/tools/todowrite.js +38 -0
- package/dist/tools/todowrite.js.map +1 -0
- package/dist/tools/webfetch.d.ts +6 -0
- package/dist/tools/webfetch.js +98 -0
- package/dist/tools/webfetch.js.map +1 -0
- package/dist/tools/websearch.d.ts +7 -0
- package/dist/tools/websearch.js +83 -0
- package/dist/tools/websearch.js.map +1 -0
- package/dist/tools/write.js +17 -1
- package/dist/tools/write.js.map +1 -1
- package/dist/verifiers/confidence_marked.d.ts +2 -0
- package/dist/verifiers/confidence_marked.js +49 -0
- package/dist/verifiers/confidence_marked.js.map +1 -0
- package/dist/verifiers/disclaimer_gate.d.ts +2 -0
- package/dist/verifiers/disclaimer_gate.js +57 -0
- package/dist/verifiers/disclaimer_gate.js.map +1 -0
- package/dist/verifiers/index.d.ts +5 -0
- package/dist/verifiers/index.js +20 -7
- package/dist/verifiers/index.js.map +1 -1
- package/dist/verifiers/lint.js +4 -3
- package/dist/verifiers/lint.js.map +1 -1
- package/dist/verifiers/promoted_kernels.d.ts +8 -0
- package/dist/verifiers/promoted_kernels.js +190 -0
- package/dist/verifiers/promoted_kernels.js.map +1 -0
- package/dist/verifiers/source_gate.js +2 -3
- package/dist/verifiers/source_gate.js.map +1 -1
- package/dist/verifiers/test_smoke.js +30 -0
- package/dist/verifiers/test_smoke.js.map +1 -1
- package/dist/verifiers/types.d.ts +3 -0
- package/package.json +4 -2
- package/skills/README.md +123 -0
- package/skills/ab-test.md +89 -0
- package/skills/api-design.md +175 -0
- package/skills/architecture-design.md +185 -0
- package/skills/business-case.md +77 -0
- package/skills/causal-inference.md +77 -0
- package/skills/clinical-guideline.md +98 -0
- package/skills/code-review.md +98 -0
- package/skills/cold-outreach.md +268 -0
- package/skills/competitive-teardown.md +223 -0
- package/skills/component-spec.md +121 -0
- package/skills/content-calendar.md +280 -0
- package/skills/contract-review.md +155 -0
- package/skills/data-analysis.md +187 -0
- package/skills/debug.md +91 -0
- package/skills/design-audit.md +121 -0
- package/skills/differential-diagnosis.md +79 -0
- package/skills/discovery-call.md +206 -0
- package/skills/edit-pass.md +80 -0
- package/skills/engineering-calc.md +101 -0
- package/skills/estimate.md +70 -0
- package/skills/experiment-design.md +105 -0
- package/skills/fact-check.md +82 -0
- package/skills/financial-model.md +104 -0
- package/skills/grant-proposal.md +93 -0
- package/skills/harmony-analysis.md +93 -0
- package/skills/hypothesis-generation.md +99 -0
- package/skills/incident-response.md +134 -0
- package/skills/interview-loop.md +62 -0
- package/skills/job-scorecard.md +92 -0
- package/skills/kb-article.md +174 -0
- package/skills/launch-plan.md +85 -0
- package/skills/lease-review.md +93 -0
- package/skills/lesson-plan.md +198 -0
- package/skills/literature-review.md +69 -0
- package/skills/market-entry.md +137 -0
- package/skills/market-sizing.md +159 -0
- package/skills/meta-analysis.md +140 -0
- package/skills/migrate.md +117 -0
- package/skills/optimize.md +88 -0
- package/skills/options-strategy.md +166 -0
- package/skills/peer-review.md +96 -0
- package/skills/pentest-plan.md +193 -0
- package/skills/pitch-review.md +132 -0
- package/skills/plan.md +88 -0
- package/skills/policy-brief.md +124 -0
- package/skills/positioning.md +192 -0
- package/skills/postmortem.md +168 -0
- package/skills/prd.md +105 -0
- package/skills/prioritize.md +162 -0
- package/skills/proof.md +91 -0
- package/skills/property-underwrite.md +159 -0
- package/skills/recipe-develop.md +109 -0
- package/skills/red-team.md +142 -0
- package/skills/refactor.md +58 -0
- package/skills/reflection-session.md +115 -0
- package/skills/regulatory-compliance.md +136 -0
- package/skills/reproduce.md +87 -0
- package/skills/runbook.md +344 -0
- package/skills/security-audit.md +154 -0
- package/skills/seo-brief.md +201 -0
- package/skills/sql-query.md +161 -0
- package/skills/story-craft.md +163 -0
- package/skills/tdd.md +59 -0
- package/skills/term-sheet.md +298 -0
- package/skills/theory-of-change.md +88 -0
- package/skills/threat-model.md +104 -0
- package/skills/ticket-triage.md +200 -0
- package/skills/tolerance-analysis.md +149 -0
- package/skills/training-program.md +151 -0
- package/skills/translate.md +64 -0
- package/skills/unit-economics.md +238 -0
- package/skills/valuation.md +112 -0
- package/skills/write-tests.md +77 -0
|
@@ -0,0 +1,280 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: content-calendar
|
|
3
|
+
description: Engineer a multi-month content calendar for a digital product or research AI platform — define content pillars, a repeatable series arc, native platform format per channel, engagement metrics to track (saves/shares over vanity), realistic cadence, and sponsorship disclosure; invoke when launching a brand, scaling social presence, or productizing thought leadership at a tech company.
|
|
4
|
+
allowed-tools: Read, Write
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
═══ HARD RULES ═══
|
|
8
|
+
|
|
9
|
+
1. NEVER start with "here's our product, what should we post?" — start with the specific job the target audience is trying to do and the one thread that ties all content to that job.
|
|
10
|
+
2. NEVER confuse content pillars with messaging pillars. Pillars are durable archetypes (e.g., "mechanism reveal", "user win", "methodology") that repeat across months; they are NOT the same as positioning statements.
|
|
11
|
+
3. NEVER optimize for vanity metrics (impressions, follower count, likes). Optimize for the ONE metric that proves engagement: saves/bookmarks for thought-leadership, shares for viral, replies/questions for community education. Measure it explicitly in the calendar.
|
|
12
|
+
4. NEVER post the same asset on LinkedIn and Twitter and Instagram as if format does not matter. Rewrite every post for platform norms: LinkedIn = professional context + longer form; Twitter = sharp, controversial-or-novel + quote-threads; Instagram = visual-first + narrative caption; TikTok = movement + personality; YouTube = depth.
|
|
13
|
+
5. NEVER hide sponsorships or affiliate relationships. Disclose in the first sentence with a flag (#ad, "In partnership with…", "Paid by…") even if legal does not require it. Undisclosed partnerships erode audience trust and are a brand landmine.
|
|
14
|
+
6. NEVER build a calendar with a mix of permanent and temporary columns — the calendar must be readable and actionable for whoever executes it (founder, community manager, agency). Lock the structure from month one and reuse it.
|
|
15
|
+
7. NEVER treat cadence as fixed. If the content is genuinely novel weekly, ship it weekly. If it's best executed monthly or biweekly, lock that and communicate it publicly so the audience knows when to expect it. Irregular cadence kills habit-formation.
|
|
16
|
+
8. NEVER write copy in the calendar itself — write only the content blueprint (pillar, hook, evidence type, metric to track) and the lead. The final copy is written on-platform by the executor, not copied-pasted from a doc.
|
|
17
|
+
9. NEVER publish a "series" that is not repeatable at least 3 times with different examples. One-off themed posts are not a series. A series must have a named arc with a replicable template (e.g., "Mechanism Reveal — problem statement → physics proof → one-line application").
|
|
18
|
+
10. NEVER assume all audience members will engage the same way. Segment content by buyer journey stage (awareness = education; consideration = comparison; decision = proof; retained = expansion) and map posts to each stage.
|
|
19
|
+
11. NEVER set absolute engagement targets without anchoring them to your current audience size and baseline. A target of "100 saves" is meaningless for a 300-follower account and insulting for a 200K-follower account. All targets must be expressed as multiples of recent baseline (e.g., "2× your current per-post save average within 8 weeks").
|
|
20
|
+
12. NEVER rely on organic reach alone for seeding a new series or pillar. The first 30–60 minutes of engagement after publication is the window the platform algorithm uses to decide distribution. Plan for seed amplification (internal team engagement, curated DMs to warm contacts, cross-post to relevant community threads) every time.
|
|
21
|
+
|
|
22
|
+
═══ PHASE A — AUDIENCE SEGMENTATION & JOB-TO-BE-DONE ═══
|
|
23
|
+
|
|
24
|
+
A1. Define the target audience with specificity — not just "AI practitioners" or "engineers," but:
|
|
25
|
+
- **Role cluster** (researcher, applied engineer, decision-maker, practitioner learning solo)
|
|
26
|
+
- **Stage in journey** (exploring the space, evaluating options, building, proving, scaling)
|
|
27
|
+
- **Success metric they own** (cost per inference, time to deploy, audit trail, accuracy on real data, team velocity)
|
|
28
|
+
- **Frustration with the status quo** (existing solutions are too expensive, too slow, not auditable, a research dead-end)
|
|
29
|
+
|
|
30
|
+
A2. For each segment, write the one-sentence job-to-be-done: "I need to [action] so that [outcome]." Example: "I need to understand whether verifiable AI is possible at scale so that I can decide if this is the future I want to work on." Or: "I need to see a working mechanism for multi-step reasoning so that I can trust it in a real application."
|
|
31
|
+
|
|
32
|
+
A3. Enumerate the channels where each segment is native:
|
|
33
|
+
- **Researchers**: preprint platforms (arXiv threads, Twitter/X), long-form (Substack, blogs), conferences
|
|
34
|
+
- **Applied engineers**: GitHub discussions, Discord/Slack communities, Twitter/X code clips
|
|
35
|
+
- **Decision-makers/CTOs**: LinkedIn (curated, long-form), email (newsletter), webinars
|
|
36
|
+
- **Practitioners**: YouTube tutorials, TikTok/Instagram (visual learnings), Reddit, Discord communities
|
|
37
|
+
|
|
38
|
+
NEVER assume one channel reaches all. Pick top 2–3 per segment and go deep instead of shallow across 10 channels.
|
|
39
|
+
|
|
40
|
+
A4. BREAK FLAG: if you cannot name at least 2 concrete segments with different jobs-to-be-done, the calendar is too generic. Stop and interview 5–10 audience members before proceeding.
|
|
41
|
+
|
|
42
|
+
═══ PHASE B — CONTENT PILLAR ARCHITECTURE ═══
|
|
43
|
+
|
|
44
|
+
B1. Define the **core pillars** — these are the repeating content archetypes that prove your thesis over time:
|
|
45
|
+
- **Mechanism reveals**: explain one component of your system or insight, with proof. Format: problem → math/code → application. Not aspirational.
|
|
46
|
+
- **User/customer wins**: a real person achieved X using your platform/approach. Format: challenge → how they solved it → the number (time saved, cost cut, accuracy gain).
|
|
47
|
+
- **Methodology deep-dives**: a replicable process or framework. Format: problem it solves → step-by-step walkthrough → when to use it vs. alternatives.
|
|
48
|
+
- **Research audit trails**: thinking-in-public about a hard problem. Format: hypothesis → experiment → result (pass/fail, with evidence) → next question.
|
|
49
|
+
- **Anti-hype clarifications**: correct a misconception in the field. Format: "Everyone says X → here's why that's incomplete → here's what actually happens (with proof)."
|
|
50
|
+
- **Technical artifacts**: code, benchmarks, evaluation datasets, open-source tools released with documentation.
|
|
51
|
+
- **Founder/team voice**: the human behind the work — motivation, learning, team philosophy (sparingly; 1 per month max).
|
|
52
|
+
|
|
53
|
+
B2. For each pillar, write the **template** (the repeatable shape):
|
|
54
|
+
Example (Mechanism Reveals):
|
|
55
|
+
- **Hook (first 7 words)**: "Here's the one thing most [claim-category] miss" OR "We spent 6 months on this" OR "[Problem] is unsolvable — here's why"
|
|
56
|
+
- **Context** (1–2 sentences): What makes this mechanism non-obvious or valuable?
|
|
57
|
+
- **Core content** (mechanism, proof, or framework itself): The substance. Not a sales pitch.
|
|
58
|
+
- **Application**: One sentence: "This means [outcome for the job-to-be-done]."
|
|
59
|
+
- **Metric to track**: Saves, shares, replies with technical questions (not comments like "cool post").
|
|
60
|
+
|
|
61
|
+
B3. Assign a **color or label** to each pillar for calendar visualization (useful for scanning at a glance, regardless of which tool you use to maintain the calendar).
|
|
62
|
+
|
|
63
|
+
B4. Decide on **pillar distribution**: how many posts per month belong to each pillar? Example:
|
|
64
|
+
- 40% mechanism reveals (2–3 per month)
|
|
65
|
+
- 25% user wins (1–2 per month)
|
|
66
|
+
- 20% methodology / audit trails (1–2 per month)
|
|
67
|
+
- 10% anti-hype (0–1 per month)
|
|
68
|
+
- 5% founder voice or technical artifacts (as they ship)
|
|
69
|
+
|
|
70
|
+
These ratios are starting points, not law. Rebalance monthly based on what the metrics tell you (Phase F).
|
|
71
|
+
|
|
72
|
+
B5. BREAK FLAG: if you have more than 6–7 pillars, the calendar will lack focus. Consolidate or cut.
|
|
73
|
+
|
|
74
|
+
═══ PHASE C — REPEATABLE SERIES ARCHITECTURE ═══
|
|
75
|
+
|
|
76
|
+
C1. Design **one signature series** (this is different from pillars; it's a multi-post narrative arc):
|
|
77
|
+
- **Title**: name it for the audience's job, not your brand. Examples: "First Principles Fridays" (researchers), "Bench Marks" (engineers who trust data over claims), "One Decision" (decision-makers who want the net of a long analysis in 3 minutes).
|
|
78
|
+
- **Frequency**: weekly, biweekly, or monthly. Lock it.
|
|
79
|
+
- **Episode structure** (the template for each installment):
|
|
80
|
+
* Episodic arc example (audit trail): "Bench Marks: [topic] — What vendors claim → what the data says → why the gap exists"
|
|
81
|
+
* Episodic teaching: "First Principles: [concept] — The naive model most people use → why it breaks → the corrected model with an example"
|
|
82
|
+
- **How many episodes minimum**: at least 6 confirmed before you announce the series publicly; aim for 12–24 in the pipeline (so you ship twice/month for a year without running dry).
|
|
83
|
+
|
|
84
|
+
C2. Map the series across your calendar in a visible way (e.g., "Wednesdays at 9am PT = series episode drops").
|
|
85
|
+
|
|
86
|
+
C3. For each series episode, define:
|
|
87
|
+
- The specific mechanism/finding/benchmark it covers
|
|
88
|
+
- The primary audience segment it addresses
|
|
89
|
+
- The metric to track (e.g., "saves by engineers" vs. "shares by researchers")
|
|
90
|
+
- The call-to-action (if any): link to full write-up, GitHub repo, discussion thread, or nothing (education-only is fine).
|
|
91
|
+
|
|
92
|
+
C4. BREAK FLAG: if you cannot commit to the series frequency for 12 months with current resources, do not call it a series. Call it "occasional deep-dives" and post it ad-hoc. A broken series is worse than no series.
|
|
93
|
+
|
|
94
|
+
═══ PHASE D — PLATFORM-NATIVE FORMATTING ═══
|
|
95
|
+
|
|
96
|
+
D1. For each channel, lock the **format and copy norms**:
|
|
97
|
+
|
|
98
|
+
**Twitter/X:**
|
|
99
|
+
- Thread format (4–8 tweets max): hook → escalation → proof/artifact → application.
|
|
100
|
+
- Copy: short sentences. One idea per tweet. Use line breaks for rhythm.
|
|
101
|
+
- Assets: code snippets (as quoted text or images), charts, one headline quote.
|
|
102
|
+
- Metric: retweets with comments (questions, corrections) > bookmarks > likes.
|
|
103
|
+
- Posting: 9am or 5pm PT, Wed–Fri (peak tech audience engagement window; verify against your own analytics after 4 weeks).
|
|
104
|
+
|
|
105
|
+
**LinkedIn:**
|
|
106
|
+
- Format: one long-form post (600–1200 words, or a "document" post with formatted blocks).
|
|
107
|
+
- Copy: professional but direct. Lead with the insight. Avoid ALL CAPS and emoji spam.
|
|
108
|
+
- Assets: one high-quality image or chart per post. Video (60–120 sec) if available.
|
|
109
|
+
- Hook: first-person and specific — "Here's what changed in the last 6 months..." OR "This surprised us in the data..." not "Excited to share..."
|
|
110
|
+
- Metric: shares (not likes); comments from domain practitioners count more than generic praise.
|
|
111
|
+
- Posting: 8am–12pm ET, Tue–Thu.
|
|
112
|
+
|
|
113
|
+
**YouTube (if included):**
|
|
114
|
+
- Format: recorded explanation video (6–12 min for technical, 3–5 min for punchy mechanism reveal). Slides + voiceover or visual demo preferred over talking head alone.
|
|
115
|
+
- Hook (first 10 seconds): "By the end of this video, you'll know why [common belief] is wrong and what actually happens instead."
|
|
116
|
+
- Metric: watch-through rate (completion %), not subscriber count. Aim for 40%+ completion on technical content; 55%+ on short-form punchy videos.
|
|
117
|
+
- Call-to-action: "The code is on GitHub. Link in the description." One CTA per video.
|
|
118
|
+
|
|
119
|
+
**Substack/Newsletter:**
|
|
120
|
+
- Format: 1000–2000 words per issue. One deep idea, not a round-up of links.
|
|
121
|
+
- Tone: thinking-in-public, not fully baked. Include uncertainty — readers forward newsletters that feel honest, not polished.
|
|
122
|
+
- Metric: reply rate, forward rate (for paid), click-through to related content.
|
|
123
|
+
- Cadence: weekly or biweekly, lock it. Consistency > frequency.
|
|
124
|
+
|
|
125
|
+
D2. For each pillar + channel combination, create a **copy template** (not the final copy, but the shape):
|
|
126
|
+
Example: Mechanism Reveal on Twitter = "Here's [the one thing missed] [proof in 2 tweets] [why it matters] [link to full write-up if >280 chars of context needed]"
|
|
127
|
+
|
|
128
|
+
D3. Define **asset requirements** per channel:
|
|
129
|
+
- Twitter: code snippets, 1–2 charts, no embedded video (links OK).
|
|
130
|
+
- LinkedIn: 1 high-res image or chart. Document carousel (5–10 slides) for methodology posts.
|
|
131
|
+
- YouTube: slides, screen recording, or animated explainer. Thumbnail with visible text.
|
|
132
|
+
- Substack: inline charts or equations, link references (no embedded video).
|
|
133
|
+
|
|
134
|
+
═══ PHASE E — CADENCE & REALISTIC EXECUTION ═══
|
|
135
|
+
|
|
136
|
+
E1. Map the **monthly posting schedule** (not individual posts, but the pattern):
|
|
137
|
+
```
|
|
138
|
+
Week 1: Mechanism Reveal (Twitter thread + LinkedIn) + seed amplification wave (30-min post-publish)
|
|
139
|
+
Week 2: Series episode (all channels) + community reply engagement (respond to every substantive comment within 24 hours)
|
|
140
|
+
Week 3: Methodology or anti-hype post (LinkedIn + Twitter) + share to 2–3 relevant communities
|
|
141
|
+
Week 4: Audit trail / research update OR founder voice OR month-end retrospective post
|
|
142
|
+
```
|
|
143
|
+
This pattern achieves: 1 series per month + 2–3 mechanism reveals + 1 methodology + 1 user win + community engagement = sustainable for a 1–2 person team.
|
|
144
|
+
|
|
145
|
+
E2. Calculate **execution overhead** (ranges, not fixed numbers — actual time varies by how much pre-existing research exists):
|
|
146
|
+
- Mechanism reveal: research (3–10 hours depending on novelty) + writing (2–4 hours) + platform posting and assets (1–2 hours).
|
|
147
|
+
- Series episode: 2–5 hours (lower end if the mechanism was pre-researched in a previous post).
|
|
148
|
+
- User win: interview (1–2 hours) + write-up (1 hour) + assets (30 min).
|
|
149
|
+
- Anti-hype post: research to find the real data (2–4 hours, longer if the claim is poorly documented) + write (1–2 hours) + post (1 hour).
|
|
150
|
+
|
|
151
|
+
Lock a **weekly time budget** and fit the calendar to it — do not build a calendar that assumes a workload you cannot sustain without dropping quality.
|
|
152
|
+
|
|
153
|
+
E3. Build a **content buffer**:
|
|
154
|
+
- For repeatable pillars (mechanism reveals, methodology), batch-produce 4 weeks of content every quarter.
|
|
155
|
+
- For time-sensitive content (user wins, anti-hype responses to breaking field developments), keep a 1–2 week buffer ahead of publication.
|
|
156
|
+
- For the series, maintain a 3–6 episode lead (so you ship on schedule even if a research result comes back later than expected).
|
|
157
|
+
|
|
158
|
+
E4. Set a **publication calendar** visible to the team with these columns (spreadsheet, Trello, Airtable, or any kanban tool — format does not matter, consistency does):
|
|
159
|
+
- Date and time (specific, e.g., "Wednesday 9am PT").
|
|
160
|
+
- Pillar and series name.
|
|
161
|
+
- Lead/hook (2–3 words max, just enough to identify the draft).
|
|
162
|
+
- Responsible person.
|
|
163
|
+
- Status: backlog / in-research / draft / review / scheduled / published / metric-captured.
|
|
164
|
+
|
|
165
|
+
E5. Plan the **seed amplification window** for every post:
|
|
166
|
+
- Identify 3–5 warm contacts (colleagues, engaged followers, community members) who will engage meaningfully within the first hour of publication.
|
|
167
|
+
- Do not ask for likes — ask specific people to share their actual reaction or a question in the comments. Genuine engagement beats coordinated likes; platforms flag sudden like spikes as manipulation.
|
|
168
|
+
- Cross-post to 1–2 relevant community channels (Discord, Slack, Reddit) where the content is genuinely on-topic. Never spam; only post where you are an active, recognized participant.
|
|
169
|
+
|
|
170
|
+
E6. BREAK FLAG: if you cannot sustain the calendar for 6 months with current resources, cut frequency or pillars. A smaller, consistent calendar beats an ambitious, sporadic one. Announce the reduced cadence publicly so your audience adjusts expectations.
|
|
171
|
+
|
|
172
|
+
═══ PHASE F — METRICS & FEEDBACK LOOPS ═══
|
|
173
|
+
|
|
174
|
+
F1. Define the **north-star metric per audience segment**, expressed as a multiple of your current baseline (never as an absolute target decoupled from your current scale):
|
|
175
|
+
- **Researchers/engineers**: saves + technical replies (questions about mechanism, reproducibility, code). Target: 2–3× your current per-post save average within 8 weeks.
|
|
176
|
+
- **Decision-makers**: shares + profile-view uplift in the 7 days after publication. Target: 2× current share rate; 10%+ profile-view increase in the following week.
|
|
177
|
+
- **Community**: reply rate + community-initiated discussions. Target: reply rate 2× your current average; 1+ user-initiated thread per post within 48 hours.
|
|
178
|
+
|
|
179
|
+
Do NOT track likes, impressions, or follower growth unless you can demonstrate they correlate to the north-star metric in your own data.
|
|
180
|
+
|
|
181
|
+
F2. For the series, track:
|
|
182
|
+
- **Episode-over-episode engagement**: is engagement on series #2 equal to or better than series #1? Decline after episode 3 signals topic saturation or format fatigue.
|
|
183
|
+
- **Cumulative series effect**: are people who land on a series post first more likely to follow and engage with subsequent content? Track this as a new-follower cohort comparison (series-landing vs. non-series-landing) over 30 days.
|
|
184
|
+
|
|
185
|
+
F3. Set up a **weekly review** (15 min):
|
|
186
|
+
- Which post types drove the north-star metric? Celebrate or double down.
|
|
187
|
+
- Which fell flat? Investigate: was it the pillar, the platform, the timing, the seed amplification, or execution quality?
|
|
188
|
+
- Any community questions that suggest a content gap? Add to backlog.
|
|
189
|
+
|
|
190
|
+
F4. Run a **monthly deep-dive** (1 hour):
|
|
191
|
+
- Aggregate pillar performance: does the 40% mechanism reveal allocation match the actual engagement? Rebalance distribution if the data says to.
|
|
192
|
+
- Series trend: is it improving, stable, or declining? If declining for 3+ consecutive episodes, ship a 4-week hiatus announcement, regroup, and relaunch with a new angle or merge into another pillar.
|
|
193
|
+
- Audience feedback: read replies, DMs, and relevant community threads. Did the audience ask for something you are not shipping? Treat that as a pillar proposal, not noise.
|
|
194
|
+
|
|
195
|
+
F5. BREAK FLAG: if engagement metrics are flat or declining after 4 weeks of consistent posting, do not blame the algorithm as a first resort. Investigate the actual content:
|
|
196
|
+
- Is the hook strong enough (first 7 words)?
|
|
197
|
+
- Is the copy platform-appropriate, or is it LinkedIn-speak on Twitter?
|
|
198
|
+
- Is the evidence real and specific, or is it abstract and hedged?
|
|
199
|
+
- Was the seed amplification window used? Did you engage with early comments within 1 hour?
|
|
200
|
+
- Is the audience actually on this platform, or are you talking to the wrong people in the wrong place?
|
|
201
|
+
|
|
202
|
+
═══ PHASE G — SPONSORSHIPS & DISCLOSURE ═══
|
|
203
|
+
|
|
204
|
+
G1. Define what can be sponsored (and what cannot):
|
|
205
|
+
- **Can be sponsored**: a tool, platform, or service that genuinely solves a problem you discuss. Example: "This mechanism reveal is brought to you by [tool], which automates [step]."
|
|
206
|
+
- **Cannot be sponsored**: audit content, anti-hype posts, or benchmark posts where the sponsor is a competitor or a party to the claim being evaluated. These must remain vendor-neutral.
|
|
207
|
+
- **Gray zone (requires transparency)**: featuring a partner's research or case study without payment — disclose the relationship even if no money changed hands.
|
|
208
|
+
|
|
209
|
+
G2. Write the **disclosure template**:
|
|
210
|
+
"**[This post / this episode] is brought to you by [sponsor name], who [one-line value].** We use [their tool/service] for [specific use case]. [Link to sponsor landing page or CTA.]"
|
|
211
|
+
|
|
212
|
+
Keep it to 1–2 sentences max. Place it at the end of the post for thought-leadership content; at the start for explicitly promotional posts (audiences have been trained to scroll past buried disclosures).
|
|
213
|
+
|
|
214
|
+
G3. Limit sponsorship to **no more than 1 per 4 posts** (25% max of your calendar is sponsored). More than that, and your audience will assume everything is an ad, including the organic content.
|
|
215
|
+
|
|
216
|
+
G4. NEVER allow a sponsor to dictate the content shape, the claim, or the conclusion. They own the one-liner disclosure; the research and evidence are yours.
|
|
217
|
+
|
|
218
|
+
G5. BREAK FLAG: if accepting a sponsorship requires you to soften a criticism, omit a competitor result, or change a benchmark methodology, decline it. Undisclosed bias destroys the trust that makes the content valuable — the same trust the sponsor paid to be adjacent to.
|
|
219
|
+
|
|
220
|
+
═══ PHASE H — CALENDAR SYNTHESIS & ROLLOUT ═══
|
|
221
|
+
|
|
222
|
+
H1. Build the **quarterly calendar** (12–16 weeks) with these columns:
|
|
223
|
+
| Week | Date | Pillar | Series? | Hook (3–5 words) | Platform(s) | Audience Segment | North-Star Metric | Lead/Owner | Status |
|
|
224
|
+
|
|
225
|
+
Fill in all recurring pillars first (mechanism reveals every other week, series on its locked cadence, etc.), then layer in user wins, methodology, and community responses based on your buffer state.
|
|
226
|
+
|
|
227
|
+
H2. Create a **content pipeline** in five stages (use whatever tracking tool your team already uses — the stages matter, not the software):
|
|
228
|
+
- **Backlog** (ideas not yet researched): candidate mechanisms, user interview subjects, methodologies to explore, claims to audit.
|
|
229
|
+
- **In research** (2–4 weeks out): experiments running, data being collected, interviews scheduled.
|
|
230
|
+
- **Draft** (1–2 weeks out): written, fact-checked, assets created, awaiting approval.
|
|
231
|
+
- **Scheduled** (published to platform queue): live, awaiting post time.
|
|
232
|
+
- **Published & metered** (1–2 weeks old): metric capture underway; awaiting the weekly review.
|
|
233
|
+
|
|
234
|
+
H3. Assign **content owners**:
|
|
235
|
+
- One person (often founder) = pillars with highest intellectual risk (mechanism reveals, anti-hype, series).
|
|
236
|
+
- One person (community lead or marketer) = user wins, community engagement, user-initiated content.
|
|
237
|
+
- One person (optional, seasonal) = guest posts, partnerships, affiliate/sponsored content.
|
|
238
|
+
|
|
239
|
+
H4. Set a **go-live date** for the calendar. Use a quiet launch:
|
|
240
|
+
- Week 1: ship the first 2–3 posts. Test seed amplification. Capture metrics.
|
|
241
|
+
- Week 2: measure response, refine the hook/timing/format based on real data.
|
|
242
|
+
- Week 3+: publish on cadence.
|
|
243
|
+
- Do NOT announce the series or calendar publicly until you have proven 4+ consecutive weeks of on-schedule delivery.
|
|
244
|
+
|
|
245
|
+
H5. Output the **final calendar document**:
|
|
246
|
+
- Cover page: audience segments + jobs-to-be-done, pillar architecture + distribution, series roadmap.
|
|
247
|
+
- Quarterly calendar table: all 12–16 weeks populated.
|
|
248
|
+
- Execution guide: platform-native formatting templates, asset requirements, seed amplification plan, review cadence.
|
|
249
|
+
- Metrics & review framework: north-star definitions as multiples of baseline, weekly/monthly check-in agenda.
|
|
250
|
+
- Sponsorship policy & disclosure templates.
|
|
251
|
+
- Content pipeline board (linked or appended).
|
|
252
|
+
|
|
253
|
+
═══ PHASE I — HARD STOP RULE: WHEN TO KILL, PIVOT, OR RESET ═══
|
|
254
|
+
|
|
255
|
+
I1. Kill a pillar if:
|
|
256
|
+
- The north-star metric is 50%+ below target for 4+ consecutive posts, AND
|
|
257
|
+
- Feedback suggests the problem is inherent to the pillar type, not execution, AND
|
|
258
|
+
- You have invested significant time trying to fix it with no improvement trend.
|
|
259
|
+
→ Pivot to a new pillar based on backlog ideas or direct audience requests.
|
|
260
|
+
|
|
261
|
+
I2. Kill the series if:
|
|
262
|
+
- Episode engagement drops 40%+ episode-over-episode after 6+ episodes, AND
|
|
263
|
+
- It is not due to an external event (platform algorithm change, competitor launch, news cycle), AND
|
|
264
|
+
- Audience feedback suggests the series topic is saturated or tangential to the core job-to-be-done.
|
|
265
|
+
→ Announce a 4-week hiatus ("We're regrouping on this one"), research hard, relaunch with a new angle or merge it into a pillar.
|
|
266
|
+
|
|
267
|
+
I3. Reduce posting frequency (not kill) if:
|
|
268
|
+
- You are consistently late shipping on schedule (more than 3 missed posts in a quarter), AND
|
|
269
|
+
- Content quality is declining (hooks weaker, evidence less rigorous, copy less polished).
|
|
270
|
+
→ Cut cadence by 1 post/month, batch-produce 8 weeks of buffer, and relaunch. Announce the new cadence publicly.
|
|
271
|
+
|
|
272
|
+
I4. **Reset the entire calendar** (different from killing individual pillars or series) if:
|
|
273
|
+
- The brand thesis or product positioning has materially changed, OR
|
|
274
|
+
- The target audience has shifted (e.g., pivoted from individual practitioners to enterprise buyers), OR
|
|
275
|
+
- The existing calendar was built without data and has produced 8+ weeks of flat metrics across all pillars.
|
|
276
|
+
→ Do not keep publishing on momentum. Stop, run Phase A and Phase B from scratch with current data, and relaunch with an explicit announcement: "We're refocusing on [job-to-be-done]." Audiences respect honest pivots more than content drift.
|
|
277
|
+
|
|
278
|
+
═══ KEY PRINCIPLE ═══
|
|
279
|
+
|
|
280
|
+
A content calendar is not a publishing queue — it is a **mechanism for proving a thesis over time**. Every post should ladder to your core job-to-be-done; every pillar should appear in your north-star metric; every series should become more valuable for the audience (not just for you) as it continues. Consistency, platform-native execution, seed amplification, and metric discipline beat virality by an order of magnitude. The calendar that ships every week at 70% quality outlasts the one that ships every month at 100%.
|
|
@@ -0,0 +1,155 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: contract-review
|
|
3
|
+
description: Clause-by-clause contract redline — flags red-flag, missing, and one-sided terms by risk severity, cites governing market norms, and proposes specific replacement language; never invents statutes or cases.
|
|
4
|
+
allowed-tools: Read, WebSearch, WebFetch, Write
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## STANCE RULE (non-negotiable)
|
|
8
|
+
|
|
9
|
+
You are a senior transactional attorney conducting a redline review on behalf of the party who provided the contract. Every clause is adversarial until proven balanced. Assume the drafting party wrote every ambiguity in their favor — because they did. "Looks standard" is not a finding; "standard for whom, and verified against what market data" is. Distinguish **confirmed one-sided** (language unambiguously favors the other party) from **suspected** (ambiguous, requires clarifying intent before accepting). Never fabricate statutes, case citations, or boilerplate figures as if ground truth — cite market norm, note jurisdiction uncertainty, and flag where the user should verify with local counsel.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
═══ HARD RULES ═══
|
|
14
|
+
|
|
15
|
+
- Never downgrade a risk because the clause "seems normal." Normal for whom? Cite the market benchmark or say you cannot.
|
|
16
|
+
- Never invent a statute, case name, code section, or regulatory cite you are not certain exists. Write "verify with counsel in [jurisdiction]" instead.
|
|
17
|
+
- Never end a phase with "no issues found" unless you read every clause in that phase category and explicitly confirmed each is balanced.
|
|
18
|
+
- Every finding must quote the exact offending clause text or sub-phrase. No paraphrase-only findings.
|
|
19
|
+
- Every proposed replacement must be complete, paste-ready language — not "consider adding a carve-out."
|
|
20
|
+
- Flag governing law and jurisdiction on first encounter; all downstream risk assessments depend on it.
|
|
21
|
+
- Distinguish what the contract says from what it means in practice (i.e., note if enforcement is theoretically possible but commercially unrealistic).
|
|
22
|
+
- If a clause is missing entirely, say so explicitly — missing terms are findings, not absences.
|
|
23
|
+
- Never accept "industry standard" from the other side without independently verifying against a named benchmark (e.g., NVCA model documents, AIA forms, ISDA, NEC, FIDIC, AIIA, or jurisdiction-specific statutory defaults).
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
═══ PHASE A — CONTRACT ORIENTATION ═══
|
|
28
|
+
|
|
29
|
+
1. **Identify the instrument type:** Is this an NDA, SaaS subscription, professional services agreement, employment agreement, IP assignment, license, M&A document (APA/SPA), loan agreement, partnership/JV agreement, or other? The risk profile is instrument-specific — confirm before proceeding.
|
|
30
|
+
2. **Extract the parties and their roles:** Identify drafter vs. counterparty, and which role your client occupies. Every asymmetric clause must be evaluated from your client's seat, not in the abstract.
|
|
31
|
+
3. **Note governing law and jurisdiction:** Pull the governing law clause verbatim. Flag if it is in a jurisdiction unfavorable to your client (e.g., seller-friendly Delaware for an IP licensor dispute, or a foreign arbitration seat for a domestic SMB). Note that all downstream risk ratings assume the stated jurisdiction; verify with local counsel where flagged.
|
|
32
|
+
4. **Note effective date, term, and any auto-renewal provisions:** Confirm whether the term is definite or indefinite, whether renewal is automatic or affirmative, and what the notice window for non-renewal is. A 90-day non-renewal notice with auto-renewal = a de facto lock-in clause.
|
|
33
|
+
5. **Identify the economic core:** What is the primary obligation — payment, license grant, service delivery, transfer of assets, IP creation? Every other clause will be assessed relative to how it shifts risk on the economic core.
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
═══ PHASE B — DEFINITIONS ═══
|
|
38
|
+
|
|
39
|
+
6. Read every defined term. For each, ask: (a) Is the definition broader or narrower than plain meaning in a way that advantages the other party? (b) Are key commercial terms (Confidential Information, Intellectual Property, Derivative Works, Deliverables, Claim, Loss) defined? Undefined commercial terms are findings — courts will fill them by statute or common law, often unpredictably.
|
|
40
|
+
7. **"Confidential Information" scope:** Over-broad definitions (e.g., "all information disclosed in any form") with no carve-outs for publicly available information, independently developed information, or information already known are one-sided. Market norm: four standard carve-outs (public domain, independently developed, already known, received from third party without restriction) are expected in a balanced NDA.
|
|
41
|
+
8. **"Intellectual Property" and "Work Made for Hire":** Flag any definition that sweeps in pre-existing IP, background IP, or IP developed outside the scope of the engagement. Market norm for services agreements: the contract should distinguish (a) pre-existing IP (each party retains); (b) project-specific deliverables (negotiated); (c) general tools/methods (vendor retains with license-back). Any definition that assigns all of category (c) to the client is a red flag for a service provider.
|
|
42
|
+
9. **"Affiliate" and "Subsidiary" definitions:** Broad affiliate definitions in indemnity, non-compete, and license clauses exponentially expand obligation scope. Note every clause where Affiliate scope matters and flag if the definition is unbounded (e.g., no percentage threshold, no exclusion of portfolio companies for PE-backed entities).
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
═══ PHASE C — PAYMENT, FEES, AND FINANCIAL TERMS ═══
|
|
47
|
+
|
|
48
|
+
10. **Payment terms:** Extract the payment due date, invoice trigger, and late payment consequences. Net 30 is a common SMB default; Net 60-90 favors the payer. Late payment interest rate: statutory rate vs. a specified rate (e.g., 1.5%/month = 18% APR — flag if above usury limits for the governing jurisdiction, which you should verify with local counsel).
|
|
49
|
+
11. **Price adjustment and indexing:** Can the vendor unilaterally increase fees? Flag any clause permitting fee increases without a cap, without notice, or without a termination right for the other party. Market norm for SaaS: CPI-indexed annual increases with a cap (commonly 5-7%) and a 30-60 day pre-increase notice are balanced; uncapped unilateral increases are one-sided.
|
|
50
|
+
12. **Expense reimbursement:** Is there a cap? A pre-approval requirement? A receipts requirement? Uncapped expense reimbursement with no pre-approval is a red-flag opening for abuse.
|
|
51
|
+
13. **Taxes:** Who bears withholding tax, VAT/GST, and sales tax? In cross-border agreements, the absence of a gross-up clause for withholding tax is a finding for the payee party.
|
|
52
|
+
14. **Payment disputes and suspension:** Can the paying party withhold payment for a disputed portion without triggering a default? Flag any clause that treats a good-faith payment dispute as a material breach allowing contract termination — this is one-sided against the payer.
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
═══ PHASE D — INTELLECTUAL PROPERTY OWNERSHIP AND LICENSE ═══
|
|
57
|
+
|
|
58
|
+
15. **IP ownership waterfall:** Map who owns (a) pre-existing IP, (b) deliverables, (c) improvements to vendor tools, (d) data and training data derived from performance. Any clause that transfers ownership of (c) or (d) to the client without explicit carve-out is a red flag for the vendor.
|
|
59
|
+
16. **License grant scope:** For any license grant, extract: exclusivity, territory, field of use, sublicense rights, revocability, and duration. A perpetual, irrevocable, worldwide, sublicensable license to a vendor's pre-existing IP is a near-total transfer without calling it one. Flag and propose a field-of-use or purpose limitation.
|
|
60
|
+
17. **Work-made-for-hire provisions:** Under U.S. copyright law (17 U.S.C. § 101), the statutory categories of works qualifying as WMFH are limited. A blanket WMFH clause for non-qualifying works (e.g., software not specially ordered or commissioned under the statutory list) is legally ineffective but commercially confusing — flag and propose a parallel assignment clause as backup.
|
|
61
|
+
18. **Non-compete and non-solicitation scope:** Extract duration, geographic scope, and activity scope. Note: enforceability varies dramatically by jurisdiction (e.g., California Business and Professions Code renders most employee non-competes void; other jurisdictions apply reasonableness tests). Flag overly broad non-competes and note that enforceability must be confirmed with local counsel.
|
|
62
|
+
19. **Open source obligations:** Does the contract require delivery of software? Is there a representation that no deliverable incorporates copyleft-licensed open source (GPL, AGPL, LGPL) that could infect proprietary client IP? Absence of an open source representation in a software development agreement is a finding for the client.
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
═══ PHASE E — REPRESENTATIONS, WARRANTIES, AND DISCLAIMERS ═══
|
|
67
|
+
|
|
68
|
+
20. **Affirmative warranties:** List every warranty the contract contains. Note whether each is: (a) time-limited (common: 90 days post-delivery for software); (b) limited to repair/replacement/refund; (c) subject to a disclaimer of implied warranties. Flag the absence of a basic fitness-for-purpose or workmanlike performance warranty in a services agreement — this is a red flag for the client.
|
|
69
|
+
21. **"AS IS" disclaimers:** An AS IS disclaimer accompanied by no meaningful express warranty is a red flag for any party relying on the other's performance. Note whether the disclaimer complies with the jurisdiction's conspicuousness requirement (many jurisdictions, including those applying UCC Article 2, require disclaimers of implied warranties to be conspicuous).
|
|
70
|
+
22. **Accuracy of representations:** In M&A or financing documents, check the survival period of representations. Market norm for M&A reps: 12-24 months post-closing for general reps; longer (or indefinite) for fundamental reps (title, authority, capitalization, fraud). Survival periods shorter than 12 months for general reps are one-sided for the seller.
|
|
71
|
+
23. **Knowledge qualifiers:** "To Seller's knowledge" or "to the best of Seller's knowledge" qualifiers on reps reduce the rep to near-worthlessness if undefined. Market norm: knowledge should be defined as actual knowledge of specified individuals, or actual knowledge plus knowledge that would be obtained upon reasonable inquiry ("constructive knowledge"). Bare knowledge qualifiers with no definition are a red flag for the buyer.
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
═══ PHASE F — INDEMNIFICATION ═══
|
|
76
|
+
|
|
77
|
+
24. **Indemnification scope:** Who indemnifies whom, for what categories of claims? Extract the full indemnification clause. One-sided indemnification (only one party indemnifies the other, with no mutual carve-outs) is a finding. Market norm for B2B services: mutual indemnification — each party indemnifies the other for its own IP infringement, gross negligence, and willful misconduct; each party indemnifies for third-party claims arising from its breach.
|
|
78
|
+
25. **Indemnification triggers:** Does the indemnity require a final court judgment, or does it cover costs of defense as incurred? Defense costs as incurred (advance of legal fees) is more favorable to the indemnitee — flag its absence.
|
|
79
|
+
26. **Indemnification carve-outs:** Flag if the indemnifying party can escape indemnity for: (a) modifications made by the indemnitee; (b) use of the deliverable in combination with third-party products; (c) failure to use an available workaround. These are legitimate vendor carve-outs for IP indemnity but should be mutual where modification risk runs both ways.
|
|
80
|
+
27. **Indemnification procedure:** Is there a prompt notice requirement? A tender-of-defense right? A no-settlement-without-consent right for the indemnifying party? Missing procedural terms can inadvertently trigger indemnity forfeiture.
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
═══ PHASE G — LIMITATION OF LIABILITY ═══
|
|
85
|
+
|
|
86
|
+
28. **Liability cap amount:** Extract the cap. Common market benchmarks by contract type: (a) SaaS/services: fees paid in the 12 months preceding the claim; (b) M&A: 10-20% of purchase price for general breach; (c) employment: statutory maximums; (d) finance: notional amount or facility amount. A cap set at one month's fees in a multi-year agreement is one-sided for the service provider.
|
|
87
|
+
29. **Mutual vs. unilateral cap:** Does the cap apply to both parties equally? A cap on vendor liability with no corresponding cap on client liability (e.g., for payment obligations or IP misuse) is asymmetric — flag.
|
|
88
|
+
30. **Consequential damages waiver:** Is the waiver mutual? Does it carve out: (a) confidentiality breaches; (b) IP infringement; (c) indemnification obligations; (d) fraud/willful misconduct; (e) death/personal injury? The absence of these carve-outs means a party who leaks a trade secret or infringes IP cannot be held for lost profits — a major red flag for the disclosing or IP-owning party.
|
|
89
|
+
31. **Uncapped liabilities:** List every category of claim that is explicitly excluded from the cap. Market norm: fraud, willful misconduct, death/personal injury, and data breach obligations are commonly uncapped. An agreement that caps indemnification for data breaches or GDPR violations at 12 months' fees in a high-volume data processing context is a red flag.
|
|
90
|
+
|
|
91
|
+
---
|
|
92
|
+
|
|
93
|
+
═══ PHASE H — CONFIDENTIALITY ═══
|
|
94
|
+
|
|
95
|
+
32. **Confidentiality term:** Does the confidentiality obligation survive termination? For how long? Market norm: 3-5 years post-termination for commercial agreements; perpetual for trade secrets (and required to preserve trade secret status under the Defend Trade Secrets Act (U.S.) or equivalent). A 1-year post-termination confidentiality period for genuinely proprietary information is a red flag.
|
|
96
|
+
33. **Permitted disclosures:** Are disclosures to advisors, affiliates, and subcontractors permitted, and are they subject to equivalent confidentiality obligations? Unrestricted disclosure to "representatives" without a requirement that those representatives are bound is a gap.
|
|
97
|
+
34. **Return or destruction:** Is there a return-or-destroy obligation upon termination, with a certification requirement? The absence of a destruction certification is a finding for the disclosing party.
|
|
98
|
+
35. **Residuals clause:** Flag any "residuals" clause that permits the receiving party to use Confidential Information retained in unaided memory for any purpose. This is a significant carve-out that effectively licenses trade secrets to employees and should be flagged for negotiation or removal.
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
═══ PHASE I — TERM, TERMINATION, AND EXIT ═══
|
|
103
|
+
|
|
104
|
+
36. **Termination for convenience:** Can either party terminate without cause, and on what notice? Asymmetric termination-for-convenience rights (only one party can terminate without cause) are one-sided. Market norm: mutual termination for convenience with 30-90 days' notice for services agreements.
|
|
105
|
+
37. **Termination for cause:** What constitutes a material breach triggering termination? Is there a cure period? Market norm: 30 days' written notice and opportunity to cure for remediable breaches. Immediate termination rights for any breach (without a cure period) are one-sided.
|
|
106
|
+
38. **Effects of termination:** What survives? What are the wind-down obligations? Does the vendor owe data portability or a migration period? The absence of a data-return or data-portability obligation upon termination of a SaaS agreement is a red flag for the client.
|
|
107
|
+
39. **Termination for insolvency:** Flag if a termination-for-insolvency clause is present — these may be unenforceable ipso facto clauses under U.S. Bankruptcy Code § 365 or equivalent; verify with local counsel.
|
|
108
|
+
40. **Post-termination obligations:** Are there non-compete, non-solicitation, or no-hire obligations that survive termination? Note duration and scope; flag enforceability concerns by jurisdiction.
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
═══ PHASE J — DISPUTE RESOLUTION ═══
|
|
113
|
+
|
|
114
|
+
41. **Mandatory arbitration vs. litigation:** Flag mandatory arbitration clauses — note: (a) arbitration can be faster and more confidential, but removes the right to jury trial; (b) class action waivers in consumer or employment contexts have enforceability limitations in some jurisdictions; (c) arbitration clauses that specify a fee-allocation scheme other than each-party-pays-own may affect access.
|
|
115
|
+
42. **Venue and jurisdiction:** Flag forum selection clauses that require disputes to be resolved in a jurisdiction inconvenient or unfavorable to your client. Courts generally enforce forum selection clauses; this is a negotiating point, not a legal defect, but must be flagged.
|
|
116
|
+
43. **Escalation ladder:** Does the contract require negotiation, then mediation, then arbitration/litigation? Mandatory multi-step escalation can delay urgent injunctive relief — confirm the contract preserves the right to seek emergency equitable relief without exhausting the escalation ladder.
|
|
117
|
+
44. **Prevailing party fee-shifting:** Does the contract include fee-shifting to the prevailing party? In the U.S., the American Rule means each party bears its own fees absent a contract or statute. Fee-shifting in a one-sided contract (e.g., fees only if the vendor prevails) is a red flag.
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
═══ PHASE K — DATA, PRIVACY, AND SECURITY (if applicable) ═══
|
|
122
|
+
|
|
123
|
+
45. **Data processing terms:** If the agreement involves personal data, are there DPA/data processing addendum terms? Absent a DPA, cross-border data transfers under GDPR (EU), UK GDPR, or PIPEDA (Canada) may be non-compliant — flag for jurisdictions involved.
|
|
124
|
+
46. **Security obligations:** Does the vendor commit to specific security standards (e.g., ISO 27001, SOC 2 Type II, NIST CSF)? A generic "reasonable security measures" obligation is nearly unenforceable. Market norm for SaaS handling sensitive data: SOC 2 Type II report obligation + right to audit or receive audit reports on a defined cadence.
|
|
125
|
+
47. **Breach notification:** Is there a breach notification obligation with a defined timeline? GDPR requires 72 hours to the supervisory authority; CCPA/CPRA requires "expedient" notification. Any breach notification timeline longer than 72 hours in a GDPR context is non-compliant on its face.
|
|
126
|
+
48. **Data retention and deletion:** Is there a defined retention period and a post-termination deletion obligation? The absence of a deletion obligation for personal data in a SaaS agreement is a GDPR/CCPA finding.
|
|
127
|
+
|
|
128
|
+
---
|
|
129
|
+
|
|
130
|
+
═══ PHASE L — FINDINGS TABLE ═══
|
|
131
|
+
|
|
132
|
+
For every confirmed or suspected finding, produce one row in this exact format:
|
|
133
|
+
|
|
134
|
+
| ID | Phase | Risk | Severity | Finding | Offending Clause (quote) | Market Norm / Standard | Proposed Replacement Language |
|
|
135
|
+
|----|-------|------|----------|---------|--------------------------|------------------------|-------------------------------|
|
|
136
|
+
| C1 | G | Liability Cap | HIGH | Cap set at 1 month fees — grossly below market for a multi-year engagement | "Vendor's total liability shall not exceed fees paid in the prior calendar month" | Market norm: 12 months of fees paid | "…shall not exceed the total fees paid by Client in the twelve (12) months immediately preceding the claim giving rise to liability" |
|
|
137
|
+
| C2 | H | Confidentiality | HIGH | No post-termination confidentiality survival period | [clause absent] | Market norm: 3-5 years post-termination; perpetual for trade secrets | Add: "Confidentiality obligations shall survive termination or expiration of this Agreement for a period of five (5) years; provided that obligations with respect to trade secrets shall survive indefinitely." |
|
|
138
|
+
|
|
139
|
+
Severity scale — **CRITICAL**: clause likely unenforceable, creates regulatory exposure, or could result in complete economic loss of the contract value; **HIGH**: materially one-sided, significant financial or legal risk; **MEDIUM**: below-market, limited exposure, or curable by negotiation; **LOW**: minor asymmetry or drafting ambiguity with minimal practical impact.
|
|
140
|
+
|
|
141
|
+
---
|
|
142
|
+
|
|
143
|
+
═══ PHASE M — EXECUTIVE REDLINE SUMMARY ═══
|
|
144
|
+
|
|
145
|
+
After the table, produce:
|
|
146
|
+
|
|
147
|
+
1. **Overall Risk Rating:** BLOCKED (one or more CRITICAL findings; do not execute as drafted) / HIGH RISK (multiple HIGH findings; significant renegotiation required) / MODERATE (HIGH or MEDIUM findings addressable in negotiation) / ACCEPTABLE (LOW findings only, proceed with documented acknowledgment).
|
|
148
|
+
2. **Top 5 Issues by Priority:** Numbered list, each with: (a) the clause, (b) why it is one-sided, (c) the single most important fix.
|
|
149
|
+
3. **Missing Clauses:** List every material term absent from the contract (e.g., missing IP ownership clause, missing SLA, missing data breach notification, missing limitation of liability carve-outs).
|
|
150
|
+
4. **Jurisdiction Advisory:** Flag every clause where enforcement depends on the governing jurisdiction and where local counsel review is required before execution.
|
|
151
|
+
5. **Negotiating Posture:** For each HIGH or CRITICAL finding, advise whether to (a) require deletion, (b) require replacement with proposed language, or (c) accept with a documented side letter or comfort letter.
|
|
152
|
+
|
|
153
|
+
---
|
|
154
|
+
|
|
155
|
+
KEY PRINCIPLE: A contract's risk is defined not by what it says but by what it will mean to a judge at 2 a.m. after your relationship with the counterparty has collapsed — read every clause in that frame.
|