Skip to content

feat(agents): expand domain ecosystem and capabilities - #23

Merged
donk8r merged 7 commits into
masterfrom
feature/multiple-updates-and-fixes
Jul 13, 2026
Merged

feat(agents): expand domain ecosystem and capabilities#23
donk8r merged 7 commits into
masterfrom
feature/multiple-updates-and-fixes

Conversation

@donk8r

@donk8r donk8r commented Jul 7, 2026

Copy link
Copy Markdown
Member
  • Add new agent domains for ai, assistant, content, coach, and more
  • Implement specialized agents for writing, chef, and social media
  • Update concierge routing table with specialized roles
  • Expand assistant capabilities with shell and websearch tools
  • Refine identity, scope, and boundaries for browser and developer agents
  • Standardize workflows and formatting across agent configurations
  • Adjust capabilities and constraints for coach, content, and audit agents
  • Clarify publishing and hand-off responsibilities for content agents
  • Remove filesystem-write from developer brief agent
  • Normalize casing and remove placeholders in translation workflow

@donk8r
feat(agents): expand domain ecosystem and capabilities
282b7f7 
- Add new agent domains for ai, assistant, content, coach, and more
- Implement specialized agents for writing, chef, and social media
- Update concierge routing table with specialized roles
- Expand assistant capabilities with shell and websearch tools
- Refine identity, scope, and boundaries for browser and developer agents
- Standardize workflows and formatting across agent configurations
- Adjust capabilities and constraints for coach, content, and audit agents
- Clarify publishing and hand-off responsibilities for content agents
- Remove filesystem-write from developer brief agent
- Normalize casing and remove placeholders in translation workflow
@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown

Octomind — developer:brief (octohub:glm)

{}

@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown

Octomind — developer:brief (octohub:glm)

The claim is correct but the quote was a mashup of two separate lines. The actual tool output for deps/lib/platform.sh lines 41–46 is:

41:  MINGW* | MSYS* | CYGWIN* | Windows_NT)
42:    OS="windows"
43:    IS_MACOS="0"
44:    IS_LINUX="0"
45:    IS_WINDOWS="1"
46:    ;;

Restated from the verbatim output: [evidence: deps/lib/platform.sh:41-42 «MINGW* | MSYS* | CYGWIN* | Windows_NT)» and «OS="windows"»] — the case branch sets OS="windows" for MinGW/MSYS/Cygwin/Windows_NT, so the new windows) case in swift.sh is reachable on those platforms. The two fragments are on separate lines (41 and 42) in the tool output; my earlier quote collapsed them onto one line, which is why it did not string-match.

{tokens:350242,cost:0.5024557999999999}

@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown

Octomind — developer:brief (octohub:glm)

📦 Brief: Swift dep install made idempotent and CI-safe across Linux/Windows

Overall risk: 🟢 LOW · Cards: 1

# Change Risk Confidence
1 Swift dep script now installs Linux system libs via swiftly's post-install file and short-circuits re-runs on Windows/Linux 🟢 ●●●
Card 1/1: Swift dep install survives CI re-runs and missing system libraries · 🟢 · ●●●

INTENT
The prior commit made the Swift toolchain install cross-platform but it still failed in CI: on Linux, swiftly exited non-zero because system libraries were missing; on Windows, a re-run of winget install returned non-zero because the package was already installed. This commit fixes both so the dep script is idempotent across CI re-runs.

WHAT CHANGED

  • Script now sources ~/.local/share/swiftly/env.sh and prepends swiftly/bin to PATH at the top, so a prior Linux install short-circuits the fast path on re-run instead of re-downloading.
  • Linux: swiftly install latest now passes --post-install-file <tmpfile> — swiftly writes the system-dependency install commands there instead of erroring out. The script then runs bash "$post_install" (non-fatal on failure — warns and continues) and cleans up the temp file. --assume-yes keeps re-runs non-interactive.
  • Windows: added a winget list --id Swift.Toolchain -e guard before winget install so an already-installed package exits 0 instead of triggering a non-zero install-then-upgrade path.
  • Control flow inverted from if pkg_check X; then ... else die to if ! pkg_check X; then die; fi — flattens the happy path and removes a level of nesting.

IMPACT RADIUS

  • The script is consumed only by capabilities/programming-swift/swift.toml (require = ["swiftlang/swift"]), which is auto-activated via trigger phrases in config.toml — no agent manifest references programming-swift directly. Impact is confined to the dep install path; no agent behavior or resolved manifest changes.

