Run any Skill in Manus with one click

letta-monorepo-coordination

Stars0

Forks0

UpdatedApril 10, 2026 at 18:51

Use when work spans multiple letta-workspace subprojects or requires understanding cross-subproject dependencies. Do not use for single-subproject changes.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

mikkihugo

mikkihugo/aicoder-opencode

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	letta-monorepo-coordination
version	2026-04-10.1
description	Use when work spans multiple letta-workspace subprojects or requires understanding cross-subproject dependencies. Do not use for single-subproject changes.
user-invocable	true

letta-monorepo-coordination

When to Use

A change in one subproject affects another (letta ↔ letta-code, letta-fleet ↔ lettactl)
Deciding which subproject owns a new piece of functionality
Coordinating a release or schema change across subprojects
Investigating a bug that crosses subproject boundaries

Subproject Map

Subproject	Root	Role
`letta`	`letta-workspace/letta`	Core agent runtime
`letta-code`	`letta-workspace/letta-code`	Code-focused agent layer
`letta-fleet`	`letta-workspace/letta-fleet`	Fleet/multi-agent orchestration
`letta-selfhost`	`letta-workspace/letta-selfhost`	Self-hosted deployment configs
`lettactl`	`letta-workspace/lettactl`	CLI control surface

Contract

Changes that affect the public interface of letta must be validated against letta-code and lettactl.
letta-fleet depends on letta runtime — fleet changes require a working letta baseline.
letta-selfhost is deployment config only — do not put runtime logic here.
One subproject at a time unless a cross-cutting change is explicitly scoped.

Workflow

Name which subprojects are affected and why.
Start in the subproject closest to the root dependency (letta before letta-code).
Verify each subproject independently before moving to the next.
Commit per subproject — do not batch cross-subproject changes in one commit.

Avoid

Making assumptions about shared interfaces without reading the source
Committing a cross-subproject change without verifying downstream subprojects build
Treating letta-selfhost as a place for runtime logic

More from this repository

same repository

dr-autonomous-iteration

mikkihugo/aicoder-opencode

Use when asked to work in a continuous loop until done or truly blocked. Orchestrates pickup, planning, TDD execution, implementation waves when needed, debugging side-chains, verification, and resume behavior.

2026-04-110

dr-clarify-spec

mikkihugo/aicoder-opencode

Use before planning when a feature or change request is underspecified. Resolve high-impact ambiguity around scope, consumers, security, failure handling, and acceptance criteria before writing the implementation plan.

2026-04-110

dr-code-review

mikkihugo/aicoder-opencode

Use for both preparing work for review and responding to review feedback. Keep review evidence local, concrete, and scoped to the real contract. Verify technically before agreeing or changing code.

2026-04-110

dr-design-and-planning

mikkihugo/aicoder-opencode

Use before implementation. Merge design discovery and plan writing into one DR-specific flow: identify the consumer, inspect the repo, debate boundaries with partner and combatant, and produce an execution-ready plan that hands off cleanly into DR-native tasks, TDD, and implementation waves.

2026-04-110

dr-finish-and-verify

mikkihugo/aicoder-opencode

Use for the last mile: rerun verification, inspect diffs, commit or push if requested, and perform local docker-compose checks when needed. This is the DR local-tools replacement for MCP-style finish/deploy carryovers.

2026-04-110

dr-generate-tasks

mikkihugo/aicoder-opencode

Use after planning and before implementation when you need a concrete, dependency-ordered task list. Turn the DR feature spec and plan into independently testable task slices with exact file paths and verification commands.

2026-04-110

name	letta-monorepo-coordination
version	2026-04-10.1
description	Use when work spans multiple letta-workspace subprojects or requires understanding cross-subproject dependencies. Do not use for single-subproject changes.
user-invocable	true

letta-monorepo-coordination

When to Use

A change in one subproject affects another (letta ↔ letta-code, letta-fleet ↔ lettactl)
Deciding which subproject owns a new piece of functionality
Coordinating a release or schema change across subprojects
Investigating a bug that crosses subproject boundaries

Subproject Map

Subproject	Root	Role
`letta`	`letta-workspace/letta`	Core agent runtime
`letta-code`	`letta-workspace/letta-code`	Code-focused agent layer
`letta-fleet`	`letta-workspace/letta-fleet`	Fleet/multi-agent orchestration
`letta-selfhost`	`letta-workspace/letta-selfhost`	Self-hosted deployment configs
`lettactl`	`letta-workspace/lettactl`	CLI control surface

Contract

Changes that affect the public interface of letta must be validated against letta-code and lettactl.
letta-fleet depends on letta runtime — fleet changes require a working letta baseline.
letta-selfhost is deployment config only — do not put runtime logic here.
One subproject at a time unless a cross-cutting change is explicitly scoped.

Workflow

Name which subprojects are affected and why.
Start in the subproject closest to the root dependency (letta before letta-code).
Verify each subproject independently before moving to the next.
Commit per subproject — do not batch cross-subproject changes in one commit.

Avoid

Making assumptions about shared interfaces without reading the source
Committing a cross-subproject change without verifying downstream subprojects build
Treating letta-selfhost as a place for runtime logic