portfolio-governance
Govern a personal software and creative portfolio with explicit ownership, lifecycle status, and attention limits. Use when deciding where a new idea belongs, reviewing overlapping repositories, selecting one active experiment, maintaining a portfolio ledger, or archiving dormant work without applying startup traction metrics to personal tools.
72
89%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Portfolio Governance
Use this skill to keep a personal project portfolio coherent, private, and sustainable.
Optimize for recurring personal utility, autonomy, privacy, learning, joy, and manageable operating burden. Do not use user growth, revenue, or market traction as default criteria for personal tools.
Classify the request first
| Work type | Primary test |
|---|---|
| Personal system or tool | Does it improve a real recurring workflow with acceptable upkeep? |
| Creative/technical laboratory | Does it answer a bounded question and preserve a learning artifact? |
| Commercial initiative | Does it meet its own trust, consent, and operating commitments? |
| Public-interest initiative | Does it meet its own safety, transparency, and accessibility commitments? |
| Reference/upstream asset | Is provenance and its narrow role explicit? |
Portfolio intake workflow
- Identify the workflow. State the real trigger, desired outcome, data touched, and existing tools that already serve it.
- Find the canonical owner. Name one repository or data/configuration boundary that owns the truth. Prefer an adapter or contract to a duplicate implementation.
- Assign a lifecycle. Use one of:
core-system,active-personal-tool,integration-contract,active-laboratory,maintenance-utility,reference-history,upstream-mirror,archive-after-audit,commercial-occasional, orpublic-interest-occasional. - Limit concurrent attention. Default to at most one core-reliability item, one contract/integration item, and one active experiment.
- Record the next decision. State the concrete acceptance condition, review date, or reactivation condition.
Canonical ownership rules
- Treat personal data, declared configuration, and reusable behavior as separate truths with explicit owners.
- Treat indexes, caches, generated inventories, and service state as derived unless explicitly declared otherwise.
- Keep live private content outside reusable templates, fixtures, and public/reference repositories.
- Keep long-form lessons and decisions in the private knowledge system; keep tasks, milestones, and status in Linear; keep implementation details near the relevant code.
- Do not allow an experiment or agent to become a live dependency without a documented promotion decision, safety boundary, and recovery plan.
Lifecycle decisions
| Lifecycle | Required note |
|---|---|
| Core system | Owner, recovery source, data/privacy boundary, and next reliability action. |
| Active personal tool | Workflow supported, maintenance boundary, and next meaningful improvement. |
| Integration contract | Systems linked, fixture/privacy rule, and acceptance check. |
| Active laboratory | Question, timebox, stop condition, and artifact to preserve. |
| Reference/upstream asset | Provenance and reason it receives no roadmap capacity. |
| Archive after audit | Retained value, successor/current authority, and reactivation condition. |
Quarterly review
Score only active or reviewable work on: personal utility, system leverage, autonomy/privacy, learning/craft, joy/creative value, and operational burden. Use evidence rather than aspiration.
- Keep: useful, safe enough, and maintainable.
- Refocus: valuable but overlapping or under-owned; write a contract or successor note.
- Pause/archive: little current value or excessive burden; preserve history without guilt.
- Promote: only after a laboratory proves a stable workflow and recovery boundary.
Safety boundaries
- Never move or delete personal data, archive repositories, change visibility, or alter live infrastructure without explicit approval of the exact scope.
- Do not commit credentials, personal notes, private host details, or raw user data.
- Require a backup, preview, rollback path, and explicit approval before consequential changes to music libraries, private knowledge, or homelab systems.
- Repository
- pvnkmnk/AgenticSelfHostSkills
- Commit
0f62e6b
- Last updated
- First committed
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.