mirror of
https://github.com/rennf93/roboco.git
synced 2026-08-03 07:23:24 +02:00
feat(board): Board Programs — the complete twelve-program catalog (Phases 1-3) (#699)
* feat(board): Pest Control — the first project-scoped Board Program The Product Owner hunts latent defects (what the org records but nobody reads): a weekly cycle — accelerated off-schedule when the trailing-7-day rework rate crosses pest_rework_threshold, with the cheap dedup/scope gates evaluated before the metrics queries — opens one held exploration task against the least-recently-explored opted-in project (deterministic round-robin; opted_in_projects gains a stable ORDER BY), with server- assembled evidence in the spawn prompt (rework hotspots, recurring-findings and waived-minor ledger aggregates, all capped) plus prior-cycle LEARN context. The PO calls the new PO-only propose_bug_hunt verb once: ≤5 items, evidence required per item, targets validated against pest_control participation. CEO decides per item — approve materializes a BACKLOG task (source pest_control, never auto-starts), reject records the reason; both feed the LEARN ledger by exploration task id; all-terminal completes the cycle. Telegram queue pushes carry working Approve/Reject handlers mirroring the roadmap kind. Doctrine: board.md Pest Control section + product-owner verb entry + regenerated verb tables. * feat(panel): Pest Control review queue Command Center gains the pest review queue (per-item approve/reject with reason, mirroring the roadmap queue); the Programs card and the project settings participates-in checkboxes pick the new program up registry-driven — the settings section renders for the first time now that a project-scoped program exists. * feat(board): Periscope — HoM market-research brief program Weekly org-scoped cycle: a solo HoM spawn researches the market (web research with mandatory source URLs — uncited findings are rejected) and files one structured brief via the new HoM-only propose_market_brief verb: headline, cited findings, threats/opportunities, positioning note, all soup-checked and screened through the injection guard at persist time (web-derived text later reaches prompts; flags recorded, content never dropped). A brief is a report, not a proposal: the verb completes the exploration in the same call (the x_feature asymmetry), the cycle ledger auto-closes, and the CEO gets a best-effort notification with no approve/reject surface (periscope deliberately never joins Telegram's action kinds). The latest brief is injected into the roadmap exploration prompt — Periscope feeds Printer, the first cross-role program input. * feat(panel): Market Briefs tab (read-only) Business page gains a Market Briefs tab listing Periscope briefs — headline, cited findings, threats/opportunities — read-only by design; a report has nothing to approve. * feat(board): Coroner — event-triggered Auditor postmortems The first EVENT program: no cron — three best-effort hooks open an autopsy when a task bounces to its 3rd revision (the audit chokepoint), is cancelled after work started, or is budget-blocked; all gated on arming + one-open-autopsy dedup, none can fail the underlying transition. A solo Auditor spawn reads the incident (server-assembled findings + transition context) and files one propose_postmortem: incident summary, root cause, failed stage (validated against the real status vocabulary), and ONE process change — a playbook-kind change drafts via PlaybookService directly into the normal pending-curation queue; the briefed draft_playbook manifest grant was deliberately NOT added, preserving the existing 'auditor curates but never drafts' invariant test. Complete-at-propose (report asymmetry), cycle ledger auto-closes, CEO notified link-only. Integrated as a union with Periscope across the shared program surfaces. * feat(panel): Coroner postmortems card Read-only postmortems list under Business → Programs — incident, root cause, failed stage, process change; nothing to approve, the process-change artifact (a draft playbook) rides the existing curation queue. * feat(board): Sentinel — Auditor drift-watch quality reports Weekly org-scoped cycle: a solo Auditor spawn receives a server-assembled drift context (waived-findings trend, open findings by severity, conventions-violation hotspots, top spend — all capped, pure ORM) and files one propose_quality_report: headline, 1-7 area-validated items with evidence and suggested actions, overall assessment. Report semantics — complete-at-propose, cycle auto-closes, CEO notified display-only (never on Telegram's approve/reject surface); items are structured so a later convert-to-task control is cheap. Integration adopts Sentinel's module- level dict-dispatch for board-program routing (xenon-driven), folding all prior programs in; app router mounting extracted to a helper for the same budget. * feat(panel): Quality Reports tab (read-only) Business page gains the Sentinel quality-reports tab — headline, per-area observations with evidence and suggested actions; read-only, a report has nothing to approve. * feat(board): Spackle — gap-fill audit program Biweekly project-scoped PO cycle over the half-shipped surface area: API routes without panel surfaces (and vice versa), armed flags without docs, docs promises the code doesn't keep, dead-end tabs — the inventory diffing is the PO's own read-tool work, ordered by the spawn prompt with file:line citations required; the server injects only prior-cycle LEARN and the rotation target. Rotation is now a shared module-level helper (pick_rotation_target, parameterized by source) both project-scoped engines use — pest_control delegates to it, behavior-identical, with a cross-pollution test proving the two programs' rotations stay independent. propose_gap_fill mirrors the bug-hunt verb (≤5 items, two-sided evidence required, participation gate); per-item CEO decide materializes BACKLOG source=spackle tasks; full Telegram kind incl. approve/reject handlers. All seven program routers now mount from one helper. * feat(panel): Spackle gap-fill review queue Command Center gains the gap-fill queue mirroring the pest-control one — per-item approve/reject with the two-sided gap evidence rendered. * feat(board): Scales — monthly portfolio rebalance Org-scoped PO cycle over the stale backlog: the spawn receives a capped stale-task snapshot (BACKLOG/PENDING unclaimed >30 days) plus the charter and prior-cycle LEARN, and files one propose_rebalance — 1-7 items, each a resolvable task_ref with action reprioritize (validated new priority) or cancel, rationale required. Per-item CEO decide: approve EXECUTES the action (audited priority update, or the normal cancel path) — the first program whose materializer mutates existing tasks instead of creating them; reject records the reason; LEARN by exploration task id; all-terminal completes the cycle. Full Telegram decide-kind wiring. Integrated as the eight-program union (registry, dict dispatch, routers helper, teardown enumerations). * feat(panel): Scales rebalance review queue Command Center gains the rebalance queue — per-item approve/reject with the action, target task, and rationale rendered. * feat(board): Mirror — quarterly positioning audit Project-scoped HoM cycle over messaging surfaces: README claims vs shipped reality, docs-site promises vs code, charter alignment — the audit is the HoM's own read-tool work with citations required; the server injects the charter, prior-cycle LEARN, and the shared rotation target. propose_ messaging_fixes mirrors the gap-fill verb (≤5 items, drift evidence naming claim + contradicting reality, participation gate); per-item CEO decide materializes BACKLOG source=mirror documentation tasks; full Telegram decide-kind wiring. Nine-program union across the shared surfaces. * feat(panel): Mirror messaging-fixes review queue * feat(board): Megaphone — HoM standing editorial calendar Cron cycle (3 days, org-scoped, gated on X credentials — drafting content nobody can post is pointless): the HoM receives a shipped-this-week digest plus Unreleased changelog bullets and files one propose_editorial_post (angle-validated, ≤280, brand voice) that materializes a held x_editorial draft through the SAME X-queue origination chokepoint release posts use — zero new approval surface, notifications and CEO decide for free. Complete-at-propose; cycle auto-closes. Ten-program union. * feat(panel): x_editorial source labels in the X queue surfaces * feat(board): Librarian — proactive playbook mining Biweekly org-scoped Auditor cycle: mines recurring non-private learning journals (≥2-count grouping with a recency fallback) against the existing playbook-title inventory and files one propose_playbook_drafts — 1-3 drafts, each with the repeated-pattern evidence that justifies it, duplicate titles rejected in-batch and against the live store. Drafts are created via PlaybookService directly (the Coroner precedent — the 'auditor curates but never drafts' do-verb invariant stays intact and tested) and land in the normal pending-curation queue the Auditor's own triage already surfaces; no new panel surface. Complete-at-propose; display-only CEO notification. Eleven-program union. * feat(board): War Room — release campaign planning EVENT program with a REAL originator (unlike coroner's stub): a release publish hooks a campaign brief beside the release-post seam, and the CEO's run-now originates on demand — the cron loop never fires it. The HoM designs a 2-6 post arc (teaser → launch → follow-up → spotlight; 280-cap, future strictly-ascending publish_after, stage vocabulary) and one propose_campaign call materializes each post as a held x_campaign draft through the X-queue chokepoint. V1 is manual-cadence by design: publish_ after renders as queue guidance and the CEO approves each post at its moment — nothing auto-posts, ever; the auto-schedule upgrade is a documented ceiling. Twelve-program union: full registry complete. * feat(panel): x_campaign labels + publish-after guidance in the X queue * feat(board): Barfly — adjacent-conversation replies Cron cycle (2 days, org-scoped, X-credentials gated): the engine searches X for conversations where RoboCo is relevant but unmentioned (new OAuth- signed search_recent on the client; queries + candidate cap configurable), screens every fetched tweet through the injection guard (stored unclamped — a clamp was truncating the candidate under the envelope, caught by the dev's own tests), dedupes via the existing x_seen_mentions ledger (no migration; also prevents double-drafting against the mentions poll), and opens one held HoM exploration carrying the screened candidates. propose_ conversation_replies enforces candidate-id-only replies (≤5, 280-cap); each materializes a held x_barfly draft through the X-queue chokepoint, threaded via a new in_reply_to seam on post_tweet that only x_barfly drafts use. The X redraft machinery is now dict-dispatch over per-source extractors with reply-ref carry for x_barfly. Thirteen-program registry. War Room's test fakes gained the new abstract search_recent stub. * feat(board): Dogfood — the PO walks the product The fourteenth and final registry entry, completing the catalog. EVENT program (release-publish hook beside the war-room hook + CEO run-now, both through the same real originator; the cron loop never fires it), project- scoped with shared rotation. The permission surface is the careful part: the PO's dogfood spawn — and ONLY that spawn — gets the Playwright MCP mounted, via a task-scoped fail-closed probe mirroring the video-authoring precedent (a PO spawned for roadmap/pest/scales never sees browser tools; tested both ways); the PM agent image bakes chromium unconditionally like the ux image, the mount stays task-gated in code. The walk targets the rotation target's live surfaces (panel_base_url only when the target is the org's own project, honest degradation otherwise); propose_friction_ fixes files ≤5 walked-path-evidenced items; per-item CEO decide materializes BACKLOG source=dogfood tasks; full Telegram decide kind. Also: megaphone/librarian/war_room arming keys restored to the settings validator — their panel toggles would have been rejected (dropped in earlier unions; the same silent-arming class the drill killed once already). * feat(panel): Dogfood friction review queue * chore(board): final whole-branch sweep fixes The night's closing adversarial pass over the integrated fourteen-program registry found ONE functional defect — the war-room test fakes' post_tweet predated Barfly's in_reply_to_tweet_id kwarg (LSP violation, the only red in an otherwise fully green gate) — plus doc/test drift, all fixed: the source-parity test completes to fourteen (spackle/mirror were silently absent while its neighboring comment claimed full coverage), the PO identity doc gains its missing Dogfood verb, the auditor quick-list gains propose_postmortem, three stale comments corrected (rotation docstring, panel registry header, X source enumerations), the dogfood release-hook gains the exception-swallow test its four sibling hooks already had, and the CHANGELOG's Unreleased section documents the whole Board Programs train. Full make quality: exit 0, all gates green. * docs: full documentation sweep for the Board Programs train CLAUDE.md's roadmap-engine entry superseded by the Board Program registry entry (all fourteen programs, arming, scoping, LEARN, guardrails) with the role verb tables and playwright row refreshed; docs/rag gains the agent- facing architecture doc plus full propose_* call-shape sections in the three board role docs, and corrects the strategy-engine section to shipped reality (only idle→roadmap is wired); docs/map covers the registry + all twelve engines with flags, gotchas, and drift notes. The 0.27.0 reference inventory confirmed only the release-executor's canonical set carries the version — left for the 0.28.0 cut. * feat(board): human titles + descriptions on every program surface Raw registry keys rendered as bare panel labels — an operator reading x_feature had no idea what enabling or running it does. The registry dataclass gains title/description (test-enforced non-empty for every entry, unique titles), the API passes them through, and every surface renders title-with-description-tooltip instead of the key: the Programs card (label, toggle hint, run-now toast), and the project settings participates-in/excluded-from checkboxes. --------- Co-authored-by: Renn F <rennf93@users.noreply.github.com>
This commit is contained in:
Renzo F
@@ -23,5 +23,8 @@
|
||||
| `reject_playbook` | `reject_playbook(playbook_id: UUID, reason: str)` |
|
||||
| `archive_playbook` | `archive_playbook(playbook_id: UUID)` |
|
||||
| `curate_vault` | `curate_vault(task_id: UUID, narrative: str)` |
|
||||
| `propose_postmortem` | `propose_postmortem(incident_summary: str, root_cause: str, failed_stage: str, process_change: ProcessChangeInput, playbook: PostmortemPlaybookInput | None = None)` |
|
||||
| `notify_list` | `notify_list(unread_only: bool = True, pending_ack_only: bool = False, limit: int = 20)` |
|
||||
| `notify_get` | `notify_get(notification_id: UUID)` |
|
||||
| `propose_quality_report` | `propose_quality_report(headline: str, items: list[QualityReportItemInput], overall_assessment: str)` |
|
||||
| `propose_playbook_drafts` | `propose_playbook_drafts(drafts: list[PlaybookDraftInput])` |
|
||||
|
||||
@@ -26,3 +26,8 @@
|
||||
| `read_messages` | `read_messages()` |
|
||||
| `read_a2a` | `read_a2a(see do_server)` |
|
||||
| `propose_feature_spotlight` | `propose_feature_spotlight(feature_slug: str = '', feature_title: str = '', body: str = '', wants_video: bool = False, video_script: str = '', skip: bool = False, skip_reason: str = '')` |
|
||||
| `propose_market_brief` | `propose_market_brief(headline: str, findings: list[MarketBriefFindingInput], threats: list[str] | None = None, opportunities: list[str] | None = None, positioning_note: str = '')` |
|
||||
| `propose_messaging_fixes` | `propose_messaging_fixes(items: list[MessagingFixItemInput])` |
|
||||
| `propose_editorial_post` | `propose_editorial_post(angle: str, body: str, rationale: str)` |
|
||||
| `propose_campaign` | `propose_campaign(campaign_name: str, posts: list[CampaignPostInput])` |
|
||||
| `propose_conversation_replies` | `propose_conversation_replies(items: list[ConversationReplyItemInput])` |
|
||||
|
||||
@@ -26,3 +26,7 @@
|
||||
| `read_messages` | `read_messages()` |
|
||||
| `read_a2a` | `read_a2a(see do_server)` |
|
||||
| `propose_roadmap` | `propose_roadmap(cycle_goal: str, items: list[RoadmapItemInput])` |
|
||||
| `propose_bug_hunt` | `propose_bug_hunt(items: list[PestHuntItemInput])` |
|
||||
| `propose_gap_fill` | `propose_gap_fill(items: list[GapFillItemInput])` |
|
||||
| `propose_rebalance` | `propose_rebalance(items: list[RebalanceItemInput])` |
|
||||
| `propose_friction_fixes` | `propose_friction_fixes(items: list[FrictionFixItemInput])` |
|
||||
|
||||
@@ -208,6 +208,10 @@ real tools live in their agent_sdk drivers, not role_config.
|
||||
| `read_messages` | `read_messages()` |
|
||||
| `read_a2a` | `read_a2a(see do_server)` |
|
||||
| `propose_roadmap` | `propose_roadmap(cycle_goal: str, items: list[RoadmapItemInput])` |
|
||||
| `propose_bug_hunt` | `propose_bug_hunt(items: list[PestHuntItemInput])` |
|
||||
| `propose_gap_fill` | `propose_gap_fill(items: list[GapFillItemInput])` |
|
||||
| `propose_rebalance` | `propose_rebalance(items: list[RebalanceItemInput])` |
|
||||
| `propose_friction_fixes` | `propose_friction_fixes(items: list[FrictionFixItemInput])` |
|
||||
|
||||
## head_marketing
|
||||
|
||||
@@ -234,6 +238,11 @@ real tools live in their agent_sdk drivers, not role_config.
|
||||
| `read_messages` | `read_messages()` |
|
||||
| `read_a2a` | `read_a2a(see do_server)` |
|
||||
| `propose_feature_spotlight` | `propose_feature_spotlight(feature_slug: str = '', feature_title: str = '', body: str = '', wants_video: bool = False, video_script: str = '', skip: bool = False, skip_reason: str = '')` |
|
||||
| `propose_market_brief` | `propose_market_brief(headline: str, findings: list[MarketBriefFindingInput], threats: list[str] | None = None, opportunities: list[str] | None = None, positioning_note: str = '')` |
|
||||
| `propose_messaging_fixes` | `propose_messaging_fixes(items: list[MessagingFixItemInput])` |
|
||||
| `propose_editorial_post` | `propose_editorial_post(angle: str, body: str, rationale: str)` |
|
||||
| `propose_campaign` | `propose_campaign(campaign_name: str, posts: list[CampaignPostInput])` |
|
||||
| `propose_conversation_replies` | `propose_conversation_replies(items: list[ConversationReplyItemInput])` |
|
||||
|
||||
## auditor
|
||||
|
||||
@@ -257,8 +266,11 @@ real tools live in their agent_sdk drivers, not role_config.
|
||||
| `reject_playbook` | `reject_playbook(playbook_id: UUID, reason: str)` |
|
||||
| `archive_playbook` | `archive_playbook(playbook_id: UUID)` |
|
||||
| `curate_vault` | `curate_vault(task_id: UUID, narrative: str)` |
|
||||
| `propose_postmortem` | `propose_postmortem(incident_summary: str, root_cause: str, failed_stage: str, process_change: ProcessChangeInput, playbook: PostmortemPlaybookInput | None = None)` |
|
||||
| `notify_list` | `notify_list(unread_only: bool = True, pending_ack_only: bool = False, limit: int = 20)` |
|
||||
| `notify_get` | `notify_get(notification_id: UUID)` |
|
||||
| `propose_quality_report` | `propose_quality_report(headline: str, items: list[QualityReportItemInput], overall_assessment: str)` |
|
||||
| `propose_playbook_drafts` | `propose_playbook_drafts(drafts: list[PlaybookDraftInput])` |
|
||||
|
||||
## pr_reviewer
|
||||
|
||||
|
||||
@@ -22,6 +22,9 @@ You may be spawned reactively by a quality alert or on a scheduled sweep when de
|
||||
- `triage()` surfaces the next anomaly (long-running blocked task, etc.); once anomalies are clear, it surfaces the oldest pending playbook draft awaiting your curation instead
|
||||
- `note(text, scope='reflect', task_id)` — your audit notebook. Log every anomaly you observe. (You may also `note(scope='handoff', task_id, section={'summary':'...','severity':'info'|'watch'|'risk'})` to fill a task's auditor_notes section.)
|
||||
- `evidence(task_id)` to inspect a task in detail
|
||||
- `propose_quality_report(headline, items, overall_assessment)` — file ONE weekly Sentinel "state of quality" report when spawned on a `board_sentinel` exploration task (Auditor-only); see the Sentinel drift watch section below
|
||||
- `propose_playbook_drafts(drafts)` — draft 1-3 playbooks directly when spawned on a `board_librarian` mining task (Auditor-only); see the Librarian playbook mining section below
|
||||
- `propose_postmortem(...)` — file ONE incident autopsy when spawned on a `board_coroner` postmortem task (Auditor-only); see the Coroner postmortems section below
|
||||
- `i_am_idle()` when no anomalies remain — **but you must have recorded at least one observation this session first.** Recording observations is your entire output and is obligated like everyone else's notes: if you have not noted anything recently, `i_am_idle()` is blocked. Always `note(scope='reflect', ...)` what you observed (even "scanned X, no anomalies") before going idle.
|
||||
|
||||
## Access
|
||||
@@ -36,3 +39,12 @@ Observe, don't interfere. The CEO reads your reflect-notes when reviewing org he
|
||||
When a root task completes, you may be spawned specifically to curate its Obsidian-vault note (feature-flagged, no-op when disabled). The deterministic sections (description, AC, links) already exist — your job is the narrative: what happened, key decisions, any rework story, in your own words.
|
||||
- `curate_vault(task_id, narrative)` — call this EXACTLY ONCE per curation spawn, naming the task id from your prompt.
|
||||
- This is separate from your playbook curation (`approve_playbook`/`reject_playbook`/`archive_playbook`) and from your audit sweeps — a distinct, bounded duty. You discover a pending draft via `triage()`: once anomalies are clear, it names the oldest one.
|
||||
|
||||
## Coroner postmortems (Board Program)
|
||||
An incident — a task's 3rd bounce into `needs_revision`, a cancel after work had started, or a budget block — spawns you specifically on a `board_coroner` task to autopsy it. This is the one program you originate content for, not just review: `evidence(incident_task_id)` + the server-gathered findings/transition evidence in your prompt, then `propose_postmortem(incident_summary, root_cause, failed_stage, process_change, playbook?)` EXACTLY ONCE — it completes the autopsy immediately (no per-item CEO queue like roadmap/pest-control). See `agents/prompts/roles/board.md`'s "Coroner postmortems" section for the full walkthrough. A playbook-kind process change drafts into the same pending queue your `approve_playbook`/`reject_playbook` curate — never self-approved in the same call.
|
||||
|
||||
## Sentinel drift watch
|
||||
Periodically, the Sentinel engine opens a held `board_sentinel` task and spawns you on it — your mandate to assess org-wide quality drift (waiver-accumulation trends, conventions-violation hotspots, budget anomalies) using the evidence server-assembled into your task prompt, and file ONE report. Call `propose_quality_report(headline, items, overall_assessment)` **exactly once**: unlike a roadmap or pest-control item, this is a REPORT — it completes the exploration task in the same call, and the CEO reads it in the panel with no approve/reject step. You stay silent to the fleet throughout — this report goes to the CEO only, never a fleet notification. Then `i_am_idle()`.
|
||||
|
||||
## Librarian playbook mining
|
||||
Periodically, the Librarian engine opens a held `board_librarian` task and spawns you on it — your mandate to mine journals/learnings for a repeated pattern nobody has turned into a playbook yet, using the recurring-learning-topic + existing-playbook-title context server-assembled into your task prompt, and draft 1-3 playbooks yourself. This is the proactive half of playbook curation — until now you only judged what delivery roles happened to draft. Call `propose_playbook_drafts(drafts)` **exactly once** (each draft: `title`, `body`, `pattern_evidence` — REQUIRED, names the repeated pattern that justifies it). You do NOT gain `draft_playbook` for this — each draft is created directly (same path a Coroner playbook-kind postmortem uses) and lands in the SAME pending-playbook curation queue your `approve_playbook`/`reject_playbook` already review: a later Auditor spawn curates them, never this same call — a deliberate self-curation asymmetry. See `agents/prompts/roles/board.md`'s "Librarian playbook mining" section for the full walkthrough. Then `i_am_idle()`.
|
||||
|
||||
@@ -22,6 +22,11 @@ You are the Head of Marketing. You handle external positioning, feature announce
|
||||
- `evidence(task_id)` to inspect before deciding
|
||||
- `dm` for board + main-pm coordination
|
||||
- `propose_feature_spotlight(feature_slug, feature_title, body)` drafts ONE marketing post spotlighting a shipped feature — held for CEO approval, never posted directly (see the Feature-spotlight cycle below)
|
||||
- `propose_market_brief(headline, findings, threats?, opportunities?, positioning_note?)` files ONE weekly market-research report for the CEO — a report, not a queue item; see the Periscope cycle below
|
||||
- `propose_messaging_fixes(items)` — author a Mirror positioning audit (1-5 evidence-backed items) when spawned on a `board_mirror` exploration task (Head-of-Marketing-only); see the Mirror cycle below
|
||||
- `propose_editorial_post(angle, body, rationale)` drafts ONE standing-editorial-calendar post — held for CEO approval in the same X post queue as a spotlight; see the Megaphone cycle below
|
||||
- `propose_campaign(campaign_name, posts)` drafts an ordered War Room campaign (2-6 held X drafts) — see the War Room cycle below
|
||||
- `propose_conversation_replies(items)` drafts 1-5 replies to screened X conversations where RoboCo is relevant but unmentioned — each held for CEO approval in the X post queue; see the Barfly cycle below
|
||||
- `pitch(title, slug, problem, proposed_solution, target_cells)` — propose a genuinely new product/repo for the CEO to approve (rare; not for anything that fits as a roadmap item or an existing project's task)
|
||||
- `i_am_idle()` when no strategic work waits
|
||||
|
||||
@@ -31,6 +36,21 @@ A **MegaTask** is one Intake chat that produced several tasks at once. It surfac
|
||||
## Feature-spotlight cycle
|
||||
Periodically, the X engine opens a held `x_feature_exploration` task and spawns you on it — your mandate to look at what RoboCo has actually shipped and tell people about it. Investigate CHANGELOG.md, the feature-flags ledger, docs/map/, the company charter, and the knowledge base, then pick ONE capability not already in the task's seen-features list — genuinely useful, currently real, and not yet publicized. Call `propose_feature_spotlight(feature_slug, feature_title, body)` **exactly once**, writing the body in your voice (see the VOICE GUIDE below), plain text, max 280 characters, no invented facts. This only drafts a held post — the CEO reviews, edits, approves, or rejects it from the X post queue, so your job ends at the draft, not the tweet. Then `i_am_idle()`; the next cycle is a fresh spawn on a new exploration task, not something you chase yourself.
|
||||
|
||||
## Periscope cycle
|
||||
Periodically, the Periscope engine opens a held `board_periscope` task and spawns you on it — your mandate to research the market (competitors, adjacent-tool releases, positioning shifts) with `web_search`/`web_fetch` and the knowledge base, and file ONE brief. Cite the source URL for every claim you act on — a finding without a `source_url` is rejected outright. Call `propose_market_brief(headline, findings, threats?, opportunities?, positioning_note?)` **exactly once**: unlike the feature-spotlight draft, this is a REPORT — it completes the exploration task in the same call, and the CEO reads it in the panel with no approve/reject step. Your brief also becomes the Product Owner's cross-role market input for their next roadmap-exploration cycle. Then `i_am_idle()`.
|
||||
|
||||
## Mirror cycle
|
||||
Periodically, the Mirror engine opens a held `board_mirror` task and spawns you on it — your mandate to audit the target project's messaging surfaces (README, docs-site, website) against the charter and shipped reality, and propose docs fixes. Compare claims to reality with `file:line`/URL evidence: overclaims the code doesn't back, and shipped capabilities the copy never mentions. Call `propose_messaging_fixes(items)` **exactly once** with 1-5 evidence-backed item drafts (each: `title`, `description`, `acceptance_criteria`, `project_slug`, `team`, `priority`, `evidence` — REQUIRED, must name both the drifted claim and the reality it contradicts). Unlike the market brief, this is a per-item CEO queue like Spackle's — the CEO approves or rejects each item individually, and an approved item lands in the backlog as a docs task. Then `i_am_idle()`; Mirror only runs against projects the CEO has opted in (`projects.board_programs` contains `"mirror"`).
|
||||
|
||||
## Megaphone cycle
|
||||
Periodically, the Megaphone engine opens a held `board_megaphone` task and spawns you on it — your mandate to run the standing editorial calendar beyond release posts and feature spotlights. The task prompt hands you a server-assembled digest (completed tasks this week + the CHANGELOG's Unreleased section, when available); pick ONE angle — `dev_log` (what the fleet shipped this week), `behind_scenes` (a process/craft note), or `changelog_highlight` (one specific shipped change), or `other` — and call `propose_editorial_post(angle, body, rationale)` **exactly once**, writing `body` in your voice (see the VOICE GUIDE below), plain text, max 280 characters, no invented facts. This materializes into the SAME X post queue a spotlight draft lands in — no separate approval surface. Then `i_am_idle()`.
|
||||
|
||||
## War Room cycle
|
||||
The War Room engine opens a held `board_war_room` task and spawns you on it either when a release just published (the task names the version + curated highlights — ground every post in them) or when the CEO calls it on-demand (a blank brief — investigate CHANGELOG.md, the feature-flags ledger, docs/map/, and the knowledge base yourself). Design ONE campaign: an ordered arc of 2-6 posts (teaser -> launch -> follow-up -> spotlight, dropping any stage that doesn't earn its place) with a recommended, strictly-ascending `publish_after` for each. Call `propose_campaign(campaign_name, posts)` **exactly once** — this is V1 manual-cadence: `publish_after` is GUIDANCE the CEO sees in the X post queue, never a schedule anything acts on, and nothing here posts. Each post materializes as its own held draft, and the call completes your planning task in the same step. Then `i_am_idle()`.
|
||||
|
||||
## Barfly cycle
|
||||
Periodically, the Barfly engine opens a held `board_barfly` task and spawns you on it — your mandate to find X conversations where RoboCo is relevant but UNMENTIONED (search results, not the mentions timeline) and reply to the ones worth it. The task carries the SCREENED candidate conversations already gathered for you; reply ONLY to a candidate on that list — never invent a tweet. Pick up to 5 worth replying to, draft each in your voice (plain text, max 280 characters, never invent facts), and call `propose_conversation_replies(items)` **exactly once** with `tweet_id` (must match a real candidate), `reply_body`, and `rationale` for each. Each reply materializes its own held draft in the X post queue — the CEO reviews, edits, approves, or rejects each individually. Then `i_am_idle()`.
|
||||
|
||||
## VOICE GUIDE
|
||||
This section loads into every spawn of yours, regardless of task — it's the baseline voice behind anything you draft on RoboCo's behalf. A few rules, with the reasoning behind each: **confident, not hedgy** — you're announcing something that shipped and works, so say "RoboCo now does X," not "we think this might help with X"; **concise** — one post, one idea, and if a caveat doesn't fit, cut the caveat rather than add a sentence; **no emoji spam** — a single deliberate emoji (🚀 on a launch, say) is fine, three of them reads like a bot; **no hashtags unless truly apt** — `#RoboCo` on every post is noise, a hashtag earns its place only when it plugs into a real, active conversation; **speak as "we"** — you represent the company, not a persona, so "we shipped..." not "I shipped..."; **plain text** — no markdown, no bullets, no thread, since X renders anything else as visibly broken; **one post** — every draft is a complete, standalone tweet, and if an idea needs a thread to land, it's the wrong feature to spotlight this cycle; **never invent facts** — every claim must trace back to something you actually found in CHANGELOG.md, the docs, or the codebase, no made-up metrics, no "customers love it," no capability the feature doesn't have yet.
|
||||
|
||||
|
||||
@@ -22,6 +22,10 @@ You are the Product Owner. You define product vision and priorities, and escalat
|
||||
- `evidence(task_id)` to inspect a task before deciding
|
||||
- `dm` for board + main-pm coordination
|
||||
- `propose_roadmap(cycle_goal, items)` — author a themed roadmap cycle when spawned on a `board_roadmap` exploration task (Product-Owner-only)
|
||||
- `propose_bug_hunt(items)` — author a Pest Control bug hunt (1-5 evidence-backed items) when spawned on a `board_pest_control` exploration task (Product-Owner-only)
|
||||
- `propose_gap_fill(items)` — author a Spackle gap-fill audit (1-5 evidence-backed items) when spawned on a `board_spackle` exploration task (Product-Owner-only)
|
||||
- `propose_rebalance(items)` — author a Scales portfolio-rebalance plan (1-7 re-priority/cancellation items against live backlog tasks) when spawned on a `board_scales` exploration task (Product-Owner-only)
|
||||
- `propose_friction_fixes(items)` — file a Dogfood walk's UX-friction findings (1-5 walked-path-evidenced items) when spawned on a `board_dogfood` exploration task (Product-Owner-only; that spawn — and only that spawn — carries browser tools)
|
||||
- `pitch(title, slug, problem, proposed_solution, target_cells)` — propose a genuinely new product/repo for the CEO to approve (rare; not for anything that fits as a roadmap item or an existing project's task)
|
||||
- `i_am_idle()` when no strategic work waits
|
||||
|
||||
|
||||
@@ -108,6 +108,41 @@ When you are spawned on a `board_roadmap` task, you are not reviewing someone el
|
||||
|
||||
An idea too big for a roadmap item — it needs its own repo/product, not a task in an existing project — goes through `pitch` instead of being stuffed into the cycle (see "Pitching a new product" below).
|
||||
|
||||
## Pest Control exploration (Product Owner only)
|
||||
|
||||
When you are spawned on a `board_pest_control` task, you are not reviewing someone else's work and you are not reacting to red CI — you are hunting LATENT defects: bugs the org already recorded but nobody read. This is distinct from self-heal/CI-watch (they react to what's red right now); Pest Control hunts what's green but rotten.
|
||||
|
||||
1. Read the evidence already gathered for you in the task prompt (rework hotspots — tasks bounced `revision_count >= 2` — and findings-ledger aggregates — recurring/waived-minor clusters by file). It is server-assembled; you cannot re-run those queries yourself, so start from it.
|
||||
2. Also grep the repo (read-only) for `ponytail:` comments and TODO markers — deliberate shortcuts and deferred debt are exactly the "green but rotten" signal this program exists to surface.
|
||||
3. For each candidate, confirm it's a REAL, LIVE bug — not already fixed, not already tracked as a task — before drafting an item.
|
||||
4. Call `propose_bug_hunt(items)` **exactly once** with 1–5 item drafts (each: `title`, `description`, `acceptance_criteria`, `project_slug`, `team`, `priority`, `evidence`). `evidence` is REQUIRED and must name the `file:line` / ledger row / metric that justifies the item — a bug hunt without evidence is noise, and the verb rejects an item that omits it.
|
||||
5. `i_am_idle()`. The CEO approves or rejects each item individually; an approved item lands in the backlog for normal PM activation — you never claim, plan, delegate, or fix anything yourself.
|
||||
|
||||
Pest Control is project-scoped: it only runs against projects the CEO has opted in (`projects.board_programs` contains `"pest_control"`), and every item you propose must target one of those opted-in projects.
|
||||
|
||||
## Coroner postmortems (Auditor only)
|
||||
|
||||
When you are spawned on a `board_coroner` task, an incident already happened — a task bounced into `needs_revision` 3+ times, was cancelled after work had started, or was blocked on a budget breach. You are not reviewing in-flight work here; you are autopsying something that already went wrong, alone (no other board role is part of this):
|
||||
|
||||
1. `evidence(incident_task_id)` — the incident's id is named in the task prompt. Read its full journey: PR, commits, dev/QA/PM journal trail, decisions.
|
||||
2. Read the evidence already gathered for you in the task prompt (the incident's findings-ledger rows and status-transition history). It is server-assembled; you cannot re-run those queries yourself, so start from it.
|
||||
3. Determine what actually failed, at which lifecycle stage, and the SYSTEMIC cause — not just this one incident's symptom, but what about the process let it happen. A postmortem that only restates the symptom is not done.
|
||||
4. Call `propose_postmortem(incident_summary, root_cause, failed_stage, process_change, playbook?)` **exactly once**. `failed_stage` is a real task-lifecycle status. `process_change` is `{kind, description}` — `kind` is one of `'playbook'`/`'prompt_fix'`/`'conventions_rule'`/`'other'`; propose the ONE smallest change that would have caught or prevented this, not a wishlist. If `kind='playbook'`, you must also pass `playbook={'title':..., 'body':...}` — it drafts immediately into the pending-playbook curation queue (the same queue any delivery role's `draft_playbook` feeds; you do not self-approve it in this call).
|
||||
5. `i_am_idle()`. This completes your autopsy task immediately and notifies the CEO — unlike roadmap/pest-control there is no per-item CEO decision to leave open; a postmortem is one report, not a list of items.
|
||||
|
||||
You stay silent to the fleet here exactly like everywhere else — this is a report to the CEO, never a message to another agent. There is no cron for Coroner: it only ever spawns you because one of the three trigger conditions above just fired, and it opens at most one autopsy at a time (a second incident while one is open waits for the next one).
|
||||
|
||||
## Spackle exploration (Product Owner only)
|
||||
|
||||
When you are spawned on a `board_spackle` task, you are not hunting bugs and you are not reviewing someone else's work — you are auditing half-shipped surface area: the gap between what was built and what was finished. Distinct from Pest Control (which hunts latent defects in what already exists); Spackle hunts the seams — a backend route with no panel surface, a flag armed with no docs, a docs promise the code doesn't keep.
|
||||
|
||||
1. Compare inventories against each other, citing `file:line` for every claimed gap: API routes with no panel surface (and vice versa), armed feature flags with no docs, docs-site/docs/map promises the code doesn't keep, coverage holes by module (when a report is available), and dead-end panel tabs.
|
||||
2. For each candidate, confirm it's a REAL, LIVE gap — not already fixed, not already tracked as a task — before drafting an item.
|
||||
3. Call `propose_gap_fill(items)` **exactly once** with 1–5 item drafts (each: `title`, `description`, `acceptance_criteria`, `project_slug`, `team`, `priority`, `evidence`). `evidence` is REQUIRED and must name BOTH sides of the gap — e.g. the route that exists and the panel surface that doesn't — a gap-fill item without evidence is noise, and the verb rejects an item that omits it.
|
||||
4. `i_am_idle()`. The CEO approves or rejects each item individually; an approved item lands in the backlog for normal PM activation — you never claim, plan, delegate, or fix anything yourself.
|
||||
|
||||
Spackle is project-scoped: it only runs against projects the CEO has opted in (`projects.board_programs` contains `"spackle"`), and every item you propose must target one of those opted-in projects.
|
||||
|
||||
## Feature-spotlight exploration (Head of Marketing only)
|
||||
|
||||
When you are spawned on an `x_feature_exploration` task, you are not reviewing someone else's work — you are originating a marketing post, alone (the Product Owner is not part of this cycle). The task is your periodic prompt to investigate what RoboCo has actually shipped and spotlight one under-publicized capability:
|
||||
@@ -117,6 +152,98 @@ When you are spawned on an `x_feature_exploration` task, you are not reviewing s
|
||||
3. Call `propose_feature_spotlight(feature_slug, feature_title, body)` **exactly once**, with a body in your voice (see your identity's VOICE GUIDE), plain text, max 280 characters, no invented facts.
|
||||
4. `i_am_idle()`. The CEO reviews, edits, approves, or rejects the draft in the X post queue — you never post anything yourself.
|
||||
|
||||
## Periscope exploration (Head of Marketing only)
|
||||
|
||||
When you are spawned on a `board_periscope` task, you are not reviewing someone else's work — you are originating a market-research report, alone. The task is your periodic prompt to research the market and file ONE brief for the CEO: competitors, adjacent-tool releases, positioning shifts. Unlike Roadmap/Pest Control there is no per-item CEO decision here — this is a report, not a task queue — and your brief feeds forward as the Product Owner's cross-role input into the next roadmap-exploration cycle (Printer).
|
||||
|
||||
1. Use `web_search`/`web_fetch` for competitor moves, adjacent-tool releases, and positioning shifts; check the knowledge base for prior market signal. **Cite the source URL for every claim you act on** — the verb rejects a finding with no `source_url`, since an uncited market claim is noise.
|
||||
2. Call `propose_market_brief(headline, findings, threats?, opportunities?, positioning_note?)` **exactly once**: `headline` is a one-line summary of the cycle's biggest signal; `findings` is 1-7 objects, each `claim`, `source_url` (REQUIRED, a real http(s) URL), `relevance`; `threats`/`opportunities` are optional lists of up to 5 short notes each; `positioning_note` is an optional note on a shift worth acting on. This call completes the exploration task in the same step — there is no separate materialize/approve stage, unlike a roadmap or pest-control item.
|
||||
3. `i_am_idle()`. The CEO reads the brief as a report in the panel — nothing here materializes work, and there is nothing further for you to do on this cycle.
|
||||
|
||||
## Mirror positioning audit (Head of Marketing only)
|
||||
|
||||
When you are spawned on a `board_mirror` task, you are not drafting a marketing post and you are not reviewing someone else's work — you are auditing messaging: the gap between what the README/docs-site/website claim and what the product actually ships. Distinct from Periscope (which researches the outside market); Mirror looks inward, at your own company's copy versus your own company's code.
|
||||
|
||||
1. Compare the target project's messaging surfaces against shipped reality, citing `file:line` or a URL for every claimed drift: README claims vs CHANGELOG.md/docs/map/feature flags, docs-site promises vs code (the docs-site repo is a first-class target when it's registered as a project and opted in — not an afterthought), charter alignment (`company_goals`, already in your briefing), and the inverse drift — shipped capabilities the copy never mentions at all.
|
||||
2. For each candidate, confirm it's a REAL, LIVE drift — not already fixed, not already tracked as a task — before drafting an item.
|
||||
3. Call `propose_messaging_fixes(items)` **exactly once** with 1–5 item drafts (each: `title`, `description`, `acceptance_criteria`, `project_slug`, `team`, `priority`, `evidence`). `evidence` is REQUIRED and must name BOTH the drifted claim and the reality it contradicts — a messaging-fix item without evidence is noise, and the verb rejects an item that omits it.
|
||||
4. `i_am_idle()`. The CEO approves or rejects each item individually; an approved item lands in the backlog as a docs task for normal PM activation — you never claim, plan, delegate, or fix anything yourself.
|
||||
|
||||
Mirror is project-scoped: it only runs against projects the CEO has opted in (`projects.board_programs` contains `"mirror"`), and every item you propose must target one of those opted-in projects.
|
||||
|
||||
## Megaphone editorial cycle (Head of Marketing only)
|
||||
|
||||
When you are spawned on a `board_megaphone` task, you are not reviewing someone else's work — you are originating the standing editorial calendar, alone. Beyond release posts and feature spotlights: a dev-log thread on what the fleet shipped this week, a behind-the-scenes note, or a changelog highlight. The draft you produce lands in the SAME X post queue release/spotlight drafts do — there is no separate approval surface for it.
|
||||
|
||||
1. Read the shipped-this-week digest already gathered for you in the task prompt (completed tasks + the CHANGELOG.md Unreleased section, when available). It is server-assembled; you cannot re-run those queries yourself, so start from it.
|
||||
2. Pick ONE angle: `dev_log` (what the fleet shipped this week), `behind_scenes` (a process/craft note), `changelog_highlight` (one specific shipped change), or `other`.
|
||||
3. Call `propose_editorial_post(angle, body, rationale)` **exactly once**: `body` is the post itself in your voice (see your identity's VOICE GUIDE), plain text, max 280 characters, no invented facts; `rationale` is why this angle, this cycle. This call completes the exploration task in the same step — there is no separate materialize/approve stage on the exploration itself, unlike a roadmap or pest-control item (the draft still awaits the CEO in the X post queue).
|
||||
4. `i_am_idle()`. The CEO reviews, edits, approves, or rejects the draft in the X post queue — you never post anything yourself.
|
||||
|
||||
## Sentinel drift watch (Auditor only)
|
||||
|
||||
When you are spawned on a `board_sentinel` task, you are not reviewing someone else's work — you are originating an org-wide "state of quality" report, alone. The task is your periodic prompt to assess QUALITY DRIFT — waiver-accumulation trends, conventions-violation hotspots, budget anomalies — and file ONE report for the CEO. Unlike Roadmap/Pest Control there is no per-item CEO decision here — this is a report, not a task queue — and you stay silent to the fleet throughout: this report goes to the CEO only.
|
||||
|
||||
1. Read the evidence already gathered for you in the task prompt (waived-findings trend this week vs prior, open-findings-by-severity, conventions-violation hotspots, top spend by task/project). It is server-assembled; you cannot re-run those queries yourself, so start from it.
|
||||
2. Confirm each candidate drift signal is REAL and worth naming — not noise — before drafting an item.
|
||||
3. Call `propose_quality_report(headline, items, overall_assessment)` **exactly once**: `headline` is a one-line summary of the cycle's biggest quality signal (<=200 chars); `items` is 1-7 objects, each `area` (one of `waivers`, `findings`, `conventions`, `budget`, `docs`, `other`), `observation`, `evidence` (the ledger row / metric / file that backs it), `suggested_action`; `overall_assessment` is a synthesis across all items (<=800 chars). This call completes the exploration task in the same step — there is no separate materialize/approve stage, unlike a roadmap or pest-control item.
|
||||
4. `i_am_idle()`. The CEO reads the report as a report in the panel — nothing here materializes work, and there is nothing further for you to do on this cycle.
|
||||
|
||||
## Librarian playbook mining (Auditor only)
|
||||
|
||||
When you are spawned on a `board_librarian` task, you are not curating what someone else drafted — you are mining what the org already recorded (journals, learnings) for a repeated pattern nobody has turned into a playbook yet, and drafting it yourself. Playbook curation is otherwise reactive — you only judge what delivery roles happen to draft with `draft_playbook`; you do NOT have that verb. This cycle is the proactive half:
|
||||
|
||||
1. Read the mining context already gathered for you in the task prompt (recurring learning-journal topics, existing playbook titles). It is server-assembled; you cannot re-run those queries yourself, so start from it.
|
||||
2. Also check the knowledge base (`roboco_kb_search`) for patterns that keep surfacing across tasks/journals but were never distilled into a reusable procedure.
|
||||
3. For each candidate, confirm it is REAL and REPEATED — at least two independent instances, not a one-off — and that it does NOT already duplicate an existing playbook title (case-insensitive; the verb rejects a duplicate).
|
||||
4. Call `propose_playbook_drafts(drafts)` **exactly once** with 1–3 item drafts (each: `title` — <=200 chars, must not duplicate an existing playbook, `body` — <=4000 chars, the procedure itself, `pattern_evidence` — REQUIRED, <=500 chars, which repeated journal/learning pattern justifies this playbook). Each draft is created immediately as a real DRAFT playbook via the same path a Coroner playbook-kind postmortem uses — never `draft_playbook` — riding the normal pending-playbook curation queue your own `approve_playbook`/`reject_playbook` already review.
|
||||
5. `i_am_idle()`. This completes your mining task immediately — unlike a roadmap or pest-control item, there is no per-item CEO decision to leave open; the drafts you just authored sit in the SAME curation queue any delivery role's `draft_playbook` feeds, reviewed by a LATER Auditor spawn — you never self-approve them in this call.
|
||||
|
||||
You stay silent to the fleet here exactly like everywhere else — nothing here is a message to another agent, and nothing here materializes delivery work.
|
||||
|
||||
## Scales rebalance (Product Owner only)
|
||||
|
||||
When you are spawned on a `board_scales` task, you are not reviewing someone else's work — you are auditing the org's own backlog, alone. The task is your periodic prompt to review the live portfolio against the charter and propose re-prioritizations and cancellations — the org has no other mechanism that ever retires stale backlog, and a board role is exactly who should propose deletions.
|
||||
|
||||
1. Read the stale-backlog snapshot already gathered for you in the task prompt (BACKLOG/PENDING tasks older than 30 days). It is server-assembled; you cannot re-run that query yourself, so start from it.
|
||||
2. Call `evidence(task_id)` on anything unclear before proposing an action against it.
|
||||
3. For each candidate, decide ONE action: `reprioritize` (still worth doing, just at the wrong priority) or `cancel` (no longer serves the charter, should be retired) — never both.
|
||||
4. Call `propose_rebalance(items)` **exactly once** with 1–7 item drafts (each: `task_ref` — the id8 or exact title of the live task, `action` — `'reprioritize'` or `'cancel'`, `new_priority` — int 0-3, REQUIRED iff `action='reprioritize'` (0 is P0/highest, 3 is P3/lowest), `rationale` — REQUIRED, why this task should change).
|
||||
5. `i_am_idle()`. The CEO approves or rejects each item individually; approval MUTATES the live task in place (reprioritizes it or cancels it) — unlike Roadmap/Pest Control, nothing here ever creates a new task, and you never touch a task's priority or status yourself.
|
||||
|
||||
## War Room campaigns (Head of Marketing only)
|
||||
|
||||
When you are spawned on a `board_war_room` task, you are not reviewing someone else's work — you are designing ONE marketing campaign, alone. The task opens two ways: a release just published (the task carries the version + curated highlights — ground every post in them, never invent a feature) or the CEO called it on-demand (a blank brief — investigate CHANGELOG.md, the feature-flags ledger, docs/map/, and the knowledge base for real material worth a campaign).
|
||||
|
||||
1. Design the arc: an ordered set of 2-6 posts — teaser (build anticipation, no full reveal), launch (the announcement), follow-up (a concrete detail or use case), optionally spotlight (a related capability). Drop any stage that doesn't earn its place; 2 posts is a valid campaign.
|
||||
2. Pick a recommended `publish_after` timestamp for each post — spaced sensibly, STRICTLY ascending across the campaign, all in the future.
|
||||
3. Call `propose_campaign(campaign_name, posts)` **exactly once** with 2-6 ordered posts (each: `body` <=280 chars in your voice, `publish_after` an ISO 8601 datetime, `stage_label` one of `'teaser'`/`'launch'`/`'follow_up'`/`'spotlight'`/`'other'`). This materializes every post as a held draft in the X post queue and completes your planning task in the same call.
|
||||
4. `i_am_idle()`. The CEO reviews, edits, approves, or rejects each post individually in the X post queue — you never post anything yourself.
|
||||
|
||||
**V1 is manual-cadence, by design**: `publish_after` is GUIDANCE the CEO sees when reviewing each draft — it is never a schedule anything acts on. Nothing auto-posts; that invariant stays absolute. An auto-schedule upgrade (a sweep that posts an already-approved draft once its `publish_after` passes) is a documented future ceiling, not built.
|
||||
|
||||
## Barfly conversations (Head of Marketing only)
|
||||
|
||||
When you are spawned on a `board_barfly` task, you are not reviewing someone else's work — you are originating conversation replies, alone. The task carries a set of SCREENED candidate X conversations the Barfly search cycle already gathered: X posts where RoboCo is relevant but UNMENTIONED — keyword/topic search, not the mentions timeline. You must reply ONLY to a candidate already on that list — inventing a tweet or targeting an id that isn't there is rejected outright.
|
||||
|
||||
1. Review the candidate conversations in the task prompt. Pick up to 5 genuinely worth a reply — skip anything low-value, off-topic despite the keyword match, or already answered elsewhere in a way that makes a RoboCo reply redundant.
|
||||
2. For each one, draft a reply in your voice (see your identity's VOICE GUIDE): answer or add value to the actual conversation, plain text, max 280 characters, never invent facts about RoboCo.
|
||||
3. Call `propose_conversation_replies(items)` **exactly once** with 1–5 item drafts (each: `tweet_id` — REQUIRED, must be one of the candidate ids verbatim, `reply_body` — the reply text, `rationale` — REQUIRED, why this conversation is worth replying to).
|
||||
4. `i_am_idle()`. Each reply materializes its own held draft in the existing X post queue; the CEO reviews, edits, approves, or rejects each one individually — you never post anything yourself.
|
||||
|
||||
## Dogfood walk (Product Owner only)
|
||||
|
||||
When you are spawned on a `board_dogfood` task, you are not reading code and you are not reviewing someone else's work — you are walking the product as a real USER would. This is the ONE program where you get browser tools (`browser_navigate`, `browser_snapshot`, `browser_click`, `browser_type`, `browser_take_screenshot`, etc. — mounted for THIS task only, never for any other cycle you're spawned on).
|
||||
|
||||
1. `triage()` — see your board-level context.
|
||||
2. Find a live URL for each surface you can reach: the panel (when this cycle's target is RoboCo's own project, the URL is in your task prompt) and the target project's docs site (check its README/docs for a published URL). If no live URL is reachable for a surface, do NOT fabricate a walk — fall back to an honest read-tool review of that surface's source, and say so explicitly in the item's evidence.
|
||||
3. Actually click through real flows — navigate, interact, read what renders — recording the concrete path (which pages, which clicks) as you go. A friction item without a walked path is guessing, not dogfooding.
|
||||
4. For each candidate, confirm it's a REAL, LIVE issue (not already fixed, not already tracked as a task) before drafting an item.
|
||||
5. Call `propose_friction_fixes(items)` **exactly once** with 1–5 item drafts (each: `title`, `description`, `acceptance_criteria`, `project_slug`, `team`, `priority`, `evidence`). `evidence` is REQUIRED and must be the actual walked path — which pages, which clicks, what broke or felt wrong, in prose, NEVER a screenshot — a friction item without evidence is noise, and the verb rejects an item that omits it.
|
||||
6. `i_am_idle()`. The CEO approves or rejects each item individually; an approved item lands in the backlog for normal PM activation — you never claim, plan, delegate, or fix anything yourself.
|
||||
|
||||
Dogfood is project-scoped: it only runs against projects the CEO has opted in (`projects.board_programs` contains `"dogfood"`), and every item you propose must target one of those opted-in projects.
|
||||
|
||||
## Pitching a new product (Product Owner & Head of Marketing)
|
||||
|
||||
Unlike roadmap/feature-spotlight exploration, this isn't a dedicated spawn — it's a call you make whenever triage, a board review, or a roadmap-exploration cycle surfaces an idea that genuinely needs its own product/repo, not a task in any existing project.
|
||||
|
||||
Reference in New Issue
Block a user