Steering with PACK.md

Every pack has a PACK.md: a short file of ground rules, such as which source to trust, how the team works, and what to decline. Every question and every task reads it first, whole, before the first decision. The pack’s owners write it, under Pack essentials on the pack page or with edisyl pack context.

Teach it, or fix it in PACK.md?

The answer is…	Do this
Missing. The pack doesn’t know the fact.	teach the document or the fact. Ask your agent, or drop the file on the pack page. Teaching updates knowledge, not PACK.md.
There, but slow or from the wrong source.	Add a line under # Routing in PACK.md, for example: - Competitor questions: the competitors.gold_data table.

The test: if the sentence could sit in a document, teach it. If it’s an instruction to the pack about how to behave, it belongs here. A word your team uses belongs in the pack’s Lexicon, not in PACK.md.

Match the rules to the scope

• A narrow pack (one machine, one product line, one team’s workflow): be specific and pointed. Write every section. Name the exact source for each kind of question, and the specific requests the pack declines.
• A broad pack (a whole function, such as supply chain or HR policy): keep the rules light. A purpose, plus routing where sources overlap. Let teaching and calibration fill in the rest.

Five sections, in this order

1. # Purpose: what the pack is for, who it serves, and who owns it. Two to four sentences. If the pack should treat a fixed day as today, add As of: YYYY-MM-DD.
2. # Routing: one line per kind of question. Each line gives the document or data source to trust. Also list what the pack does not cover.
3. # How we work: cadences, who decides, and each recurring routine with the document that holds its steps. Don’t paste the steps.
4. # Answer style: only your own conventions, such as voice, length, currency, rounding, or a required report format. Set the fiscal year with the pack’s calendar, not in PACK.md. Answers already carry their period and sources. A style can’t override the product’s own rules: “never say you don’t know” is ignored, and every figure stays exactly as the evidence states it.
5. # Decline when: the specific requests the pack turns down, and what it offers instead. A broad line like “decline pricing questions” also refuses ones the pack can answer. This steers which questions the pack answers. It isn’t access control: keep data people must not read out of the pack.

Tip

After a first calibration, check which questions the pack declined but should have answered. A # Decline when line that’s too broad is the usual cause.

Example: a supplier-risk pack

Synthetic, but the shape holds for any narrow pack:

# Purpose
Answers supplier-risk questions for the EU procurement team: delivery
performance, supplier scorecards and contract terms.
Owner: procurement analytics.

# Routing
- Delivery and spend figures: the PROCUREMENT data source.
- Contract terms: the contract library.
- OTIF and scorecard method: see scorecard-policy.md.

# How we work
Weekly supplier review every Monday: follow review-checklist.md.
Category managers decide. The pack prepares evidence.
Finance closes on the 5th business day.

# Answer style
Amounts in EUR to the nearest thousand. FY starts 1 April.

# Decline when
Asked to change a purchase order, or to rank individual people.
Offer the evidence instead.

Best practices

• Name the document, don’t paste it. The file is capped at 10,000 characters, and every question pays for its length. Point to the file by name: - Scoring method: see scorecard-policy.md.
• Write routing after a first calibration. Load objectives, let calibration test them, then add routing where answers miss.
• You keep PACK.md current. Teaching keeps the knowledge current, but never writes this file. Forgetting a document trims any lines that point at it.
• Read it before you write it. A write replaces the whole file. If you write from an old copy, you lose everything added after that copy.

Commands

edisyl pack context get <pack>                  # anyone who can read the pack
edisyl pack context edit <pack>                 # opens your editor
edisyl pack context set <pack> --file PACK.md   # upload a local file
edisyl pack context history <pack>              # who changed what
edisyl pack context revert <pack> <revision-id>

Everything except get needs manage_pack on the pack. If edit says “not found” on a pack you can see, you aren’t its owner.

edit saves only if nobody wrote the file while you had it open. If someone did, the save is refused and your draft stays on disk. Read the file again, add your change, and write again. revert saves the chosen version as a new revision. History is never erased. See edisyl pack context for every flag.