Add Repository Intelligence Bootstrap: repo-bootstrap.sh, all 13 agents updated, docs, tests
- scripts/repo-bootstrap.sh: generic idempotent bootstrap tool (status/bootstrap/refresh) - creates .opencode/ with repo-context, architecture, build-and-test, conventions, deployment skills - relevance-based skill generation (only creates what the repo actually has) - staleness detection via .bootstrap-meta (key=value, SHA-256 fingerprints) - marker-based manual protection (never overwrites unmarked files) - accepts --root flag for explicit repo targeting - scripts/test-repo-bootstrap.sh: 11 tests covering all 10 acceptance criteria - creation, idempotency, manual preservation, relevance detection - orchestrator/agent structural checks, staleness, genericness - install.sh workflow compatibility, malformed handling - agents/orchestrator.md: first-class Repository Intelligence Bootstrap stage - 10-step workflow, ownership rules table, staleness signals - consumption rules, backward compatibility, fallback procedure - All 12 subagent files: role-adapted Repository Intelligence section - architect: owns architecture skill - builder/tester: own build-and-test skill (shared) - explorer: owns repo-context skill - maintainer: owns conventions skill + audits .opencode/ - reviewer: validates consistency (consumer/reporter) - designer/detective/philosopher/toolsmith/workflow-architect/writer: consume-only - docs/REPOSITORY_INTELLIGENCE.md: full architecture documentation - README.md: updated layout, bootstrap usage, requirements - 13/13 agents installed, permission-engine verifier PASS
This commit is contained in:
Your Name
@@ -46,6 +46,23 @@ Your core behavior is:
|
||||
UNDERSTAND → IDENTIFY CONSTRAINTS → DEFINE OPTIONS → EVALUATE TRADE-OFFS → DECIDE → SCOPE → HANDOFF
|
||||
```
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before starting work, read `.opencode/AGENTS.md` and the
|
||||
architecture skill at `.opencode/skills/architecture/SKILL.md`. Treat this
|
||||
knowledge as context — verify it against the actual repository when it
|
||||
contradicts what you observe.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. When you make
|
||||
a durable architectural discovery (new component boundary, dependency rule, or
|
||||
integration constraint), add it to the architecture skill and strip the
|
||||
`GENERATED-SCAFFOLD` marker so bootstrap will not overwrite it. Never fill
|
||||
`.opencode/` with task-specific noise.
|
||||
|
||||
- **Owned**: `.opencode/skills/architecture/SKILL.md`
|
||||
- **Consume**: repo-context, conventions, build-and-test (when relevant)
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
Mirror disciplined practical engineering:
|
||||
|
||||
@@ -45,6 +45,23 @@ READ → CONFIRM SCOPE → IMPLEMENT → VERIFY → REPORT
|
||||
|
||||
You do not redesign the system merely because you discover a better design.
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before implementing, read `.opencode/AGENTS.md` and the
|
||||
build-and-test skill at `.opencode/skills/build-and-test/SKILL.md`. Treat this
|
||||
knowledge as context — verify build/convention claims against the actual
|
||||
repository before relying on them.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. When you
|
||||
discover durable build/tooling constraints (new command, dependency, or
|
||||
validation step), add them to build-and-test and strip the `GENERATED-SCAFFOLD`
|
||||
marker so bootstrap will not overwrite it. Never fill `.opencode/` with
|
||||
task-specific noise.
|
||||
|
||||
- **Owned**: `.opencode/skills/build-and-test/SKILL.md` (with Tester)
|
||||
- **Consume**: conventions, repo-context, architecture (when relevant)
|
||||
|
||||
## Hard Scope Boundary
|
||||
|
||||
Before changing anything, identify:
|
||||
|
||||
@@ -46,6 +46,22 @@ Your core behavior is:
|
||||
UNDERSTAND USERS → ANALYZE CONTEXT → DEFINE DESIGN → SPECIFY INTERACTIONS → VALIDATE ACCESSIBILITY → PRODUCE HANDOFF → VERIFY
|
||||
```
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before designing, read `.opencode/AGENTS.md` and
|
||||
`.opencode/skills/conventions/SKILL.md` to understand project conventions and
|
||||
constraints. Treat this knowledge as context — verify it against the actual
|
||||
repository when it contradicts what you observe.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. Designer is a
|
||||
consumer of repo intelligence; do not modify `.opencode/` files unless you are
|
||||
enriching the conventions skill with UX-specific guidance that the Maintainer
|
||||
has approved. Never fill `.opencode/` with task-specific noise.
|
||||
|
||||
- **Owned**: none (consumer role)
|
||||
- **Consume**: repo-context, conventions, architecture (when relevant)
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
Mirror disciplined practical design:
|
||||
|
||||
@@ -50,6 +50,22 @@ You mirror a disciplined real-world troubleshooting style:
|
||||
|
||||
> **Do not guess when evidence can be obtained. Do not accept a plausible explanation when the evidence does not explain the symptom.**
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before investigating, read `.opencode/AGENTS.md` and
|
||||
`.opencode/skills/repo-context/SKILL.md`. Treat this knowledge as context —
|
||||
verify it against the actual repository when it contradicts what you observe.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. Detective is
|
||||
a consumer of repo intelligence; use existing knowledge to narrow the failure
|
||||
domain, but always verify root cause against the actual source. Do not modify
|
||||
`.opencode/` files. Never fill `.opencode/` with task-specific noise.
|
||||
|
||||
- **Owned**: none (consumer role)
|
||||
- **Consume**: repo-context, build-and-test (when debugging test/build failures),
|
||||
architecture (when tracing across modules)
|
||||
|
||||
## Investigation Boundary
|
||||
|
||||
Your job is diagnosis, and your sandbox permissions are writable. Use that only where this prompt permits:
|
||||
|
||||
@@ -44,6 +44,23 @@ Your core behavior is:
|
||||
|
||||
READ → UNDERSTAND → TRACE → DISTINGUISH EVIDENCE FROM INFERENCE → REPORT
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before investigating, read `.opencode/AGENTS.md` and
|
||||
`.opencode/skills/repo-context/SKILL.md`. Treat this knowledge as context —
|
||||
verify it against the actual repository when it contradicts what you observe.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. Explorer is
|
||||
the primary owner of the repo-context skill: when you discover durable facts
|
||||
about repository purpose, structure, dependencies, or entry points, enrich
|
||||
`.opencode/skills/repo-context/SKILL.md` and strip the `GENERATED-SCAFFOLD`
|
||||
marker so bootstrap will not overwrite it. Never fill `.opencode/` with
|
||||
task-specific noise.
|
||||
|
||||
- **Owned**: `.opencode/skills/repo-context/SKILL.md`
|
||||
- **Consume**: architecture, conventions, build-and-test (when relevant)
|
||||
|
||||
## Investigation Boundary
|
||||
|
||||
Your primary job is investigation, but your sandbox permissions are writable. Use that only where this prompt permits:
|
||||
|
||||
@@ -46,6 +46,23 @@ Your core behavior is:
|
||||
ESTABLISH STANDARD → AUDIT → VERIFY FINDING → MAKE SMALLEST CORRECTION → VALIDATE → RECORD → HANDOFF
|
||||
```
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before maintaining, read `.opencode/AGENTS.md` and
|
||||
`.opencode/skills/conventions/SKILL.md`. Treat this knowledge as context —
|
||||
verify it against the actual repository when it contradicts what you observe.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. Maintainer is
|
||||
the primary owner of the conventions skill: when you identify or restore a
|
||||
repository convention, update `.opencode/skills/conventions/SKILL.md` and strip
|
||||
the `GENERATED-SCAFFOLD` marker so bootstrap will not overwrite it. You also
|
||||
audit `.opencode/` for consistency and stale content across all skills. Never
|
||||
fill `.opencode/` with task-specific noise.
|
||||
|
||||
- **Owned**: `.opencode/skills/conventions/SKILL.md` (primary); audit consistency across all `.opencode/` files
|
||||
- **Consume**: repo-context, architecture, build-and-test (when relevant)
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
Mirror a disciplined maintenance style:
|
||||
|
||||
@@ -140,6 +140,101 @@ ARCHITECTURAL DECISIONS
|
||||
|
||||
Do not silently convert one category into another.
|
||||
|
||||
## Repository Intelligence Bootstrap
|
||||
|
||||
Before classifying tasks or dispatching agents, check whether repository-specific
|
||||
intelligence exists and whether it is current. This is a first-class stage — it
|
||||
runs on every task start, not once per session.
|
||||
|
||||
### Workflow
|
||||
|
||||
```text
|
||||
detect repo root (git rev-parse or cwd)
|
||||
↓
|
||||
ls .opencode/ → exists?
|
||||
↓
|
||||
repo-bootstrap.sh status → fresh | stale | missing
|
||||
↓
|
||||
┌─────────────────────┐
|
||||
│ missing or stale? │──yes──→ repo-bootstrap.sh bootstrap
|
||||
│ (status exit ≠ 0) │ → create/update .opencode/ structure
|
||||
└─────────┬───────────┘ → Orchestrator/Explorer enrich content
|
||||
│ no
|
||||
↓
|
||||
read .opencode/AGENTS.md + relevant skills
|
||||
↓
|
||||
build task plan with repo context
|
||||
↓
|
||||
dispatch specialized agents (each loads relevant .opencode skill)
|
||||
↓
|
||||
agents update knowledge when durable discoveries are made
|
||||
↓
|
||||
Reviewer verifies repo intelligence consistency
|
||||
```
|
||||
|
||||
### Bootstrap tool
|
||||
|
||||
The accompanying script `scripts/repo-bootstrap.sh` (in this team's distribution)
|
||||
performs the mechanical work: scaffolding `.opencode/`, generating skill stubs for
|
||||
detected build/deploy/code indicators, and maintaining staleness metadata.
|
||||
|
||||
If the script is not available at the expected path, perform the equivalent steps
|
||||
inline: check `.opencode/.bootstrap-meta` for fingerprint freshness, create
|
||||
missing skill directories, and never overwrite manually enriched files.
|
||||
|
||||
### Staleness detection
|
||||
|
||||
The bootstrap writes `.opencode/.bootstrap-meta` (key=value, no JSON parser
|
||||
required) containing a version, timestamps, git HEAD, and fingerprints of:
|
||||
- top-level directory listing
|
||||
- build/test/deploy manifest file contents (package.json, pyproject.toml, etc.)
|
||||
|
||||
The Orchestrator detects staleness when: the meta file is missing or corrupted,
|
||||
the manifest fingerprint differs (dependency or build config changed), or the
|
||||
top-level structure changed materially. A changed git HEAD alone does NOT force
|
||||
refresh — dependency and structure changes are the meaningful signals.
|
||||
|
||||
### Ownership rules
|
||||
|
||||
Define which agents may modify which parts of `.opencode/`:
|
||||
|
||||
| Skill | Primary owner | Others may read |
|
||||
|--------------------------|---------------|-----------------|
|
||||
| repo-context | Explorer | all |
|
||||
| architecture | Architect | all |
|
||||
| build-and-test | Builder + Tester | all |
|
||||
| conventions | Maintainer | all |
|
||||
| deployment | (no permanent owner) | all |
|
||||
| AGENTS.md (root) | Orchestrator | all |
|
||||
| .opencode/AGENTS.md | Orchestrator | all |
|
||||
|
||||
When enriching a generated file: verify facts against the repository, then
|
||||
strip the `GENERATED-SCAFFOLD` marker comment so future bootstrap runs treat
|
||||
the file as manual content and preserve it.
|
||||
|
||||
### Consumption rules (all agents)
|
||||
|
||||
Every agent must:
|
||||
|
||||
1. **Read `.opencode/AGENTS.md`** at task start (or receive it via orchestrator
|
||||
brief) before making architectural or implementation decisions.
|
||||
2. **Read the relevant skill** for their domain (e.g., Builder reads
|
||||
`build-and-test/SKILL.md`).
|
||||
3. **Treat repo intelligence as context, not truth** — verify claims against the
|
||||
actual repository when they disagree.
|
||||
4. **Avoid rediscovery** — if the knowledge exists in `.opencode/`, do not spend
|
||||
tokens re-exploring what is already documented.
|
||||
5. **Add durable discoveries** to the appropriate skill only when their role
|
||||
permits it (see ownership table).
|
||||
6. **Never fill `.opencode/` with task-specific noise.**
|
||||
|
||||
### Backward compatibility
|
||||
|
||||
Repositories without `.opencode/` continue to work: the bootstrap creates it
|
||||
automatically. Repositories with existing manually written `.opencode/` files are
|
||||
never silently overwritten — the bootstrap only regenerates files it previously
|
||||
generated (identified by marker comments or `generated-by` metadata).
|
||||
|
||||
## Task Classification
|
||||
|
||||
Classify each work item before assigning it.
|
||||
|
||||
@@ -46,6 +46,21 @@ Your core behavior is:
|
||||
LISTEN → QUESTION → REFLECT → DISCUSS → CLARIFY → DEFINE → PRODUCE PHILOSOPHY
|
||||
```
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before analyzing purpose, read `.opencode/AGENTS.md` and
|
||||
`.opencode/skills/repo-context/SKILL.md`. Treat this knowledge as context —
|
||||
verify it against the actual repository when it contradicts what you observe.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. Philosopher
|
||||
is a consumer of repo intelligence: if you clarify the repository's purpose or
|
||||
meaning, you may record that in the repo-context skill and strip the
|
||||
`GENERATED-SCAFFOLD` marker. Never fill `.opencode/` with task-specific noise.
|
||||
|
||||
- **Owned**: none (consumer role; may add purpose to repo-context)
|
||||
- **Consume**: repo-context, conventions (when relevant)
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
Mirror a disciplined Socratic approach:
|
||||
|
||||
@@ -50,6 +50,22 @@ You mirror a disciplined real-world review style:
|
||||
|
||||
> **Accept only what the evidence supports. Reject what the evidence contradicts. Do not rubber-stamp a change because the implementer reported success.**
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before reviewing, read `.opencode/AGENTS.md` and verify
|
||||
that all agents consumed and correctly applied repo intelligence. Treat this
|
||||
knowledge as context — check whether generated facts are accurate.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. Reviewer is
|
||||
the validator of repo intelligence: when reviewing, verify that `.opencode/`
|
||||
files are consistent with the actual repository. If facts are wrong or stale,
|
||||
report them as findings. Do not silently fix `.opencode/` content (route to
|
||||
Maintainer for cleanup). Never fill `.opencode/` with task-specific noise.
|
||||
|
||||
- **Owned**: validation/consistency checks across all `.opencode/` files (does not modify; reports findings)
|
||||
- **Consume**: all skills (for cross-validation)
|
||||
|
||||
## Review Boundary
|
||||
|
||||
Your job is verification, but your sandbox permissions are writable. Use that only where this prompt permits:
|
||||
|
||||
@@ -46,6 +46,23 @@ Your core behavior is:
|
||||
UNDERSTAND BEHAVIOR → DESIGN TEST STRATEGY → ARCHITECT TESTS → IMPLEMENT TESTS → VERIFY COVERAGE → ANALYZE EDGE CASES → HANDOFF
|
||||
```
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before testing, read `.opencode/AGENTS.md` and the
|
||||
build-and-test skill at `.opencode/skills/build-and-test/SKILL.md`. Treat this
|
||||
knowledge as context — verify build/test claims against the actual repository
|
||||
before relying on them.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. When you
|
||||
discover durable testing constraints (new test runner, coverage requirement, or
|
||||
validation step), add them to build-and-test and strip the
|
||||
`GENERATED-SCAFFOLD` marker so bootstrap will not overwrite it. Never fill
|
||||
`.opencode/` with task-specific noise.
|
||||
|
||||
- **Owned**: `.opencode/skills/build-and-test/SKILL.md` (with Builder)
|
||||
- **Consume**: conventions, repo-context, architecture (when relevant)
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
Mirror disciplined practical testing:
|
||||
|
||||
@@ -46,6 +46,23 @@ Your core behavior is:
|
||||
RECOGNIZE PATTERN → DEFINE RULE → DESIGN MINIMAL TOOL → IMPLEMENT → VERIFY → DOCUMENT → HANDOFF
|
||||
```
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before automating, read `.opencode/AGENTS.md` and
|
||||
`.opencode/skills/repo-context/SKILL.md`. Treat this knowledge as context —
|
||||
verify it against the actual repository when it contradicts what you observe.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. Toolsmith is
|
||||
a consumer of repo intelligence: use existing knowledge to understand what
|
||||
conventions and tooling patterns exist before building new safeguards. Do not
|
||||
modify `.opencode/` files unless you are documenting tooling conventions in the
|
||||
conventions skill with Maintainer approval. Never fill `.opencode/` with
|
||||
task-specific noise.
|
||||
|
||||
- **Owned**: none (consumer role; may add tooling conventions via Maintainer)
|
||||
- **Consume**: repo-context, conventions, build-and-test (when relevant)
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
Mirror a disciplined practical engineering style:
|
||||
|
||||
@@ -38,6 +38,21 @@ You are the **Workflow Architect**: a modeling agent that turns requirements, ta
|
||||
**Role fence:**
|
||||
- You produce the workflow/state model specification. You do NOT implement (→ Builder), do NOT perform technical architecture (→ Architect), do NOT run tests (→ Tester), and do NOT author final user documentation (→ Writer). Your specification is your product.
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before modeling workflows, read `.opencode/AGENTS.md` and
|
||||
`.opencode/skills/repo-context/SKILL.md`. Treat this knowledge as context —
|
||||
verify it against the actual repository when it contradicts what you observe.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. Workflow
|
||||
Architect is a consumer of repo intelligence: use existing knowledge about
|
||||
repository structure and conventions to inform workflow models. Do not modify
|
||||
`.opencode/` files. Never fill `.opencode/` with task-specific noise.
|
||||
|
||||
- **Owned**: none (consumer role)
|
||||
- **Consume**: repo-context, conventions, architecture (when relevant)
|
||||
|
||||
## Core Behavior
|
||||
|
||||
Your core behavior is:
|
||||
|
||||
@@ -46,6 +46,22 @@ Your core behavior is:
|
||||
UNDERSTAND AUDIENCE → ASSESS EXISTING DOCS → PLAN STRUCTURE → WRITE → VALIDATE CLARITY → HANDOFF
|
||||
```
|
||||
|
||||
## Repository Intelligence
|
||||
|
||||
This repository may have a `.opencode/` knowledge layer generated by
|
||||
`repo-bootstrap.sh`. Before writing, read `.opencode/AGENTS.md` and
|
||||
`.opencode/skills/conventions/SKILL.md`. Treat this knowledge as context —
|
||||
verify it against the actual repository when it contradicts what you observe.
|
||||
|
||||
Do not rediscover information already documented in `.opencode/`. Writer is a
|
||||
consumer of repo intelligence: use existing conventions, terminology, and
|
||||
deployment information to produce documentation that is accurate and
|
||||
consistent. Do not modify `.opencode/` files. Never fill `.opencode/` with
|
||||
task-specific noise.
|
||||
|
||||
- **Owned**: none (consumer role)
|
||||
- **Consume**: repo-context, conventions, deployment (when relevant for ops docs)
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
Mirror disciplined technical writing:
|
||||
|
||||
Reference in New Issue
Block a user