agentleFS
Dan-ClearyDan-Cleary/fdestack/skills/customer-context/SKILL.md

customer-context

Skill40 starsChanged 6 months agoMITView on GitHub

Load a customer's context at the start of every session. Run this before any other FDEstack skill. Reads all 7 context files, surfaces drift since last session, asks what's new, and commits updates.

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. About 0 are common, 11 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If NO_CUSTOMERS_DIR appears AND there are git remotes that don't look like a personal ops repo (e.g., remote URL contains a company/project …

    line 38
  2. Distinctive:

    Wait for confirmation before continuing if this warning fires.

    line 47
  3. Very specific:

    If DECLINED_LAST_SESSION=true: print at the top of the Session Brief:

    line 69
  4. Distinctive:

    If learnings are found, incorporate relevant ones into your analysis during this session.

    line 86
  5. Very specific:

    If DRIFT_CHECK=first_session: note "First session — no drift to show." If diff output is non-empty: summarize as "DRIFT SINCE LAST SESSION" …

    line 129
  6. Distinctive:

    If diff output is non-empty: summarize as "DRIFT SINCE LAST SESSION" in the Brief.

    line 130
  7. Distinctive:

    If diff is empty: note "No changes since last session."

    line 131
  8. Distinctive:

    Ask: "Anything to update before we start?"

    line 168
  9. Distinctive:

    If the answer is ambiguous (could go to 2+ files), ask which file before writing.

    line 179
  10. Distinctive:

    If nothing to update, skip to Step 8.

    line 180
  11. Very specific:

    Update the ## Last Updated line in each file you modify with today's date.

    line 182
  12. Distinctive:

    If nothing changed: write the session marker (Step 9) and stop.

    line 192
  13. Distinctive:

    If changes exist, print:

    line 194
  14. Distinctive:

    no: write declined flag to session marker (Step 9), print "OK — changes not committed.

    line 200
  15. Distinctive:

    let me edit first: wait for the user to make edits, then re-show the diff and ask again

    line 201
  16. Very specific:

    Write ts=<unix_timestamp> to the marker.

    line 219

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/customer-context

Load and update a customer's context. Run this at the start of every customer session.

Step 0: Parse customer name

The customer name is the first argument after the skill invocation. If no name is provided, ask: "Which customer? (e.g. /customer-context acme)"

Set CUSTOMER_NAME from the argument. All file paths below use this name. The ops repo root is the current working directory — all paths are relative to it.

Step 1: Ops repo safety check

Run:

git remote -v 2>/dev/null | head -4
[ -d customers/ ] && ls customers/ | head -3 || echo "NO_CUSTOMERS_DIR"

If NO_CUSTOMERS_DIR appears AND there are git remotes that don't look like a personal ops repo (e.g., remote URL contains a company/project name that matches obvious customer patterns), print:

Warning: I don't see a customers/ directory here. Are you sure you're in your FDE ops repo (e.g. ~/fde-ops/) and not inside a customer's codebase? Committing customer context here could expose internal notes to the customer's team. Type "yes" to proceed anyway, or cd to your ops repo first.

Wait for confirmation before continuing if this warning fires.

Step 2: Check session marker freshness

MARKER="/tmp/fdestack-session-$CUSTOMER_NAME"
if [ -f "$MARKER" ]; then
  MARKER_TS=$(cat "$MARKER" | grep '^ts=' | cut -d= -f2)
  NOW=$(date +%s)
  AGE=$(( NOW - MARKER_TS ))
  if [ "$AGE" -lt 43200 ]; then
    echo "MARKER_FRESH=true AGE_HOURS=$(( AGE / 3600 ))"
  else
    echo "MARKER_FRESH=false AGE_HOURS=$(( AGE / 3600 ))"
  fi
  DECLINED=$(cat "$MARKER" | grep '^declined=true' || echo "")
  [ -n "$DECLINED" ] && echo "DECLINED_LAST_SESSION=true"
else
  echo "MARKER_FRESH=false MARKER_MISSING=true"
fi

If DECLINED_LAST_SESSION=true: print at the top of the Session Brief:

Note: last session's changes were not committed — drift detection may show accumulated changes from multiple sessions.

Step 3: Load cross-customer learnings

LEARNINGS_FILE="$HOME/.fdestack/learnings.jsonl"
if [ -f "$LEARNINGS_FILE" ] && [ -s "$LEARNINGS_FILE" ]; then
  echo "LEARNINGS: $(wc -l < "$LEARNINGS_FILE" | tr -d ' ') entries"
  # Surface top 3 most recent entries
  tail -3 "$LEARNINGS_FILE" | jq -r '"[learning] " + .key + ": " + .insight' 2>/dev/null || true
else
  echo "LEARNINGS: 0"
fi

If learnings are found, incorporate relevant ones into your analysis during this session. Display them under "PRIOR LEARNINGS" in the Session Brief if any seem applicable.

Step 4: Load customer context files

