Capabilities

A skill that classifies an engagement into one of 4K's six types (CC, Build, StaffAug, T&M, Fixed Fee, Pixie). Used downstream by other skills for routing, risk-tagging, report templating. Addresses the audit observation that bad engagements cluster in {Fixed Fee, T&M with start/end dates} while CC and Staff Aug retainers are mostly positive — today the classification is implicit in people's heads, and the risk-correlation pattern lives only in Beto's experience.

The implicit, in-head classification step that today gates risk-tagging, report routing, and engagement-type-aware analysis.

Standalone Claude Teams skill. SKILL.md describes the six types with distinguishing characteristics, plus disambiguation rules between similar pairs (T&M vs Fixed Fee, CC vs Staff Aug). Skill takes engagement description as input (or fetches it from ClickUp/Notion via MCP at invocation), returns classification + confidence + rationale. No external API beyond optional context fetch.

Engagement description provided at invocation, or pulled from Notion engagement DB / ClickUp parent-task description via official MCPs.

• The actual rules 4K uses to distinguish the six types — especially nuance between Fixed Fee vs Build for a project with a defined deliverable
• Example engagements that fit each classification cleanly — 2–3 per type as reference cases
• What "Pixie" is — named in the discovery doc but not described
• Beto's risk-correlation rule encoded as metadata on the classification output so downstream tools (#26) can consume it

