Skip to main content
This page turns finished work into , then turns an approved Experience into a managed . The point is not how polished the model draft looks. It is whether checked exact evidence and the version. Review first: a proposal becomes a Candidate, Review approves or rejects, Experience can be recalled, and Skill still needs export.
Review and export commands follow the latest published official docs. This page helps you run one review path where failure stays visible.

Two creation paths

Choose the path by the evidence you already have. The typed path is model-free and reproducible; generation is useful only when the Server has a working generation provider. The CLI currently has no experience propose or skill propose subcommand. Use the Python Client or HTTP API for model-free typed proposals. This tutorial establishes a deterministic Review loop with typed proposals first, then shows model-generation commands.

1. Prepare exact evidence

Capture one task-result Source. Create propose_experience.py:
Run it and keep the output:
Replace SCOPE_ID and CANDIDATE_ID in later CLI commands with the values printed by the script.

2. Inspect the Candidate

The default Inbox lists pending heads only:
Show the current version:
Before deciding, inspect:
  • all four proposal fields;
  • exact source_refs and artifact_refs;
  • target, which appears only for replacement;
  • status, family, and reason;
  • current version.
Do not rely on the model’s summary. Open the evidence and verify that it supports the proposed action, outcome, and lesson.

3. Revise replaces the whole proposal

Use the Source ID returned by capture. The Candidate remains pending and advances to version 2. Show it again and inspect the complete replacement. Intentionally approve with the stale version:
It should return HTTP 409 candidate_conflict. Do not change the value to 2 and retry without confirming that current v2 is the proposal you intend to approve.

4. Approve or reject

Approve the inspected v2:
Keep the exact result_artifact:
Reject is an alternative terminal branch and needs another pending Candidate:
Approved and rejected Candidates are terminal. Neither may be revised, approved, or rejected again.

5. Verify Experience recall

There is no powercontext context prepare CLI command. Use the Python Client:
Replace SCOPE_ID with the actual value. Approval makes the current Experience head eligible for recall, but it does not guarantee selection for every query. Scope, query relevance, and byte budget still apply. Pending, rejected, and historical Experience Revisions stay outside default recall.

6. Create a Skill Candidate

The clearest lineage for a new Skill is the approved Experience. Create propose_skill.py:
Replace SCOPE_ID and EXPERIENCE_ID, then run the script. Use the same Candidate list, show, revise, and approve commands. For longer instructions, use a UTF-8 file:
Choose exactly one of --instructions and --instructions-file. Approval produces:
The Skill still does not enter PreparedContext. That is expected.

7. Read and export an exact Skill Revision

Read it first:
Export to Codex:
Export to Claude Code:
The target is claude_code, not claude-code. The output directory contains:
Confirm that powercontext.json cites exact skill/SKILL_ID@1. CLI export is create-only and refuses an existing destination. Managed Skill export currently supports Codex and Claude Code only. A bundled Skill shipped with a plugin does not imply managed export support.

Model-generation path

With a generation model configured, a Candidate may also be generated from exact evidence:
Generate Skill from approved Experience:
The response may be:
or:
A no-op does not enter the Inbox and has no Candidate to approve. Without a generation model, generate returns 503 generation_unavailable. Other Skill origins:
  • source: one or more exact Source refs only, with no Artifact refs or target;
  • usage: an exact target Skill and at least one bounded Source. The Server validates reference shape; the reviewer decides whether the Source truly records useful observed behavior.
A Review path is incomplete until its failure is visible. A stale Candidate version or a drifted replacement target must leave the Candidate pending; it must not create a partial Artifact or silently approve newer content.

Conflict handling

A replacement Candidate cannot switch its target to another Revision during revise.

How you know it worked

  • A typed proposal can create a pending Candidate without a model.
  • Generate may return pending, or no change.
  • Review always shows the Candidate first, then uses the expected_version you inspected.
  • A stale version returns 409.
  • Approval returns an exact result_artifact.
  • The approved current Experience may participate in relevant recall.
  • Approving a Skill does not export it, and does not execute it.
  • The export directory contains SKILL.md and powercontext.json.
  • An existing destination, or local drift, is never overwritten silently.
Basic usage ends here. Pick the path that matches the work you are doing now.
If PowerContext fails while automatically fetching context, keep working. If you explicitly write a Memory, commit a Handoff, approve a proposal, or export a Skill, you must see the failure. Read fail-open for the full rule.

Next step

Connect a Python Agent

First integration is LangGraph or LangChain.

Configure a common or coding Agent

Hermes and OpenClaw are common Agents. Codex and Claude Code are on coding agents.