[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X4Z4TCG9MN2HMB3Z96P1DM":3,"skill-same:01M6X4Z4TCG9MN2HMB3Z96P1DM":150},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":89,"commitSha":90,"skillDirectory":91,"forksCount":14,"repositoryHtmlUrl":92,"repositoryHomepageUrl":93,"ownerHtmlUrl":94,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":95,"install":96,"resources":109},"01M6X4Z4TCG9MN2HMB3Z96P1DM","owner-profiling",null,"Build and maintain a structured personal-context portfolio for the project owner — identity, working style, goals, team, decision patterns. Includes both an interview protocol for bootstrapping and observable-signal patterns for incremental refinement. Use to bootstrap an owner profile (interview), to refine an existing profile (target one file), or to incrementally update the profile based on observed patterns from a normal session (the agent watches for signals and proposes additions when evidence accrues).","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"owner profiling","profiling","observe","when","normal","audit trail","personal-context","project","signals","refine","maintain","run","log","portfolio","work","decision","team","ids","audit","update","2026-11-10 10:12:30",false,"---\nname: owner-profiling\ndescription: |\n  Build and maintain a structured personal-context portfolio for the project owner — identity, working style, goals, team, decision patterns. Includes both an interview protocol for bootstrapping and observable-signal patterns for incremental refinement. Use to bootstrap an owner profile (interview), to refine an existing profile (target one file), or to incrementally update the profile based on observed patterns from a normal session (the agent watches for signals and proposes additions when evidence accrues).\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-owner-profiling\n    version: \"1.0.0\"\n    created: 2026-04-07T00:00:00Z\n    category: process\n    layer: 4\n    uses:\n      - skill: event-log\n        purpose: Log events to keep the audit trail accurate after every write.\n      - skill: actor-profile\n        purpose: Resolve and validate Actor IDs referenced by this skill's entities.\n    provides:\n      primitives: []\n      templates: [identity, working-style, goals-and-context, team-and-relationships]\n    commands:\n      - name: owner-profiling-bootstrap\n        args: \"owner-name\"\n        description: \"Run the initial profiling interview for a new project owner\"\n      - name: owner-profiling-refine\n        args: \"owner-name\"\n        description: \"Refine an existing owner profile from new observations\"\n      - name: owner-profiling-observe\n        args: \"owner-name observation\"\n        description: \"Record a behavioural observation about a project owner\"\n---\n\n# Owner Profiling\n\n## Intro\n\n`owner-profiling` builds and maintains a four-file personal context portfolio\nfor the project owner: who they are, how they want to be communicated with,\nwhat they're optimizing for, and who they work with. The profile is the\nsingle most-loaded set of files per session — it's how the agent learns to\nsound like the owner and act in their interest. This skill operates in three\nmodes: **bootstrap** (interview when no profile exists), **refine** (walk\nthrough one file to update it), and **observe** (incrementally enrich the\nprofile from signals seen during normal work).\n\n## Overview\n\n### The four files\n\n```\ncontext\u002Fowner\u002F                  ← public + project-private files (git-tracked)\n  identity.md                   privacy: public\n  working-style.md              privacy: project-private (default)\n  goals-and-context.md          privacy: project-private (default)\n\ncontext\u002Fowner\u002Fprivate\u002F          ← user-private files (gitignored)\n  team-and-relationships.md     privacy: user-private\n```\n\n| File | What it contains | Privacy |\n|---|---|---|\n| `identity.md` | Name, role, organization, what you do, what you're known for. The \"if the agent can only read one file, this is it\" file. | public |\n| `working-style.md` | Communication style + preferences-and-constraints + role-and-responsibilities merged. The hard rules, the always-do\u002Fnever-do list, the tone preferences, the actual weekly cadence. The single highest-leverage file per session. | project-private |\n| `goals-and-context.md` | Goals & priorities + domain knowledge merged. What you're optimizing for, what you know that the agent doesn't, where you're a beginner. | project-private |\n| `team-and-relationships.md` | Per-person notes about collaborators — communication style, sensitivities, mutual dependencies. **Never checked into git.** Lives in `private\u002F` so the gitignore rule `context\u002F**\u002Fprivate\u002F` excludes it. | user-private |\n\n### The three modes\n\n#### Mode 1 — Bootstrap (first-time interview)\n\nTriggered when `context\u002Fowner\u002Fidentity.md` is missing or is a stub. The\nagent runs the interview protocol from `references\u002Finterview-protocol.md`,\nwhich walks through each of the four files in order. Each file's interview\nis a small set of questions (3-6 per file). Drafts are reviewed by the\nuser before being saved. The whole bootstrap takes 20-40 minutes and\nshould NOT be done in a single sitting unless the user is fresh — break\nacross sessions if needed.\n\nThe recommended order is:\n1. `identity.md` first (10 minutes) — quick wins, useful immediately\n2. `working-style.md` second (15 minutes) — biggest payoff per minute\n3. `goals-and-context.md` third (10 minutes)\n4. `team-and-relationships.md` last (5 minutes per person, optional — many users skip this initially)\n\n#### Mode 2 — Refine (target one file)\n\nTriggered by an explicit user request: \"Let's update my working style file.\"\nOr by the agent noticing a section is empty\u002Fstale and asking. The agent\nloads the file, walks the relevant interview questions for the empty\nsections only, drafts updates, gets approval, writes back.\n\n#### Mode 3 — Observe (incremental enrichment)\n\nTriggered by signals seen during normal work, NOT by an explicit request.\nThe agent has the table from `references\u002Fobservable-signals.md` in mind\nand watches for evidence: terse vs. verbose messages, formality, jargon\nusage, decision speed, dependency attitudes, etc. When the agent has\nobserved something **3+ times** in the same session OR **across 3+\nsessions**, it surfaces it to the user:\n\n> \"I've noticed you consistently prefer X over Y. Want me to add this to\n> your working-style.md as a preference?\"\n\nThe agent NEVER edits the profile silently. The user always approves.\n\n### Always-loaded vs. on-demand\n\nThe agent loads `identity.md` and `working-style.md` at session start. These\nare short and high-leverage. `goals-and-context.md` is loaded when the\nsession involves planning or scoping decisions. `team-and-relationships.md`\nis loaded selectively when the agent is preparing communication for a\nspecific person (PR review, email draft, meeting prep).\n\nThis is the entry point for the broader context-efficiency story (see the\n`agent-management` skill's \"Context budget and lazy loading\" section).\n\n### Commands\n\n- `\u002Fowner-profiling-bootstrap owner-name` — run the initial profiling interview for a new project owner\n- `\u002Fowner-profiling-refine owner-name` — refine an existing owner profile from new observations\n- `\u002Fowner-profiling-observe owner-name observation` — record a behavioural observation about a project owner\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Updating the owner profile when the relationship is what\n  changed.** If Alice's role on the project shifted, that's a\n  Binding update, not an owner-profile rewrite. The owner profile\n  describes who the owner IS, not what they're currently DOING.\n- **Putting sensitive information in public profile files.**\n  Personal context (home situation, salary, relationship dynamics\n  with specific colleagues) belongs in the user-private files\n  under `context\u002Fowner\u002Fprivate\u002F`. Never write sensitive content\n  to `assets\u002Fidentity.md` or any other public-tier file.\n- **Treating the profile as a static one-shot document.** Owner\n  profiles are living artifacts. Re-run the interview protocol\n  when major life or work changes happen, and update incrementally\n  whenever observable signals warrant it (per the\n  observable-signals reference).\n- **Skipping the interview protocol because \"it'll be faster to\n  guess\".** Don't infer the owner's preferences from one\n  conversation. The interview exists because preferences are\n  surprising — even self-aware owners frequently say \"I didn't\n  realize I cared about that\" mid-interview.\n- **Profile fields out of sync with each other.** If\n  `working-style.md` says timezone CET but `goals-and-context.md`\n  says working hours 6am-10am ET, one of them is wrong. Run a\n  consistency check across the four files when updating any of\n  them.\n- **Inferring strong preferences from one interaction.** A\n  one-time annoyance is not a preference. Wait for at least two\n  independent observations of the same pattern before adding it\n  to the profile.\n- **Forgetting privacy tier on new fields.** Every field added to\n  the profile must declare its privacy tier (`public`,\n  `project-private`, or `user-private`). Defaulting to public for\n  convenience leaks information. Default to `user-private` and\n  upgrade visibility deliberately.\n\n## Full reference\n\n### The four templates\n\nThe templates live in `assets\u002F` and are scaffolded into a project's\n`context\u002Fowner\u002F` and `context\u002Fowner\u002Fprivate\u002F` directories during `aibox\ninit` (or when the owner-profiling skill is first activated).\n\n- **`assets\u002Fidentity.md`** — frontmatter (`privacy: public`) + sections:\n  Name\u002FRole\u002FOrganization, What I Do (one paragraph), What I'm Known For\n  (1-3 sentences). The entire file should be under one screen.\n\n- **`assets\u002Fworking-style.md`** — frontmatter (`privacy: project-private`) +\n  sections: Communication style (tone, length, formality), Hard\n  constraints (timezone, availability, non-negotiables), Strong preferences\n  (formatting, vocabulary, dislikes), Role and responsibilities (weekly\n  cadence, decision authority, deliverables), Things I hate (visceral pet\n  peeves the agent should avoid).\n\n- **`assets\u002Fgoals-and-context.md`** — frontmatter (`privacy: project-private`) +\n  sections: Current goals (this quarter), Longer-term goals (year+),\n  How I think about tradeoffs (default positions), What I'm NOT\n  prioritizing, Areas of expertise, Key terminology (jargon I use without\n  needing definitions), Where I'm a beginner (topics where I want more\n  explanation).\n\n- **`assets\u002Fteam-and-relationships.md`** — frontmatter (`privacy:\n  user-private`) + per-person blocks: Name, Role, Relationship type, How\n  we interact, What they need from me, What I need from them, Context for\n  agents (sensitivities, communication style, preferences). **Lives in\n  `context\u002Fowner\u002Fprivate\u002F` by convention.**\n\n### The interview protocol\n\nSee `references\u002Finterview-protocol.md`. It contains the per-file question\nlist, the order, and the discipline rules (sequential not batched, draft\nafter 3-4 questions, validate before saving, never edit silently).\n\n### Observable signals\n\nSee `references\u002Fobservable-signals.md`. A table of patterns the agent\nshould watch for during normal work, organized by category (communication,\ntechnical preferences, decision patterns, workflow patterns). Each row\ndescribes the signal, how to observe it, and an example recorded preference.\n\n### The privacy convention\n\nPrivacy tiers are enforced by directory layout:\n\n| Tier | Path under `context\u002F` | Git status |\n|---|---|---|\n| public | `owner\u002Fidentity.md` (and other `privacy: public` files) | tracked |\n| project-private | `owner\u002Fworking-style.md`, `owner\u002Fgoals-and-context.md` | tracked |\n| user-private | `owner\u002Fprivate\u002Fteam-and-relationships.md` | gitignored |\n\nThe aibox `.gitignore` includes `context\u002F**\u002Fprivate\u002F` which matches\n`private\u002F` directories at any depth under `context\u002F`. `aibox lint` (Phase 4.4)\nverifies that any entity with `privacy: user-private` lives under a\n`private\u002F` directory.\n\n### Why these four and not the original ten\n\nThe portfolio source ([nlwhittemore\u002Fpersonal-context-portfolio](https:\u002F\u002Fgithub.com\u002Fnlwhittemore\u002Fpersonal-context-portfolio))\nproposes ten files. We merged for context efficiency:\n\n| Original portfolio file | Where it goes here |\n|---|---|\n| identity.md | `identity.md` |\n| role-and-responsibilities.md | merged into `working-style.md` |\n| communication-style.md | merged into `working-style.md` |\n| preferences-and-constraints.md | merged into `working-style.md` |\n| current-projects.md | dropped — overlaps with `context\u002FPROJECTS.md` (process tier) |\n| goals-and-priorities.md | merged into `goals-and-context.md` |\n| domain-knowledge.md | merged into `goals-and-context.md` |\n| team-and-relationships.md | `team-and-relationships.md` (kept standalone, in `private\u002F`) |\n| tools-and-systems.md | dropped — already captured by `aibox.toml` and the devcontainer |\n| decision-log.md | dropped — overlaps with `context\u002Fdecisions\u002F` (DecisionRecord primitive) |\n\nNet: 10 portfolio files → 4 owner-profiling files. Roughly half the loaded\ncontext for a typical session, with no information loss for the workflows\nwe care about.\n\n### Relationship to the Actor primitive\n\n`owner-profiling` does NOT replace the `Actor` primitive. They serve\ndifferent purposes:\n\n- **`Actor` entities** (under `context\u002Factors\u002F`) — structured records of\n  every person\u002Fagent\u002Fservice that participates in the project. Used for\n  assignments, bindings, role-binding lookups. Machine-readable.\n- **`owner-profiling` files** (under `context\u002Fowner\u002F`) — the project owner's\n  rich personal context, in prose, optimized for the agent reading them at\n  session start. Human-authored.\n\nThe owner is also an Actor entity (`ACTOR-owner` typically), but their\nActor file is a thin pointer to the rich `owner\u002F` files. The `Actor` file\nmight say `bio_files: [\"context\u002Fowner\u002Fidentity.md\", \"context\u002Fowner\u002Fworking-style.md\"]`\nso any tool that wants the owner's profile knows where to look.\n\n### Multi-actor profiles (future)\n\nThe current design assumes a single owner per project. A future extension\ncould put each actor's profile under `context\u002Factors\u002F\u003Cactor-id>\u002F` with the\nsame four-file structure. The `actor-profile` skill would learn about\nthis layout. v0.4.0 ships only the owner case.\n\n### MCP server\n\nNone in v0.4.0. The skill is markdown-only. The agent reads\u002Fwrites the\nfiles via the standard file-edit tool. If patterns of use justify a server\nin a future release (e.g. \"validate the privacy tier matches the\ndirectory\" as a tool call), it can be added; until then, the simplicity\nof \"just files\" wins.\n","# Owner Profiling\n\n## Intro\n\n`owner-profiling` builds and maintains a four-file personal context portfolio\nfor the project owner: who they are, how they want to be communicated with,\nwhat they're optimizing for, and who they work with. The profile is the\nsingle most-loaded set of files per session — it's how the agent learns to\nsound like the owner and act in their interest. This skill operates in three\nmodes: **bootstrap** (interview when no profile exists), **refine** (walk\nthrough one file to update it), and **observe** (incrementally enrich the\nprofile from signals seen during normal work).\n\n## Overview\n\n### The four files\n\n```\ncontext\u002Fowner\u002F                  ← public + project-private files (git-tracked)\n  identity.md                   privacy: public\n  working-style.md              privacy: project-private (default)\n  goals-and-context.md          privacy: project-private (default)\n\ncontext\u002Fowner\u002Fprivate\u002F          ← user-private files (gitignored)\n  team-and-relationships.md     privacy: user-private\n```\n\n| File | What it contains | Privacy |\n|---|---|---|\n| `identity.md` | Name, role, organization, what you do, what you're known for. The \"if the agent can only read one file, this is it\" file. | public |\n| `working-style.md` | Communication style + preferences-and-constraints + role-and-responsibilities merged. The hard rules, the always-do\u002Fnever-do list, the tone preferences, the actual weekly cadence. The single highest-leverage file per session. | project-private |\n| `goals-and-context.md` | Goals & priorities + domain knowledge merged. What you're optimizing for, what you know that the agent doesn't, where you're a beginner. | project-private |\n| `team-and-relationships.md` | Per-person notes about collaborators — communication style, sensitivities, mutual dependencies. **Never checked into git.** Lives in `private\u002F` so the gitignore rule `context\u002F**\u002Fprivate\u002F` excludes it. | user-private |\n\n### The three modes\n\n#### Mode 1 — Bootstrap (first-time interview)\n\nTriggered when `context\u002Fowner\u002Fidentity.md` is missing or is a stub. The\nagent runs the interview protocol from `references\u002Finterview-protocol.md`,\nwhich walks through each of the four files in order. Each file's interview\nis a small set of questions (3-6 per file). Drafts are reviewed by the\nuser before being saved. The whole bootstrap takes 20-40 minutes and\nshould NOT be done in a single sitting unless the user is fresh — break\nacross sessions if needed.\n\nThe recommended order is:\n1. `identity.md` first (10 minutes) — quick wins, useful immediately\n2. `working-style.md` second (15 minutes) — biggest payoff per minute\n3. `goals-and-context.md` third (10 minutes)\n4. `team-and-relationships.md` last (5 minutes per person, optional — many users skip this initially)\n\n#### Mode 2 — Refine (target one file)\n\nTriggered by an explicit user request: \"Let's update my working style file.\"\nOr by the agent noticing a section is empty\u002Fstale and asking. The agent\nloads the file, walks the relevant interview questions for the empty\nsections only, drafts updates, gets approval, writes back.\n\n#### Mode 3 — Observe (incremental enrichment)\n\nTriggered by signals seen during normal work, NOT by an explicit request.\nThe agent has the table from `references\u002Fobservable-signals.md` in mind\nand watches for evidence: terse vs. verbose messages, formality, jargon\nusage, decision speed, dependency attitudes, etc. When the agent has\nobserved something **3+ times** in the same session OR **across 3+\nsessions**, it surfaces it to the user:\n\n> \"I've noticed you consistently prefer X over Y. Want me to add this to\n> your working-style.md as a preference?\"\n\nThe agent NEVER edits the profile silently. The user always approves.\n\n### Always-loaded vs. on-demand\n\nThe agent loads `identity.md` and `working-style.md` at session start. These\nare short and high-leverage. `goals-and-context.md` is loaded when the\nsession involves planning or scoping decisions. `team-and-relationships.md`\nis loaded selectively when the agent is preparing communication for a\nspecific person (PR review, email draft, meeting prep).\n\nThis is the entry point for the broader context-efficiency story (see the\n`agent-management` skill's \"Context budget and lazy loading\" section).\n\n### Commands\n\n- `\u002Fowner-profiling-bootstrap owner-name` — run the initial profiling interview for a new project owner\n- `\u002Fowner-profiling-refine owner-name` — refine an existing owner profile from new observations\n- `\u002Fowner-profiling-observe owner-name observation` — record a behavioural observation about a project owner\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Updating the owner profile when the relationship is what\n  changed.** If Alice's role on the project shifted, that's a\n  Binding update, not an owner-profile rewrite. The owner profile\n  describes who the owner IS, not what they're currently DOING.\n- **Putting sensitive information in public profile files.**\n  Personal context (home situation, salary, relationship dynamics\n  with specific colleagues) belongs in the user-private files\n  under `context\u002Fowner\u002Fprivate\u002F`. Never write sensitive content\n  to `assets\u002Fidentity.md` or any other public-tier file.\n- **Treating the profile as a static one-shot document.** Owner\n  profiles are living artifacts. Re-run the interview protocol\n  when major life or work changes happen, and update incrementally\n  whenever observable signals warrant it (per the\n  observable-signals reference).\n- **Skipping the interview protocol because \"it'll be faster to\n  guess\".** Don't infer the owner's preferences from one\n  conversation. The interview exists because preferences are\n  surprising — even self-aware owners frequently say \"I didn't\n  realize I cared about that\" mid-interview.\n- **Profile fields out of sync with each other.** If\n  `working-style.md` says timezone CET but `goals-and-context.md`\n  says working hours 6am-10am ET, one of them is wrong. Run a\n  consistency check across the four files when updating any of\n  them.\n- **Inferring strong preferences from one interaction.** A\n  one-time annoyance is not a preference. Wait for at least two\n  independent observations of the same pattern before adding it\n  to the profile.\n- **Forgetting privacy tier on new fields.** Every field added to\n  the profile must declare its privacy tier (`public`,\n  `project-private`, or `user-private`). Defaulting to public for\n  convenience leaks information. Default to `user-private` and\n  upgrade visibility deliberately.\n\n## Full reference\n\n### The four templates\n\nThe templates live in `assets\u002F` and are scaffolded into a project's\n`context\u002Fowner\u002F` and `context\u002Fowner\u002Fprivate\u002F` directories during `aibox\ninit` (or when the owner-profiling skill is first activated).\n\n- **`assets\u002Fidentity.md`** — frontmatter (`privacy: public`) + sections:\n  Name\u002FRole\u002FOrganization, What I Do (one paragraph), What I'm Known For\n  (1-3 sentences). The entire file should be under one screen.\n\n- **`assets\u002Fworking-style.md`** — frontmatter (`privacy: project-private`) +\n  sections: Communication style (tone, length, formality), Hard\n  constraints (timezone, availability, non-negotiables), Strong preferences\n  (formatting, vocabulary, dislikes), Role and responsibilities (weekly\n  cadence, decision authority, deliverables), Things I hate (visceral pet\n  peeves the agent should avoid).\n\n- **`assets\u002Fgoals-and-context.md`** — frontmatter (`privacy: project-private`) +\n  sections: Current goals (this quarter), Longer-term goals (year+),\n  How I think about tradeoffs (default positions), What I'm NOT\n  prioritizing, Areas of expertise, Key terminology (jargon I use without\n  needing definitions), Where I'm a beginner (topics where I want more\n  explanation).\n\n- **`assets\u002Fteam-and-relationships.md`** — frontmatter (`privacy:\n  user-private`) + per-person blocks: Name, Role, Relationship type, How\n  we interact, What they need from me, What I need from them, Context for\n  agents (sensitivities, communication style, preferences). **Lives in\n  `context\u002Fowner\u002Fprivate\u002F` by convention.**\n\n### The interview protocol\n\nSee `references\u002Finterview-protocol.md`. It contains the per-file question\nlist, the order, and the discipline rules (sequential not batched, draft\nafter 3-4 questions, validate before saving, never edit silently).\n\n### Observable signals\n\nSee `references\u002Fobservable-signals.md`. A table of patterns the agent\nshould watch for during normal work, organized by category (communication,\ntechnical preferences, decision patterns, workflow patterns). Each row\ndescribes the signal, how to observe it, and an example recorded preference.\n\n### The privacy convention\n\nPrivacy tiers are enforced by directory layout:\n\n| Tier | Path under `context\u002F` | Git status |\n|---|---|---|\n| public | `owner\u002Fidentity.md` (and other `privacy: public` files) | tracked |\n| project-private | `owner\u002Fworking-style.md`, `owner\u002Fgoals-and-context.md` | tracked |\n| user-private | `owner\u002Fprivate\u002Fteam-and-relationships.md` | gitignored |\n\nThe aibox `.gitignore` includes `context\u002F**\u002Fprivate\u002F` which matches\n`private\u002F` directories at any depth under `context\u002F`. `aibox lint` (Phase 4.4)\nverifies that any entity with `privacy: user-private` lives under a\n`private\u002F` directory.\n\n### Why these four and not the original ten\n\nThe portfolio source ([nlwhittemore\u002Fpersonal-context-portfolio](https:\u002F\u002Fgithub.com\u002Fnlwhittemore\u002Fpersonal-context-portfolio))\nproposes ten files. We merged for context efficiency:\n\n| Original portfolio file | Where it goes here |\n|---|---|\n| identity.md | `identity.md` |\n| role-and-responsibilities.md | merged into `working-style.md` |\n| communication-style.md | merged into `working-style.md` |\n| preferences-and-constraints.md | merged into `working-style.md` |\n| current-projects.md | dropped — overlaps with `context\u002FPROJECTS.md` (process tier) |\n| goals-and-priorities.md | merged into `goals-and-context.md` |\n| domain-knowledge.md | merged into `goals-and-context.md` |\n| team-and-relationships.md | `team-and-relationships.md` (kept standalone, in `private\u002F`) |\n| tools-and-systems.md | dropped — already captured by `aibox.toml` and the devcontainer |\n| decision-log.md | dropped — overlaps with `context\u002Fdecisions\u002F` (DecisionRecord primitive) |\n\nNet: 10 portfolio files → 4 owner-profiling files. Roughly half the loaded\ncontext for a typical session, with no information loss for the workflows\nwe care about.\n\n### Relationship to the Actor primitive\n\n`owner-profiling` does NOT replace the `Actor` primitive. They serve\ndifferent purposes:\n\n- **`Actor` entities** (under `context\u002Factors\u002F`) — structured records of\n  every person\u002Fagent\u002Fservice that participates in the project. Used for\n  assignments, bindings, role-binding lookups. Machine-readable.\n- **`owner-profiling` files** (under `context\u002Fowner\u002F`) — the project owner's\n  rich personal context, in prose, optimized for the agent reading them at\n  session start. Human-authored.\n\nThe owner is also an Actor entity (`ACTOR-owner` typically), but their\nActor file is a thin pointer to the rich `owner\u002F` files. The `Actor` file\nmight say `bio_files: [\"context\u002Fowner\u002Fidentity.md\", \"context\u002Fowner\u002Fworking-style.md\"]`\nso any tool that wants the owner's profile knows where to look.\n\n### Multi-actor profiles (future)\n\nThe current design assumes a single owner per project. A future extension\ncould put each actor's profile under `context\u002Factors\u002F\u003Cactor-id>\u002F` with the\nsame four-file structure. The `actor-profile` skill would learn about\nthis layout. v0.4.0 ships only the owner case.\n\n### MCP server\n\nNone in v0.4.0. The skill is markdown-only. The agent reads\u002Fwrites the\nfiles via the standard file-edit tool. If patterns of use justify a server\nin a future release (e.g. \"validate the privacy tier matches the\ndirectory\" as a tool call), it can be added; until then, the simplicity\nof \"just files\" wins.\n",{"name":5,"metadata":54,"description":88},{"processkit":55},{"id":56,"uses":57,"layer":64,"created":65,"version":66,"category":67,"commands":68,"provides":80,"apiVersion":87},"SKILL-owner-profiling",[58,61],{"skill":59,"purpose":60},"event-log","Log events to keep the audit trail accurate after every write.",{"skill":62,"purpose":63},"actor-profile","Resolve and validate Actor IDs referenced by this skill's entities.",4,1775520000000,"1.0.0","process",[69,73,76],{"args":70,"name":71,"description":72},"owner-name","owner-profiling-bootstrap","Run the initial profiling interview for a new project owner",{"args":70,"name":74,"description":75},"owner-profiling-refine","Refine an existing owner profile from new observations",{"args":77,"name":78,"description":79},"owner-name observation","owner-profiling-observe","Record a behavioural observation about a project owner",{"templates":81,"primitives":86},[82,83,84,85],"identity","working-style","goals-and-context","team-and-relationships",[],"processkit.projectious.work\u002Fv1","Build and maintain a structured personal-context portfolio for the project owner — identity, working style, goals, team, decision patterns. Includes both an interview protocol for bootstrapping and observable-signal patterns for incremental refinement. Use to bootstrap an owner profile (interview), to refine an existing profile (target one file), or to incrementally update the profile based on observed patterns from a normal session (the agent watches for signals and proposes additions when evidence accrues).\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":97,"prompt":107,"zipAvailable":108},[98,101,104],{"tool":99,"command":100},"npx","npx skills add projectious-work\u002Fprocesskit --skill owner-profiling",{"tool":102,"command":103},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill owner-profiling",{"tool":105,"command":106},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill owner-profiling","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling\u002FSKILL.md",true,[110,116,120,124,128,134,138,142,146],{"path":111,"resourceType":112,"resourceTypeDesc":113,"sizeBytes":114,"sourceHtmlUrl":115},"assets\u002Fgoals-and-context.md","ASSET","资产文件",1779,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling\u002Fassets\u002Fgoals-and-context.md",{"path":117,"resourceType":112,"resourceTypeDesc":113,"sizeBytes":118,"sourceHtmlUrl":119},"assets\u002Fidentity.md",634,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling\u002Fassets\u002Fidentity.md",{"path":121,"resourceType":112,"resourceTypeDesc":113,"sizeBytes":122,"sourceHtmlUrl":123},"assets\u002Fteam-and-relationships.md",1351,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling\u002Fassets\u002Fteam-and-relationships.md",{"path":125,"resourceType":112,"resourceTypeDesc":113,"sizeBytes":126,"sourceHtmlUrl":127},"assets\u002Fworking-style.md",2592,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling\u002Fassets\u002Fworking-style.md",{"path":129,"resourceType":130,"resourceTypeDesc":131,"sizeBytes":132,"sourceHtmlUrl":133},"commands\u002Fowner-profiling-bootstrap.md","REFERENCE","参考文档",138,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling\u002Fcommands\u002Fowner-profiling-bootstrap.md",{"path":135,"resourceType":130,"resourceTypeDesc":131,"sizeBytes":136,"sourceHtmlUrl":137},"commands\u002Fowner-profiling-observe.md",144,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling\u002Fcommands\u002Fowner-profiling-observe.md",{"path":139,"resourceType":130,"resourceTypeDesc":131,"sizeBytes":140,"sourceHtmlUrl":141},"commands\u002Fowner-profiling-refine.md",130,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling\u002Fcommands\u002Fowner-profiling-refine.md",{"path":143,"resourceType":130,"resourceTypeDesc":131,"sizeBytes":144,"sourceHtmlUrl":145},"references\u002Finterview-protocol.md",5521,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling\u002Freferences\u002Finterview-protocol.md",{"path":147,"resourceType":130,"resourceTypeDesc":131,"sizeBytes":148,"sourceHtmlUrl":149},"references\u002Fobservable-signals.md",7571,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.8.0\u002Fcontext\u002Fskills\u002Fowner-profiling\u002Freferences\u002Fobservable-signals.md",[151,173,193,213,230,248],{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":49},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[157],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[159,160,161,48,162,163,43,164,165,166,153,167,168,169,170,171,172],"management","skill management","create","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":180,"publishedAt":49},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[179],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[159,181,182,183,184,185,163,43,186,187,165,188,189,190,167,191,192],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":199,"publishedAt":49},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[159,200,201,161,48,202,163,43,41,203,204,205,167,206,207,208,209,210,211,212],"proposition","proposition management","index","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":217,"categories":218,"keywords":219,"publishedAt":49},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[159,166,220,161,163,221,222,186,223,41,165,224,225,167,226,227,207,228,170,229],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":231,"name":232,"nameZh":6,"description":233,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":234,"categories":235,"keywords":236,"publishedAt":49},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[237,238,239,240,163,241,242,243,43,244,245,246,247],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":249,"name":250,"nameZh":6,"description":251,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":252,"categories":253,"keywords":254,"publishedAt":49},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[159,255,256,161,48,202,163,221,43,164,41,257,165,204,167,227,207,208,258,172],"capability","capability management","queries","changes"]