# ADR-0006: Kit adapts to user function-mode and integrates with the organizational process; recursively populates skills from org-local repository

- **Date:** 2026-05-01
- **Status:** superseded by ADR-0009 (mode-set revision: `creating` replaces `researching`); function-adaptation framework otherwise intact
- **Reversibility:** medium (the function-adaptation framing can be relaxed; the org-local-skill-repository discovery can be removed; both would require updating Q1 + Q6 + the discovery skill)
- **Deciders:** practitioner@example.com (operator)
- **Scope:** kit (V1.1 adaptation behavior)

## Context

V1 framing assumed the user was building something. Templates, skills, and the worked example weighted toward the build context (eval baselines, reproducibility gates, platform-kit posture). This produced a kit that landed naturally for builders and felt foreign to other functions.

Operator feedback after V1 ship (2026-05-01):

> "Not every individual is building something. So we do want it to adapt to the users function to support, and help understand their work process so as it deploys, it integrates and assimilates the users work process into the greater work process, organizationally aware."

The corrected framing: the kit serves any function with structure worth governing, not just builders. Specifically: builders, operators, decision-makers, researchers. The templates remain the same; their relative weight in the deployment changes based on the user's function-mode. The deployed instance integrates with existing organizational rhythms (standup, weekly review, quarterly planning) and existing tooling (Slack, Linear, Confluence) rather than introducing new patterns it then has to be reconciled with.

Additionally:

> "On landing, when determining the functions that could ultimately be served, the kit should recursively populate skills, ideally from the company or organizations local repository if they have one."

The deployed instance should detect the org's local skill repository (if it exists) and recursively populate skills from there, taking precedence over kit-bundled defaults when an org-local equivalent exists. This makes the kit organizationally aware at the skill layer, not just at the rhythm layer.

## Decision

V1.1 adds two behaviors:

### 1. Function-mode adaptation

Q1 of the orientation base set is extended from "function identity (name + purpose + type)" to "function identity (name + purpose + type + function-mode)." Function-mode is one of:

- `building` - actively constructing new capability; eval baselines and reproducibility gates load-bearing
- `operating` - running an existing process; not building; L0 + L7 + inbox-outbox load-bearing
- `deciding` - decision-rich function; ADR practice load-bearing; lighter on platform-kit work
- `researching` - inquiry-driven; session-log discipline load-bearing
- `mixed` - name dominant + secondary

The discovery skill reads the function-mode answer and shapes the conversation accordingly. The deploy skill renders templates with the appropriate weight (a `building` deployment scaffolds full L4; a `deciding` deployment treats L4 as inherited or N/A).

### 2. Organizationally-aware skill population

Q6 (platform kit posture) is extended to include an org-local-skill-repository question. If the answer indicates the org has a skill repository (e.g., Cowork team-skills storage, internal skill library, GitHub-based skill bundle), the deploy skill performs recursive population:

1. Detects the org-local skill repository
2. Reads its skill manifest
3. For each skill in the org-local repo: if a kit-bundled equivalent exists, the org-local takes precedence (with `MIRRORED FROM: {org_local_path}` header); if no kit-bundled equivalent, the org-local skill is added to the deployed instance's skill set
4. The deployed instance's skill set is the union of kit-bundled defaults plus org-local additions

This makes the deployed instance organizationally aware at the skill layer.

### 3. Existing-process integration

Q10 is extended to include "existing organizational rhythms" and "existing decision rituals." The deploy skill aligns the deployed instance's Doc Lifecycle cadences to the named rhythms (e.g., quarterly review aligns to org's quarterly planning cycle) and writes inbox-outbox pairs that route through existing tooling (Slack channels, Linear projects) rather than introducing new patterns.

## Options considered

### Option A: Function-mode adaptation + org-local-skill-population + rhythm-alignment [CHOSEN]

- **Summary:** Three behaviors added; templates stay the same but their weight shifts; org-local skills take precedence; cadences align to existing rhythms.
- **Pros:** Kit lands naturally for any function-mode; organizationally aware at skill and rhythm layers; existing organizational process is respected and extended rather than replaced.
- **Cons:** Q1 and Q6 grow (more acceptance criteria); discovery skill must judge function-mode weighting effectively; org-local-skill-repository detection mechanism is a new responsibility.

