Project Hints

workspace(action: activate) now returns a project_hints field with manifest-derived context so agents have useful information even when onboarding has never been run.

Why

Previously, an agent hitting a codescout project in a client that never calls onboarding saw only the languages list. No build commands, no entry points, no manifest info. The agent had to probe the filesystem itself — or guess.

project_hints fills that gap with a cheap manifest probe that runs on every workspace(action: activate) call.

What you get

{
  "status": "ok",
  "project": "codescout",
  "project_root": "/home/you/work/codescout",
  "languages": ["rust"],
  "project_hints": {
    "primary_language": "rust",
    "manifest": "Cargo.toml",
    "entry_points": ["src/main.rs", "src/lib.rs"],
    "build_commands": ["cargo build", "cargo test", "cargo run"],
    "onboarded": false
  },
  "memories": [],
  "hint": "CWD: /home/you/work/codescout. Run workspace(action: status) for health checks and memory staleness."
}

Fields

Field	Meaning
`primary_language`	Language inferred from the detected manifest. `null` when no manifest recognised.
`manifest`	Filename that drove detection (`Cargo.toml`, `package.json`, etc.).
`entry_points`	Canonical entry-point files that exist on disk. Capped at 3.
`build_commands`	Build / test / run commands for the detected manifest.
`onboarded`	`true` when an `onboarding` memory exists (indicates a full onboarding has been performed at some point).

Supported manifests

Manifest	Language	Notes
`package.json`	`typescript` if `tsconfig.json` also exists, else `javascript`	Checked first — Node projects sometimes ship a `pyproject.toml` for tooling.
`Cargo.toml`	`rust`
`pyproject.toml` / `setup.py`	`python`
`go.mod`	`go`
`pom.xml`	`java`
`build.gradle.kts` / `build.gradle`	`kotlin`

Relationship to `onboarding`

project_hints is not a replacement for the onboarding tool. It’s a cheap fallback for when onboarding has never been called:

Signal	Source
Primary language, entry points, build commands	`project_hints` — always populated when a manifest exists
README summary, architecture notes, memory writes	`onboarding` — only after full scan
System prompt draft	`onboarding` — only after full scan

When onboarded: true, the real memories (project-overview, architecture, language-patterns) are the authoritative source. project_hints stays populated for consistency but agents should prefer memory content when available.

Behaviour

No probe runs if the project root has no recognised manifest — fields are null / empty arrays.
All probes are read-only file-existence checks. No file parsing beyond checking tsconfig.json presence for TS vs JS disambiguation.
First manifest match wins. package.json takes priority; otherwise the order is: Cargo.toml → pyproject.toml → setup.py → go.mod → pom.xml → build.gradle.kts → build.gradle.

Keyboard shortcuts

codescout Manual