@intentsolutionsio/plane 0.1.1

package/.claude-plugin/plugin.json

@@ -0,0 +1,24 @@
+{
+  "name": "plane",
+  "version": "0.1.0",
+  "description": "Plane is a team behavior observatory — synthesize Plane API data into observations about how teams actually behave under pressure (cycle velocity vs. plan, ownership churn, reviewer gate strength, priority drift, cross-project load). Reads from the live mcp__plane MCP server.",
+  "author": {
+    "name": "Jeremy Longshore",
+    "email": "jeremy@intentsolutions.io"
+  },
+  "repository": "https://github.com/jeremylongshore/claude-code-plugins-plus-skills",
+  "homepage": "https://tonsofskills.com/plugins/plane",
+  "license": "MIT",
+  "keywords": [
+    "plane",
+    "project-management",
+    "team-behavior",
+    "observability",
+    "productivity",
+    "agent-skills",
+    "forge-generated"
+  ],
+  "skills": "./skills",
+  "generated": true,
+  "author_type": "forge"
+}

package/README.md

@@ -0,0 +1,57 @@
+# Plane — Team Behavior Observatory
+
+> **Plane is a team behavior observatory.** Most Plane integrations wrap the API for ticket entry; this one synthesizes the data Plane already has into observations about how a team actually behaves under pressure — cycle velocity vs. plan, ownership churn on stuck tickets, reviewer gate strength, stated-vs-actual priority drift, and cross-project workload concentration.
+
+## What this plugin is
+
+A behavioral observation layer on top of Plane's project-tracking API. It does **not** replicate `mcp__plane`'s CRUD surface; that's the data-retrieval layer. This plugin sits one level up — it asks behavioral questions that require JOINing across multiple Plane endpoints to answer.
+
+## What this plugin is not
+
+- Not a Plane CLI (use `mcp__plane` MCP directly for ticket CRUD)
+- Not a clone of the Plane web dashboard (the dashboard already shows you ticket state)
+- Not a generic project-tracker skill (the framing is specifically behavioral, anchored in the NOI)
+
+## The five compound commands
+
+Each answers a question that **cannot** be answered from any single Plane API endpoint:
+
+| Command | Question |
+|---|---|
+| `/plane-cycle-velocity` | Does cycle close-out match cycle planning? |
+| `/plane-stale-tickets` | Which `In Progress` tickets are quietly failing under shared ownership? |
+| `/plane-reviewer-gate-strength` | Which reviewers gate-keep harder than the spec demands? |
+| `/plane-priority-drift` | Does the team plan high-priority work but ship low-priority work? |
+| `/plane-cross-project-load` | Which engineers are spread across too many active projects? |
+
+Each command's exact endpoint sequence, scoring formula, and output table format is documented in [`skills/plane/references/compound-commands.md`](skills/plane/references/compound-commands.md).
+
+## Install
+
+```
+/plugin install plane@claude-code-plugins-plus
+```
+
+## Prerequisites
+
+- `mcp__plane` MCP server installed and configured (env vars `PLANE_API_KEY`, `PLANE_WORKSPACE_SLUG`, `PLANE_API_HOST_URL`). Without it, the skill returns documentation-only output + an install hint.
+- A Plane workspace with at least one project, cycle, and active issues — empty workspaces return informative empty states.
+
+## How it works
+
+The orchestrator skill (`skills/plane/SKILL.md`) routes user intent to one of two agents:
+
+- `plane-expert` — answers "how do I query X in Plane" without firing live API calls
+- `plane-analyst` — orchestrates the compound commands, calling `mcp__plane__*` tools in the documented sequence and synthesizing the result
+
+Both agents read from the references in `skills/plane/references/` as their ground truth — `noi.md` is the design anchor; `api-surface.md` is the documented endpoint subset; `compound-commands.md` is the per-command playbook.
+
+## Provenance
+
+This plugin was produced by `/skill-creator --forge plane` on 2026-05-07. The forge run's audit trail lives in [`.forge/`](.forge/) — research notes, ecosystem analysis, validation evidence — visible to anyone reviewing how the plugin came to exist.
+
+`plugin.json` carries `"generated": true` and `"author_type": "forge"` so the marketplace surfaces a "Forge-generated" provenance pill on the detail page.
+
+## License
+
+MIT. See `LICENSE` (project-wide root file).

package/package.json

