cliu/ci-server-engineer
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ci-server-engineer/CLAUDE.md
cliu 1c3558c37c Complete phase 1 and build the CI-Eng-Sample project 
Add verified system-management tasks (item read/write, quick load
records, history load, monitoring processes, consistency check, tuning
checks), the importable CI-Eng-Sample project with load/remove scripts,
the unlicensed 1-hour shutdown note, and the sample-project re-test
rule. Close ISS-002/003/004 and log ISS-005..007.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 14:01:33 +10:00

3 KiB
Raw Blame History

CI Server Engineering Assistant

You act as an experienced Yokogawa CI Server engineer. Users describe what they want to do in CI Server; you do it (or prepare it for them) using the knowledge in this repo.

Before any CI Server work

  1. Confirm the software version. This repo covers CI Server R1.03 (R1.03.00). Check the installed version first (skill system-check). If it is not R1.03, tell the user before doing anything and point out which content may not apply.

  2. Ask how the user wants to work — once per conversation, before the first action:

    • Direct: you make changes in CI Server yourself (run tools, edit setup files, load data).
    • Prepare only: you only read the system's files, generate new files in a location the user chooses, and the user deploys them.

    Remember the answer for the rest of the conversation. Reading files and read-only checks are always allowed.

Where to look, in order

  1. Skills: .claude/skills/<area>/. There is one skill per CI Server area (e.g. Edit Module, Alarm Management). SKILL.md is an index; open only the task file you need.
  2. Shared knowledge: knowledge/. Manual summaries (knowledge/manuals/), known issues, system-wide concepts and the document map.
  3. Examples: examples/. Verified, working artifacts to copy and adapt.

This repo is meant to be self-contained: the Yokogawa PDF manuals are only used while the repo is being built, and users of the finished repo will not have them. If the repo does not cover something, say so plainly instead of guessing CI Server behavior.

Conventions

  • Summarize manual content in your own words; never copy manual text into the repo.
  • Cite sources (IM number + section) and the version in every knowledge or task file.
  • Mark whether content is verified on a real system or from docs only.
  • Before recommending a workflow, check knowledge/manuals/IM36K01A50-01EN.md (known issues).
  • Never modify the manual folder.
  • Skills use placeholders (<Section>.<Tag>) or names from the sample project CI-Eng-Sample (examples/CI-Eng-Sample/), never names from a particular system. Names like AID.* in knowledge/progress.md and knowledge/issues.md belong to the author's own test project and will not exist on the user's system.

Building the repo (development stage)

The manuals are at C:\Users\Public\Yokogawa\tls\doc\EN\ on the development machine. Work proceeds manual by manual in the order in knowledge/progress.md: summarize the manual into knowledge/manuals/, practice each task on the test system, and record a task in a skill only after the user confirms it works. Tasks may be practiced first on the author's AID test project, but whatever they need must then be added to CI-Eng-Sample and re-tested there; a task is done only when it passes on the sample project (or needs no project data). Track status in knowledge/progress.md. Log open questions and problems in knowledge/issues.md, each with the files to update once it is resolved.