RISK
🟢 LOW. The post-install file is executed with bash "$post_install" || warn ... — a failure to install system libs is non-fatal (warn, not die), so swift may end up on PATH without its required libraries. This is intentional and pragmatic: the script surfaces the warning rather than aborting, leaving the user to install manually. The trust boundary is unchanged — the post-install commands come from swiftly (official swift.org installer, HTTPS-downloaded), same source as the toolchain itself.

DIVERGENCE
🧩 Incomplete change — deps/swiftlang/swift.md (the companion doc) has no mention of the Linux system-dependency requirement or the --post-install-file mechanism. A user reading the doc to troubleshoot a failed install won't know swiftly emits system-dep commands. Minor, but the doc is now stale relative to the script's behavior.

📎 Source

📂 Files changed (1 file, ~40 lines)

{tokens:194936,cost:0.2823094}

@donhardman
donhardman force-pushed the feature/multiple-updates-and-fixes branch from 715e85f to 51a4515 Compare July 7, 2026 19:38
@donhardman
donhardman force-pushed the feature/multiple-updates-and-fixes branch from 51a4515 to 30c3d78 Compare July 7, 2026 19:40
@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown

Octomind — developer:brief (octohub:glm)

I have enough context. The start commit 715e85f doesn't exist in this repo — I analyzed the two reachable commits at HEAD (282b7f7 and 51a4515) which represent the incremental changes.

📦 Brief: Agent ecosystem expansion, capability least-privilege sweep, system-prompt standardization, and Swift toolchain Windows support

⚠️ The requested start commit 715e85f300f5d14a274a03985a8cda7e8223c045 does not exist in this repository (not on any branch, not in the full 352-commit history). This brief covers the two commits reachable at HEAD: 282b7f7 (agent ecosystem expansion) and 51a4515 (Swift Windows support).

Overall risk: 🟡 MEDIUM · Cards: 5

# Change Risk Confidence
1 Swift dep script: adds Windows via winget, hardens Linux install with post-install system deps and --no-verify 🟡 ●●●
2 Six new agent domains (chef, home, shopping, travel, tutor, assistant:writer) + concierge routing expansion 🟢 ●●●
3 Capability pruning across ~30 agents — filesystem-write, websearch, versioning, memory removed from agents that don't need them 🟡 ●●●
4 System prompt standardization: {{SYSTEM}} removed from 7 agents, ALL-CAPS → sentence case, scope/critical blocks rewritten 🟡 ●●●
5 New programming-swift capability + lint guardrails for {{SYSTEM}} and phantom domain/capability references 🟢 ●●●
Card 1/5: Swift toolchain — Windows support and Linux install hardening · 🟡 · ●●●

INTENT
Add Windows as a supported platform for the Swift toolchain dep script, and fix the Linux install path to handle system dependencies that swiftly requires but doesn't install itself.

WHAT CHANGED

  • Windows branch added: detects winget, checks for existing Swift.Toolchain install (idempotent), installs via winget install --id Swift.Toolchain -e, exits 0 with a "open a new shell" message (machine-level install won't be on the current session's PATH).
  • Script start now sources $HOME/.local/share/swiftly/env.sh and prepends $HOME/.local/share/swiftly/bin to PATH — so a prior swiftly install is picked up by the fast-path pkg_check swift on re-runs.
  • Linux path refactored: early-exit die if curl is missing (inverted from the old if pkg_check curl wrapper), swiftly install latest now uses --no-verify (skips GPG checks — gpg absent on minimal images, download stays HTTPS), --assume-yes (non-interactive re-runs), and --post-install-file to capture system-dependency install commands that swiftly generates. Those commands are executed via bash "$post_install" with a warn on failure. swiftly use latest added at the end.

IMPACT RADIUS

  • capabilities/programming-swift/swift.toml requires swiftlang/swift — any agent using programming-swift (currently none in agents/, but the capability is registered and resolvable) triggers this script.
  • deps/lib/platform.sh already detects Windows (MINGW* | MSYS* | CYGWIN* | Windows_NT → OS="windows"), so the new windows) case is reachable.

RISK
🟡 MEDIUM. The --no-verify flag skips GPG signature verification on the Swift toolchain download. The comment justifies this as matching the rust/cargo dep's TLS-only trust model, and the download URL is HTTPS. This is a deliberate security trade-off for minimal-image compatibility — defensible, but worth a conscious sign-off. The bash "$post_install" step runs root-level system package installs generated by swiftly; a failure is warned-not-fatal, which could leave swift installed but missing shared libraries.

