Engagement bootstrap

Engagement Bootstrap

Forward-deployed work runs COMPASS and SAGE under a harder constraint: the codebase is new every time, the spec is often half-formed, and whatever you learn has to either stay put or be sanitized before it travels to the next client. This protocol doesn't replace COMPASS or SAGE — it's the discipline that keeps them safe to run across many different clients' repos instead of just one.

When to trigger

1. You're opening a codebase or environment you haven't worked in before, on a timebox (a discovery call, a sprint, a POC).
2. A stakeholder's request is unclear, or has changed since you started building against it.
3. You're about to build something explicitly meant as a demo/POC rather than production code.
4. An engagement is closing out and there are engagement-local skills, ledger improvised/synthesized entries, or patterns worth evaluating for reuse.

1. Bootstrap (onboarding under partial observability)

Before writing code in a new engagement, spend a fixed, small amount of time — not open-ended exploration — capturing what you'd otherwise re-derive every session:

• Stack, entry points, how to run it, how to test it.
• Constraints the client has stated (compliance, deploy target, existing conventions you must not break).
• The timebox for this engagement and what "done" looks like at the end of it.
• Explicit unknowns — what you don't know yet, not just what you do.

Write this to .claude/compass-sage/engagements/<client-slug>/brief.md (template: ledger/ENGAGEMENT-TEMPLATE.md). This is the partial-observability fix for engagement work: the next session, or the teammate who picks this up, reads the brief instead of re-discovering the codebase from zero.

2. Scope the ask

A vague or shifting request is not a reason to guess. Write the scope back in one paragraph — what you understood, what you assumed, what you're building first — and flag every assumption explicitly instead of silently picking one. Build the smallest slice that tests the riskiest assumption before committing to the full ask. If the ask shifts mid-build, that's a partial ledger entry citing what changed and when (see sage-skill-evolution), not a silent scope change.

3. Keep engagement work local by default

Ledger entries and any skills COMPASS synthesizes during an engagement stay in .claude/compass-sage/engagements/<client-slug>/ledger.md, and in that engagement's own skills directory if the skill is client-specific — not the project's shared .claude/skills/. Client business logic, internal system names, and credentials belong to that client. Nothing crosses into the portable library by default.

4. Promote, but sanitize first

At engagement close — or whenever a synthesized skill shows real reuse potential beyond this client — run a sanitization pass before promoting it to the shared/portable skill library:

• Strip the client's name, internal system/service names, proprietary business rules, URLs, and credentials.
• Generalize the trigger conditions in the description frontmatter so it matches the shape of the problem, not this client's instance of it.
• Re-read it as if you'd never seen this client's codebase — if it still only makes sense with that context, it isn't ready to promote.

This is COMPASS's step 7 (self-reflection) with a confidentiality lens instead of a correctness one: a skill that ships to the portable library without this pass is a leak, not a first draft.

5. Flag demo vs. production

Tag ledger notes demo-only or hardened for anything built under engagement time pressure. A POC quietly handed off as production code is a failure mode SAGE's ledger won't catch on its own — it reads as a success unless the note says otherwise. If a demo is going to outlive the engagement, say so and route the hardening work explicitly instead of letting it ship by omission.