future-planner

name	future-planner
description	Use when evaluating future roadmap ideas, creating planning-only architecture docs, or assessing R&D concepts against Hussh north stars, trust boundaries, and current repo reality.

Hussh Future Planner Skill

Purpose and Trigger

• Primary scope: future-roadmap-plan-intake
• Trigger on future roadmap concepts, R&D architecture notes, assistant-evolution ideas, external trend fit questions, and planning-only concept docs that must stay separate from vision and active implementation.
• Avoid overlap with planning-board, docs-governance, and repo-context.

Coverage and Ownership

• Role: owner
• Owner family: future-planner

Owned repo surfaces:

1. docs/future
2. .codex/skills/future-planner
3. .codex/workflows/future-roadmap-plan

Non-owned surfaces:

1. docs-governance
2. planning-board
3. repo-context
4. docs/vision

Do Use

1. Deciding whether an idea belongs in north-star vision, future roadmap, or active execution.
2. Creating or refining planning-only docs under docs/future/.
3. Assessing future concepts against trust boundaries, PKM, consent, delegation, connector access, UX clarity, and operational complexity.
4. Turning vague future ideas into explicit R&D notes with promotion criteria.
5. Removing or rerouting future-roadmap docs once repo evidence proves the capability is implemented.

Do Not Use

1. Active implementation work or execution-owned technical specs.
2. GitHub board updates that belong to planning-board.
3. Broad repo scanning when the correct owner family is still unknown.
4. Rewriting durable vision docs unless the product thesis itself is changing.

Read First

1. docs/vision/README.md
2. docs/future/README.md
3. docs/reference/operations/documentation-architecture-map.md
4. consent-protocol/docs/reference/personal-knowledge-model.md

Workflow

1. Ground the idea in current repo reality before planning future behavior.
2. Classify the request explicitly as vision, future roadmap, or execution.
3. For material Hussh product direction, founder language, One/Kai/Nav ontology, PCHP/BYOA/on-device posture, PKM/World Model authority, or roadmap positioning, run the Founder Wiki North-Star Probe from .codex/skills/codex-skill-authoring/references/founder-wiki-north-star-probe.md.
4. Treat the founder wiki as north-star and future-state evidence, not proof that a runtime feature exists today. Record repo/wiki disagreement as current_state_vs_north_star_drift.
5. Keep private wiki evidence local-only unless the user explicitly asks for an internal private artifact.
6. Assess edge cases before writing:
   • trust and authority boundaries
   • BYOK and zero-knowledge compatibility
   • PKM vs runtime-memory separation
   • A2A or delegated-execution implications
   • connector permissions and on-demand consent
   • user-facing trust-state clarity
7. Record what already exists, what is missing, what needs new primitives, and what should stay out of scope.
8. If repo evidence proves a future item is now implemented or approved for execution, remove it from docs/future/ or hand it to docs-governance for promotion into the current execution docs. Do not leave implemented capabilities framed as future promises.
9. Place the output in docs/future/ unless the work is already approved for execution or belongs in docs/vision/.
10. Add explicit status and promotion criteria to every future-state concept doc.

Handoff Rules

1. If the task is broad repo orientation first, start with repo-context.
2. If the task becomes documentation-home governance, hand off to docs-governance.
3. If the task becomes issue or board planning, hand off to planning-board.
4. If the concept is approved and becomes active work, hand off to the correct execution owner skill instead of keeping implementation detail in future-planner.

Required Checks

python3 .codex/skills/codex-skill-authoring/scripts/skill_lint.py
./bin/hushh docs verify
./bin/hushh codex audit