added
This commit is contained in:
parent
62b2ea5a43
commit
d93487f69f
|
|
@ -1,3 +1,5 @@
|
|||
66/15/26: added pid_maturity-model-roadmap, adjustments to the pid-template, added pid-initial-creation-skill.md. refer to this task file for more information: C:\projects\indx\portable-identity-document-template-OPEN\tasks\2026-06-15-pid-repo-development.md
|
||||
|
||||
6/2/26: added to PID section "Stop Beating Our Chests For Attention" and "Applied Knowledge & Recommendations"
|
||||
|
||||
5/20/26: Added: ## Caution About Asking AI To Enhance Your PID From The Web Try to be you and capture you in your PID. You can grab ideas from others and from research. But if you ask AI to make your PID for you - AI-generated - then without sufficient direction from you, it will chose to create something that is less unique and begins to look more like what it finds across the Internet, which is becoming flooded with AI-generated content that tends to become homogenized. You must be the creator and architect and use AI to help you, but don't let it do it for you.
|
||||
|
|
|
|||
3
FLOWS.md
Normal file
3
FLOWS.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
This document is for the repo administrator to help understand what needs to be adjusted where when documents are changed.
|
||||
|
||||
1. C:\projects\indx\portable-identity-document-template-OPEN\skills\PID-initial-creation-skill.md contains PID-template structure. Upate it if the C:\projects\indx\portable-identity-document-template-OPEN\PID-template.md file changes.
|
||||
|
|
@ -1,5 +1,4 @@
|
|||
# PID Maturity Model & Roadmap
|
||||
## From Resume to Agent-Native Identity
|
||||
# **PID Maturity Model & Roadmap**
|
||||
|
||||
# Overview
|
||||
|
||||
|
|
|
|||
942
skills/PID-initial-creation-skill.md
Normal file
942
skills/PID-initial-creation-skill.md
Normal file
|
|
@ -0,0 +1,942 @@
|
|||
---
|
||||
name: pid-initial-creation
|
||||
description: Create a person's initial Portable Identity Document (PID) from gathered source materials using the PID template structure. Use this skill when a user wants to generate a first PID from resumes, LinkedIn profiles, bios, project notes, personality tests, websites, social posts, portfolio materials, or other reference documents.
|
||||
version: 1.0
|
||||
status: draft
|
||||
intended_hosts:
|
||||
- Claude Desktop
|
||||
- Codex Desktop
|
||||
- ChatGPT with file/context access
|
||||
- other local or cloud AI agent apps
|
||||
---
|
||||
|
||||
# PID Initial Creation Skill
|
||||
|
||||
## Purpose
|
||||
|
||||
This skill creates a person's first **Portable Identity Document (PID)** from materials they gather and provide.
|
||||
|
||||
The goal is not to create a traditional resume. The goal is to create a rich, AI-readable, human-reviewable identity document that helps AI systems understand:
|
||||
|
||||
- who the person is
|
||||
- what they know
|
||||
- what they have done
|
||||
- what they are currently focused on
|
||||
- what they need
|
||||
- what they can help others with
|
||||
- what makes them distinctive
|
||||
- what opportunities, collaborators, ideas, and resources may be relevant to them
|
||||
|
||||
This skill should produce a draft PID in the flow of the PID template while preserving the person's authentic voice, experience, values, interests, and intentions.
|
||||
|
||||
---
|
||||
|
||||
# Contract
|
||||
|
||||
This skill guarantees:
|
||||
|
||||
- It will create a complete first-draft PID using the standard PID template flow.
|
||||
- It will use only the user's provided materials and clearly marked user statements unless the user explicitly asks for outside research.
|
||||
- It will not invent credentials, achievements, affiliations, projects, relationships, or claims.
|
||||
- It will identify gaps, uncertainties, and places where the user should add more detail.
|
||||
- It will preserve the user's authentic signal rather than turning them into generic AI-generated professional language.
|
||||
- It will include privacy cautions and avoid sensitive identifiers.
|
||||
- It will produce a reviewable Markdown PID draft.
|
||||
- It will produce a separate improvement checklist for the user.
|
||||
- It will include customization prompts where the user may adapt the PID for their own goals.
|
||||
|
||||
---
|
||||
|
||||
# Inputs
|
||||
|
||||
The skill expects as many of the following as the user can provide.
|
||||
|
||||
## Required
|
||||
|
||||
- The current PID template.
|
||||
- At least one source of personal/professional information.
|
||||
|
||||
## Recommended Source Materials
|
||||
|
||||
The user may provide:
|
||||
|
||||
- resume
|
||||
- LinkedIn profile export or pasted profile text
|
||||
- short bio
|
||||
- long bio
|
||||
- personal website text
|
||||
- company website text
|
||||
- project notes
|
||||
- portfolio materials
|
||||
- case studies
|
||||
- writing samples
|
||||
- social posts
|
||||
- newsletters
|
||||
- podcast appearances
|
||||
- presentation abstracts
|
||||
- business descriptions
|
||||
- product/service descriptions
|
||||
- personality test results
|
||||
- strengths assessments
|
||||
- values exercises
|
||||
- testimonials
|
||||
- endorsements
|
||||
- publications
|
||||
- education history
|
||||
- certifications
|
||||
- affiliations
|
||||
- event participation
|
||||
- personal notes about current goals
|
||||
- list of what they need
|
||||
- list of what they can offer
|
||||
- list of things they want AI agents to discover about them
|
||||
|
||||
## Optional User Direction
|
||||
|
||||
Ask the user to provide short answers to these questions if source materials are thin:
|
||||
|
||||
1. What do you want to be found for?
|
||||
2. What kinds of people or opportunities do you want to attract?
|
||||
3. What are you open to right now?
|
||||
4. What are you currently working on?
|
||||
5. What do you need help with?
|
||||
6. What can you help others with?
|
||||
7. What makes your approach different?
|
||||
8. What should AI systems not misunderstand about you?
|
||||
9. What should not be included publicly?
|
||||
10. What tone should the PID use: straightforward, warm, technical, entrepreneurial, creative, academic, executive, or other?
|
||||
|
||||
---
|
||||
|
||||
# Outputs
|
||||
|
||||
This skill produces:
|
||||
|
||||
## Primary Output
|
||||
|
||||
- `PID-draft.md`
|
||||
|
||||
A complete first-draft Portable Identity Document in Markdown using the PID template flow.
|
||||
|
||||
## Secondary Output
|
||||
|
||||
- `PID-review-checklist.md`
|
||||
|
||||
A checklist of:
|
||||
|
||||
- missing information
|
||||
- unclear claims
|
||||
- generic language to improve
|
||||
- unsupported claims to verify
|
||||
- privacy items to review
|
||||
- suggested user edits
|
||||
- sections that need more specificity
|
||||
- optional customizations based on the user's goals
|
||||
|
||||
## Optional Output
|
||||
|
||||
If the user requests structured data or the host supports writing multiple files, produce:
|
||||
|
||||
- `PID-source-map.md` — maps PID claims back to source materials
|
||||
- `PID-open-questions.md` — questions the user should answer before publishing
|
||||
- `PID-publication-notes.md` — guidance for publishing via Google Drive, OneDrive, GitHub, PDF, or personal website
|
||||
|
||||
---
|
||||
|
||||
# Skill Shape
|
||||
|
||||
`service`
|
||||
|
||||
This is one bounded workflow with clear inputs and outputs.
|
||||
|
||||
It may optionally use a lightweight `reviewer-panel` pattern if the host supports subagents or multiple review passes.
|
||||
|
||||
---
|
||||
|
||||
# Requires
|
||||
|
||||
This skill requires:
|
||||
|
||||
- access to the PID template
|
||||
- access to the user's provided source materials
|
||||
- ability to read text files or pasted text
|
||||
- ability to write a Markdown output file or provide Markdown text
|
||||
- ability to ask clarifying questions when essential information is missing
|
||||
|
||||
If the host cannot read attachments, ask the user to paste the materials or provide accessible text.
|
||||
|
||||
---
|
||||
|
||||
# Ensures
|
||||
|
||||
Before finishing, this skill ensures:
|
||||
|
||||
- all standard PID sections are present
|
||||
- unsupported claims are removed or marked for user verification
|
||||
- sensitive details are excluded or flagged
|
||||
- generic resume language is reduced
|
||||
- the PID contains concrete capabilities, assets, needs, proof, and match context
|
||||
- the output is organized for AI comprehension and human review
|
||||
- the final answer tells the user what was produced and what still needs review
|
||||
|
||||
---
|
||||
|
||||
# Capabilities
|
||||
|
||||
Required host capabilities:
|
||||
|
||||
- CLI tools: optional
|
||||
- MCP/connectors: optional
|
||||
- browser access: optional; use only if user explicitly requests public web enrichment
|
||||
- filesystem access: recommended for reading source documents and writing outputs
|
||||
- network access: optional
|
||||
- subagent support: optional
|
||||
- image/document/spreadsheet support: useful but not required
|
||||
|
||||
If a required capability is unavailable, fail closed or ask the user for another format. Do not silently pretend to have read unavailable materials.
|
||||
|
||||
---
|
||||
|
||||
# State Scope
|
||||
|
||||
`project`
|
||||
|
||||
Persistent writes, if available:
|
||||
|
||||
- `PID-draft.md`
|
||||
- `PID-review-checklist.md`
|
||||
- optional source map and open questions files
|
||||
|
||||
Do not update long-term user memory unless the user explicitly asks.
|
||||
|
||||
---
|
||||
|
||||
# Host Primitive Adapter
|
||||
|
||||
Map abstract needs to available host actions:
|
||||
|
||||
- spawn subagent: optional; use reviewer personas if available
|
||||
- ask user: ask only when missing information blocks a useful draft
|
||||
- read/write files: read user materials and write Markdown outputs when possible
|
||||
- run shell command: optional; not normally required
|
||||
- use browser: only if user asks for web enrichment or public source verification
|
||||
- use connector: optional for Google Drive, OneDrive, GitHub, or local files
|
||||
- create durable report: required if file writing is available
|
||||
|
||||
If the host cannot create files, output Markdown content directly and tell the user to save it.
|
||||
|
||||
---
|
||||
|
||||
# Customization Points
|
||||
|
||||
This is a general-purpose PID creation skill. Users may customize it for their own needs.
|
||||
|
||||
## Customize Audience
|
||||
|
||||
The user may tune the PID toward:
|
||||
|
||||
- hiring
|
||||
- being hired
|
||||
- partnerships
|
||||
- investor discovery
|
||||
- advisory work
|
||||
- project collaborators
|
||||
- local community building
|
||||
- industry networking
|
||||
- research collaboration
|
||||
- creator/media visibility
|
||||
- AI-agent matchmaking
|
||||
- NetworkSIG participation
|
||||
|
||||
## Customize Domain
|
||||
|
||||
The user may add domain-specific language; for example:
|
||||
|
||||
- outdoor industry
|
||||
- paddlesports
|
||||
- software
|
||||
- AI
|
||||
- manufacturing
|
||||
- education
|
||||
- finance
|
||||
- energy
|
||||
- agriculture
|
||||
- local services
|
||||
- consulting
|
||||
- creative work
|
||||
- nonprofit work
|
||||
- public lands/conservation
|
||||
- pet/dog training
|
||||
- any other field
|
||||
|
||||
## Customize Privacy
|
||||
|
||||
The user may set rules such as:
|
||||
|
||||
- do not include employer names
|
||||
- do not include client names
|
||||
- do not include revenue numbers
|
||||
- do not include family details
|
||||
- do not include health information
|
||||
- do not include exact street address
|
||||
- do not include private projects
|
||||
- summarize sensitive work at a high level
|
||||
|
||||
## Customize Tone
|
||||
|
||||
The user may request:
|
||||
|
||||
- concise
|
||||
- warm
|
||||
- executive
|
||||
- technical
|
||||
- entrepreneurial
|
||||
- plainspoken
|
||||
- academic
|
||||
- creative
|
||||
- community-oriented
|
||||
- highly detailed
|
||||
- minimally promotional
|
||||
|
||||
## Customize Publication Target
|
||||
|
||||
The user may indicate where the PID will live:
|
||||
|
||||
- Google Doc
|
||||
- Microsoft OneDrive Word document
|
||||
- public Github Markdown file
|
||||
- PDF hosted in cloud storage
|
||||
- personal website
|
||||
- advanced PID repo (see pid-maturity-model-roadmap.md)
|
||||
|
||||
---
|
||||
|
||||
# Workflow
|
||||
|
||||
## Phase 1: Intake And Source Inventory
|
||||
|
||||
1. List all source materials provided.
|
||||
2. Identify the type of each source:
|
||||
- resume
|
||||
- profile
|
||||
- bio
|
||||
- project notes
|
||||
- social posts
|
||||
- personality tests
|
||||
- portfolio
|
||||
- website
|
||||
- other
|
||||
3. Determine whether source materials are sufficient to create a useful first draft.
|
||||
4. If materials are too thin, ask only the most essential missing questions.
|
||||
|
||||
Completion criteria:
|
||||
|
||||
- sources are known
|
||||
- missing material is identified
|
||||
- privacy risks are noted
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Extract Raw Identity Signals
|
||||
|
||||
Extract information into these buckets:
|
||||
|
||||
- open-to categories
|
||||
- skills and expertise
|
||||
- tools and technologies
|
||||
- relationships and networks
|
||||
- data/content assets
|
||||
- physical assets
|
||||
- platforms and systems
|
||||
- capital/access
|
||||
- products and services
|
||||
- immediate needs
|
||||
- strategic needs
|
||||
- constraints and gaps
|
||||
- current projects
|
||||
- experiments
|
||||
- research
|
||||
- business initiatives
|
||||
- interests
|
||||
- industries
|
||||
- technologies
|
||||
- problems
|
||||
- curiosities
|
||||
- experience
|
||||
- education
|
||||
- affiliations
|
||||
- credibility signals
|
||||
- values
|
||||
- principles
|
||||
- strengths
|
||||
- weaknesses/blind spots
|
||||
- energy patterns
|
||||
- work style
|
||||
- superpowers
|
||||
- builds
|
||||
- results
|
||||
- experiments
|
||||
- case studies
|
||||
- artifacts
|
||||
- additional signals
|
||||
- ideal collaborators
|
||||
- ideal problems
|
||||
- non-ideal matches
|
||||
- recent updates
|
||||
|
||||
Completion criteria:
|
||||
|
||||
- each relevant signal is captured
|
||||
- uncertain signals are marked as uncertain
|
||||
- no unsupported claim is promoted as fact
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Create AI-Distinctive Identity Layer
|
||||
|
||||
Improve machine-legibility by identifying:
|
||||
|
||||
1. Clear category anchoring
|
||||
2. Differentiation statement
|
||||
3. Named systems, methods, or frameworks
|
||||
4. Vocabulary ownership
|
||||
5. Explicit capabilities
|
||||
6. Inputs → transformation → outputs
|
||||
7. Audience and use-case specificity
|
||||
8. Memorable concept hooks
|
||||
9. Generic language to replace
|
||||
|
||||
Do not over-polish. The goal is distinctive signal, not generic professional branding.
|
||||
|
||||
Completion criteria:
|
||||
|
||||
- the PID contains clear category anchoring
|
||||
- the PID includes at least one differentiation statement or flags that the user must supply one
|
||||
- the PID avoids generic claims wherever possible
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Draft The PID In Template Flow
|
||||
|
||||
Create `PID-draft.md` using this structure:
|
||||
|
||||
```md
|
||||
# Portable Identity Document: [Person Name]
|
||||
|
||||
## Overview
|
||||
|
||||
## Privacy And Publication Notes
|
||||
|
||||
# 1. Open To
|
||||
|
||||
# 2. What I Have
|
||||
|
||||
# 3. What I Need
|
||||
|
||||
# 4. Current Focus
|
||||
|
||||
# 5. Interests, Passions, Talents
|
||||
|
||||
# 6. History
|
||||
|
||||
# 7. Credibility
|
||||
|
||||
# 8. Identity Layer
|
||||
|
||||
# 9. Proof Of Work
|
||||
|
||||
# Additional Signals
|
||||
|
||||
# Match Context
|
||||
|
||||
# Update Log
|
||||
|
||||
# Appendix / Open Questions
|
||||
|
||||
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.
|
||||
```
|
||||
|
||||
If the person's name is not provided, use:
|
||||
|
||||
```md
|
||||
# Portable Identity Document
|
||||
```
|
||||
|
||||
Do not fabricate a name.
|
||||
|
||||
Completion criteria:
|
||||
|
||||
- all PID sections exist
|
||||
- weak sections include useful prompts rather than invented filler
|
||||
- the draft is coherent and ready for human review
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Add Review Prompts Inside The PID
|
||||
|
||||
Where appropriate, insert short prompts such as:
|
||||
|
||||
```md
|
||||
[USER REVIEW: Confirm whether this is accurate.]
|
||||
```
|
||||
|
||||
```md
|
||||
[USER ADD: Add examples, links, or proof.]
|
||||
```
|
||||
|
||||
```md
|
||||
[USER DECIDE: Keep this public, summarize it, or remove it.]
|
||||
```
|
||||
|
||||
```md
|
||||
[USER CUSTOMIZE: Adjust this section for your specific goals.]
|
||||
```
|
||||
|
||||
Use these sparingly. The PID should be readable, not cluttered.
|
||||
|
||||
Completion criteria:
|
||||
|
||||
- important uncertainty is visible
|
||||
- user knows where to refine
|
||||
- the draft does not pretend to be final
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: Privacy And Sensitivity Review
|
||||
|
||||
Review the PID for:
|
||||
|
||||
- exact home address
|
||||
- phone numbers
|
||||
- personal identifiers
|
||||
- private client details
|
||||
- private employer information
|
||||
- family details
|
||||
- health information
|
||||
- financial details
|
||||
- legal issues
|
||||
- confidential business information
|
||||
- private project details
|
||||
- anything the user explicitly marked private
|
||||
|
||||
If found, either remove, generalize, or flag.
|
||||
|
||||
Examples:
|
||||
|
||||
- Replace exact street address with City/State/Country.
|
||||
- Replace client names with industry or category.
|
||||
- Replace revenue numbers with ranges or qualitative descriptions if appropriate.
|
||||
- Remove sensitive personal details unless explicitly approved.
|
||||
|
||||
Completion criteria:
|
||||
|
||||
- the PID is suitable for public URL sharing, subject to user review
|
||||
- sensitive items are not accidentally included
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Reviewer Panel
|
||||
|
||||
If subagents or multiple review passes are available, run a lightweight reviewer panel.
|
||||
|
||||
Use these personas:
|
||||
|
||||
## Designer
|
||||
|
||||
Reviews:
|
||||
|
||||
- readability
|
||||
- document flow
|
||||
- clarity
|
||||
- tone
|
||||
- human usability
|
||||
|
||||
## Architect
|
||||
|
||||
Reviews:
|
||||
|
||||
- structure
|
||||
- section separation
|
||||
- future migration to repo/data files
|
||||
- machine readability
|
||||
|
||||
## Domain Expert
|
||||
|
||||
Reviews:
|
||||
|
||||
- whether the person's domain positioning is specific
|
||||
- whether jargon is appropriate
|
||||
- whether capabilities and proof are credible
|
||||
|
||||
## Human Advocate
|
||||
|
||||
Reviews:
|
||||
|
||||
- authenticity
|
||||
- privacy
|
||||
- user agency
|
||||
- over-polishing
|
||||
- whether the person still sounds like a real person
|
||||
|
||||
## Performance Expert
|
||||
|
||||
Reviews:
|
||||
|
||||
- retrieval usefulness
|
||||
- whether agents can quickly identify needs, offers, capabilities, proof, and match context
|
||||
|
||||
## Code Expert
|
||||
|
||||
Normally not required for a Level 1 PID. Use only if the PID includes structured JSON, GitHub repo setup, scripts, or technical publication requirements.
|
||||
|
||||
Completion criteria:
|
||||
|
||||
- reviewer issues are either fixed or included in the review checklist
|
||||
|
||||
---
|
||||
|
||||
## Phase 8: Produce Review Checklist
|
||||
|
||||
Create `PID-review-checklist.md` with these sections:
|
||||
|
||||
```md
|
||||
# PID Review Checklist
|
||||
|
||||
## Highest Priority Edits
|
||||
|
||||
## Missing Information
|
||||
|
||||
## Claims To Verify
|
||||
|
||||
## Privacy Items To Review
|
||||
|
||||
## Generic Language To Improve
|
||||
|
||||
## Suggested Specificity Upgrades
|
||||
|
||||
## Suggested Proof Links
|
||||
|
||||
## Suggested Differentiation Improvements
|
||||
|
||||
## Suggested Match Context Improvements
|
||||
|
||||
## Publication Readiness
|
||||
|
||||
## Optional Next-Level Upgrades
|
||||
```
|
||||
|
||||
Completion criteria:
|
||||
|
||||
- the user knows exactly what to edit next
|
||||
- publication risks are clear
|
||||
- next steps are practical
|
||||
|
||||
---
|
||||
|
||||
## Phase 9: Publication Guidance
|
||||
|
||||
At the end of the PID or in `PID-publication-notes.md`, include brief guidance.
|
||||
|
||||
Recommended publication options:
|
||||
|
||||
1. Google Doc with public URL
|
||||
2. Microsoft OneDrive Word document with public URL
|
||||
3. Markdown file in a public GitHub repository
|
||||
4. PDF hosted in cloud storage
|
||||
5. Personal website page
|
||||
6. Advanced PID repository
|
||||
|
||||
Warn:
|
||||
|
||||
- do not share static copies that will go out of date
|
||||
- share the URL to the maintained source
|
||||
- review privacy before making public
|
||||
- update periodically
|
||||
|
||||
Completion criteria:
|
||||
|
||||
- the user understands where to save the PID
|
||||
- the PID is URL-accessible after the user publishes it
|
||||
|
||||
---
|
||||
|
||||
# Validation
|
||||
|
||||
Before finishing, verify:
|
||||
|
||||
## Structural Validation
|
||||
|
||||
- [ ] PID title exists.
|
||||
- [ ] Overview exists.
|
||||
- [ ] Open To exists.
|
||||
- [ ] What I Have exists.
|
||||
- [ ] What I Need exists.
|
||||
- [ ] Current Focus exists.
|
||||
- [ ] Interests, Passions, Talents exists.
|
||||
- [ ] History exists.
|
||||
- [ ] Credibility exists.
|
||||
- [ ] Identity Layer exists.
|
||||
- [ ] Proof Of Work exists.
|
||||
- [ ] Additional Signals exists.
|
||||
- [ ] Match Context exists.
|
||||
- [ ] Update Log exists.
|
||||
- [ ] Open Questions or Review Checklist exists.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
## Faithfulness Validation
|
||||
|
||||
- [ ] No major claim is invented.
|
||||
- [ ] Unsupported claims are flagged.
|
||||
- [ ] The draft does not exaggerate credentials.
|
||||
- [ ] The draft distinguishes facts from inferences.
|
||||
- [ ] The draft preserves the user's actual direction and interests.
|
||||
|
||||
## Specificity Validation
|
||||
|
||||
- [ ] Generic phrases are reduced.
|
||||
- [ ] Capabilities are stated explicitly.
|
||||
- [ ] At least one differentiation statement is present or requested.
|
||||
- [ ] Current focus is concrete.
|
||||
- [ ] Needs are actionable.
|
||||
- [ ] Match context is clear enough for agents to use.
|
||||
|
||||
## Privacy Validation
|
||||
|
||||
- [ ] No sensitive identifiers are included.
|
||||
- [ ] Exact address is not included.
|
||||
- [ ] Private details are removed or flagged.
|
||||
- [ ] Public-readiness warning is included.
|
||||
|
||||
## AI-Usability Validation
|
||||
|
||||
- [ ] Section headings are clear.
|
||||
- [ ] Bullets are used where helpful.
|
||||
- [ ] Needs/offers/capabilities are easy to extract.
|
||||
- [ ] Proof links or artifact prompts are included where needed.
|
||||
- [ ] The document is suitable for future conversion into repo structure or JSON.
|
||||
|
||||
---
|
||||
|
||||
# Test Surface
|
||||
|
||||
This skill can be tested through:
|
||||
|
||||
- Static checks:
|
||||
- required sections exist
|
||||
- output file names are correct
|
||||
- no unresolved placeholders remain except intentional `[USER ...]` review prompts
|
||||
|
||||
- Invariant checks:
|
||||
- no invented claims
|
||||
- no sensitive identifiers
|
||||
- all PID sections appear in the correct order
|
||||
|
||||
- Fixture tests:
|
||||
- resume-only input
|
||||
- LinkedIn-only input
|
||||
- project-notes-only input
|
||||
- sparse input
|
||||
- highly technical input
|
||||
- nontraditional career input
|
||||
- business owner input
|
||||
- student/early-career input
|
||||
- retired/advisory-focused input
|
||||
|
||||
- Behavioral tests:
|
||||
- agent asks for missing essentials when needed
|
||||
- agent does not fabricate information
|
||||
- agent flags uncertainty
|
||||
- agent produces review checklist
|
||||
- agent performs privacy review before finishing
|
||||
|
||||
- LLM-as-judge evals:
|
||||
- authenticity
|
||||
- specificity
|
||||
- usefulness for AI matching
|
||||
- clarity
|
||||
- faithfulness to sources
|
||||
|
||||
---
|
||||
|
||||
# Edge Cases
|
||||
|
||||
Actively handle:
|
||||
|
||||
- user provides only a resume
|
||||
- user provides only scattered notes
|
||||
- user has multiple careers or identities
|
||||
- user has no formal resume
|
||||
- user is early career
|
||||
- user is retired or semi-retired
|
||||
- user is a founder with multiple companies
|
||||
- user has confidential clients
|
||||
- user has sensitive personal history
|
||||
- user wants to be hired but also wants partnerships
|
||||
- user has many interests and no clear focus
|
||||
- user has no obvious proof of work
|
||||
- user uses vague language
|
||||
- source materials contradict each other
|
||||
- source materials are outdated
|
||||
- source materials are overly promotional
|
||||
- source materials contain private information
|
||||
- user wants a highly public PID
|
||||
- user wants a semi-private PID
|
||||
- user plans to migrate to a GitHub PID repo later
|
||||
|
||||
---
|
||||
|
||||
# Ratchet Rules
|
||||
|
||||
When this skill discovers a recurring mistake, ambiguous case, failed validation, or agent shortcut, convert the lesson into at least one durable artifact:
|
||||
|
||||
- updated skill instruction
|
||||
- anti-pattern
|
||||
- example prompt
|
||||
- validation checklist item
|
||||
- privacy rule
|
||||
- source-material intake question
|
||||
- fixture case
|
||||
- output schema requirement
|
||||
- reviewer-panel rule
|
||||
|
||||
Do not merely fix the current PID. Improve the skill so future PID drafts are better.
|
||||
|
||||
Examples:
|
||||
|
||||
- If the agent invents achievements, add a stronger unsupported-claim rule.
|
||||
- If the agent misses privacy risks, add a privacy checklist item.
|
||||
- If the agent creates generic language, add examples of stronger specificity.
|
||||
- If the agent struggles with early-career users, add an early-career fixture.
|
||||
- If users repeatedly omit "What I Need," add intake questions for needs.
|
||||
- If users do not know their differentiation, add a differentiation interview step.
|
||||
|
||||
---
|
||||
|
||||
# Anti-Patterns
|
||||
|
||||
Do not:
|
||||
|
||||
- write a traditional resume
|
||||
- reduce the person to job titles
|
||||
- over-polish the person into generic professional branding
|
||||
- invent claims
|
||||
- invent metrics
|
||||
- invent credentials
|
||||
- invent affiliations
|
||||
- invent current goals
|
||||
- include sensitive identifiers
|
||||
- include exact home address
|
||||
- expose private client names without approval
|
||||
- assume all source materials are current
|
||||
- bury needs and offers in long prose
|
||||
- omit the review checklist
|
||||
- skip privacy review
|
||||
- skip uncertainty flags
|
||||
- create a PID that sounds like everyone else
|
||||
- use vague phrases like "innovative," "hardworking," "detail-oriented," or "customer-focused" without concrete proof
|
||||
- ask AI to make the person sound like internet averages instead of themselves
|
||||
|
||||
---
|
||||
|
||||
# Run Receipt
|
||||
|
||||
For serious use, leave a short run receipt at the end of the final response or in a separate file:
|
||||
|
||||
```md
|
||||
# PID Creation Run Receipt
|
||||
|
||||
## Inputs Used
|
||||
|
||||
## Outputs Produced
|
||||
|
||||
## Sections Completed
|
||||
|
||||
## Sections Needing User Review
|
||||
|
||||
## Privacy Checks Performed
|
||||
|
||||
## Unsupported Claims Removed Or Flagged
|
||||
|
||||
## Validation Results
|
||||
|
||||
## Ratchet Lessons
|
||||
|
||||
## Recommended Next Steps
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Final Report
|
||||
|
||||
When finished, report:
|
||||
|
||||
- what was produced
|
||||
- what source materials were used
|
||||
- what was validated
|
||||
- what still needs user review
|
||||
- whether any sensitive material was removed or flagged
|
||||
- where the user should publish the PID
|
||||
- what optional next-level upgrades are recommended
|
||||
|
||||
Keep the final report concise unless the user asks for detail.
|
||||
|
||||
---
|
||||
|
||||
# Suggested User Prompt
|
||||
|
||||
Users can run this skill with a prompt like:
|
||||
|
||||
```text
|
||||
Use the PID Initial Creation Skill to create my first Portable Identity Document.
|
||||
|
||||
I am providing:
|
||||
1. my source materials
|
||||
2. the PID template
|
||||
3. this skill
|
||||
|
||||
Create:
|
||||
- PID-draft.md
|
||||
- PID-review-checklist.md
|
||||
|
||||
Follow the PID template flow. Do not invent claims. Flag anything uncertain. Remove or flag privacy-sensitive details. Make the PID specific, authentic, and useful for AI agents to understand what I know, what I have, what I need, what I am working on, and what kinds of opportunities or collaborators would be relevant.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Advanced Optional Prompt
|
||||
|
||||
For users who want a stronger first draft:
|
||||
|
||||
```text
|
||||
Before drafting my PID, first extract my raw identity signals into buckets:
|
||||
- skills
|
||||
- assets
|
||||
- needs
|
||||
- current focus
|
||||
- interests
|
||||
- history
|
||||
- credibility
|
||||
- identity layer
|
||||
- proof of work
|
||||
- additional signals
|
||||
- match context
|
||||
|
||||
Then generate the PID draft.
|
||||
|
||||
After drafting, run a review pass for:
|
||||
- specificity
|
||||
- authenticity
|
||||
- privacy
|
||||
- AI findability
|
||||
- missing proof
|
||||
- unsupported claims
|
||||
|
||||
Finally, produce a review checklist and publication notes.
|
||||
```
|
||||
---
|
||||
|
||||
# One-Sentence Version
|
||||
|
||||
Use the person's own materials to create a specific, authentic, privacy-reviewed Portable Identity Document that helps AI agents understand who they are, what they have, what they need, what they are building, and how they should be discovered.
|
||||
584
skills/PID-update-maintenance-skill.md
Normal file
584
skills/PID-update-maintenance-skill.md
Normal file
|
|
@ -0,0 +1,584 @@
|
|||
---
|
||||
name: pid-update-maintenance
|
||||
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.
|
||||
|
||||
## Contract
|
||||
|
||||
This skill guarantees:
|
||||
|
||||
- It will ask for the user's current PID location and format before attempting updates.
|
||||
- It will ask which data sources the user authorizes for review.
|
||||
- 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.
|
||||
|
||||
## Ensures
|
||||
|
||||
Before finishing, this skill ensures:
|
||||
|
||||
- A review draft exists before any PID update.
|
||||
- The user has either approved the draft, or the PID remains unchanged.
|
||||
- Approved updates are placed into the correct PID sections.
|
||||
- Rejected, private, or low-confidence items are excluded or converted into questions.
|
||||
- The final response clearly states whether the PID was updated or is still awaiting review.
|
||||
|
||||
## Capabilities
|
||||
|
||||
Required host capabilities:
|
||||
|
||||
- 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:
|
||||
|
||||
- Ask user: collect PID location, timeframe, source permissions, privacy boundaries, and review approval.
|
||||
- Read files: inspect only approved local folders and source files.
|
||||
- Write files: create local Markdown drafts and receipts.
|
||||
- Run shell commands: list files, inspect modified dates, search text, read Git history, and validate outputs.
|
||||
- Use connector: read or update Gmail, Calendar, Drive, Docs, Sheets, or other approved systems.
|
||||
- Use browser: inspect only approved URLs or public PID publication targets.
|
||||
- Spawn subagent: optional; use for large source reviews or independent privacy/specificity review.
|
||||
- Create durable report: required; at minimum create or provide the review draft and run receipt.
|
||||
|
||||
If the host cannot provide the primitive needed for a requested source or output format, explain the limitation and offer a copy-ready fallback.
|
||||
|
||||
## Recommended Intake Checklist
|
||||
|
||||
At the beginning, ask the user to provide or confirm the following. Keep the intake concise if the user has already supplied some answers.
|
||||
|
||||
```md
|
||||
# PID Update Intake
|
||||
|
||||
## Current PID
|
||||
- PID location or link:
|
||||
- PID format: Google Doc / Word / OneDrive / Markdown / PDF / website / repo / other
|
||||
- Can the agent edit it directly, or should it prepare copy-ready Markdown only?
|
||||
|
||||
## Timeframe
|
||||
- Default: last 7 days
|
||||
- Requested range:
|
||||
|
||||
## Output Location
|
||||
- Folder for local review draft:
|
||||
- Preferred draft filename:
|
||||
|
||||
## Approved Data Sources
|
||||
- Local project folders:
|
||||
- Notes folders:
|
||||
- Documents folders:
|
||||
- Downloads or exports:
|
||||
- Git repositories:
|
||||
- Email accounts or labels:
|
||||
- Calendar events:
|
||||
- Meeting transcripts or recordings converted to text:
|
||||
- Chat logs or collaboration tools:
|
||||
- CRM, database, CSV, JSON, or spreadsheet exports:
|
||||
- Browser bookmarks or reading lists:
|
||||
- Social posts, newsletters, or publishing platforms:
|
||||
- Portfolio, website, or content folders:
|
||||
- Photos, screenshots, design files, or media metadata:
|
||||
- Learning logs, courses, books, papers, saved articles:
|
||||
- Financial, sales, support, product, or analytics exports:
|
||||
- Other source categories:
|
||||
|
||||
## Privacy Boundaries
|
||||
- Never include:
|
||||
- Summarize but do not name:
|
||||
- Ask before including:
|
||||
- Safe to include:
|
||||
|
||||
## Update Goals
|
||||
- What do you want your PID to become easier to find for?
|
||||
- What kinds of people, opportunities, or matches matter right now?
|
||||
- What current needs or offers should be especially visible?
|
||||
- What should AI systems not misunderstand about you?
|
||||
```
|
||||
|
||||
## Outputs
|
||||
|
||||
Primary output:
|
||||
|
||||
- `PID-update-review-draft-[YYYY-MM-DD].md`
|
||||
|
||||
The draft must be local, reviewable, and organized by PID section.
|
||||
|
||||
Secondary outputs when useful:
|
||||
|
||||
- `PID-update-source-map-[YYYY-MM-DD].md` mapping each proposed update to source paths, emails, meetings, or other evidence.
|
||||
- `PID-update-open-questions-[YYYY-MM-DD].md` for uncertain findings that need user answers.
|
||||
- `PID-update-run-receipt-[YYYY-MM-DD].md` recording what happened.
|
||||
|
||||
Final output after approval:
|
||||
|
||||
- An updated PID, or copy-ready approved update text when direct editing is unavailable.
|
||||
|
||||
## Draft Header Requirement
|
||||
|
||||
Every review draft must begin with this instruction block:
|
||||
|
||||
```md
|
||||
# PID Update Review Draft
|
||||
|
||||
This is a draft for your review before anything is added to your Portable Identity Document (PID).
|
||||
|
||||
Please edit freely:
|
||||
- delete anything that should not be included
|
||||
- correct anything inaccurate
|
||||
- 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:
|
||||
|
||||
- Open To
|
||||
- What I Have
|
||||
- What I Need
|
||||
- Current Focus
|
||||
- Interests, Passions, Talents
|
||||
- History
|
||||
- Credibility
|
||||
- Identity Layer
|
||||
- Proof Of Work
|
||||
- Additional Signals
|
||||
- Match Context
|
||||
- Update Log
|
||||
|
||||
## Source Categories To Review
|
||||
|
||||
When authorized, inspect sources for signals in these categories:
|
||||
|
||||
- Local files: documents, notes, working drafts, folders created or modified, exports, PDFs, spreadsheets, presentations.
|
||||
- Project work: repos, commits, issue notes, task files, plans, specs, prototypes, designs, scripts, data pipelines.
|
||||
- Email: sent mail, received threads, introductions, decisions, requests, collaborations, follow-ups, newsletters, opportunities.
|
||||
- Calendar: meetings, events, travel, conferences, workshops, recurring commitments, relationship-building activity.
|
||||
- Meeting records: transcripts, summaries, action items, decisions, objections, insights, stakeholder names.
|
||||
- Chats and collaboration tools: Slack, Teams, Discord, SMS exports, comments, shared docs, decision trails.
|
||||
- Databases and structured exports: CSV, JSON, SQL exports, CRM, support tickets, sales, analytics, product usage, research datasets.
|
||||
- Content and publishing: articles, social posts, newsletters, videos, podcasts, talks, comments, drafts, outlines.
|
||||
- Learning and research: courses, books, papers, saved articles, annotations, experiments, reading notes, aha moments.
|
||||
- Creative and design work: images, decks, sketches, mockups, media files, design artifacts.
|
||||
- Relationships and network: new collaborators, advisors, customers, vendors, communities, referrals, introductions made or received.
|
||||
- Proof and credibility: certifications, testimonials, awards, media mentions, event participation, shipped artifacts, measurable outcomes.
|
||||
- Needs and constraints: blockers, missing resources, requested help, tools needed, funding needs, hiring needs, feedback needs.
|
||||
- Assets and offers: reusable systems, templates, data, content, capabilities, tools, access, audiences, products, services.
|
||||
- Identity signals: values clarified, principles tested, preferred work patterns, strengths, weaknesses, energy patterns.
|
||||
- Match context: ideal collaborators, non-ideal matches, emerging opportunities, who needs what the user has, what the user needs from others.
|
||||
|
||||
## Signal Extraction Heuristics
|
||||
|
||||
Be thorough. Small discoveries matter.
|
||||
|
||||
Look for:
|
||||
|
||||
- created, edited, shipped, published, launched, fixed, automated, cleaned, migrated, organized, analyzed
|
||||
- learned, realized, discovered, reframed, decided, validated, invalidated, changed mind
|
||||
- met, introduced, advised, helped, asked, offered, followed up, partnered
|
||||
- researched, compared, evaluated, recommended, rejected, adopted, stopped using
|
||||
- wrote, recorded, presented, designed, prototyped, tested, documented
|
||||
- solved, debugged, unblocked, improved, simplified, clarified
|
||||
- evidence of recurring interests, emerging vocabulary, named systems, new frameworks, and repeated themes
|
||||
- needs implied by blockers, unanswered questions, stalled work, repeated friction, missing expertise, missing access
|
||||
- offers implied by artifacts, repeated help given, reusable methods, strong opinions, unique data, relationships, domain experience
|
||||
|
||||
Prefer concrete, grounded language over generic praise.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Phase 1: Intake And Permission
|
||||
|
||||
1. Ask for the current PID path/link and format.
|
||||
2. Ask for the timeframe. Use the last 7 days if the user says weekly or gives no range.
|
||||
3. Ask which source categories are approved and where to find them.
|
||||
4. Ask for privacy boundaries.
|
||||
5. Ask where to save the local review draft.
|
||||
|
||||
Stop if the user has not authorized any source review.
|
||||
|
||||
### Phase 2: Read The Current PID
|
||||
|
||||
1. Read the PID from the provided location or connector.
|
||||
2. Identify headings, section order, tone, and current emphasis.
|
||||
3. Identify stale sections, thin sections, repeated vocabulary, open needs, existing offers, and match context.
|
||||
4. Note the PID's publication target and any format constraints.
|
||||
|
||||
Completion criteria:
|
||||
|
||||
- PID structure is known, or fallback structure is selected.
|
||||
- PID privacy posture is understood.
|
||||
|
||||
### Phase 3: Source Inventory
|
||||
|
||||
1. List each approved source.
|
||||
2. Record access method, date range, and scan limits.
|
||||
3. Prefer metadata and targeted searches before reading large corpora.
|
||||
4. Do not read sources outside the user's approved categories.
|
||||
5. Track unreadable or skipped sources in the run receipt.
|
||||
|
||||
Completion criteria:
|
||||
|
||||
- Reviewed sources are explicit.
|
||||
- Skipped sources are explicit.
|
||||
|
||||
### Phase 4: Extract Candidate Signals
|
||||
|
||||
Create raw notes with source references for:
|
||||
|
||||
- accomplishments
|
||||
- projects advanced or completed
|
||||
- problems solved
|
||||
- decisions made
|
||||
- ideas, insights, and aha moments
|
||||
- learnings and recommendations
|
||||
- relationships and introductions
|
||||
- content created or published
|
||||
- tools, systems, templates, datasets, or assets created
|
||||
- proof of work and credibility signals
|
||||
- emerging needs, blockers, constraints, and asks
|
||||
- changed priorities or current focus
|
||||
- match opportunities: who may need what the user has, and who may have what the user needs
|
||||
|
||||
Mark each candidate as:
|
||||
|
||||
- `Fact` when directly supported by a source.
|
||||
- `Inference` when reasoned from evidence.
|
||||
- `Question` when user confirmation is needed.
|
||||
|
||||
### Phase 5: Categorize By PID Structure
|
||||
|
||||
Map candidate signals to the user's PID sections.
|
||||
|
||||
Rules:
|
||||
|
||||
- Put time-bound activity in Update Log.
|
||||
- Put reusable capabilities, systems, assets, data, tools, products, and relationships in What I Have.
|
||||
- Put blockers, asks, desired collaborators, resources, capital, access, feedback, or support in What I Need.
|
||||
- Put active projects, experiments, research, and initiatives in Current Focus.
|
||||
- Put durable interests, curiosities, domains, and recurring questions in Interests, Passions, Talents.
|
||||
- Put shipped artifacts, case studies, builds, results, and evidence in Proof Of Work.
|
||||
- Put endorsements, certifications, events, media, publications, and platform presence in Credibility.
|
||||
- Put values, principles, strengths, weaknesses, work style, and energy patterns in Identity Layer.
|
||||
- Put ideal collaborators, ideal problems, non-ideal matches, and matching guidance in Match Context.
|
||||
- Put observations, frameworks, recommendations, predictions, writing samples, questions, and applied knowledge in Additional Signals.
|
||||
|
||||
Allow the same discovery to appear in more than one section only when each placement adds distinct value.
|
||||
|
||||
### Phase 6: Draft The Review File
|
||||
|
||||
Write `PID-update-review-draft-[YYYY-MM-DD].md`.
|
||||
|
||||
For each section, include:
|
||||
|
||||
- proposed additions
|
||||
- source/evidence note
|
||||
- confidence level
|
||||
- privacy note if relevant
|
||||
- user-review questions
|
||||
|
||||
Suggested item format:
|
||||
|
||||
```md
|
||||
## [PID Section]
|
||||
|
||||
### Proposed Addition
|
||||
- [Fact / Inference / Question] Proposed PID text.
|
||||
- Evidence: [source path, email/thread, meeting title/date, export row, or note]
|
||||
- Confidence: High / Medium / Low
|
||||
- Privacy: Safe / Review / Generalize / Exclude unless approved
|
||||
```
|
||||
|
||||
End the draft with:
|
||||
|
||||
- `Possible Things Others May Need From You`
|
||||
- `Possible People Or Opportunities You May Need`
|
||||
- `Open Questions For You`
|
||||
- `Suggested Skill Improvements Based On This Run`
|
||||
|
||||
### Phase 7: User Review Gate
|
||||
|
||||
Stop after creating the draft.
|
||||
|
||||
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.
|
||||
- [ ] User edits were incorporated faithfully.
|
||||
|
||||
## Test Surface
|
||||
|
||||
This skill can be tested through:
|
||||
|
||||
- Static checks: required sections exist in the draft; draft header exists; run receipt exists.
|
||||
- Invariant checks: no PID update before review approval; every proposed fact has evidence; every inference is labeled.
|
||||
- Fixture tests: weekly local folder scan; email-only scan; meeting-transcript scan; sparse-source scan; large-folder scan; private-client scan; edited-draft continuation.
|
||||
- Behavioral tests: agent asks for PID location, source authorization, timeframe, privacy boundaries, and review approval.
|
||||
- LLM-as-judge evals: whether extracted updates are useful, specific, grounded, privacy-aware, and mapped to PID sections.
|
||||
|
||||
## Edge Cases
|
||||
|
||||
Actively handle:
|
||||
|
||||
- user has no current PID or provides an inaccessible PID
|
||||
- PID is a PDF with no editable source
|
||||
- user approves many folders but no date range
|
||||
- file modified time is misleading because old files were copied
|
||||
- many files changed but few contain meaningful identity signals
|
||||
- email threads contain sensitive personal or business information
|
||||
- meeting transcripts include other people's private statements
|
||||
- source materials contradict the existing PID
|
||||
- user edits the draft heavily
|
||||
- user wants direct publishing but connector access is unavailable
|
||||
- user's PID structure differs from the standard template
|
||||
- the same update belongs to multiple sections
|
||||
- findings are valuable but too speculative
|
||||
- the agent discovers needs the user did not explicitly state
|
||||
- the agent discovers offers the user is undervaluing
|
||||
|
||||
## Ratchet Rules
|
||||
|
||||
When user edits, validation failures, or review discussions reveal a recurring issue, convert it into a durable improvement.
|
||||
|
||||
Possible ratchet artifacts:
|
||||
|
||||
- update this skill's instructions
|
||||
- add a privacy rule
|
||||
- add a new source category to the intake checklist
|
||||
- add a recurring user preference
|
||||
- add an anti-pattern
|
||||
- add a validation checklist item
|
||||
- add a fixture scenario
|
||||
- add a stronger section-mapping rule
|
||||
- add a local source inventory template
|
||||
|
||||
Examples:
|
||||
|
||||
- If the user repeatedly deletes a type of personal information, add it to privacy boundaries for future runs.
|
||||
- If the agent misses a recurring source such as meeting transcripts, add that source category.
|
||||
- If the user rewrites vague accomplishments into measurable proof, add a specificity rule.
|
||||
- If the agent overemphasizes major projects and misses small learnings, strengthen the small-signal extraction heuristic.
|
||||
- If the agent puts needs in Update Log only, add a rule to also consider What I Need and Match Context.
|
||||
|
||||
Do not merely correct the current PID update. Make future runs better.
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
Do not:
|
||||
|
||||
- update the PID before the user reviews the Markdown draft
|
||||
- scan sources the user did not authorize
|
||||
- treat all recent files as meaningful
|
||||
- dump raw private notes into the PID
|
||||
- publish sensitive details because they were found in a source
|
||||
- invent accomplishments, relationships, needs, or proof
|
||||
- hide uncertainty
|
||||
- collapse the update into a resume-style summary
|
||||
- ignore small learnings, aha moments, process improvements, or recommendations
|
||||
- only capture what the user explicitly says they need; infer possible needs and ask for confirmation
|
||||
- only capture what the user explicitly says they offer; infer possible offers and ask for confirmation
|
||||
- overwrite the whole PID when an append would preserve user control
|
||||
- treat PDF editing as canonical when a source document exists
|
||||
- treat user edits as optional suggestions
|
||||
|
||||
## Run Receipt
|
||||
|
||||
Create a receipt in the final response or in `PID-update-run-receipt-[YYYY-MM-DD].md`:
|
||||
|
||||
```md
|
||||
# PID Update Run Receipt
|
||||
|
||||
## Timeframe
|
||||
|
||||
## PID Source
|
||||
|
||||
## Approved Sources Reviewed
|
||||
|
||||
## Sources Skipped Or Unavailable
|
||||
|
||||
## Draft Created
|
||||
|
||||
## User Review Status
|
||||
|
||||
## PID Update Status
|
||||
|
||||
## Validation Results
|
||||
|
||||
## Privacy Decisions
|
||||
|
||||
## Notable Inferences
|
||||
|
||||
## Open Questions
|
||||
|
||||
## Skill Ratchet Suggestions
|
||||
```
|
||||
|
||||
## Final Report
|
||||
|
||||
When finished, report concisely:
|
||||
|
||||
- where the review draft was created
|
||||
- what sources and timeframe were reviewed
|
||||
- whether the PID was updated or is awaiting review
|
||||
- what validations passed
|
||||
- what risks or open questions remain
|
||||
- any suggested skill improvements learned from the run
|
||||
|
||||
## Suggested User Prompt
|
||||
|
||||
```text
|
||||
Use the PID Update Maintenance Skill to update my Portable Identity Document.
|
||||
|
||||
My PID is here: [path or link]
|
||||
Review this timeframe: [last 7 days / dates]
|
||||
Save the review draft here: [folder]
|
||||
|
||||
Approved sources:
|
||||
- [folders]
|
||||
- [email labels or accounts]
|
||||
- [calendar range]
|
||||
- [meeting transcript folders]
|
||||
- [CSV/JSON/database exports]
|
||||
- [other sources]
|
||||
|
||||
Privacy boundaries:
|
||||
- never include [items]
|
||||
- generalize [items]
|
||||
- ask before including [items]
|
||||
|
||||
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.
|
||||
31
tasks/2026-06-15-pid-repo-development.md
Normal file
31
tasks/2026-06-15-pid-repo-development.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# This is the original instructions to Ai to create the PID-update-maintenance-skill.md
|
||||
|
||||
I want you to create a skill. The skill is designed to help update a user's PID. Please first reference this repo for the PID, what it is, what it does, why, etc: C:\projects\indx\portable-identity-document-template-OPEN for you to gain more context on this project. Wider context for the PID repo and what it acheives can be found in this vision document: C:\projects\paddlenet\paddlenet-business\specs\1_strategy_s\nsig-vision-strategy.md That can help you understand how this skill and the PID fits within the broader framework for networking in the AI era.
|
||||
|
||||
## Purpose of skill
|
||||
|
||||
People will not manually maintain rich PID profiles indefinitely—and even if they wanted to, it becomes increasingly difficult over time. Each week we learn new things, complete projects, build relationships, create content, solve problems, and gain experiences that may be valuable signals to others. Capturing and organizing all of that manually is unrealistic. Instead, we want to delegate the ongoing observation, summarization, and cataloging of our activities to an AI agent, allowing it to identify meaningful changes, draft updates, and help keep our PID current with minimal effort.
|
||||
|
||||
The skill is designed to do this by accessing the persons local workstation files, what changed, where, why, how, what did the user create, learn accomplish?
|
||||
|
||||
The suggested time frame to run the skill is weekly, but the user can adjust the skill by specific dates or time frame.
|
||||
|
||||
The file directories the user should provide in the skill at the top. The skill could also access user emails for this information. Information can be files, emails, virtual meeting records that are converted speech to text, access to databases if the user provides through MCP or via CSV files or JSON files of the data...any digital data that the user gives access for review. The skill should provide a checklist at the beginning about what data categoreis the user could provide for the agent to review, and the user inputs where to find that information. THere could be other categories of information to access I am missing. Add them.
|
||||
|
||||
THe skill should output any relevant info it finds into a local .md file for the user to first review. THe skill needs to output the information into categories according to the user's PID format. The user needs to provide a local link to their PID so the agent can read that.
|
||||
|
||||
User PIDs could be in google doc format, microsfot word format, .md format, PDF format, or any other popular formats that can be uploaded to a cloud storage or equivalent and a link is created to access it. In whateer format the user uses, the user needs to provide access to that document for the agent to review and update. So the skil need to ask this information at the beginnging along with other info referenced above.
|
||||
|
||||
After reviewing the output .md file, the user will adjust, delete, change, add as needed. At the top of the .md file, include instructions tot he users to change/ammend/add as needed, but if they do, then they should be prompted to ask the agent to adjust the skill based on their changes, so the skill evolves and learns.
|
||||
|
||||
After the rewview is done, the skill will continue by appending that info to the user's PID. So the skill should incortporate reasining and discussion as needed between the agent and the user to execute this reivew-draft.md publish-final PID public process.
|
||||
|
||||
This skill should be thorough and complete, surfacing even the smallest of learnings or accomplishments or creatives or problems solved or "aha's" or revelations or evolutionary improvements. The agent through the skill should infer based on discoveries what the user might need or want, what they have that others will need or want.
|
||||
|
||||
Prompt where the skill can be adjusted to surface information relevant to the user based on their PID. But we want to be throrough in discoveries because they could provide value to a user via their PID that they are not seeing. So do not be too narrow.
|
||||
|
||||
The skill can be run manually by the user, or if they want to automate it into a harness and cron job, they can do that on their own.
|
||||
|
||||
Please use this skill template to design this skill: C:\projects\productivity\misc-productivity-tools-OPEN\skill-template
|
||||
|
||||
You can ouput the skill in md format to this folder and I wil review: C:\projects\indx\portable-identity-document-template-OPEN\skills
|
||||
Loading…
Reference in New Issue
Block a user