본문으로 건너뛰기
cccskills
무료GitHub에 공개

code-implementation

Implement, fix, refactor, or remove repository code through a defined workflow. It connects each change to an acceptance criterion, checks effects on existing behavior, and guides focused testing, change review, and verification.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Implement, fix, refactor, or remove repository code under required scope, non-regression, verification, and review gates. Use whenever a task may change a production, test, script, or other implementation artifact, including build logic, generated source, and behavior-affecting configuration. Also use it alongside a specialized code-changing Skill. Do not use for read-only analysis or review, diagnosis-only work, or prose-only changes.

설치 방법 보기

이럴 때 유용합니다

  • Implementing a feature within an agreed scope
  • Fixing bugs while preserving existing behavior
  • Checking impacts before removing code
  • Verifying build or configuration changes

포함된 파일(7)

  • SKILL.md5.4 KB
  • agents/openai.yaml1.1 KB
  • references/rules/artifact-removal-and-contract-impact.md5.5 KB
  • references/rules/implementation.md9.7 KB
  • references/rules/non-regression.md6.3 KB
  • references/rules/testing.md4.8 KB
  • references/verification.md6.5 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Code Implementation

AGENTS.md remains authoritative for scope, permission, safety, architecture, and task lifecycle. Reading this Skill does not grant write, Git, remote, file-type, or scope authority.

Required References

Read every selected reference through EOF before relying on it. Do not substitute catalog metadata, a summary, another Skill, or ordinary coding judgment for a required repository source.

  • For every code-affecting write, read .codex/skills/code-implementation/references/rules/implementation.md.
  • Before loading the testing rules, use these routing facts: for Maven source trees only src/main/** may be the subject of added or updated tests; a change confined to src/test/** requires no additional coverage; and a script, configuration, policy, or harness change needs tests only when an existing focused test mechanism protects its behavior. Read .codex/skills/code-implementation/references/rules/testing.md before assessing test scenarios for changed src/main/** behavior, satisfying requested test or coverage work, or creating or changing a test.
  • Read .codex/skills/code-implementation/references/rules/artifact-removal-and-contract-impact.md before removing or replacing an owner, classifying an artifact as unused or removable, changing a public or externally visible contract, or modifying an affected snapshot, golden file, registration, loading path, or workflow filter.
  • Read .codex/skills/code-implementation/references/rules/non-regression.md when a change affects a public or shared contract, crosses behavior owners, or has credible functional or performance risk. Otherwise preserve supported behavior through the implementation rules and focused owner checks without loading the full reference.
  • Read .codex/skills/code-implementation/references/verification.md before the first repository check and reuse it while the task state is unchanged.
  • For production or test Java and Maven POM changes, read .codex/skills/coding-standards/SKILL.md through EOF and use its Implementation Guidance Mode. For other artifacts, inspect only written standards that govern the changed files. Do not run the standalone inventory or physical-line audit unless the user requests that audit.

Specialized repository Skills compose with this Skill when they write code. Their narrower rules add to these rules and do not replace them.

Workflow

  1. Apply the pre-write gates in AGENTS.md and freeze file -> allowed change intent -> unmet acceptance criterion. Infer clearly authorized paths without asking the user to repeat the request; expand only with exact additional path and intent authorization. Before selecting an implementation, distinguish original user requirements, maintained project contracts, author design choices and unverified assumptions in the existing task record, and trace every hard constraint to its original source. Approval to implement a proposal preserves the approved choice but does not establish that its version pin was an original requirement or that the pin is necessary; retain the constraints and tradeoffs the user actually confirmed with their sources. For a new local override, compatibility exception or parallel mechanism, record the verified reason direct reuse cannot meet the accepted requirements.
  2. Map every planned production and test change to one unsatisfied acceptance criterion and identify the supported existing paths that the change can affect.
  3. Classify functional and performance risk before the first relevant write. Preserve supported behavior outside the exact requested change; when the full non-regression reference is triggered, capture its required baseline before editing.
  4. Implement the smallest clear change under the implementation rules, and apply the testing rules when their trigger above matches.
  5. After each coherent edit batch, inspect every changed path and hunk. Inspect immediately after a formatter, generator, bulk replacement, or another action whose write set is not exact. Stop at the existing scope or authority gate when a required change lies outside the frozen boundary.
  6. Complete this step when Coding Standards applies. After the last implementation write, reapply the Coding Standards Implementation Guidance Mode to affected files and complete its final manual checklist recheck before final verification. Any later write returns the affected files and rules to this step.
  7. Run the narrowest meaningful checks under the verification rules. Reuse a passing result while its task state and evidence remain unchanged; rerun only checks invalidated by a relevant write, failure, scope change, or new evidence.
  8. After verification, follow .codex/context/change-completion.md as the sole completion-loop orchestration owner.

Do not treat a passing build, test, formatter, benchmark, or review tool as proof by itself. Judge the requested behavior, supported existing behavior, contracts, architecture, and affected performance paths directly.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Investigate Apache ShardingSphere issues using official documentation, code, tests, and issue discussions. Distinguish bugs, unsupported usage, duplicates, and enhancement requests, then draft a concise maintainer-style reply explaining the evidence and next action.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Distinguish bugs from unsupported configurations
  • Check whether an issue duplicates an earlier report or fix
  • Draft a GitHub issue reply with clear next steps
apache/shardingsphere2.1만2026년 10월 19일 업데이트

Apply Apache ShardingSphere’s written coding standards during implementation or review, covering naming, Java constructs, tests, and Maven dependencies. Also audit a specified scope without editing files, combining automated checks with manual inspection of applicable rules.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Check changed code against written repository standards
  • Review Java naming and declaration conventions
  • Verify changed Maven dependency declarations
apache/shardingsphere2.1만2026년 10월 19일 업데이트

gen-ut

무료

Create or improve unit tests for Apache ShardingSphere classes. Cover the target class’s behavior and affected branches, verify explicitly requested coverage goals, and consolidate suitable scenarios into parameterized tests, which run the same checks with different inputs.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Add missing unit tests for a target class
  • Verify an explicitly requested coverage target
  • Consolidate suitable tests with different input data
apache/shardingsphere2.1만2026년 10월 19일 업데이트

review-pr

무료

Review Apache ShardingSphere pull requests or authorized downstream changes using repository evidence. Assess code correctness, merge readiness, or CI failures, then produce consolidated findings or a ready-to-copy reply to a review discussion.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Review code changes for correctness and regression risks
  • Assess whether a pull request is ready to merge
  • Investigate CI failures
apache/shardingsphere2.1만2026년 10월 19일 업데이트

apache의 스킬 모두 보기

이 스킬의 문제 신고