chore: rename hawk-eco to graycode-eco, drop bundled skills

.github/actions/checkout-eyrie/action.yml

@@ -1,5 +1,5 @@
 name: Checkout ecosystem
-description: Clone Hawk ecosystem repos into hawk/external for hawk go.work
+description: Clone graycode-eco ecosystem repos into hawk/external for hawk go.work
 
 inputs:
   ref:

.shared-templates/Makefile.library.tmpl

@@ -1,4 +1,4 @@
-# Canonical hawk-eco Makefile for Go LIBRARY repos.
+# Canonical graycode-eco Makefile for Go LIBRARY repos.
 # Source of truth: .shared-templates/Makefile.library.tmpl at the eco root.
 # Placeholders rendered per repo: {{NAME}}.
 

.shared-templates/Makefile.python.tmpl

@@ -1,4 +1,4 @@
-# Canonical hawk-eco Makefile for Python repos.
+# Canonical graycode-eco Makefile for Python repos.
 # Source of truth: .shared-templates/Makefile.python.tmpl at the eco root.
 # Placeholders rendered per repo: {{NAME}}.
 

.shared-templates/README.md

@@ -1,6 +1,6 @@
-# hawk-eco shared templates
+# graycode-eco shared templates
 
-Every hawk-ecosystem repo's `Makefile`, `lefthook.yml`, and
+Every graycode-ecosystem repo's `Makefile`, `lefthook.yml`, and
 `.github/workflows/*.yml` carries a header comment like:
 
 ```
@@ -12,7 +12,7 @@ This directory is that source of truth. It lives here, in `hawk`, because
 there is no separate monorepo at the workspace root to hold it.
 
 **This directory is not built or run by hawk itself.** It is a template
-library that other hawk-ecosystem repos copy from and diff against.
+library that other graycode-ecosystem repos copy from and diff against.
 
 ## Layout
 

.shared-templates/docs/coverage-matrix.md

@@ -1,4 +1,4 @@
-# hawk-eco coverage thresholds
+# graycode-eco coverage thresholds
 
 Each repo's CI enforces its own minimum test-coverage percentage, hardcoded
 into that repo's `.github/workflows/ci.yml` (`THRESHOLD=` for the `go-ci.yml`

.shared-templates/lefthook.yml.tmpl

@@ -1,4 +1,4 @@
-# Canonical lefthook config for hawk-eco Go repos.
+# Canonical lefthook config for graycode-eco Go repos.
 # Source of truth: .shared-templates/lefthook.yml.tmpl
 #
 # Install lefthook:
@@ -140,7 +140,7 @@ prepare-commit-msg:
 
 # ---------------------------------------------------------------------------
 # Notes for foundation repos (hawk-core-contracts, hawk-mcpkit): these have
-# no hawk-eco dependencies at all, so `pre-push.commands.boundaries` checks
+# no graycode-eco dependencies at all, so `pre-push.commands.boundaries` checks
 # for *zero* GrayCodeAI/* imports rather than checking against a peer-engine
 # allowlist. The command line above is identical either way — only
 # scripts/check-ecosystem-boundaries.sh differs per repo role.

.shared-templates/scripts/check-ecosystem-boundaries.sh.tmpl

@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-# Canonical import-boundary guard for hawk-eco repos.
+# Canonical import-boundary guard for graycode-eco repos.
 # Source of truth: .shared-templates/scripts/check-ecosystem-boundaries.sh.tmpl
 #
 # This template has three real variants depending on the repo's role. Pick
@@ -54,7 +54,7 @@ echo "ecosystem boundary guard passed"
 
 # =============================================================================
 # VARIANT 2 — Foundation repo (hawk-core-contracts, hawk-mcpkit).
-# Foundation repos sit below everything: zero hawk-eco dependencies at all.
+# Foundation repos sit below everything: zero graycode-eco dependencies at all.
 # =============================================================================
 #
 # FORBIDDEN='github\.com/GrayCodeAI/(?!{{OWN_MODULE}}(/|"))'
@@ -67,7 +67,7 @@ echo "ecosystem boundary guard passed"
 # fi
 #
 # if [[ -n "${violations}" ]]; then
-#   echo "forbidden hawk-eco imports found in {{OWN_MODULE}}:"
+#   echo "forbidden graycode-eco imports found in {{OWN_MODULE}}:"
 #   echo "${violations}"
 #   echo
 #   echo "{{OWN_MODULE}} is a foundation repo — it must not depend on hawk, engines, or any other GrayCodeAI/* package"

.shared-templates/scripts/sync-external.sh

@@ -1,7 +1,7 @@
 #!/usr/bin/env bash
 # Read-only drift report: compares each external/<repo> submodule's pinned
 # commit against the HEAD of the sibling dev clone at ../<repo> (relative to
-# the hawk-eco workspace root). Unlike `make sync-submodules` (which mutates
+# the graycode-eco workspace root). Unlike `make sync-submodules` (which mutates
 # the submodule checkout), this makes no changes — it only reports.
 #
 # Typical drift: you commit changes in ../tok, but forget `make