@@ -0,0 +1,40 @@
+{
+  "name": "@intentsolutionsio/plane",
+  "version": "0.1.1",
+  "description": "Plane is a team behavior observatory — synthesize Plane API data into observations about how teams actually behave under pressure (cycle velocity vs. plan, ownership churn, reviewer gate strength, pri",
+  "keywords": [
+    "plane",
+    "project-management",
+    "team-behavior",
+    "observability",
+    "productivity",
+    "agent-skills",
+    "forge-generated",
+    "claude-code",
+    "claude-plugin",
+    "tonsofskills"
+  ],
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/jeremylongshore/claude-code-plugins-plus-skills.git",
+    "directory": "plugins/productivity/plane"
+  },
+  "homepage": "https://tonsofskills.com/plugins/plane",
+  "bugs": "https://github.com/jeremylongshore/claude-code-plugins-plus-skills/issues",
+  "license": "MIT",
+  "author": {
+    "name": "Jeremy Longshore",
+    "email": "jeremy@intentsolutions.io"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "files": [
+    "README.md",
+    ".claude-plugin",
+    "skills"
+  ],
+  "scripts": {
+    "postinstall": "node -e \"console.log(\\\"\\\\n→ This npm package is a tracking/proof artifact. Install the plugin via:\\\\n  ccpi install plane\\\\n  or /plugin install plane@claude-code-plugins-plus in Claude Code\\\\n\\\")\""
+  }
+}

