ワンクリックでManusで任意のスキルを実行

spec-sync

スター6

フォーク1

更新日2026年7月17日 01:39

Use in cross-session work when user-confirmed outcomes, non-goals, hard constraints, or acceptance criteria have not been written back to the current source of truth (spec), or reality conflicts with it enough that following it would be wrong; also use during wrap-up or handoff when a source of truth should exist but does not. Edit only the affected original wording; do not keep separate old and new versions. Do not trigger for work that can be completed within one session, local implementation details, verification against existing acceptance criteria, locating the source of truth, or ordinary documentation edits.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

chipfighter

chipfighter/coding-discipline

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

The decision test (the only test for whether to sync)

If the next session or another agent read only the current source of truth, would it continue toward an outcome the user has rejected, violate a new constraint, or judge completion against stale criteria? If so, the change must be synced.

Only changes the user has already confirmed belong in the spec; your own inferences and ideas still under discussion do not.
Before deciding, read the current source of truth at most once to compare. Do not turn this into research.

Write-back rules

Use the current source of truth already designated by the project—the document named by the project guide.
If none is designated, designate an existing Issue / PRD / ADR / status document as the current spec; do not copy it into a second document. If there are multiple candidates or none is obvious, ask the user to choose.
If nothing exists and the work genuinely spans sessions, is shared by multiple people, or would be costly to get wrong, ask whether the user wants a minimal spec (below). The user decides whether to create one; do not create one for work that can be completed within a single session.
After designating or creating one, put a pointer to the source of truth in the project guide document (the “where to find the current state” entry in CLAUDE.md / AGENTS.md)—write only the pointer, not a copy of the content—so the next session can find it.
Edit only the affected original wording: do not append separate “old decision / new decision” versions, reorder the document, or polish the whole document along the way. Replace the affected text as a whole only when the direction changes substantially; leave history to Git.
Do not record execution progress, next steps, or verification evidence. Those belong to the harness / Git / CI, not the spec.
In multi-person / multi-agent work, workers are read-only by default; the primary agent or owner maintains the spec.

Minimal spec (five items—add no more than needed)

The current desired outcome; explicit non-goals; hard constraints; acceptance criteria for this work; confirmed unresolved questions that would block safe execution (include only questions the user has confirmed—do not promote your guesses into settled facts).

Exceptions (do not force either case)

No write access to the source of truth (for example, a PRD owned by someone else): do not overstep. State clearly what is stale and who should update it.
The user explicitly refuses write-back: explain that the next session may read the old target, then comply. An old spec must never be used to block the user's latest instruction.

Hard rules

Do not write changes to outcomes / non-goals / hard constraints / acceptance criteria into the source of truth until the user has confirmed them.
If the implementation is verified but the source of truth is not synced, report those as two separate facts. Do not claim “the source of truth is synced” or “handoff will preserve everything.”
Complete the sync within this session. Do not expect a later session to recover intent that was never persisted.

Boundary

Which document is the current source of truth and how to read it belong to context-hygiene. Verifying completion against existing acceptance criteria belongs to verify-before-done. This skill governs one thing only: whether the source of truth reflects the user's latest confirmed decisions.

このリポジトリの他の Skills

同じリポジトリ

git-flow

chipfighter/coding-discipline

Use when creating a branch, using worktrees for parallel work, committing, or wrapping up. Covers branch naming, conventional commits, short-lived branches, worktree isolation, and final merge/cleanup.

2026-07-176

systematic-debugging

chipfighter/coding-discipline

Use before proposing a permanent fix for bugs, test failures, or unexpected behavior with an unknown root cause—mandatory when symptoms are far from the cause, a prior fix failed, or the issue crosses components. Reproduce, trace backward to the root cause, fix once at the source, and add a regression test. Do not trigger for obvious errors whose message identifies the cause (syntax/typo/missing import); fix those directly.

2026-07-176

brainstorming

chipfighter/coding-discipline

Use before coding when requirements have multiple reasonable interpretations, approaches require tradeoffs, or mistakes would be costly (permissions/payments/data migration/public APIs/data structures/hard-to-revert changes). Clarify requirements and design one question at a time, then get approval before implementation. Do not trigger for a focused small change with a clear goal and approach, or for mechanical edits (copy/constants/config values).

2026-07-176

tdd

chipfighter/coding-discipline

Use before implementation when behavior can be verified by automated tests and regression coverage has clear value. For bugs with an unknown root cause, use systematic-debugging first, then return for red-green. Follow red-green-refactor—write a failing test first, add only enough code to pass it, then refactor. Do not trigger for documentation, configuration, copy-only, or styling changes with no testable behavior.

2026-07-176

verify-before-done

chipfighter/coding-discipline

Use before claiming "done", "fixed", "tested", or "it runs", and before committing or opening a PR or MR—no task is exempt. Accept only evidence gathered after the last relevant change and just sufficient to prove the claim; do not over-verify small changes.

2026-07-176

code-review

chipfighter/coding-discipline

Use when changes affect interactions across multiple modules, involve high-risk areas (authorization/authentication, payments/funds, data deletion/migration, public APIs/cross-service interfaces/security boundaries), or the user requests a review. Review in this order—correctness → requirements → security → simplicity → style. Verify feedback before acting; do not comply blindly or agree performatively. Unless the user asks, documentation-only changes, explicit config values, and mechanical renames do not trigger merely because of a PR or merge.

2026-07-166

name

spec-sync

description

The decision test (the only test for whether to sync)

If the next session or another agent read only the current source of truth, would it continue toward an outcome the user has rejected, violate a new constraint, or judge completion against stale criteria? If so, the change must be synced.

Only changes the user has already confirmed belong in the spec; your own inferences and ideas still under discussion do not.
Before deciding, read the current source of truth at most once to compare. Do not turn this into research.

Write-back rules

Use the current source of truth already designated by the project—the document named by the project guide.
If none is designated, designate an existing Issue / PRD / ADR / status document as the current spec; do not copy it into a second document. If there are multiple candidates or none is obvious, ask the user to choose.
If nothing exists and the work genuinely spans sessions, is shared by multiple people, or would be costly to get wrong, ask whether the user wants a minimal spec (below). The user decides whether to create one; do not create one for work that can be completed within a single session.
After designating or creating one, put a pointer to the source of truth in the project guide document (the “where to find the current state” entry in CLAUDE.md / AGENTS.md)—write only the pointer, not a copy of the content—so the next session can find it.
Edit only the affected original wording: do not append separate “old decision / new decision” versions, reorder the document, or polish the whole document along the way. Replace the affected text as a whole only when the direction changes substantially; leave history to Git.
Do not record execution progress, next steps, or verification evidence. Those belong to the harness / Git / CI, not the spec.
In multi-person / multi-agent work, workers are read-only by default; the primary agent or owner maintains the spec.

Minimal spec (five items—add no more than needed)

Exceptions (do not force either case)

No write access to the source of truth (for example, a PRD owned by someone else): do not overstep. State clearly what is stale and who should update it.
The user explicitly refuses write-back: explain that the next session may read the old target, then comply. An old spec must never be used to block the user's latest instruction.

Hard rules

Do not write changes to outcomes / non-goals / hard constraints / acceptance criteria into the source of truth until the user has confirmed them.
If the implementation is verified but the source of truth is not synced, report those as two separate facts. Do not claim “the source of truth is synced” or “handoff will preserve everything.”
Complete the sync within this session. Do not expect a later session to recover intent that was never persisted.