[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M73FS2JWXTP0WKFZ77M7WFAS":3,"skill-same:01M73FS2JWXTP0WKFZ77M7WFAS":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M73FS2JWXTP0WKFZ77M7WFAS","agent-lifecycle-manager",null,"Manages the creation, validation, and maintenance of AI agent files across the project, including PM-led hiring (creation) and firing (deprecation\u002Fremoval) of agents with their skill packages. Use when: creating new agents, hiring or firing agents, updating agent metadata\u002Ffrontmatter, validating agent structures, attaching or detaching skills to agents, or managing agent roles and 3-tier configurations.","5throck\u002Fai-workspace-standards","5throck","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F10958964?v=4","01M73BFEH0V0VS483TW4JD49JW","01M73BFEJ5VQZJHJSFTVPAZGDM",25,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-safety\u002F.hermes\u002Fskills\u002Fagent-lifecycle-manager\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: agent-lifecycle-manager\nstatus: active\nscope: common\ndescription: >\n  Manages the creation, validation, and maintenance of AI agent files across the project,\n  including PM-led hiring (creation) and firing (deprecation\u002Fremoval) of agents with their\n  skill packages. Use when: creating new agents, hiring or firing agents, updating agent\n  metadata\u002Ffrontmatter, validating agent structures, attaching or detaching skills to agents,\n  or managing agent roles and 3-tier configurations.\nowner: pm\nversion: 1.4.0\nlast_reviewed: 2026-11-06\nrelates_to:\n  - skill: skill-lifecycle-manager\n    type: composes_with\nmetadata:\n  type: process\n  triggers:\n    - create agent\n    - new agent\n    - validate agents\n    - agent lifecycle\n    - manage agents\n    - hire agent\n    - fire agent\n    - deprecate agent\n---\n\n## Overview\n\nThis skill provides a systematic approach to creating, validating, and maintaining AI agent files (`agents\u002F*.md`). It ensures all agents follow proper structure, have correct YAML frontmatter (status, tier, role, etc.), and are properly registered in the central `AGENTS.md` registry.\n\n## When to Use This Skill\n\n**Create New Agent:**\n- Trigger: \"Create a new agent for X\" or \"Add a new agent to the project\"\n- Use Case: A new specific role is needed that requires its own system prompt and tools.\n\n**Validate Existing Agents:**\n- Trigger: \"Check if agents are valid\" or \"Run agent audit\"\n- Use Case: After modifying agent markdown files, before committing changes.\n\n**Update Agent Status\u002FMetadata:**\n- Trigger: \"Update agent tiers\" or \"Deprecate agent Y\"\n- Use Case: Modifying the 3-tier strategy mappings or retiring old agents.\n\n**Hire an Agent (PM-decided):**\n- Trigger: PM observes a hiring signal (recurring unmatched work type, role overload, new domain) or the user explicitly requests a new specialist\n- Use Case: PM determines the roster needs a new specialist and runs the Hiring Workflow below\n\n**Fire an Agent (PM-decided):**\n- Trigger: PM observes a firing signal (long undispatched agent, absorbed role, quarterly roster review) or the user explicitly requests removal\n- Use Case: PM determines an agent should exit the roster and runs the Firing Workflow below\n\n---\n\n## Step 1: Create or Update Agent File\n\n**Purpose**: Create or modify an agent file in the `agents\u002F` directory.\n\n**Steps**:\n1. Navigate to the `agents\u002F` directory in the project root.\n2. Create or edit `agents\u002F\u003Cagent-name>.md` using kebab-case naming.\n3. (Optional) Run `bun scripts\u002Fagent-create.ts \u003Cagent-name>` if you want to use the automated scaffolding script.\n\n---\n\n## Step 2: Write Agent Frontmatter\n\n**Purpose**: Define agent metadata using the standard YAML frontmatter specification.\n\n**Required Frontmatter Structure**:\n```yaml\n---\nname: agent-name\nrole: \"Brief 2-4 word title\"\nstatus: active\ndescription: \"Short sentence on what the agent does\"\ntier: high | medium | low\n---\n```\n\n**Validation**:\n- All required fields must be present.\n- `status` must be valid.\n- `tier` is one scalar line (`high`, `medium`, or `low`) — the agent author's cost-ceiling declaration (ADR-0102). The platform→model mapping is NOT declared here; `docs\u002Fworkspace-schema.json` → `models` resolves tier→model per platform at dispatch\u002Fvalidation time.\n\n---\n\n## Step 3: Write Agent Content\n\n**Purpose**: Document the agent's system prompt and behavioral instructions.\n\n**Content Guidelines**:\n- Provide clear identity and context mapping.\n- Focus on specific behavioral guidelines and domain constraints.\n- Do NOT repeat global rules (like UTF-8 enforcement or standard PR procedures) that are already covered in workspace standards.\n- **If the agent role involves research, investigation, or presenting external information**: explicitly include the Source Attribution principle in the agent's constraints or behavioral guidelines — require source citation for factual claims and use `⚠️ Unverified` disclosure for unverifiable information.\n- **`## Legal Basis` section is conditional (U-20261026-004)**: include it ONLY for agents whose mandate rests on statutes, regulations, or certification\u002Fpermit regimes (regulatory-dd, legal-counsel, compliance, licensing). Sibling-ownership Boundary content that does not cite a statute belongs in Role or Constraints instead. Do not propagate the section to non-regulatory agents by skeleton inertia — a `## Legal Basis` with no statutory grounding is noise, and no validator excuses it.\n\n---\n\n## Step 4: Update AGENTS.md Registry\n\n**Purpose**: Register the agent in the project's central orchestrator document.\n\n**Steps**:\n1. Open `AGENTS.md` in the project root.\n2. Add a new row to the appropriate table (Orchestration, Design, Execution, Security).\n3. Ensure the format matches: `| Agent Role | agents\u002Fagent-name.md | Tier | Role description |`\n\n---\n\n## Changing an Agent's Tier\n\n**Purpose**: Keep every tier declaration surface in sync when a tier changes.\n\nTier is declared in exactly one place: the agent file's scalar `tier: high|medium|low` frontmatter line (ADR-0102). The schema's only tier-related block is `models`, which maps tier→model per platform — never edit it to change an agent's tier. **Update surfaces in this order**:\n\n1. `agents\u002F\u003Cname>.md` frontmatter scalar `tier:` line (the declaration — change this first)\n2. `AGENTS.md` §1 Agent Roster and §4.1 Subagent Roster Tier cells\n3. `docs\u002Flifecycle\u002Fagents\u002F\u003Cname>.md` `**Tier**:` field (and any stale tier prose)\n\nThen run the tier drift check — it must pass before the change lands:\n\n```bash\nbun scripts\u002Flifecycle-sync-audit.ts   # Check F: tier cross-surface parity (frontmatter anchor)\n```\n\n---\n\n## Step 5: Validate Agent Lifecycle\n\n**Purpose**: Ensure the agent passes all programmatic lifecycle audits.\n\n**Run Validation Scripts**:\nTo run a comprehensive audit across all agents:\n```bash\nbun scripts\u002Fagent-lifecycle-audit.ts\n```\n\nTo verify a specific agent:\n```bash\nbun scripts\u002Fagent-verify.ts \u003Cagent-name>\n```\n\nTo verify tier consistency across all tier surfaces (frontmatter, AGENTS.md rosters, lifecycle records):\n```bash\nbun scripts\u002Flifecycle-sync-audit.ts   # Check F\n```\n\n**Validation Checklist**:\n- [ ] No orphaned agents (every `.md` file in `agents\u002F` is listed in `AGENTS.md`)\n- [ ] Frontmatter passes all audit checks\n- [ ] Tier mappings are correctly structured\n- [ ] Tier drift check passes (Check F: rosters and lifecycle record all agree with the frontmatter scalar `tier:`)\n- [ ] **Recommended**: Consider declaring the skill's deployment scope — is it needed in all variant projects (common) or workspace-root-only? Workspace-only skills should not be placed in `templates\u002Fcommon\u002Fskills\u002F`.\n- [ ] **If research\u002Finvestigation role**: agent content includes source citation requirements and uncertainty disclosure (`⚠️ Unverified`)\n- [ ] **If numerical computation role** (aerospace, finance, precision control, scientific): agent content includes Computational Integrity Standards — states that calculations must be delegated to external tools (Fortran, Python+NumPy, etc.) and never performed by AI directly\n- [ ] **If education\u002Ftutoring\u002Fcoaching role**: agent content includes the Socratic Method as the default teaching approach — guide learners through questions before providing direct answers; include explicit exceptions for urgent or simple lookup contexts where direct answers are appropriate\n\n---\n\n## Hiring Workflow (PM-decided)\n\nPM decides when to hire autonomously — no blocking user approval. A hiring decision is recorded and executed through dispatch:\n\n| Role | Duty |\n|------|------|\n| PM | Detect signal, define role, decide, emit decision record, dispatch |\n| automation-engineer | Execute file edits (agent file, registry) |\n| lifecycle-manager | Update governance records, publish L0→L1 |\n\n### Step H1: Detect Signal and Check Duplication\n\n**Hiring signals** (any one suffices, evidence goes in the decision record):\n- The same work type recurs with no matching specialist at triage classification\n- One agent repeatedly absorbs unrelated domain work (role overload)\n- A new domain keeps requiring ad-hoc handling; a direct user request (\"hire an agent for X\") is also a valid signal\n\nBefore proceeding, verify the role does not duplicate an existing agent: review the current roster (`agents\u002F*.md` frontmatter and the AGENTS.md §1 roster) and check whether re-tiering, re-scoping, or a skill attach would cover the need instead.\n\n### Step H2: Define the Role\n\n- Name: kebab-case, maps 1:1 to `agents\u002F\u003Cname>.md`\n- Responsibilities: 2–4 concrete duties, distinct from every existing agent\n- Phases: which workflow phases the agent leads or supports\n- Tier: assign per the 3-tier strategy (one scalar `tier:` line in the agent frontmatter; the schema `models` block resolves the model per platform — ADR-0102)\n\n### Step H3: Assemble the Initial Skill Package\n\nThe initial skill package is part of the hiring decision (PM-decided). For each required capability:\n\n1. Search `skills\u002F*\u002FSKILL.md` for an existing skill covering it\n2. **Found** → attach: set\u002Fextend the skill's `owner:` to include the new agent (see Skill Attach\u002FDetach Rules below)\n3. **Not found** → file a skill `create` request through the Skill Request Workflow in `skill-lifecycle-manager` (agent-initiated, PM-approved); execution may follow after hiring\n\n### Step H4: Record the Decision\n\nBefore any dispatch:\n1. Emit a Gate-Moment Decision Record at `docs\u002Fdecisions\u002FDEC-YYYYMMDD-NN.md` (ADR-0061). The record must carry the ADR-0061 required frontmatter fields (`id, date, agent, decision, alternatives, status`); validate with `bun scripts\u002Fvalidate-decisions.ts`. Content: signal, evidence, role definition, skill package, alternatives considered (re-scope\u002Fattach existing agent)\n2. Append a summary entry to the active `memory\u002FYYYY-MM-DD.md`\n\n### Step H5: Execute via Dispatch\n\nPM dispatches **automation-engineer** (never edits files directly):\n1. Create `agents\u002F\u003Cname>.md` — write it directly (recommended) or via `bun scripts\u002Fagent-create.ts \u003Cagent-name>`; the file must contain **all schema-required frontmatter fields** (`name`, `role`, `status`, `tier`, `version`, `last_reviewed`, `description`, `lifecycle` per `schemas\u002Fagent.schema.json`)\n2. Register the agent in the AGENTS.md §1 Agent Roster table (`| Agent Role | agents\u002Fagent-name.md | Tier | Role description |`)\n3. Apply the skill package owner updates (Step H3)\n4. Create the governance record `docs\u002Flifecycle\u002Fagents\u002F\u003Cname>.md` (Created date, empty Phase History, Metadata with Owner + Current Phase `production`)\n5. lifecycle-manager then updates governance records, regenerates the derived artifacts (`bun scripts\u002Fgenerate-version-manifest.ts`, `bun scripts\u002Fgenerate-skill-graph.ts`), and publishes via `bun run propagate:apply`\n\n### Step H6: Validate\n\n```bash\nbun scripts\u002Fagent-lifecycle-audit.ts   # all-agent audit\nbun scripts\u002Flifecycle-sync-audit.ts    # Check F: tier cross-surface parity\n```\n\nBoth must pass before the hiring is considered complete.\n\n---\n\n## Firing Workflow (PM-decided)\n\nPM decides when to fire autonomously. Default exit is **deprecation** (reversible); hard delete requires an explicit user request.\n\n### Step F1: Detect Signal and Analyze Dependencies\n\n**Firing signals**:\n- Agent not dispatched over an extended period (evidence from lifecycle records \u002F memory logs)\n- Role fully absorbed by another agent\n- Quarterly roster review (AGENTS.md §10 cadence; the Q4 deprecation sweep may be extended to agents)\n\nDependency analysis before deciding — map everything that breaks if the agent exits:\n1. **Owned skills**: reverse-lookup `owner:` across `skills\u002F*\u002FSKILL.md`\n2. **Handoff relations**: `handoff_to` \u002F `handoff_from` in the agent definition and dispatch templates\n3. **Phases**: phases where the agent is lead or supporting\n4. **Roster references**: AGENTS.md §1\u002F§4.1 rows, `docs\u002Flifecycle\u002Fagents\u002F\u003Cname>.md`\n\n### Step F2: Plan Skill Disposition\n\nThe disposition plan is part of the firing decision — the fired agent cannot request anything:\n- **Still-needed skills** → reassign `owner:` to a surviving agent (or to the hiring package of a replacement)\n- **Unnecessary skills** → route through the Deprecation & Removal section of `skill-lifecycle-manager` (PM-approved)\n\n### Step F3: Record the Decision\n\nBefore any dispatch:\n1. Emit a Gate-Moment Decision Record at `docs\u002Fdecisions\u002FDEC-YYYYMMDD-NN.md` (ADR-0061) with the required frontmatter fields; validate with `bun scripts\u002Fvalidate-decisions.ts`. Content: signal, dependency map, disposition plan, exit mode (deprecate vs delete)\n2. Append a summary entry to the active `memory\u002FYYYY-MM-DD.md`\n\n### Step F4: Execute via Dispatch\n\nPM dispatches **automation-engineer**:\n\n**Default — deprecate:**\n1. Set `status: deprecated` in the agent frontmatter (keep the file and governance record in place)\n2. Schedule the removal review: set `removal_review: YYYY-MM-DD` in the agent frontmatter (default: deprecation + 90 days) — the quarterly roster review consumes it, and `agent-lifecycle-audit.ts` FAILS once the date passes without a review decision\n3. Apply the skill disposition plan (Step F2)\n4. Update AGENTS.md roster cells (mark deprecated; do not delete the row yet)\n5. lifecycle-manager updates governance records, regenerates derived artifacts (`generate-version-manifest.ts`, `generate-skill-graph.ts`), and publishes L0→L1\n\n**Hard delete — explicit user request only:**\n1. Confirm the user explicitly asked for deletion (not just \"fire\" in passing)\n2. Run `bun scripts\u002Fagent-delete.ts \u003Cname> --force`\n3. Remove the AGENTS.md §1\u002F§4.1 roster rows\n4. Complete the skill disposition plan — no orphaned skills may remain\n5. lifecycle-manager updates governance records, regenerates derived artifacts, and publishes L0→L1\n\n### Step F5: Validate\n\n```bash\nbun scripts\u002Fagent-lifecycle-audit.ts\nbun scripts\u002Flifecycle-sync-audit.ts\n```\n\nThe audit now enforces the reference sweep mechanically: Check 13 fails on dangling `handoff_to`\u002F`handoff_from` references to the fired agent, and the skill-disposition checks fail on any skill left with the fired agent as sole (or now-nonexistent) `owner:`. Confirm both in the audit output — these are no longer prose-only checks.\n\n---\n\n## Skill Attach\u002FDetach Rules\n\nSkill-to-agent binding lives in the skill frontmatter `owner:` field. Keep both surfaces consistent — the skill's `owner:` and the agent's own capability descriptions must tell the same story.\n\n- **Attach**: add the agent name to `owner:` (space-delimited or list per existing notation in that file). Do not remove the previous owner unless the capability moves entirely.\n- **Detach**: remove the agent from `owner:` only when another owner remains or the skill is routed to deprecation (never leave `owner:` empty).\n- **Multi-owner**: allowed — record the primary owner first; each owner must actually dispatch the skill in its workflow, otherwise use a one-off reference instead.\n- **Consistency check**: after any attach\u002Fdetach, grep both directions — the skill's `owner:` list and the agent definition's tool\u002Fskill sections — and fix drift before validation.\n\n---\n\n\n## Expected Outputs\n\n- Properly formatted agent `.md` file in the `agents\u002F` directory.\n- Clean run of `agent-lifecycle-audit.ts` with 0 errors or warnings.\n- Updated `AGENTS.md` reflecting the new or modified agent state.\n- For hiring: decision record + registered roster row + attached skill package.\n- For firing: decision record + deprecated status (or clean delete) + completed skill disposition plan.\n\n---\n\n## Related Skills\n\n- **skill-lifecycle-manager**: Manages skill creation, validation, agent skill requests (Step R1–R3), and skill deprecation\u002Fremoval.\n- **team-builder**: Whole-team restructuring (benchmarking, bulk create\u002Fconvert\u002Fdelete with skill transfer) — use for team-scale changes, not single-agent hire\u002Ffire.\n","## Overview\n\nThis skill provides a systematic approach to creating, validating, and maintaining AI agent files (`agents\u002F*.md`). It ensures all agents follow proper structure, have correct YAML frontmatter (status, tier, role, etc.), and are properly registered in the central `AGENTS.md` registry.\n\n## When to Use This Skill\n\n**Create New Agent:**\n- Trigger: \"Create a new agent for X\" or \"Add a new agent to the project\"\n- Use Case: A new specific role is needed that requires its own system prompt and tools.\n\n**Validate Existing Agents:**\n- Trigger: \"Check if agents are valid\" or \"Run agent audit\"\n- Use Case: After modifying agent markdown files, before committing changes.\n\n**Update Agent Status\u002FMetadata:**\n- Trigger: \"Update agent tiers\" or \"Deprecate agent Y\"\n- Use Case: Modifying the 3-tier strategy mappings or retiring old agents.\n\n**Hire an Agent (PM-decided):**\n- Trigger: PM observes a hiring signal (recurring unmatched work type, role overload, new domain) or the user explicitly requests a new specialist\n- Use Case: PM determines the roster needs a new specialist and runs the Hiring Workflow below\n\n**Fire an Agent (PM-decided):**\n- Trigger: PM observes a firing signal (long undispatched agent, absorbed role, quarterly roster review) or the user explicitly requests removal\n- Use Case: PM determines an agent should exit the roster and runs the Firing Workflow below\n\n---\n\n## Step 1: Create or Update Agent File\n\n**Purpose**: Create or modify an agent file in the `agents\u002F` directory.\n\n**Steps**:\n1. Navigate to the `agents\u002F` directory in the project root.\n2. Create or edit `agents\u002F\u003Cagent-name>.md` using kebab-case naming.\n3. (Optional) Run `bun scripts\u002Fagent-create.ts \u003Cagent-name>` if you want to use the automated scaffolding script.\n\n---\n\n## Step 2: Write Agent Frontmatter\n\n**Purpose**: Define agent metadata using the standard YAML frontmatter specification.\n\n**Required Frontmatter Structure**:\n```yaml\n---\nname: agent-name\nrole: \"Brief 2-4 word title\"\nstatus: active\ndescription: \"Short sentence on what the agent does\"\ntier: high | medium | low\n---\n```\n\n**Validation**:\n- All required fields must be present.\n- `status` must be valid.\n- `tier` is one scalar line (`high`, `medium`, or `low`) — the agent author's cost-ceiling declaration (ADR-0102). The platform→model mapping is NOT declared here; `docs\u002Fworkspace-schema.json` → `models` resolves tier→model per platform at dispatch\u002Fvalidation time.\n\n---\n\n## Step 3: Write Agent Content\n\n**Purpose**: Document the agent's system prompt and behavioral instructions.\n\n**Content Guidelines**:\n- Provide clear identity and context mapping.\n- Focus on specific behavioral guidelines and domain constraints.\n- Do NOT repeat global rules (like UTF-8 enforcement or standard PR procedures) that are already covered in workspace standards.\n- **If the agent role involves research, investigation, or presenting external information**: explicitly include the Source Attribution principle in the agent's constraints or behavioral guidelines — require source citation for factual claims and use `⚠️ Unverified` disclosure for unverifiable information.\n- **`## Legal Basis` section is conditional (U-20261026-004)**: include it ONLY for agents whose mandate rests on statutes, regulations, or certification\u002Fpermit regimes (regulatory-dd, legal-counsel, compliance, licensing). Sibling-ownership Boundary content that does not cite a statute belongs in Role or Constraints instead. Do not propagate the section to non-regulatory agents by skeleton inertia — a `## Legal Basis` with no statutory grounding is noise, and no validator excuses it.\n\n---\n\n## Step 4: Update AGENTS.md Registry\n\n**Purpose**: Register the agent in the project's central orchestrator document.\n\n**Steps**:\n1. Open `AGENTS.md` in the project root.\n2. Add a new row to the appropriate table (Orchestration, Design, Execution, Security).\n3. Ensure the format matches: `| Agent Role | agents\u002Fagent-name.md | Tier | Role description |`\n\n---\n\n## Changing an Agent's Tier\n\n**Purpose**: Keep every tier declaration surface in sync when a tier changes.\n\nTier is declared in exactly one place: the agent file's scalar `tier: high|medium|low` frontmatter line (ADR-0102). The schema's only tier-related block is `models`, which maps tier→model per platform — never edit it to change an agent's tier. **Update surfaces in this order**:\n\n1. `agents\u002F\u003Cname>.md` frontmatter scalar `tier:` line (the declaration — change this first)\n2. `AGENTS.md` §1 Agent Roster and §4.1 Subagent Roster Tier cells\n3. `docs\u002Flifecycle\u002Fagents\u002F\u003Cname>.md` `**Tier**:` field (and any stale tier prose)\n\nThen run the tier drift check — it must pass before the change lands:\n\n```bash\nbun scripts\u002Flifecycle-sync-audit.ts   # Check F: tier cross-surface parity (frontmatter anchor)\n```\n\n---\n\n## Step 5: Validate Agent Lifecycle\n\n**Purpose**: Ensure the agent passes all programmatic lifecycle audits.\n\n**Run Validation Scripts**:\nTo run a comprehensive audit across all agents:\n```bash\nbun scripts\u002Fagent-lifecycle-audit.ts\n```\n\nTo verify a specific agent:\n```bash\nbun scripts\u002Fagent-verify.ts \u003Cagent-name>\n```\n\nTo verify tier consistency across all tier surfaces (frontmatter, AGENTS.md rosters, lifecycle records):\n```bash\nbun scripts\u002Flifecycle-sync-audit.ts   # Check F\n```\n\n**Validation Checklist**:\n- [ ] No orphaned agents (every `.md` file in `agents\u002F` is listed in `AGENTS.md`)\n- [ ] Frontmatter passes all audit checks\n- [ ] Tier mappings are correctly structured\n- [ ] Tier drift check passes (Check F: rosters and lifecycle record all agree with the frontmatter scalar `tier:`)\n- [ ] **Recommended**: Consider declaring the skill's deployment scope — is it needed in all variant projects (common) or workspace-root-only? Workspace-only skills should not be placed in `templates\u002Fcommon\u002Fskills\u002F`.\n- [ ] **If research\u002Finvestigation role**: agent content includes source citation requirements and uncertainty disclosure (`⚠️ Unverified`)\n- [ ] **If numerical computation role** (aerospace, finance, precision control, scientific): agent content includes Computational Integrity Standards — states that calculations must be delegated to external tools (Fortran, Python+NumPy, etc.) and never performed by AI directly\n- [ ] **If education\u002Ftutoring\u002Fcoaching role**: agent content includes the Socratic Method as the default teaching approach — guide learners through questions before providing direct answers; include explicit exceptions for urgent or simple lookup contexts where direct answers are appropriate\n\n---\n\n## Hiring Workflow (PM-decided)\n\nPM decides when to hire autonomously — no blocking user approval. A hiring decision is recorded and executed through dispatch:\n\n| Role | Duty |\n|------|------|\n| PM | Detect signal, define role, decide, emit decision record, dispatch |\n| automation-engineer | Execute file edits (agent file, registry) |\n| lifecycle-manager | Update governance records, publish L0→L1 |\n\n### Step H1: Detect Signal and Check Duplication\n\n**Hiring signals** (any one suffices, evidence goes in the decision record):\n- The same work type recurs with no matching specialist at triage classification\n- One agent repeatedly absorbs unrelated domain work (role overload)\n- A new domain keeps requiring ad-hoc handling; a direct user request (\"hire an agent for X\") is also a valid signal\n\nBefore proceeding, verify the role does not duplicate an existing agent: review the current roster (`agents\u002F*.md` frontmatter and the AGENTS.md §1 roster) and check whether re-tiering, re-scoping, or a skill attach would cover the need instead.\n\n### Step H2: Define the Role\n\n- Name: kebab-case, maps 1:1 to `agents\u002F\u003Cname>.md`\n- Responsibilities: 2–4 concrete duties, distinct from every existing agent\n- Phases: which workflow phases the agent leads or supports\n- Tier: assign per the 3-tier strategy (one scalar `tier:` line in the agent frontmatter; the schema `models` block resolves the model per platform — ADR-0102)\n\n### Step H3: Assemble the Initial Skill Package\n\nThe initial skill package is part of the hiring decision (PM-decided). For each required capability:\n\n1. Search `skills\u002F*\u002FSKILL.md` for an existing skill covering it\n2. **Found** → attach: set\u002Fextend the skill's `owner:` to include the new agent (see Skill Attach\u002FDetach Rules below)\n3. **Not found** → file a skill `create` request through the Skill Request Workflow in `skill-lifecycle-manager` (agent-initiated, PM-approved); execution may follow after hiring\n\n### Step H4: Record the Decision\n\nBefore any dispatch:\n1. Emit a Gate-Moment Decision Record at `docs\u002Fdecisions\u002FDEC-YYYYMMDD-NN.md` (ADR-0061). The record must carry the ADR-0061 required frontmatter fields (`id, date, agent, decision, alternatives, status`); validate with `bun scripts\u002Fvalidate-decisions.ts`. Content: signal, evidence, role definition, skill package, alternatives considered (re-scope\u002Fattach existing agent)\n2. Append a summary entry to the active `memory\u002FYYYY-MM-DD.md`\n\n### Step H5: Execute via Dispatch\n\nPM dispatches **automation-engineer** (never edits files directly):\n1. Create `agents\u002F\u003Cname>.md` — write it directly (recommended) or via `bun scripts\u002Fagent-create.ts \u003Cagent-name>`; the file must contain **all schema-required frontmatter fields** (`name`, `role`, `status`, `tier`, `version`, `last_reviewed`, `description`, `lifecycle` per `schemas\u002Fagent.schema.json`)\n2. Register the agent in the AGENTS.md §1 Agent Roster table (`| Agent Role | agents\u002Fagent-name.md | Tier | Role description |`)\n3. Apply the skill package owner updates (Step H3)\n4. Create the governance record `docs\u002Flifecycle\u002Fagents\u002F\u003Cname>.md` (Created date, empty Phase History, Metadata with Owner + Current Phase `production`)\n5. lifecycle-manager then updates governance records, regenerates the derived artifacts (`bun scripts\u002Fgenerate-version-manifest.ts`, `bun scripts\u002Fgenerate-skill-graph.ts`), and publishes via `bun run propagate:apply`\n\n### Step H6: Validate\n\n```bash\nbun scripts\u002Fagent-lifecycle-audit.ts   # all-agent audit\nbun scripts\u002Flifecycle-sync-audit.ts    # Check F: tier cross-surface parity\n```\n\nBoth must pass before the hiring is considered complete.\n\n---\n\n## Firing Workflow (PM-decided)\n\nPM decides when to fire autonomously. Default exit is **deprecation** (reversible); hard delete requires an explicit user request.\n\n### Step F1: Detect Signal and Analyze Dependencies\n\n**Firing signals**:\n- Agent not dispatched over an extended period (evidence from lifecycle records \u002F memory logs)\n- Role fully absorbed by another agent\n- Quarterly roster review (AGENTS.md §10 cadence; the Q4 deprecation sweep may be extended to agents)\n\nDependency analysis before deciding — map everything that breaks if the agent exits:\n1. **Owned skills**: reverse-lookup `owner:` across `skills\u002F*\u002FSKILL.md`\n2. **Handoff relations**: `handoff_to` \u002F `handoff_from` in the agent definition and dispatch templates\n3. **Phases**: phases where the agent is lead or supporting\n4. **Roster references**: AGENTS.md §1\u002F§4.1 rows, `docs\u002Flifecycle\u002Fagents\u002F\u003Cname>.md`\n\n### Step F2: Plan Skill Disposition\n\nThe disposition plan is part of the firing decision — the fired agent cannot request anything:\n- **Still-needed skills** → reassign `owner:` to a surviving agent (or to the hiring package of a replacement)\n- **Unnecessary skills** → route through the Deprecation & Removal section of `skill-lifecycle-manager` (PM-approved)\n\n### Step F3: Record the Decision\n\nBefore any dispatch:\n1. Emit a Gate-Moment Decision Record at `docs\u002Fdecisions\u002FDEC-YYYYMMDD-NN.md` (ADR-0061) with the required frontmatter fields; validate with `bun scripts\u002Fvalidate-decisions.ts`. Content: signal, dependency map, disposition plan, exit mode (deprecate vs delete)\n2. Append a summary entry to the active `memory\u002FYYYY-MM-DD.md`\n\n### Step F4: Execute via Dispatch\n\nPM dispatches **automation-engineer**:\n\n**Default — deprecate:**\n1. Set `status: deprecated` in the agent frontmatter (keep the file and governance record in place)\n2. Schedule the removal review: set `removal_review: YYYY-MM-DD` in the agent frontmatter (default: deprecation + 90 days) — the quarterly roster review consumes it, and `agent-lifecycle-audit.ts` FAILS once the date passes without a review decision\n3. Apply the skill disposition plan (Step F2)\n4. Update AGENTS.md roster cells (mark deprecated; do not delete the row yet)\n5. lifecycle-manager updates governance records, regenerates derived artifacts (`generate-version-manifest.ts`, `generate-skill-graph.ts`), and publishes L0→L1\n\n**Hard delete — explicit user request only:**\n1. Confirm the user explicitly asked for deletion (not just \"fire\" in passing)\n2. Run `bun scripts\u002Fagent-delete.ts \u003Cname> --force`\n3. Remove the AGENTS.md §1\u002F§4.1 roster rows\n4. Complete the skill disposition plan — no orphaned skills may remain\n5. lifecycle-manager updates governance records, regenerates derived artifacts, and publishes L0→L1\n\n### Step F5: Validate\n\n```bash\nbun scripts\u002Fagent-lifecycle-audit.ts\nbun scripts\u002Flifecycle-sync-audit.ts\n```\n\nThe audit now enforces the reference sweep mechanically: Check 13 fails on dangling `handoff_to`\u002F`handoff_from` references to the fired agent, and the skill-disposition checks fail on any skill left with the fired agent as sole (or now-nonexistent) `owner:`. Confirm both in the audit output — these are no longer prose-only checks.\n\n---\n\n## Skill Attach\u002FDetach Rules\n\nSkill-to-agent binding lives in the skill frontmatter `owner:` field. Keep both surfaces consistent — the skill's `owner:` and the agent's own capability descriptions must tell the same story.\n\n- **Attach**: add the agent name to `owner:` (space-delimited or list per existing notation in that file). Do not remove the previous owner unless the capability moves entirely.\n- **Detach**: remove the agent from `owner:` only when another owner remains or the skill is routed to deprecation (never leave `owner:` empty).\n- **Multi-owner**: allowed — record the primary owner first; each owner must actually dispatch the skill in its workflow, otherwise use a one-off reference instead.\n- **Consistency check**: after any attach\u002Fdetach, grep both directions — the skill's `owner:` list and the agent definition's tool\u002Fskill sections — and fix drift before validation.\n\n---\n\n\n## Expected Outputs\n\n- Properly formatted agent `.md` file in the `agents\u002F` directory.\n- Clean run of `agent-lifecycle-audit.ts` with 0 errors or warnings.\n- Updated `AGENTS.md` reflecting the new or modified agent state.\n- For hiring: decision record + registered roster row + attached skill package.\n- For firing: decision record + deprecated status (or clean delete) + completed skill disposition plan.\n\n---\n\n## Related Skills\n\n- **skill-lifecycle-manager**: Manages skill creation, validation, agent skill requests (Step R1–R3), and skill deprecation\u002Fremoval.\n- **team-builder**: Whole-team restructuring (benchmarking, bulk create\u002Fconvert\u002Fdelete with skill transfer) — use for team-scale changes, not single-agent hire\u002Ffire.\n",{"name":5,"owner":23,"scope":24,"status":25,"version":26,"metadata":27,"relates_to":38,"description":42,"last_reviewed":43},"pm","common","active","1.4.0",{"type":28,"triggers":29},"process",[30,31,32,33,34,35,36,37],"create agent","new agent","validate agents","agent lifecycle","manage agents","hire agent","fire agent","deprecate agent",[39],{"type":40,"skill":41},"composes_with","skill-lifecycle-manager","Manages the creation, validation, and maintenance of AI agent files across the project, including PM-led hiring (creation) and firing (deprecation\u002Fremoval) of agents with their skill packages. Use when: creating new agents, hiring or firing agents, updating agent metadata\u002Ffrontmatter, validating agent structures, attaching or detaching skills to agents, or managing agent roles and 3-tier configurations.\n",1793923200000,"main","1162ccc568cf90c01b3886d6143cbfd851a37883","templates\u002Fco-safety\u002F.hermes\u002Fskills\u002Fagent-lifecycle-manager",9,"https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards","https:\u002F\u002Fgithub.com\u002F5throck","Experienced in digital transformation, enterprise IT, startup acceleration, and business strategy. Focused on building practical systems that connect technolo","2026-11-14 21:22:34",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add 5throck\u002Fai-workspace-standards --skill agent-lifecycle-manager",{"tool":58,"command":59},"bunx","bunx skills add 5throck\u002Fai-workspace-standards --skill agent-lifecycle-manager",{"tool":61,"command":62},"pnpm","pnpm dlx skills add 5throck\u002Fai-workspace-standards --skill agent-lifecycle-manager","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-safety\u002F.hermes\u002Fskills\u002Fagent-lifecycle-manager\u002FSKILL.md",true,[],[67,75,80,85,90,95],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":74},"01M7BBJDYHJMGTJYSC37JVWY8S","i18n-layout","Text layout and encoding guidance: character encoding (UTF-8, legacy Korean code pages, BOM hazards), line endings, RTL\u002Fbidi handling, and script-specific font selection (Hangul focus). Use when: encoding is corrupted or mojibake appears, an RTL locale must render correctly, fonts must be chosen for a script, or CRLF\u002FBOM issues surface.","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[],"2026-11-15 14:19:17",{"skillNo":76,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":74},"01M7BBJ9XHAAS1AVGKZZ841VBZ","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002F.hermes\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[],{"skillNo":81,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":74},"01M7BBJ5C3X8TKFKG5R9P9P49W","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002F.gemini\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[],{"skillNo":86,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":74},"01M7BBJ1B52X0QMJ2QVBMPJB37","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002F.codex\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[],{"skillNo":91,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":74},"01M7BBHX91BW2Q2R276MRX5AW3","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002F.claude\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[],{"skillNo":96,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":74},"01M7BBHQWGXPSFRWN1PRC2NMMV","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-work\u002F.agents\u002Fskills\u002Fi18n-layout\u002FSKILL.md",[],[]]