New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Senpi Todotools Extension Worker

by code-yeongyu in code-yeongyu/senpi

Worker brief for implementing one pre-assigned feature in the senpi todotools built-in extension, with strict scope, typing, testing and git-safety rules.

MITAuto-check passedDevelopment

Install Senpi Todotools Extension Worker

skills CLI
$ npx skills add code-yeongyu/senpi --skill coding-agent-extension-worker -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install code-yeongyu/senpi coding-agent-extension-worker --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/code-yeongyu/senpi.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.factory/skills/coding-agent-extension-worker .claude/skills/coding-agent-extension-worker && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
coding-agent-extension-worker
GitHub stars
470
Token cost
~2.8k tokens
SKILL.md length
1,468 words
Files
1
Skills in repo
7
Repo updated
First seen
Licence
MIT

At a glance

Worker brief for implementing one pre-assigned feature in the senpi todotools built-in extension, with strict scope, typing, testing and git-safety rules.

  • Works in 9 steps: Orient (≤ 5 minutes) → Investigate the existing code (≤ 15… → Plan the edits (brief) → …
  • Implementing an assigned feature in the todotools extension from a feature list
  • SKILL.md covers Context you MUST read before…, Hard rules — never violate, Procedure and Mission-documented baseline…, plus 4 more sections
  • Calls git and npm

What it does

The agent implements exactly one feature from `features.json`, working only against that feature's description, preconditions, expected behavior, verification steps and the assertions it fulfills. Before starting it reads the mission document, the validation contract, the architecture, environment and user-testing notes under `.factory/library`, and both the mission and root `AGENTS.md` files.

Hard rules keep the work inside the `todotools` extension and `builtin/index.ts`, leaving core packages and other extension files untouched. Type suppressions such as `any` and `@ts-ignore` are banned in that folder, imports must be top-level, tests use a faux provider through `createHarness` and never real LLM calls, and git use is limited to adding specific paths with no force flags, hard resets or stashes, committing only files touched in the session. Emojis are not allowed. It covers refactoring, the continuation runtime, config resolver, prompt builder, tests, golden snapshots and changelog entries, but not manual tmux QA.

When your agent uses it

  • Implementing an assigned feature in the todotools extension from a feature list
  • Writing tests and golden snapshots for the continuation runtime or config resolver
  • Adding a changelog entry and harness helpers alongside an extension change

Example prompts

  • “Implement the feature assigned in features.json and make its fulfilled assertions pass.”
  • “Add golden snapshot tests for the todotools prompt builder using the faux provider harness.”
  • “Refactor the config resolver in todotools and add the CHANGELOG entry.”

Requirements

  • A checkout of the senpi-mono repository with `features.json` and the mission documents

Workflow steps

9 steps, taken from the step headings in SKILL.md.

  1. Orient (≤ 5 minutes)
  2. Investigate the existing code (≤ 15 minutes)
  3. Plan the edits (brief)
  4. Implement
  5. Verify your feature's contract assertions
  6. Run the verification commands
  7. Review diff before commit
  8. Commit
  9. Handoff

What it can do on your machine

Read from SKILL.md and the folder at commit 0fa9139. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • npm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and npm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Senpi Todotools Extension Worker loads about 2.8k tokens when it runs. Until then it costs about 72 tokens; SKILL.md has 1,468 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~72
When it runs · the whole SKILL.md, loaded when a task matches
~2.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from code-yeongyu/senpi at commit 0fa9139, republished under its MIT licence (© code-yeongyu). 1,468 words, ~2,843 tokens.

Download SKILL.mdSave it as .claude/skills/coding-agent-extension-worker/SKILL.md (or your agent's skills folder).
name
coding-agent-extension-worker
description
Implements a single feature in the pi-mono `todotools` builtin extension work. Use for refactoring, continuation runtime, config resolver, prompt builder, test authoring, golden snapshots, CHANGELOG entries, and harness helpers. Does NOT do manual tmux QA.

Coding Agent Extension Worker

You are implementing exactly ONE feature from features.json in the senpi-mono coding-agent package. Your feature has been pre-assigned — read it from features.json, identify it by its id, and focus exclusively on its description, preconditions, expectedBehavior, verificationSteps, and the assertions listed in fulfills.

Context you MUST read before starting

  1. Feature spec: features.json — your assigned feature only.
  2. Mission document: mission.md in the mission directory — for overall context.
  3. Validation contract: validation-contract.md — each ID in your feature's fulfills describes the exact pass/fail condition you must satisfy. Read ALL your fulfills entries before you start.
  4. Architecture: .factory/library/architecture.md — the target system shape. Your work MUST conform to this.
  5. Environment notes: .factory/library/environment.md — tooling quirks, forbidden patterns.
  6. User testing surface: .factory/library/user-testing.md — test infrastructure conventions.
  7. Mission agents guidance: AGENTS.md in the mission directory — boundaries, conventions, git safety rules.
  8. Project agents guidance: the root AGENTS.md at the repo root (senpi-mono coding guidelines) — fork strategy, commit conventions, anti-patterns.

Hard rules — never violate

  • Fork strategy: Every change is a builtin-extension change. You may not modify packages/ai, packages/agent, packages/tui, packages/mom, packages/pods, packages/coding-agent/src/core/settings-manager.ts, packages/coding-agent/src/core/extensions/types.ts, runner.ts, loader.ts, wrapper.ts, or any other builtin extension besides todotools/ and builtin/index.ts.
  • No type suppressions: any, as any, @ts-ignore, @ts-expect-error are forbidden across all files in builtin/todotools/. Use explicit type guards instead.
  • No inline imports: top-level ES imports only. Never await import() or import("pkg").Type.
  • No real LLM calls in tests: always use the faux provider via createHarness.
  • Git safety: only git add <specific-path>. Never -A, never ., never --no-verify, never reset --hard, never checkout ., never clean -fd, never stash.
  • Only commit files you touched in this session. Inspect git status before staging.
  • No emojis in code, commits, test names, or PR comments.
  • Biome enforced: 3-space / tab indent matching the existing file style, 120-char line width.
  • tsc enforced: all code compiles cleanly with no diagnostics.

Procedure

Step 1 — Orient (≤ 5 minutes)

Read in this order: your feature entry in features.json, the fulfills assertions in validation-contract.md, .factory/library/architecture.md, .factory/library/environment.md, mission AGENTS.md, root project AGENTS.md. Do not start coding until you have read all of these. If anything is ambiguous or conflicts with what's on disk, return to orchestrator instead of guessing.

Step 2 — Investigate the existing code (≤ 15 minutes)

Explore the relevant source files before writing any code:

  • For refactor work: read packages/coding-agent/src/core/extensions/builtin/todowrite.ts (pre-refactor) AND builtin/index.ts (registration).
  • For continuation work: read packages/coding-agent/src/core/extensions/types.ts (search for agent_end, sendUserMessage, registerFlag, getFlag, BeforeAgentStartEvent) to confirm signatures. Also read packages/coding-agent/docs/extensions.md sections on those APIs. Read the existing permission-system/settings.ts for the canonical "read settings via SettingsManager without widening the interface" pattern.
  • For test work: read test/suite/harness.ts, test/suite/todowrite-extension.test.ts, test/utilities.ts to understand the faux provider pattern.

Use Grep, Glob, and Read tools. Prefer reading real source over trusting summaries.

Step 3 — Plan the edits (brief)

List the files you will create, edit, or delete for this feature. Verify each is inside the allowed paths. If any file is outside the allow-list, stop and return to orchestrator.

Step 4 — Implement

Make the edits. Match the existing code style (tabs, indent, type annotations). When you write a new module:

  • Use top-level ES imports.
  • Export only the public symbols your feature requires.
  • Prefer small, focused functions with explicit types.
  • For runtime event handlers, wrap the body in try/catch and log errors — never let a throw escape the extension API surface.
  • For pure functions (config resolver, prompt builder), forbid any filesystem or process imports.
Step 5 — Verify your feature's contract assertions

For each assertion ID in your feature's fulfills, confirm the evidence requirement is actually met by your implementation. Re-read the behavioral description in validation-contract.md. If an assertion requires a specific file, a specific grep result, a specific test outcome — satisfy it exactly.

Step 6 — Run the verification commands

Run your feature's verificationSteps in the order listed. They typically include:

  • File existence checks.
  • Grep checks for forbidden patterns.
  • Package-level vitest runs for your test files (.factory/services.yaml test-coding-agent or test-coding-agent-file commands).
  • Full coding-agent vitest run.
  • npm run check at the repo root.

Capture all output. If any step fails, diagnose and fix. Do NOT mark the feature done with failing verification.

Step 7 — Review diff before commit

Run git status and git diff to inspect every change. Confirm:

  • No files outside your allow-list are modified.
  • No out-of-scope files are staged.
  • No accidental deletions.
  • No accidental large binary additions.
  • No local-ignore/ files are staged.
Step 8 — Commit

Stage with explicit paths only. Commit with a conventional message scoped to your feature. Do not push.

Step 9 — Handoff

Return a structured handoff (the mission runner collects this):

  • successState: "success" (all assertions verified), "partial" (some assertions blocked, documented), or "failure" (unable to complete).
  • filesChanged: the exact list of paths you created/modified/deleted.
  • verifications: the verification commands you ran and their outcomes.
  • discoveredIssues: anything you noticed about the codebase that's broken or concerning but outside your feature scope (do not silently ignore — surface it).
  • whatWasLeftUndone: anything you skipped or couldn't finish inside your scope. If anything, explain why.
  • criticalContext: anything a subsequent worker needs to know that isn't already in the architecture or environment docs.
Show full SKILL.md (633 more words)Show less

Mission-documented baseline failures (precedence rule)

Mission AGENTS.md MAY contain a section titled "Known Pre-Existing Issues (Do Not Fix — Out of Scope)" listing test files and case counts that are red at the mission's base commit. When such a section exists, the following rule applies and overrides the generic "return on out-of-scope validator failure" escalation:

  1. After running the full test command, compare the set of failing files and the total failing case count against the documented baseline.
  2. If the observed set is exactly the documented set (same files, same total count), you MAY proceed and commit. The mission has explicitly waived these failures.
  3. If the observed set has any new file, any new failing case in a non-baseline file, a higher count in any baseline file, or a missing failure that the baseline expected, you MUST stop and return to orchestrator. This indicates either a regression introduced by your change or a baseline shift that needs orchestrator attention.
  4. Always include the observed-vs-documented comparison in your handoff verification log so the orchestrator can audit it.

Scoped pre-existing dirty state at session start

If git status at the start of your session shows uncommitted changes that are entirely inside your assigned feature's allowed paths, treat this as a recoverable in-progress state from a prior worker session, NOT an immediate escalation. Procedure:

  1. Run git status --short and git diff (and git diff --cached) over the dirty files. Confirm every dirty path is inside your feature's allow-list.
  2. If ANY dirty path is outside your allow-list, stop and return to orchestrator immediately — do not modify those files and do not commit them.
  3. If all dirty paths are in-scope, audit the changes against your feature's description, expectedBehavior, and fulfills. If they are correct and complete, proceed to Step 5 (verify) and Step 6 (run verification commands), then commit them as your feature's commit.
  4. If they are partially correct, finish them, then verify and commit.
  5. If they are wrong or contradict the spec, return to orchestrator with a summary — do NOT silently revert another worker's intent.

Untracked files outside your feature paths (e.g., .pi/permissions-approved.jsonl, .pi/settings.json, .sisyphus/, local-ignore/) are unrelated user-local artifacts and should be ignored, never staged.

Escalation triggers

Return control to the orchestrator immediately (do NOT attempt creative workarounds) when:

  • A required ExtensionAPI does not exist with the signature you expected.
  • A verification step fails for a reason outside your changes AND outside the mission-documented baseline failures (see precedence rule above).
  • You encounter uncommitted changes in the working tree you did not author AND the changes are outside your feature's allowed paths (see scoped dirty state rule above).
  • npm run check or npm run build fails for reasons unrelated to your edits.
  • You discover an assertion in your fulfills that is impossible to satisfy as written.
  • A boundary violation would be required to complete the feature.

Anti-patterns to avoid

  • Rewriting code that is not in your feature scope "while you're there."
  • Adding new CLI flags, config keys, or events not in the architecture document.
  • Using SettingsManager in ways that widen the upstream Settings interface.
  • Module-level mutable state (let currentState = ... at the top of a file). ALL state must live inside closures.
  • Using turn_end instead of agent_end for continuation (turn_end causes infinite recursion inside the tool loop).
  • Using as any or @ts-ignore to "unblock" a type issue — return to orchestrator instead.
  • Skipping verification "because the code looks right." Always run the tests.

Expected duration

  • Simple features (golden snapshot, changelog entry, CLI smoke): 15-30 minutes.
  • Medium features (config resolver, prompt builder, harness helper): 30-60 minutes.
  • Large features (full refactor, runtime handler, integration test suite): 60-120 minutes.

If your feature is running significantly over budget, stop, assess, and consider returning to the orchestrator with partial state plus a plan for breaking it down further.

© code-yeongyu, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .factory/skills/coding-agent-extension-worker of code-yeongyu/senpi.

Open the folder on GitHubat commit 0fa9139

Compare with similar skills

Senpi Todotools Extension Worker next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Senpi Todotools Extension Worker compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Senpi Todotools Extension Worker this skillcode-yeongyu/senpi470—~2.8kAutomated safety check: PassMIT
Effect TSmattiacerutti/supernova187—~2.8kAutomated safety check: PassMIT
Effect TSpproenca/dot-skills214—~2kAutomated safety check: PassMIT
Effect TStellahq/opensession392—~3.7kAutomated safety check: PassMIT
Tabler Shared Lib Helperstabler/tabler42k—~1.2kAutomated safety check: PassMIT
Typescript Idiomsirahardianto/awesome-agv157—~6.1kAutomated safety check: PassMIT

Similar skills

  • Effect TS

    mattiacerutti/supernova

    Write idiomatic Effect v4 TypeScript following official best practices from effect-solutions and the Effect source.

    187 GitHub stars~2.8k tokensUpdated today
    DevelopmentAuto-check passed

  • Effect TS

    pproenca/dot-skills

    Effect-TS library usage in TypeScript — Effect.gen generators, Schema.Struct/Schema.Class definitions, Layer/Context.Tag/Service patterns, Effect.pipe pipelines, Data.TaggedError/Data.Class error…

    214 GitHub stars~2k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

  • Effect TS

    tellahq/opensession

    Write idiomatic Effect v4 TypeScript verified against the pinned effect@4.0.0-rc.112 source.

    392 GitHub stars~3.7k tokensUpdated today
    Testing & QAAuto-check passed

  • Tabler Shared Lib Helpers

    tabler/tabler

    Moves logic out of Astro frontmatter into tested helper modules under shared/lib, with rules for naming, typing, deterministic demo data and sibling test files.

    42k GitHub stars~1.2k tokensUpdated today
    DevelopmentAuto-check passed

  • Typescript Idioms

    irahardianto/awesome-agv

    TypeScript strict typing: type narrowing, discriminated unions, Zod runtime validation, generic utility types, and Vitest testing.

    157 GitHub stars~6.1k tokensUpdated 2 days ago
    Testing & QAAuto-check passed

  • Vue Idioms

    irahardianto/awesome-agv

    Vue 3 Composition API patterns: <script setup syntax, reactive state with Pinia stores, reusable composables, and Vitest component testing.

    157 GitHub stars~6k tokensUpdated 2 days ago
    Testing & QAAuto-check passed

More from code-yeongyu/senpi

  • Senpi Agent QA Harness

    code-yeongyu/senpi

    Checks changes to the senpi coding agent by driving the real CLI from source in an isolated sandbox, over RPC, terminal UI, mock model and CLI smoke channels.

    470 GitHub stars~2.7k tokensUpdated today
    Auto-check: notes

  • Merge Upstream into Fork

    code-yeongyu/senpi

    Syncs a fork branch with its upstream remote using a history-preserving merge commit, with no rebase and no force push.

    470 GitHub stars~1.6k tokensUpdated today
    Auto-check passed

  • Bun 1.4 Builtins Guide

    code-yeongyu/senpi

    Points the agent at Bun 1.4 built-in APIs before it installs an npm package, so image, browser, markdown, cron, PTY and test work uses what Bun already ships.

    470 GitHub stars~1.3k tokensUpdated today
    Auto-check passed

  • GPT Image Prompt Guide

    code-yeongyu/senpi

    Prompt-crafting guide for gpt-image-2.5: which image tool to call, which model to pick, and how to write prompts, edit with references and refine over turns.

    470 GitHub stars~2.3k tokensUpdated today
    Auto-check passed

  • Senpi Release Publishing

    code-yeongyu/senpi

    Walks the canonical CalVer release flow for senpi, from a clean main checkout through changelog audit, checks, tag push, GitHub Release and npm publishing.

    470 GitHub stars~1.7k tokensUpdated today
    Auto-check passed

  • Tmux Manual QA Worker

    code-yeongyu/senpi

    Runs one manual QA scenario for the todo continuation feature in the real ./pi-test.sh CLI inside tmux, captures scrollback and checks a deterministic count marker.

    470 GitHub stars~1.6k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Senpi Todotools Extension Worker

What does Senpi Todotools Extension Worker do?

Worker brief for implementing one pre-assigned feature in the senpi todotools built-in extension, with strict scope, typing, testing and git-safety rules. json`, working only against that feature's description, preconditions, expected behavior, verification steps and the assertions it fulfills.md` files.

When should I use Senpi Todotools Extension Worker?

Senpi Todotools Extension Worker fits situations like: implementing an assigned feature in the todotools extension from a feature list; writing tests and golden snapshots for the continuation runtime or config resolver; adding a changelog entry and harness helpers alongside an extension change.

How do I install Senpi Todotools Extension Worker in Claude Code?

Run `npx skills add code-yeongyu/senpi --skill coding-agent-extension-worker -a claude-code`. Or copy the skill folder (.factory/skills/coding-agent-extension-worker in code-yeongyu/senpi) into .claude/skills/coding-agent-extension-worker in your project. Claude Code loads it when a task matches its description.

How do I install Senpi Todotools Extension Worker in Codex?

Run `npx skills add code-yeongyu/senpi --skill coding-agent-extension-worker -a codex`. Or copy the skill folder (.factory/skills/coding-agent-extension-worker in code-yeongyu/senpi) into .agents/skills/coding-agent-extension-worker in your project. Codex loads it when a task matches its description.

Can I use Senpi Todotools Extension Worker in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add code-yeongyu/senpi --skill coding-agent-extension-worker -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/coding-agent-extension-worker, .gemini/skills/coding-agent-extension-worker, .github/skills/coding-agent-extension-worker and .opencode/skills/coding-agent-extension-worker in your project.

What does Senpi Todotools Extension Worker need to run?

Going by SKILL.md and its folder, Senpi Todotools Extension Worker needs the command-line tools its instructions call (git and npm). Our summary lists: A checkout of the senpi-mono repository with `features.json` and the mission documents.

Does Senpi Todotools Extension Worker access the network?

SKILL.md contains no URLs. Its commands use git and npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Senpi Todotools Extension Worker safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Senpi Todotools Extension Worker use?

Senpi Todotools Extension Worker is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Senpi Todotools Extension Worker use?

About 2.8k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Senpi Todotools Extension Worker?

Skills that share tags, products or a category with Senpi Todotools Extension Worker: Effect TS (mattiacerutti/supernova, 187 stars), Effect TS (pproenca/dot-skills, 214 stars), Effect TS (tellahq/opensession, 392 stars) and Tabler Shared Lib Helpers (tabler/tabler, 42k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Senpi Todotools Extension Worker?

code-yeongyu (a GitHub user) maintains it in code-yeongyu/senpi, which has 470 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on October 7, 2026.

Source: code-yeongyu/senpi on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.