individual-management

name	individual-management
description	Manage individual lifecycle and knowledge injection. Use when you need to create, retire, restore, or permanently remove individuals, or when you need to inject principles and procedures into an individual.

Feature: Individual Lifecycle Manage the full lifecycle of individuals in the RoleX world. All operations are invoked via the use tool with ! prefix.

Scenario: born — create a new individual Given you want to bring a new individual into the world When you call use with !individual.born Then a new individual node is created under society And the individual can be activated, hired into organizations, and taught skills And parameters are: """ locator: "!individual.born" args: content: "Feature: ..." # Gherkin persona (optional) id: "sean" # kebab-case identifier alias: ["小明", "xm"] # aliases (optional) """

Scenario: born — persona writing guidelines Given the persona defines who this individual is Then the Feature title names the individual And the description captures personality, values, expertise, and background And Scenarios describe distinct aspects of the persona And keep it concise — identity is loaded at every activation

Scenario: retire — archive an individual Given an individual should be temporarily deactivated When you call use with !individual.retire Then the individual is moved to the past archive And all data is preserved for potential restoration via rehire And parameters are: """ locator: "!individual.retire" args: individual: "sean" """

Scenario: die — permanently remove an individual Given an individual should be permanently removed When you call use with !individual.die Then the individual is moved to the past archive And this is semantically permanent — rehire is technically possible but not intended And parameters are: """ locator: "!individual.die" args: individual: "sean" """

Scenario: retire vs die — when to use which Given you need to remove an individual from active duty When the individual may return later (sabbatical, role rotation) Then use retire — it signals intent to restore When the individual is no longer needed (deprecated role, replaced) Then use die — it signals finality

Scenario: rehire — restore a retired individual Given a retired individual needs to come back When you call use with !individual.rehire Then the individual is restored to active society And all previous knowledge, experience, and history are intact And parameters are: """ locator: "!individual.rehire" args: individual: "sean" """

Feature: Knowledge Injection Inject principles and procedures into an individual from the outside. This bypasses the cognition cycle — no encounters or experiences consumed. Use this to equip individuals with pre-existing knowledge and skills.

Scenario: teach — inject a principle Given an individual needs a rule or guideline it hasn't learned through experience When you call use with !individual.teach Then a principle is created directly under the individual And if a principle with the same id already exists, it is replaced (upsert) And parameters are: """ locator: "!individual.teach" args: individual: "sean" content: "Feature: Always validate input\n ..." id: "always-validate-input" """

Scenario: train — inject a procedure (skill reference) Given an individual needs a skill it hasn't mastered through experience When you call use with !individual.train Then a procedure is created directly under the individual And if a procedure with the same id already exists, it is replaced (upsert) And the procedure Feature description MUST contain the ResourceX locator for the skill And parameters are: """ locator: "!individual.train" args: individual: "sean" content: "Feature: Skill Creator\n https://github.com/Deepractice/DeepracticeX/tree/main/skills/skill-creator\n\n Scenario: When to use\n Given I need to create a skill\n Then load this skill" id: "skill-creator" """

Scenario: teach vs realize — when to use which Given you need to add a principle to an individual When the principle comes from external knowledge (documentation, best practices, user instruction) Then use teach — inject directly, no experience needed When the individual discovered the principle through its own work Then use realize — it consumes experience and produces the principle organically

Scenario: train vs master — when to use which Given you need to add a procedure to an individual When the skill already exists (published skill, known capability) Then use train — inject directly with a locator reference When the individual developed the skill through its own experience Then use master — it consumes experience and produces the procedure organically

Scenario: Principle writing guidelines Given a principle is a transferable truth Then the Feature title states the rule as a general statement And Scenarios describe different situations where this principle applies And the tone is universal — no mention of specific projects or people And the id is keywords joined by hyphens (e.g. "always-validate-input")

Scenario: Procedure writing guidelines Given a procedure is a skill reference pointing to full instructions Then the Feature title names the capability And the Feature description line MUST be the ResourceX locator And the locator can be a GitHub URL, local path, or registry identifier And Scenarios summarize when and why to use this skill And the id is keywords joined by hyphens (e.g. "skill-creator")

Feature: Common Workflows Typical sequences of operations for managing individuals.

Scenario: Bootstrap a new role Given you need to create a fully equipped individual When setting up a new role from scratch Then follow this sequence: """ 1. locator: "!individual.born" args: { id: "sean", content: "Feature: ..." } 2. locator: "!individual.teach" args: { individual: "sean", content: "...", id: "..." } # repeat 3. locator: "!individual.train" args: { individual: "sean", content: "...", id: "..." } # repeat 4. activate with roleId: "sean" # verify the individual's state """

Scenario: Transfer knowledge between individuals Given individual A has a useful principle or procedure When individual B needs the same knowledge Then teach/train the same content to individual B And use the same id to maintain consistency across individuals

Scenario: Update existing knowledge Given an individual's principle or procedure is outdated When the content needs to change but the concept is the same Then teach/train with the same id — upsert replaces the old version And the individual retains the same id with updated content

Scenario: Remove knowledge Given an individual has outdated or incorrect knowledge When it should be removed entirely Then use forget with the node id And only instance nodes can be forgotten — prototype nodes are read-only