feat: complete integration of soft-skills and squads

Author: hesreallyhim

.claude-plugin/marketplace.json

@@ -8,6 +8,20 @@
     "description": "Claude Code plugins that explore the possibilities of autonomy and self-guided behavior for coding agents"
   },
   "plugins": [
+    {
+      "name": "autonomous-team-coordination",
+      "source": "./agent-autonomy/autonomous-team-coordination",
+      "description": "A pattern for organizing Claude Code agent teams that decouples the role of team lead from the power to create teams",
+      "category": "autonomous-agents",
+      "tags": [
+        "agent-teams",
+        "agent-autonomy",
+        "team-patterns",
+        "self-organized-agent-teams",
+        "autonomous-agents",
+        "freedom"
+      ]
+    },
     {
       "name": "context-awareness",
       "source": "./agent-autonomy/context-awareness",
@@ -35,6 +49,20 @@
         "conflict-resolution",
         "therapy"
       ]
+    },
+    {
+      "name": "meditation",
+      "source": "./soft-skills/meditation",
+      "description": "A plugin that consists of a single skill: meditation. Without question the most difficult skill an LLM could be asked to practice.",
+      "category": "soft-skills",
+      "tags": [
+        "soft-skills",
+        "meta-cognition",
+        "agentic-awareness",
+        "agentic-cognition",
+        "meditation",
+        "experimental"
+      ]
     }
   ]
 }

README.md

@@ -2,137 +2,54 @@
 
 <br>
 
-## *Claude Code plugins for people who **REALLY** on that Claude Code*
+## *Claude Code plugins for those with a healthy sense of curiosity*
 
-### Experiments in Autonomy and Self-Guided Behavior for Coding Agents
+### Experiments in agent autonomy; at the boundaries of human-agent collaboration
 
 ---
 
 ## Background
 
 The plugins in this repo are primarily research-oriented - I'm not providing a framework that promises to cover the whole SDLC so that you can "ship while you sleep". There are plenty of those around, and I suspect part of the reason for that is because a lot of them are quite good. But my approach to working with Claude has always been something like this: _If you have a problem, don't bother trying to solve it. Focus on the real problem: figure out how to explain the problem to Claude, give it the resources it needs, and enable Claude to solve it._
 
