FAQ

FAQ

What is Lineage?

Lineage is a local runtime for distributing agent environment packages. It lets someone package the files around an agent workflow, share that package, and let another person inspect and activate it on their own machine.

What goes into a package?

Skills, workflows, agents, policies, references, setup material, and provider adapters can go into a package when they are safe to share.

What should not go into a package?

Do not package API keys, auth tokens, .env values, provider credentials, private machine-local cache, shell history, or private workflow data.

Is Lineage replacing Claude, Codex, or other agent tools?

No. Lineage sits around local agent commands. The receiver still uses their own agent provider and local credentials.

How do I install Lineage?

Run:

curl -fsSL https://agenticlineage.vercel.app/install.sh | sh

Developers with Go installed can also run:

go install github.com/agentic-lineage/lineage/cmd/lineage@latest

What is the fastest way to use a published package?

Use lineage add inside the project where you want the package enabled:

lineage add <package-name>

For an exact version:

lineage add <package-name>@<version>

Published packages are listed at agenticlineage.vercel.app/packages.

What is the difference between add, pull, import, and enable?

• lineage add <ref> is the one-command receiver path for registry packages: fetch, verify, inspect, confirm, and enable.
• lineage package pull <ref> fetches a registry package into your local package store but does not enable it by itself.
• lineage package import <file.tgz> imports a local archive someone sent you.
• lineage enable <path-or-id> records an already-local package in the current project.

Why inspect before enabling?

Packages can affect a local agent environment. The receiver should understand what files, skills, setup steps, and provider assumptions a package contains before enabling it.

What does lineage inspect show?

lineage inspect <path-or-id> shows a package's manifest, discovered contents, digest, and declared capabilities without enabling it.

What does lineage doctor check?

lineage doctor checks project config, whether enabled packages still resolve, whether the shim directory is on PATH, and whether provider binaries such as claude or codex resolve the way Lineage expects.

How does publishing work?

Run lineage login once to authenticate with GitHub, then:

lineage package publish ./my-package

The first publish of a package name claims it for that GitHub login. Future versions need the same publisher identity and a bumped version in lineage.yaml.

Are capabilities enforced?

No. Declared filesystem and network capabilities are safety metadata in this build. Lineage shows them during validation, inspection, dry runs, and package page flows so receivers can make an informed choice, but they are not a sandbox.

What happens before Lineage writes files?

The first real provider run shows what Lineage will create or change and asks for confirmation. --dry-run never writes. --yes skips the prompt for scripts or trusted automation.

How do workflows run?

If a package declares an ordered workflow, use:

lineage workflow run <workflow-name> <claude|codex>

The workflow path materializes only the workflow's declared steps, while lineage run <provider> applies the full enabled package set.

How are feature requests handled?

Use GitHub Discussions for early ideas. Once an idea is concrete enough to build, it should become a GitHub issue with acceptance criteria and a goal-based milestone.

How should contributors work?

Assign an issue before starting work. Open PRs against develop. Link the issue and include relevant tests or a clear no-test justification.