.shared-templates/workflows/go-ci.yml.tmpl

@@ -1,4 +1,4 @@
-# Canonical CI workflow for hawk-eco Go repos.
+# Canonical CI workflow for graycode-eco Go repos.
 # Source of truth: .shared-templates/workflows/go-ci.yml.tmpl
 #
 # Placeholders rendered per repo:
@@ -228,7 +228,7 @@ jobs:
         run: go build ./...
 
 # -----------------------------------------------------------------------------
-# Foundation repos (hawk-core-contracts, hawk-mcpkit) have zero hawk-eco
+# Foundation repos (hawk-core-contracts, hawk-mcpkit) have zero graycode-eco
 # dependencies, so they drop the GOPROXY/GOPRIVATE/GONOSUMDB env block above
 # and every "Clone <peer repo>" step that other repos may add for local
 # workspace deps — there is nothing to clone.

.shared-templates/workflows/go-release.yml.tmpl

@@ -23,7 +23,7 @@ jobs:
           fetch-depth: 0   # goreleaser needs full history for changelog
 
       # Only needed if this repo has local workspace dependencies on other
-      # hawk-eco repos at build time (hawk itself clones eyrie this way via
+      # graycode-eco repos at build time (hawk itself clones eyrie this way via
       # ./.github/actions/checkout-eyrie). Omit for repos with none.
 
       - name: Set up Go

.shared-templates/workflows/python-ci.yml.tmpl

@@ -1,4 +1,4 @@
-# Canonical CI workflow for hawk-eco Python repos.
+# Canonical CI workflow for graycode-eco Python repos.
 # Source of truth: .shared-templates/workflows/python-ci.yml.tmpl
 #
 # Placeholders rendered per repo:

.shared-templates/workflows/python-release.yml.tmpl

@@ -1,4 +1,4 @@
-# Canonical PyPI publish workflow for hawk-eco Python repos.
+# Canonical PyPI publish workflow for graycode-eco Python repos.
 # Triggered by release-please when it pushes a v* tag.
 # Source of truth: .shared-templates/workflows/python-release.yml.tmpl
 #

AGENTS.md

@@ -1,20 +1,23 @@
 ---
-description: Extending hawk-eco — how to write AGENTS.md files, custom specialists, skills, hooks, MCP servers, and plugins.
+description: Extending hawk — how to write AGENTS.md files, custom specialists, skills, hooks, MCP servers, and plugins.
 globs: "*.go, *.js, *.md, *.json, *.toml, *.yaml, *.yml"
 alwaysApply: false
 ---
 
-# Extending hawk-eco
+# Extending hawk
 
-hawk-eco is an open-source code intelligence platform. This document describes how to extend it with custom tools, skills, hooks, and integrations.
+hawk is an open-source code intelligence platform. It lives in the `graycode-eco`
+workspace alongside the ecosystem repos that power it (`eyrie`, `hawk-core-contracts`,
+`tok`, `yaad`, `trace`, `sight`, `inspect`). This document describes how to extend
+hawk with custom tools, skills, hooks, and integrations.
 
 ## Development workflow
 
 When starting any new work (feature, fix, refactor, chore), always create a feature branch from `main` first. Never commit directly to `main`. Use branch naming conventions like `feat/<description>`, `fix/<description>`, or `chore/<description>`. Open a PR, ensure CI is green, then merge.
 
 ## 1. Drop a project `AGENTS.md`
 
