description: Maintain and update an existing Portable Identity Document (PID) by scanning user-approved local files, emails, transcripts, calendars, databases, exports, and other digital activity over a chosen timeframe. Use this skill when a user wants an AI agent to discover recent accomplishments, learnings, projects, relationships, needs, assets, proof of work, insights, and other signals; draft a reviewable PID update file; incorporate user edits; and append approved updates to the user's PID in Google Docs, Microsoft Word/OneDrive, Markdown, PDF/source file, repository, or another accessible format.
---
# PID Update Maintenance Skill
## Purpose
Help a user keep an existing Portable Identity Document current with minimal manual effort.
People will not manually maintain rich PID profiles indefinitely. Each week they learn things, complete projects, build relationships, create content, solve problems, make decisions, discover tools, attend meetings, and develop new needs or offers that may be valuable signals to others. This skill delegates the ongoing observation, summarization, categorization, and update-drafting work to an AI agent while preserving human review and control.
The agent should look for meaningful change across user-approved sources, draft a local Markdown review file organized by the user's current PID structure, invite the user to edit that draft, learn from those edits when asked, and only then append approved updates to the PID.
The companion file is intentionally separate from the main skill so users can customize the maintenance workflow without editing the core skill. The main skill may be updated by maintainers over time; the user variables file should persist across main-skill updates.
Treat the companion file as configuration, not as permission to bypass the main contract. If the companion file conflicts with the main skill, follow the stricter privacy, source-boundary, evidence, and review-gate rule unless the user explicitly approves otherwise.
- It will look for and read `PID-update-maintenance-skill-user-variables.md` beside this skill when present, then use it to prefill intake, defaults, source lists, privacy boundaries, and user-specific adjustments.
- It will ask the user to explicitly list every data source location, account, connector, export, folder, repository, and cloud document set authorized for review; the PID repo or PID file location is never assumed to be the activity source unless the user says so.
- It will respect the requested timeframe, defaulting to the last 7 days when no timeframe is provided.
- It will create a local Markdown draft before changing the PID.
- It will organize findings according to the user's actual PID structure when readable, falling back to the standard PID template sections when needed.
- It will distinguish sourced facts, reasonable inferences, and user-review questions.
- It will surface small but meaningful signals, not only major achievements.
- It will preserve privacy and avoid publishing sensitive data unless explicitly approved.
- It will not update, overwrite, publish, email, or share the PID without user confirmation after review.
- It will produce a run receipt documenting inputs, outputs, validations, and unresolved risks.
- It will ratchet lessons from user edits into improved instructions when the user asks the agent to adjust the skill.
## Skill Shape
`system`
This skill coordinates intake, source review, signal extraction, categorization, user review, final PID update, validation, and skill-improvement feedback.
## Requires
This skill requires:
- A user-provided link or path to the current PID.
- User authorization for each source category reviewed.
- A date range or timeframe, or permission to use the default weekly window.
- Ability to read at least one source of recent activity.
- Ability to create a local Markdown draft for review.
- Explicit user approval before modifying the PID.
If the PID is inaccessible, ask the user for an export, local copy, pasted text, or connector access. Do not infer the PID structure from memory alone.
If `PID-update-maintenance-skill-user-variables.md` exists, read it before asking intake questions. Use it to reduce repeated questions, but still ask the user to confirm missing, stale, risky, or ambiguous variables before scanning sources or editing a PID.
- CLI tools: useful for local file discovery, date filtering, Git history, and source inventory.
- MCP/connectors: optional but recommended for Gmail, Google Calendar, Google Drive, Google Docs, OneDrive, databases, and other external systems.
- Browser access: optional; use only for user-approved web-accessible PIDs or publication checks.
- Filesystem access: required for local source scanning and Markdown draft output unless the user works entirely through connectors.
- Network access: optional; use only for user-approved cloud documents, repositories, or web sources.
- Subagent support: optional for large source reviews or reviewer-panel passes.
- Document/spreadsheet/PDF support: useful when the PID or sources are Word, Sheets, Excel, PDF, or exported reports.
If a required capability is unavailable, stop or narrow the workflow. Do not pretend to have reviewed inaccessible sources.
## State Scope
`project`
Persistent writes:
- local review draft
- optional source map
- optional open questions file
- optional run receipt
- approved PID update when the user confirms publication
Do not write long-term user memory or update the skill itself unless the user explicitly asks the agent to preserve a recurring preference or adjust the skill.
## Host Primitive Adapter
Map abstract workflow needs to available host actions:
List every authorized source explicitly. Do not assume the PID repo, the folder containing the PID, the current workspace, or recently modified nearby files are approved activity sources unless the user names them. Ask for exact local paths, cloud locations, connector scopes, account labels, export files, repositories, or date-bounded queries for each source category.
Agent response to human when PID update review draft is complete: This is a draft for your review before anything is added to your Portable Identity Document (PID).
- add missing context, links, examples, names, or proof
- mark private items that should be removed or generalized
- strengthen anything that feels too vague or too narrow
After you edit this draft, ask the agent to continue from your revised file and update your PID.
If your edits reveal a recurring preference, missing category, privacy rule, source type, or better way to describe your work, ask the agent to adjust the PID update maintenance skill so future runs improve.
```
## PID Section Mapping
First read the user's current PID and infer its headings. Preserve the user's structure when appending updates.
If the PID cannot be read or has no clear structure, use the standard PID sections:
This list is based on the pid-template.md file. That file may evolve to a different structure. Make sure the user has given the AI access to the latest version of this file.
1. Look for `PID-update-maintenance-skill-user-variables.md` beside this skill. If present, read it and extract defaults, approved sources, privacy boundaries, output preferences, and user-specific adjustments.
2. Ask for or confirm the current PID path/link and format.
3. Ask for or confirm the timeframe. Use the user variables default when present; otherwise use the last 7 days if the user says weekly or gives no range.
4. Ask the user to list or confirm every approved source location and access method, including local PC paths, cloud folders/connectors, email accounts or labels, calendars, meeting transcript folders, chat exports, repositories, databases, spreadsheets, and publishing/content systems. Do not infer sources from the PID path, current repo, cwd, or neighboring folders.
5. Ask for or confirm privacy boundaries.
6. Ask where to save the local review draft if not specified in user variables.
Stop if the user has not authorized at least one explicit source location, connector scope, account label, export file, repository, or bounded query to review.
4. Do not read sources outside the user's explicitly listed locations, connectors, accounts, repositories, exports, or bounded queries, even if they are near the PID file or appear recently modified.
Ask the user to review and edit the Markdown file. Do not update the PID yet.
Continue only when the user explicitly says the draft is ready, approved, or provides the revised file.
### Phase 8: Incorporate User Edits
1. Read the edited review draft.
2. Treat user edits as authoritative.
3. Remove rejected items.
4. Generalize private items.
5. Strengthen items the user expanded.
6. Identify any preference that should improve future skill runs.
If the user's edits imply a recurring rule, ask whether to update the skill or add that rule to a local preference note.
### Phase 9: Update The PID
Update method depends on format:
- Google Doc: use the Google Drive/Docs connector when available, or prepare copy-ready Markdown.
- Microsoft Word/OneDrive: edit a local `.docx` or prepare copy-ready content for OneDrive when direct connector access is unavailable.
- Markdown: append or merge directly into the appropriate sections.
- PDF: update the source document first when possible; avoid editing the PDF as the canonical source unless the user confirms it is the source of truth.
- Website/repo: update the source Markdown/data files, not only the generated site.
- Unknown or locked format: provide copy-ready approved update text.
Append to existing sections rather than rewriting the entire PID unless the user requests restructuring.
### Phase 10: Validate And Receipt
Before finishing:
1. Re-read the changed PID when possible.
2. Confirm approved updates appear in the intended sections.
3. Confirm rejected/private items were not included.
4. Confirm the Update Log includes the timeframe and date.
5. Confirm no unsupported inference was promoted to fact.
6. Write or update the run receipt.
## Validation
Structural validation:
- [ ] Current PID was read or fallback limitation was disclosed.
- [ ] Review draft was created before PID update.
- [ ] Draft used the user's PID structure or standard fallback.
- [ ] Every proposed update has section placement.
- [ ] Final PID update only happened after user approval.
Evidence validation:
- [ ] Every fact has source evidence.
- [ ] Every inference is labeled.
- [ ] Every low-confidence item is either excluded or turned into a question.
- [ ] Source limits and skipped sources are recorded.
Privacy validation:
- [ ] Privacy boundaries were collected.
- [ ] Sensitive identifiers were excluded or generalized.
- [ ] Private client, employer, family, health, legal, financial, or confidential project details were not published without approval.
- [ ] Draft includes privacy notes where needed.
Quality validation:
- [ ] Small learnings, improvements, and aha moments were considered.
- [ ] Needs and offers were both reviewed.
- [ ] Possible match implications were surfaced.
- [ ] Generic language was replaced with concrete signals where possible.
- intake captured PID location, timeframe, privacy boundaries, and at least one explicit approved source location/account/connector/export/repository/query; PID folder/source assumptions are not acceptable
For serious use, leave a durable, inspectable receipt. Treat the receipt as the replay/audit record for the skill run, not merely a human-readable final summary.
The receipt should let a future agent answer:
- what skill ran
- under what version/context it ran
- what timeframe was reviewed
- what sources were authorized
- what sources were used, skipped, unavailable, or intentionally excluded
- assumptions made
- capabilities used
- tool calls or commands executed
- external state changed
- outputs produced
- validations run
- failures found
- fixes applied
- user review status
- PID update status
- ratchet artifacts added or suggested
- unresolved risks
- follow-up recommendations
- how the run could be resumed, audited, forked, or repeated
If the receipt is compacted into a final response, preserve the full receipt as a file, JSON artifact, test log, or run directory whenever the workflow is important. A final-response summary is a projection of the receipt; it is not the receipt itself.
Use this Markdown structure when writing `PID-update-run-receipt-[YYYY-MM-DD].md`:
The run receipt is for future agents, auditors, and maintainers.
Do not rely on the final response as the only record when files were created, source materials were interpreted, validations were run, validations were skipped, privacy decisions were made, failures were discovered, the PID was modified, or ratchet artifacts were added or suggested.
First create a local Markdown review draft organized by my PID sections. Do not update the PID until I review and approve the draft.
```
## One-Sentence Version
Scan user-approved recent activity, extract grounded identity signals, draft them into the user's PID structure for human review, then append approved updates so the PID stays fresh, specific, and useful for AI-native matching.
