diff --git a/bin/README.md b/bin/README.md index a8c1a63..09a42f8 100644 --- a/bin/README.md +++ b/bin/README.md @@ -18,7 +18,7 @@ Auto-discovers (no hardcoded skill list) by scanning each organ repo's - **`PyAutoMind/skills/`** — registry-coupled skills (`create_issue`). - **`PyAutoBrain/skills/`** — development-workflow skills (`start_dev`, - `start_dev_for_user`, `plan_branches`, `start_library`, `start_workspace`, + `start_dev_for_user`, `start_library`, `start_workspace`, `ship_library`, `ship_workspace`, `register_and_iterate`, `repo_cleanup`, `update_issue`). - **`PyAutoHeart/skills/`** — status / readiness / validation skills diff --git a/bin/check_skill_line_counts.sh b/bin/check_skill_line_counts.sh index 3509033..e745021 100755 --- a/bin/check_skill_line_counts.sh +++ b/bin/check_skill_line_counts.sh @@ -35,25 +35,31 @@ for root in "${ROOTS[@]}"; do for dir in "$root"/*/; do [ -d "$dir" ] || continue name="$(basename "$dir")" - # Primary files: SKILL.md (dispatcher/frontmatter) and the command/body - # .md. Supporting docs (reference.md, examples, etc.) are exempt. + # The budget is the skill's MANDATORY LOAD: SKILL.md (dispatcher/ + # frontmatter) plus the command/body .md, summed — both are read + # on every invocation. Supporting docs (reference.md, examples, etc.) are + # lazy and exempt. + total=0 + found=0 for primary in "$dir/SKILL.md" "$dir/$name.md"; do [ -f "$primary" ] || continue - checked=$((checked + 1)) - lines=$(wc -l < "$primary") - if [ "$lines" -gt "$LIMIT" ]; then - echo "OVER ${lines} ${primary#$PYAUTO_ROOT/}" - over=$((over + 1)) - fi + found=1 + total=$((total + $(wc -l < "$primary"))) done + [ "$found" -eq 1 ] || continue + checked=$((checked + 1)) + if [ "$total" -gt "$LIMIT" ]; then + echo "OVER ${total} ${dir#$PYAUTO_ROOT/} (SKILL.md + $name.md)" + over=$((over + 1)) + fi done done echo "" if [ "$over" -eq 0 ]; then - echo "OK: all $checked primary skill files are within $LIMIT lines." + echo "OK: all $checked skills are within the $LIMIT-line mandatory-load budget." exit 0 else - echo "FAIL: $over primary skill file(s) exceed $LIMIT lines — factor detail into reference.md." + echo "FAIL: $over skill(s) exceed the $LIMIT-line mandatory-load budget — factor detail into reference.md." exit 1 fi diff --git a/bin/install.sh b/bin/install.sh index a64be5b..cdcb866 100755 --- a/bin/install.sh +++ b/bin/install.sh @@ -11,7 +11,7 @@ # slated to leave PyAutoLabs/; kept only so an old # checkout still resolves, auto-skipped once gone # - PyAutoMind/skills/ — registry-coupled skills (create_issue, handoff) -# - PyAutoBrain/skills/ — development-workflow skills (start_*/ship_*/plan_branches/…) +# - PyAutoBrain/skills/ — development-workflow skills (start_*/ship_*/…) # - PyAutoHeart/skills/ — status / readiness / diagnostic skills # - PyAutoBuild/skills/ — release-execution skills ONLY (pre_build) # - autolens_profiling/skills/ — science-profiling skills (profile_likelihood) diff --git a/skills/WORKFLOW.md b/skills/WORKFLOW.md index 1762424..3073829 100644 --- a/skills/WORKFLOW.md +++ b/skills/WORKFLOW.md @@ -1,6 +1,6 @@ # PyAuto workflow skills — shared reference -The `start_*` / `ship_*` / `plan_branches` / `register_and_iterate` skills are the +The `start_*` / `ship_*` / `register_and_iterate` skills are the **development-workflow entry points** of the PyAuto organism. They are *not* independent reasoning systems: each one is a thin entry point that delegates to the organs. This file is the shared context every workflow skill points at, so @@ -133,6 +133,19 @@ pyauto-heart readiness --json # authoritative GREEN / YELLOW / RED verdict Tests/smoke runs that feed the verdict are Heart's domain — invoke them through the vitals faculty rather than re-deriving pass/fail criteria in the skill. +## Cross-harness notes (apply to every workflow skill) + +- `/name` references mean "use that skill"; a harness without slash commands + follows the same body file directly. +- "Plan Mode" means: present the plan and wait for explicit user approval + before any file edit. +- If the user gives a development task with **no** PyAutoMind prompt path, + first write a concise prompt under the right `//` folder + (original request verbatim), then continue with that path. +- Where a body delegates mechanical execution to a Sonnet subagent, a harness + without subagents performs the same steps directly, preserving the + judgment/mechanical split above. + ## Execution environments There is **no special "mobile" or "phone" mode** — PyAutoBrain runs the same diff --git a/skills/plan_branches/SKILL.md b/skills/plan_branches/SKILL.md deleted file mode 100755 index b5d2c44..0000000 --- a/skills/plan_branches/SKILL.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -name: plan-branches -description: After a plan is approved, survey all affected repositories for current branch state and suggest a unified working branch name to avoid overlap with other work or agents. ---- - -After a plan has been created and approved, run this skill to survey all repositories that the plan will touch, report their current branch state, and propose a single working branch name for the entire task. - -A PyAutoBrain planning entry point — branch/worktree setup is the dev workflow's -own feature-dev git mechanics (not Build, which is release-only); task state is -PyAutoMind. Shared organ boundary and the execution-environment model are in -[`../WORKFLOW.md`](../WORKFLOW.md). - -## Steps - -1. **Identify affected repositories** - - Review the approved plan and list every repository that will be modified. Only include repos that the plan actually touches — do not list all repos from `settings.json` if they are not relevant. - -2. **Report current branch state for each affected repo** - - For each affected repository, run: - ```bash - git -C branch --show-current - git -C status --short - ``` - - Display a table like: - - ``` - Repository | Current Branch | Dirty? - ------------------------|----------------|------- - ./PyAutoFit | main | clean - ./PyAutoArray | feature/xyz | 2 modified - ``` - - If a repo is on a non-main/non-master branch or has uncommitted changes, flag it with a warning — this may indicate another task or agent is active there. - -3. **Check for active Claude agents, recent branches, and worktree claims** - - Source the worktree helper and list anything already claimed by another task: - - ```bash - source admin_jammy/software/worktree.sh - worktree_list_claimed - ``` - - This prints one line per `(task, repo, branch, worktree_path)` quadruple currently registered in `active.md`. For each affected repo the new plan wants to touch, check whether a different task already claims it via a `worktree:` field. If so, flag it as a **hard conflict** — the new task cannot start until the other one ships. - - Then, for each affected repo, also run: - ```bash - git -C branch --sort=-committerdate | head -5 - ``` - - Show the 5 most recent branches per repo so the user can spot ongoing work that pre-dates the worktree flow. A feature branch on the main checkout that is **not** referenced by any `worktree:` claim is unregistered work, not a conflict — surface it as a warning, not a block. - -4. **Suggest a unified branch name** - - Propose a single branch name to be used across all affected repos. Use the format: - ``` - feature/ - ``` - - The name should be: - - Descriptive of the task from the plan - - Lowercase, kebab-case - - Short (under 50 chars) - -5. **Present summary for approval** - - Display the full summary: - - List of affected repos - - Current branch and dirty state for each - - Recent branches for each - - Any warnings about potential overlap - - The suggested branch name - - Then ask the user: - - "Does this branch name work, or would you like a different one?" - - "Are any of the flagged repos a concern? Should we wait or coordinate?" - - **Do not proceed with any work until the user confirms the branch name and acknowledges any overlap warnings.** - -6. **On resume: verify branches and worktree match the plan** - - When resuming work on an existing plan (e.g. a new conversation continuing previous work, or returning after a break), run this verification step **before making any edits**: - - a. Read the plan or `active.md` entry to find the agreed branch name, the worktree root path (`worktree:` field), and the list of affected repositories. - - b. **Verify the worktree root exists on disk:** - ```bash - test -d "$WT_ROOT" && echo "present" || echo "MISSING" - test -f "$WT_ROOT/activate.sh" && echo "activate.sh ok" || echo "activate.sh MISSING" - ``` - - If the worktree root has been deleted but `active.md` still lists it, stop and ask the user whether to: - - Re-create the worktree via `worktree_create ` (resumes the task), or - - Abandon the task and remove its entry from `active.md`. - - c. For each affected repo listed in the task, run `git -C "$WT_ROOT/" branch --show-current` and compare against the expected branch. Display the comparison table: - - ``` - Repository | Expected Branch | Actual Branch | Status - ------------------------|-----------------------|-----------------------|-------- - $WT_ROOT/PyAutoFit | feature/my-task | feature/my-task | OK - $WT_ROOT/PyAutoArray | feature/my-task | main | MISMATCH - ``` - - d. If **all repos match**: confirm and continue work. Remind the user to `source "$WT_ROOT/activate.sh"` if they're in a fresh shell. - - e. If **any repo is on an unexpected branch**: - - Flag each mismatch with a warning - - Ask the user whether to: - - Switch the mismatched worktree to the expected branch (`git -C "$WT_ROOT/" checkout `) - - Continue on the current branch (with acknowledgement) - - Abort and investigate - - **Do not proceed with any edits until the user responds.** - -## Execution environments - -The steps above assume a local-dev checkout with task worktrees. In other -execution environments (see [`../WORKFLOW.md`](../WORKFLOW.md)): - -- **web-github / analysis-only** (no local tree): skip the worktree checks - (`worktree_list_claimed`, `worktree_check_conflict`) and read branch state via - the GitHub API instead of local `git -C`: - ```bash - gh api repos///branches --jq '.[].name' | head -10 - gh api repos///branches/ --jq '.name' 2>/dev/null - ``` - Use the repo → owner mapping in WORKFLOW.md. Suggest the branch name and present - the summary as normal; on resume, verify branches via the API. - -This is the same reasoning in every environment — only the source of branch state -differs (local git vs GitHub API). It is not a separate "mobile mode". diff --git a/skills/repo_cleanup/SKILL.md b/skills/repo_cleanup/SKILL.md index 94e4cf3..3be2c3c 100644 --- a/skills/repo_cleanup/SKILL.md +++ b/skills/repo_cleanup/SKILL.md @@ -30,8 +30,8 @@ execution-environment model: [`../WORKFLOW.md`](../WORKFLOW.md). **Distinct from:** `worktree_status` (Heart read-only diagnostic — consulted here, but this also mutates); post-merge cleanup in `CLAUDE.md` (once per shipped task — -this covers residue when that flow is skipped); `plan_branches` (task start — this -is between-tasks hygiene). +this covers residue when that flow is skipped); the start_dev branch survey +(task start — this is between-tasks hygiene). ## Safety principles (non-negotiable) diff --git a/skills/ship_library/SKILL.md b/skills/ship_library/SKILL.md index 086ae97..b538f22 100644 --- a/skills/ship_library/SKILL.md +++ b/skills/ship_library/SKILL.md @@ -5,25 +5,11 @@ description: Ship PyAutoLabs source-library changes — run tests, commit, push, # Ship Library -A PyAutoBrain development-workflow entry point. Shipping a library feature is -**feature-dev** work: dev-workflow → vitals faculty → Heart readiness gate → -commit/push/feature-PR, with PyAutoMind holding task state. It is **not** a Build -task — Build is release/packaging only (PyPI/tags/notebooks) and `ship_*` reaches -it solely for the release step. Shared organ boundary, the readiness gate and the -execution-environment model are in [`../WORKFLOW.md`](../WORKFLOW.md). - -Use `ship_library.md` in this directory as the authoritative workflow body -(`reference.md` holds the PR format, execution contract and impact analysis). - -Follow the command file exactly, adapting Claude-specific references to Codex: - -- `/ship_library` means use this skill. -- If the command file delegates mechanical execution to a Claude subagent, Codex - should either use an available subagent tool with the same contract or perform - the same mechanical steps directly while preserving the judgment/mechanical - split in the user-facing workflow. -- Preserve the `## API Changes` PR-body contract because `/start_workspace`, - release review, and downstream workspace migration depend on it. - -Do not duplicate or reinterpret the workflow here. If the workflow changes, edit -`ship_library.md`. +Follow [`ship_library.md`](ship_library.md) in this directory exactly — the +authoritative workflow body (`reference.md` holds the PR format, execution +contract and impact analysis). Shared context and cross-harness notes: +[`../WORKFLOW.md`](../WORKFLOW.md). Shipping a library feature is +**feature-dev** work gated by Heart — not a Build task. Preserve the +`## API Changes` PR-body contract — `/start_workspace`, release review, and +downstream workspace migration depend on it. Do not duplicate or reinterpret +the workflow here — if it changes, edit `ship_library.md`. diff --git a/skills/ship_workspace/SKILL.md b/skills/ship_workspace/SKILL.md index 9c27dd4..926a3fe 100644 --- a/skills/ship_workspace/SKILL.md +++ b/skills/ship_workspace/SKILL.md @@ -5,26 +5,11 @@ description: Ship PyAutoLabs workspace and tutorial changes — validate scripts # Ship Workspace -A PyAutoBrain development-workflow entry point. Shipping a workspace feature is -**feature-dev** work: dev-workflow → vitals faculty → Heart readiness gate → -commit/push/feature-PR/merge, with PyAutoMind holding task state. It is **not** a -Build task — Build is release/packaging only. Shared organ boundary, the -readiness gate and the execution-environment model are in -[`../WORKFLOW.md`](../WORKFLOW.md). - -Use `ship_workspace.md` in this directory as the authoritative workflow body -(`reference.md` holds the PR format, merge gate and issue/Mind formats). - -Follow the command file exactly, adapting Claude-specific references to Codex: - -- `/ship_workspace` means use this skill. -- Slash-command references such as `/smoke_test` refer to the matching Codex - skill or shared command body. -- If the command file delegates mechanical execution to a Claude subagent, Codex - should either use an available subagent tool with the same contract or perform - the same mechanical steps directly. -- Preserve the `## Scripts Changed` PR-body contract and the library-first merge - gate for linked workspace PRs. - -Do not duplicate or reinterpret the workflow here. If the workflow changes, edit -`ship_workspace.md`. +Follow [`ship_workspace.md`](ship_workspace.md) in this directory exactly — the +authoritative workflow body (`reference.md` holds the PR format, merge gate and +issue/Mind formats). Shared context and cross-harness notes: +[`../WORKFLOW.md`](../WORKFLOW.md). Shipping a workspace feature is +**feature-dev** work gated by Heart — not a Build task. Preserve the +`## Scripts Changed` PR-body contract and the **library-first merge gate** for +linked workspace PRs. Do not duplicate or reinterpret the workflow here — if it +changes, edit `ship_workspace.md`. diff --git a/skills/start_dev/SKILL.md b/skills/start_dev/SKILL.md index 245ce19..3bd6cd0 100644 --- a/skills/start_dev/SKILL.md +++ b/skills/start_dev/SKILL.md @@ -5,25 +5,8 @@ description: Default entry point for PyAutoLabs development tasks — implement, # Start Dev -A PyAutoBrain development-workflow entry point. It routes reasoning through the -Brain Feature Agent, consults PyAutoMemory, records state in PyAutoMind, and -hands off to `/start_library` / `/start_workspace`. Shared organ boundary, -agent entry points and the execution-environment model are in -[`../WORKFLOW.md`](../WORKFLOW.md). - -Use `start_dev.md` in this directory as the authoritative workflow body -(`reference.md` holds the long-form templates). - -Follow the command file exactly, adapting Claude-specific references to Codex: - -- `/start_dev ` means use this skill with the same prompt path. -- If the user gives a development task without a prompt path, first create a - concise prompt file in the appropriate `PyAutoMind/` category and include - the original request verbatim, then use this skill with that prompt path. -- "Plan Mode" means present the plan and wait for explicit user approval before - file edits when this workflow is being used. -- Slash-command references such as `/plan_branches`, `/start_library`, and - `/start_workspace` refer to the matching Codex skill or shared command body. - -Do not duplicate or reinterpret the workflow here. If the workflow changes, edit -`start_dev.md`. +Follow [`start_dev.md`](start_dev.md) in this directory exactly — the +authoritative workflow body. `reference.md` holds the long-form templates and +the branch survey; shared context and cross-harness notes are in +[`../WORKFLOW.md`](../WORKFLOW.md). Do not duplicate or reinterpret the +workflow here — if it changes, edit `start_dev.md`. diff --git a/skills/start_dev/reference.md b/skills/start_dev/reference.md index d7ae860..6afee6d 100644 --- a/skills/start_dev/reference.md +++ b/skills/start_dev/reference.md @@ -91,3 +91,135 @@ issue** — instead: prompt_sync_push "prompt: archive completed z_features tracker — " ``` Print a one-line "archived" confirmation and stop. + +## Branch survey (the former /plan_branches) + +Run after the plan is approved (start_dev step 4): survey every repository the plan will touch, report branch state, and propose a single working branch name for the task. + +A PyAutoBrain planning entry point — branch/worktree setup is the dev workflow's +own feature-dev git mechanics (not Build, which is release-only); task state is +PyAutoMind. Shared organ boundary and the execution-environment model are in +[`../WORKFLOW.md`](../WORKFLOW.md). + +## Steps + +1. **Identify affected repositories** + + Review the approved plan and list every repository that will be modified. Only include repos that the plan actually touches — do not list all repos from `settings.json` if they are not relevant. + +2. **Report current branch state for each affected repo** + + For each affected repository, run: + ```bash + git -C branch --show-current + git -C status --short + ``` + + Display a table like: + + ``` + Repository | Current Branch | Dirty? + ------------------------|----------------|------- + ./PyAutoFit | main | clean + ./PyAutoArray | feature/xyz | 2 modified + ``` + + If a repo is on a non-main/non-master branch or has uncommitted changes, flag it with a warning — this may indicate another task or agent is active there. + +3. **Check for active Claude agents, recent branches, and worktree claims** + + Source the worktree helper and list anything already claimed by another task: + + ```bash + source admin_jammy/software/worktree.sh + worktree_list_claimed + ``` + + This prints one line per `(task, repo, branch, worktree_path)` quadruple currently registered in `active.md`. For each affected repo the new plan wants to touch, check whether a different task already claims it via a `worktree:` field. If so, flag it as a **hard conflict** — the new task cannot start until the other one ships. + + Then, for each affected repo, also run: + ```bash + git -C branch --sort=-committerdate | head -5 + ``` + + Show the 5 most recent branches per repo so the user can spot ongoing work that pre-dates the worktree flow. A feature branch on the main checkout that is **not** referenced by any `worktree:` claim is unregistered work, not a conflict — surface it as a warning, not a block. + +4. **Suggest a unified branch name** + + Propose a single branch name to be used across all affected repos. Use the format: + ``` + feature/ + ``` + + The name should be: + - Descriptive of the task from the plan + - Lowercase, kebab-case + - Short (under 50 chars) + +5. **Present summary for approval** + + Display the full summary: + - List of affected repos + - Current branch and dirty state for each + - Recent branches for each + - Any warnings about potential overlap + - The suggested branch name + + Then ask the user: + - "Does this branch name work, or would you like a different one?" + - "Are any of the flagged repos a concern? Should we wait or coordinate?" + + **Do not proceed with any work until the user confirms the branch name and acknowledges any overlap warnings.** + +6. **On resume: verify branches and worktree match the plan** + + When resuming work on an existing plan (e.g. a new conversation continuing previous work, or returning after a break), run this verification step **before making any edits**: + + a. Read the plan or `active.md` entry to find the agreed branch name, the worktree root path (`worktree:` field), and the list of affected repositories. + + b. **Verify the worktree root exists on disk:** + ```bash + test -d "$WT_ROOT" && echo "present" || echo "MISSING" + test -f "$WT_ROOT/activate.sh" && echo "activate.sh ok" || echo "activate.sh MISSING" + ``` + + If the worktree root has been deleted but `active.md` still lists it, stop and ask the user whether to: + - Re-create the worktree via `worktree_create ` (resumes the task), or + - Abandon the task and remove its entry from `active.md`. + + c. For each affected repo listed in the task, run `git -C "$WT_ROOT/" branch --show-current` and compare against the expected branch. Display the comparison table: + + ``` + Repository | Expected Branch | Actual Branch | Status + ------------------------|-----------------------|-----------------------|-------- + $WT_ROOT/PyAutoFit | feature/my-task | feature/my-task | OK + $WT_ROOT/PyAutoArray | feature/my-task | main | MISMATCH + ``` + + d. If **all repos match**: confirm and continue work. Remind the user to `source "$WT_ROOT/activate.sh"` if they're in a fresh shell. + + e. If **any repo is on an unexpected branch**: + - Flag each mismatch with a warning + - Ask the user whether to: + - Switch the mismatched worktree to the expected branch (`git -C "$WT_ROOT/" checkout `) + - Continue on the current branch (with acknowledgement) + - Abort and investigate + - **Do not proceed with any edits until the user responds.** + +## Execution environments + +The steps above assume a local-dev checkout with task worktrees. In other +execution environments (see [`../WORKFLOW.md`](../WORKFLOW.md)): + +- **web-github / analysis-only** (no local tree): skip the worktree checks + (`worktree_list_claimed`, `worktree_check_conflict`) and read branch state via + the GitHub API instead of local `git -C`: + ```bash + gh api repos///branches --jq '.[].name' | head -10 + gh api repos///branches/ --jq '.name' 2>/dev/null + ``` + Use the repo → owner mapping in WORKFLOW.md. Suggest the branch name and present + the summary as normal; on resume, verify branches via the API. + +This is the same reasoning in every environment — only the source of branch state +differs (local git vs GitHub API). It is not a separate "mobile mode". diff --git a/skills/start_dev/start_dev.md b/skills/start_dev/start_dev.md index ba77f0b..9d2d055 100644 --- a/skills/start_dev/start_dev.md +++ b/skills/start_dev/start_dev.md @@ -85,10 +85,11 @@ fresh session could start from the issue alone. ### 4. Survey branches -Run `/plan_branches` reasoning for the affected repos: report each repo's branch -+ dirty state, suggest `feature/` (kebab-case, <50 chars), and derive -the worktree root `~/Code/PyAutoLabs-wt//` (created later by -`/start_library`). See `plan_branches`. +Run the **branch survey** ([`reference.md`](reference.md) → "Branch survey") +for the affected repos: report each repo's branch + dirty state, check worktree +claims, suggest `feature/` (kebab-case, <50 chars), and derive the +worktree root `~/Code/PyAutoLabs-wt//` (created later by +`/start_library`). ### 5. Create the issue via the Mind primitive diff --git a/skills/start_dev_for_user/start_dev_for_user.md b/skills/start_dev_for_user/start_dev_for_user.md index 406be6e..497c8f9 100644 --- a/skills/start_dev_for_user/start_dev_for_user.md +++ b/skills/start_dev_for_user/start_dev_for_user.md @@ -67,8 +67,9 @@ comment → `needs-info` label → partial `active.md` entry → **stop**) per ### 4. Plan + branch survey Produce the two-level plan (high-level + detailed) as in `/start_dev` step 3, and -run `/plan_branches` reasoning — suggest `feature/` and derive the -worktree root. We do **not** create or rename an issue. +run the branch survey (`start_dev/reference.md` → "Branch survey") — suggest +`feature/` and derive the worktree root. We do **not** create or +rename an issue. ### 5. Plan comment (milestone #2) diff --git a/skills/start_library/SKILL.md b/skills/start_library/SKILL.md index fa175a9..de2a802 100644 --- a/skills/start_library/SKILL.md +++ b/skills/start_library/SKILL.md @@ -5,19 +5,8 @@ description: Set up PyAutoLabs source-library development after start_dev — cr # Start Library -A PyAutoBrain development-workflow entry point: sets up the worktree/branch for -library source work and registers state in PyAutoMind. Shared organ boundary and -the execution-environment model are in [`../WORKFLOW.md`](../WORKFLOW.md). - -Use `start_library.md` in this directory as the authoritative workflow body. - -Follow the command file exactly, adapting Claude-specific references to Codex: - -- `/start_library` means use this skill. -- Slash-command references such as `/ship_library` refer to the matching Codex - skill or shared command body. -- When the command file says to display a summary, report the same operational - details to the user before editing inside the task worktree. - -Do not duplicate or reinterpret the workflow here. If the workflow changes, edit -`start_library.md`. +Follow [`start_library.md`](start_library.md) in this directory exactly — the +authoritative workflow body. Shared context and cross-harness notes are in +[`../WORKFLOW.md`](../WORKFLOW.md). Report the worktree/branch summary to the +user before editing inside the task worktree. Do not duplicate or reinterpret +the workflow here — if it changes, edit `start_library.md`. diff --git a/skills/start_workspace/SKILL.md b/skills/start_workspace/SKILL.md index 823b1e3..510e7a6 100644 --- a/skills/start_workspace/SKILL.md +++ b/skills/start_workspace/SKILL.md @@ -5,20 +5,9 @@ description: Set up PyAutoLabs workspace or tutorial development — attach or c # Start Workspace -A PyAutoBrain development-workflow entry point: sets up the worktree/branch for -workspace/tutorial work and registers state in PyAutoMind. Shared organ boundary -and the execution-environment model are in [`../WORKFLOW.md`](../WORKFLOW.md). - -Use `start_workspace.md` in this directory as the authoritative workflow body -(`reference.md` holds the long-form formats). - -Follow the command file exactly, adapting Claude-specific references to Codex: - -- `/start_workspace` means use this skill. -- Slash-command references such as `/ship_workspace` and `/smoke_test` refer to - the matching Codex skill or shared command body. -- Maintain the library-first rule: linked workspace work follows the upstream - library PR and must use that PR's API-change summary. - -Do not duplicate or reinterpret the workflow here. If the workflow changes, edit -`start_workspace.md`. +Follow [`start_workspace.md`](start_workspace.md) in this directory exactly — +the authoritative workflow body (`reference.md` holds the long-form formats). +Shared context and cross-harness notes: [`../WORKFLOW.md`](../WORKFLOW.md). +Maintain the **library-first rule**: linked workspace work follows the upstream +library PR and must use that PR's API-change summary. Do not duplicate or +reinterpret the workflow here — if it changes, edit `start_workspace.md`.