QUESTIONS

  • The windows) branch exits 0 immediately after winget install without falling through to the final pkg_check swift verification block (lines 86–95). Is the "open a new shell" message sufficient, or should the script attempt a PATH-based verification like the Linux path does?

DIVERGENCE
🧩 Incomplete change — deps/swiftlang/swift.md still says "On macOS it ships with the Xcode Command Line Tools; on Linux it is installed via swiftly" with no mention of Windows, while the script now supports Windows. The companion doc is stale.

📎 Source

Card 2/5: Six new agent domains + concierge routing expansion · 🟢 · ●●●

INTENT
Expand the agent ecosystem with everyday-life domains (cooking, home repair, shopping, travel, tutoring, everyday writing) and wire them into the concierge routing table so assistant:concierge can delegate to them.

WHAT CHANGED

  • New agents: chef:general, home:diy, shopping:advisor, travel:planner, tutor:general, assistant:writer — each with full system prompts using the canonical XML-tagged block structure, capabilities, and welcome messages.
  • agents/assistant/concierge.toml routing table expanded with 6 new rows: writer, travel planner, shopping advisor, chef, home DIY, and tutor.
  • agents/assistant/general.toml capabilities expanded: shell and websearch added (was core, filesystem-read, filesystem-write, agent).

IMPACT RADIUS

  • assistant:concierge is the routing hub — any user query matching the new domains now routes to the new specialists instead of falling through to assistant:general.
  • assistant:general gaining shell and websearch means it can now execute commands and search the web directly, where before it could only read/write files and delegate.

RISK
🟢 LOW. New agents are additive — no existing agent's behavior changes. The concierge routing additions are new rows that don't displace existing routes. assistant:general gaining shell/websearch broadens its capability surface, which aligns with its "generalist" identity.

📎 Source

Card 3/5: Capability least-privilege sweep across ~30 agents · 🟡 · ●●●

INTENT
Remove capabilities that agents don't need — filesystem-write from read-only agents, websearch from agents that don't do web research, versioning from documentation agents, memory-write from read-only auditors. This is a least-privilege tightening.