### Option B: Builder-only kit (status quo)

- **Summary:** V1 stays builder-weighted; non-builder functions are out of scope.
- **Pros:** Smaller kit scope; clearer mental model of who it serves.
- **Cons:** Excludes most functions in most organizations; the operator has explicitly named non-builders as in scope; the kit becomes a niche tool rather than a general operating-model deployment.

### Option C: Function-mode only (no org-local-skill-population, no rhythm-alignment)

- **Summary:** Add function-mode to Q1; templates weight accordingly; do not integrate with org tooling or rhythms.
- **Pros:** Simpler V1.1 delta; lower implementation cost.
- **Cons:** Function-mode adaptation without organizational awareness produces a kit that recognizes diverse functions but still introduces foreign rhythms and skills; the org-side actors will reject it as not-respecting-existing-process.

## Rationale

Option B is rejected on operator-stated scope grounds. Option C captures one of the three behaviors but not the others; the operator's framing was explicit that organizational awareness applies at function-mode + skill-population + rhythm layers together, not separately. Option A is the only one that operationalizes the full operator framing.

The tradeoff explicitly accepted: more behavior in the discovery + deploy skills; the skills must be capable of detecting function-mode, detecting org-local skill repositories, and aligning rhythms. Mitigation: the discovery skill (new, V1.1) is being built specifically to handle these capabilities; the deploy skill becomes a multi-phase orchestrator that delegates to discovery for these judgments rather than encoding them inline.

## Consequences

### Positive

- The kit serves any function-mode (not just builders) with appropriate weight per mode
- Organizationally aware at skill and rhythm layers; existing process is extended, not replaced
- Org-local-skill-population produces deployments that have access to the organization's own institutional skills, not just kit-bundled defaults
- Adoption rate increases because the deployed instance respects existing patterns rather than introducing foreign ones

### Negative

- Q1 and Q6 grow; discovery skill complexity grows with them
- Org-local-skill-repository detection has edge cases (multiple repos, ambiguous precedence rules, conflicting names with kit-bundled skills); discovery skill must handle these
- Rhythm-alignment requires the deployed instance to know about org rhythms it did not previously care about; introduces some coupling between the kit and the host organization
- Function-mode weighting could produce surprises (a `deciding` deployment may be confused that the kit treats L4 as inherited; the deployed instance's CLAUDE.md needs to explain the weighting rationale)

### Followups

- Q1 acceptance criteria updated to include function-mode (`QUESTIONS.md` rewrite, V1.1)
- Q6 acceptance criteria updated to include org-local-skill-repository (`QUESTIONS.md` rewrite, V1.1)
- Q10 acceptance criteria updated to include existing organizational rhythms (`QUESTIONS.md` rewrite, V1.1)
- New skill: `architect-discovery` drives function-mode + org-local-repo + rhythm questions and adapts conversation accordingly
- `skills/deploy/SKILL.md` updated: render templates with function-mode weighting; perform recursive skill population from org-local repo; align Doc Lifecycle cadences to named rhythms
- `skills/architect-kit-mirror/SKILL.md` updated: handle the org-local-skill-repo as a new mirror posture (a sixth branch beyond the L4 template's five branches; or a mode within `mature-internal-mirror`)
- PHILOSOPHY.md additions: "Why the kit adapts to the user's function, not just builders"; "Why the kit assimilates the user's work process into the organizational process"
- TERMS.md additions: function-mode, organizationally-aware, org-local-skill-repository, rhythm-alignment

## Cross-references

- ADR-0004 (recursive question discipline) - the question-asking discipline that surfaces function-mode, org-local-repo, and rhythm answers
- ADR-0005 (continuous-rescaffolding) - rescaffolds revisit function-mode (if user shifts modes), org-local-repo (if new skills are added there), and rhythms (if org rhythms change)
- BOOTSTRAP-BRIEF Section I (cardinal insight 3 - learning is the process; function-adaptation is part of how learning happens)
- PHILOSOPHY.md "Why the kit adapts to the user's function"
- PHILOSOPHY.md "Why the kit assimilates the user's work process"
- QUESTIONS.md Q1, Q6, Q10
- `skills/architect-discovery/SKILL.md`
- `skills/architect-kit-mirror/SKILL.md` (updated for org-local-repo handling)
