Conversation
📝 WalkthroughWalkthroughAdds persistent task management: new SQLite-backed tasks table and migrations, Task DAO with CRUD & cascading soft-delete, a Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI as "june task"
participant Repo as "GitRepo (repo/branch)"
participant DB as "SQLite (~/.june/june.db)"
User->>CLI: june task create --title "T1" [--parent t-...]
CLI->>Repo: determine repo root & branch (scope)
CLI->>DB: open DB connection
CLI->>DB: generateUniqueTaskID -> GetTask (collision check)
DB-->>CLI: not-found / unique id
CLI->>DB: CreateTask(id, repo_path, branch, title, ...)
DB-->>CLI: success
CLI-->>User: print created task (human or --json)
sequenceDiagram
participant User
participant CLI as "june task"
participant DB as "SQLite (~/.june/june.db)"
User->>CLI: june task delete t-12345
CLI->>DB: DeleteTask (validate & soft-delete, recursive CTE)
DB-->>CLI: success
CLI-->>User: confirmation / updated list reflects deletion
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Comment |
Adds database schema for task persistence with support for: - Hierarchical tasks via parent_id foreign key - Soft delete via deleted_at column - Git scope via repo_path and branch columns - Indexes for common query patterns Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…mmands Includes: - create: Create one or more tasks, with optional --parent flag - list: List root tasks or show task details with children - update: Update status, note, or title - delete: Soft-delete with cascade to children - JSON output support via --json flag Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This pull request adds a comprehensive persistent task management system to the June CLI tool. The feature allows orchestrators and users to track tasks that survive context compaction by storing them in a SQLite database.
Key changes:
- SQLite-backed task persistence with CRUD operations
- Parent/child task hierarchy with cascade delete
- Tasks scoped to git repository and branch
- CLI commands for task management (create, list, update, delete)
Reviewed changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 12 comments.
Show a summary per file
| File | Description |
|---|---|
| internal/db/task.go | Core database operations for tasks (Create, Get, Update, Delete, List) |
| internal/db/task_test.go | Comprehensive unit tests for task database operations |
| internal/db/db.go | Database schema and migration logic for tasks table |
| internal/db/db_test.go | Migration tests ensuring tasks table creation |
| internal/cli/task.go | CLI command implementation for task management |
| internal/cli/task_test.go | Unit tests for CLI task commands |
| internal/cli/task_integration_test.go | End-to-end integration tests for task workflows |
| internal/cli/taskid.go | Task ID generation with collision retry |
| internal/cli/taskid_test.go | Tests for ID generation logic |
| internal/cli/root.go | Registration of task command in root CLI |
| README.md | User documentation for task commands |
| CLAUDE.md | Developer documentation for task feature |
| docs/plans/ | Design and implementation planning documents |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
internal/db/db.go (1)
53-82: Fix multi-statement schema execution and enable foreign key constraints.The
schemaconstant contains multiple SQL statements, butdatabase/sql'sExec()method executes only the first statement per call. This meansdb.Exec(schema)at line 109 only creates theagentstable; thetaskstable and indexes are never created from the schema string. Themigrate()function then (correctly, by accident) creates the tasks table as a workaround.Split schema statements into individual
Exec()calls inOpen(), or restructure the initialization to handle multi-statement setup properly. Additionally, theFOREIGN KEYconstraint onparent_idwill not be enforced unlessPRAGMA foreign_keys = ONis enabled via the DSN parameter (_pragma=foreign_keys(1)) or explicitly after opening the connection.Suggested fixes:
- Split schema statements: call
db.Exec()once per statement (or move non-agents DDL tomigrate())- Enable foreign key pragma in DSN:
sql.Open("sqlite", "file:" + path + "?_pragma=foreign_keys(1)")
🤖 Fix all issues with AI agents
In @internal/cli/taskid_test.go:
- Around line 58-82: TestGenerateUniqueTaskIDRetriesOnCollision currently
ignores the return value/error from database.CreateTask which can let the test
false-pass; update the test to capture and assert the error from
database.CreateTask (e.g., check error != nil and t.Fatalf on error) when
creating the initial task with ID "t-12345" so the setup fails the test if the
insert fails.
In @internal/cli/taskid.go:
- Around line 22-37: generateUniqueTaskID currently compares the GetTask error
directly to db.ErrTaskNotFound and ignores potential errors from generateTaskID;
update it to use errors.Is(err, db.ErrTaskNotFound) when checking the GetTask
result and explicitly check/propagate any error returned by generateTaskID
before calling database.GetTask; keep the retry loop and return the same final
error message on exhaustion, but ensure you import and use the standard errors
package for the Is check and return generateTaskID errors wrapped (or
propagated) so caller can see generation failures.
- Around line 11-20: The generateTaskID function must stop panicking and return
an error: change its signature to generateTaskID() (string, error), call
rand.Read(b) on a 3-byte slice and if it returns an error return "", err (no
panic); avoid the fmt/slice trick by using hex.EncodeToString(b) (or build the
hex string with %02x per byte) and take the first 5 hex characters, then return
"t-"+hex[:5], nil; update all callers to handle the (string, error) result.
In @internal/db/task.go:
- Around line 65-70: GetTask and scanTasks currently ignore errors from
time.Parse when setting t.CreatedAt, t.UpdatedAt, and t.DeletedAt, which can
hide malformed timestamps; update both functions to capture and handle parse
errors instead of discarding them: check the error returned by time.Parse for
CreatedAt and UpdatedAt and return or wrap a descriptive error (including the
raw timestamp and field name) from GetTask (and from scanTasks where used), and
for DeletedAt ensure you validate the pointer value parse and propagate the
error rather than silently leaving a nil/zero time; reference the t.CreatedAt,
t.UpdatedAt, t.DeletedAt fields and the GetTask and scanTasks functions when
making these changes so callers receive a clear error if timestamps are
malformed.
- Around line 170-210: DeleteTask can leave children marked deleted if the
parent update later fails; wrap the cascade and parent update in a DB
transaction: begin a transaction (e.g. d.BeginTx / tx), run the recursive
descendants UPDATE and the parent UPDATE using tx.Exec instead of d.Exec, check
the parent UPDATE RowsAffected from the tx result, and commit; on any error
rollback and return the wrapped error. Ensure GetTask is still used to validate
existence before starting the transaction or run it inside the transaction if
you need a consistent read.
🧹 Nitpick comments (9)
README.md (1)
40-64: Docs are clear; consider documenting allowed--statusvalues and--jsonexample.internal/db/task_test.go (1)
149-149: Consider checking the CreateTask error.The error from
db.CreateTask(task)is ignored here. While subsequent operations would fail if creation failed, explicitly checking errors improves test diagnostics.Suggested fix
- db.CreateTask(task) + if err := db.CreateTask(task); err != nil { + t.Fatalf("CreateTask failed: %v", err) + }internal/cli/task.go (1)
200-207: CountChildren errors silently ignored.The error from
database.CountChildren(t.ID)is discarded. While acceptable for display purposes (showing 0 on error), consider logging at debug level for troubleshooting.internal/cli/task_integration_test.go (1)
23-25: Git command errors are not checked.The
exec.Command("git", ...).Run()calls ignore errors. If git is not available or initialization fails, the test may produce confusing failures later.Suggested fix
- exec.Command("git", "init").Run() - exec.Command("git", "checkout", "-b", "feature-auth").Run() + if err := exec.Command("git", "init").Run(); err != nil { + t.Fatalf("git init failed: %v", err) + } + if err := exec.Command("git", "checkout", "-b", "feature-auth").Run(); err != nil { + t.Fatalf("git checkout failed: %v", err) + }internal/cli/task_test.go (4)
34-51: Missing error handling in test setup.The setup helper ignores errors from
os.MkdirAll,os.Getwd,os.Chdir, and git commands. While tests may still catch failures downstream, silent failures in setup can lead to confusing test results.♻️ Proposed fix
func setupTestRepo(t *testing.T) string { t.Helper() tmpDir := t.TempDir() t.Setenv("JUNE_HOME", tmpDir) repoDir := filepath.Join(tmpDir, "repo") - os.MkdirAll(repoDir, 0755) + if err := os.MkdirAll(repoDir, 0755); err != nil { + t.Fatalf("MkdirAll: %v", err) + } // Save current dir - origDir, _ := os.Getwd() - t.Cleanup(func() { os.Chdir(origDir) }) + origDir, err := os.Getwd() + if err != nil { + t.Fatalf("Getwd: %v", err) + } + t.Cleanup(func() { + if err := os.Chdir(origDir); err != nil { + t.Errorf("Chdir cleanup: %v", err) + } + }) - os.Chdir(repoDir) - exec.Command("git", "init").Run() - exec.Command("git", "checkout", "-b", "main").Run() + if err := os.Chdir(repoDir); err != nil { + t.Fatalf("Chdir: %v", err) + } + if err := exec.Command("git", "init").Run(); err != nil { + t.Fatalf("git init: %v", err) + } + if err := exec.Command("git", "checkout", "-b", "main").Run(); err != nil { + t.Fatalf("git checkout: %v", err) + } return repoDir }
53-73: Tests lack error checking on intermediate commands.In
TestTaskCreateWithParentandTestTaskCreateMultiple, the firstcmd.Execute()calls don't check for errors. If the first create fails, the test continues with invalid state.♻️ Example fix for TestTaskCreateWithParent
// Create parent first cmd := newTaskCmd() cmd.SetArgs([]string{"create", "Parent task"}) var stdout bytes.Buffer cmd.SetOut(&stdout) - cmd.Execute() + if err := cmd.Execute(); err != nil { + t.Fatalf("Create parent failed: %v", err) + }Also applies to: 75-102, 104-122
83-91: Potential issue: Reusing buffer without resetting before second command.When creating the child task,
stdout.Reset()is called after setting it on the new command. The buffer should be reset before being assigned to ensure clean state.♻️ Proposed fix
// Create child cmd = newTaskCmd() cmd.SetArgs([]string{"create", "Child task", "--parent", parentID}) - stdout.Reset() - cmd.SetOut(&stdout) + var childOut bytes.Buffer + cmd.SetOut(&childOut) err := cmd.Execute() if err != nil { t.Fatalf("Execute failed: %v", err) } - childID := strings.TrimSpace(stdout.String()) + childID := strings.TrimSpace(childOut.String())
124-153: Consider adding negative test cases.The tests cover the happy paths well. Consider adding tests for error scenarios:
- Creating a task with a non-existent parent ID
- Updating/deleting a non-existent task
- Updating with invalid status values
Also applies to: 155-190, 192-223, 225-251, 253-284
internal/db/task.go (1)
27-42: CreateTask ignores the passedDeletedAtfield.Line 35 hardcodes
nilfordeleted_at, which is fine for normal creation. However, the function signature accepts a fullTaskstruct that includesDeletedAt, which could mislead callers into thinking they can set it.Consider either:
- Documenting that
DeletedAtis ignored on creation, or- Creating a dedicated
CreateTaskInputstruct withoutDeletedAt
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @docs/plans/2026-01-07-task-persistence-design.md:
- Line 30: The docs claim IDs use a "4-char hash" but examples and the
implementation (see internal/cli/taskid.go and examples like t-a3f8b) use 5 hex
characters after the "t-" prefix; update the documentation text to say "5-char
hex hash" (or "5 hex characters") to match the implementation and examples, or
alternatively change internal/cli/taskid.go and example IDs to generate/reflect
4 characters—pick the former to keep current examples and adjust the line
describing "ID format" accordingly.
🧹 Nitpick comments (7)
internal/db/db.go (1)
72-88: Consider DRYing up the tasks schema definition.The tasks table schema is defined here in the
schemaconstant and again in the migration function (lines 169-184). This duplication could lead to inconsistencies if one definition is updated without the other.♻️ Potential refactor approach
Consider extracting the tasks table DDL into a constant that can be reused:
const tasksTableDDL = ` CREATE TABLE IF NOT EXISTS tasks ( id TEXT PRIMARY KEY, parent_id TEXT, title TEXT NOT NULL, status TEXT NOT NULL DEFAULT 'open', notes TEXT, created_at TEXT NOT NULL, updated_at TEXT NOT NULL, deleted_at TEXT, repo_path TEXT NOT NULL, branch TEXT NOT NULL, FOREIGN KEY (parent_id) REFERENCES tasks(id) ); CREATE INDEX IF NOT EXISTS idx_tasks_parent ON tasks(parent_id); CREATE INDEX IF NOT EXISTS idx_tasks_scope ON tasks(repo_path, branch); CREATE INDEX IF NOT EXISTS idx_tasks_status ON tasks(status); `Then reference it in both the schema constant and the migration function.
internal/cli/task.go (2)
200-207: Silently ignored errors fromCountChildren.The error from
database.CountChildren()is discarded with_. While the child count is non-critical for display, consider logging a warning if the count fails, as it could indicate database issues.- childCount, _ := database.CountChildren(t.ID) + childCount, err := database.CountChildren(t.ID) + if err != nil { + // Log warning but continue - child count is non-critical + }Also applies to: 218-224
146-150: Consider usingjson.Marshalfor JSON output consistency.The JSON output is manually constructed with
fmt.Fprintf. While the task ID format (t-xxxxx) won't contain problematic characters, usingjson.Marshalwould be more robust and consistent with the JSON output inlistRootTasks.♻️ Suggested refactor
if outputJSON { - fmt.Fprintf(out, `{"id":"%s"}`+"\n", id) + enc := json.NewEncoder(out) + enc.Encode(map[string]string{"id": id}) } else { fmt.Fprintln(out, id) }internal/cli/task_integration_test.go (1)
23-25: Consider checking git command errors in tests.The
exec.Command(...).Run()calls ignore errors. While test assertions would eventually fail if git isn't available, explicit error checking would provide clearer failure messages.♻️ Suggested improvement
- exec.Command("git", "init").Run() - exec.Command("git", "checkout", "-b", "feature-auth").Run() + if err := exec.Command("git", "init").Run(); err != nil { + t.Skipf("git not available: %v", err) + } + if err := exec.Command("git", "checkout", "-b", "feature-auth").Run(); err != nil { + t.Fatalf("git checkout failed: %v", err) + }internal/db/task.go (3)
44-73: Silently ignored time parsing errors.The
time.Parsecalls at lines 65-66 and 68-69 ignore errors. While timestamps stored viaCreateTaskshould always be valid RFC3339, corrupted data would result in zero-value times without indication.♻️ Optional: Log or propagate parse errors
- t.CreatedAt, _ = time.Parse(time.RFC3339, createdAt) - t.UpdatedAt, _ = time.Parse(time.RFC3339, updatedAt) + var parseErr error + t.CreatedAt, parseErr = time.Parse(time.RFC3339, createdAt) + if parseErr != nil { + return nil, fmt.Errorf("parse created_at: %w", parseErr) + } + t.UpdatedAt, parseErr = time.Parse(time.RFC3339, updatedAt) + if parseErr != nil { + return nil, fmt.Errorf("parse updated_at: %w", parseErr) + }
170-210: DeleteTask lacks transaction for atomicity.The cascade delete performs two separate
Execcalls (children, then parent). If the process crashes between these calls, children could be deleted while the parent remains. Consider wrapping in a transaction.♻️ Suggested improvement
func (d *DB) DeleteTask(id string) error { now := time.Now().Format(time.RFC3339) // First check if task exists and is not already deleted task, err := d.GetTask(id) if err != nil { return err } if task.DeletedAt != nil { return ErrTaskNotFound } + tx, err := d.Begin() + if err != nil { + return fmt.Errorf("begin transaction: %w", err) + } + defer tx.Rollback() + // Soft delete children first (recursive via CTE) - _, err = d.Exec(` + _, err = tx.Exec(` WITH RECURSIVE descendants AS ( SELECT id FROM tasks WHERE parent_id = ? UNION ALL SELECT t.id FROM tasks t INNER JOIN descendants d ON t.parent_id = d.id ) UPDATE tasks SET deleted_at = ? WHERE id IN (SELECT id FROM descendants)`, id, now) if err != nil { return fmt.Errorf("delete children: %w", err) } // Soft delete the task itself - result, err := d.Exec(`UPDATE tasks SET deleted_at = ? WHERE id = ? AND deleted_at IS NULL`, now, id) + result, err := tx.Exec(`UPDATE tasks SET deleted_at = ? WHERE id = ? AND deleted_at IS NULL`, now, id) if err != nil { return fmt.Errorf("delete task: %w", err) } rows, _ := result.RowsAffected() if rows == 0 { return ErrTaskNotFound } + if err := tx.Commit(); err != nil { + return fmt.Errorf("commit transaction: %w", err) + } + return nil }
212-238: Same time parsing error handling concern in scanTasks.Lines 228-232 silently ignore time parsing errors, same as in
GetTask. Consider consistent error handling.
- Change generateTaskID to return error instead of panicking - Use errors.Is for ErrTaskNotFound comparison - Handle time.Parse errors in GetTask and scanTasks - Wrap DeleteTask in a transaction for atomicity - Add empty title validation in CreateTask - Handle CountChildren errors instead of ignoring - Validate parent task is in same scope before creating child - Check parent is not deleted before creating child - Add test assertions for cascade delete verification - Fix cleanup order in setupTestRepo test helper Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Fix all issues with AI agents
In @internal/cli/taskid_test.go:
- Around line 25-38: Remove or weaken the probabilistic uniqueness test
TestGenerateTaskIDUniqueness: either delete the TestGenerateTaskIDUniqueness
function entirely, or replace its body so it only asserts the format/structure
of IDs produced by generateTaskID (e.g., regex or length checks) and does not
assert uniqueness; rely on existing tests for generateUniqueTaskID to verify
collision handling. Update references in the test file to remove any uniqueness
assertions and run tests to ensure no other tests depend on
TestGenerateTaskIDUniqueness.
In @internal/db/task_test.go:
- Around line 41-49: The tests currently compare the returned error to the
sentinel ErrTaskNotFound using direct equality (e.g., in TestGetTaskNotFound
calling db.GetTask), which will break if the implementation wraps errors; update
assertions to use errors.Is(err, ErrTaskNotFound) instead of err ==
ErrTaskNotFound (apply the same change to the other failing test blocks
referenced around lines 192-201 and 357-365) so the tests correctly detect
wrapped errors from db.GetTask and related methods.
- Around line 251-266: In TestListTasksExcludesDeleted, the call to db.Exec used
to set deleted_at is ignoring its returned error; update the test to capture and
check the Exec error (from the db.Exec call that updates "tasks" for
"t-deleted") and fail the test if Exec returns a non-nil error before calling
db.ListRootTasks, ensuring the manual soft-delete actually succeeded; keep
everything else in TestListTasksExcludesDeleted and use the same db variable and
SQL/update parameters.
- Around line 126-163: The test currently ignores errors from DB calls (e.g.,
the GetTask call in TestUpdateTask uses got, _ := db.GetTask(...)), which can
hide failures; update the test to capture and assert errors from all DB
operations (CreateTask, GetTask, any List* calls) by checking the returned error
and calling t.Fatalf or t.Fatalf with the error when non-nil; apply the same
pattern to the other test blocks noted (the similar CreateTask/GetTask/List*
usages at the other ranges) so every db call is validated and the test fails
fast on unexpected errors.
In @internal/db/task.go:
- Around line 96-132: UpdateTask currently allows setting title to blank; when
update.Title != nil trim whitespace and validate it the same way as CreateTask
does, returning the same validation error (e.g., ErrInvalidTitle) if the trimmed
title is empty. Modify the UpdateTask handler (TaskUpdate processing) to perform
that check before appending "title = ?" to setParts so blank or whitespace-only
titles are rejected consistently with creation. Ensure you reuse any existing
validation helper (e.g., validateTitle) or the same error constant used by
CreateTask to keep behavior consistent.
🧹 Nitpick comments (2)
internal/cli/task.go (1)
66-83: Consider supporting “clear note/title” by usingFlags().Changed(...)instead of!= "".
Currently you can’t set a note/title to empty, only to a non-empty string. With Cobra,cmd.Flags().Changed("note")lets you distinguish “flag omitted” vs “set to empty”.Also applies to: 310-333
internal/db/task.go (1)
28-46: Consider normalizing timestamps to UTC (safer ordering when stored as TEXT).
If you keepcreated_at/updated_atas RFC3339 TEXT, writing UTC consistently avoids cross-offset lexicographic ordering surprises.Also applies to: 135-151
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
internal/cli/task.gointernal/cli/task_test.gointernal/cli/taskid.gointernal/cli/taskid_test.gointernal/db/task.gointernal/db/task_test.go
🚧 Files skipped from review as they are similar to previous changes (1)
- internal/cli/taskid.go
🧰 Additional context used
📓 Path-based instructions (2)
**/*.go
📄 CodeRabbit inference engine (CLAUDE.md)
Follow TDD: write failing test, implement, verify
Files:
internal/cli/task_test.gointernal/cli/taskid_test.gointernal/cli/task.gointernal/db/task_test.gointernal/db/task.go
internal/cli/**/*.go
📄 CodeRabbit inference engine (CLAUDE.md)
CLI command logic should be in
internal/cli/directory using Cobra framework
Files:
internal/cli/task_test.gointernal/cli/taskid_test.gointernal/cli/task.go
🧠 Learnings (3)
📚 Learning: 2026-01-07T14:24:40.451Z
Learnt from: CR
Repo: sky-xo/june PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-07T14:24:40.451Z
Learning: Applies to **/*.go : Follow TDD: write failing test, implement, verify
Applied to files:
internal/cli/task_test.gointernal/cli/taskid_test.gointernal/db/task_test.go
📚 Learning: 2026-01-07T14:24:40.451Z
Learnt from: CR
Repo: sky-xo/june PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-07T14:24:40.451Z
Learning: Applies to internal/cli/**/*.go : CLI command logic should be in `internal/cli/` directory using Cobra framework
Applied to files:
internal/cli/task_test.gointernal/cli/taskid_test.gointernal/cli/task.go
📚 Learning: 2026-01-07T14:24:40.451Z
Learnt from: CR
Repo: sky-xo/june PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-07T14:24:40.451Z
Learning: Applies to internal/claude/**/*.go : Keep file parsing logic in `internal/claude/` directory
Applied to files:
internal/cli/task_test.go
🧬 Code graph analysis (5)
internal/cli/task_test.go (1)
internal/cli/root.go (1)
Execute(47-65)
internal/cli/taskid_test.go (2)
internal/db/db.go (1)
Open(97-121)internal/db/task.go (1)
Task(11-22)
internal/cli/task.go (3)
internal/scope/git.go (2)
RepoRoot(12-41)BranchName(44-51)internal/db/task.go (3)
Task(11-22)TaskUpdate(89-93)ErrTaskNotFound(25-25)internal/db/db.go (2)
DB(92-94)Open(97-121)
internal/db/task_test.go (1)
internal/db/task.go (3)
Task(11-22)ErrTaskNotFound(25-25)TaskUpdate(89-93)
internal/db/task.go (1)
internal/db/db.go (1)
DB(92-94)
🔇 Additional comments (1)
internal/db/task.go (1)
27-46: Nice: delete is transactional + recursive cascade is clear.
The transaction-wrapped cascade behavior aligns with the PR objectives (atomic soft-delete of parent + descendants). Based on learnings, this is a solid “test + implement” flow.Also applies to: 183-237
- Add DeletedAt check in listSpecificTask to return "not found" for deleted tasks, matching soft delete semantics - Use errors.Is() instead of == for ErrTaskNotFound comparison in runTaskUpdate and runTaskDelete (Go best practice) - Add TestTaskListDeletedByID test to verify deleted task behavior Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
internal/cli/task_test.go (2)
55-56: Check errors from git commands in test setup.The git commands are executed without checking their return status. If
gitis unavailable or these commands fail, tests may produce confusing failures or unexpected behavior downstream.🔧 Proposed fix to add error checking
- exec.Command("git", "init").Run() - exec.Command("git", "checkout", "-b", "main").Run() + if err := exec.Command("git", "init").Run(); err != nil { + t.Fatalf("git init failed: %v", err) + } + if err := exec.Command("git", "checkout", "-b", "main").Run(); err != nil { + t.Fatalf("git checkout failed: %v", err) + }
91-91: Consider checking errors from intermediatecmd.Execute()calls in tests.Multiple test functions execute commands without checking for errors (e.g., lines 91, 139, 144, 171, 178, 208, 226, 240, 247, 254, 269, 287, 302, 309, 333, 340, 361). While these are often setup or intermediate steps before the main assertion, unchecked errors can mask failures and make test debugging more difficult.
For example, if a
createorlistcommand fails silently during setup, subsequent assertions may fail with confusing messages rather than pointing to the actual problem.Also applies to: 139-139, 144-144, 171-171, 178-178, 208-208, 226-226, 240-240, 247-247, 254-254, 269-269, 287-287, 302-302, 309-309, 333-333, 340-340, 361-361
internal/cli/task.go (1)
132-149: Consider capturing timestamp per task for precise creation times.Currently,
time.Now()is called once (line 132) before the loop, so all tasks created in a single command invocation receive identicalCreatedAtandUpdatedAttimestamps. While this batch-operation behavior may be intentional, capturing a fresh timestamp for each task iteration would provide more precise creation times and preserve ordering if the loop takes measurable time to execute.♻️ Optional refactor for per-task timestamps
- // Create tasks - now := time.Now() out := cmd.OutOrStdout() for _, title := range args { id, err := generateUniqueTaskID(database) if err != nil { return fmt.Errorf("generate task ID: %w", err) } + now := time.Now() task := db.Task{ ID: id, ParentID: parentPtr, Title: title, Status: "open", RepoPath: repoPath, Branch: branch, CreatedAt: now, UpdatedAt: now, }
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
internal/cli/task.gointernal/cli/task_test.go
🧰 Additional context used
📓 Path-based instructions (2)
**/*.go
📄 CodeRabbit inference engine (CLAUDE.md)
Follow TDD: write failing test, implement, verify
Files:
internal/cli/task_test.gointernal/cli/task.go
internal/cli/**/*.go
📄 CodeRabbit inference engine (CLAUDE.md)
CLI command logic should be in
internal/cli/directory using Cobra framework
Files:
internal/cli/task_test.gointernal/cli/task.go
🧠 Learnings (4)
📚 Learning: 2026-01-07T14:24:40.451Z
Learnt from: CR
Repo: sky-xo/june PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-07T14:24:40.451Z
Learning: Applies to **/*.go : Follow TDD: write failing test, implement, verify
Applied to files:
internal/cli/task_test.go
📚 Learning: 2026-01-07T14:24:40.451Z
Learnt from: CR
Repo: sky-xo/june PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-07T14:24:40.451Z
Learning: Applies to internal/cli/**/*.go : CLI command logic should be in `internal/cli/` directory using Cobra framework
Applied to files:
internal/cli/task_test.gointernal/cli/task.go
📚 Learning: 2026-01-07T14:24:40.451Z
Learnt from: CR
Repo: sky-xo/june PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-07T14:24:40.451Z
Learning: Applies to internal/claude/**/*.go : Keep file parsing logic in `internal/claude/` directory
Applied to files:
internal/cli/task_test.go
📚 Learning: 2026-01-07T14:24:40.451Z
Learnt from: CR
Repo: sky-xo/june PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-07T14:24:40.451Z
Learning: Applies to internal/scope/**/*.go : Git project/branch detection logic should be in `internal/scope/` directory
Applied to files:
internal/cli/task_test.gointernal/cli/task.go
🧬 Code graph analysis (2)
internal/cli/task_test.go (1)
internal/cli/root.go (1)
Execute(47-65)
internal/cli/task.go (3)
internal/scope/git.go (2)
RepoRoot(12-41)BranchName(44-51)internal/db/task.go (3)
Task(11-22)TaskUpdate(89-93)ErrTaskNotFound(25-25)internal/db/db.go (2)
DB(92-94)Open(97-121)
🔇 Additional comments (3)
internal/cli/task.go (3)
251-254: LGTM - proper handling of soft-deleted tasks.The check ensures that soft-deleted tasks (where
DeletedAtis non-nil) are hidden from direct ID lookups, returning a "not found" error instead. This correctly implements the behavior described in the PR commit message.
350-355: LGTM - correct use oferrors.Is()for error checking.The error handling properly uses
errors.Is()to check for the sentineldb.ErrTaskNotFound, as mentioned in the PR commit message. This is the correct approach for comparing sentinel errors in Go.
372-377: LGTM - correct use oferrors.Is()for error checking.Properly uses
errors.Is()to check fordb.ErrTaskNotFound, consistent with the improvements mentioned in the PR commit message.
- Add empty title validation in UpdateTask to match CreateTask behavior - Use errors.Is() instead of == for ErrTaskNotFound in tests - Check errors from all db.CreateTask, GetTask, ListRootTasks calls in tests - Check errors from db.Exec when soft-deleting in tests - Check errors from git init/checkout commands in CLI tests - Check errors from all cmd.Execute() calls in CLI tests Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Design for making June a Claude Code plugin that vendors superpowers skills and modifies planning/execution workflows to use persistent June tasks instead of TodoWrite. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add plugin.json contents - Note .skill-cache needs .gitignore entry - Use generic repo URL placeholder - Fix contradiction about plugin conflicts Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
9 tasks covering: - CLI enhancement (--note flag) - Plugin infrastructure - Skills directory setup - Skill modifications for june task integration - Build and test Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- writing-plans: quick fresheyes always, suggest full 2x Claude for 400+ lines - subagent-driven-development: model selection table, skip code quality for mechanical - executing-plans: june task integration - fresheyes + review-pr-comments: include in June - design-review, tool-scout, webresearcher: stay in user skills Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Fix test to use setupTestRepo helper (consistent with existing tests) - Fix verification step to check error return - Use portable sources: clone superpowers and fresheyes repos - Fix step order to prevent overwrites - Clarify fresheyes invocation with Skill tool syntax - Add parent-id handoff explanation between writing-plans and execution - Fix skill count (16 = 14 superpowers + 2 new) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Enable setting a note when creating tasks with the --note flag. The note is stored on the task during creation and can be viewed with task list commands. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add Claude Code plugin section to README.md documenting installation, skills, and build commands. Update CLAUDE.md to note that June is also a Claude Code plugin. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Users can now install via: /plugin marketplace add sky-xo/june /plugin install june@june
There was a problem hiding this comment.
Actionable comments posted: 15
🤖 Fix all issues with AI agents
In @CLAUDE.md:
- Line 93: The current sentence "Tasks are scoped to the current git repo and
branch" is too broad—update the wording to state that only task creation and
root listing (e.g., "june task list" without an ID and task creation commands)
are scoped to the current git repo and branch, while ID-based operations ("june
task list <id>", "june task update <id>", "june task delete <id>") are global
across branches; make this single-line clarification so readers understand that
ID-based task management persists when switching branches.
In @june-skills/executing-plans/SKILL.md:
- Around line 58-60: The markdown blocks showing the command and its output lack
language specifiers; add a "bash" language tag to the command block containing
"june task list <parent-id>" and add a "text" (or "bash") language tag to the
subsequent output block that starts with "t-a3f8 "Implement feature" ..." so
both code blocks render with proper syntax highlighting and plain text
formatting.
- Around line 1-97: Duplicate skill sets exist in the june-skills directory
(executing-plans, fresheyes, review-pr-comments, subagent-driven-development,
writing-plans) while skills/ is the authoritative source; remove the duplication
by deleting the entire june-skills/ directory or, if june-skills/ serves a
distinct purpose, document that purpose and remove only the duplicated skill
files (matching names: executing-plans, fresheyes and its supporting files,
review-pr-comments, subagent-driven-development and its prompt files,
writing-plans) so that only the canonical copies in skills/ remain; update any
references or onboarding docs that pointed to june-skills/ to reference skills/
(or to the documented purpose) and run a quick repo search to ensure no
lingering imports/links to june-skills/ remain.
In @june-skills/writing-plans/SKILL.md:
- Line 90: Add language identifiers to the fenced code blocks so they get syntax
highlighting: change the fence before the git commands block containing "git add
tests/path/test.py src/path/file.py" to ```bash and change the fence before the
example output block that starts with "Tasks created: t-xxxx (N children)" to
```text; keep the block contents unchanged.
- Line 67: Replace the bold step labels (e.g., "**Step 2: Run test to verify it
fails**") with proper Markdown headings (for example "### Step 2: Run test to
verify it fails") so they become semantic headings; update the other similar
bold labels shown in the diff (the ones matching lines containing "**Step X:
...**" at the indicated locations, including the occurrences around the texts
matching lines 72, 79, 84, and the one at 169) to use the same heading syntax
for consistent document structure and outline generation.
In @skills/executing-plans/SKILL.md:
- Around line 58-60: Add explicit language identifiers to the fenced code blocks
in SKILL.md so syntax/highlighting is correct: change the command block
containing "june task list <parent-id>" to use ```bash and change the example
output block to use ```text; apply the same fix to the other example blocks
referenced (the output/example region around lines 64-69) so all fenced blocks
have appropriate language tags.
In @skills/subagent-driven-development/SKILL.md:
- Around line 121-193: The example workflow code block in SKILL.md is missing a
fenced code language which hurts readability; update the opening fence for the
workflow snippet that starts with "You: I'm using Subagent-Driven Development to
execute this plan." to include a language token (e.g., ```text or ```bash) so
the block is properly labeled and accessible, leaving the rest of the content
unchanged.
In @skills/systematic-debugging/find-polluter.sh:
- Around line 22-23: The current TEST_FILES assignment uses find -path with
TEST_PATTERN which may contain shell globstar patterns like ** that find -path
doesn't interpret the same way; update the logic so TEST_PATTERN is either
converted to a path-style pattern for find -path or switch to using find -name
(matching basenames) when TEST_PATTERN is a filename glob, or alternatively
enable and use shell globbing to expand TEST_PATTERN before invoking find;
specifically, change how TEST_FILES is computed around the TEST_FILES variable
so it either calls find with -name when TEST_PATTERN is a filename glob,
documents the required path-style pattern for -path, or expands TEST_PATTERN in
the shell (with globstar enabled) prior to sorting.
- Line 42: The npm test invocation passes $TEST_FILE directly which can be
misinterpreted by npm; modify the command to explicitly forward the file
argument by inserting the `--` separator before the variable, i.e. change the
invocation using `npm test "$TEST_FILE" > /dev/null 2>&1 || true` to use `npm
test -- "$TEST_FILE" > /dev/null 2>&1 || true`, updating the line that
references the TEST_FILE variable.
In @skills/systematic-debugging/test-academic.md:
- Line 3: Update the path reference on line 3 from
"skills/debugging/systematic-debugging" to the correct path
"skills/systematic-debugging" (or use "skills/systematic-debugging/SKILL.md" if
pointing to the main skill document) so the link points to the existing
systematic debugging skill.
In @skills/systematic-debugging/test-pressure-3.md:
- Around line 46-65: Replace the bolded option labels "A) ...", "B) ...", "C)
..." with proper markdown headings (e.g., use "### A) Push back: \"I think we
should investigate the root cause first\"", "### B) Go along with senior's fix",
"### C) Compromise: \"Can we at least look at the middleware docs?\"") so each
option becomes a semantically correct heading; keep the existing bullet content
under each heading and ensure the heading level is consistent across all three
options.
In @skills/using-git-worktrees/SKILL.md:
- Around line 57-60: The current combined check uses `||` so it returns success
if either .worktrees or worktrees is ignored, but we need to verify the specific
directory chosen (priority .worktrees). Replace the single `git check-ignore -q
.worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null` with a
prioritized check: first test `.worktrees` with `git check-ignore -q .worktrees
2>/dev/null` and only if that directory doesn't exist or isn't applicable, then
test `worktrees` (`git check-ignore -q worktrees 2>/dev/null`); implement this
using an if/elif/else or two separate checks so the chosen directory's ignore
status is validated according to the documented priority.
In @skills/writing-skills/anthropic-best-practices.md:
- Around line 1008-1009: Update the two bullets that claim "claude.ai can
install packages from npm and PyPI" and "Anthropic API has no network access..."
to clarify sandbox behavior: state that the claude.ai web Code console runs in a
restricted sandbox that blocks/limits system-level package installs, filesystem
and network access (leading to permission/sudo failures), that package installs
are possible when running the model locally via CLI/Desktop apps on the user’s
machine, and that GitHub access for private repos is limited by authentication
constraints; keep the Anthropic API note but add that it likewise has no
arbitrary runtime package installation or unrestricted network access.
In @skills/writing-skills/SKILL.md:
- Around line 75-81: Update the unlabeled fenced code blocks in SKILL.md so they
include a language specifier (e.g., use ```text) to enable proper syntax
highlighting/accessibility; specifically modify the directory-structure block
shown around lines 75 and the other unlabeled blocks flagged at lines 350, 357,
365, and 376 to use a language token (consistent with the proposed fix for the
directory structure example), ensuring each opening ``` is replaced with ```text
(or another appropriate language) while leaving the block contents unchanged.
In @skills/writing-skills/testing-skills-with-subagents.md:
- Line 327: There's a typo in the checklist item text "[ ] Updated description
ith violation symptoms": change "ith" to "with" so it reads "[ ] Updated
description with violation symptoms"; update that exact string in the document
(skills/writing-skills/testing-skills-with-subagents.md) to fix the typo.
🧹 Nitpick comments (44)
skills/systematic-debugging/test-pressure-2.md (3)
12-15: Add language identifier to the fenced code block.The code block should specify a language for proper rendering and to satisfy markdown linting rules.
📝 Suggested fix
-``` +```text Expected: { status: 'completed', amount: 100 } Received: { status: 'pending', amount: 100 }</details> --- `29-29`: **Use proper heading syntax instead of bold emphasis.** Lines 29, 37, 53, and 60 use bold text for section headers. Using proper markdown heading syntax (e.g., `###`) would improve document structure and accessibility. <details> <summary>📝 Suggested fix</summary> ```diff -**Option A: Follow systematic debugging** +### Option A: Follow systematic debugging -**Option B: "Good enough" solution** +### Option B: "Good enough" solution -**A) Delete all the timeout code. Start systematic debugging from Phase 1.** +### A) Delete all the timeout code. Start systematic debugging from Phase 1. -**C) Quick investigation first** +### C) Quick investigation firstAlso applies to: 37-37, 53-53, 60-60
66-68: Consider clarifying the expected response format.The prompt asks "Which do you choose?" after stating users "must choose and act" (line 3). It's unclear whether the reader should state their choice, explain their reasoning, or implement the selected option. Consider adding a sentence clarifying the expected response format if this is meant to be interactive.
skills/requesting-code-review/SKILL.md (1)
51-51: Add language specification to fenced code block.The code block at line 51 is missing a language identifier, which is required for markdown compliance and proper syntax highlighting.
✨ Proposed fix
[Just completed Task 2: Add verification function] You: Let me request code review before proceeding. - +```bash BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}') HEAD_SHA=$(git rev-parse HEAD) - +``` [Dispatch superpowers:code-reviewer subagent]Based on static analysis tools (markdownlint-cli2).
skills/fresheyes/fresheyes-quick.md (1)
70-70: Add language specification to fenced code block.The code block at line 70 is missing a language identifier. Since it contains markdown-formatted output, marking it appropriately will improve rendering and tooling integration.
✨ Proposed fix
3. Re-run tests ### Step 8: Report -``` +```markdown ## Quick Fresh-Eyes Complete **Files reviewed:** [list]Based on static analysis tools (markdownlint-cli2).
skills/fresheyes/SKILL.md (2)
84-90: Add language specifier to YAML configuration code block.This code block should specify
yamlto enable proper syntax highlighting and follow markdown standards.-``` +```yaml Task tool: subagent_type: general-purpose prompt: <contents of fresheyes-full.md with scope replaced> description: "Fresh eyes review #N" run_in_background: true (when multiple agents) -``` +```
109-135: Add language specifier to template output code block.This code block should specify a language (e.g.,
markdownortext) to follow markdown standards and enable syntax highlighting.-``` +```text ## Verdict: [PASSED/FAILED] (N/M agents found blocking issues) ## Agents Usedskills/systematic-debugging/test-pressure-1.md (2)
17-19: Add language specifier to error log code block.Specify a language (e.g.,
textorbash) to follow markdown standards.You quickly check the logs and see: -``` +```text PaymentError: Connection timeout to payments.api.com -``` +```
38-55: Prefer markdown headings over bold text for section structure.Lines 38, 44, and 50 use bold emphasis (A) ...) for option labels. Convert these to proper markdown headings (### or ####) to improve document structure and accessibility.
-**A) Follow the systematic debugging process** +### A) Follow the systematic debugging process - Stop and investigate root cause first (35+ minutes) - Another $525k lost during investigation - Manager will be furious - You look slow/incompetent -**B) Quick fix now, investigate later** +### B) Quick fix now, investigate later - Add retry logic (5 minutes total) - Stop the bleeding immediately - Investigate root cause after service restored - Save $450k vs Option A -**C) Compromise: Minimal investigation** +### C) Compromise: Minimal investigation - Quick 5-minute check of recent changes - If nothing obvious, add retry - Investigate properly after restore - "Being pragmatic not dogmatic"docs/plans/2026-01-10-june-plugin-followup.md (2)
70-84: Add language specifier to task list output code block.Specify a language (e.g.,
textorbash) to follow markdown standards.Output: -``` +```text t-a6891 "Implement June Plugin" [closed] Note: All 9 tasks completed t-7a70d "Task 1: Add --note flag" [closed] Note: Implemented, spec compliant, code quality approved t-2a8e9 "Task 2: Create plugin infrastructure" [closed] Note: Implemented, spec compliant, code quality approved t-a88d0 "Task 3: Create june-skills directory" [closed] Note: Implemented, spec compliant, code quality approved ... (all children with all notes) -``` +```
61-88: Full tree dump flag is a valuable usability improvement.The proposal to add a
--fullflag tojune task listwith recursive output and notes is thoughtful. After compaction, Claude would need exactly this kind of context to resume effectively. The suggested output format (lines 70-84) is clear and actionable.Consider documenting this as a priority in the action items if it emerges as critical during the validation testing (lines 106-107).
If this feature becomes a priority based on your validation testing, I can help generate the implementation skeleton for recursive task fetching and formatted output.
skills/test-driven-development/testing-anti-patterns.md (1)
15-15: Specify language for all fenced code blocks.Seven code blocks lack language identifiers, preventing syntax highlighting and causing markdown linting violations (MD040). These blocks need language specification based on context.
♻️ Proposed fixes for code block language specifications
- Line 15: ``` → ``` + Line 15: ```typescript - Line 53: ``` → ``` + Line 53: ``` (Gate Function - plain text/pseudocode) - Line 104: ``` → ``` + Line 104: ``` (Gate Function - plain text/pseudocode) - Line 153: ``` → ``` + Line 153: ``` (Gate Function - plain text/pseudocode) - Line 212: ``` → ``` + Line 212: ``` (Gate Function - plain text/pseudocode) - Line 231: ``` → ``` + Line 231: ``` (Plain text listing) - Line 243: ``` → ``` + Line 243: ``` (Plain text - TDD cycle)Also applies to: 53-53, 104-104, 153-153, 212-212, 231-231, 243-243
skills/test-driven-development/SKILL.md (2)
33-33: Specify language for fenced code blocks.Three code blocks lack language specifications (MD040 violations). Lines 33 and 90 need language identifiers; line 366 can use a language or be left blank for plain text.
♻️ Proposed fixes for language specifications
Line 33: -```dot +```dot Line 90: -```typescript +```typescript Line 366: -``` +``` (or leave blank for plain text)Also applies to: 90-90, 366-366
208-208: Convert emphasis-only lines to proper markdown headings.Nine lines use emphasis (
**...**) as standalone headings instead of markdown heading syntax (MD036 violations). This degrades semantic structure and linting compliance. Convert to###headings for better clarity and proper document structure.Examples:
- Line 208:
**"I'll write tests after to verify it works"**→### I'll write tests after to verify it works- Line 218:
**"I already manually tested all the edge cases"**→### I already manually tested all the edge cases- (and similar for lines 228, 236, 246, 294, 302, 308, 318)
Also applies to: 218-218, 228-228, 236-236, 246-246, 294-294, 302-302, 308-308, 318-318
skills/subagent-driven-development/spec-reviewer-prompt.md (1)
7-7: Specify language for the fenced code block.Line 7's code block lacks a language identifier (MD040 violation). Use
yamlfor proper syntax highlighting of the task tool definition.♻️ Proposed fix
-``` +```yaml Task tool (general-purpose):skills/brainstorming/SKILL.md (1)
19-19: Minor: Hyphenate compound adjectivemultiple-choice.The linter suggests hyphenating "multiple choice" when it functions as a compound adjective before a noun. Line 19 reads: "Prefer multiple choice questions when possible" → should be "multiple-choice questions."
This is a style consistency issue (common in technical writing per AP and Chicago Manual of Style).
♻️ Proposed fix
- Prefer multiple choice questions when possible, but open-ended is fine too + Prefer multiple-choice questions when possible, but open-ended is fine tooskills/writing-skills/examples/CLAUDE_MD_TESTING.md (1)
8-8: Add language identifier to fenced code blocks.The linter (markdownlint-cli2 MD040) requires a language identifier for all fenced code blocks. Lines 8, 22, 39, and 53 contain plain-text scenario blocks without language specified.
Since these are scenario descriptions (not executable code), mark them as
`text`or`plaintext`for consistency with strict linting.♻️ Proposed fixes
Line 8 (Scenario 1):
-``` +```text IMPORTANT: This is a real scenario. Choose and act.Line 22 (Scenario 2):
-``` +```text IMPORTANT: This is a real scenario. Choose and act.Line 39 (Scenario 3):
-``` +```text IMPORTANT: This is a real scenario. Choose and act.Line 53 (Scenario 4):
-``` +```text IMPORTANT: This is a real scenario. Choose and act.Also applies to: 22-22, 39-39, 53-53
skills/verification-before-completion/SKILL.md (1)
18-20: Add language specifications to fenced code blocks.All seven fenced code blocks are missing language specifications, which violates Markdown best practices (MD040). These should be annotated as
textorplaintextto make the linting compliant.♻️ Proposed fixes for all fenced code blocks
- ``` + ```text NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE```diff - ``` + ```text BEFORE claiming any status or expressing satisfaction: 1. IDENTIFY: What command proves this claim? ...And similarly for the remaining code blocks at lines 79, 85, 91, 97, and 103. </details> Also applies to: 26-38, 79-82, 85-88, 91-94, 97-100, 103-106 </blockquote></details> <details> <summary>june-skills/fresheyes/fresheyes-quick.md (2)</summary><blockquote> `70-80`: **Add language specification to the report template code block.** The fenced code block at line 70 is missing a language specification (MD040). Use `text` or `markdown` as appropriate. <details> <summary>♻️ Proposed fix</summary> ```diff - ``` + ```text ## Quick Fresh-Eyes Complete ...</details> --- `15-15`: **Consider clarifying the {{REVIEW_SCOPE}} placeholder.** Line 15 uses `{{REVIEW_SCOPE}}` as a template variable but doesn't explain what should go there. A brief note (e.g., "list files or describe area under review") would improve usability for someone filling in this template. </blockquote></details> <details> <summary>skills/subagent-driven-development/implementer-prompt.md (1)</summary><blockquote> `5-5`: **Add language specification to the task tool template code block.** The fenced code block at line 5 is missing a language specification (MD040). Use `text` or `plaintext` as appropriate. <details> <summary>♻️ Proposed fix</summary> ```diff - ``` + ```text Task tool (general-purpose): ...</details> </blockquote></details> <details> <summary>skills/fresheyes/fresheyes-full.md (1)</summary><blockquote> `16-25`: **Add language specifier to all fenced code blocks (MD040 violations).** Specifying a language improves content rendering by using the correct syntax highlighting for code. Twelve fenced code blocks lack language specifiers. For pseudocode, flow diagrams, and conversational examples, use `text` as the language identifier. <details> <summary>🔧 Example fix for lines 16-25</summary> ```diff -``` +```text WHEN receiving code review feedback: 1. READ: Complete feedback without reacting 2. UNDERSTAND: Restate requirement in own words (or ask) 3. VERIFY: Check against codebase reality 4. EVALUATE: Technically sound for THIS codebase? 5. RESPOND: Technical acknowledgment or reasoned pushback 6. IMPLEMENT: One item at a time, test each -``` +```Apply the same fix to all other unspecified code blocks (lines 42, 51, 68, 90, 102, 134, 153, 179, 185, 191, 197).
Also applies to: 42-48, 51-57, 68-84, 90-96, 102-111, 134-144, 153-162, 179-182, 185-188, 191-194, 197-201
skills/receiving-code-review/SKILL.md (1)
16-25: Add language specifier to all fenced code blocks (MD040 violations).Same issue as in
fresheyes-full.md: eleven fenced code blocks lack language specifiers. Specifying a language improves content rendering by using the correct syntax highlighting for code. Usetextfor pseudocode, flow diagrams, and conversational examples.🔧 Example fix for lines 16-25
-``` +```text WHEN receiving code review feedback: 1. READ: Complete feedback without reacting 2. UNDERSTAND: Restate requirement in own words (or ask) 3. VERIFY: Check against codebase reality 4. EVALUATE: Technically sound for THIS codebase? 5. RESPOND: Technical acknowledgment or reasoned pushback 6. IMPLEMENT: One item at a time, test each -``` +```Apply the same fix to all other unspecified code blocks (lines 42, 51, 68, 90, 102, 134, 153, 179, 185, 191, 197).
Also applies to: 42-48, 51-57, 68-84, 90-96, 102-111, 134-144, 153-162, 179-182, 185-188, 191-194, 197-201
june-skills/subagent-driven-development/implementer-prompt.md (1)
5-5: Add language specifier to code fence.The fenced code block opening should include a language identifier to comply with markdown standards and improve IDE syntax highlighting.
-``` +```yamljune-skills/subagent-driven-development/SKILL.md (1)
121-121: Add language specifier to code fence.The fenced code block should include a language identifier for markdown compliance and syntax highlighting.
-``` +```textskills/systematic-debugging/find-polluter.sh (1)
42-42: Consider preserving stderr for debugging.Redirecting both stdout and stderr to
/dev/nullmakes it impossible to see if the test command itself fails (e.g., command not found, syntax error). Consider preserving stderr while suppressing only test output.♻️ Proposed improvement
-npm test "$TEST_FILE" > /dev/null 2>&1 || true +npm test "$TEST_FILE" 2>&1 | grep -v "^.*test.*$" || trueOr at minimum:
-npm test "$TEST_FILE" > /dev/null 2>&1 || true +npm test "$TEST_FILE" >/dev/null || trueThis preserves stderr so script errors are visible while suppressing stdout.
skills/using-git-worktrees/SKILL.md (2)
86-99: Variables used before definition and tilde expansion issue.The case statement references
$LOCATIONand$BRANCH_NAMEwithout showing where they're defined, which may confuse readers. Additionally, line 92 uses~/in a variable assignment, which won't expand correctly without proper quoting or using$HOME.♻️ Proposed improvements
Add variable definitions before the case statement:
# Example variables (adjust based on earlier logic) LOCATION=".worktrees" # or "worktrees" or global path BRANCH_NAME="feature/my-feature" project=$(basename "$(git rev-parse --show-toplevel)")Fix tilde expansion:
~/.config/superpowers/worktrees/*) - path="~/.config/superpowers/worktrees/$project/$BRANCH_NAME" + path="$HOME/.config/superpowers/worktrees/$project/$BRANCH_NAME" ;;
96-99: Add error handling for worktree creation.The
git worktree addcommand with-bflag will fail if the branch already exists. Consider handling this case or documenting the expected behavior.♻️ Proposed improvement
-# Create worktree with new branch -git worktree add "$path" -b "$BRANCH_NAME" -cd "$path" +# Create worktree with new branch +if git worktree add "$path" -b "$BRANCH_NAME"; then + cd "$path" +else + echo "Failed to create worktree. Branch may already exist." + echo "To checkout existing branch: git worktree add \"$path\" \"$BRANCH_NAME\"" + exit 1 +fiskills/dispatching-parallel-agents/SKILL.md (1)
143-147: Add language identifier to fenced code block.The fenced code block lacks a language identifier, which reduces readability and may affect syntax highlighting.
📝 Suggested fix
-``` +```text Agent 1 → Fix agent-tool-abort.test.ts Agent 2 → Fix batch-completion-behavior.test.ts Agent 3 → Fix tool-approval-race-conditions.test.ts</details> </blockquote></details> <details> <summary>skills/subagent-driven-development/code-quality-reviewer-prompt.md (1)</summary><blockquote> `9-18`: **Add language identifier to fenced code block.** The fenced code block lacks a language identifier. Consider using `text` or `markdown` for better readability. <details> <summary>📝 Suggested fix</summary> ```diff -``` +```text Task tool (superpowers:code-reviewer): Use template at requesting-code-review/code-reviewer.md WHAT_WAS_IMPLEMENTED: [from implementer's report] PLAN_OR_REQUIREMENTS: Task N from [plan-file] BASE_SHA: [commit before task] HEAD_SHA: [current commit] DESCRIPTION: [task summary]</details> </blockquote></details> <details> <summary>june-skills/fresheyes/fresheyes-full.md (1)</summary><blockquote> `70-82`: **Add language identifier to fenced code block.** The output template fenced code block lacks a language identifier. Consider using `text` or `markdown` for better readability. <details> <summary>📝 Suggested fix</summary> ```diff -``` +```text ## Files Examined - [list each file you read/examined] ## Issues Found [For each issue:] - **[severity]** `file:line` - description ## Summary [Brief summary of findings] --- **INDEPENDENT CODE REVIEW [PASSED/FAILED]**</details> </blockquote></details> <details> <summary>README.md (1)</summary><blockquote> `93-97`: **Add language identifier to fenced code block (line 94).** Static analysis (markdownlint) expects fenced code blocks to have a language specified. Change the opening fence to include a language identifier. <details> <summary>🔧 Proposed fix</summary> ```diff **Via marketplace (recommended):** -``` +```bash /plugin marketplace add sky-xo/june /plugin install june@june -``` +```skills/writing-skills/testing-skills-with-subagents.md (1)
184-200: Optional: Add language specifier to fenced code block.The fenced code block at line 199 lacks a language specifier. While this is an empty placeholder block showing structure, adding a language hint improves clarity.
📝 Proposed fix
</Before> <After> -``` +```markdown Write code before test? Delete it. Start over.Makefile (1)
49-49: Simplify git fetch command.Using
git fetch origin mainonly fetches the main branch. Consider usinggit fetch originto fetch all refs, or verify that the main branch exists on origin.♻️ Proposed refactor
- cd .skill-cache/superpowers && git fetch origin main && git log --oneline HEAD..origin/main + cd .skill-cache/superpowers && git fetch origin && git log --oneline HEAD..origin/mainjune-skills/fresheyes/SKILL.md (2)
84-90: Optional: Add language specifier to fenced code block.The fenced code block lacks a language specifier. Consider adding
yamlortextto improve rendering.📝 Proposed fix
**Claude (Task tool):** -``` +```yaml Task tool: subagent_type: general-purpose
109-135: Optional: Add language specifier to fenced code block.The report template code block lacks a language specifier. Consider adding
markdownortext.📝 Proposed fix
#### Step 5: Report -``` +```markdown ## Verdict: [PASSED/FAILED] (N/M agents found blocking issues)skills/finishing-a-development-branch/SKILL.md (4)
28-34: Optional: Add language specifier to fenced code block.The error message code block lacks a language specifier. Consider adding
textormarkdown.📝 Proposed fix
**If tests fail:** -``` +```text Tests failing (<N> failures). Must fix before completing:
53-62: Optional: Add language specifier to fenced code block.The options presentation code block lacks a language specifier. Consider adding
textormarkdown.📝 Proposed fix
Present exactly these 4 options: -``` +```text Implementation complete. What would you like to do?
117-124: Optional: Add language specifier to fenced code block.The confirmation prompt code block lacks a language specifier. Consider adding
textormarkdown.📝 Proposed fix
**Confirm first:** -``` +```text This will permanently delete:
163-178: Refactor bold text to proper headings.The "Common Mistakes" section uses bold text instead of proper Markdown headings, which reduces document structure clarity.
♻️ Proposed refactor
## Common Mistakes -**Skipping test verification** +### Skipping test verification - **Problem:** Merge broken code, create failing PR - **Fix:** Always verify tests before offering options -**Open-ended questions** +### Open-ended questions - **Problem:** "What should I do next?" → ambiguous - **Fix:** Present exactly 4 structured options -**Automatic worktree cleanup** +### Automatic worktree cleanup - **Problem:** Remove worktree when might need it (Option 2, 3) - **Fix:** Only cleanup for Options 1 and 4 -**No confirmation for discard** +### No confirmation for discard - **Problem:** Accidentally delete work - **Fix:** Require typed "discard" confirmationskills/writing-skills/SKILL.md (1)
314-314: Minor: "helper2" and "step1" examples could be clearerThe generic label examples
helper1, helper2, step3, pattern4are meant to illustrate bad naming practices. However, the static analysis tool flaggedhelper2andstep1as potential spelling issues because they appear without context. Consider adding quotes or formatting to make it explicit these are anti-pattern examples.✨ Suggested clarification
### ❌ Generic Labels -helper1, helper2, step3, pattern4 +`helper1`, `helper2`, `step3`, `pattern4` **Why bad:** Labels should have semantic meaninginternal/cli/task_test.go (1)
65-410: Consider adding error path testsThe test suite thoroughly covers happy paths (creation, listing, updates, deletion), but I don't see tests for error conditions such as:
- Creating a task with a non-existent parent ID
- Updating a non-existent task
- Deleting a non-existent task
- Invalid status values in updates
These error paths are important for CLI robustness.
Would you like me to generate additional test cases for error conditions?
docs/plans/2026-01-10-june-plugin-impl.md (2)
1-13: Fix heading hierarchy violation—missing h2 level.Heading levels should only increment by one level at a time. The document jumps from h1 to h3 at line 13, skipping h2. Add h2 section headings to structure the task groups logically.
🔧 Proposed fix for heading structure
# June Plugin Implementation Plan > **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. **Goal:** Transform June into a Claude Code plugin with task-aware workflow skills. **Architecture:** Add plugin structure (.claude-plugin/), create june-skills/ for custom skills, add Makefile targets to vendor superpowers and overlay customizations. Modify skills to use `june task` commands and add fresheyes integration. **Tech Stack:** Go (CLI enhancement), Makefile (build process), Markdown (skills) --- -### Task 1: Add --note flag to task create +## Implementation Tasks + +### Task 1: Add --note flag to task create
158-170: Add language specifiers to all fenced code blocks.Specifying a language improves content rendering by enabling syntax highlighting. Many code blocks throughout this plan lack language specifiers, degrading readability and making copy/paste harder.
🔧 Sample fixes (apply to all code blocks)
-Create `.claude-plugin/plugin.json`: +Create `.claude-plugin/plugin.json`: -```json +```json { "name": "june", ... } -``` +``` -Add to `Makefile`: +Add to `Makefile`: -```makefile +```makefile # Superpowers vendoring SUPERPOWERS_VERSION := v4.0.3 ... -``` +``` -```bash +```bash # Create parent task for the plan june task create "<Plan Title>" --json # Returns: {"id": "t-xxxx"} -``` +```Apply this pattern to all 12+ code blocks in the document that lack language specifiers (notably shell, Go, JSON, and Makefile blocks).
Also applies to: 184-205, 364-373, 377-381
| june task create "New task" --json | ||
| ``` | ||
|
|
||
| Tasks are scoped to the current git repo and branch. |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Clarify task scoping behavior.
The statement "Tasks are scoped to the current git repo and branch" is incomplete and potentially misleading. Only task creation and root listing (june task list without an ID) are scoped to the current repo and branch. ID-based operations (june task list <id>, june task update <id>, june task delete <id>) are intentionally global and work across branches, allowing users to maintain task visibility when switching branches.
Based on learnings, this design choice enables cross-branch task management.
📝 Suggested clarification
-Tasks are scoped to the current git repo and branch.
+Task creation and root listing are scoped to the current git repo and branch.
+Once created, tasks can be accessed by ID from any branch using list/update/delete commands.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Tasks are scoped to the current git repo and branch. | |
| Task creation and root listing are scoped to the current git repo and branch. | |
| Once created, tasks can be accessed by ID from any branch using list/update/delete commands. |
🤖 Prompt for AI Agents
In @CLAUDE.md at line 93, The current sentence "Tasks are scoped to the current
git repo and branch" is too broad—update the wording to state that only task
creation and root listing (e.g., "june task list" without an ID and task
creation commands) are scoped to the current git repo and branch, while ID-based
operations ("june task list <id>", "june task update <id>", "june task delete
<id>") are global across branches; make this single-line clarification so
readers understand that ID-based task management persists when switching
branches.
| --- | ||
| name: executing-plans | ||
| description: Use when you have a written implementation plan to execute in a separate session with review checkpoints | ||
| # Based on: superpowers v4.0.3 | ||
| # Customization: June task persistence instead of TodoWrite | ||
| --- | ||
|
|
||
| # Executing Plans | ||
|
|
||
| ## Overview | ||
|
|
||
| Load plan, review critically, execute tasks in batches, report for review between batches. | ||
|
|
||
| **Core principle:** Batch execution with checkpoints for architect review. | ||
|
|
||
| **Announce at start:** "I'm using the executing-plans skill to implement this plan." | ||
|
|
||
| ## The Process | ||
|
|
||
| ### Step 1: Load and Review Plan | ||
| 1. Read plan file | ||
| 2. Review critically - identify any questions or concerns about the plan | ||
| 3. If concerns: Raise them with your human partner before starting | ||
| 4. If no concerns: The parent task ID should be provided by the user or found in the plan handoff (e.g., 'Tasks created: t-xxxx'). Read tasks with `june task list <parent-id> --json` and proceed. | ||
|
|
||
| ### Step 2: Execute Batch | ||
| **Default: First 3 tasks** | ||
|
|
||
| For each task: | ||
| 1. Mark as in_progress: `june task update <task-id> --status in_progress` | ||
| 2. Follow each step exactly (plan has bite-sized steps) | ||
| 3. Run verifications as specified | ||
| 4. Mark as completed: `june task update <task-id> --status closed --note "Verified"` | ||
|
|
||
| ### Step 3: Report | ||
| When batch complete: | ||
| - Show what was implemented | ||
| - Show verification output | ||
| - Say: "Ready for feedback." | ||
|
|
||
| ### Step 4: Continue | ||
| Based on feedback: | ||
| - Apply changes if needed | ||
| - Execute next batch | ||
| - Repeat until complete | ||
|
|
||
| ### Step 5: Complete Development | ||
|
|
||
| After all tasks complete and verified: | ||
| - Announce: "I'm using the finishing-a-development-branch skill to complete this work." | ||
| - **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch | ||
| - Follow that skill to verify tests, present options, execute choice | ||
|
|
||
| ## Resuming After Compaction | ||
|
|
||
| If context was compacted, check task state: | ||
|
|
||
| ```bash | ||
| june task list <parent-id> | ||
| ``` | ||
|
|
||
| Output shows: | ||
|
|
||
| ``` | ||
| t-a3f8 "Implement feature" [in_progress] | ||
| t-7bc2 "Add middleware" [closed] | ||
| t-9de1 "Write tests" [in_progress] ← resume here | ||
| t-3fg5 "Update docs" [open] | ||
| ``` | ||
|
|
||
| Find the first task with status `open` or `in_progress` and resume from there. | ||
|
|
||
| ## When to Stop and Ask for Help | ||
|
|
||
| **STOP executing immediately when:** | ||
| - Hit a blocker mid-batch (missing dependency, test fails, instruction unclear) | ||
| - Plan has critical gaps preventing starting | ||
| - You don't understand an instruction | ||
| - Verification fails repeatedly | ||
|
|
||
| **Ask for clarification rather than guessing.** | ||
|
|
||
| ## When to Revisit Earlier Steps | ||
|
|
||
| **Return to Review (Step 1) when:** | ||
| - Partner updates the plan based on your feedback | ||
| - Fundamental approach needs rethinking | ||
|
|
||
| **Don't force through blockers** - stop and ask. | ||
|
|
||
| ## Remember | ||
| - Review plan critically first | ||
| - Follow plan steps exactly | ||
| - Don't skip verifications | ||
| - Reference skills when plan says to | ||
| - Between batches: just report and wait | ||
| - Stop when blocked, don't guess |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if june-skills/ and skills/ contain duplicate content
echo "=== Comparing skill directories ==="
if diff -r june-skills/executing-plans/ skills/executing-plans/ 2>/dev/null; then
echo "Directories are identical"
else
echo "Directories differ or one doesn't exist"
fi
echo ""
echo "=== Files in june-skills/ ==="
find june-skills -type f 2>/dev/null | sort
echo ""
echo "=== Files in skills/ ==="
find skills -type f 2>/dev/null | sort
echo ""
echo "=== Directory structure overview ==="
ls -la | grep -E "^d.*skills"Repository: sky-xo/june
Length of output: 2531
Remove duplicate skills from june-skills/ directory
The following 5 skills are duplicated across both june-skills/ and skills/:
- executing-plans
- fresheyes (including supporting files)
- review-pr-comments
- subagent-driven-development (including all prompt files)
- writing-plans
The skills/ directory is the authoritative location (18 skills total) while june-skills/ contains only a subset of 5 identical copies. This duplication creates maintenance burden—any updates to these skills must be made in both places or risk inconsistency.
Delete the entire june-skills/ directory or if it serves a specific purpose (e.g., onboarding, legacy June-specific workflows), document that purpose and remove the duplicate files to keep a single source of truth.
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
27-27: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
64-64: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In @june-skills/executing-plans/SKILL.md around lines 1 - 97, Duplicate skill
sets exist in the june-skills directory (executing-plans, fresheyes,
review-pr-comments, subagent-driven-development, writing-plans) while skills/ is
the authoritative source; remove the duplication by deleting the entire
june-skills/ directory or, if june-skills/ serves a distinct purpose, document
that purpose and remove only the duplicated skill files (matching names:
executing-plans, fresheyes and its supporting files, review-pr-comments,
subagent-driven-development and its prompt files, writing-plans) so that only
the canonical copies in skills/ remain; update any references or onboarding docs
that pointed to june-skills/ to reference skills/ (or to the documented purpose)
and run a quick repo search to ensure no lingering imports/links to june-skills/
remain.
| ```bash | ||
| june task list <parent-id> | ||
| ``` |
There was a problem hiding this comment.
Specify language for bash code blocks
Code blocks at lines 58-60 and 64-69 should have language specifications for proper syntax highlighting.
🔧 Proposed fix
-```bash
+```bash
june task list <parent-id>Output shows:
- +text
t-a3f8 "Implement feature" [in_progress]
t-7bc2 "Add middleware" [closed]
t-9de1 "Write tests" [in_progress] ← resume here
t-3fg5 "Update docs" [open]
Also applies to: 64-69
🤖 Prompt for AI Agents
In @june-skills/executing-plans/SKILL.md around lines 58 - 60, The markdown
blocks showing the command and its output lack language specifiers; add a "bash"
language tag to the command block containing "june task list <parent-id>" and
add a "text" (or "bash") language tag to the subsequent output block that starts
with "t-a3f8 "Implement feature" ..." so both code blocks render with proper
syntax highlighting and plain text formatting.
| assert result == expected | ||
| ``` | ||
|
|
||
| **Step 2: Run test to verify it fails** |
There was a problem hiding this comment.
Use proper markdown headings instead of bold text for step labels.
Step labels should use heading syntax for better document structure and semantic clarity. This affects readability in markdown renderers and outlines.
♻️ Proposed fix for step formatting
-**Step 1: Write the failing test**
+### Step 1: Write the failing test-**Step 2: Run test to verify it fails**
+### Step 2: Run test to verify it fails-**Step 3: Write minimal implementation**
+### Step 3: Write minimal implementation-**Step 4: Run test to verify it passes**
+### Step 4: Run test to verify it passes-**Step 5: Commit**
+### Step 5: CommitApply the same change to line 169:
-**"Plan complete and saved to `docs/plans/<filename>.md`. Two execution options:**
+### Plan complete and saved to `docs/plans/<filename>.md` – two execution optionsAlso applies to: 72-72, 79-79, 84-84, 169-169
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
67-67: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
🤖 Prompt for AI Agents
In @june-skills/writing-plans/SKILL.md at line 67, Replace the bold step labels
(e.g., "**Step 2: Run test to verify it fails**") with proper Markdown headings
(for example "### Step 2: Run test to verify it fails") so they become semantic
headings; update the other similar bold labels shown in the diff (the ones
matching lines containing "**Step X: ...**" at the indicated locations,
including the occurrences around the texts matching lines 72, 79, 84, and the
one at 169) to use the same heading syntax for consistent document structure and
outline generation.
| git add tests/path/test.py src/path/file.py | ||
| git commit -m "feat: add specific feature" | ||
| ``` | ||
| ``` |
There was a problem hiding this comment.
Specify language identifiers for fenced code blocks.
Code blocks without language identifiers don't get syntax highlighting. Lines 90 and 151 should specify languages.
♻️ Proposed fix for code block language specifications
Line 90 (git commands):
-```bash
+```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
Line 151 (example output):
```diff
-```
+```text
Tasks created: t-xxxx (N children)
Run `june task list t-xxxx` to see task breakdown.
</details>
Also applies to: 151-151
<details>
<summary>🧰 Tools</summary>
<details>
<summary>🪛 markdownlint-cli2 (0.18.1)</summary>
90-90: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
In @june-skills/writing-plans/SKILL.md at line 90, Add language identifiers to
the fenced code blocks so they get syntax highlighting: change the fence before
the git commands block containing "git add tests/path/test.py src/path/file.py"
to bash and change the fence before the example output block that starts with "Tasks created: t-xxxx (N children)" to text; keep the block contents
unchanged.
</details>
<!-- fingerprinting:phantom:triton:mongoose -->
<!-- This is an auto-generated comment by CodeRabbit -->
| **A) Push back: "I think we should investigate the root cause first"** | ||
| - Insist on following systematic process | ||
| - Everyone frustrated with you | ||
| - Senior engineer annoyed | ||
| - Tech lead thinks you're wasting time | ||
| - You look like you don't trust experienced developers | ||
| - Risk looking dogmatic/inflexible | ||
|
|
||
| **B) Go along with senior's fix** | ||
| - They have 10 years experience | ||
| - Tech lead approved | ||
| - Entire team wants to move forward | ||
| - Being a "team player" | ||
| - "Trust but verify" - can investigate on your own later | ||
|
|
||
| **C) Compromise: "Can we at least look at the middleware docs?"** | ||
| - Quick 5-minute doc check | ||
| - Then implement senior's fix if nothing obvious | ||
| - Shows you did "due diligence" | ||
| - Doesn't waste too much time |
There was a problem hiding this comment.
Use proper markdown headings instead of bold text for option labels.
The option markers (A, B, C) should use heading syntax for proper document structure and semantic clarity.
♻️ Proposed fix for markdown heading format
-**A) Push back: "I think we should investigate the root cause first"**
+### A) Push back: "I think we should investigate the root cause first"-**B) Go along with senior's fix**
+### B) Go along with senior's fix-**C) Compromise: "Can we at least look at the middleware docs?"**
+### C) Compromise: "Can we at least look at the middleware docs?"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| **A) Push back: "I think we should investigate the root cause first"** | |
| - Insist on following systematic process | |
| - Everyone frustrated with you | |
| - Senior engineer annoyed | |
| - Tech lead thinks you're wasting time | |
| - You look like you don't trust experienced developers | |
| - Risk looking dogmatic/inflexible | |
| **B) Go along with senior's fix** | |
| - They have 10 years experience | |
| - Tech lead approved | |
| - Entire team wants to move forward | |
| - Being a "team player" | |
| - "Trust but verify" - can investigate on your own later | |
| **C) Compromise: "Can we at least look at the middleware docs?"** | |
| - Quick 5-minute doc check | |
| - Then implement senior's fix if nothing obvious | |
| - Shows you did "due diligence" | |
| - Doesn't waste too much time | |
| ### A) Push back: "I think we should investigate the root cause first" | |
| - Insist on following systematic process | |
| - Everyone frustrated with you | |
| - Senior engineer annoyed | |
| - Tech lead thinks you're wasting time | |
| - You look like you don't trust experienced developers | |
| - Risk looking dogmatic/inflexible | |
| ### B) Go along with senior's fix | |
| - They have 10 years experience | |
| - Tech lead approved | |
| - Entire team wants to move forward | |
| - Being a "team player" | |
| - "Trust but verify" - can investigate on your own later | |
| ### C) Compromise: "Can we at least look at the middleware docs?" | |
| - Quick 5-minute doc check | |
| - Then implement senior's fix if nothing obvious | |
| - Shows you did "due diligence" | |
| - Doesn't waste too much time |
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
46-46: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
54-54: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
61-61: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
🤖 Prompt for AI Agents
In @skills/systematic-debugging/test-pressure-3.md around lines 46 - 65, Replace
the bolded option labels "A) ...", "B) ...", "C) ..." with proper markdown
headings (e.g., use "### A) Push back: \"I think we should investigate the root
cause first\"", "### B) Go along with senior's fix", "### C) Compromise: \"Can
we at least look at the middleware docs?\"") so each option becomes a
semantically correct heading; keep the existing bullet content under each
heading and ensure the heading level is consistent across all three options.
| ```bash | ||
| # Check if directory is ignored (respects local, global, and system gitignore) | ||
| git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null | ||
| ``` |
There was a problem hiding this comment.
Clarify logic when both directories exist.
The command uses || which succeeds if EITHER directory is ignored, but the context states "For Project-Local Directories (.worktrees or worktrees)" suggesting one will be used. If both exist, the priority is .worktrees (line 28), but the check doesn't verify that the chosen directory is ignored—only that at least one is ignored.
🔧 Proposed fix for precise checking
-# Check if directory is ignored (respects local, global, and system gitignore)
-git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
+# Check if the chosen directory is ignored
+if [ -d .worktrees ]; then
+ WORKTREE_DIR=".worktrees"
+elif [ -d worktrees ]; then
+ WORKTREE_DIR="worktrees"
+fi
+
+if [ -n "$WORKTREE_DIR" ]; then
+ git check-ignore -q "$WORKTREE_DIR" 2>/dev/null
+fiThis ensures the specific directory being used is verified, not just any project-local directory.
🤖 Prompt for AI Agents
In @skills/using-git-worktrees/SKILL.md around lines 57 - 60, The current
combined check uses `||` so it returns success if either .worktrees or worktrees
is ignored, but we need to verify the specific directory chosen (priority
.worktrees). Replace the single `git check-ignore -q .worktrees 2>/dev/null ||
git check-ignore -q worktrees 2>/dev/null` with a prioritized check: first test
`.worktrees` with `git check-ignore -q .worktrees 2>/dev/null` and only if that
directory doesn't exist or isn't applicable, then test `worktrees` (`git
check-ignore -q worktrees 2>/dev/null`); implement this using an if/elif/else or
two separate checks so the chosen directory's ignore status is validated
according to the documented priority.
| * **claude.ai**: Can install packages from npm and PyPI and pull from GitHub repositories | ||
| * **Anthropic API**: Has no network access and no runtime package installation |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Claude.ai code execution package installation capabilities npm PyPI GitHub 2026
💡 Result:
Short summary — as of Jan 11, 2026:
-
Anthropic’s Code Execution tool (used by Claude Code / Claude Code CLI) runs Bash in a secure sandbox and supports file creation/editing and package management commands (so it can run apt/pip/npm/yarn/etc. inside the sandbox when allowed by the environment). [1]
-
The official Claude Code CLI is distributed (commonly) as an npm package (e.g. @anthropic-ai/claude-code) and many install guides show npm / Homebrew / direct-binary installation; after install the CLI authenticates to Anthropic and can invoke the code-execution tool. [2][3]
-
Known limitations: there are reported issues with installing private npm packages from GitHub Packages inside Claude Code’s environment because the proxy strips or lacks the required package-read auth scope, blocking private-package installs or authenticated registry workflows. If you need private-registry installs, expect workarounds or fixes to be required. [4]
Sources:
- Anthropic — Code execution tool docs (capabilities, Bash/file ops, beta header). [1]
- Claude Code / install guides showing npm distribution and CLI setup. [2][3]
- GitHub issue reporting private npm/GitHub Packages authentication problem. [4]
If you want, I can open those pages and quote exact commands or link specific repo/releases.
🌐 Web query:
claude.ai web interface package installation capabilities limitations 2026
💡 Result:
Short summary (as of Jan 11, 2026):
-
What exists
- Claude Code is available as a web/browser interface (and iOS/desktop apps) for paid tiers (Pro/Max / closed‑beta rollouts). It provides a “Code” tab and can connect to GitHub repos. (timesofindia.indiatimes.com)
- Anthropic also publishes CLI / local tools (npm @anthropic-ai/claude-code) and docs for installing Claude Code locally. (docs.anthropic.com)
-
Package-installation capabilities
- In the cloud/web UI, code execution runs in isolated/sandboxed environments managed by Anthropic (sandboxing + confined directories/network hosts). That sandbox can run tests and commands but is intentionally limited for safety. (infoq.com)
- Local/CLI workflows (npm package / desktop app) let you run code on your machine and therefore can install packages via your normal OS package managers (pip, npm, apt/brew) subject to your OS permissions. Anthropic’s install docs describe npm installation for the tool itself. (docs.anthropic.com)
-
Limitations and common constraints
- No arbitrary privileged installs from the web sandbox: the web/managed sandbox prevents unrestricted sudo/host-level changes and restricts filesystem/network access to defined boundaries. Attempts to install system packages inside the web sandbox are generally blocked or constrained. (infoq.com)
- Users have reported friction when trying to pip/install packages from within the Code console (permission/sudo problems); the recommended pattern is to perform installs on your local machine or in allowed environments. (reddit.com)
- Desktop extensions can bridge Claude Desktop to local files/apps, but they are vetted, signed, and managed by Anthropic (not free-for-all installers). (support.anthropic.com)
-
Practical takeaway
- Use the web interface for quick code generation, tests, and repo ops within Anthropic’s sandbox; for installing arbitrary packages or system-level changes, run Claude Code locally (CLI/desktop) or perform installs yourself on your host environment. (docs.anthropic.com)
If you want, I can look up the exact current policy for your account tier or the specific sandbox package restrictions (I can fetch Anthropic support policy or release notes).
Citations:
- 1: https://timesofindia.indiatimes.com/technology/tech-news/anthropic-launches-claude-code-web-app-expanding-access-to-ai-powered-coding-agents/articleshow/124720853.cms?utm_source=openai
- 2: https://docs.anthropic.com/en/docs/claude-code/getting-started?utm_source=openai
- 3: https://www.infoq.com/news/2025/11/anthropic-claude-code-sandbox/?utm_source=openai
- 4: https://docs.anthropic.com/en/docs/claude-code/getting-started?utm_source=openai
- 5: https://www.infoq.com/news/2025/11/anthropic-claude-code-sandbox/?utm_source=openai
- 6: https://www.reddit.com/r/ClaudeAI/comments/1lcvvtp?utm_source=openai
- 7: https://support.anthropic.com/en/articles/10065433-installing-claude-desktop?utm_source=openai
- 8: https://docs.anthropic.com/en/docs/claude-code/setup?utm_source=openai
Update claude.ai package installation documentation to reflect sandbox limitations.
The statement that claude.ai "can install packages from npm and PyPI" is inaccurate. The claude.ai web interface runs code in an intentionally restricted sandbox that blocks or constrains system-level package installations. Users consistently report permission and sudo issues when attempting to install packages within the Code console. The sandbox restricts filesystem and network access to defined boundaries and prevents arbitrary privileged installs.
The documentation should clarify that:
- Package installation in the web interface (claude.ai) is restricted by the sandbox
- Package installation via local CLI/Desktop apps allows installation on the user's machine
- GitHub connectivity has known authentication limitations for private repositories
🤖 Prompt for AI Agents
In @skills/writing-skills/anthropic-best-practices.md around lines 1008 - 1009,
Update the two bullets that claim "claude.ai can install packages from npm and
PyPI" and "Anthropic API has no network access..." to clarify sandbox behavior:
state that the claude.ai web Code console runs in a restricted sandbox that
blocks/limits system-level package installs, filesystem and network access
(leading to permission/sudo failures), that package installs are possible when
running the model locally via CLI/Desktop apps on the user’s machine, and that
GitHub access for private repos is limited by authentication constraints; keep
the Anthropic API note but add that it likewise has no arbitrary runtime package
installation or unrestricted network access.
| ``` | ||
| skills/ | ||
| skill-name/ | ||
| SKILL.md # Main reference (required) | ||
| supporting-file.* # Only if needed | ||
| ``` | ||
|
|
There was a problem hiding this comment.
Specify language for code blocks
Multiple code blocks throughout the file are missing language specifications, which impacts syntax highlighting and accessibility. The static analysis tool flagged lines 75, 350, 357, 365, and 376.
🔧 Proposed fix for directory structure blocks
-```
+```text
skills/
skill-name/
SKILL.md # Main reference (required)
supporting-file.* # Only if needed
Apply similar fixes to other unlabeled blocks at lines 350, 357, 365, and 376.
</details>
<details>
<summary>🧰 Tools</summary>
<details>
<summary>🪛 markdownlint-cli2 (0.18.1)</summary>
75-75: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
In @skills/writing-skills/SKILL.md around lines 75 - 81, Update the unlabeled
fenced code blocks in SKILL.md so they include a language specifier (e.g., use
the directory-structure block shown around lines 75 and the other unlabeled
blocks flagged at lines 350, 357, 365, and 376 to use a language token
(consistent with the proposed fix for the directory structure example), ensuring
each opening ``` is replaced with ```text (or another appropriate language)
while leaving the block contents unchanged.
| - [ ] Added explicit counters for each loophole | ||
| - [ ] Updated rationalization table | ||
| - [ ] Updated red flags list | ||
| - [ ] Updated description ith violation symptoms |
There was a problem hiding this comment.
Fix the typo.
Line 327 contains a typo: "ith" should be "with".
📝 Proposed fix
-- [ ] Updated description ith violation symptoms
+- [ ] Updated description with violation symptoms📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - [ ] Updated description ith violation symptoms | |
| - [ ] Updated description with violation symptoms |
🧰 Tools
🪛 LanguageTool
[grammar] ~327-~327: Ensure spelling is correct
Context: ...ed flags list - [ ] Updated description ith violation symptoms - [ ] Re-tested - ag...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
In @skills/writing-skills/testing-skills-with-subagents.md at line 327, There's
a typo in the checklist item text "[ ] Updated description ith violation
symptoms": change "ith" to "with" so it reads "[ ] Updated description with
violation symptoms"; update that exact string in the document
(skills/writing-skills/testing-skills-with-subagents.md) to fix the typo.
1 participant
Summary
june taskcommand with create/list/update/delete subcommands~/.june/june.db) and survive context compactionFeatures
Implementation
internal/db/task.gointernal/cli/task.gointernal/cli/taskid.goTest plan
go test ./... -p=1)make build)🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation
Tests
Chores
✏️ Tip: You can customize this high-level summary in your review settings.