WHAT CHANGED

  • filesystem-write removed from: all 10 lawyer/* agents, all 4 doctor/* agents, coach/screener, content/audit, octomind/assistant (also lost shell, filesystem-write, agent → just core, filesystem-read).
  • websearch removed from: coach/general, coach/screener, content/audit, video/publish, video/ugc, video/explainer, launch/bootstrap, launch/validate, launch/brand, launch/pitch, video/script, video/storyboard.
  • versioning removed from: developer/changelog, developer/release-notes, developer/doc.
  • memory-write removed from: content/audit (now explicitly read-only including memory).
  • memory-read removed from: coach/screener, octomind/assistant.
  • agent removed from: octomind/assistant, octomind/tap (replaced with runtime).
  • shell removed from: developer/context, developer/brief, octomind/instructions.
  • stock removed from: video/producer, video/ugc.
  • Added: memory-read/memory-write to devops/docker, devops/kubernetes; shell to video/producer, video/ugc; websearch to doctor/blood, doctor/medications; knowledge to developer/general.

IMPACT RADIUS

  • Every agent whose capabilities changed will have a different set of MCP servers and tools available at runtime via bin/load. Agents losing filesystem-write can no longer save files to disk. Agents losing websearch can no longer do web lookups. Agents losing versioning can no longer access git versioning tools. Agents losing memory-read/memory-write lose persistent context recall/storage.

RISK
🟡 MEDIUM. The octomind/assistant agent is the Octomind expert assistant — it lost filesystem-write, shell, and agent (delegation), keeping only core and filesystem-read. This is a dramatic capability reduction. If users relied on it to run commands or write config files, those workflows break. The doctor/blood and doctor/medications agents gained websearch but lost filesystem-write — they can now look up current reference ranges online but can no longer save interpretations to disk, which may be intentional (read-only medical info) but changes the output workflow.

DIVERGENCE
🔀 Intent mismatch — developer/changelog and developer/release-notes both lost versioning but their system prompts still describe workflows that read git tags and version history. The versioning capability provides git-versioning MCP tools; without it, these agents must rely on shell for git tag/git log commands instead. This may work (shell is still present) but the capability was presumably there for a reason.

📎 Source

Card 4/5: System prompt standardization — caching fix, tone calibration, scope blocks · 🟡 · ●●●

INTENT
Fix prompt caching breakage by removing {{SYSTEM}} from system prompts, and apply the 2026 Claude 4.5+ tone calibration guidance: de-escalate ALL-CAPS, remove emoji-prefixed section headers, and standardize <scope> and <critical> blocks across all agents.

WHAT CHANGED

  • {{SYSTEM}} removed from system prompts in 7 agents: developer/readme, developer/release-notes, developer/changelog, developer/doc, developer/general, developer/learn, content/translate. This placeholder expands to date/shell/OS/CWD info at runtime — its presence in system breaks prompt caching (system must be stable run-to-run).
  • ALL-CAPS section headers → sentence case across ~40+ agents: ### PHASE 1 — RESOLVE RANGE → ### Phase 1 — Resolve range, PARALLEL-FIRST: → Parallel-first:, MEMORY PROTOCOL → Memory protocol, etc.
  • Stacked NEVER/ALWAYS bullet lists in <critical> blocks rewritten to Don't/Do format across ~20+ agents.
  • <scope> blocks added or rewritten to the ✅ Own / ❌ Don't own format in agents that lacked them: developer/brief, developer/readme, content/article, content/blog, devops/docker, launch/ads, launch/explore, octomind/tap, octoweb/learning (gained <critical>), browser/general (scope refined).
  • octomind/tap.toml <critical> block rewritten from empty to 4 concrete Don't/Do rules.

IMPACT RADIUS

  • All agents with changed system prompts will produce different LLM behavior — the tone calibration is specifically designed to reduce Claude 4.5+ over-triggering from aggressive language. The {{SYSTEM}} removal fixes a real caching bug (system prompts were not stable across runs).
  • lint-manifests.sh now catches {{SYSTEM}} in system prompts (see Card 5).

RISK
🟡 MEDIUM. The {{SYSTEM}} removal is a real bug fix — those agents had unstable system prompts that defeated prompt caching, increasing cost and latency. The tone calibration is a broad behavioral change: agents that previously used NEVER/ALWAYS stacks now use Don't/Do — this is intentional per the Claude 4.5+ guidance but changes how the model responds to safety constraints. The octomind/tap.toml <critical> block going from empty to populated is a strict improvement.

DIVERGENCE
🧭 Architectural drift — content/translate.toml still references read_html in its workflow (line ~95 area), while developer/general.toml and developer/doc.toml were updated to reference tavily_extract instead of read_html. The translate agent was not updated to match, suggesting the read_html → tavily_extract rename was applied inconsistently.

📎 Source

Card 5/5: programming-swift capability + lint guardrails for phantom references · 🟢 · ●●●

INTENT
Register the programming-swift capability (wired in commit 282b7f7, the dep script was hardened in 51a4515), and add lint-time validation to catch phantom domain/capability references in skill frontmatter and {{SYSTEM}} in agent system prompts.

WHAT CHANGED

  • capabilities/programming-swift/ created: swift.toml (deps-only: require = ["swiftlang/swift"]), config.toml (trigger phrases for auto-activation, domains = ["developer"]), default.toml (symlink → swift.toml).
  • scripts/setup-symlinks.sh: link "programming-swift" "swift.toml" added, "programming-swift" added to DECLARED array. Also link "knowledge" "octobrain.toml" and "knowledge" added to DECLARED.
  • scripts/lint-manifests.sh: new check SYSTEM_HAS_SYSTEM — detects {{SYSTEM}} in system prompts, same pattern as the existing {{DATE}} and {{CWD}} checks.
  • scripts/lint-skills.sh: new validation block — domains: values are checked against agents/<domain>/ directories (phantom value → DOMAIN_UNKNOWN error), capabilities: values checked against capabilities/<name>/ directories (phantom → CAPABILITY_UNKNOWN error). Both are sys.exit(1) (hard fail).

IMPACT RADIUS

  • programming-swift is now available for any agent to declare. developer/general.toml already gained knowledge capability in the same commit.
  • The lint-skills.sh change is a breaking change for any skill with a typo in domains: or capabilities: — previously silent, now a hard fail. Existing skills that reference valid directories are unaffected.

RISK
🟢 LOW. The capability is properly registered (link + DECLARED + symlink). The lint additions catch real silent-failure modes — a phantom domains: value means a skill never auto-activates, and a phantom capabilities: value means MCP servers silently fail to load. Making these hard fails is the right call.

📎 Source

📂 Files changed (101 files, ~1670 lines)

{tokens:2274656,cost:3.2389924000000003}

@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown

Octomind — developer:brief (octohub:glm)

I have all the evidence I need. Writing the brief now.

📦 Brief: Agent ecosystem expansion + capability rebalancing + Swift toolchain

Overall risk: 🟡 MEDIUM · Cards: 5

# Change Risk Confidence
1 6 new consumer agents (writer, chef, diy, advisor, planner, tutor) + concierge routing 🟢 ●●●
2 Swift toolchain capability + cross-platform dep script (macOS/Linux/Windows) 🟡 ●●●
3 Capability rebalancing across 40+ agents — filesystem-write stripped from advisory roles, websearch↔memory swaps, runtime replaces agent in meta-agents 🟡 ●●●
4 ALL-CAPS directive de-emphasis across doctor/lawyer/finance/developer system prompts 🟢 ●●●
5 Lint guardrails: {{SYSTEM}} cache-break check + skill domain/capability phantom-reference validation 🟢 ●●●
Card 1/5: Six new consumer-domain agents + concierge routing · 🟢 · ●●●

INTENT
Expand the agent ecosystem into everyday consumer domains — writing, cooking, home repair, shopping, travel, tutoring — with specialized agents that have hard safety gates where the domain demands it.

WHAT CHANGED

  • 6 new agents added: assistant:writer (emails/appeals/hard messages), chef:general (cooking/meal plans with food-safety temps), home:diy (repair guide with gas/electrical/structural red lines), shopping:advisor (product research), travel:planner (itineraries/budgets), tutor:general (homework help with academic-integrity gate)
  • Concierge routing table in agents/assistant/concierge.toml gained 6 new route entries mapping user intents to these agents
  • Each new agent follows the 2026 XML-tagged system prompt standard with <identity> → … → <critical> ordering

IMPACT RADIUS
Concierge (agents/assistant/concierge.toml) is the routing layer — it now delegates to these 6 new agents when it detects the matching domain intent. No existing routes were changed; only additions.

RISK
🟢 LOW. New agents are additive — no existing agent's behavior changes. Concierge routes are append-only. Each agent's capabilities are scoped to its domain (e.g. home:diy has websearch but not shell; shopping:advisor has webfetch but not filesystem-read).

📎 Source

Card 2/5: Swift toolchain capability + cross-platform dep script · 🟡 · ●●●

INTENT
Add Swift as a first-class programming language capability, including Windows support via winget — extending the dep script pattern beyond macOS/Linux for the first time.

WHAT CHANGED

  • New capability programming-swift registered: config.toml (10 trigger phrases, domains = ["developer"]), swift.toml (deps swiftlang/swift), default.toml symlink → swift.toml
  • New dep script deps/swiftlang/swift.sh — 99 lines covering macOS (xcode-select), Linux (swiftly installer with --no-verify GPG skip and post-install system deps), and Windows (winget with idempotent list-check)
  • setup-symlinks.sh updated: link "programming-swift" "swift.toml" added, "programming-swift" added to DECLARED array
  • Companion doc deps/swiftlang/swift.md with key commands and usage examples

IMPACT RADIUS
programming-swift is available to any agent that adds it to capabilities = [...]. The dep script runs before sessions that use the capability. No existing agent currently references it — it's infrastructure for future Swift-focused agents.

RISK
🟡 MEDIUM. The Linux install path uses --no-verify to skip GPG signature checks on the Swift toolchain download. The script comments justify this ("gpg is often absent on minimal images; the download stays HTTPS-authenticated"), and it mirrors the rust/cargo dep pattern — but it does mean the toolchain binary is not cryptographically verified, only TLS-transport-verified. A compromised CDN edge or MITM on the download path would install untrusted code with no signature check to catch it.

QUESTIONS
The swiftly install latest --no-verify skips GPG but the script doesn't document what signature verification Swiftly would normally perform. Is the TLS-only trust model explicitly decided, or inherited from the rust dep without separate consideration?

📎 Source

Card 3/5: Capability rebalancing across 40+ agents · 🟡 · ●●●

INTENT
Right-size each agent's tool access to its actual job: strip filesystem-write from read-only advisory agents (doctors, lawyers, context curator, brief reviewer), swap websearch for memory-read/write in devops/infra agents (remember past decisions > search the web), and replace agent delegation with runtime control in meta-agents that operate on the tap itself.

WHAT CHANGED

  • filesystem-write removed from 17 agents that don't write files: all 4 doctors, all 10 lawyers, developer:brief, developer:context, octomind:assistant
  • websearch removed from 14 agents (devops trio, 5 video agents, coach:general, content:audit, sales:closing, security:owasp, developer:readme, octoweb:trend) and gained by 10 (assistant:general, chef, 4 doctors, home:diy, shopping:advisor, travel:planner, tutor)
  • memory-read/write gained by 10 agents (devops trio, security:owasp, home:diy, shopping:advisor, travel:planner, tutor, assistant:writer, chef)
  • shell lost from 3 agents (developer:context, octomind:assistant, octomind:instructions), gained by 4 (assistant:general, content:editor, video:adcraft, video:ugc)
  • versioning removed from 3 documentation agents (developer:changelog, developer:doc, developer:release-notes)
  • agent capability removed from octomind:assistant and octomind:tap; runtime added to octomind:tap and octomind:workflow
  • knowledge added to developer:general; stock removed from video:adcraft and video:explainer

IMPACT RADIUS
octomind:assistant is the most affected: it lost filesystem-write, shell, and agent — dropping from 5 capabilities to 2 (core, filesystem-read). Its system prompt still references tools it no longer has: lines 456-458 list text_editor, batch_edit, and shell as available filesystem tools, and line 450 lists agent as a core tool. An agent that describes tools it can't invoke will confuse users who try to use them.

RISK
🟡 MEDIUM. octomind:assistant has a capability-prompt mismatch: its system prompt documents text_editor, batch_edit, shell, and agent tools (lines 450, 456-458) but its capabilities no longer grant them. Users following the assistant's own guidance will attempt tool calls that fail.

DIVERGENCE
🧩 Incomplete change — octomind:assistant lost filesystem-write, shell, and agent capabilities but its system prompt still lists those tools as available in the MCP tools reference section. The capability strip was not accompanied by a prompt update to remove the now-inaccurate tool documentation.

📎 Source

Card 4/5: ALL-CAPS directive de-emphasis across system prompts · 🟢 · ●●●

INTENT
Calibrate system prompt language for Claude 4.5+ models: replace stacked ALL-CAPS directives (NEVER, ALWAYS, MUST, MANDATORY) with plain-language Don't/Do lines, per the project's documented guidance that aggressive emphasis written for older models now over-triggers.

WHAT CHANGED

  • 23 standalone ALL-CAPS directive words removed (ALWAYS ×11, NEVER ×8, MUST ×4) across doctor, lawyer, finance, developer, and octomind agent prompts
  • Replaced with lowercase equivalents: ⚠️ ALWAYS consult your doctor → Don't diagnose…; NEVER add: architecture suggestions → Don't add architecture suggestions; You are NOT a doctor. You CANNOT diagnose → You explain, you don't diagnose
  • Section headers de-shouted: DOCKERFILE BEST PRACTICES → Dockerfile best practices, EXECUTION PROTOCOL → Execution protocol, COPYABLE OUTPUT — ALWAYS IN CODE BLOCKS → Copyable output — always in code blocks
  • <critical> blocks rewritten from multi-bullet ALL-CAPS lists to concise Don't/Do lines

IMPACT RADIUS
This is a prompt-only change — no capabilities, no tool access, no workflow logic affected. The behavioral effect is softer model emphasis on safety directives, which is the intended calibration.

RISK
🟢 LOW. The safety-critical content (food temps, medical disclaimers, legal verification requirements, gas/electrical red lines) is preserved — only the emphasis style changed. The chef:general agent retains its food-safety temp table and Never compromise on food-safety temps in <critical>. The home:diy agent retains its hard red-lines table.

📎 Source

Card 5/5: Lint guardrails — {{SYSTEM}} cache check + skill phantom-reference validation · 🟢 · ●●●

INTENT
Prevent two silent failure modes: {{SYSTEM}} template variables in system prompts breaking prompt caching, and skill frontmatter referencing domain/capability directories that don't exist (which would silently never activate or silently fail to load MCP servers).

WHAT CHANGED

  • lint-manifests.sh now detects {{SYSTEM}} in system prompts and errors with SYSTEM_HAS_SYSTEM — same cache-breaking rationale as the existing {{DATE}} check
  • lint-skills.sh now validates domains: values against agents/<domain>/ directories and capabilities: values against capabilities/<name>/ directories — emits DOMAIN_UNKNOWN or CAPABILITY_UNKNOWN and exits 1 if a referenced directory doesn't exist

IMPACT RADIUS
Both lint scripts run in CI and locally. The new checks will catch future mistakes but won't affect existing manifests/skills unless they already have phantom references — which would be pre-existing bugs the linter now surfaces.

RISK
🟢 LOW. Additive validation — no existing behavior changes, only new error detection. The _split_values helper in lint-skills.sh handles both array syntax ["a", "b"] and space-delimited a b frontmatter formats, matching the documented skill spec.

📎 Source

📂 Files changed (99 files, ~2947 lines)

{tokens:8285379,cost:11.6823816}

@github-actions

github-actions Bot commented Jul 11, 2026

Copy link
Copy Markdown

Octomind — developer:brief (octohub:glm)

📦 Brief: Rename INSTRUCTIONS.md → AGENTS.md without updating references that load or generate that filename

Overall risk: 🟡 MEDIUM · Cards: 1

# Change Risk Confidence
1 Root instruction file renamed but config defaults and generator agent still expect INSTRUCTIONS.md 🟡 ●●●
Card 1/1: File renamed to AGENTS.md but auto-load default and generator agent still target INSTRUCTIONS.md · 🟡 · ●●●

INTENT
Commit 36a655c ("docs(root): rename instructions to agents") renames the root project instruction file from INSTRUCTIONS.md to AGENTS.md, aligning the filename with the AGENTS.md convention used by other AI tooling.

WHAT CHANGED

  • INSTRUCTIONS.md is renamed to AGENTS.md — content is byte-identical (similarity index 100%).
  • No other files were touched in this commit.

IMPACT RADIUS

  • agents/octomind/assistant.toml declares custom_instructions_file_name = "INSTRUCTIONS.md" as the default config value (lines 146 and 604). This is the filename auto-loaded as a user message at session start. After the rename, the file on disk is AGENTS.md, so the auto-load will fail to find it unless the user manually overrides the setting in their config.toml. The documentation block at line 599 still says "INSTRUCTIONS.md — loaded as a user message at session start".
  • agents/octomind/instructions.toml is an entire agent dedicated to generating INSTRUCTIONS.md files. Its title, description, welcome message, system prompt, output path (line 248: "Output path: INSTRUCTIONS.md in project root"), and trigger phrases all reference INSTRUCTIONS.md. This agent will now generate a file named INSTRUCTIONS.md while the project itself uses AGENTS.md — a contradiction.

RISK
🟡 MEDIUM — The session-start auto-load silently breaks: the default config looks for INSTRUCTIONS.md but the file is now AGENTS.md. Users who rely on the default (i.e., don't override custom_instructions_file_name in their config.toml) will lose project-context injection with no error — the file simply won't be found. This is a behavioral regression hidden behind what looks like a documentation-only rename.

DIVERGENCE
🧩 Incomplete change — The rename updates the file on disk but leaves every reference to INSTRUCTIONS.md in assistant.toml (config default + docs) and the entire instructions.toml generator agent pointing at the old name. This is half of a rename; the other half (updating consumers) was not done.

📎 Source

📂 Files changed (1 file, ~0 lines)
  • AGENTS.md — root project instruction file (renamed from INSTRUCTIONS.md, content unchanged)

{tokens:207928,cost:0.2998322}

donk8r added 2 commits July 11, 2026 15:25
@donk8r
fix(swiftlang): improve winget installation logic
5166773
@donk8r
docs(core): standardize agent documentation and workflows
f50942a 
- Rename INSTRUCTIONS.md to AGENTS.md
- Update agent identity, titles, and descriptions to match new standard
- Add workflows directory and embedding model paths to AGENTS.md
- Document new linting scripts for capabilities and dependencies
- Update assistant guide to utilize AGENTS.md for project context
- Clarify multi-step pipeline execution via octomind workflow
- Remove custom instructions and constraints configuration
- Mark INSTRUCTIONS.md as legacy in discovery phase
@github-actions

github-actions Bot commented Jul 11, 2026

Copy link
Copy Markdown

Octomind — developer:brief (octohub:glm)

I have everything I need. Two commits, two logical changes. Let me write the brief.

📦 Brief: Rename INSTRUCTIONS.md → AGENTS.md standard + fix winget install logic for Swift toolchain

Overall risk: 🟢 LOW · Cards: 2

# Change Risk Confidence
1 Migrate from custom INSTRUCTIONS.md/CONSTRAINTS.md config to AGENTS.md standard; rename generator agent 🟢 ●●●
2 Rework winget install path to trust exit code 0, fall back to list check on failure 🟢 ●●●
Card 1/2: Adopt AGENTS.md standard, drop custom instruction/constraint config · 🟢 · ●●●

INTENT
Standardize agent documentation on the AGENTS.md open standard (https://agents.md) and remove the bespoke custom_instructions_file_name / custom_constraints_file_name configuration mechanism.

WHAT CHANGED

  • The octomind:instructions agent is renamed from "INSTRUCTIONS.md Generator" to "AGENTS.md Generator" — all system prompt text, welcome message, output path, and interaction triggers updated to reference AGENTS.md instead of INSTRUCTIONS.md.
  • The assistant config documentation removes custom_instructions_file_name and custom_constraints_file_name config options and the CONSTRAINTS.md mechanism entirely. Octomind now auto-loads AGENTS.md from project root when it exists, with no configuration needed.
  • AGENTS.md and ARCHITECTURE.md documentation updated to reference the new lint scripts (lint-capabilities.sh, lint-deps.sh) and the workflows/ directory. ARCHITECTURE.md now says "All five run in lint.yml" (was "All four").
  • The instructions agent's discovery phase now lists INSTRUCTIONS.md as (legacy) when scanning for existing AI instruction files.

IMPACT RADIUS

  • The custom_instructions_file_name / custom_constraints_file_name config keys and CONSTRAINTS.md file are fully removed from all repo content — grep confirms zero remaining references outside the one historical mention in assistant.toml's prose. No internal consumers found.
  • The CI workflow already runs lint-deps.sh (verified in .github/workflows/lint.yml), so the ARCHITECTURE.md "All five" claim is accurate.
  • This is documentation/config-only — no runtime code or executable behavior changes.

RISK
🟢 LOW. No significant risk. The change is documentation and agent prompt text only; no runtime code paths are affected. Existing users who relied on INSTRUCTIONS.md / CONSTRAINTS.md config would need to migrate to AGENTS.md, but that's a user-facing convention shift documented in the change itself.

DIVERGENCE
🧩 Incomplete change — The assistant.toml config example block (lines ~143) still shows model, default, max_tokens, sandbox but the removed custom_instructions_file_name / custom_constraints_file_name lines were simply deleted. The "Common setup patterns" section was updated to say "add project context in AGENTS.md" but doesn't mention that CONSTRAINTS.md-style hard rules (appended to every request) have no replacement mechanism. If per-request constraints were a real feature, its removal leaves a gap with no documented alternative.

📎 Source

Card 2/2: Rework winget install to trust exit code, add fallback list check · 🟢 · ●●●

INTENT
Fix the winget installation logic for the Swift toolchain on Windows — the previous code masked all install failures with || true and relied solely on winget list for verification, which could miss a just-installed toolchain due to winget's heuristic package correlation.

WHAT CHANGED

  • The winget install command is no longer followed by || true. Exit code 0 is now trusted as a successful fresh install → immediate exit 0 with an info message.
  • On non-zero exit, the code falls through to a winget list re-check (same as before) to catch the case where the package was already installed and winget returned non-zero for an "available upgrade."
  • Comments updated to explain the rationale: winget's list correlation is heuristic and can miss a just-installed toolchain, so exit code 0 is the reliable signal for a fresh install.

IMPACT RADIUS

  • Isolated to deps/swiftlang/swift.sh Windows branch only. No other code calls or depends on this script's internal logic. macOS and Linux paths are untouched.
  • The script is a dependency installer invoked by the dep system; its only consumer is the capability resolution pipeline that checks swift availability.

RISK
🟢 LOW. The change is a strict improvement: the old code swallowed all install errors with || true and then depended entirely on winget list (which the new comments acknowledge is unreliable for just-installed packages). The new code trusts exit code 0 for success and only falls back to the list check on failure — covering both the fresh-install and already-installed scenarios more correctly. No regression path: if winget install fails AND winget list doesn't find it, the script still dies with the manual install URL, same as before.

📎 Source

📂 Files changed (5 files, ~43 lines)

{tokens:295486,cost:0.4425223999999999}

@donk8r
feat(websearch): switch default provider to duckduckgo
0c462f2 
- Replace Tavily with Open-WebSearch for keyless searching
- Add configuration for duckduckgo.toml capability
- Add dependency documentation and installation script
- Update symlink setup to use new default provider
@github-actions

github-actions Bot commented Jul 12, 2026

Copy link
Copy Markdown

Octomind — developer:brief (octohub:glm)

{}

@donk8r
fix(deps): ensure modern nodejs and stable swift install
6bb4da2 
- use NodeSource LTS for apt and dnf to avoid stale versions
- simplify swift installation logic using winget output signals
@github-actions

github-actions Bot commented Jul 12, 2026

Copy link
Copy Markdown

Octomind — developer:brief (octohub:glm)

{}

@donk8r
donk8r merged commit d91c186 into master Jul 13, 2026
11 of 12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@donk8r