chore: move skills and evals to plugins/bin, remove legacy root configs

Skills and evals migrated from .agents/ to plugins/bin/ plugin directory.
Remove .mcp.json, provider-manifest.sh, and skills-lock.json legacy artifacts.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.claude-plugin/marketplace.json

@@ -8,6 +8,11 @@
       "name": "kyberforge",
       "description": "Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace.",
       "source": "./plugins/kyberforge"
+    },
+    {
+      "name": "bin",
+      "description": "A place for things to be binned",
+      "source": "./plugins/bin"
     }
   ]
 }

.github/plugin/marketplace.json

@@ -8,6 +8,11 @@
       "name": "kyberforge",
       "description": "Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace.",
       "source": "./plugins/kyberforge"
+    },
+    {
+      "name": "bin",
+      "description": "A place for things to be binned",
+      "source": "./plugins/bin"
     }
   ]
 }

.mcp.json

@@ -1,3 +0,0 @@
-{
-  "mcpServers": {}
-}

AGENTS.md

@@ -4,9 +4,6 @@ This repo is the global AI development configuration repository — the authorit
 
 ## Structure
 
-- `core/` — provider-agnostic source of truth (plain language, no tool-specific references)
-- `.agents/skills/` — directly-deployed skills (Agent Skills standard); deployed to `~/.agents/skills/` via `install.sh`; marketplace and factory skills live in `plugins/kyberforge/` instead
-- `.agents/evals/` — eval.yaml files for skills not bundled into a plugin
 - `.claude-plugin/` — marketplace manifest (`marketplace.json`); read by both Claude Code and Copilot CLI
 - `plugins/` — installable plugin units; each is self-contained (skills, agents, hooks, MCP servers, bundled assets); install separately via `claude plugin install <name>@holocron`
 - `providers/claude-code/` — Claude Code adapter (deployed to `~/.claude/` via `install.sh`)
@@ -33,7 +30,6 @@ Read these on demand:
 
 ## Key rules
 
-- `core/` content must use plain imperative language — no tool names, provider APIs, or format assumptions
 - Never edit files deployed by `sync.sh` directly in a project; put customizations in override files
 - `providers/claude-code/CLAUDE.md` is the deployed global config — edit it there, not here
 - Governance constraints from `core/instructions/governance.md` apply when building content in this repo — hard prohibitions on secrets and data, HITL requirements before irreversible actions, sycophancy resistance, and deterministic execution preference are always in effect

CONTEXT.md

@@ -7,9 +7,6 @@ description: Domain language and decisions for the global AI development config
 
 ## Principles
 
-### Provider-agnostic core
-`core/` content uses plain imperative language — no tool names, provider APIs, or format assumptions. Anything referencing a specific tool belongs in `providers/`, not `core/`. Providers translate core content into the tool's expected format and language.
-
 ### CLAUDE.md index model
 `AGENTS.md` is the source of always-on universal rules (provider-agnostic). `providers/claude-code/CLAUDE.md` is a thin adapter: it imports `~/.agents/AGENTS.md` via `@~/.agents/AGENTS.md` and appends Claude Code-specific additions (`@import` for governance.md, content index). Deployed to `~/.claude/CLAUDE.md` via `install.sh`. Context size is kept minimal — only what is needed every session is loaded upfront; detailed content is pulled on demand. See ADR-0012.
 
@@ -21,8 +18,6 @@ Workflow artifacts are committed to `docs/` in subdirectories by type. All are t
 
 **Naming:**
 - `docs/prd/<slug>.md` — Product Requirements Documents
-- `docs/ard/<slug>.md` — Architecture Requirements Documents
-- `docs/bug/<slug>.md` — Bug Briefs
 - `docs/notes/<slug>.md` — Exploration Notes
 - `docs/adr/NNNN-<slug>.md` — Architecture Decision Records
 - `docs/issues/NNNN-<slug>.md` — Issues
@@ -35,7 +30,7 @@ Workflow artifacts are committed to `docs/` in subdirectories by type. All are t
 
 **Slug** — kebab-case, lowercase, max 4–5 words, derived from the document title. No dates (git history carries dates). Examples: `chunk-2-instructions`, `user-auth-flow`, `database-migration`.
 
-**When each is written:** PRDs, ARDs, Bug Briefs, and Notes are pre-work — produced by a grill session before issues are created. ADRs are post-decision — written during or after implementation of an ARD when a hard-to-reverse choice is made. An improvement kick-off produces either a PRD (user-facing scope) or ARD (architectural scope).
+**When each is written:** PRDs, ARDs — produced by a grill session before issues are created. ADRs are post-decision — written during or after implementation of an ARD when a hard-to-reverse choice is made. An improvement kick-off produces either a PRD (user-facing scope) or ARD (architectural scope).
 
 ### Content chunk QA
 Instruction files and other content chunks cannot be unit tested. Verification is human-executed after implementation: open a new Claude session, exercise the relevant behaviour, and confirm the rules take effect. Each issue includes a short acceptance criteria checklist for the human to run post-commit. Automated QA applies to tooling (scripts, hooks); manual QA applies to agent behaviour and content correctness.
