Asterweave vs. the repository
This is the single most important distinction for using Asterweave well. Getting it wrong produces either a repository that fights the plugin, or a plugin that has been quietly reimplemented per-repository and has drifted from its safety guarantees.
┌───────────────────────────────┐
│ ASTERWEAVE (the plugin) │
│ Reusable capability │
│ │
│ 16 workflow skills │
│ 13 generic specialist agents │
│ 2 hooks (destructive-op guard, │
│ evidence stop gate) │
│ Graph orchestration + state │
│ GitHub / Azure DevOps MCP │
└───────────────┬────────────────┘
│ routes to, reads
▼
┌───────────────────────────────┐
│ REPOSITORY │
│ │
│ CLAUDE.md │
│ .claude/rules/*.md │
│ .claude/agents/*.md (optional) │
│ .claude/asterweave.json │
│ specs/ (optional, if it exists)│
│ src/, tests/ │
└───────────────────────────────┘
Asterweave owns
- the delivery graph and its node contracts, attempt budgets, and typed edges;
- the sixteen
/asterweave:*skills and thirteen generic specialist agents; - destructive-command blocking and the evidence stop gate;
- durable workflow state and the append-only event ledger;
- GitHub/Azure DevOps MCP interaction: issues, PRs, CI checks, review comments;
- the evidence contract — what counts as proof a claim is true.
Repository .claude/ owns
CLAUDE.md— short, stable, always-loaded facts about the repository;.claude/rules/*.md— path-scoped conventions (backend, database, security, ...);.claude/agents/*.md— only genuinely domain-specific specialists a generic Asterweave agent cannot reasonably provide (see Repository agents);.claude/asterweave.json— routing to project skills/agents per stage, plus required quality-gate commands (see asterweave.json reference);- project skills under
.claude/skills/— reusable, repository-specific workflows, which also double as the repository's own slash commands.
specs/ owns (when a repository has one)
- functional requirements (
FR-###) and quality attributes (NFR-###); - constraints (
C-###) the design must respect; - use cases (
UC-###) — actors, preconditions, main/alternate flows, postconditions; - domain vocabulary.
Asterweave never generates specs/. It reads and links to one your repository already has, and can propose creating or updating a single use case for a normal/complex change under explicit approval. See Specifications.
The rule that keeps these from colliding
Do not duplicate Asterweave's workflows, generic agents, or safety gates inside a repository's
.claude/configuration.
Concretely:
- Don't write a repository
deliver.mdcommand — Asterweave's/asterweave:deliveralready exists globally. - Don't write a generic
code-reviewerorsecurity-revieweragent — Asterweave'sasterweave:staff-reviewerandasterweave:security-revieweralready exist. Writefinance-domain-revieweronly if it holds bounded, recurring domain expertise those generic reviewers cannot provide. - Don't write a repository hook that re-blocks
git push --force— Asterweave'sPreToolUsehook already does that. Write a repository hook only for enforcement Asterweave genuinely does not cover. - Don't put product requirements in
CLAUDE.md— that belongs inspecs/, read byanalyzeandchallenge.
/asterweave:scaffold applies exactly this classification when it proposes changes: every existing .claude/agents/*.md is judged KEEP (bounded domain expertise), MERGE (fold real domain rules into a rule file, drop the agent), or REMOVE (duplicates a generic Asterweave role) — never by file name, by actual responsibility. See Repository scaffolding.
A decision tree for new project knowledge
Next
- Repository scaffolding — what
/asterweave:scaffoldactually detects, writes, preserves, and refuses to delete. - Rules — the difference between plugin-enforced policy and project rules.
- Agent routing — how
.claude/asterweave.jsonconnects the two sides.