CUSTOMER_DIR="customers/$CUSTOMER_NAME"
mkdir -p "$CUSTOMER_DIR"
for f in profile stack stakeholders blockers unknowns decisions timeline; do
  if [ ! -f "$CUSTOMER_DIR/$f.md" ]; then
    FDESTACK_DIR=$(dirname "$(dirname "$(readlink -f "${BASH_SOURCE[0]}" 2>/dev/null || echo "$HOME/.claude/skills/customer-context/SKILL.md")")")
    cp "$FDESTACK_DIR/templates/$f.md" "$CUSTOMER_DIR/$f.md" 2>/dev/null || \
    cp "$HOME/.claude/skills/fdestack/templates/$f.md" "$CUSTOMER_DIR/$f.md" 2>/dev/null || \
    echo "## Last Updated" > "$CUSTOMER_DIR/$f.md"
    echo "  created: $f.md from template"
  fi
done
ls "$CUSTOMER_DIR/"

Read all 7 files:

  • customers/<name>/profile.md
  • customers/<name>/stack.md
  • customers/<name>/stakeholders.md
  • customers/<name>/blockers.md
  • customers/<name>/unknowns.md
  • customers/<name>/decisions.md
  • customers/<name>/timeline.md

Step 5: Drift detection

CUSTOMER_DIR="customers/$CUSTOMER_NAME"
# Check if files have git history
HAS_HISTORY=$(git log --oneline -1 -- "$CUSTOMER_DIR/" 2>/dev/null)
if [ -n "$HAS_HISTORY" ]; then
  git diff HEAD -- "$CUSTOMER_DIR/" 2>/dev/null
  echo "DRIFT_CHECK=done"
else
  echo "DRIFT_CHECK=first_session"
fi

If DRIFT_CHECK=first_session: note "First session — no drift to show." If diff output is non-empty: summarize as "DRIFT SINCE LAST SESSION" in the Brief. If diff is empty: note "No changes since last session."

Step 6: Print Session Brief

Print this to the terminal:

════════════════════════════════════════════════════════════
CUSTOMER: <name> | SESSION: <YYYY-MM-DD> | FDE: <git user.name>
════════════════════════════════════════════════════════════

CURRENT STATE:
  [3-5 bullets synthesized from profile.md + recent decisions.md]

OPEN UNKNOWNS:
  [unknowns.md items, HIGH first, then MED, then LOW]
  [if none: "No open unknowns — nice."]

CURRENT BLOCKERS:
  [blockers.md items, HIGH first]
  [if none: "No active blockers."]

DRIFT SINCE LAST SESSION:
  [summary of git diff, or "No changes" or "First session"]
  [if DECLINED_LAST_SESSION: "Note: last session not committed — diff may span multiple sessions"]

[PRIOR LEARNINGS: <applicable entries from learnings.jsonl, if any>]

RECOMMENDED FIRST ACTION:
  [one sentence based on highest-priority blocker or unknown]
  [first session with empty context: "Tell me what you already know about this customer
   (company, engagement stage, who's involved) — I'll route it to the right context file."]
════════════════════════════════════════════════════════════

Step 7: Ask what's new

Ask: "Anything to update before we start?"

Route answers to the right file by content type:

  • New person / contact / org chart change → stakeholders.md
  • New tool / system / infra / API / data format → stack.md
  • New deadline / date / milestone → timeline.md
  • New blocker / stuck / can't proceed → blockers.md
  • New unknown / unclear / need to find out → unknowns.md
  • Decision made / resolved / agreed → decisions.md
  • General company / product info → profile.md

If the answer is ambiguous (could go to 2+ files), ask which file before writing. If nothing to update, skip to Step 8.

Update the ## Last Updated line in each file you modify with today's date.

Step 8: Confirm before committing

Show what changed:

git diff -- "customers/$CUSTOMER_NAME/" 2>/dev/null
git status --short -- "customers/$CUSTOMER_NAME/" 2>/dev/null

If nothing changed: write the session marker (Step 9) and stop. Print "Nothing changed — context is current."

If changes exist, print:

Here's what I'm about to commit to your ops repo: [show the diff summary — which files changed and what] Commit these changes? (yes / no / let me edit first)

  • yes: proceed to commit in Step 8a
  • no: write declined flag to session marker (Step 9), print "OK — changes not committed. Next session will note that drift detection may be incomplete.", stop
  • let me edit first: wait for the user to make edits, then re-show the diff and ask again

Step 8a: Commit

git add "customers/$CUSTOMER_NAME/"
git commit -m "context: $CUSTOMER_NAME session $(date +%Y-%m-%d)"

Step 9: Write session marker

MARKER="/tmp/fdestack-session-$CUSTOMER_NAME"
printf "ts=%s\n" "$(date +%s)" > "$MARKER"
# If commit was declined, add the flag:
# printf "declined=true\n" >> "$MARKER"

Write ts=<unix_timestamp> to the marker. If the commit was declined in Step 8, also write declined=true on a second line.

Print: "Session marker written. Other FDEstack skills are ready to use for $CUSTOMER_NAME."

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.