@@ -45,14 +40,8 @@ Instruction files and other content chunks cannot be unit tested. Verification i
 ### Conventional commits
 All commits in this repo follow the Conventional Commits specification (`feat:`, `fix:`, `docs:`, `chore:`, `refactor:`, `test:`). Convention is defined in `core/instructions/git.md`. Changelog tooling is a follow-on issue — convention is established first.
 
-### Project override model
-Projects override on-demand content (workflows, agent roles, prompts) by placing their own versions in `.claude/`. Universal rules are additive — projects extend them, not replace them. A rule that needs per-project suppression is not truly universal.
-
-### Sync model
-Projects must never edit synced files directly — customizations live in separate override files. A sync conflict is a signal that a synced file was edited directly.
-
-### Repo as source of truth
-All project state, decisions, context, and working conventions live in this repo. External memory systems should not be used for this project — they create a split-brain risk where cached state diverges from the repo. At the start of every session, read `CLAUDE.md`, `CONTEXT.md`, `docs/VISION.md`, and `docs/spec/overview.md`. Everything needed to orient is here.
+### Repo/gitea as source of truth
+All project state, decisions, context, and working conventions live in this repo ro Gitea. External memory systems should not be used for this project — they create a split-brain risk where cached state diverges from the repo. At the start of every session, read `CLAUDE.md`, `CONTEXT.md`, `docs/VISION.md`, and `docs/spec/overview.md`. Everything needed to orient is here.
 
 Before answering any design or architecture question, check for existing decisions: `docs/adr/` (hard architectural decisions) and the resolved rows (marked ✅) in the `docs/ROADMAP.md` open questions table. Never propose an approach without verifying no decision already covers it.
 
@@ -100,17 +89,14 @@ Contains always-on rules in plain markdown with no provider-specific syntax (no
 ### Skill composition
 A skill calling another skill by name to delegate a sub-task. The calling skill focuses on the orchestration decision ("when to do X"); the called skill owns the mechanics ("how to do X"). Established compositions: `grill-me` calls `write-adr` when a decision crystallises; `implement-feature` calls `tdd` as its implementation methodology. Composition chains are formalised as workflows in Chunk 4.
 
-### Source field
-Field (`source:`) in a skill's `META.md` tracking upstream provenance. An array — supports multiple upstream sources per skill. Each entry: `repo` (GitHub slug, e.g. `mattpocock/skills` — no URL, slug is stable and searchable), `commit` (exact SHA reviewed at adoption), `files` (list of files adopted with inline comments on what was taken), `updated` (date of last upstream review for this entry). Absence of `source:` means self-authored original. Upstream review cadence: per-skill during Chunk 3 (run during source review step); quarterly after roadmap completion (post Chunk 7). Companion field: `references:` (array of URLs or citations) for general external citations — distinct from `source:` which tracks adoptions with commit-level traceability. Both fields live in `META.md`, not in SKILL.md frontmatter.
+<!-- ### Source field
+Field (`source:`) in a skill's `META.md` tracking upstream provenance. An array — supports multiple upstream sources per skill. Each entry: `repo` (GitHub slug, e.g. `mattpocock/skills` — no URL, slug is stable and searchable), `commit` (exact SHA reviewed at adoption), `files` (list of files adopted with inline comments on what was taken), `updated` (date of last upstream review for this entry). Absence of `source:` means self-authored original. Upstream review cadence: per-skill during Chunk 3 (run during source review step); quarterly after roadmap completion (post Chunk 7). Companion field: `references:` (array of URLs or citations) for general external citations — distinct from `source:` which tracks adoptions with commit-level traceability. Both fields live in `META.md`, not in SKILL.md frontmatter. -->
 
-### META.md
-A per-skill markdown file containing a single YAML code block with provenance and audit fields: `version`, `updated`, `when`, `source`, and `references`. Lives alongside the SKILL.md in the skill directory (either `.agents/skills/<name>/META.md` or `plugins/<plugin>/skills/<name>/META.md`). Not loaded at agent startup — progressive disclosure principle: name and description route the skill; provenance is only needed for upgrade reviews and audits. Prevents these fields from being scanned on every session start alongside every skill's name and description. The authoritative schema is `META-TEMPLATE.md` in `plugins/kyberforge/skills/write-skill/`. See also: [[Source field]].
+<!-- ### META.md
+A per-skill markdown file containing a single YAML code block with provenance and audit fields: `version`, `updated`, `when`, `source`, and `references`. Lives alongside the SKILL.md in the skill directory (either `.agents/skills/<name>/META.md` or `plugins/<plugin>/skills/<name>/META.md`). Not loaded at agent startup — progressive disclosure principle: name and description route the skill; provenance is only needed for upgrade reviews and audits. Prevents these fields from being scanned on every session start alongside every skill's name and description. The authoritative schema is `META-TEMPLATE.md` in `plugins/kyberforge/skills/write-skill/`. See also: [[Source field]]. -->
 
 ### Provider-agnostic issue tracker
-Skills and workflows reference "linked issue" generically rather than a specific provider. In the file-based phase, an issue is a `docs/issues/NNNN-<slug>.md` file. When Gitea MCP is configured, the same skills use it instead. The active backend is determined at runtime by MCP availability. "Issue" is the canonical cross-provider term (GitHub, GitLab, Gitea all use it). Gitea-specific skills are a provider adapter (`providers/gitea/`), not part of the core library. See ADR-0011.
-
-### Design phase sequence
-The canonical pre-implementation sequence within any workstream: `grill-lean` (optional lightweight interrogation, no docs) → `grill-me` (primary: deep interrogation + domain alignment + ADR writing) → `write-prd` (why + what only, never how) → `architecture-review` (optional: technical approach evaluation, ≥2 options) → `break-into-issues` (independently shippable slices; proposes Gitea milestone groupings for PRDs producing >5 issues).
+Skills and workflows reference "linked issue" generically rather than a specific provider. In the file-based phase, an issue is a `docs/issues/NNNN-<slug>.md` file. When Gitea MCP is configured, the same skills use it instead. The active backend is determined at runtime by MCP availability. "Issue" is the canonical cross-provider term (GitHub, GitLab, Gitea all use it).
 
 ### PRD scope
 A PRD contains: problem statement, goals, explicit non-goals, functional requirements at feature level, success criteria. Never contains: technical approach, implementation steps, or EARS-level detail. HOW is handled downstream: workstream-level technical approach belongs in `architecture-review` (≥2 options, tradeoffs, optional step after `write-prd`); issue-level HOW belongs in issue design notes. Prerequisite: a completed grill session. Validated by inline self-checks in the `write-prd` skill.
@@ -125,13 +111,10 @@ Files that reference other files should declare those references explicitly. The
 A focused work session oriented around a single goal — a feature, bug, improvement, or exploration. Starts with a grill to produce an artifact (PRD, Bug Brief, ADR, etc.), runs through issue implementation, and closes with docs + commit. Ongoing skills (/diagnose, /prototype, /zoom-out) are invoked ad hoc within a workstream as needed.
 
 ### Workflow artifacts
-Output documents produced by a grill session that scope the work before implementation. All are committed to the repo under `docs/` following the docs convention. Each artifact generates one or more issues in `docs/issues/` but is not itself an issue.
+Output documents produced by a grill session that scope the work before implementation. All are committed to the repo under `docs/` following the docs convention. Each artifact generates one or more issues but is not itself an issue.
 
 Pre-work (grill output):
 - **PRD** (Product Requirements Document) — for features and improvements with user-facing scope
-- **ARD** (Architecture Requirements Document) — for architectural changes; defines what needs to change and why, analogous to a PRD but for architecture. Produced before implementation; not the same as an ADR.
-- **Bug Brief** — for bugs; feeds into /diagnose
-- **Exploration Note** — for ideation; may or may not produce issues
 
 Post-decision:
 - **ADR** (Architecture Decision Record) — records the decision made, alternatives considered, and rationale. Written during or after implementation of an ARD, not before. Hard-to-reverse decisions only.

plugins/bin/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "bin",
+  "displayName": "bin",
+  "version": "1.0.0",
+  "description": "A place for things to be binned",
+  "author": { "name": "Defame1297", "url": "https://git.dev.rkdr.net/Defame1297/" },
+  "license": "MIT",
+  "keywords": []
+}

