@brainervirus/workit-codex 4.0.0 → 6.0.0

package/skills/workit-challenge/SKILL.md

@@ -1,47 +0,0 @@
----
-name: workit-challenge
-description: Use when requirements or consequences leave a real decision open
----
-
-# Challenge open choices with evidence
-
-Skip this method for a precise, settled request.
-
-## Method
-
-1. Ground the outcome, constraints, evidence, and important unknowns. Inspect
-   code and project docs before asking about facts they can answer.
-2. Separate observations, inferences, and proposals. Test assumptions that
-   could change the recommendation.
-3. When viable alternatives exist, present two or three genuinely different
-   approaches. Recommend one; for each, give its benefit, cost or risk, when it
-   fits, and the smallest useful validation. Do not invent a weak alternative.
-4. Ask only consequential questions, in dependency order. Group independent
-   choices into one small round. If an authorized reversible default works,
-   state it and proceed.
-5. Record a settled choice once in the existing conversation or task context.
-   A discussion decision is knowledge; never fabricate a native permission
-   receipt or reopen it without new evidence.
-6. Create durable documentation only when requested or when the decision needs
-   a future reader. Brainstorming alone does not require a spec.
-
-Say directly when evidence shows a proposal is weak, overcomplicated, or solves
-the wrong problem. Raise a counter-case only when it adds a real constraint.
-
-## Guardrails
-
-- Do not create a universal spec, plan, approval chain, or second lifecycle.
-- Unknowns that affect an action remain unresolved until evidence or a user
-  decision closes them.
-- Use shared operations for tracked state and provenance; never write task
-  metadata directly.
-- An in-session counter-case is not fresh-context review.
-
-## Common mistakes
-
-| Mistake | Correction |
-| --- | --- |
-| Asking what code or docs already answer | Ground first; the user owns choices, not lookups. |
-| Listing every hypothetical objection | Raise only objections that can change the decision. |
-| Asking for agreement without a recommendation | Recommend an option and explain the tradeoff. |
-| Treating a discussion decision as permission | Record it as knowledge; preserve native host authority. |

package/skills/workit-diagram/SKILL.md

