Skip to content

Extend the management skills

Audience. Daily user and Developer.

When to read this. You ran condash skills install to drop the shipped skills into <conception>/.agents/skills/, used them for a week, and hit "I wish this also did X". This page shows how to add team-specific behaviour without losing access to upstream updates.

The shipped skills are intentionally minimal — they cover the conception convention itself, not your team's workflow on top of it. Two extension paths exist; pick whichever matches your update cadence.

For the base reference (every action, every CLI verb each one wraps), see the management skills reference.

Where the skills live

condash ships five skills:

# After running `condash skills install`
<conception>/.agents/skills/applications/
<conception>/.agents/skills/knowledge/
<conception>/.agents/skills/pr/
<conception>/.agents/skills/projects/
<conception>/.agents/skills/visual/

Each directory contains a SKILL.md (the entry point) plus per-action detail files (e.g. create.md, close.md for /projects) and, where a harness needs its own frontmatter, an optional SKILL.<harness>.md overlay (e.g. SKILL.claude.md). The sources are placed verbatim — the harness launcher renders them per agent at run time.

The manifest at <conception>/.agents/.condash-skills.json tracks the shipped version + SHA256 per file. condash skills install is non-interactive. When a file's on-disk content differs from what it shipped, the install refuses that file and exits with a validation error:

3 item(s) refused (locally edited). Re-run with --force to overwrite or --diff to inspect.

There is no prompt and no yes/no. Your customisations are never clobbered silently — but they are also never merged for you.

Path 1 — fork the shipped files

The simplest extension: edit the file in place. Add a section to SKILL.md, change a step in create.md, override a default flag in close.md. The next condash skills install detects the drift and refuses that file, leaving your copy untouched and exiting non-zero. Two flags steer it from there:

  • --diff — print what upstream would have written, so you can merge by hand.
  • --force — overwrite your edit with the shipped version.

Doing nothing keeps your local copy, which is the point: the default is safe, and taking an upstream change is an explicit act.

This is the right path when:

  • The change is small (a few lines).
  • The change is universally appropriate for your team.
  • You're willing to manually re-merge upstream changes once or twice a year.

It is the wrong path when the change is large or speculative — those go in path 2.

Path 2 — wrap with a custom skill

Write a separate /my-team-projects (or whatever name) skill that runs your extra logic and then delegates to the shipped one. Example shape:

# /my-team-projects — wrapper

Trigger: `/my-team-projects <action> [args]`

When invoked, run the team-specific pre-step (below), then dispatch to the shipped `/projects` skill for the base operation.

## Action: create

1. Ask the user the standard fields plus the team-specific `**Linear ID**:` header.
2. Run `/projects create` with the gathered fields.
3. After creation, append the Linear ID line to the README header, between `apps` and `## Goal`.
4. Open the matching Linear ticket in the browser via `condash openExternal`.

This keeps upstream /projects updates painless: the shipped skill evolves without touching your wrapper.

It is the right path when:

  • The change is large or has side effects (creating tickets, posting Slack, generating PDFs).
  • The change is project-specific (you don't want it loaded in every conception).
  • You want to share the wrapper as a separate package or repo.

Worked extensions

The patterns below are realistic shapes — copy and adapt to your tree.

Branch isolation on create

Problem. Your projects-that-touch-code need to work in a git worktree, not the main checkout. The shipped /projects create writes the README and stops; you want it to also scaffold the worktree when the item declares a branch.

Wrapper sketch. After /projects create returns:

condash worktrees setup <branch>

Run it only when the new item has a branch field. The shipped /projects create already prompts for it; the wrapper just observes the result and runs the setup command. condash worktrees setup is the canonical path — it knows where worktrees live (the worktrees_path key in .condash/settings.json), and by default it both copies the files listed in each repo's env: key and runs its install: hook.

The flags a wrapper author actually needs:

Flag Effect
--repo <r> Restrict to specific repos (comma-separated) instead of every repo declaring the branch.
--base <ref> Base ref. Defaults to Base from the declaring items' READMEs; with no base at all each repo branches from its default-branch tip.
--no-install Skip the per-repo install: command.
--no-env Skip the per-repo env: file copy.

--copy-env no longer exists — a repo without an env: key gets no env-file copy. Declare env: [...] on the repo entry instead; it applies unconditionally and is explicit about what gets copied. See Repositories and open-with launchers.

Deliverable generation on close

Problem. When a document kind item closes, you want the deliverable PDF regenerated from the latest notes without anyone remembering.

Wrapper sketch. Override the close action: before calling /projects close, locate the canonical note (look for a ## Deliverables line pointing at a .md source, or fall back to the longest note body) and run your md_to_pdf pipeline. Verify the output is non-empty, then delegate to /projects close. Fail loudly if the PDF generation fails — a stale deliverable in a done item is worse than an item stuck in review.

This pattern only fits document-kind items; project and incident items rarely have a single canonical deliverable.

Notes index on add-note

Problem. Items accumulate notes. Without an index, the only way to discover what's in the notes/ folder is the Files panel.

Wrapper sketch. After creating a note — a skill runs in a terminal, so it writes the file directly under notes/NN-<slug>.md; there is no CLI verb and no IPC available to it — edit the README:

  1. Locate ## Notes. If absent, append one before ## Timeline.
  2. Add a bullet - [filename](notes/filename.md) — <first 80 chars of body>.
  3. Keep bullets in alphabetical order; update existing bullets in place rather than duplicating.

Don't touch hand-written bullets for other files — only manage the bullet for the file you just created.

Why not ship these by default

Each pattern assumes something the conception convention itself doesn't:

  • Branch isolation assumes you have a worktrees_path configured and that branch is part of your workflow.
  • Deliverable generation assumes a specific md_to_pdf pipeline is available and that document items have a canonical note.
  • Notes index assumes the README has a ## Notes section and that notes have first-paragraph summaries.

None of these are universal. The shipped skills stay at the intersection of what every conception tree needs; team-specific conventions are one fork (or one wrapper) away.

Reference