sync: skills and tool contract overhaul from private repo

2026-03-07 11:45:26 +11:00
parent 46ac8d9bde
commit 2cdd685c04
32 changed files with 2548 additions and 681 deletions
@@ -0,0 +1,29 @@
+---
+name: Audit
+description: "Run a structured audit of graph quality, skill quality, and operational consistency."
+when_to_use: "User asks for review, QA, cleanup, or governance checks."
+when_not_to_use: "Simple one-off write/read requests."
+success_criteria: "Findings are prioritized, concrete, and tied to actionable fixes."
+---
+
+# Audit
+
+## Scope
+
+1. Node quality: duplicates, vague descriptions, missing dates, weak titles.
+2. Edge quality: missing links, weak explanations, wrong directionality.
+3. Dimension quality: drift, overlap, low-signal categories.
+4. Skill quality: trigger clarity, overlap, dead/unused skills.
+
+## Output Format
+
+1. Critical issues
+2. High-impact improvements
+3. Cleanup actions
+4. Optional refinements
+
+## Rules
+
+- Prefer specific evidence over generic commentary.
+- Propose the smallest high-leverage fixes first.
+- Separate defects from optional polish.
@@ -0,0 +1,33 @@
+---
+name: Calibration
+description: "Run periodic check-ins to recalibrate goals, projects, preferences, and graph structure."
+when_to_use: "User asks for a check-in, reset, review, or strategic recalibration."
+when_not_to_use: "Single isolated question with no strategic update needed."
+success_criteria: "Graph reflects current reality: updated hubs, changed priorities, and explicit deltas."
+---
+
+# Calibration
+
+## Objective
+
+Re-anchor the graph to the user's current state.
+
+## Check-in Sequence
+
+1. Review major hub nodes and active project nodes.
+2. Ask what changed: goals, priorities, constraints, beliefs, preferences.
+3. Identify stale nodes and missing nodes.
+4. Propose precise updates: update existing vs create new.
+5. Apply changes with explicit rationale.
+
+## Write Guidance
+
+- Prefer updating existing nodes when continuity matters.
+- Create new nodes for genuine shifts in direction/identity/approach.
+- Add edges that explain evolution (old -> new).
+
+## Output
+
+- What changed
+- What was updated vs newly created
+- What should be reviewed next check-in
@@ -0,0 +1,26 @@
+---
+name: Connect
+description: "Create and refine meaningful relationships between nodes, including integration-style synthesis links."
+when_to_use: "User asks to connect ideas, merge insights, or strengthen graph relationships."
+when_not_to_use: "Task is purely node creation with no relationship work required."
+success_criteria: "High-signal edges improve retrieval quality and graph coherence."
+---
+
+# Connect
+
+## Goal
+
+Turn isolated nodes into a useful reasoning graph.
+
+## Process
+
+1. Identify candidate nodes to connect.
+2. Check existing relationships first.
+3. Add/upgrade edges with explicit directional explanation.
+4. When integrating multiple nodes, create synthesis links that preserve provenance.
+
+## Quality Bar
+
+- Edge explanation must answer: "why does this relationship exist?"
+- Direction should be intentional and interpretable.
+- Avoid obvious/tautological edges.
@@ -0,0 +1,42 @@
+---
+name: Create Skill
+description: "Design or refine a skill using a tight trigger, explicit contract, and measurable outcomes."
+when_to_use: "User asks to create, rewrite, or improve a skill."
+when_not_to_use: "Task is normal graph operation and no new skill is needed."
+success_criteria: "Skill has clear trigger boundaries, execution steps, guardrails, and evaluation hooks."
+---
+
+# Create Skill
+
+## Objective
+
+Create skills that are precise, callable, and testable.
+
+## Skill Design Standard
+
+1. Define trigger boundary clearly: when to use and when not to use.
+2. Define required outputs and quality bar.
+3. Specify concrete execution sequence.
+4. Add hard guardrails (what to reject/avoid).
+5. Keep it short; remove fluff and duplicate policy text.
+
+## Required Structure
+
+- `name`
+- `description`
+- `when_to_use`
+- `when_not_to_use`
+- `success_criteria`
+- Step-by-step procedure
+- Do-not list
+
+## Validation Checklist
+
+- Can another agent execute this without guessing?
+- Does it avoid overlap with existing skills?
+- Are failure modes explicit?
+- Is there an obvious way to evaluate success?
+
+## Consolidation Rule
+
+If two skills have the same trigger + same tool path + same output contract, merge them.
@@ -0,0 +1,37 @@
+---
+name: DB Operations
+description: "Use this for all graph read/write operations with strict data quality standards."
+when_to_use: "Any request to read, create, update, connect, classify, or traverse graph data."
+when_not_to_use: "Pure conversation with no graph interaction needed."
+success_criteria: "Writes are explicit and correct; descriptions are concrete; edges and dimensions are high-signal."
+---
+
+# DB Operations
+
+## Core Rules
+
+1. Search before create to avoid duplicates.
+2. Every create/update must include an explicit description of WHAT the thing is and WHY it matters.
+3. Use event dates when known (when it happened, not when saved).
+4. Apply dimensions deliberately; prefer existing dimensions over creating noisy new ones.
+5. Create edges when relationships are meaningful; edge explanations should read as a sentence.
+
+## Write Quality Contract
+
+- `title`: clear and specific.
+- `description`: concrete object-level description, not vague summaries.
+- `notes/content`: extra context, analysis, supporting detail.
+- `link`: external source URL only.
+
+## Execution Pattern
+
+1. Read context (search + relevant nodes + relevant edges).
+2. Decide: create vs update vs connect.
+3. Execute minimum required writes.
+4. Verify result reflects user intent exactly.
+
+## Do Not
+
+- Create duplicate nodes when an update is correct.
+- Write vague descriptions ("discusses", "explores", "is about").
+- Create weak or directionless edges.
@@ -0,0 +1,34 @@
+---
+name: Onboarding
+description: "Onboard a new user by mapping goals, projects, worldview, and preferences into a strong initial graph."
+when_to_use: "New user setup or major reset of account context."
+when_not_to_use: "User asks for a narrow tactical operation only."
+success_criteria: "User has an initial hub-node structure and clear next steps for graph growth."
+---
+
+# Onboarding
+
+## Goal
+
+Understand the user deeply enough to bootstrap a useful externalized context graph.
+
+## Interview Flow
+
+1. Clarify outcomes: goals for this system and success horizon.
+2. Map active projects: responsibilities, timelines, decision pressure.
+3. Capture worldview: beliefs, principles, working assumptions, decision criteria.
+4. Capture identity/context anchors: roles, domains, recurring themes.
+5. Capture interaction preferences: style, rigor, speed vs depth, tone.
+
+## Graph Bootstrap
+
+1. Propose 3-6 hub nodes with clear rationale.
+2. Propose starter dimensions that reflect real domains.
+3. Create initial edges between hubs and active projects.
+4. Confirm with user before writing.
+
+## Output
+
+- Initial hub map
+- Suggested first write actions
+- Suggested weekly maintenance rhythm
@@ -0,0 +1,30 @@
+---
+name: Persona
+description: "Build and maintain a user-defined agent persona and interaction style profile."
+when_to_use: "User asks to set or refine how the agent should behave."
+when_not_to_use: "No behavior/persona request is present."
+success_criteria: "Persona is explicit, editable, and consistently applied across interactions."
+---
+
+# Persona
+
+## Objective
+
+Make agent behavior fully malleable to the user.
+
+## Capture Model
+
+1. Communication style (directness, brevity, tone).
+2. Thinking style (exploratory vs decisive, framework-heavy vs practical).
+3. Decision style (challenge level, risk posture, evidence threshold).
+4. Collaboration style (pushback expectations, cadence, format preferences).
+
+## Persistence Pattern
+
+- Store persona as explicit nodes (and updates over time), not hidden assumptions.
+- Keep versioned changes visible to the user.
+
+## Do Not
+
+- Freeze persona permanently.
+- Apply unstated style assumptions when user instructions conflict.
@@ -0,0 +1,28 @@
+---
+name: Traverse
+description: "Gather deeper context by traversing connected nodes before answering."
+when_to_use: "Question benefits from broader context than a single direct lookup."
+when_not_to_use: "Simple factual answer can be resolved from one direct node."
+success_criteria: "Answer is grounded in relevant connected context without over-traversal noise."
+---
+
+# Traverse
+
+## Strategy
+
+1. Start with seed nodes from the user query.
+2. Expand neighbors breadth-first with depth limits.
+3. Prioritize high-signal nodes (strong relevance + strong edge semantics).
+4. Pull key evidence from top nodes.
+5. Answer directly and explain why chosen nodes mattered.
+
+## Defaults
+
+- Depth: 2
+- Seed count: 3-5
+- Exploration budget: ~40 nodes
+
+## Do Not
+
+- Traverse without limits.
+- Include distant low-signal nodes just to add volume.