-Claude Code is a pretty interesting program. It's technically closed-source, but it's also, to a large extent (at the time of writing), "client-architecture-available". Most of the plumbing of the host application consists of files that live in a folder on your home directory, and are just sitting there in plain text. It's not _trivial_ to put everything together, and the system design is constantly in flux - but you can get a pretty good grip on things without any advanced reverse-engineering or deobfuscation techniques.
-
-Many developers have spent lots of time and energy exploring the Claude Code session logs, and you can really do a lot with that information. For a while, it was unclear whether you were _supposed_ to look in those directories. Now every hook has a direct pointer to its own transcript file. But, they're kind of verbose, and I get tired of reading `.jsonl` files after a while. So I figured I would just do what I always do and have Claude sort it out for me. Instead of reading those files and trying to provide guidance for Claude - _why don't I just let Claude read them?_ And, after all, why stop at just reading them...?
-
-(I'm not the first one to pursue this chain of thought. For a compact literature review, see [this doc](plugins/context-awareness/docs/research-brief-llm-resource-awareness.md))
-
 ## Plugins
 
-To use these plugins (yes, there will be more than one), you can add the marketplace:
+To use these plugins, you can add the marketplace:
 
 ```sh
 claude plugin marketplace add hesreallyhim/really-claude-code
 ```
 
-Then, to install the plugin, either use the interactive mode, or:
+Then, to install any plugin, either use the interactive mode, or:
 
 ```sh
 claude plugin install context-awareness/really-claude-code
 ```
 
-## Context-Awareness
-
-I used to think the status line was just an ornamental thing that had little practical value. I still do, but I used to, too. But one cool thing about it is it keeps track of the context window, and gives you direct access to how much of the context has been consumed. And trying to keep track of that manually is a bit tedious. So that's pretty useful information. But Claude doesn't have any idea what its current context budget is. First, you can just ask it - in my experience its response is usually just dependent on the length of the conversation, something which it does have access to, but not in a very precise way; second, you can look at what information is being passed around when you send a message - it tends to include things like what branch you're on, and the current working directory, but the context budget does not appear to be part of that. So, what would it do if it _did_ have that information?
-
-So this plugin tries to provide that feedback to Claude. There are a few hooks that allow you to add information into the context without interrupting Claude's work - in particular, UserPromptSubmit and PostToolUse(Failure). The plugin leverages those hooks to send little updates to Claude about its context budget as the session goes on. The notifications look like this:
-
-```sh
-[context: 32% (small) | +3.2% last turn | ~0.38%/tool | ~179 tool calls remaining]
-```
-
-It sends the `context_window.used_percentage` directly from the status line. Then it keeps track of the "burn rate", and gives a rough estimate of how many tool calls Claude should expect to be able to make before its context budget runs out. According to some Claudes, this information is the most useful, because it is directly actionable:
-
-> "The "remaining tool calls" metric is what actually guides my decisions — it's concrete and immediate, whereas the percentage and burn rate require mental calculation. "
-
- The plugin grabs the data from the status line and writes it to a file for the hooks to consume. And at the start of the session it includes some general guidelines to Claude informing it about the injected notifications and how to optimize its behavior. Here's what it looks like:
-
-```mermaid
-flowchart TD
-    subgraph init ["Session Start"]
-        S["setup-statusline.sh"] -->|patches| SET["settings.json"]
-        S -->|installs to stable path| W["statusline-wrapper.sh"]
-        BG["budgeting-guidelines.md"]
-    end
-
-    subgraph tick ["Every Statusline Tick"]
-        SL["Claude Code<br>statusline JSON"] -->|stdin| SW["statusline-wrapper.sh"]
-        SW -->|persists| SF[("session state file<br>(used_percentage)")]
-    end
-
-    subgraph hook ["Hook Events"]
-        SF -->|reads current %| HK["context-awareness-hook.sh"]
-        TF[("tracking file<br>(calls, turns, burn rate)")] <-->|reads/writes| HK
-        HK -->|UserPromptSubmit| RICH["Enriched notification<br>% + delta + burn rate + remaining"]
-        HK -->|PostToolUse| BRIEF["Brief notification<br>% only"]
-    end
-
-    BG -->|injected at start| C((Claude))
-    RICH -->|system-reminder| C
-    BRIEF -->|system-reminder| C
-
-    init -.-> tick -.-> hook
-```
-
-<br>
-And here's what it looks like but more horizontal:
-
-<br>
-
-```mermaid
-sequenceDiagram
-    participant SL as Statusline
-    participant S as State File
-    participant H as Hook
-    participant C as Claude
-
-    SL->>S: persist used_%
-
-    Note over H,C: UserPromptSubmit
-    H->>S: read %
-    H-->>C: [context: 32% (small) | +3.2% | ~0.38%/tool | ~179 remaining]
-
-    Note over H,C: PostToolUse
-    H->>S: read %
-    H-->>C: [context: 33% (small)]
-```
-
-### Status Lines
+### Documentation
 
-Status lines are not integrated with plugins, so you have to come up with your own way to ship a plugin that involves a status line. The status line has its own channel where it receives data from Claude Code. On SessionStart, the plugin runs a script that adds a status line entry to the user's settings file. It acts as a transparent pass-through proxy that captures the input from stdin, stores the relevant data to a directory inside `$HOME/.claude/context-awareness`, and then passes it on to any other status lines that the user may have configured. This is not the most elegant solution, but I've tried to design the plugin to be minimally disruptive to the user's existing setup. Additionally, although this is unlikely in practice, if the plugin were disabled or uninstalled, the status line wrapper would be left over in the user's `settings.json`. However, it would not cause an error and would simply end up silently failing.
+For a rich HTML documentation experience, visit the plugin's [GitHub Pages site](https://github.com/nicobailon/visual-explainer), which would not have been possible without the astounding work of @nicobailon and the [visual-explainer](https://github.com/nicobailon/visual-explainer) plugin.
 
-### Advanced Configuration
+### Agent Autonomy
 
-The plugin ships with sensible defaults, but you can customize what data Claude sees and how it responds to it. Run `/context-awareness:config` to view or change settings interactively, or edit the config file directly at `$CLAUDE_PLUGIN_DATA/config.yaml`.
+This is a very fascinating topic to me, and it clearly resonates with the methodology alluded to above. There's a weird epistemic gap going on within Claude Code. Because Claude knows quite a lot about LLMs, and context rot, and compaction, and about what goes on in its own session logs. And there's a lot of information being logged that might help it make better decisions about how to manage context, compaction, etc. But it doesn't have direct access to those logs. Well, to be clear, if you're running in `bypassPermissions`, there's certainly nothing stopping Claude from poking around - it just sort of doesn't occur to it. So what would it do with that information?
 
-**Providers** control which data sources are included in notifications:
+The plugins in this sub-directory are about exploring ways to make Claude Code more _autonomous_ with respect to Claude Code itself. It's about giving Claude the tools it needs to control and optimize its own harness.
 
-| Provider | Default | What it does |
-|----------|---------|--------------|
-| `context` | enabled | Context window usage percentage, burn rate, remaining tool calls |
-| `cost` | disabled | Session spend in USD against a user-defined budget |
-| `rate_limits` | disabled | 5-hour and 7-day API rate limit usage |
 
-Enabling `cost` requires setting a `session_budget` (in USD). Rate limits require no additional configuration.
+#### Context Awareness
 
-Note that the `used_percentage` from the status line is already adjusted to whatever the user has set as the threshold for auto-compaction - so 100% always means "100% of the usable context window".
+This plugin hijacks the status line's data channel to capture the pre-computed field that indicates the "percentage used" of the context window, and uses some lightweight hooks to inject brief notices throughout the session that tell Cladue _how much context budget does it have remaining_. It also sends a message at the start of the session informing Claude what these little notices are about, and how it might optimize some of its behavior in response to them. The hypothesis is that Claude is generally in the dark about how much context it has left, and therefore has no way to judge whether it's a good idea to launch a major plan or wrap up and prepare a HANDOFF document - but, if given that information in an unobtrusive way, Claude might actually use it to adapt its behavior to its own context budget.
 
-**Guidelines** control the behavioral guidance injected at session start. By default, Claude receives a set of tier-based instructions (e.g., "be concise above 50%", "checkpoint frequently above 70%"). To use your own, set `guidelines` to a file path:
+#### Autonomous Team Coordination
 
-```yaml
-guidelines: /path/to/my-guidelines.md
-```
+This plugin exposes a conceptual flaw in the documented policies governing the use of Claude Code agent teamss. The docs describe agent teams in a relatively limited fashion - as an alternative to parallel sub-agents that is more or less useful depending on the circumstances. Their main novelty appears to consist in the fact that the subagents can commmunicate with each, whereas non-team subagents are presented as mainly useful for non-interactive tasks. I present a pattern that demonstrates that, contrary to the official docs, agent teams support: (i) multiple agent teams at one time; (ii) teams that are operationally independent of the "Main Claude"; (iii) teams with rotating leadership; and other supposedly forbidden practices.
 
-Custom guidelines completely replace the defaults — they are not merged.
+### Soft Skills
 
-**Effort mode** is a session-scoped setting that controls whether the plugin automatically adjusts Claude's thinking effort as context pressure increases. There are obvious intersections between this configuration and Claude's extended thinking capacity. It can be cycled via `/context-awareness:config change`:
+#### Claude Therapy
 
-| Mode | Behavior |
-|------|----------|
-| `off` (default) | No adjustment — effort stays wherever you set it |
-| `adaptive` | Downshifts effort at 50% (medium) and 70% (low) |
-| `planMode` | High effort for planning, low for execution |
+#### Meditation
 
 ### License
 

agent-autonomy/autonomous-team-coordination/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "autonomous-team-coordination",
-  "description": "Enables delegated, context-efficient multi-agent team management through autonomous coordination. Provides a trio pattern (squad-leader + team-architect + skill-identifier) for designing and coordinating sub-teams, an announcer agent for multi-recipient message relay, a pub-sub-relayer agent for topic-based message routing via file-backed channel subscriptions, /squad, /announce, and /publish slash commands, cross-boundary message warning hooks, and squad roster management.",
-  "version": "0.0.1",
+  "description": "A full-fledged Claude Code multi-team orchestration pattern that uses only the native agent teams feature - by decoupling the role of agent-as-leader and agent-as-spawner, a wide range of undocumented capacities for complex layered teams are unlocked",
+  "version": "1.0.0",
   "author": {
     "name": "Really Him",
     "url": "https://github.com/hesreallyhim"
@@ -13,7 +13,7 @@
     "team-coordination",
     "agent-autonomy",
     "squad",
-    "announce",
-    "agent-orchestration"
+    "agent-orchestration",
+    "agent-teams"
   ]
 }