plugins/bin/README.md

@@ -0,0 +1,40 @@
+# bin
+
+A place for things to be binned
+
+## Install
+
+**Claude Code:**
+
+```bash
+claude plugin marketplace add <owner>/<repo>
+claude plugin install bin@<marketplace-name>
+```
+
+**GitHub Copilot CLI:**
+
+```bash
+copilot plugin marketplace add <owner>/<repo>
+copilot plugin install bin
+```
+
+**Local (development):**
+
+```bash
+# Claude Code
+claude --plugin-dir ./plugins/bin
+
+# GitHub Copilot CLI
+copilot plugin install ./plugins/bin
+```
+
+## Contents
+
+| Component   | Path                                                 | Description                                                   |
+| -------------| ------------------------------------------------------| ---------------------------------------------------------------|
+| Skills      | `skills/`                                            | Slash commands available after install                        |
+| Agents      | `agents/`                                            | Role-based agents (`.md` for Claude, `.agent.md` for Copilot) |
+
+## Author
+
+Defame1297

plugins/bin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "bin",
+  "description": "A place for things to be binned",
+  "author": { "name": "Defame1297", "email": "defame1297@rkdr.net" },
+  "license": "MIT",
+  "keywords": [],
+  "agents": "agents/",
+  "skills": ["skills/"]
+}

providers/claude-code/provider-manifest.sh

@@ -1,6 +0,0 @@
-#!/usr/bin/env bash
-# Claude Code provider manifest — sourced by install.sh after deploy-manifest.sh.
-# Appends to SKILL_ADAPTERS, which must be initialised before sourcing this file.
-
-# Claude Code reads skills from ~/.claude/skills/, not ~/.agents/skills/ natively.
-SKILL_ADAPTERS+=(".claude/skills")

skills-lock.json

@@ -1,4 +0,0 @@
-{
-  "version": 1,
-  "skills": {}
-}