-When hawk-eco starts in a directory, it looks for project-level instructions and injects them into the system prompt. The lookup walks from your current working directory **up to the nearest git root** and reads the first matching file at each level — general rules at the repo root, more specific rules in sub-trees. Files are labeled with their directory in the prompt (e.g. `## Project guidelines (services/api/AGENTS.md)`).
+When hawk starts in a directory, it looks for project-level instructions and injects them into the system prompt. The lookup walks from your current working directory **up to the nearest git root** and reads the first matching file at each level — general rules at the repo root, more specific rules in sub-trees. Files are labeled with their directory in the prompt (e.g. `## Project guidelines (services/api/AGENTS.md)`).
 
 Accepted file names, in priority order at each level:
 
@@ -26,7 +29,7 @@ Accepted file names, in priority order at each level:
 
 Matching is **case-insensitive** on the basename, so `AGENTS.md`, `Agents.md`, and `agents.md` resolve to the same file on Windows and macOS. The git-tracked filename in this repo is `AGENTS.md` — keep that on case-sensitive filesystems (Linux, the WSL filesystem, or a CI runner) to match what the loader looks for.
 
-Both files use the same format. YAML frontmatter is optional; the markdown body is loaded as instructions for the agent. hawk-eco reads the file once at session start, so changes take effect on the next launch — not mid-session.
+Both files use the same format. YAML frontmatter is optional; the markdown body is loaded as instructions for the agent. hawk reads the file once at session start, so changes take effect on the next launch — not mid-session.
 
 ```markdown
 # Project conventions for <your project>
@@ -39,26 +42,26 @@ Both files use the same format. YAML frontmatter is optional; the markdown body
 
 Tips:
 
-- Keep each file under ~8 KiB. hawk-eco caps the **total** across all matched files at 32 KiB; everything past the cap is dropped.
+- Keep each file under ~8 KiB. hawk caps the **total** across all matched files at 32 KiB; everything past the cap is dropped.
 - Re-state rules in the imperative voice: "Run `make lint`", not "you should consider running the linter".
 - Don't put secrets, model IDs, or environment-specific paths in `AGENTS.md`. Use config files for those.
-- In a monorepo, drop a narrower `AGENTS.md` in each sub-tree (e.g. `services/api/AGENTS.md`). hawk-eco picks those up automatically when you launch from inside the sub-tree.
+- In a monorepo, drop a narrower `AGENTS.md` in each sub-tree (e.g. `services/api/AGENTS.md`). hawk picks those up automatically when you launch from inside the sub-tree.
 - A YAML frontmatter block (`---\n...\n---`) at the top is preserved verbatim in the injected prompt but is not parsed for `globs:` or `alwaysApply:` scoping today — keep the body self-contained.
 
 ### Personal guidelines, across every project
 
-For preferences that follow *you*, not a specific repo (tone, tooling habits, workflow), drop a `ZERO.md` in your user config directory: `~/.config/hawk-eco/ZERO.md` on Linux/macOS, `%AppData%\Roaming\hawk-eco\ZERO.md` on Windows — the same directory as config files and your personal specialists. Same format and 8 KiB cap as the project files above, and the same case-insensitive basename match.
+For preferences that follow *you*, not a specific repo (tone, tooling habits, workflow), drop a `ZERO.md` in your user config directory: `~/.hawk/ZERO.md` on Linux/macOS, `%AppData%\hawk\ZERO.md` on Windows — the same directory as config files and your personal specialists. Same format and 8 KiB cap as the project files above, and the same case-insensitive basename match.
 
 This file is injected as its own `## User guidelines` section, before the project's `AGENTS.md`/`ZERO.md`, and is labeled as personal preference in the prompt: project guidelines are the later, more specific instruction and take precedence over it when the two conflict.
 
 ## 2. Custom specialists
 