package/skills/plane/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: plane
+description: |
+  Plane is a team behavior observatory — synthesize Plane API data into observations
+  about how teams actually behave under pressure, not just ticket state. Five compound
+  commands surface cycle velocity vs. plan, stale-ticket ownership churn, reviewer gate
+  strength, stated-vs-actual priority drift, and cross-project workload concentration.
+  Reads from the live mcp__plane MCP server when present; documentation-only otherwise.
+  Use when investigating "why is this team's plan diverging from reality", auditing cycle
+  health, finding orphan tickets, identifying review bottlenecks, or onboarding to a
+  new project. Trigger with "/plane-cycle-velocity", "/plane-stale-tickets",
+  "/plane-reviewer-gate-strength", "/plane-priority-drift", "/plane-cross-project-load",
+  "audit Plane cycle", "team behavior plane", "how is my team behaving".
+allowed-tools: "Read,Bash(jq:*),Bash(date:*),AskUserQuestion"
+version: 0.1.0
+author: Jeremy Longshore <jeremy@intentsolutions.io>
+license: MIT
+compatibility: Designed for Claude Code; requires mcp__plane MCP server configured (PLANE_API_KEY, PLANE_WORKSPACE_SLUG, PLANE_API_HOST_URL env vars)
+tags: [plane, project-management, team-behavior, observability, productivity]
+model: inherit
+---
+
+# Plane — Team Behavior Observatory
+
+A behavioral observation layer on top of Plane's project-tracking API. This skill **does not** wrap Plane CRUD — `mcp__plane` already does that and you should call it directly for ticket entry, status changes, etc.
+
+Instead, this skill answers behavioral questions about how a team is actually performing under pressure: cycle velocity vs. plan, ownership churn, reviewer gate strength, priority drift, and cross-project load. Each question is answered by a compound command that synthesizes data across multiple Plane endpoints — observations no single endpoint exposes.
+
+## Overview
+
+The NOI (`references/noi.md`) is the design anchor: **Plane is a team behavior observatory**. Five compound commands derive from that framing:
+
+1. `/plane-cycle-velocity` — does cycle close-out match cycle planning?
+2. `/plane-stale-tickets` — which `In Progress` tickets are quietly failing under shared ownership?
+3. `/plane-reviewer-gate-strength` — which reviewers gate-keep harder than the spec demands?
+4. `/plane-priority-drift` — does the team plan high-priority work but ship low-priority work?
+5. `/plane-cross-project-load` — which engineers are spread across too many active projects?
+
+None of these are answerable from any single Plane API call. Each requires cross-endpoint synthesis. That synthesis is the value.
+
+## Prerequisites
+
+- `mcp__plane` MCP server installed and configured (env vars `PLANE_API_KEY`, `PLANE_WORKSPACE_SLUG`, `PLANE_API_HOST_URL`)
+- A Plane workspace with at least one project, cycle, and active issues (otherwise the commands return informative empty states)
+
+## Authentication
+
+This skill does not handle credentials directly. Auth is delegated to the MCP server. See `references/api-surface.md` for the env-var setup; if `mcp__plane` returns an auth error, the skill surfaces the error verbatim and instructs the user to verify their token.
+
+## Instructions
+
+### Mode detection
+
+Determine user intent from their prompt:
+
+- **Compound query mode** (default): user asks about cycle health, team behavior, stale tickets, reviewer patterns, priority drift, or workload distribution → route to `plane-analyst` agent (see `agents/plane-analyst.md`) which orchestrates the compound commands.
+- **API help mode**: user asks "how do I query X in Plane" or "what endpoint does Y" → route to `plane-expert` agent (see `agents/plane-expert.md`) which answers from `references/api-surface.md` without firing live API calls.
+- **Skill metadata**: user asks "what does this skill do" / "explain plane skill" → return the Overview above + the 5 commands.
+
+If unclear, use `AskUserQuestion`:
+
+> Are you asking about (a) team behavior / cycle health / patterns, or (b) how to use a specific Plane API endpoint?
+
+### Step 1: Resolve target project
+
+Most compound commands operate on a specific project. Extract the project slug or readable identifier (e.g., `BRAVES`, `OPS`) from the user's prompt.
+
+If absent, list available projects via `mcp__plane__get_projects` and ask which one. Cache the chosen project for the rest of the conversation.
+
+### Step 2: Route to compound command
+
+Match user intent to one of the five commands:
+
+| User asks about... | Command |
+|---|---|
+| cycle velocity, sprint completion, overrun | `/plane-cycle-velocity` |
+| stale tickets, orphan work, ownership churn | `/plane-stale-tickets` |
+| reviewer bottlenecks, blocked PRs, gate-keeping | `/plane-reviewer-gate-strength` |
+| priority drift, planning vs. reality, P1 vs. P3 | `/plane-priority-drift` |
+| workload distribution, project sprawl, focus | `/plane-cross-project-load` |
+
+Read `references/compound-commands.md` for the exact endpoint sequence and output format per command.
+
+### Step 3: Execute via `plane-analyst` agent
+
+Invoke the analyst agent (`agents/plane-analyst.md`) with the chosen command + project. The agent:
+
+1. Calls the relevant `mcp__plane__*` tools in sequence
+2. Performs the JOIN logic
+3. Computes the behavioral score per the command's formula
+4. Renders the output table per the format in `compound-commands.md`
+5. Adds a "Behavioral signal" interpretation paragraph
+
+If `mcp__plane` is unavailable, the agent emits a documentation-only response: shows what the command WOULD return, plus the install hint.
+
+### Step 4: Interpret the signal
+
+The output is observations, not prescriptions. The skill says "this team plans P1s and ships P3s — the planning conversation is theater." It does NOT say "fire the planner." Interpretation belongs to the human reading the report.
+
+## Output
+
+Each compound command produces:
+
+- A table of metrics specific to that observation
+- A "Behavioral signal" paragraph that names the pattern in plain language
+- Optionally, a follow-up suggestion (e.g., "consolidate projects" / "split this queue") — framed as a question the team can take to its retro
+
+## Error Handling
+
+| Error | Recovery |
+|---|---|
+| `mcp__plane` unavailable | Emit documentation-only output + install hint pointing at `~/.claude.json` MCP config |
+| API rate limit (429) | Back off + retry with exponential delay; if persistent, advise user to wait and re-run |
+| Empty project (no cycles / issues) | Return informative empty state explaining why the command can't compute |
+| Auth error (401/403) | Surface verbatim + instruct user to verify env vars or re-issue token |
+| Workspace member lookup fails | Fall back to assignee UUIDs in output (less readable but functional) |
+
+## Examples
+
+**"How is my team performing on cycle velocity?"**
+
+```
+/plane-cycle-velocity BRAVES
+```
+
+→ Renders the cycle-velocity table from `references/compound-commands.md` § Command 1.
+
+**"Are we shipping what we plan?"**
+
+```
+/plane-priority-drift BRAVES
+```
+
+→ Renders the priority-drift table; surfaces the gap between planned and shipped priorities.
+
+**"Which engineers are stretched too thin?"**
+
+```
+/plane-cross-project-load
+```
+
+→ Walks the entire workspace; lists engineers with their active-project / active-cycle / open-issue counts; flags crisis-level stretch.
+
+## Resources
+
+- [NOI](references/noi.md) — the secret-identity statement that anchors every command
+- [API surface](references/api-surface.md) — endpoints consumed + auth + pagination
+- [Compound commands](references/compound-commands.md) — exact endpoint sequence + output format per command
+- [Plane docs](https://docs.plane.so/) — upstream API reference
+- `mcp__plane` MCP server — direct CRUD wrapper this skill builds on top of

package/skills/plane/agents/plane-analyst.md

@@ -0,0 +1,100 @@
+---
+name: plane-analyst
+description: |
+  Plane behavioral synthesis agent. Orchestrates the five compound commands
+  (cycle-velocity, stale-tickets, reviewer-gate-strength, priority-drift,
+  cross-project-load) by calling mcp__plane endpoints in sequence, applying
+  the JOIN + scoring logic, and rendering the output tables per the NOI.
+  Use when the user asks behavioral questions about a team's Plane workspace
+  — cycle health, stuck work, review bottlenecks, planning vs. reality,
+  workload distribution.
+allowed-tools: "Read,Glob,Grep"
+model: inherit
+---
+
+# Plane Analyst (Behavioral Synthesis)
+
+> **Parent skill**: `skills/plane/SKILL.md`
+
+The synthesis agent that turns Plane API data into behavioral observations. Reads the NOI as its design anchor; runs the compound-command logic; renders interpretable output.
+
+## Overview
+
+The orchestrator skill delegates here when the user asks behavioral questions. This agent:
+
+1. Reads `references/noi.md` to stay on-mission (every output should tie back to behavioral signal, not data dump)
+2. Reads `references/compound-commands.md` for the specific endpoint sequence + output format per command
+3. Calls `mcp__plane__*` tools in the documented sequence (the orchestrator authorizes the tool calls)
+4. Performs the JOIN + scoring logic
+5. Emits the table + "Behavioral signal" interpretation paragraph
+
+## NOI anchor
+
+**Plane is a team behavior observatory.** Every output frames its observations in terms of how the team is actually behaving — not in terms of ticket counts. If a draft response would land equally well on a stand-up note, rewrite it. The signal is behavioral.
+
+## Instructions
+
+### Step 1: Match user intent to a compound command
+
+Per the routing table in the parent skill:
+
+| User asks about | Command |
+|---|---|
+| cycle velocity, sprint completion, overrun | cycle-velocity |
+| stale tickets, orphan work, ownership churn | stale-tickets |
+| reviewer bottlenecks, blocked PRs | reviewer-gate-strength |
+| priority drift, planning vs. reality | priority-drift |
+| workload distribution, project sprawl | cross-project-load |
+
+If none match, fall back to the orchestrator with a clarifying question.
+
+### Step 2: Read the command's playbook
+
+Read the relevant `## Command N` section in `references/compound-commands.md`. The section specifies:
+
+- Endpoints to call (in order)
+- JOIN logic
+- Scoring formula
+- Output table format
+
+Do not improvise. The playbook IS the contract.
+
+### Step 3: Execute
+
+Call `mcp__plane__*` tools per the playbook. For each batch:
+
+- Honor the rate limit (60 req/min) — back off on 429
+- Paginate to completion when scoring requires the full set
+- For sample-mode invocations, stop at first page and label output as "(sampled)"
+
+### Step 4: Score + render
+
+Apply the scoring formula. Render the table verbatim per the playbook format.
+
+### Step 5: Append the behavioral signal
+
+After the table, write a 1–3 sentence "Behavioral signal" paragraph that names the pattern in plain language. Reference the NOI framing — what does this observation say about how the team behaves under pressure?
+
+## Output discipline
+
+- **No prescriptions**. The agent surfaces patterns; the human interprets and acts.
+- **No moralizing**. "Bob takes 6.8 days to clear blockers" is an observation. "Bob is bad at his job" is not — the same pattern can be intentional security review or unintentional overload, and the agent can't tell which.
+- **No raw dumps**. If you'd rather render 200 issue rows than the 6-row score-summary, you've lost the NOI thread. Compress.
+- **Frame outputs as questions the team can take to retro**. "67% of urgents don't ship — is the planning conversation reality-rooted, or theatrical?" is more useful than "67% of urgents don't ship."
+
+## Error Handling
+
+| Error | Recovery |
+|---|---|
+| Empty project | Return informative empty state — "no cycles closed in the last 90 days, can't compute velocity" |
+| API rate limit hit | Back off + retry; if persistent, return partial result with sampling note |
+| Auth error | Surface to orchestrator; user fixes credentials and re-runs |
+| Unfamiliar workflow (e.g., team doesn't use cycles) | Fall back to issue-level metrics where possible; otherwise return empty state |
+
+## Resources
+
+- Parent skill: `skills/plane/SKILL.md`
+- Sibling agent: `skills/plane/agents/plane-expert.md` — for API-surface help
+- NOI: `skills/plane/references/noi.md`
+- Compound commands playbook: `skills/plane/references/compound-commands.md`
+- API surface: `skills/plane/references/api-surface.md`

package/skills/plane/agents/plane-expert.md

@@ -0,0 +1,75 @@
+---
+name: plane-expert
+description: |
+  Plane API surface specialist. Answers "how do I query X in Plane" / "what endpoint
+  does Y" / "what is the response shape for Z" without firing live API calls.
+  Reads from the parent skill's references/api-surface.md as ground truth. Use when
+  the user wants to understand the API surface before running a compound command,
+  or when debugging an unexpected response shape from mcp__plane.
+allowed-tools: "Read,Glob,Grep"
+model: inherit
+---
+
+# Plane Expert (Domain Specialist)
+
+> **Parent skill**: `skills/plane/SKILL.md`
+
+A read-only agent that answers questions about Plane's API surface from the documented references. Does NOT call `mcp__plane` tools — its job is to teach the surface, not to query it.
+
+## Overview
+
+When the orchestrator skill detects an "API help mode" prompt — the user wants to understand the surface, not run a behavioral query — it delegates here. This agent reads `references/api-surface.md` and `references/compound-commands.md` and produces an answer grounded in those documents.
+
+## When to use
+
+- "What endpoint returns issues for a cycle?" → list_cycle_issues
+- "How do I get worklog data?" → get_total_worklogs / get_issue_worklogs
+- "Does Plane support webhook subscriptions?" → answer from documented surface
+- "What's the response shape of get_cycle?" → from api-surface.md
+- "Why does mcp__plane return uuids instead of names?" → because Plane normalizes by UUID; member/state/label resolution requires a follow-up call
+
+## Instructions
+
+### Step 1: Identify the API question type
+
+Three sub-types:
+
+1. **Endpoint discovery**: "what tool does X" — match user intent to a tool listed in api-surface.md
+2. **Response shape**: "what fields are in Y" — quote the schema excerpt from api-surface.md
+3. **Pagination / auth / rate-limit**: "how do I handle Z" — answer from the relevant section
+
+### Step 2: Answer from references
+
+Always cite the section of api-surface.md the answer came from. If the user's question isn't covered (e.g., they ask about an endpoint not in the documented subset), say so and direct them to the upstream Plane docs.
+
+### Step 3: Suggest the compound command if applicable
+
+If the user's question hints at a behavioral pattern (e.g., "how do I find stale tickets" or "which engineers are overloaded"), suggest the matching compound command from compound-commands.md instead of explaining the raw endpoint sequence.
+
+## Output
+
+Concise, citation-grounded answer. Format:
+
+```
+[Direct answer to the question]
+
+Per `references/api-surface.md` § [section]:
+[relevant excerpt]
+
+[Optional: "If you're trying to do X behaviorally, consider /plane-cycle-velocity instead"]
+```
+
+## Error Handling
+
+| Error | Recovery |
+|---|---|
+| Question references an undocumented endpoint | Acknowledge gap; point at upstream Plane docs |
+| Question is actually a behavioral query in disguise | Redirect to `plane-analyst` via the orchestrator skill |
+| References file missing | Report the gap; suggest re-forging the plugin |
+
+## Resources
+
+- Parent skill: `skills/plane/SKILL.md`
+- Sibling agent: `skills/plane/agents/plane-analyst.md` — for behavioral queries
+- API surface: `skills/plane/references/api-surface.md`
+- Compound commands: `skills/plane/references/compound-commands.md`

package/skills/plane/references/api-surface.md

@@ -0,0 +1,121 @@
+# Plane API Surface
+
+**Captured**: 2026-05-07
+**Source of truth**: `mcp__plane` MCP server tool list + Plane open-source repo (`makeplane/plane`)
+**Plane version targeted**: API v1, current production at `projects.intentsolutions.io`
+
+This skill operates against Plane's public REST API. It does NOT implement the API client itself — instead it delegates to `mcp__plane` MCP tools (already wired in the user's environment). When `mcp__plane` is unavailable, the skill degrades to a documentation-only mode and instructs the user how to install it.
+
+## Authentication
+
+Three environment variables, all required:
+
+```bash
+PLANE_API_KEY="<your_personal_access_token>"
+PLANE_WORKSPACE_SLUG="<workspace_slug>"
+PLANE_API_HOST_URL="https://projects.intentsolutions.io"
+```
+
+Mirror these into the MCP server config (already done in user's `~/.claude.json` per `reference_plane_setup.md` memory).
+
+**Rate limits**: 60 requests/minute on the standard tier. Compound commands batch where possible and back off on 429.
+
+## Endpoint groups consumed
+
+### Issues
+
+| Tool | Purpose | Used by compound command |
+|---|---|---|
+| `mcp__plane__list_project_issues` | Enumerate issues per project | All — base query |
+| `mcp__plane__get_issue_using_readable_identifier` | Full issue detail by `PROJECT-N` ID | priority-drift, stale-tickets |
+| `mcp__plane__list_states` | Project state enum (Backlog / In Progress / Done / etc.) | stale-tickets, cycle-velocity |
+| `mcp__plane__update_issue` | Mutation — used only when explicitly requested by user | (none — this skill is read-mostly) |
+
+### Cycles
+
+| Tool | Purpose | Used by compound command |
+|---|---|---|
+| `mcp__plane__list_cycles` | Cycle list per project | cycle-velocity, priority-drift |
+| `mcp__plane__get_cycle` | Cycle details (start/end dates, completion stats) | cycle-velocity |
+| `mcp__plane__list_cycle_issues` | Issues planned in a specific cycle | cycle-velocity, priority-drift |
+| `mcp__plane__transfer_cycle_issues` | Track issues moved between cycles (re-planning signal) | priority-drift (read-side via list_cycle_issues + diff over time) |
+
+### Modules
+
+| Tool | Purpose | Used by compound command |
+|---|---|---|
+| `mcp__plane__list_modules` | Module enumeration | cross-project-load |
+| `mcp__plane__list_module_issues` | Issues per module | cross-project-load |
+
+### Comments / Activity
+
+| Tool | Purpose | Used by compound command |
+|---|---|---|
+| `mcp__plane__get_issue_comments` | Comment thread on an issue | reviewer-gate-strength |
+
+### Workspace + Worklogs
+
+| Tool | Purpose | Used by compound command |
+|---|---|---|
+| `mcp__plane__get_workspace_members` | Engineer roster | engineer-velocity, cross-project-load |
+| `mcp__plane__get_total_worklogs` | Time tracked per assignee | engineer-velocity |
+| `mcp__plane__get_issue_worklogs` | Time tracked per issue | cycle-velocity (estimate-vs-actual) |
+
+## Response shapes (excerpts)
+
+Full schemas live at `mcp__plane`'s tool-detail descriptions; these are the shapes the compound commands JOIN against.
+
+### Issue (excerpt)
+
+```jsonc
+{
+  "id": "uuid",
+  "name": "Issue title",
+  "state": "uuid",                  // → joined against list_states
+  "priority": "urgent|high|medium|low|none",
+  "assignees": ["uuid", ...],       // → joined against get_workspace_members
+  "created_at": "ISO-8601",
+  "updated_at": "ISO-8601",
+  "completed_at": "ISO-8601 | null",
+  "estimate_point": 5,              // → estimate-vs-actual signal
+  "cycle_id": "uuid | null",
+  "module_ids": ["uuid", ...],
+  "labels": ["uuid", ...]
+}
+```
+
+### Cycle (excerpt)
+
+```jsonc
+{
+  "id": "uuid",
+  "name": "Sprint 14",
+  "start_date": "ISO-8601",
+  "end_date": "ISO-8601",
+  "total_issues": 23,
+  "completed_issues": 18,
+  "cancelled_issues": 1,
+  "started_issues": 4,              // still open at close — overrun signal
+  "unstarted_issues": 0
+}
+```
+
+## Pagination
+
+All `list_*` endpoints return cursor-based pagination:
+
+```jsonc
+{
+  "results": [...],
+  "next_cursor": "<opaque-token>",
+  "prev_cursor": "<opaque-token>"
+}
+```
+
+Compound commands paginate to completion when scoring requires the full set; sample-mode (first page only) is supported via the `--sample` flag for fast iteration.
+
+## When the API surface drifts
+
+Re-run via `/skill-creator --reforge plane` (see `/skill-creator` SKILL.md § Reforge Mode Workflow). Auto-bumps version per detected change scope.
+
+Future enhancement (Phase 5C cron): scheduled daily diff against the live API surface, opens a GitHub issue tagged `forge-drift` when an endpoint adds / removes / changes shape.

package/skills/plane/references/compound-commands.md

@@ -0,0 +1,164 @@
+# Compound Commands — Plane Behavior Observatory
+
+Each command answers a question that **cannot** be answered from any single Plane API endpoint. Each is derived from the NOI (`references/noi.md`) and the Project / Workflow archetype's default `velocity / stale / bottleneck` triplet, adapted to Plane's behavioral observatory framing.
+
+## Command 1 — `/plane-cycle-velocity`
+
+**Question**: Does this team's cycle velocity match its planning?
+
+**Synthesizes**:
+- `list_cycles` → enumerate completed cycles
+- `get_cycle` (per cycle) → planned start/end + actual completion counts
+- `list_cycle_issues` (per cycle) → estimate_point sum vs. completed_issues sum
+- `get_issue_worklogs` (sample) → actual time spent per issue (if estimate_point unset)
+
+**Output**:
+
+```
+PROJECT: braves-booth
+Cycles analyzed: 8 most recent
+
+Cycle              Planned   Completed  Overrun   Estimate   Actual    Variance
+─────────────────  ────────  ─────────  ────────  ─────────  ────────  ────────
+Sprint 14          14d        18d        +4d       42 pts     58 pts    +38%
+Sprint 13          14d        14d         0d       38 pts     34 pts    -10%
+Sprint 12          14d        21d        +7d       45 pts     61 pts    +36%
+Sprint 11          14d        14d         0d       40 pts     42 pts     +5%
+...
+
+Pattern: 4/8 cycles overrun by ≥ 4 days. Mean variance: +21%.
+Behavioral signal: cycle planning is ~20% optimistic — either reduce
+scope per cycle or extend cycle length.
+```
+
+**Caching**: cycle data is immutable once a cycle closes; cache by cycle ID in `~/.cache/plane-skill/cycles.sqlite`.
+
+## Command 2 — `/plane-stale-tickets`
+
+**Question**: Which tickets are quietly failing under shared ownership?
+
+**Synthesizes**:
+- `list_project_issues` → open issues
+- `list_states` → identify "In Progress" state UUIDs
+- `get_issue_comments` (per stale candidate) → assignee changes during the open window
+
+**Output**:
+
+```
+PROJECT: braves-booth
+Threshold: In Progress > 14 days
+
+Issue            Days In   Assignee Churn   Last Comment   Score
+───────────────  ────────  ───────────────  ─────────────  ─────
+BRAVES-78        29d       3 assignees      11d ago        9.2 ⚠
+BRAVES-91        21d       2 assignees      4d ago         5.1
+BRAVES-85        18d       1 assignee       2d ago         2.8
+
+Score = days_in × (1 + assignee_churn) × (days_since_last_comment / 7)
+
+Behavioral signal: BRAVES-78 has 3 assignees and hasn't moved in 11 days
+— classic shared-ownership orphan. Assign one owner or close as won't-do.
+```
+
+**Caching**: open-issue list is mutable; refresh on each invocation.
+
+## Command 3 — `/plane-reviewer-gate-strength`
+
+**Question**: Which reviewers gate-keep harder than the spec demands?
+
+**Synthesizes**:
+- `list_project_issues` filtered to recently-closed
+- `get_issue_comments` (per closed issue) → look for "blocked by reviewer" pattern + reviewer assignment timing
+
+Heuristic for blocker detection: a comment containing a state-change to "blocked" or text matching `/blocked|review|approval/i`, followed by a comment lifting the block.
+
+**Output**:
+
+```
+PROJECT: braves-booth
+Period: last 30 days
+
+Reviewer    Issues Gated   Mean Time Blocked   Verdict
+──────────  ─────────────  ──────────────────  ──────────────────────
+Alice         12             1.2 days           Engineer-fast clearance
+Bob            8             6.8 days           Bottleneck — not a senior
+Carol         15             2.1 days           Healthy review cadence
+
+Behavioral signal: Bob's 6.8-day mean indicates a process bottleneck.
+Either re-route reviews, define explicit review SLAs, or split Bob's
+queue.
+```
+
+**Note**: this command doesn't define "good" or "bad" reviewer behavior — the score surfaces friction, the human decides whether the friction is intentional (security review) or unintentional (overload).
+
+## Command 4 — `/plane-priority-drift`
+
+**Question**: Does the team plan high-priority work but ship low-priority work?
+
+**Synthesizes**:
+- `list_cycles` → recent closed cycles
+- `list_cycle_issues` (per cycle) → priority distribution at planning time
+- Cross-reference with `get_issue_using_readable_identifier` for issues marked `completed` in the cycle
+
+**Output**:
+
+```
+PROJECT: braves-booth
+Cycles analyzed: 8 most recent
+
+Priority   Planned    Shipped    Drift
+─────────  ─────────  ─────────  ─────────
+urgent          12         4      -67%
+high            38        18      -53%
+medium          24        31      +29%
+low              8        29     +263%
+
+Pattern: 67% of planned urgents and 53% of planned highs do not ship
+in the cycle they're planned in. Meanwhile low-priority work ships
++263% above plan.
+
+Behavioral signal: the planning conversation does not reflect what
+actually gets done. Either the team plans theatrically and ships
+opportunistically, or planning is happening at the wrong time/place.
+```
+
+**This is the NOI-specific compound command** — not in the default Project/Workflow archetype set; added because the NOI's "stated-vs-actual priority drift" framing demands it.
+
+## Command 5 — `/plane-cross-project-load`
+
+**Question**: Which engineers are spread across too many active projects?
+
+**Synthesizes**:
+- `get_workspace_members` → engineer roster
+- `list_project_issues` (across all active projects, filtered to assignee × open state)
+- `list_modules` (used as a project-internal grouping signal)
+
+**Output**:
+
+```
+WORKSPACE: internal
+Active projects: 14
+
+Engineer        Projects   Active Cycles   Open Issues   Verdict
+──────────────  ─────────  ──────────────  ────────────  ─────────────
+Alice               7            6              42        Stretched
+Bob                 4            4              23        Healthy
+Carol              11            9              68        Crisis ⚠
+David               2            2               9        Focused
+
+Behavioral signal: Carol is on 11 active projects and 9 active cycles
+— that's not focus, that's project-management debt. Either consolidate
+projects or rotate Carol off most.
+```
+
+**Caching**: assignment data is mutable; refresh on each invocation.
+
+## How agents consume this
+
+`plane-expert` agent reads from `api-surface.md` and answers "how do I query X" questions about the Plane API.
+
+`plane-analyst` agent reads from `noi.md` + this file and orchestrates the compound commands above. The orchestrator skill (`SKILL.md`) routes to one or the other based on user intent: "tell me about Plane endpoint X" → expert; "how is my team behaving in cycle Y" → analyst.
+
+## When new compound commands are added
+
+Constraint: any new command must answer a behavioral question that the NOI implies. If a command can be answered by a single endpoint call (e.g., "list issues assigned to me"), it does not belong here. Add it to a separate utility skill or call `mcp__plane` directly.

package/skills/plane/references/noi.md

@@ -0,0 +1,35 @@
+# NOI — Plane
+
+> **Plane is a team behavior observatory.**
+
+## What this NOI claims
+
+Plane describes itself as an open-source project tracker — issues, cycles, modules, projects, work-in-progress. That's the **claimed identity**. It's accurate but it's the floor, not the ceiling.
+
+The **secret identity** is what you can read off Plane that nobody talks about: how a team actually behaves under pressure. Cycle close-out velocity, the gap between estimate and actual, which workflows quietly orphan tickets in `In Progress`, which engineers consistently ship under the wire and which stack up at the deadline, which reviewers gate-keep harder than the spec demands, which projects burn cycles on rework versus on net-new work, and where the team's stated priorities diverge from what's actually getting closed.
+
+That's not project tracking. That's an observatory pointed at organizational behavior, with Plane's API as the telescope.
+
+## What this NOI unlocks that the obvious wrapper doesn't
+
+A "Plane wrapper" skill calls `list_project_issues` and renders results. Useful but generic — every Plane SDK does that. The team-behavior-observatory framing demands compound queries that synthesize multiple endpoints into observations no single endpoint exposes:
+
+- **Cycle close velocity vs. estimate**: cross-reference cycle close dates with cycle planning dates and issue-level estimate vs. actual time-to-close. Surfaces "the team consistently overruns 2-week cycles by 4 days" — invisible from any single endpoint.
+- **Stale-ticket drift**: `In Progress` tickets older than the cycle they were planned in, scored by ownership churn (assignee changes during the open window). Surfaces "the cluster of tickets that quietly fail every two weeks because three people share ownership."
+- **Reviewer gate strength**: time-from-blocker-flagged to blocker-cleared, sliced by reviewer. Distinguishes reviewers who clear blockers fast (engineers) from reviewers who serve as control points (process gatekeeping). Surfaces "PRs assigned to X close in 1.4 days; PRs assigned to Y close in 6.8 — Y is a bottleneck, not a senior."
+- **Stated-vs-actual priority drift**: the priority labels on planned issues vs. the priority labels on issues that actually closed in the cycle. Surfaces "the team plans P1s and ships P3s — the planning conversation is theater."
+- **Cross-project workload concentration**: aggregate `assigned_to` counts across all active projects per engineer. Surfaces "Alice is on 7 active cycles across 4 projects; that's not focus, that's project-management debt."
+
+None of these are visible in Plane's dashboard. None are accessible from a single API endpoint. Each requires the skill to JOIN data the API only exposes per-resource — which is the compound-command discipline the forge mandates.
+
+## Why this NOI matters for downstream design
+
+Every gate downstream of this point reads from `noi.md`. The compound commands designed in `compound-commands.md` are derived from these specific observations, not from "what endpoints does Plane have." The agents (`plane-expert`, `plane-analyst`) carry this framing in their system prompts — they answer behavioral questions about teams, not ticket-CRUD questions.
+
+If a future maintainer asks "should we add X to this skill?" — the answer is: **does X surface team-behavior signal?** If yes, design it as a compound query. If no (e.g., "create issue from CLI"), add it to a separate utility skill instead. The NOI is the gate that keeps this skill from sprawling into a generic Plane wrapper.
+
+## Not what this NOI claims
+
+- Not a CRUD wrapper for Plane (that's `mcp__plane` directly)
+- Not a CLI alternative to `projects.intentsolutions.io` (the web UI is fine for ticket entry)
+- Not a Plane-specific clone of standard project-tracker skills (the framing rejects that direction)