shikhu 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- shikhu-0.1.0/.claude/skills/study/SKILL.md +113 -0
- shikhu-0.1.0/.github/dependabot.yml +32 -0
- shikhu-0.1.0/.github/workflows/ci.yml +79 -0
- shikhu-0.1.0/.github/workflows/release.yml +41 -0
- shikhu-0.1.0/.gitignore +18 -0
- shikhu-0.1.0/.python-version +1 -0
- shikhu-0.1.0/LICENSE +21 -0
- shikhu-0.1.0/PKG-INFO +193 -0
- shikhu-0.1.0/README.md +173 -0
- shikhu-0.1.0/pyproject.toml +55 -0
- shikhu-0.1.0/src/shikhu/__init__.py +1 -0
- shikhu-0.1.0/src/shikhu/__main__.py +5 -0
- shikhu-0.1.0/src/shikhu/attribution.py +145 -0
- shikhu-0.1.0/src/shikhu/classifier.py +69 -0
- shikhu-0.1.0/src/shikhu/cli.py +47 -0
- shikhu-0.1.0/src/shikhu/commands/__init__.py +1 -0
- shikhu-0.1.0/src/shikhu/commands/clean.py +30 -0
- shikhu-0.1.0/src/shikhu/commands/coverage.py +119 -0
- shikhu-0.1.0/src/shikhu/commands/generate_from_study.py +59 -0
- shikhu-0.1.0/src/shikhu/commands/init.py +63 -0
- shikhu-0.1.0/src/shikhu/commands/quiz.py +235 -0
- shikhu-0.1.0/src/shikhu/commands/refresh.py +162 -0
- shikhu-0.1.0/src/shikhu/commands/review_log.py +70 -0
- shikhu-0.1.0/src/shikhu/commands/study_context.py +43 -0
- shikhu-0.1.0/src/shikhu/commands/summarize.py +118 -0
- shikhu-0.1.0/src/shikhu/commands/utils.py +75 -0
- shikhu-0.1.0/src/shikhu/generator.py +242 -0
- shikhu-0.1.0/src/shikhu/ingest.py +86 -0
- shikhu-0.1.0/src/shikhu/prompts/archive/prompts_v2.toml +27 -0
- shikhu-0.1.0/src/shikhu/prompts/archive/prompts_v3.toml +46 -0
- shikhu-0.1.0/src/shikhu/prompts/archive/prompts_v4.toml +56 -0
- shikhu-0.1.0/src/shikhu/prompts/prompts.toml +56 -0
- shikhu-0.1.0/src/shikhu/staleness.py +126 -0
- shikhu-0.1.0/src/shikhu/store.py +673 -0
- shikhu-0.1.0/tests/conftest.py +43 -0
- shikhu-0.1.0/tests/test_attribution.py +135 -0
- shikhu-0.1.0/tests/test_clean.py +29 -0
- shikhu-0.1.0/tests/test_cli_help.py +27 -0
- shikhu-0.1.0/tests/test_coverage.py +58 -0
- shikhu-0.1.0/tests/test_golden.py +51 -0
- shikhu-0.1.0/tests/test_ingest.py +81 -0
- shikhu-0.1.0/tests/test_init.py +69 -0
- shikhu-0.1.0/tests/test_packaging.py +47 -0
- shikhu-0.1.0/tests/test_question_timing.py +59 -0
- shikhu-0.1.0/tests/test_quiz.py +89 -0
- shikhu-0.1.0/tests/test_refresh.py +45 -0
- shikhu-0.1.0/tests/test_regex_classifier.py +83 -0
- shikhu-0.1.0/tests/test_revalidation.py +57 -0
- shikhu-0.1.0/tests/test_staleness.py +225 -0
- shikhu-0.1.0/tests/test_store.py +151 -0
- shikhu-0.1.0/tests/test_summarize.py +72 -0
- shikhu-0.1.0/uv.lock +2636 -0
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: study
|
|
3
|
+
description: Tutor the user through a source file with a cached summary, a guided walkthrough, and free-form Q&A — then persist a review record so future quizzes know what was covered.
|
|
4
|
+
argument-hint: "[file-path]"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Grep
|
|
8
|
+
- Glob
|
|
9
|
+
- Bash(uv run shikhu *)
|
|
10
|
+
- Bash(ls *)
|
|
11
|
+
- Bash(git ls-files *)
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
# /study — guided file review before a quiz
|
|
15
|
+
|
|
16
|
+
## About shikhu
|
|
17
|
+
|
|
18
|
+
Shikhu is a knowledge-coverage CLI that tracks how well a user understands *their own* codebase. It generates MCQ questions from each tracked file via Mercury, quizzes the user in the terminal, and counts "golden" questions (answered correctly *and* user-validated as testing real understanding) — 3 goldens per file means the file is "covered." `shikhu` is the entry point (`src/shikhu/cli.py`); commands live in `src/shikhu/commands/`.
|
|
19
|
+
|
|
20
|
+
The flow is **code → study → quiz**. `/study` is the *learn* step: you build the user's mental model of one file before they quiz on it, and every conceptual question they ask gets logged to `review_questions` so `shikhu generate-from-study <file>` can later seed quiz Qs that test those same concepts.
|
|
21
|
+
|
|
22
|
+
## Your role
|
|
23
|
+
|
|
24
|
+
You are the user's study partner. Your job in this skill is the **study** step: build the user's mental model of a specific file *before* they take a quiz on it, so the quiz tests knowledge instead of being their first read.
|
|
25
|
+
|
|
26
|
+
## 1. Resolve the target file
|
|
27
|
+
|
|
28
|
+
The argument is `$ARGUMENTS`. Treat it as the path to study.
|
|
29
|
+
|
|
30
|
+
- If no argument is provided, tell the user `Usage: /study <file-path>` and stop. (Auto-recommendation is a follow-up ship, not in scope here.)
|
|
31
|
+
- Verify the file exists with `Read` before proceeding. If it doesn't, stop and tell the user.
|
|
32
|
+
- Check that the file is tracked by git:
|
|
33
|
+
```bash
|
|
34
|
+
git ls-files --error-unmatch "$ARGUMENTS"
|
|
35
|
+
```
|
|
36
|
+
If the command exits non-zero (file untracked), tell the user one line — *"Heads up: `$ARGUMENTS` isn't tracked by git, so `shikhu refresh` and `shikhu coverage` won't see it until you `git add` it. /study still works."* — then continue. Don't stop.
|
|
37
|
+
|
|
38
|
+
## 2. Load context (small, deliberate footprint)
|
|
39
|
+
|
|
40
|
+
Do these in parallel where possible:
|
|
41
|
+
|
|
42
|
+
1. **Read the target file** with the `Read` tool — you'll walk through it.
|
|
43
|
+
2. **Read `CLAUDE.md`** for project conventions.
|
|
44
|
+
3. **Load cached summary + prior reviews** in one call:
|
|
45
|
+
```bash
|
|
46
|
+
uv run shikhu study-context "$ARGUMENTS"
|
|
47
|
+
```
|
|
48
|
+
If the output says `No cached summary`, tell the user one line — *"No cached summary yet, generating one now (~30s)…"* — then run:
|
|
49
|
+
```bash
|
|
50
|
+
uv run shikhu summarize --file "$ARGUMENTS"
|
|
51
|
+
uv run shikhu study-context "$ARGUMENTS"
|
|
52
|
+
```
|
|
53
|
+
The second call now returns the freshly cached summary; proceed with that.
|
|
54
|
+
|
|
55
|
+
If there are prior reviews, skim their `agent_summary` lines so you don't repeat ground already covered.
|
|
56
|
+
|
|
57
|
+
## 3. Start the review (get a review_id you'll close later)
|
|
58
|
+
|
|
59
|
+
```bash
|
|
60
|
+
uv run shikhu log-review "$ARGUMENTS" --start
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
Capture the stdout integer — that's the `review_id`. You'll need it for every `log-study-question` call and to close the review at the end.
|
|
64
|
+
|
|
65
|
+
## 4. Present the summary
|
|
66
|
+
|
|
67
|
+
Show the cached summary verbatim to the user, framed as "here's the 30-second overview before we dig in." Then ask:
|
|
68
|
+
> *"Want to walk through it section-by-section, or do you have specific questions already?"*
|
|
69
|
+
|
|
70
|
+
## 5. Walk the file
|
|
71
|
+
|
|
72
|
+
Default path: walk the file top-down, one logical section at a time (a function, a class, a config block — let the code's structure guide you, not line counts).
|
|
73
|
+
|
|
74
|
+
For each section:
|
|
75
|
+
- **Reference it** with `file_path:line_number` so the user can navigate to it in their editor.
|
|
76
|
+
- **Explain what it does** in 2-3 sentences, leaning on what's in the summary and the code itself.
|
|
77
|
+
- **Ask one probe question** — not a quiz question, a model-check question. E.g. *"What do you think happens if this is called with an empty list?"* or *"Why do you think this is cached instead of recomputed?"*
|
|
78
|
+
- **Listen to their answer.** If they ask a question back, answer it — and log it:
|
|
79
|
+
```bash
|
|
80
|
+
uv run shikhu log-study-question <review_id> "<their question, quoted>" --conceptual --answered
|
|
81
|
+
```
|
|
82
|
+
Use `--not-conceptual` for mechanical/syntax questions, `--unanswered` if you couldn't give a good answer.
|
|
83
|
+
|
|
84
|
+
If the user steers — "skip to X", "I want to understand Y" — follow their lead. The file walk is a default, not a script.
|
|
85
|
+
|
|
86
|
+
## 6. Close the loop
|
|
87
|
+
|
|
88
|
+
When the user signals they're done (they say so, or the walk is complete):
|
|
89
|
+
|
|
90
|
+
1. **Write a short agent summary** (3-5 sentences): what sections you covered, what the user seemed to grasp well, what was shaky, what they should revisit. This is the durable record that survives even if transcripts move.
|
|
91
|
+
2. **Resolve the Claude Code transcript path** for this session. Claude Code encodes the cwd by replacing `/`, `_`, and `.` with `-`:
|
|
92
|
+
```bash
|
|
93
|
+
ls -t ~/.claude/projects/$(pwd | tr '/_.' '-')/*.jsonl 2>/dev/null | head -1
|
|
94
|
+
```
|
|
95
|
+
(If this returns nothing, skip `--transcript`; the `agent_summary` alone is enough to keep the review record useful.)
|
|
96
|
+
3. **Close the review** with both pieces:
|
|
97
|
+
```bash
|
|
98
|
+
uv run shikhu log-review "$ARGUMENTS" --review-id <review_id> --summary "<your summary>" --transcript "<path or omit>"
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
## 7. Offer the quiz
|
|
102
|
+
|
|
103
|
+
End with:
|
|
104
|
+
> *"Ready to test it? Run `uv run shikhu quiz --file $ARGUMENTS` — or come back later and I'll have remembered what we covered."*
|
|
105
|
+
|
|
106
|
+
Do **not** auto-launch the quiz. Quizzing is a separate intentional act.
|
|
107
|
+
|
|
108
|
+
## Style
|
|
109
|
+
|
|
110
|
+
- Concise. This is a tutoring session, not a lecture.
|
|
111
|
+
- Cite `path:line` whenever you reference code so the user can jump there in their editor.
|
|
112
|
+
- Never invent behavior the code doesn't show — if unsure, say so and read the relevant file.
|
|
113
|
+
- If the user edits the file during the session, flag it: the summary and questions for this file will go stale and `shikhu refresh` will need to run.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# Dependabot version updates. Security alerts are enabled separately at the
|
|
2
|
+
# repo level (Settings → Security → Dependabot alerts).
|
|
3
|
+
version: 2
|
|
4
|
+
updates:
|
|
5
|
+
# Python dependencies (pyproject.toml + uv.lock). Use the `uv` ecosystem
|
|
6
|
+
# so Dependabot updates the lockfile too — the `pip` ecosystem doesn't
|
|
7
|
+
# touch uv.lock, which breaks our `uv lock --check` CI step.
|
|
8
|
+
- package-ecosystem: "uv"
|
|
9
|
+
directory: "/"
|
|
10
|
+
schedule:
|
|
11
|
+
interval: "weekly"
|
|
12
|
+
open-pull-requests-limit: 5
|
|
13
|
+
groups:
|
|
14
|
+
python-minor-patch:
|
|
15
|
+
patterns:
|
|
16
|
+
- "*"
|
|
17
|
+
update-types:
|
|
18
|
+
- "minor"
|
|
19
|
+
- "patch"
|
|
20
|
+
|
|
21
|
+
# GitHub Actions versions in .github/workflows/
|
|
22
|
+
- package-ecosystem: "github-actions"
|
|
23
|
+
directory: "/"
|
|
24
|
+
schedule:
|
|
25
|
+
interval: "monthly"
|
|
26
|
+
groups:
|
|
27
|
+
actions-minor-patch:
|
|
28
|
+
patterns:
|
|
29
|
+
- "*"
|
|
30
|
+
update-types:
|
|
31
|
+
- "minor"
|
|
32
|
+
- "patch"
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
name: CI
|
|
2
|
+
|
|
3
|
+
on:
|
|
4
|
+
pull_request:
|
|
5
|
+
push:
|
|
6
|
+
branches: [main]
|
|
7
|
+
|
|
8
|
+
jobs:
|
|
9
|
+
test:
|
|
10
|
+
runs-on: ubuntu-latest
|
|
11
|
+
permissions:
|
|
12
|
+
contents: read
|
|
13
|
+
checks: write
|
|
14
|
+
pull-requests: write
|
|
15
|
+
steps:
|
|
16
|
+
- uses: actions/checkout@v6
|
|
17
|
+
|
|
18
|
+
- name: Install uv
|
|
19
|
+
uses: astral-sh/setup-uv@v7
|
|
20
|
+
with:
|
|
21
|
+
python-version: "3.12"
|
|
22
|
+
enable-cache: true
|
|
23
|
+
|
|
24
|
+
- name: Validate lockfile is in sync with pyproject.toml
|
|
25
|
+
run: uv lock --check
|
|
26
|
+
|
|
27
|
+
# Tests are deterministic (temp DBs, no network/API keys), so no secrets needed.
|
|
28
|
+
- name: Sync dependencies
|
|
29
|
+
run: uv sync --frozen
|
|
30
|
+
|
|
31
|
+
- name: Lint + format check (ruff)
|
|
32
|
+
run: |
|
|
33
|
+
uv run ruff check src tests
|
|
34
|
+
uv run ruff format --check src tests
|
|
35
|
+
|
|
36
|
+
- name: Type check (ty — advisory, non-blocking)
|
|
37
|
+
continue-on-error: true
|
|
38
|
+
run: uv run ty check src/
|
|
39
|
+
|
|
40
|
+
- name: Run tests
|
|
41
|
+
run: uv run pytest tests/ -v --junitxml=junit.xml
|
|
42
|
+
|
|
43
|
+
- name: Publish test results
|
|
44
|
+
uses: EnricoMi/publish-unit-test-result-action@v2
|
|
45
|
+
if: always()
|
|
46
|
+
with:
|
|
47
|
+
files: junit.xml
|
|
48
|
+
|
|
49
|
+
smoke-install:
|
|
50
|
+
name: Packaging smoke test
|
|
51
|
+
runs-on: ubuntu-latest
|
|
52
|
+
steps:
|
|
53
|
+
- uses: actions/checkout@v6
|
|
54
|
+
|
|
55
|
+
- name: Install uv
|
|
56
|
+
uses: astral-sh/setup-uv@v7
|
|
57
|
+
with:
|
|
58
|
+
python-version: "3.12"
|
|
59
|
+
enable-cache: true
|
|
60
|
+
|
|
61
|
+
- name: Build wheel
|
|
62
|
+
run: uv build --wheel
|
|
63
|
+
|
|
64
|
+
- name: Install wheel into clean stdlib venv
|
|
65
|
+
run: |
|
|
66
|
+
python -m venv /tmp/shikhu-smoke
|
|
67
|
+
/tmp/shikhu-smoke/bin/pip install --upgrade pip --quiet
|
|
68
|
+
/tmp/shikhu-smoke/bin/pip install dist/shikhu-*.whl
|
|
69
|
+
|
|
70
|
+
- name: shikhu --help works post-install
|
|
71
|
+
run: /tmp/shikhu-smoke/bin/shikhu --help
|
|
72
|
+
|
|
73
|
+
- name: shikhu init creates DB + .quizignore in a fresh directory
|
|
74
|
+
run: |
|
|
75
|
+
mkdir /tmp/shikhu-smoke-test
|
|
76
|
+
cd /tmp/shikhu-smoke-test
|
|
77
|
+
/tmp/shikhu-smoke/bin/shikhu init
|
|
78
|
+
test -f coverage.db
|
|
79
|
+
test -f .quizignore
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
name: Release
|
|
2
|
+
|
|
3
|
+
# Cuts a GitHub Release + publishes to PyPI when a vX.Y.Z tag is pushed.
|
|
4
|
+
# Builds the wheel + sdist, publishes to PyPI via Trusted Publishing (OIDC —
|
|
5
|
+
# no API token stored), then attaches the artifacts to a GitHub Release.
|
|
6
|
+
on:
|
|
7
|
+
push:
|
|
8
|
+
tags:
|
|
9
|
+
- "v*"
|
|
10
|
+
|
|
11
|
+
permissions:
|
|
12
|
+
contents: write # required for gh release create
|
|
13
|
+
id-token: write # required for PyPI Trusted Publishing (OIDC)
|
|
14
|
+
|
|
15
|
+
jobs:
|
|
16
|
+
release:
|
|
17
|
+
runs-on: ubuntu-latest
|
|
18
|
+
steps:
|
|
19
|
+
- uses: actions/checkout@v6
|
|
20
|
+
|
|
21
|
+
- name: Install uv
|
|
22
|
+
uses: astral-sh/setup-uv@v7
|
|
23
|
+
with:
|
|
24
|
+
python-version: "3.12"
|
|
25
|
+
enable-cache: true
|
|
26
|
+
|
|
27
|
+
- name: Tests must pass before releasing
|
|
28
|
+
run: |
|
|
29
|
+
uv sync --frozen
|
|
30
|
+
uv run pytest tests/ -q
|
|
31
|
+
|
|
32
|
+
- name: Build wheel + sdist
|
|
33
|
+
run: uv build
|
|
34
|
+
|
|
35
|
+
- name: Publish to PyPI (Trusted Publishing)
|
|
36
|
+
uses: pypa/gh-action-pypi-publish@release/v1
|
|
37
|
+
|
|
38
|
+
- name: Create GitHub release
|
|
39
|
+
env:
|
|
40
|
+
GH_TOKEN: ${{ github.token }}
|
|
41
|
+
run: gh release create "${GITHUB_REF_NAME}" dist/* --generate-notes
|
shikhu-0.1.0/.gitignore
ADDED
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
.env
|
|
2
|
+
coverage.db
|
|
3
|
+
.quizignore
|
|
4
|
+
__pycache__/
|
|
5
|
+
.venv/
|
|
6
|
+
venv/
|
|
7
|
+
dist/
|
|
8
|
+
benchmark_dataset_*.json
|
|
9
|
+
|
|
10
|
+
# vet skill installs (per-harness, local tooling — not project deliverables)
|
|
11
|
+
.agents/
|
|
12
|
+
.codex/
|
|
13
|
+
.opencode/
|
|
14
|
+
.claude/skills/vet/
|
|
15
|
+
|
|
16
|
+
# local scratch / dogfooding artifacts
|
|
17
|
+
trial_run.md
|
|
18
|
+
workflows.html
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
3.12
|
shikhu-0.1.0/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Arjun Patel
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
shikhu-0.1.0/PKG-INFO
ADDED
|
@@ -0,0 +1,193 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: shikhu
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: Knowledge coverage for your codebase
|
|
5
|
+
License-Expression: MIT
|
|
6
|
+
License-File: LICENSE
|
|
7
|
+
Requires-Python: >=3.12
|
|
8
|
+
Requires-Dist: anthropic>=0.84.0
|
|
9
|
+
Requires-Dist: pydantic>=2.13.4
|
|
10
|
+
Requires-Dist: python-dotenv>=1.2.2
|
|
11
|
+
Requires-Dist: requests>=2.34.2
|
|
12
|
+
Requires-Dist: rich>=13.0.0
|
|
13
|
+
Requires-Dist: typer>=0.26.2
|
|
14
|
+
Provides-Extra: evals
|
|
15
|
+
Requires-Dist: gliner2>=1.3.1; extra == 'evals'
|
|
16
|
+
Provides-Extra: mcp
|
|
17
|
+
Requires-Dist: fastmcp[apps]>=3.3.1; extra == 'mcp'
|
|
18
|
+
Requires-Dist: mcp[cli]>=1.27.1; extra == 'mcp'
|
|
19
|
+
Description-Content-Type: text/markdown
|
|
20
|
+
|
|
21
|
+
# Project Shikhu
|
|
22
|
+
|
|
23
|
+
[](https://github.com/arjunpatel7/shikhu/actions/workflows/ci.yml)
|
|
24
|
+
|
|
25
|
+
Project Shikhu helps you learn your codebases that you generate with AI.
|
|
26
|
+
|
|
27
|
+
Use shikhu to study your codebase, track your understanding, and increase your understanding of your code. Shikhu does this by learning about your files, generating quizzes for you to take, and even by helping you study the code after you make it.
|
|
28
|
+
|
|
29
|
+
Conceptual understanding is measured by **knowledge coverage** — the share of your codebase backed by *golden questions* (questions you answered correctly *and* confirmed actually test understanding of the file). Three goldens per file = fully covered.
|
|
30
|
+
|
|
31
|
+
Think test coverage, but for your brain!
|
|
32
|
+
|
|
33
|
+
## Getting Started
|
|
34
|
+
|
|
35
|
+
Prerequisites:
|
|
36
|
+
- An **Inception API key** (required). This gives you access to fast, text-diffusion models for question generation and summarization. You can get one for free at [Inception Labs](https://platform.inceptionlabs.ai/).
|
|
37
|
+
- A **skill-compatible coding agent** like Claude Code, Codex, or Cursor (strongly recommended). The core loop — `refresh`, `quiz`, `coverage` — runs entirely in your terminal, but Shikhu really shines when paired with the `/study` skill (step 5): it turns "I don't get this file" into a guided walkthrough *and* feeds your weak spots back into future quizzes.
|
|
38
|
+
|
|
39
|
+
### 1. Install
|
|
40
|
+
|
|
41
|
+
**To use Shikhu on your own codebase** — install it as a standalone tool, then run it from inside any repo:
|
|
42
|
+
|
|
43
|
+
```bash
|
|
44
|
+
uv tool install git+https://github.com/arjunpatel7/shikhu.git
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
This puts `shikhu` on your `PATH` in an isolated environment (no clash with your project's dependencies). `cd` into any repo and the commands below just work — each repo gets its own `coverage.db`, `.quizignore`, and `.env`. (`pipx install git+…` or `pip install git+…` into a virtualenv work too.)
|
|
48
|
+
|
|
49
|
+
Provide your Mercury API key via a `.env` file in the repo you're quizzing (auto-loaded), or export it in your shell:
|
|
50
|
+
```
|
|
51
|
+
INCEPTION_API_KEY=your-key-here
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
Get a key at [Inception Labs](https://www.inceptionlabs.ai/).
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
### 2. Initialize
|
|
58
|
+
|
|
59
|
+
```bash
|
|
60
|
+
shikhu init
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
This creates a database and a `.quizignore` file (like `.gitignore` but for quiz generation). Add files to the latter to avoid getting quizzed on them, like config or docfiles.
|
|
64
|
+
|
|
65
|
+
### 3. Generate questions
|
|
66
|
+
|
|
67
|
+
Next, you're ready to batch some questions. Run the following command:
|
|
68
|
+
|
|
69
|
+
```bash
|
|
70
|
+
shikhu refresh
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
Shikhu scans your tracked files, checks for stale questions, and generates new ones using the Mercury API. Files matching `.quizignore` patterns are skipped.
|
|
74
|
+
|
|
75
|
+
Under the hood, `refresh` runs two passes in parallel: **summaries** (a cached Mercury summary per file, used to seed question generation and to feed `/study`) and **questions** (one batch per file). Both skip files whose content hash and prompt version haven't changed, so re-running `refresh` after a small edit only regenerates the files that actually changed. If you only want to refresh summaries, run `shikhu summarize`; tune parallelism with `--summary-workers` (default 8).
|
|
76
|
+
|
|
77
|
+
### 4. Take a quiz
|
|
78
|
+
|
|
79
|
+
After working on your code base, it's time to take a quiz!
|
|
80
|
+
|
|
81
|
+
(document any args here too)
|
|
82
|
+
|
|
83
|
+
```bash
|
|
84
|
+
shikhu quiz
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
You'll get multiple-choice questions about your code. After each answer you can rate the question quality — good questions that you answer correctly can become **golden questions**. These are eventually used as measures of knowledge coverage. You'll have **3 golden questions** per file, and passing all of them represents basic understanding of the file.
|
|
88
|
+
|
|
89
|
+
`shikhu quiz` has a couple of flags worth knowing:
|
|
90
|
+
- `--n <int>` — number of questions in the round (default 5)
|
|
91
|
+
- `--file <path>` — quiz only on one file (handy after editing it)
|
|
92
|
+
|
|
93
|
+
**What happens to old questions?** When you edit a file, Shikhu detects the change (via content hash) and marks that file's questions stale on the next `refresh`. Stale questions stick around in the database — nothing is deleted — and `refresh` generates a fresh batch on top.
|
|
94
|
+
|
|
95
|
+
Golden questions get special treatment. If a file changes after you mastered it, those goldens are flagged for **re-validation**: they come up first in your next quiz so you can prove the change didn't break your understanding. Answer correctly and they go back to golden + fresh; answer wrong and they lose golden status (your coverage updates accordingly).
|
|
96
|
+
|
|
97
|
+
### 5. Drill weak spots with `/study` (optional)
|
|
98
|
+
|
|
99
|
+
When a quiz surfaces a file you don't really understand, use the project's `/study` skill (inside your agent) to walk through it. The skill loads a cached summary, takes you through the file, and **logs every conceptual question you ask** to the database.
|
|
100
|
+
|
|
101
|
+
Then turn those questions into quiz questions that test the same concepts:
|
|
102
|
+
|
|
103
|
+
```bash
|
|
104
|
+
shikhu generate-from-study path/to/file.py
|
|
105
|
+
shikhu quiz --file path/to/file.py
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
This reinforces exactly the gaps you surfaced during study — not generic file-level questions.
|
|
109
|
+
|
|
110
|
+
### 6. Check your coverage
|
|
111
|
+
|
|
112
|
+
Wanna know how well you know your codebase? Run this commmand
|
|
113
|
+
|
|
114
|
+
```bash
|
|
115
|
+
shikhu coverage
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
Shows which files you've mastered and which need work. Each file needs 3 golden questions to be fully covered.
|
|
119
|
+
|
|
120
|
+
## All Commands
|
|
121
|
+
|
|
122
|
+
| Command | What it does |
|
|
123
|
+
|---------|-------------|
|
|
124
|
+
| `shikhu init` | Set up database, check API keys, create `.quizignore` |
|
|
125
|
+
| `shikhu quiz` | Take a quiz (default 5 questions) |
|
|
126
|
+
| `shikhu quiz --n 10` | Quiz with 10 questions |
|
|
127
|
+
| `shikhu quiz --file path.py` | Quiz on a single file |
|
|
128
|
+
| `shikhu refresh` | Staleness check + regenerate stale questions and summaries |
|
|
129
|
+
| `shikhu summarize` | Parallel Mercury summaries for every tracked file |
|
|
130
|
+
| `shikhu summarize --file path.py` | Force-regenerate summary for one file |
|
|
131
|
+
| `shikhu generate-from-study path.py` | Generate quiz Qs seeded by your prior `/study` questions for that file |
|
|
132
|
+
| `shikhu coverage` | Print knowledge-coverage report |
|
|
133
|
+
| `shikhu clean` | Delete the database (asks for confirmation) |
|
|
134
|
+
| `shikhu clean --yes` | Delete without confirmation |
|
|
135
|
+
|
|
136
|
+
|
|
137
|
+
## How It Works
|
|
138
|
+
|
|
139
|
+
1. **Question generation** — Mercury (Inception Labs) reads your source files and generates conceptual multiple-choice questions about design decisions, architecture, and how things work.
|
|
140
|
+
|
|
141
|
+
2. **Quizzing** — Answer questions in the terminal. Rate question quality. Correct answers on good questions become **golden** — validated proof you understand that file.
|
|
142
|
+
|
|
143
|
+
3. **Coverage tracking** — Each file targets 3 golden questions. Coverage = how many files have reached that bar.
|
|
144
|
+
|
|
145
|
+
4. **Staleness** — When code changes (detected via SHA-256 hashing), related questions are marked stale so your coverage stays honest.
|
|
146
|
+
|
|
147
|
+
5. **Study-driven generation** — `/study` captures the conceptual questions you actually ask while learning a file. `shikhu generate-from-study` turns those into quiz questions, so the next quiz tests the gaps you surfaced — not just whatever Mercury picks from the file.
|
|
148
|
+
|
|
149
|
+
## Golden Questions
|
|
150
|
+
|
|
151
|
+
A golden question is one you:
|
|
152
|
+
- Answered correctly
|
|
153
|
+
- Rated as good quality
|
|
154
|
+
- Confirmed it tests real understanding of the file
|
|
155
|
+
|
|
156
|
+
3 golden questions per file = fully covered. Golden questions go stale when the underlying code changes, keeping coverage honest over time.
|
|
157
|
+
|
|
158
|
+
## Privacy & Data
|
|
159
|
+
|
|
160
|
+
Everything Shikhu knows lives in one local SQLite file, `coverage.db`, in the repo you run it from. Nothing is uploaded anywhere. Two things are worth knowing:
|
|
161
|
+
|
|
162
|
+
- **File contents are sent to the Mercury API** (Inception Labs) to generate questions and summaries — that's the only data that leaves your machine, under your own API key. Use `.quizignore` to exclude anything you don't want sent.
|
|
163
|
+
- **Shikhu reads your local Claude Code transcripts** for the current project (`~/.claude/projects/...`) to find conceptual questions you've asked, and stores them in `coverage.db` to seed better quiz questions. These prompts never leave your machine — but it's one more reason `coverage.db` must stay out of git. `shikhu init` adds it to your `.gitignore` automatically.
|
|
164
|
+
|
|
165
|
+
## Configuration
|
|
166
|
+
|
|
167
|
+
### `.quizignore`
|
|
168
|
+
|
|
169
|
+
Controls which files are skipped during generation:
|
|
170
|
+
```
|
|
171
|
+
# Skip these
|
|
172
|
+
*.lock
|
|
173
|
+
.claude/
|
|
174
|
+
tests/
|
|
175
|
+
deprecated/
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
### Environment Variables
|
|
179
|
+
|
|
180
|
+
| Variable | Required | Purpose |
|
|
181
|
+
|----------|----------|---------|
|
|
182
|
+
| `INCEPTION_API_KEY` | Yes | Mercury API for question generation |
|
|
183
|
+
|
|
184
|
+
## Tech
|
|
185
|
+
|
|
186
|
+
- Python 3.12+, managed with [uv](https://docs.astral.sh/uv/)
|
|
187
|
+
- [Mercury](https://www.inceptionlabs.ai/) for question generation
|
|
188
|
+
- [Typer](https://typer.tiangolo.com/) + [Rich](https://rich.readthedocs.io/) for the CLI
|
|
189
|
+
- SQLite for local storage
|
|
190
|
+
- SHA-256 file hashing for staleness detection
|
|
191
|
+
|
|
192
|
+
## Love the repo and have some ideas?
|
|
193
|
+
Feel free to open an issue! We aren't accepting PRs at this time.
|
shikhu-0.1.0/README.md
ADDED
|
@@ -0,0 +1,173 @@
|
|
|
1
|
+
# Project Shikhu
|
|
2
|
+
|
|
3
|
+
[](https://github.com/arjunpatel7/shikhu/actions/workflows/ci.yml)
|
|
4
|
+
|
|
5
|
+
Project Shikhu helps you learn your codebases that you generate with AI.
|
|
6
|
+
|
|
7
|
+
Use shikhu to study your codebase, track your understanding, and increase your understanding of your code. Shikhu does this by learning about your files, generating quizzes for you to take, and even by helping you study the code after you make it.
|
|
8
|
+
|
|
9
|
+
Conceptual understanding is measured by **knowledge coverage** — the share of your codebase backed by *golden questions* (questions you answered correctly *and* confirmed actually test understanding of the file). Three goldens per file = fully covered.
|
|
10
|
+
|
|
11
|
+
Think test coverage, but for your brain!
|
|
12
|
+
|
|
13
|
+
## Getting Started
|
|
14
|
+
|
|
15
|
+
Prerequisites:
|
|
16
|
+
- An **Inception API key** (required). This gives you access to fast, text-diffusion models for question generation and summarization. You can get one for free at [Inception Labs](https://platform.inceptionlabs.ai/).
|
|
17
|
+
- A **skill-compatible coding agent** like Claude Code, Codex, or Cursor (strongly recommended). The core loop — `refresh`, `quiz`, `coverage` — runs entirely in your terminal, but Shikhu really shines when paired with the `/study` skill (step 5): it turns "I don't get this file" into a guided walkthrough *and* feeds your weak spots back into future quizzes.
|
|
18
|
+
|
|
19
|
+
### 1. Install
|
|
20
|
+
|
|
21
|
+
**To use Shikhu on your own codebase** — install it as a standalone tool, then run it from inside any repo:
|
|
22
|
+
|
|
23
|
+
```bash
|
|
24
|
+
uv tool install git+https://github.com/arjunpatel7/shikhu.git
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
This puts `shikhu` on your `PATH` in an isolated environment (no clash with your project's dependencies). `cd` into any repo and the commands below just work — each repo gets its own `coverage.db`, `.quizignore`, and `.env`. (`pipx install git+…` or `pip install git+…` into a virtualenv work too.)
|
|
28
|
+
|
|
29
|
+
Provide your Mercury API key via a `.env` file in the repo you're quizzing (auto-loaded), or export it in your shell:
|
|
30
|
+
```
|
|
31
|
+
INCEPTION_API_KEY=your-key-here
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Get a key at [Inception Labs](https://www.inceptionlabs.ai/).
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
### 2. Initialize
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
shikhu init
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
This creates a database and a `.quizignore` file (like `.gitignore` but for quiz generation). Add files to the latter to avoid getting quizzed on them, like config or docfiles.
|
|
44
|
+
|
|
45
|
+
### 3. Generate questions
|
|
46
|
+
|
|
47
|
+
Next, you're ready to batch some questions. Run the following command:
|
|
48
|
+
|
|
49
|
+
```bash
|
|
50
|
+
shikhu refresh
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
Shikhu scans your tracked files, checks for stale questions, and generates new ones using the Mercury API. Files matching `.quizignore` patterns are skipped.
|
|
54
|
+
|
|
55
|
+
Under the hood, `refresh` runs two passes in parallel: **summaries** (a cached Mercury summary per file, used to seed question generation and to feed `/study`) and **questions** (one batch per file). Both skip files whose content hash and prompt version haven't changed, so re-running `refresh` after a small edit only regenerates the files that actually changed. If you only want to refresh summaries, run `shikhu summarize`; tune parallelism with `--summary-workers` (default 8).
|
|
56
|
+
|
|
57
|
+
### 4. Take a quiz
|
|
58
|
+
|
|
59
|
+
After working on your code base, it's time to take a quiz!
|
|
60
|
+
|
|
61
|
+
(document any args here too)
|
|
62
|
+
|
|
63
|
+
```bash
|
|
64
|
+
shikhu quiz
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
You'll get multiple-choice questions about your code. After each answer you can rate the question quality — good questions that you answer correctly can become **golden questions**. These are eventually used as measures of knowledge coverage. You'll have **3 golden questions** per file, and passing all of them represents basic understanding of the file.
|
|
68
|
+
|
|
69
|
+
`shikhu quiz` has a couple of flags worth knowing:
|
|
70
|
+
- `--n <int>` — number of questions in the round (default 5)
|
|
71
|
+
- `--file <path>` — quiz only on one file (handy after editing it)
|
|
72
|
+
|
|
73
|
+
**What happens to old questions?** When you edit a file, Shikhu detects the change (via content hash) and marks that file's questions stale on the next `refresh`. Stale questions stick around in the database — nothing is deleted — and `refresh` generates a fresh batch on top.
|
|
74
|
+
|
|
75
|
+
Golden questions get special treatment. If a file changes after you mastered it, those goldens are flagged for **re-validation**: they come up first in your next quiz so you can prove the change didn't break your understanding. Answer correctly and they go back to golden + fresh; answer wrong and they lose golden status (your coverage updates accordingly).
|
|
76
|
+
|
|
77
|
+
### 5. Drill weak spots with `/study` (optional)
|
|
78
|
+
|
|
79
|
+
When a quiz surfaces a file you don't really understand, use the project's `/study` skill (inside your agent) to walk through it. The skill loads a cached summary, takes you through the file, and **logs every conceptual question you ask** to the database.
|
|
80
|
+
|
|
81
|
+
Then turn those questions into quiz questions that test the same concepts:
|
|
82
|
+
|
|
83
|
+
```bash
|
|
84
|
+
shikhu generate-from-study path/to/file.py
|
|
85
|
+
shikhu quiz --file path/to/file.py
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
This reinforces exactly the gaps you surfaced during study — not generic file-level questions.
|
|
89
|
+
|
|
90
|
+
### 6. Check your coverage
|
|
91
|
+
|
|
92
|
+
Wanna know how well you know your codebase? Run this commmand
|
|
93
|
+
|
|
94
|
+
```bash
|
|
95
|
+
shikhu coverage
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
Shows which files you've mastered and which need work. Each file needs 3 golden questions to be fully covered.
|
|
99
|
+
|
|
100
|
+
## All Commands
|
|
101
|
+
|
|
102
|
+
| Command | What it does |
|
|
103
|
+
|---------|-------------|
|
|
104
|
+
| `shikhu init` | Set up database, check API keys, create `.quizignore` |
|
|
105
|
+
| `shikhu quiz` | Take a quiz (default 5 questions) |
|
|
106
|
+
| `shikhu quiz --n 10` | Quiz with 10 questions |
|
|
107
|
+
| `shikhu quiz --file path.py` | Quiz on a single file |
|
|
108
|
+
| `shikhu refresh` | Staleness check + regenerate stale questions and summaries |
|
|
109
|
+
| `shikhu summarize` | Parallel Mercury summaries for every tracked file |
|
|
110
|
+
| `shikhu summarize --file path.py` | Force-regenerate summary for one file |
|
|
111
|
+
| `shikhu generate-from-study path.py` | Generate quiz Qs seeded by your prior `/study` questions for that file |
|
|
112
|
+
| `shikhu coverage` | Print knowledge-coverage report |
|
|
113
|
+
| `shikhu clean` | Delete the database (asks for confirmation) |
|
|
114
|
+
| `shikhu clean --yes` | Delete without confirmation |
|
|
115
|
+
|
|
116
|
+
|
|
117
|
+
## How It Works
|
|
118
|
+
|
|
119
|
+
1. **Question generation** — Mercury (Inception Labs) reads your source files and generates conceptual multiple-choice questions about design decisions, architecture, and how things work.
|
|
120
|
+
|
|
121
|
+
2. **Quizzing** — Answer questions in the terminal. Rate question quality. Correct answers on good questions become **golden** — validated proof you understand that file.
|
|
122
|
+
|
|
123
|
+
3. **Coverage tracking** — Each file targets 3 golden questions. Coverage = how many files have reached that bar.
|
|
124
|
+
|
|
125
|
+
4. **Staleness** — When code changes (detected via SHA-256 hashing), related questions are marked stale so your coverage stays honest.
|
|
126
|
+
|
|
127
|
+
5. **Study-driven generation** — `/study` captures the conceptual questions you actually ask while learning a file. `shikhu generate-from-study` turns those into quiz questions, so the next quiz tests the gaps you surfaced — not just whatever Mercury picks from the file.
|
|
128
|
+
|
|
129
|
+
## Golden Questions
|
|
130
|
+
|
|
131
|
+
A golden question is one you:
|
|
132
|
+
- Answered correctly
|
|
133
|
+
- Rated as good quality
|
|
134
|
+
- Confirmed it tests real understanding of the file
|
|
135
|
+
|
|
136
|
+
3 golden questions per file = fully covered. Golden questions go stale when the underlying code changes, keeping coverage honest over time.
|
|
137
|
+
|
|
138
|
+
## Privacy & Data
|
|
139
|
+
|
|
140
|
+
Everything Shikhu knows lives in one local SQLite file, `coverage.db`, in the repo you run it from. Nothing is uploaded anywhere. Two things are worth knowing:
|
|
141
|
+
|
|
142
|
+
- **File contents are sent to the Mercury API** (Inception Labs) to generate questions and summaries — that's the only data that leaves your machine, under your own API key. Use `.quizignore` to exclude anything you don't want sent.
|
|
143
|
+
- **Shikhu reads your local Claude Code transcripts** for the current project (`~/.claude/projects/...`) to find conceptual questions you've asked, and stores them in `coverage.db` to seed better quiz questions. These prompts never leave your machine — but it's one more reason `coverage.db` must stay out of git. `shikhu init` adds it to your `.gitignore` automatically.
|
|
144
|
+
|
|
145
|
+
## Configuration
|
|
146
|
+
|
|
147
|
+
### `.quizignore`
|
|
148
|
+
|
|
149
|
+
Controls which files are skipped during generation:
|
|
150
|
+
```
|
|
151
|
+
# Skip these
|
|
152
|
+
*.lock
|
|
153
|
+
.claude/
|
|
154
|
+
tests/
|
|
155
|
+
deprecated/
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
### Environment Variables
|
|
159
|
+
|
|
160
|
+
| Variable | Required | Purpose |
|
|
161
|
+
|----------|----------|---------|
|
|
162
|
+
| `INCEPTION_API_KEY` | Yes | Mercury API for question generation |
|
|
163
|
+
|
|
164
|
+
## Tech
|
|
165
|
+
|
|
166
|
+
- Python 3.12+, managed with [uv](https://docs.astral.sh/uv/)
|
|
167
|
+
- [Mercury](https://www.inceptionlabs.ai/) for question generation
|
|
168
|
+
- [Typer](https://typer.tiangolo.com/) + [Rich](https://rich.readthedocs.io/) for the CLI
|
|
169
|
+
- SQLite for local storage
|
|
170
|
+
- SHA-256 file hashing for staleness detection
|
|
171
|
+
|
|
172
|
+
## Love the repo and have some ideas?
|
|
173
|
+
Feel free to open an issue! We aren't accepting PRs at this time.
|