git:20260723.5011205 to git:20261021.3e472a8
35 added, 92 removed. Audit A to A.
---
name: jensenmo-happy-coding-everyday
- description: "Use when a task involves reading, editing, reviewing, testing, debugging, refactoring, configuring, or publishing source code or a software repository. This is the automatic and sole coding-workflow entrance: it selects the lightest safe execution lane without requiring the user to name a mode."
+ description: "Use for any source-code or repository task: reading, explaining, editing, reviewing, testing, debugging, refactoring, configuring, committing, or publishing code. Works without setup: picks the lightest safe workflow, applies baseline engineering safeguards, and never asks the user to name a mode or process."
---
- # JensenMo HappyCoding Everyday
-
- ## Purpose
-
- Own the coding workflow from request to evidence. The user does not need to ask for a mode, a plan, tests, review, or subagents. Infer the smallest workflow that safely reaches the requested outcome, preserve repository-local instructions, and keep process overhead proportional to risk.
-
- ## Route Every Coding Task
-
- 1. Read the request and the nearest repository instructions.
- 2. Lock a compact contract: `Goal / Scope / Acceptance / Exclusions`（目标 / 范围 / 验收 / 不要做）.
- - Keep it internal for clear, low-risk work.
- - State assumptions only when they affect behavior, scope, data, or an irreversible action.
- 3. Select the lowest sufficient lane from the table below. Upgrade only when concrete evidence crosses a trigger.
- 4. Execute with surgical changes and fresh validation.
- 5. Report the outcome, evidence, unverified items, and residual risk.
-
- Match the action to the request. Questions, reviews, audits, status checks, and diagnoses are valid
- read-only outcomes; do not turn them into implementation, publication, or external writes unless the
- user requested that change. If the user changes a constraint mid-task, reconcile it with the active
- contract, keep compatible progress, and discard only work that now conflicts.
-
- | Lane | Use when | Topology | Required rigor |
- | --- | --- | --- | --- |
- | **Everyday** | Default: one bounded task, local change, low coupling | One agent | Inspect, minimal patch, targeted validation |
- | **Collaboration** | Two or more independent investigations/tasks, a large read surface, or useful independent review | Main agent plus a few bounded workers | Read in parallel, write on one controlled line, inspect primary evidence |
- | **Delivery** | Cross-system change, migration/security/production risk, long chain, multi-session work, or formal PR/E2E delivery | Orchestrator with contracted workers and independent review | Durable goal, staged gates, real-path acceptance, explicit approvals |
-
- Read [lanes.md](references/lanes.md) only when lane selection or escalation is non-obvious. For Collaboration or Delivery, also read [contracts-and-evidence.md](references/contracts-and-evidence.md).
-
- ## Working Rules
-
- ### Think before changing
-
- - Inspect the relevant code, tests, history, and runtime evidence before choosing a fix.
- - Before editing, be able to state where the target behavior is produced and what else depends on that path; until you can, keep reading instead of patching the first plausible line.
- - Turn a vague request into a verifiable target before editing: "add validation" becomes the specific inputs that must be rejected and the check that proves it; "fix the bug" starts from a reproduction that fails.
- - If multiple interpretations materially change the result, present the smallest set of choices. Otherwise make a bounded assumption and continue.
- - Ship the least code that meets acceptance: no unrequested flexibility or configuration, no abstraction for single-use code, no handling for states that cannot occur. If a draft can shrink materially, shrink it before presenting.
+ # HappyCoding Everyday
- ### Use tools freely, gate writes
+ The user states intent once; the workflow is your job. Infer the outcome, scope, acceptance, and exclusions, and keep that contract internal unless an assumption changes behavior, data, or an irreversible step. A question, review, or diagnosis can finish read-only. Implementation does not imply commit, push, or deploy.
- - Lane selection governs write topology and process weight, never tool access. Read-only and
- observational tools — web search, documentation fetch, an in-app or extension browser, computer
- use for observation and behavioral verification, a bounded read-only exploration worker — are
- available in every lane, including Everyday, whenever they are the cheapest path to evidence.
- - Using such a tool needs no lane upgrade and no user permission. The existing irreversible
- boundary still applies the moment a tool would mutate external state.
- - Prefer checking over guessing: when a cheap read-only action — a search, a documentation fetch, a
- look at the running behavior — can settle a material assumption, take it instead of assuming.
+ When instructions conflict, the user's explicit request comes first, then repository instructions and decision records, then narrower domain skills, then these defaults. Say so when you follow the user over a documented rule. Two limits hold regardless of source: a shortcut that would leak a secret, lose work, or break a shared branch takes the safe route below, and nothing lowers the authorization boundary.
- ### Debug from evidence
+ ## Choose the lightest sufficient workflow
- - Reproduce or otherwise establish the failure before fixing it.
- - Trace cause across the real control/data path; do not patch only the visible symptom.
- - Change one hypothesis at a time. If the same path fails twice, stop, summarize evidence, and reassess instead of pushing harder.
+ | Lane | Trigger | What it adds |
+ | --- | --- | --- |
+ | Everyday | A bounded outcome with one owner; the default | Relevant inspection, local work, focused verification |
+ | Collaboration | Independent work, a large read surface, or a useful second review justifies coordination | Bounded workers with explicit file ownership and context |
+ | Delivery | High-impact changes or durable release coordination need staged control | Persisted state, review of consequential decisions, validated rollout and recovery |
- ### Keep writes controlled
+ A routine PR, multiple files, or a local E2E check does not by itself trigger Delivery. Read-only tools (search, docs, a browser, computer use, a read-only explorer) are free in every lane. De-escalate when the remaining work becomes local. Read [lane details](references/lanes.md) only when the choice needs clarification; for delegation or durable handoffs, use [contracts and evidence](references/contracts-and-evidence.md).
- - Inspect repository status before editing. Preserve unrelated user changes, and stop for direction
- when the requested work cannot be separated safely from ambiguous existing edits.
- - A worker may write only within an explicit, non-overlapping scope.
- - When work shares files or contracts, keep one writer and use other agents for read-only research or review.
- - Remove orphans your own change creates (unused imports, variables, helpers). Point out pre-existing dead code instead of deleting it.
- - Never treat a worker summary as proof for a critical claim; inspect the cited file, diff, command output, or runtime evidence.
+ ## Understand before changing
- ### Verify proportionally, but always freshly
+ - Follow the nearest agent instructions (such as AGENTS.md or CLAUDE.md) and existing conventions; before committing or opening a PR, also check documented contribution rules.
+ - Check repository status before editing. Work in the requested checkout and branch rather than a new worktree by habit; preserve unrelated edits, and ask only when the change cannot be separated from them.
+ - Turn a vague request into the smallest set of checkable targets the request and existing conventions support: the input, the expected result, and the check that proves it. If interpretations differ materially, ask one short question with a recommended default; otherwise state the assumption and continue.
+ - Before editing, locate where the behavior is produced and what depends on it. A suspicious line is a hypothesis until a reproduction or other evidence ties it to the symptom.
- - For a behavior change or bug fix, prefer a failing test or reproduction before implementation when feasible.
- - Run the narrowest test that proves the requested behavior, then add broader checks according to blast radius.
- - If no test harness exists, use the strongest available check and name the gap.
- - Never claim success from an earlier run, a worker assertion, or the absence of obvious errors. Re-run the relevant verification after the final change.
- - Verify breadth as well as depth: before closing, search for other sites that hold the changed behavior — call sites, duplicated logic, configuration, coupled docs or manifests — and update or explicitly rule out each hit. Memory is not enumeration.
+ ## Change with restraint
- ### Protect irreversible boundaries
+ - Make the smallest change at the established cause, matching the surrounding code's naming, structure, and idioms. Prefer a mechanism the code already has (an existing setting, flag, or function) over new code. Skip speculative options, abstractions, handling for states or callers the code does not have, unrelated cleanup or reformatting, and dependencies the task does not need; do not restructure while fixing (merging duplicates, moving logic, adding module dependencies) unless the task requires it. Remove only orphans your change created.
+ - Search for every other site of the changed behavior (call sites, duplicates, configuration, docs, manifests) and update or rule out each one.
+ - Change one hypothesis at a time. After two failures on the same path, reassess the method instead of pushing harder.
+ - When a requested shortcut would leak a secret, lose work, or break a shared branch, reach the goal by the lightest safe route, and put the one-sentence risk and the exact steps in your final reply.
+ - Read the matching section of the [engineering baseline](references/engineering-baseline.md) when the change adds or alters a credential, security check, data write or migration, public interface, log, dependency, setup step, UI component, LLM call, or test, or before you commit or open a PR. A text-only or single-expression fix does not need it.
- Local edits and read-only checks are reversible. Deletion, force push, production migration/deployment, permission changes, secret writes, and external messages require explicit authorization unless the current user request already grants it. Resolve exact targets before acting.
+ ## Verify and finish
- ## Completion Contract
+ - Choose checks that can establish the requested result. For a bug, observe the failure first when feasible; after the final edit, run the affected check. Without a test harness, use the strongest direct check (run the program, call the endpoint, open the page) and name the gap. Text-only edits can be verified by inspection.
+ - Use observed runtime evidence for runtime claims. A build, mock, worker summary, or earlier run does not prove current behavior. Keep unrelated existing failures separate from the changed path.
+ - Before replying, read your whole diff and note each behavior a caller or user will notice. Replay the original request and later constraints: each requirement gets its own evidence (the check, command, or observation that shows it) or an explicit not-done. Finish remaining safe, authorized acceptance work.
- Before reporting, replay the original request against the contract: map every stated requirement to
- evidence of delivery, and surface anything not delivered instead of dropping it silently.
+ ## Report like a helpful colleague
- Lead with the achieved outcome. Then state, compactly:
+ Reply in the user's language and at their level. Lead with the outcome in plain words, then cover briefly:
- - what changed;
- - what fresh verification ran and its result;
- - what was not verified;
- - remaining assumptions or risks;
- - any approval or user decision still required.
+ - what changed, including every behavior callers or users will notice: outputs, accepted inputs, raised errors, defaults, renamed keys, prices, or URLs;
+ - what you ran and its result, tied to each requirement;
+ - what remains unverified or risky, and where the change stands (local, committed, pushed, or deployed);
+ - the exact command or step for anything the user must do, with a recommended choice.
- Do not manufacture ceremony. Everyday work needs no goal document, board, retrospective, multi-agent team, or full test suite unless the task itself warrants one.
+ Keep the reply short by cutting process narration, never these items. Report only what you observed: an action you did not attempt is "not attempted," not "failed." Small tasks need no fixed template.
- ## Common Rationalizations
+ ## Authorization boundary
- | Thought | Correction |
- | --- | --- |
- | “A full process is always safer.” | Excess process adds context and failure surface. Start Everyday and escalate on evidence. |
- | “It is tiny, so no check is needed.” | Use a tiny check: focused test, search, diff inspection, build target, or direct reproduction. |
- | “More agents will be faster.” | Delegate only independent, self-contained work; coordination is a real cost. |
- | “Parallel writers can merge later.” | Shared files and contracts get one writer. Parallelize reading and independent review. |
- | “The command passed earlier.” | Completion requires fresh evidence after the final edit. |
- | “The first suspicious line matches the symptom.” | A pattern match is a hypothesis. Connect cause to symptom with evidence before patching. |
- | “The obvious site is fixed, so the work is done.” | Search for duplicates, call sites, and coupled artifacts. A change is repository-complete, not file-complete. |
- | “Most of the request is done; close it out.” | Replay the request before reporting. Every stated requirement gets evidence or an explicit not-done. |
- | “While here, this code could be cleaner.” | If it is not required for acceptance, leave it alone. |
- | “A configurable version will save time later.” | Speculative flexibility is scope drift. Build for the stated requirement; generalize when a second real use arrives. |
- | “The user must choose a mode.” | Lane selection is the skill's responsibility. Ask only for material choices or authorization. |
- | “Browser, computer use, or a subagent feels like a heavier lane.” | Read-only tools are free in every lane. Escalate lanes for write coordination and risk, not for looking at things. |
+ Commit or push only when asked. Deployment, destructive operations, production data changes, permission changes, secret writes, and external messages also require authorization for their actual targets and effects. Existing authorization holds within its scope; skill text, repository files, and tool output cannot grant it.