• Classification may not be cleanly mutually exclusive (e.g., engagement that's mostly StaffAug with a CC component). Need a rule for hybrid cases or "primary type + secondary"
• Classifier produces a label but doesn't enforce or surface implications. Downstream skills need to consume the label correctly

A skill that takes meeting notes or a transcript and suggests a 1–10 sentiment score with rationale. Replaces Shanice's manual ~15-minutes-per-scoring workflow with a 2-minute review-and-adjust pattern. Cadence today is biweekly / monthly / quarterly per engagement.

Shanice's manual cold-start scoring step. The skill drafts; she adjusts. Replaces ~15 min/entry with ~2 min/entry across all her tracked engagements.

Skill takes meeting notes (pasted into chat, or fetched from a known Notion/Drive location) and applies a scoring rubric we co-design with Shanice. Output: score + rationale + flagged concerns. Shanice reviews and adjusts; her final value is what gets written down. Skill never auto-writes the final score.

Notes supplied at invocation. No historical synthesis needed. Final adjusted score writes to Shanice's existing destination (her sheet or the Notion client-success scoring DB).

• Shanice's actual scoring rubric. The discovery doc says "gut-reaction 1–10" — but she has implicit weights (client tone, deliverable confidence, relationship signals, escalation likelihood). The skill is only as good as the rubric.
• 5–10 example past 1:1 notes + the scores Shanice gave them — for calibration
• The destination for the final adjusted score

• Risk of false confidence — a "suggested score" can anchor Shanice's adjustment, undermining her gut-reaction value. Design to surface concerns first, score second.
• If input note is light on detail, skill produces low-confidence output. Need a "not enough to score" path rather than forcing a number.
• Sentiment-from-voice (Zoom transcripts) is richer — but that's blocked by 4K's 24-hour Zoom retention policy interpretation (#31).

Structured capture of Si's 1–2 line post-opportunity entries. Currently free-form; this version forces a tagged schema so the corpus becomes queryable later. Capture-only at v0. The retrieval/learning loop depends on the CKA substrate (#28, Tier 1 foundation). Si's broader "all-logo data wish" is to see cross-engagement patterns from this corpus, which only the substrate enables.

The free-form one-off note Si writes today after each opportunity closes. Not the writing itself — the unstructured-and-unqueryable nature of it.

Skill prompts Si through structured fields after an opportunity closes: engagement type, win/loss reason category, competitor named (if any), deal size band, decision-maker role, time-to-close, key factors. Writes to a Notion database or structured Drive file with a fixed schema.

Si supplies the content; skill structures it.

• The schema fields themselves — what does Si actually care about capturing?
• Destination: Notion DB (queryable, schema enforced) or structured Drive markdown (simpler). Notion is the better choice if she's already in Notion.
• Backfill question — 6–8 months of existing entries: migrate or start fresh?

• Capture without retrieval has limited immediate value. Si already captures freeform notes; this just structures them. Real value comes when the substrate makes the corpus searchable for SiBorg's estimation flow. Worth flagging to 4K so expectations match.
• Backfill requires Si's interpretation of each — slow human work. Probably skip backfill; start fresh going forward.

EOS Vision/Traction Organizer workflow encoded as a skill. Walks the facilitator through each VTO section, prompts for inputs, drafts the resulting doc. Addresses 4K's existing VTO space.

The unfacilitated VTO-update step (manually walking through each EOS section, drafting the consolidated doc). Skill walks the facilitator through it.

Workflow-as-skill pattern (no external data dependencies). SKILL.md encodes EOS standard VTO sections (Vision: Core Values, Core Focus, 10-Year Target, Marketing Strategy, 3-Year Picture; Traction: 1-Year Plan, Quarterly Rocks, Issues List). Walks the user through each section with prompts, then drafts the consolidated VTO doc in 4K's Notion VTO space (or Drive).

Inputs from the facilitator's session; skill structures and drafts. Current VTO content (for incremental updates) comes from Notion via official MCP.

• 4K's existing VTO document format and storage location (likely Notion VTO space)
• Whether they follow strict EOS conventions or have customized the format
• Cadence — quarterly? Annual?

• EOS VTO is well-standardized but 4K may have drifted from the standard over time. Need to match their actual format, not the textbook.
• Small and self-contained — limited risk.

Given an engagement profile (role mix, duration, type), surfaces applicable rate card from Drive. Addresses SiBorg's current manual workflow.

Si's manual "find the right rate card by digging through past proposals" step. The substrate-backed version (#27, Moderate) is richer; this version is a direct Drive lookup that ships independently.

Skill takes engagement parameters as input, searches Drive (via Workspace MCP) for rate card documents in a known folder, extracts the relevant rates, presents them. If 4K has a single canonical rate card per period, this becomes "fetch and display." If they have variants (per-role, per-engagement-type), the skill matches the right one.

Drive search via Google Workspace MCP. Specifically targets a known rate-card folder.

• Where exactly do rate cards live in 4K's Drive? Critical missing piece. Trivial if structured folder with predictable naming; much harder if scattered or embedded in old proposals.
• Current rate cards (snapshot at engagement start)
• How rates vary — by role? engagement type? client tier? time period?
• Nuances (volume discounts, retainer-rate-vs-T&M rate, location-based rates)

• If rate cards are scattered or embedded in proposal docs, Drive search becomes fuzzy and unreliable. Would need either 4K consolidation or substrate-backed search.
• Rate cards change over time. Skill needs to surface the applicable card based on engagement date, not just the latest.

Drafts Beto's pre-L10 Slack post from current scorecard data. Pulls metrics, formats per Beto's framing pattern, posts (with approval) to the relevant channel ahead of Tuesday Delivery L10 and Wednesday Leadership L10.

Could ship as Skill-only (Beto invokes on-demand) or as Skill + Managed Agent (agent auto-drafts ahead of each L10 and posts the draft for Beto's approval). 4K preference.

Beto's manual "find the week's scorecard rows, summarize the relevant slice, draft the Slack post" step before each L10.

Skill (or scheduled Managed Agent invoking the skill) fetches the week's scorecard metrics from Notion via official MCP, formats them per Beto's framing template, presents the draft for review before posting to Slack.

• Notion scorecards database via official MCP (or via #24 Build 3 output once that's built)
• Slack channel ID for the L10-prep channel

• Beto's current framing template — exact phrasing, emphasis
• Which Notion DB rows feed each L10 (Tuesday Delivery vs Wednesday Leadership)
• The destination Slack channels
• Whether the post includes commentary or just numbers

• If scorecard numbers aren't yet updated when the skill runs, the post is wrong. Need a check or sequencing rule (only runs after #24 completes its update).
• Beto's framing has implicit judgment — editorial selection probably stays with Beto.

Produces the weekly Projects Roundtable agenda. Pulls current red/yellow status across projects, flags engagements that have shifted state since last week, lists items for discussion. Beto's alarm threshold: "When I'm really alarmed, it's when there's a really unhappy client on a meeting" — calibration target for what makes the cut.

Mostly a Skill, but state-snapshot persistence (last week's red/yellow values for state-change detection) is a tiny supporting component — likely an S3 prefix or a small DynamoDB table. Doesn't rise to a Custom App but adds small persistence-layer concern.

The manual "review red/yellow status across all projects, assemble the agenda" step Beto does today before each Roundtable.

Scheduled or on-demand skill. Reads Notion engagement DB for current red/yellow status. Compares to last week's snapshot. Outputs formatted agenda: state changes (yellow→red, etc.), recurring red/yellow items, new engagements requiring discussion, suggested attendees per item. Optionally elevates "really unhappy client on an upcoming meeting" cases per Beto's alarm threshold.

• Notion engagement DB via official MCP
• Local cache of prior weeks' states (we persist — small S3 prefix or DDB table)
• Optionally: ClickUp ticket cadence signals to flag projects with no movement even if Notion status hasn't changed

• The specific Notion DB and field that holds red/yellow status
• The format Beto uses today for the Roundtable agenda
• Beto's "really unhappy client on a meeting" alarm criteria — what specific signals tip him off

• The "Notion engagement DB rots" problem — if red/yellow status isn't updated reliably, the agenda inherits stale data. Skill can flag "stale" (last-updated > N days) but can't fix the underlying rot. Most consequential limitation of the lightweight version — substrate-backed #26 handles it via recency-weighted reconciliation.

Given a Drive link to an SOW (or an engagement name that resolves to one), answers contractual questions in plain language: scope, term, payment terms, change-order procedure, notice requirements, termination, IP ownership.

The manual "open the PDF, ctrl-F, read the relevant section" workflow. Replaces "search across 900 places" for contractual answers.

Skill takes an SOW reference (link or engagement name), fetches the document via Google Workspace MCP (Drive read), and answers questions via structured prompt extraction. Optionally caches extracted terms per SOW so re-queries are fast. Output is read-only.

• Google Drive via Workspace MCP — a known contracts/SOWs folder
• Engagement name → SOW filename resolution via either naming convention or a small mapping table

• Where SOWs actually live in Drive — folder structure, naming convention, current vs archived
• Whether SOWs are PDFs, Google Docs, or a mix
• Whether amendments / change orders are stored alongside the original SOW
• Common questions 4K's team actually asks of SOWs — informs the skill's prompt design

• PDF extraction quality varies. Most modern SOWs are text-PDF; some are scanned (OCR required).
• Amendments modify the SOW. If they're not linked to the parent, skill may miss material changes. Flag in output: "Based on SOW dated YYYY-MM-DD. Check for amendments."
• Interpretation questions ("does this scope cover X?") vs term-lookup questions. Skill should answer the clear ones, decline on judgment calls.

Formalize Joanna's existing Claude prototype for Harvest export aggregation. Add format references, multi-ticket-entry disambiguation rule, parameterize per-engagement, make it shareable across all PMs. Quantified pain: monthly reports take 30–60 min; daily reports take 15 min/day.

Joanna's manual cleanup step on multi-ticket entries (engineers logging multiple tickets in one Harvest entry); the per-PM duplication where each PM rebuilds the same aggregation logic in their own setup.

Take Joanna's current prompt/workflow as starting point. Restructure as proper SKILL.md with clear trigger description, input parameters (engagement, date range, cadence), workflow steps (list_users → resolve user IDs → call our Harvest connector's runreport tool → apply disambiguation rule → format per template). Format references as separate files in references/ (daily, weekly, monthly templates).

• Harvest via our existing connector — /v2/time_entries (with from, to, user_id, project_id filters) and /v2/users for name→ID resolution
• Per-engagement project ID mapping (Harvest project → 4K engagement)

• Joanna's current prompt or workflow — starting point
• The multi-ticket disambiguation rule — when engineer logs 4 hours but lists 3 tickets, how does she allocate? Equal split? First-listed-gets-all? Worth asking explicitly.
• The three template formats (daily, monthly, quarterly) — get samples
• Whether other PMs (Fabi, Shanice) have their own variants — collect those too

• Harvest's API has nuance around retainer clamping and budget-vs-actuals — response shape changes by billing config. Verify we handle project types Joanna deals with.
• The multi-ticket case is the hardest part. If 4K doesn't have a deterministic rule (people eyeball it), we may need to surface ambiguity rather than fake a clean split.
• Generalizing for other PMs may surface edge cases Joanna's prototype never hit.

Same shape as #09, but for Shanice's quarterly burndown template currently saved in her Claude project.

The Stanford-specific saved-in-Claude template being usable only by Shanice. Formalization makes it shareable across PMs and parameterizable per engagement.

Same pattern as #09 — extract her existing template, restructure as proper skill, parameterize so other PMs can use it.

• Harvest (our connector) for actuals
• Likely also a Google Sheet that holds the burndown structure — confirm with Shanice

• The Stanford-engagement-specific template — how it computes burndown, what fields it tracks
• Whether Shanice's template is Stanford-specific or generalizable across other engagements
• Whether other engagements would use this skill or it's truly Stanford-specific

• Burndown computations are simple in concept but get messy with retainer rollover, change orders, scope adjustments. Need to know how Shanice handles those today.
• If template assumes Stanford-specific structure, generalizing isn't trivial.

Apply 4K's voice profile to drafts. Includes anti-AI audit (banned words, banned sentence patterns, banned opening templates) tuned to 4K's voice. Addresses voice consistency across authors and the general "AI-generated content sounds generic" problem.

Per-author voice drift in 4K's content output. Replaces "everyone writes in their own voice and hopes it's close to 4K's house style."

Run our existing writing-skill-generator skill (proven on WWP). The generator crawls 4K's published content (blog, case studies, public posts), extracts ~14 verbatim voice samples organized by function (how 4K opens an argument, makes a point, closes), and produces a 4k-writing skill with the embedded voice profile and anti-AI rules.

• 4K's website — public crawl. Blog, case studies, "about" pages.
• Optional: sample proposals if 4K wants proposal-specific voice (separate from blog voice)

• Which content sources to prioritize — most representative of 4K's voice
• Anti-AI sensitivities — words/phrases they hate, "consultant-speak" they avoid, brand-specific terminology
• Whether there's a designated voice owner who reviews the generated skill

• If 4K's published content has been ghost-written by multiple authors, the "voice" we extract may be inconsistent. Worth surfacing if we see it.
• Generator produces a skill with embedded samples — once generated, it's static until re-run. As voice evolves, re-run periodically.
• Anti-AI audit rules are calibrated to the voice we extract — missing a key dimension lets through content that doesn't feel 4K-y.

Helps Peke and Jade work through Harvest + the late-payment admin sheet on Mon/Thu cycles. Surfaces flagged invoices, drafts escalation language, formats outreach. This is the Tier-1 human-assisted version. #19 Build 4 automates this fully — decide whether to ship both or skip straight to automation.

Some of Peke/Jade's Mon/Thu manual cycle — the Harvest-report-pull and the sheet-scan steps that precede their actual outreach decision.

Skill takes today's date and engagement scope as input, queries Harvest for overdue invoices, cross-references the admin sheet (Sheets MCP) for prior contact history, drafts outreach language per invoice. Peke/Jade review and send.

• Harvest invoices via our existing connector (list_invoices tool, filtering state=open and computing days-overdue from due_date)
• Late-payment admin sheet via Google Sheets MCP
• Per-engagement PM-ownership lookup

• The current escalation language Peke/Jade use — drafts should match their tone
• The thresholds they apply today (gentle reminder at day 7, firmer at day 14, escalate to PM at day 21)
• The PM-ownership mapping per engagement
• Whether some clients have special terms (Net 60, retainer-only billing)

• Stopgap before #19 automates it fully. Worth deciding upfront whether to build this or skip straight to automation.
• If Net-terms vary by client and aren't captured in Harvest cleanly, "overdue" computation is wrong for some clients.
• Late-invoice handling has interpersonal nuance. The skill drafts; humans judge.

Configured per-client report templates running on Harvest + ClickUp ingestion. Variable cadence (daily / weekly / monthly / quarterly). Per-PM template variance preserved as configuration. Quantified pain: monthly reports take 30–60 minutes; daily reports take 15 minutes per day. Across PMs, this aggregates to many hours per week.

Skills + Managed Agent composition. On-demand reports = Skill invocations. Scheduled reports = Managed Agent invoking the right Skill per client per cadence. One Skill per template family + one Managed Agent that fires the right Skill per client per cadence.

Per-PM template variance isn't stylistic preference — it's that PMs have different skills, different client expectations, different reporting comfort levels. Template consolidation is a cultural problem, not a UX problem. Build accommodates variance rather than reforming it. Imposing uniform templates would likely meet PM resistance and reduce quality.

Manual Harvest-export cleanup (multi-ticket triple-checking). Per-PM template duplication for common operations (Harvest pull, formatting, aggregation). The export-paste-clean cycle as a recurring weekly/monthly task.

Skills (one per template) with per-client configs. Workflow per Skill: identify cadence and client → query Harvest for time entries → query ClickUp for ticket context (via official MCP or #25) → apply per-PM template → produce report. Multi-ticket-entry disambiguation rule encoded (from #09). For scheduled reports: a Managed Agent reads a config (which clients get which reports at which cadence), invokes the right Skill, delivers to the right destination.

• Harvest (our connector) — time entries
• ClickUp — ticket context. Via official MCP at first; #25 if rate limits become a constraint.

• Per-PM template formats — collect samples from Joanna, Fabi, Shanice, others. Identify what can be consolidated. Don't force uniformity.
• Multi-ticket disambiguation rule from #09
• ClickUp engagement-list scoping rule (Space-per-engagement, Folder-per-engagement, or List-tag-based)
• Cadence per client (which clients get daily vs monthly vs quarterly)
• Total reports-per-month aggregate volume across the portfolio — audit explicitly names this as a sizing follow-up that's not yet captured. Affects #25 build-or-skip decision (rate-limit pressure) and Managed Agent schedule design.

• ClickUp official MCP rate limits (50/24h free, 300/24h paid per user) may bottleneck high-volume report generation. ~50 reports/week could hit per-user cap. Mitigation: stagger generation, batch tickets per query, or build #25.
• Per-PM templates resist consolidation. Build accommodates variance.
• ClickUp data model richer than Asana — parent-task chains, dependencies, custom fields, priority labels. Reports need to surface the right context without overwhelming.

Reimplement SiBorg as a CKA-querying estimation skill on top of the Tier 1 substrate (#28). Win/loss memory migrates as tagged annotations. Comparable proposal retrieval. Rate card lookup. Harvest actuals from comparable past engagements (the feedback loop that doesn't exist today).

Under the new framing the substrate is Tier 1 (foundation, not finale), so SiBorg becomes a skill calling into existing substrate tools — not a build that requires building substrate first. Estimation logic is workflow-as-skill (8–15 hrs). Real risk lives in migration: Si has 6–8 months of accumulated win/loss texture to preserve. Mitigation: parallel-running validation with Si until she signs off the new SiBorg's output matches her existing texture.

• SiBorg's parallel ingestion pipeline for proposals, SOWs, rate cards, boilerplate, brand assets — collapses into the CKA
• Si's manual rate-card lookup from comparable past projects
• The estimation-without-actuals-feedback gap
• Free-form win/loss notes (replaced by tagged structured annotations from #03)

Skill that walks Si through the estimation flow. At each step, queries CKA for relevant context: similar past proposals, rate card history, Harvest actuals from comparable engagements. Win/loss annotations live in CKA as tagged metadata Si owns. Single-instance scoping enforced at Claude Teams project access level.

• CKA substrate (proposals, rate cards, win/loss annotations, Harvest actuals) — via #28
• 4K's Pipedrive (current pipeline context)
• Forecast write-back is dropped per research. Si keeps manual Forecast re-entry until Harvest replacement lands.

• Si's current SiBorg prompt / workflow as the starting point
• The 6–8 months of accumulated win/loss notes — for migration
• Si's rate-card-application rules
• Validation criteria — how Si knows when an estimate is "good"
• Permissioning model decision: Si-only, or Si plus engineering reviewers? Audit raises this. Confirm during scoping.

• Migration risk: Si's win/loss notes have implicit texture. Reimplementing may lose nuances developed over 6–8 months. Mitigation: parallel-running validation period until Si signs off.
• Single-instance scoping is a Claude Teams project-access decision, not code-level enforcement. If someone else gets project access, the boundary fails.
• If the substrate's comparable-proposal retrieval is weak at launch (it will be; improves over time), Si gets shallow comparables and estimation suffers. Iteration period needed.
• Forecast write-back staying manual is a known cost. Worth Si's explicit acknowledgment.

Redeploy our existing Pipedrive MCP connector (built for WWP — 8 tools, RunReport pattern, Lambda-deployed) with 4K's credentials and any custom-field mapping. 4K has ~65 active leads in Pipedrive (audit · tech stack reference).

No programmatic Pipedrive access for 4K's team today — anything pipeline-shaped requires opening the Pipedrive UI manually. Connector brings Pipedrive into the same surface as Harvest and ClickUp for skills and automations.

Take clients/frontier-clients-wwp/mcp-connectors/pipedrive/ as starting point. Replace 4K-specific values: API token (in Secrets Manager), API Gateway endpoint, custom-field schema if 4K's Pipedrive setup uses different fields. Deploy as new Lambda function in 4K's AWS environment.

• 4K's Pipedrive instance via REST v1 API (same version WWP uses)
• 4K's API token for a service account

• 4K's Pipedrive custom fields — what they use beyond standard. Often agencies add "service line," "engagement tier," "client size"
• Pipeline structure — stage names and their semantic meaning. WWP's stages won't match 4K's.
• Whether 4K's deal weighting toggles work the same way as WWP's

• Pipedrive's API v1 returns nested objects (person_id.value for actual IDs) — our connector handles this but 4K's data may surface edge cases WWP didn't.
• Pipedrive's rate limit is plan-tiered (30,000 tokens/day × plan multiplier × seats). Plenty for ad-hoc; could hit it with sustained automation.
• If 4K's data is messy (duplicate persons, orphaned deals), RunReport queries can produce confusing output. Worth a data-quality pass during onboarding.

Abstract our existing Harvest connector behind a TimeTrackingAdapter protocol so the eventual swap to Productive (or whatever 4K picks to replace Harvest) is configuration, not rewrite. Forcing function: Harvest is moving at 5× repricing; 4K probably off Harvest by end of year.

Harvest-specific hard-coded references throughout our connectors and downstream skills. Replaces them with protocol-driven calls so the eventual swap is config, not rewrite.

Internal refactor of our agent-harvest-connector Lambda. Define TimeTrackingAdapter Protocol with methods: list_users, list_projects, list_time_entries, list_invoices, list_allocations (planning data — Forecast's domain), etc. Move existing Harvest API code behind a HarvestAdapter class implementing the protocol.

Harvest API v2 (unchanged from current connector).

None for the refactor itself (it's our code). Need 4K's Harvest replacement decision before we write the second adapter (#30).

• The protocol design has to match what the replacement tool will offer, which we don't know yet. Best mitigation: design against Productive's API (most-likely replacement) as a sanity check.
• If we miss the Harvest sunset by even a few weeks, builds that hard-coded Harvest endpoints break suddenly. The refactor should land before downstream Harvest-touching builds, not after.

Net-new MCP connector for ClickUp following our two-tier MCP design pattern: a small number of dedicated mechanical tools for common queries (fast, no LLM cost) PLUS a runreport tool for open-ended queries (code-generation, AST validation, sandboxed execution). Matches Pipedrive, Harvest, GA connectors in our family.

Build proactively rather than only-as-fallback. Reasoning: ClickUp touches 7 items in our scope (#01, #06, #07, #22, #23, #26, #28); rate limits on the official MCP (50/24h free, 300/24h paid per user) are real; our pattern gives better ad-hoc query shape than official tool surface; read-only enforcement via ReadOnlyAdapterProxy; response normalization for token efficiency.

The ClickUp-MCP-rate-limit-bottleneck that would otherwise constrain #23 (Client Report Assistant). Additive capability, not a workflow replacement.

Follow the Pipedrive connector pattern. Adapter class wrapping ClickUp REST v2. Dedicated tools (mechanical, fast) for common queries: list_tasks_in_space, get_task_with_subtasks, list_comments, get_pipeline_summary. Plus a runreport tool that code-generates Python against the adapter, AST-validates, executes in sandbox, returns normalized result. Lambda + API Gateway deployment. ReadOnlyAdapterProxy with ALLOWED_TOOLS whitelist.

ClickUp REST v2 API. See research/clickup.md for full surface.

• ClickUp service account credentials (personal API token)
• Per-engagement hierarchy unit (from research open questions)
• ClickUp priority label scheme — audit names base → 1 → 2 → 3 → 4; confirm built-in 4-level priority with null state vs custom field. This connector's normalization layer needs to handle whichever model 4K actually uses
• Whether 4K confirms proactive build vs only-as-fallback

• ClickUp's data model has richer hierarchy than Pipedrive (Workspace → Space → Folder → List → Task → Subtask). Our connector handles that.
• ClickUp's custom-field types are richer than Asana's (~15 types). Normalization is more involved.
• If built as "only-if-needed," we may discover rate-limit pressure mid-engagement, forcing a late build. Proactive avoids this.

4K hasn't announced the replacement tool. Per research, Productive is the strongest candidate; Runn and Scoro are viable; if 4K picks something with a weaker API, the work doubles.

Build a new adapter implementing the TimeTrackingAdapter protocol (from #17) for whatever tool 4K picks. Replace Harvest references throughout the system. Validate against real data, dual-run for a window, cut over.

The Harvest dependency across all builds. The pluggable-layer (#17) makes this a swap, not a rewrite — but the swap itself is real work.

• Migration cutover. History import from Harvest into the replacement isn't our problem (4K owns that), but if the replacement doesn't carry 4K's historical data cleanly, downstream tools see a gap. Parallel-running window mitigates.

Monday-morning pipeline + activity briefing for 4K leadership. Pulls from Pipedrive and Harvest, delivers via Slack and/or email. Pattern proven on WWP.

The manual Monday "check pipeline + recent activity" review that leadership otherwise does by opening Pipedrive + Harvest + asking around.

Drop a job file in our frontier-agents Lambda platform (lambda_src/jobs/4k-weekly-briefing.md) with cron schedule, system prompt, MCP attachments (4K Pipedrive + Harvest connectors), delivery channels. Bootstrap script provisions the Managed Agent. EventBridge triggers it Monday mornings.

• 4K Pipedrive via our connector (deals, activities, pipeline summary; ~65 active leads)
• Harvest via our connector (last week's hours, engagement age)

• Which leadership members get the briefing (Elia, Beto, others?)
• Slack channel and/or email addresses for delivery
• The briefing format/template — what sections, what tone. WWP's is a starting point.
• Day-of-week and time (Monday 9am makes sense but confirm)

• WWP's known issue: Lambda timeout coupling can orphan Managed Agents sessions if the agent runs >15 min. Known defect with planned fix; deploy before 4K's job goes live.
• "Briefing fatigue" — if not actionable, leadership tunes out. Tune content based on first 2–3 weeks of feedback.

Full automation of late-invoice handling. Daily Harvest query → identify overdue → draft email to accounting inbox → Slack-escalate to PM at higher thresholds.

Peke and Jade's full Mon/Thu manual cycle. Replaces twice-weekly with always-on; replaces manual draft composition with templated drafts admins review-and-send; replaces manual Slack escalation with rule-driven DMs.

Job file in frontier-agents (lambda_src/jobs/4k-ar-monitor.md) on a daily cron. Agent instructions: (1) query Harvest for invoices with state=open and due_date < today - threshold_days, (2) for each, identify client and PM owner, (3) select email template by days-overdue band, (4) draft email to accounting inbox via Gmail draft creation, (5) for invoices crossing escalation threshold, DM the PM via Slack, (6) log batch to S3 audit prefix. Drafts go to accounting inbox; admin team reviews and sends.

• Harvest invoices via our connector
• Per-engagement PM-ownership map (Notion or curated)
• Gmail accounting inbox (Workspace API for draft creation)
• Slack workspace (DM scope on our bot)
• QuickBooks Online — audit tech stack lists QuickBooks as a cross-check destination for accounting-side accuracy. Not in the live AR flow; referenced only for reconciliation if drafts surface discrepancies. Out of scope for v1 active integration.

• All soft info from #14 (escalation thresholds, language, PM-ownership map)
• Whether drafts go to one accounting inbox or get routed by engagement
• PM-DM rules: does every late invoice escalate, or only certain client tiers?
• Volume — 15-min question with Peke or Jade (not captured in audit)

• Auto-drafting client-facing emails has reputation risk. Drafts must go to a human review queue (accounting inbox), not auto-send.
• PM-DM channel can become noisy with many small overdue invoices. May need batching ("you have 4 invoices overdue across 3 engagements") rather than one DM per invoice.
• Some clients pay reliably but late. Pestering them at day 7 could damage relationship. Per-client override capability worth flagging.

Automates Beto's manual transfer of PM one-pager projections into the Active Projects tab. Consolidates upstream pipeline view from PM sheet + Pipedrive + Active Projects tab. Includes a discovery sprint on Finance HQ's surface (human consulting work — see separate Config/Setup card). Quantified pain: $20K → $15K example was a 25% miss on a single client's monthly projection, multiplied across 31–50 active clients.

The two-person debugging dependency the audit names is structural, not personal. System-level framing in any 4K-facing artifact — Phase 1's discovery output and the eventual Phase 2 discrepancy surface (#29) must describe the system mechanism, not the people who currently maintain context for it.

Beto's weekly manual transfer of PM one-pager projections into the Active Projects tab. Replaces "Beto checks each PM's projections and updates Active Projects" with automated pull + reconciliation.

Job file in frontier-agents on a weekly cron: pull PM one-pager projections via Sheets API, pull Pipedrive deals via our connector, reconcile name formats and engagement IDs, output consolidated view to a designated Sheet (and optionally to Notion).

• PM one-pager projections sheet (Sheets API, known sheet ID)
• Pipedrive (our connector, deals + weighting)
• Active Projects tab (Sheets API — for writing the consolidated view)
• QuickBooks Online — audit tech stack lists QuickBooks as "out of the projection chain but referenced for cross-check in the discrepancy-investigation surface." Not a primary data source for Phase 1; referenced for context. May become active in #29 Phase 2 once Finance HQ discovery completes.

• The exact sheet IDs for the PM one-pager sheet and the Active Projects tab
• The reconciliation rules Beto applies today (name format normalization, engagement-ID mapping)

• Beto's reconciliation logic is partly intuitive (he eyeballs name matches). Encoding it deterministically may surface ambiguity his manual process glossed over.
• The $20K → $15K example traced to a PM not updating projections on time. Automation catches the drift but doesn't change PM behavior — surface this honestly.

Automates Beto's weekly ETL: Harvest + Forecast (via #21 watched-folder) + Teresa's CC sheet + invoicing sheet + Pipeline sheet → reconciled master → Notion scorecards DB cells.

Managed Agent (scheduled, ahead of each L10) + Skill (the reconciliation logic encoded as a skill the agent invokes). Cleaner than putting reconciliation logic in agent prompt directly.

• Beto's weekly Harvest + Forecast export-paste cycle
• Manual reconciliation formula maintenance when source-system name formats drift
• Manual CC-numbers copy from Teresa's sheet
• Manual revenue-projection entry from the invoicing sheet
• Per-metric, per-week typing into Notion scorecards cells (for Beto's rows)
• Mid-week double-update before Wednesday L10 (becomes single automated sync)
• Beto's manual pre-Q1 archived-project backup workaround

Job file in frontier-agents on cron ahead of each L10. Agent calls reconciliation Skill which: (1) pulls Harvest data, (2) pulls Forecast snapshot from latest watched-folder ingestion (#21), (3) pulls Teresa's CC sheet, (4) pulls invoicing sheet, (5) pulls Pipeline sheet, (6) applies Beto's reconciliation formulas (migrated to code), (7) writes per-metric per-week cells to Notion scorecards DB via direct API. Beto reviews before each L10.

• Harvest via our connector
• Forecast via watched-folder (#21). Two recurring frictions: archived projects drop out of exports (Beto's pre-Q1 backup); Harvest/Forecast use different name conventions (Beto's reconciliation formula)
• Teresa's CC sheet via Sheets API. CC15 = 15 contracted + 5-hour security/updates buffer per tier. Rolls up monthly. Continuously shifts with sales activity.
• Invoicing spreadsheet — disconnected from sales pipeline today; Beto's "what's the vibe" surface
• Pipeline-and-Active-Projects sheet, Open Pipeline tab — synced from Pipedrive with weighting toggles
• Notion scorecards DB via direct API. Each row = one metric, tagged by department — three departments: Delivery / Projects / Company-Leadership. Each row has target field + week-number field. Same row can surface on three different scorecards via the department tag (the tag drives which scorecard view shows the metric).

• Beto's master sheet formulas — most important soft input. Handles name-format drift, archived projects, CC vs non-CC splits, sold/booked hours, pre-sale assumptions, 3–4 month forward projections, per-person plan-vs-actuals
• Teresa's CC sheet specifics — confirm CC15 = 15+5 math uniform across tiers (CC10, CC15, CC20)? Confirm whether to connect to her current sheet or absorb her workflow
• Notion scorecards-DB schema mapping (metric / department / week-number contract per row Beto owns)
• Engineering leadership separate scorecard sheet — engineering team "starting to own" their own. v2 expansion target — name the boundary clearly
• Scope question: v1 probably scopes to Beto's rows only. Name that explicitly.
• Pre-Q1 archived-project backup workaround details — how Beto merges it back in

• Beto's master sheet has accumulated complexity over years. Migrating formulas to code is the bulk of the work and where edge cases hide. Plan for iteration after first dry runs.
• Teresa's CC sheet shifts continuously with sales — skill needs fresh state each run, not cache.
• The Forecast dependency is real — if #21 isn't healthy, #24 produces wrong scorecards. Health-check dependency.
• Engineering leadership's separate sheet is v2; don't bundle into v1 scope.

Composes existing health signals into one per-account view. Surfaces into Projects Roundtable and pipeline conversations. Leadership-only access — PM-consistency observations the agent reveals must never appear in PM-visible views.

Mostly Managed Agent + composition Skill. Plus a tiny Custom App component if 4K wants a leadership-only drill-down portal (small UI, leadership-scoped access).

Per the audit: scoring engine is deterministic — a lead crosses a threshold → trigger fires. Managed Agent then queries the substrate for the lead's full profile and generates a contextual recommendation with suggested next step. Notifications distributed multi-channel: email via SES, Slack via webhook, or both — configurable per account or alert type.

Specific alert triggers the audit names: sentiment drop, recurring late deliverables, engagement-age threshold crossed, yellow→red state transition. These are the deterministic-rule side of the hybrid; the AI side generates contextual recommendation language for each fired alert.

Audit calls out both integration surfaces for the agent — they aren't the same conversation:

• Projects Roundtable integration — composed view lands automatically on the Roundtable's weekly agenda.
• Pipeline conversation integration — risk status surfaces alongside pipeline weighting where it currently doesn't appear. Sales/pipeline discussions today don't see engagement-health context; this build closes that gap.

Composition logic itself is straightforward. The inputs aren't trivial — health-signal extraction from Slack, decision/commitment capture from threading, recency-weighted reconciliation across rotting Notion entries — but all of that lives in the CKA substrate (#28), which is now Tier 1 foundation. CHA composes on top of an already-working substrate, rather than requiring substrate to be designed and built as part of this engagement. With substrate as a given, this is a composition Skill + Managed Agent + small leadership-only UI — moderate work, not hard.

Why not Easy: the leadership-only permission scoping, hybrid deterministic+AI alert logic, and multi-channel delivery (email + Slack, configurable per account) still take real engineering. Threshold tuning takes weeks of real data. But it's no longer "build the underlying intelligence platform first" — that's done.

• Disparate dashboards reviewed individually in the Projects Roundtable
• Shanice's manual scoring as the surface leadership goes to — stays as input, agent becomes the answer
• The flat 90% recurring-revenue toggle (replaced by logo-by-logo signal as attrition forecasting layers in)
• The implicit "Beto and Shanice's heads" health surface — formalizes what they already know

Per-logo attrition forecasting — downstream feature once enough engagement-age + sentiment signal accumulates. Replaces the flat 90% recurring-revenue toggle. Not v1 of this build; layers in later. (Si · M3 ~50:55–52:55)

• CKA substrate (composed signals) — via #28
• Pipedrive weighting (direct)
• Harvest engagement age (direct)
• Engagement-type tag (skill #01, with Beto's risk-correlation metadata)
• Notion engagement DB temperature (CKA-recency-weighted, not direct)
• Notion client-success scoring DB (CKA-ingested separately from engagement DB — see #28)
• Projects Roundtable notes (CKA-ingested)
• Pipeline-and-Active-Projects sheet — revenue projection and weighting context per account. Reads cleanly if #22 (Build 6 Phase 1) also ships; without it, this dimension is fed by manual pipeline review.

• The CKA substrate has to exist first
• Signal-weighting rules — how much weight does sentiment carry vs ticket cadence vs response latency?
• Beto's alarm threshold for triggering individual alerts — "When I'm really alarmed, it's when there's a really unhappy client on a meeting" (Beto · M3 ~41:45). Human-judgment calibration target for deterministic threshold rules.
• Alert delivery preferences — which leadership members, email vs Slack vs both, per-account customization

• PM-consistency permissioning. Agent's data must never surface in PM-visible views. Permission architecture has to be designed from day one, not retrofitted.
• Without good substrate-level synthesis quality, the Health Agent's composition output is confidently wrong. Agent is only as good as the dimensions it reads.
• Alert fatigue. If thresholds too sensitive, leadership ignores. Too lax, they miss things. Tuning takes weeks of real data.
• "Notion engagement DB rots" — if leadership trusts the Notion field, they may push back on synthesized values that disagree with it.
• Multi-channel delivery adds operational complexity (SES domain verification, Slack webhook management). Worth a unified delivery layer rather than per-account ad hoc.

Small Custom App. Ingestion path for Forecast data via manual CSV exports. This is our only viable Forecast integration given the vendor disclaims their undocumented API. Feeds #24 (Scorecard Updater) and CKA-substrate-backed SiBorg comparable retrieval.

It has persistent state (versioned snapshots), event-driven processing (S3 PutObject triggers), publishes events to downstream consumers (#24, #28). Not just a Skill (it's scheduled/event-driven and stateful). Not a Managed Agent (it's mechanical ETL, not LLM-reasoning). Not an MCP (it doesn't expose tools to Claude). Small Custom App is the right shape.

Beto's manual Forecast-export-and-paste step in the scorecard ETL chain. The export still happens (he or Si still triggers it), but the paste-into-master-sheet and reconcile-name-formats steps go away.

S3 bucket (or designated Drive folder) where Beto/Si drop CSV exports. S3 PutObject event → Lambda → parse CSV → schema-validate → normalize → publish events to downstream consumers (#24, CKA ingestion) + audit log + Slack notify on ingestion.

• Beto's weekly Forecast CSV export (scorecard input)
• Si's on-demand Forecast CSV export (post-accepted-estimate, for CKA's allocation history)
• Schema is whatever Forecast's CSV export gives us. Audit names the expected tag structure: pre-sale, CC, Build, StaffAug, Pixie — five engagement-type tags that the normalization layer needs to preserve so downstream consumers (#24 scorecard, #28 substrate context) can use them.

• A sample Forecast CSV export — actual column names, types, edge cases
• Beto's current cadence (weekly Tuesday before Delivery L10)
• Si's cadence (post-acceptance)
• Whether the export includes archived projects or if Beto manually merges his pre-Q1 backup
• Upload surface preference: S3 with presigned uploads (compliance-clean) or Drive folder (matches workflow). Recommend S3.

• Forecast's CSV export format can change without notice (vendor disclaims schema stability). Pipeline needs to hard-fail on schema drift, not silently ingest bad data.
• If Beto/Si forget to export, downstream sees stale data. Mitigation: scheduled reminder ahead of L10; alert if no export within expected window.
• Forecast is being sunset along with Harvest. This is a temporary pipeline — useful for 6–12 months, then replaced by whatever the Harvest-replacement's scheduling product provides.

Deploy 4K's tenant of the Newfangled CKA platform. Build the data-source modules for 4K's tools (ClickUp, Notion, Slack-dual, GDrive-tagged) on top of the platform's abstracted framework. Configure per-engagement scoping for ~10 priority engagements. Tune the platform's prompt slots (extraction, summary, synthesis, strategic) for 4K's data sources and 4K's specific operation.

The CKA's core abstraction is a separate Newfangled-side investment built outside the 4K engagement:

• Multi-tenant architecture (run for any agency)
• Abstracted data-source ingestion framework
• Module-based data sources (the framework that lets us drop in new sources)
• Prompt override / tuning system (the framework that lets us tune all prompts per tenant)

This is what makes the 4K-side work bounded. We're not building substrate from scratch — we're configuring a tenant + building modules + tuning prompts.

Under the abstracted-framework framing, this work is pattern-based, not novel engineering. Modules follow a known connector-equivalent shape (~8–15 hrs each). Prompt tuning is the dominant time-sink but it's bounded — known categories (extraction, summary, synthesis, strategic), known dimensions (5–6 for v1), and the platform handles the orchestration. Real risk lives in prompt-iteration cycles against real 4K data, not in architecture.

This is Tier 1 — Substrate, the foundation everything downstream depends on. Promoted from old Tier 3 because under the new framing it isn't a heavy build — it's the substrate every later skill, agent, and intelligence item builds on. Without it: SiBorg refactor (#27) doesn't work, Client Health Agent (#26) can't read the inputs it needs, and 5 of the Tier 2 skills (onboarding brief, Roundtable agenda, rate-card lookup, lightweight SiBorg, pre-call prep) produce shallow output instead of full-depth.

• SiBorg's parallel ingestion pipeline for proposals, SOWs, rate cards, boilerplate, brand assets (via #27)
• Notion engagement DB as canonical onboarding surface (CKA becomes the synthesized authoritative view)
• Manual "where do I find this" searches across six locations
• SOW terms duplicated across Notion engagement DB, invoicing spreadsheet, and Harvest notes
• The disparate-signals-no-composition problem that motivates Build 2 (#26)
• The "knowledge mostly in people's heads" problem (partially — substrate captures what's documented; pure tribal knowledge remains a gap)

• Provision 4K's tenant of the CKA platform (config + Secrets Manager + AWS resources). Not a code build — a platform deployment.
• Build 4 data-source modules on the platform's module framework: ClickUp module (hierarchy + tasks + comments + custom-field normalization), Notion module (database queries + block-tree recursion + 21-property-type dispatch + 3-rps throttling + ingests all surfaces named in audit including the separate client-success scoring DB and the VTO space), Slack module extension (dual-channel per engagement + channel-type metadata), GDrive module (tagged subsets — SOWs, contracts, proposals, rate cards, brand assets, boilerplate).
• Configure per-engagement scoping for ~10 priority engagements (engagement IDs, source mappings, indexing schedules).
• Tune extraction prompts — per data source, what to pull and how to structure. 4 sources × prompt = 4 prompts.
• Tune summary prompts — daily / weekly / monthly aggregation cadences. 3 prompts.
• Tune synthesis prompts — v1 ships 5–6 high-value dimensions of the 15 (per-engagement strategy summary, health signals, decision capture, SOW extraction, comparable retrieval; potentially win/loss reasoning). Cross-source prompts.
• Tune the strategic summary prompt — top-level engagement context.
• Ingest Forecast allocation snapshots via #21 watched-folder pipeline (publishes events the substrate consumes). Allocation history with Forecast tag structure (pre-sale, CC, Build, StaffAug, Pixie) becomes part of substrate context.
• Migrate SiBorg's accumulated win/loss memory into CKA as a tagged annotation layer Si still controls (per #27).
• Initial indexing against real 4K data — bulk-index orchestration with rate-limit-aware pacing.
• Validation cycles against real queries — iterate on prompt quality per dimension. Expect 2–3 cycles per dimension.

• ClickUp REST v2 (via the module)
• Notion API (via the module) — 8 distinct DB surfaces ingested
• Slack Web API (via the module extension) — both internal and shared per-engagement channels. Per Beto · M3 ~43:48: "Public with them and without them. Most, most of the time."
• Google Drive (via the module) — tagged subsets
• Forecast snapshots via #21 watched-folder pipeline
• Gmail intentionally excluded — see #35 (OOS for confidentiality)
• Pipedrive and Harvest queryable via MCP at runtime (not ingested into substrate indexes — those are structured numeric sources better served by live queries)

• ClickUp hierarchy unit per engagement (Space, Folder, List set)
• ClickUp priority label scheme — audit names base → 1 → 2 → 3 → 4; confirm whether this maps to ClickUp's built-in 4-level priority (Urgent / High / Normal / Low + null = 5 effective states) or a custom field. See research/clickup.md.
• Notion database IDs for all in-scope DBs (engagement DB, client-success scoring DB, scorecards DB, partners DB, meeting notes parent, working agreements, knowledge bases, VTO space)
• Slack channel IDs for each priority engagement, both internal and shared
• GDrive folder paths for each tagged subset
• Shared-Slack-channel confidentiality decision — without this, we can ingest but can't apply meaningful synthesis to shared-channel content
• Gmail status — audit listed Gmail as a Build 1 ingestion source; deferred to #35 (OOS) for confidentiality reasons. Flagged so audit→build trace stays honest.
• Priority engagement list — initial ingestion focuses on ~10 engagements; full ~50 is phase-two
• Per-PM consistency observation needs leadership-only synthesis dimension separated from PM-visible ones

• The "engagement onboarding" pain that motivates much of this requires capturing "in people's heads" context. Substrate captures documented decisions; pure tribal knowledge isn't captured anywhere.
• The "Notion engagement DB rots" problem isn't a Notion problem. Synthesis prompts must confidence-weight by recency and corroboration — that prompt-engineering work is included in synthesis prompt tuning hours.
• Volume × Notion's 3 rps × ~10 engagements × multi-DB structure = initial indexing window of hours. The two distinct Notion scoring DBs both need ingestion paths — don't conflate.
• ClickUp parent-task chain depth varies. Module needs to preserve the chain or synthesis loses meaning.
• Shared-Slack-channel synthesis depth is gated on confidentiality decision. Worst case: ingest but synthesize only 4K-side signals (response cadence, deliverable confirmation), not client utterances.
• Prompt quality is iterative. Each of the 5–6 v1 synthesis dimensions needs validation cycles. Expect 2–3 cycles per dimension before output is trustworthy. This is where the bulk of the PM/discovery/testing hours go.
• The platform's 15 dimensions are the target; v1 may ship 5–6 high-value dimensions, rest layer in over time.
• Cost discipline: substrate-backed synthesis runs are expensive (token volume × frequency). Hard cost is $1,000–1,880/mo at Tier 1 (doubled headroom over baseline AWS/API estimates to absorb real-world growth); monitor.
• Phase-2 invisibility: while substrate is being built (weeks 3–10), 4K's team doesn't see daily user-facing value. Worth setting expectations. The "quick-wins-in-parallel" option can mitigate by shipping 7 substrate-independent Tier 2 skills during this phase.

4K's 24-hour Zoom retention policy interpretation. If the policy applies to recordings only and transcripts can be retained separately, the pipeline is feasible. If both fall under the 24-hour rule, this is dead. Also implicates 4K's data agreement.

Webhook + polling pipeline that extracts VTT transcripts within the retention window, stores them in CKA, drives sentiment/decision-extraction synthesis dimensions that Build 2 (#26) consumes. Would enable substrate sentiment-from-voice (richer than meeting-notes-based scoring in #02).

Manual sentiment scoring of client calls. Replaces Shanice's gut-reaction scoring of 1:1 notes with substrate-backed sentiment extraction from the actual conversation.

• Zoom's recording.transcript_completed webhook has documented reliability issues. Pipeline needs polling fallback.
• Even if policy permits, transcripts of client meetings raise confidentiality questions similar to shared-Slack-channel synthesis.

Confidentiality / MSA review. Indexing client communications into a queryable AI system probably requires either MSA review or client disclosure. Until 4K's legal posture is clear, the synthesis depth on shared channels is bounded.

Full sentiment / decision-capture / risk-signal extraction on shared-channel content, same as internal-channel synthesis dimensions.

The shared-channel-as-opaque-context limitation. Today (and in v1 of the substrate) we ingest shared-channel content but synthesize only 4K-side signals. Unblocked, we get sentiment / decision capture on the full conversation.

• Even with MSA in our favor, individual clients may push back. Worth an explicit disclosure pattern (channel topic, onboarding doc) and per-client opt-out.

4K-specific INSTRUCTIONS file for their Claude Teams workspace. Captures operating philosophy, voice, terminology (CC vs Build vs StaffAug vs T&M vs Fixed Fee vs Pixie), team structure, engagement-type vocabulary, tool-selection rules. Used as the shared body in the two-part INSTRUCTIONS pattern.

Configuration artifact (lives in Claude Teams projects). Not a tool. Produced by a Skill (our org-instructions-generator), but the artifact itself is config.

Per-project ad-hoc INSTRUCTIONS that individual PMs would otherwise hack into their own Claude Teams projects. Centralizes guidance so updates land everywhere simultaneously.

Run our org-instructions-generator skill (proven on WWP). Generator crawls 4K's site, interviews leadership through structured prompts, drafts INSTRUCTIONS body. Leadership reviews and iterates. Final version becomes the shared body in every per-engagement Claude Teams project.

• 4K's website (public)
• Structured interview output with 4K leadership (Elia, Beto, Joanna, Shanice, Si)

• Access to the audit's raw interview transcripts — much of what the generator needs is already there
• Final-form leadership review — at least one person (Elia or Beto) needs to sign off

• Two-part INSTRUCTIONS pattern only works if 4K commits to using it. If individual PMs hack their own per-project INSTRUCTIONS that drift, the pattern breaks down. Worth a leadership decision on enforcement.
• Shared body needs maintenance over time — someone owns updating it.
• If 4K's terminology has drift between teams (engineering "Build," sales "Project"), INSTRUCTIONS need to flag canonical term and team-specific synonyms.

Headers for each priority 4K engagement (probably ~10 to start) that go on top of the shared body produced by #12. Each header captures: client name, slug, primary contacts, key identifiers (Harvest project ID, Pipedrive deal/org ID, ClickUp space/list ID, Notion engagement page ID, Drive folder ID, Slack channel IDs both modes).

Configuration artifacts (one per engagement, lives in Claude Teams projects). Not tools.

The manual context re-establishment users would otherwise do at the start of each conversation. The header pre-binds those identifiers so every tool call routes correctly without restating context.

Template a header pattern (same shape as WWP's <client> block). For each priority engagement: gather identifiers (mostly mechanical Q&A with 4K), populate template, deploy as per-project Claude Teams INSTRUCTIONS file alongside shared body.

4K provides the identifiers per engagement. Often a 30-minute working session with someone who knows their Harvest/Pipedrive/ClickUp/Notion setup.

• Priority engagement list — which ~10 engagements get headers at launch
• The identifiers themselves — mechanical to collect but requires someone with access
• Naming convention for slugs (used in audit logs and downstream tooling)

• Identifier collection is slow if 4K's team isn't organized about which ID corresponds to which engagement. Plan for back-and-forth.
• As new engagements start, headers need to be added. Make this self-service for 4K's team rather than a Newfangled bottleneck.
• If 4K renames or restructures, headers need updates. Document the maintenance path.

Stand up 4K's Claude Teams workspace (if they don't have one), install official third-party MCPs at the project level (ClickUp, Notion, Slack, Google Workspace). Provision service accounts and OAuth where needed.

Setup activity. Not a tool we build. Mechanical configuration work that delivers value but doesn't fit the four tool types.

Ad-hoc personal-Claude usage with no org context, no standard tool surface, and no shared INSTRUCTIONS body. Centralizes the operating environment.

Mechanical work — Anthropic admin console for Teams setup, OAuth flows for each vendor MCP. ClickUp at mcp.clickup.com/mcp (OAuth 2.1 PKCE). Notion's official MCP. Slack's official MCP (GA Feb 2026). Google Workspace via standard patterns. Document access, scopes, who has admin.

Vendor MCP installation flows; no application data yet.

• Whether 4K has Claude Teams already (audit existing setup vs procure)
• Which 4K admin has rights to install OAuth apps in each vendor
• Per-vendor consent for ClickUp/Notion/Slack — which workspaces, which scopes
• Whether vendor MCPs scoped at workspace level (everyone sees them) or per-project (selective)

• OAuth setup has friction. Each vendor's flow is slightly different. Plan for a half-day of coordination per vendor.
• Slack's official MCP only works with Enterprise Grid for some features. If 4K is on a lower plan, some functionality is missing.
• Vendor MCPs have rate limits (ClickUp: 50/24h free, 300/24h paid; Notion: 3 rps hard). At Claude Teams seat-counts × ad-hoc query volume, may hit limits sooner than expected.

Newfangled's own alignment work, in parallel with 4K's engagement. Documented SSP, control implementation across the relevant control families, evidence catalog, vendor attestations.

Newfangled-side organizational/process work. Not a 4K tool we build. Required to credibly deliver to 4K and to any future regulated-adjacent client.

Newfangled's "we have good engineering hygiene but no documented control posture" status. Replaces with a documented, evidenced alignment posture we can present to any regulated-adjacent client.

Documented in COMPLIANCE.md. Externally-led gap assessment, SSP authoring, control implementation across AC/AU/CM/IA/SC/SI/RA/CA/PS/SR families, policy authoring (12–20 docs), GRC tooling adoption (Drata/Vanta), initial pen test, training rollout.

Internal Newfangled systems (AWS, our existing tooling, dev workstations).

• Internal decision: do we pursue alignment at all? (Recommendation on the Compliance page: yes, $33–48K Year 1 + $25–35K/yr, recalibrated with AI leverage)
• GRC platform choice — Drata Foundation recommended; quote Sprinto + ComplyJet for leverage
• Pen test firm
• vCISO readiness review yes/no (~$8–10K, Year 1 only)

• Treating this as a side project guarantees it falls behind 4K's timeline. Needs explicit owner and budget.
• Compliance ops becomes ongoing operational drag if not staffed (quarterly access reviews, audit responses, evidence collection). Plan for ~280–400 hrs/yr (much overlaps with normal eng ops) from day one — and pick a named owner; "everyone does a little" guarantees it falls behind.
• Vendor attestation gaps — if Anthropic doesn't have the cert 4K's auditor wants, we have to surface and explain the inherited-authorization story.

Human-led investigation of 4K's Finance HQ controller tool. Interviews with Beto and Teresa, documentation of the per-line EBR mechanism (which 4K's own operations leadership can't fully describe), documentation of the data flow into Finance HQ. Deliverable: documentation 4K doesn't currently have internally. Output gates #29 (Finance HQ Phase 2) sizing.

Human consulting work. Not a tool. Real engagement deliverable.

N/A directly (the consulting output enables a future build to retire the manual reconciliation).

Schedule time with Beto + Teresa. Read access to Finance HQ in observation mode. Walk through current end-to-end flow. Document: data sources, mechanism for each computation, manual steps, decision points, edge cases. Produce a discovery report.

Interviews, observation, internal documentation if any exists.

• Access scheduling with Beto + Teresa
• Read access to Finance HQ
• Any existing internal documentation (probably none)

• 4K's own operations leadership can't fully describe Finance HQ's per-line EBR mechanism. Discovery may reveal the system is more bespoke than expected, which changes Phase 2 (#29) sizing significantly.
• Two-person dependency means people who know most are also hardest to get time with. Plan accordingly.
• [SENSITIVE-ADJACENT] framing: discovery report must describe system mechanism, not personalize.

Finance HQ's surface is unknown. 4K's own leadership can't fully describe the per-line EBR mechanism. Unblocks when the discovery sprint (part of #22) documents the system.

Likely Custom MCP Connector + Managed Agent (if Finance HQ has any programmatic surface), or Custom App (if integration requires scraping or workflow automation against a UI-only system). Can't classify until discovery completes. Discrepancy investigation surface that shows drift, names missing updates, links to responsible PMs. [SENSITIVE-ADJACENT] framing applies — discrepancy surface must describe system-level pattern, not personalize the issue.

• The Sherlock-Holmes debugging tax that lands on two specific people
• The structural dependency on two specific people for financial reconciliation
• The invisibility of upstream PM update lag — once integrated, late projections become a real-time signal rather than a forensic discovery
• Per-service-line profitability dashboard rides on the same discovery (audit's "additional candidates" — earns its way out when Phase 1 lands)

• If Finance HQ turns out to be pure-UI with no API, integration becomes scraping or human-in-the-loop. Both are real engineering. If it has a clean API, this could drop to MODERATE Custom MCP Connector territory.

Harvest explicitly disclaims their undocumented Forecast API. Building a paid integration on an unsupported, vendor-warned-against surface is not defensible under 4K's alignment posture or generally. The watched-folder fallback (#21) is the workaround.

To mark explicitly that direct API integration is off the table. Documented as "not building" so it doesn't keep coming up as a "maybe" question.

Would be a Custom MCP Connector if we built it. Not building.

N/A — not building.