القائمة
Start work on an issue with branch setup and implementation design. Use this whenever the user wants to begin a new task, start on a ticket, or set up a feature branch for development work.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Training plan scheduling, weekly retrospectives, and training adjacent constraint validation. Use this skill whenever the user mentions training, lifts, runs, climbs, the Friday long run, sauna timing, cold plunge timing, recovery days, cutback weeks, altitude weeks, race week, training restructure, Fitbod, asking to schedule a training session, or asking to look back / retrospect on a past training week. Also trigger for "/assist:plan-training", "schedule my long run", "what does training look like this week", "how did last week go", "training retro", or any request that touches the training plan in `Constitution/Fitness/`. Independently usable, and also called by `/assist:plan-week` during Monday planning.
Weekly planning, calendar management, and Monday morning task slotting. Use this skill whenever the user mentions weekly planning, the Monday planning session, slotting tasks, finding free time, checking what their week looks like, moving or swapping calendar events, or wants help fitting something into their week. Also trigger when the user asks about V2MOM measure coverage. Training plan scheduling lives in `assist:plan-training` and meal planning in `assist:plan-meals`; this skill calls into both during Monday planning.
Audit and redesign the context architecture (every CLAUDE.md, learned-rules.md, and tool doc that loads into Claude Code sessions) so load-bearing rules are surfaced and enforced at the point of use rather than scattered, duplicated, or buried. Use this skill whenever Forni says "groom context", "groom-context", "we forgot a basic again", "the context is sprawling", "the rules keep getting lost", "clean up the context", or invokes "/assist:groom-context". Also invoked as a closing step by the monthly path of assist:reflect. This is the cleanup counterpart to assist:codify-context, which writes knowledge into the same architecture.
Craft Business Development emails for RYLLC fractional CTO consultancy. Handles warm reconnects, job posting outreach, rejection follow-ups, VC intros, and custom BD scenarios. Uses established templates and project voice.
Codify knowledge from the current session into the appropriate location in the context architecture using progressive disclosure. Use this skill whenever the user says "codify" followed by a topic, wants to capture something they just figured out, asks to document a pattern or convention, or says something like "we should write this down" or "future me needs to know this." Also trigger when the user discovers a gotcha, foot-gun, or non-obvious behavior worth preserving. Works for both project directories (three-layer CLAUDE.md/README.md pattern) and skill directories (Learned Rules in SKILL.md). Named after the "plan, delegate, assess, codify" Level 4 compounding loop. This is the write-in counterpart to `assist:groom-context`, which audits and prunes the same context architecture.
Triage Gmail inbox by labeling, starring, and archiving emails. Also creates filters for recurring senders. Use this skill whenever the user mentions email triage, inbox cleanup, email labels, email filters, or wants to process their inbox. Default mode is triage.
| name | sdlc:design |
| description | Start work on an issue with branch setup and implementation design. Use this whenever the user wants to begin a new task, start on a ticket, or set up a feature branch for development work. |
| argument-hint | <issue-id> |
| allowed-tools | ["Bash(git *)","Bash(linear *)","Bash(*get-base-branch.sh*)","Bash(*get-branch-strat.sh*)","Bash(*get-linear-issue-id.sh*)","Bash(*sanitize-branch-name.sh*)","Bash(grep *)","Bash(echo *)","Read","TodoWrite","EnterWorktree","EnterPlanMode","ExitPlanMode","AskUserQuestion"] |
Starting work on issue $ARGUMENTS. Setting up git branch and fetching issue details.
In all bash steps below, substitute placeholder names (like BASE_BRANCH, BRANCH_NAME, etc.) with the actual values you stored earlier. Each placeholder appears in ALL_CAPS.
Try to extract a Linear issue ID from the argument:
../../scripts/get-linear-issue-id.sh "$ARGUMENTS"
If the script succeeds, store the output as ISSUE_ID and fetch the full issue:
linear issue view ISSUE_ID
Parse and display:
If the Linear CLI is not installed or the fetch fails, continue without issue details. The user can provide context manually.
git status --porcelain
If output is non-empty, use AskUserQuestion to prompt:
If clean, proceed.
Follow Branch Verification to get BASE_BRANCH and CURRENT_BRANCH.
Sanitize the argument into a valid branch name:
../../scripts/sanitize-branch-name.sh "$ARGUMENTS"
Store the output as BRANCH_NAME. Check if it already exists:
git rev-parse --verify "BRANCH_NAME"
If the branch exists, use AskUserQuestion:
Determine the branching strategy:
../../scripts/get-branch-strat.sh
Store the output as BRANCH_STRAT. Fetch the latest from remote:
git fetch origin "BASE_BRANCH"
Use Claude Code's native worktree tool. Track whether BRANCH_NAME is a brand new branch (default) or a pre existing branch the user chose to reuse via "Use existing branch" earlier in this step. Store this as BRANCH_IS_NEW (true or false). The branches diverge below.
Call EnterWorktree with name set to BRANCH_NAME. Claude creates .claude/worktrees/BRANCH_NAME, opens a fresh branch named worktree-BRANCH_NAME from current HEAD, and switches the session into the worktree.
trueDrop the worktree- prefix so the branch matches the issue identifier:
git branch -m "worktree-BRANCH_NAME" "BRANCH_NAME"
Anchor the new branch to the latest base ref. This matches the prior git worktree add ... origin/BASE_BRANCH semantics regardless of where the main worktree's HEAD was:
git reset --hard origin/"BASE_BRANCH"
false (reusing an existing branch)Do NOT rename and do NOT hard reset. The rename target already exists on disk, so git branch -m would fail; the hard reset would obliterate the user's prior commits on BRANCH_NAME. Instead, switch the worktree to the existing branch and discard the throwaway one Claude just created:
git switch "BRANCH_NAME"
git branch -d "worktree-BRANCH_NAME"
The existing branch's commits and tracking information are preserved.
Report to the user: "Worktree created at .claude/worktrees/BRANCH_NAME"
git checkout -b "BRANCH_NAME" origin/"BASE_BRANCH"
🛑 STOP — CALL
EnterPlanModeBEFORE ANYTHING ELSE IN THIS STEP. 🛑This is not a suggestion. This is not a vibe. This is a hard requirement.
The very first tool call in Step 4 MUST be
EnterPlanMode. Not after a quick exploration. Not after a small Read. Not "I'll enter plan mode once I'm ready to draft." FIRST. ALWAYS. NO EXCEPTIONS.Plan mode is the safety rail that prevents accidental writes while requirements are still being discussed. Skipping it has caused real incidents where code was written before the user signed off. Saying "you are now in plan mode" in prose does not put you in plan mode — only the
EnterPlanModetool call does.If you find yourself reading a file, drafting a plan, or calling any tool other than
EnterPlanModeas your first action in Step 4: STOP, back up, and callEnterPlanModefirst.
Once plan mode is active, your task is to:
Do not start implementing until the user approves. The plan exists so the user can course-correct before any code is written. When the plan is ready, use ExitPlanMode to request approval.
After approval, if a valid ISSUE_ID was found in Step 1, check if the Linear CLI is available:
command -v linear
If the command fails, skip the Linear updates and continue. Otherwise:
Write a design summary capturing the planning iterations, key decisions, and the chosen approach. Structure it as:
Post the summary as a comment on the ticket:
linear issue comment add ISSUE_ID "DESIGN_SUMMARY"
Then update the issue status:
linear issue update ISSUE_ID -s "In Progress"