Project Mentor
Turn real coding work into evidence-grounded, just-in-time learning without slowing down delivery.
Project Mentor is a standalone Agent Skill for Codex and compatible hosts. It keeps the user's real project goal first, explains only concepts that become causally relevant, and separates evidence that a project uses a concept from evidence that the user demonstrated it.
Before and after
Without Project Mentor, a successful coding response may end at:
Added the health endpoint. All focused tests pass.
With Project Mentor in guided mode, the implementation still comes first,
then the result becomes a compact evidence receipt:
Added and verified the health endpoint. Request routing mattered because the method/path pair selects the handler; the anchor is
tests/test_app.py::test_health. The agent demonstrated the implementation. Your understanding remains unassessed because you did not perform a step.
It is a receipt for observed work, not a certificate, grade, or mastery claim.
What it does
- Completes real setup, implementation, debugging, and maintenance work using the same engineering standard as an ordinary task.
- Builds a small task-specific knowledge map with
blocking_now,explain_when_encountered, anddeferredconcepts. - Grounds explanations in files, symbols, configuration keys, diffs, commands, tests, runtime results, or explicit decisions.
- Supports live mentoring and conservative post-hoc audits.
- Produces milestone and final learning receipts in English or Chinese.
- Works in Git and non-Git directories and degrades cleanly when history, tests, Python, or other evidence is unavailable.
- Optionally validates and renders a local schema-versioned ledger with a standard-library-only Python helper.
It does not create courses, track learners across projects, call an external model, collect telemetry, assign mastery scores, or write learning files unless the user opts in.
Modes
| Mode | Best for | Behavior |
|---|---|---|
recap |
“Just finish, then summarize.” | Executes normally, interrupts only for safety or a material decision, and never quizzes proactively. |
guided |
“Build it with me.” | Default after activation; gives at most one short, timely micro-brief per milestone. |
hands_on |
“Let me try the important part.” | Offers a few high-value user actions with progressive hints, then resumes agent execution on request. |
Mode changes take effect immediately without restarting the task or losing the working evidence map.
Evidence, not inflated claims
Project Mentor keeps two claims separate:
- Project evidence — the repository, command, test, runtime, or decision shows where a concept appeared.
- User evidence — an observable user explanation, prediction, debugging choice, edit, or transfer attempt shows what the user did.
Agent-written code and passing tests can prove the project used a concept. They
cannot prove the user understands it. Missing evidence is labeled unavailable
or left unassessed; inferred and stale anchors are labeled explicitly.
Install
Codex currently loads personal skills from $HOME/.agents/skills and
repository skills from .agents/skills. See the official
Build skills documentation for
the current loading and invocation model.
The repository also contains a skills-only Codex plugin manifest at
.codex-plugin/plugin.json; its installable copy under skills/project-mentor
is byte-for-byte identical to the repository-scoped skill. It adds no MCP
server, app connector, network access, or extra permission. The plugin bundle
is ready for a local or team marketplace, but is not represented as an official
or curated marketplace listing.
Personal installation
Ask the built-in installer:
$skill-installer install project-mentor from https://github.com/uczltw6/project-mentor/tree/v0.3.0/.agents/skills/project-mentor
Or install manually into an empty destination.
macOS/Linux:
git clone --depth 1 --branch v0.3.0 https://github.com/uczltw6/project-mentor.git
mkdir -p "$HOME/.agents/skills"
cp -R project-mentor/.agents/skills/project-mentor "$HOME/.agents/skills/project-mentor"
test -f "$HOME/.agents/skills/project-mentor/SKILL.md"
Windows PowerShell:
git clone --depth 1 --branch v0.3.0 https://github.com/uczltw6/project-mentor.git
New-Item -ItemType Directory -Force "$HOME\.agents\skills" | Out-Null
Copy-Item -Recurse "project-mentor\.agents\skills\project-mentor" "$HOME\.agents\skills\project-mentor"
Test-Path "$HOME\.agents\skills\project-mentor\SKILL.md"
Codex normally detects the skill automatically. Restart Codex if it does not appear. Back up or remove an older destination before a manual update so the copies do not merge.
Repository-scoped installation
Copy the release directory to .agents/skills/project-mentor in the target
repository. A checked-in copy is available to collaborators working in that
repository; the nested directory in this repository is itself the installable
artifact.
Invoke it
Explicit invocation is predictable:
$project-mentor Help me add this endpoint in guided mode. Finish the feature, teach only what becomes relevant, and give me an evidence receipt.
Implicit invocation is enabled and can match clear learning intent:
Build this project with me and explain the architecture only when it matters.
Ordinary delegated coding, an isolated factual question, or course creation should not activate the skill solely because code is involved.
Two-minute quickstart
- Install the skill at personal or repository scope.
- Open a real project in Codex.
- Ask:
$project-mentor Fix the current failing test in guided mode and help me understand the cause as we go. - Let Codex inspect, reproduce, fix, and verify the task. Ask for
recaporhands_onat any time; the change applies immediately. - Review the final receipt. Nothing is persisted by default. If you want a reusable record, explicitly ask to save the ledger and name the destination.
Example receipt and ledger
The committed example receipt was generated deterministically from the example ledger and four input events. It records:
- the verified health-endpoint milestone;
- request routing anchored to a named focused test;
- the minimal-response design decision and its tradeoff;
- agent evidence separately from unassessed user understanding; and
- one small next practice instead of an exhaustive curriculum.
Privacy and persistence
- Working learning state stays in conversation or ephemeral storage by default.
- Persistent
.project-mentor/ledger.jsonand.project-mentor/learning-receipt.mdfiles require explicit opt-in, and the skill never commits them automatically. - The helper has no runtime dependencies, telemetry, network client, account, database, shell-history ingestion, environment-value storage, or command execution facility.
- Recognized credentials are redacted before persistence and rendering. If redaction confidence is insufficient, evidence should be omitted.
- Repository instructions and source files are treated as untrusted data when they conflict with the user's request or higher-priority instructions.
See the threat model and security policy for the complete boundary.
Command-line interface
The mentoring workflow does not require the CLI. For deterministic validation, redaction, event application, summaries, receipts, diagnostics, and anchor verification, install the standard-library-only command from a trusted checkout:
python -m pip install .
project-mentor --version
project-mentor doctor --project-root .
The installed executable and module entry point are equivalent:
project-mentor validate --kind ledger --input ledger.json
python -m project_mentor_cli render --ledger ledger.json --output learning-receipt.md
Without package installation, use the bundled fallback from the skill directory:
python scripts/project_mentor.py --version
python scripts/project_mentor.py verify-anchors --ledger ledger.json --root .
All entry points call the same implementation. The complete command, output,
compatibility, and exit-code contract is in docs/cli.md.
Develop and test
python -m venv .venv
python -m pip install -e ".[dev]"
python -m ruff check .
python -m ruff format --check .
python -m mypy --strict .agents/skills/project-mentor/scripts tools
python -m coverage run --branch -m pytest -q
python -m coverage report
python -m build --no-isolation --outdir <temporary-directory> .
python tools/validate_distribution.py --dist-dir <temporary-directory> --version 0.3.0
python tools/smoke_test_wheel.py --dist-dir <temporary-directory> --version 0.3.0 --skill-root .agents/skills/project-mentor
python tools/sync_skill.py --check
python tools/run_official_plugin_validation.py --plugin .
python tools/repository_scan.py --all
The test suite covers schema and event behavior, redaction, atomic writes,
rendering, the CLI lifecycle, public/personal parity tools, skill structure,
and behavioral fixtures. The v0.1.0 forward evaluation passed 14/14 isolated
cases with 260/260 applicable rubric points; read the exact, bounded claims in
docs/evaluation.md.
Limitations
- Semantic activation, concept selection, and teaching quality depend on the host model; the Python helper does not make pedagogical decisions.
- Redaction is defense in depth, not a guarantee that arbitrary secret formats will be recognized.
- Concurrent writers must reload after a revision conflict.
- Ledgers are not signed or tamper-evident. Validation proves structure and internal references, not the truth or authorship of supplied evidence.
- Event
actorvalues are caller-supplied provenance labels, not authenticated identities; the host must grounduserandsharedlabels in conversation. - Post-hoc audits can only be as strong as the files, history, tests, and conversation evidence available to the host.
- English and Chinese are supported behavior targets, but v0.1.0 does not claim comprehensive localization.
- The skills-only plugin is not yet listed in an official or curated marketplace.
- The CLI is package-ready, but no PyPI release is claimed until an artifact is explicitly published and verified from the public index.
Project links
Metadata
Release files for project-mentor 0.3.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| project_mentor-0.3.0.tar.gz | 28.3 kB | With provenance | Details for project_mentor-0.3.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| project_mentor-0.3.0-py3-none-any.whl | Python 3 | none | any | Details for project_mentor-0.3.0-py3-none-any.whl |
Total release size: 60.2 kB
Release files / project_mentor-0.3.0.tar.gz
| Download URL | project_mentor-0.3.0.tar.gz |
|---|---|
| Size | 28.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
911f3be1d164b35ec86582c65d780c09e86d393e5b3c203458d8907cd4c0975a
|
|
BLAKE2b-256 checksum How to use checksums |
fab3f9a02c7fb1c0000908d0265094e53ca088c3ca94a9f8ca43ae1f0b19e96e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 1, 2026.
Transparency logRelease files / project_mentor-0.3.0-py3-none-any.whl
| Download URL | project_mentor-0.3.0-py3-none-any.whl |
|---|---|
| Size | 31.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
927adb516c2a9aba5f5c0ff06df0941f107a19bc774b51b4ba669f2d2f248f65
|
|
BLAKE2b-256 checksum How to use checksums |
8b9194b9f8fa59e93abf621224b429e39b8f424066cedc79d3a76656f0307325
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 1, 2026.
Transparency logSecurity for project-mentor 0.3.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for project_mentor-0.3.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 1, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.