-Specialists are hawk-eco's sub-agents. Three scopes, in priority order:
+Specialists are hawk's sub-agents. Three scopes, in priority order:
 
 | Scope | Path | Shared? |
 | --- | --- | --- |
-| Built-in | compiled into hawk-eco | yes |
-| User | `~/.config/hawk-eco/specialists/*.md` | no — your machine only |
+| Built-in | compiled into hawk | yes |
+| User | `~/.hawk/specialists/*.md` | no — your machine only |
 | Project | `./.zero/specialists/*.md` | yes — the repo team |
 
 Project overrides user overrides built-in when names collide.
@@ -86,23 +89,34 @@ Reply with one JSON object per finding: `{"file", "line", "severity", "message",
 CLI management:
 
 ```bash
-hawk-eco specialist list
-hawk-eco specialist show api-reviewer
-hawk-eco specialist create api-reviewer \
+hawk specialist list
+hawk specialist show api-reviewer
+hawk specialist create api-reviewer \
     --project \
     --description "Reviews API changes" \
     --tools read-only,plan \
     --prompt "$(cat api-reviewer.md)"
-hawk-eco specialist edit api-reviewer --project
-hawk-eco specialist delete api-reviewer --project
-hawk-eco specialist path                       # prints the resolved specialists directory
+hawk specialist edit api-reviewer --project
+hawk specialist delete api-reviewer --project
+hawk specialist path                       # prints the resolved specialists directory
 ```
 
 ## 3. Skills
 
-Skills are markdown instruction files that extend agent capabilities. They can be:
-- Project-scoped: dropped in `./.zero/skills/` or `./skills/`
-- User-scoped: dropped in `~/.config/hawk-eco/skills/`
+hawk ships **no bundled skills** by default. Skills are markdown instruction
+files that extend agent capabilities, sourced from the separate
+`GrayCodeAI/hawk-community-skills` repo and installed on demand:
+
+```bash
+hawk skills search <query>          # find skills in hawk-community-skills
+hawk skills install <owner/repo> [skill-name]   # install after user approval
+hawk skills list                    # list installed skills
+hawk skills remove <name>
+```
+
+Installed skills live in user or project scope:
+- User-scoped: `~/.hawk/skills/`
+- Project-scoped: `./.zero/skills/` or `./skills/`
 
 A skill manifest:
 
@@ -130,45 +144,45 @@ Hooks allow custom commands to run at specific lifecycle points:
 - `sessionEnd` — runs at session teardown
 
 ```bash
-hawk-eco hook add beforeReview --command "lint-check"
-hawk-eco hook remove beforeReview
-hawk-eco hook list
+hawk hook add beforeReview --command "lint-check"
+hawk hook remove beforeReview
+hawk hook list
 ```
 
 ## 5. MCP integration
 
-MCP (Model Context Protocol) servers can expose tools to hawk-eco:
+MCP (Model Context Protocol) servers can expose tools to hawk:
 
 ```bash
-hawk-eco mcp add --name server --url http://localhost:8080
-hawk-eco mcp remove server
-hawk-eco mcp list
+hawk mcp add --name server --url http://localhost:8080
+hawk mcp remove server
+hawk mcp list
 ```
 
 ## 6. Plugins
 
-Plugins extend hawk-eco with custom tools and capabilities:
+Plugins extend hawk with custom tools and capabilities:
 
 ```bash
-hawk-eco plugin add --name my-plugin --path ./my-plugin
-hawk-eco plugin remove my-plugin
-hawk-eco plugin list
+hawk plugin add --name my-plugin --path ./my-plugin
+hawk plugin remove my-plugin
+hawk plugin list
 ```
 
 ## 7. Verification
 
-hawk-eco includes a self-verification system to validate local changes before contributing:
+hawk includes a self-verification system to validate local changes before contributing:
 
 ```bash
-hawk-eco verify
-hawk-eco verify --fix
+hawk verify
+hawk verify --fix
 ```
 
 ## Development
 
 ```bash
 make lint
-hawk-eco verify
+hawk verify
 ```
 
 ### Architecture note: cross-repo contracts