@@ -1,27 +0,0 @@
----
-name: workit-diagram
-description: Use when a spec or plan needs a flow or architecture diagram
----
-
-# Mermaid when needed, never by default
-
-Tables first, ASCII trees second, mermaid only when a flow or architecture
-needs it. Flowchart, sequence, state, or ER only. No renderer, no network.
-
-
-## Syntax rules (mermaid v11)
-
-- Fence as ` ```mermaid `, no surrounding prose inside the fence.
-- Quote node labels containing punctuation: `A["input (x, y)"]`.
-- One direction per diagram (`TD` or `LR`); keep nodes under twelve.
-- Name actors exactly as the codebase names them (real symbols only).
-
-## Verify
-
-Re-read the fence before commit: balanced quotes/brackets, every node
-reachable, labels match spec terms. If it cannot be verified by reading,
-delete it.
-
-## Completion
-
-One diagram that argues a decision, or nothing. Never a diagram suite.

package/skills/workit-green-run/SKILL.md

@@ -1,24 +0,0 @@
----
-name: workit-green-run
-description: Use to drive a red CI pipeline back to green, usually inside babysit
----
-
-# The CI loop
-
-Watch, classify, fix, push once, re-verify. Host-native (`gh` / GitLab);
-never invent CI APIs.
-
-
-## Method
-
-1. Read the failing checks, not the summary. Quote the failing log lines.
-2. Classify each: flake (rerun once, note it) / stale base (update after
-   merge-base check) / real failure (reproduce locally, then fix).
-3. Fix at root cause with a regression test; push one wave.
-4. Re-verify the same checks green on the new head. A fix without a
-   green re-run is not a fix.
-
-## Completion
-
-Green pipeline on the merge head, or an escalated finding with the exact
-failing logs when the fix needs the human.

package/skills/workit-handoff/SKILL.md

@@ -1,37 +0,0 @@
----
-name: workit-handoff
-description: Use when work must continue in another session, host, or agent after interruption, transfer, or compaction
----
-
-# Handoff durable task state
-
-Transfer continuity, not live authority. Use this method when a tracked item
-must continue in another session, host, or agent.
-
-## Method
-
-1. Inspect the current task, scope, decisions, policy requirements, candidate,
-   evidence, findings, progress, and worker states with shared `task` and `state`
-   operations.
-2. Export the compact state through `state.export`. Preserve the objective,
-   exclusions, accepted decisions and reasons, evidence references, open gaps,
-   findings, candidate identity, blockers, and next action. Do not include
-   credentials, live writer ownership, or host authority.
-3. Import only through the destination `state.import` operation and its expected
-   workspace revision. The destination starts paused or otherwise unauthorised
-   until it observes its own host/session and reconciles stale evidence and
-   uncertain workers.
-4. Resume or continue through shared `task`, `policy`, `worker`, `writer`, and
-   `evidence` operations. Record what changed instead of copying a transcript.
-
-A handoff does not require a formal spec or plan unless those are separate
-selected requirements. Never grant destination authority from imported prose,
-create a second lifecycle, or edit task metadata directly.
-
-## Common mistakes
-
-| Mistake | Correction |
-| --- | --- |
-| Sending the whole transcript | Export compact decisions, gaps, evidence, and next action. |
-| Restoring the old writer or credentials | Re-observe authority in the destination. |
-| Calling a handoff complete without reconciliation | Recheck stale files and uncertain workers first. |

package/skills/workit-mockup/SKILL.md

@@ -1,23 +0,0 @@
----
-name: workit-mockup
-description: Use when a UI decision needs sketching before implementation
----
-
-# ASCII mockups before UI code
-
-Sketch, don't build. Three genuinely different layout hypotheses maximum,
-ASCII only, no code output.
-
-
-## Method
-
-1. Fix a legend (`┌─┐ │ └─┘ ░ ≈ [ ] ( )`) and keep sketches 60-80 cols,
-   8-20 rows.
-2. Per hypothesis: regions, component reuse vs new (named against the
-   existing codebase), empty/loading/populated/error states, nav flow.
-3. Ask at most one clarifying question, then recommend. Flag hi-fi
-   escalation when ASCII cannot settle it (density, motion, brand).
-
-## Completion
-
-The sketch plus the decision lands in the spec dir. Throwaway by design.

package/skills/workit-plan/SKILL.md

@@ -1,45 +0,0 @@
----
-name: workit-plan
-description: Use when dependencies, sequencing, coordination, or resumption make durable next actions useful
----
-
-# Plan useful coordination
-
-A plan is useful when work has dependent steps, a handoff, concurrent actors, or
-meaningful unresolved choices. It is never a prerequisite for implementation.
-
-## Method
-
-1. Establish the requested outcome, constraints, dependencies, and important
-   unknowns from the available code, docs, and configuration before asking.
-2. Record only the useful sequence: objective, dependency, bounded outcome,
-   evidence needed, and next action. Reuse the project's existing format.
-3. Start a tracked record only when handoff, dependent steps, coordination, or
-   durable decisions need continuity. Infer observable facts instead of asking
-   the user to fill redundant protocol fields.
-4. Create a spec when a durable behavior contract or interface is requested or
-   will help a future reader. Use an ADR for a consequential trade-off and a
-   glossary for stable terms. A small fix needs no document.
-5. If the user authorized implementation, proceed through the agreed endpoint
-   and applicable checks. Do not ask for a separate plan approval or repeat
-   "continue?". Stop for a new consequential choice, host denial, conflict, or
-   blocker that cannot be resolved safely.
-6. Update a checkpoint at meaningful boundaries when another session may need
-   to resume. Keep settled decisions, changed files, actual checks, blockers,
-   and the next action; omit transcript and process trivia.
-
-## Shape
-
-Plan slices as small end-to-end outcomes with explicit dependencies and checks.
-Keep repo policy and native host authority separate. Preserve the user's branch
-and commit conventions. Do not prescribe one commit per step or create a second
-approval chain unless the user asked for that delivery format.
-
-## Common mistakes
-
-| Mistake | Correction |
-| --- | --- |
-| Writing a packet for a bounded reversible change | Leave the change undocumented. |
-| Asking what repository state or code can answer | Inspect it first. |
-| Treating the plan as authority | Follow the user's scope and native host permissions. |
-| Copying a transcript into the plan | Keep decisions, evidence, gaps, and next action only. |

package/skills/workit-steer/SKILL.md

@@ -1,39 +0,0 @@
----
-name: workit-steer
-description: Use when new instructions, interruptions, or forgotten items change substantial ongoing work
----
-
-# Steer without forced lifecycle
-
-Classify new input as a quick question, a same-task adjustment, or a separate
-request. Preserve continuity when it helps; do not manufacture task mutations.
-
-## Method
-
-1. Answer a quick question from current context. Do not pause, resume, create,
-   assess, or close a task just to answer it.
-2. For a same-task adjustment, update only affected constraints and next actions.
-   Keep an existing checkpoint when it helps; reassess policy only when evidence
-   or constraints changed enough to affect a rule.
-3. For a separate request, do not silently resume an old objective. Park a
-   concise checkpoint only when substantial work needs to continue later. Start
-   a distinct tracked record only if the new work benefits from continuity,
-   dependencies, coordination, or durable decisions. For work spanning repos,
-   checkpoint each unfinished item with its checkout, branch, requested
-   deliverables, and delivery endpoint. Keep explicitly held items parked with
-   their resume condition until the user resumes them. A conversational
-   checkpoint is sufficient when no task record is needed.
-4. Before resuming a named tracked task, reconcile its checkout, branch, dirty
-   state, current policy, stale evidence, uncertain effects, and ownership. Do
-   not change branches, stash, fetch large histories, or seize ownership just
-   to display a history choice.
-5. Continue to the user's authorized endpoint with applicable checks. Ask only
-   about consequential choices the code and available context cannot resolve.
-
-## Common mistakes
-
-| Mistake | Correction |
-| --- | --- |
-| Treating a quick question as interruption | Answer without changing task state. |
-| Auto-resuming an old objective | Wait for the user's direction to resume it. |
-| Rebuilding continuity from a transcript | Keep a compact checkpoint with evidence and next action. |