# sliver-code-skill

**Repository Path**: sliver-ring_admin/sliver-code-skill

## Basic Information

- **Project Name**: sliver-code-skill
- **Description**: 六年程序员编码经验，一次性蒸馏，即开即用，助力你全面vibecoding！
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 2
- **Forks**: 0
- **Created**: 2026-05-22
- **Last Updated**: 2026-06-12

## Categories & Tags

**Categories**: Uncategorized

**Tags**: Agent, skills, vibecoding

## README

![Sliver Engineering Workflow cover](assets/cover-en.png)

# Sliver Engineering Workflow

Sliver Engineering Workflow is a Codex / Cursor / code-agent skill for repo-native engineering work. It turns a production-oriented engineering method into an installable, reusable, and partially checkable workflow: audit current truth, lock the owner layer and product boundary, design the mainline architecture, implement through the right layer, verify against risk, write docs back, and run drift checks.

It is not a prompt collection or a generic project scaffold. Its purpose is to reduce agent drift during project initiation, feature work, behavior changes, refactors, debugging, validation, and handoff. It especially rejects the common failure mode of starting from UI, HTTP handlers, CLI wiring, prompts, or one-off patches and then reverse-engineering the architecture afterward.

## What It Does

- Project initiation and zero-to-one work: starts with a bootstrap-stage agent constitution, shapes vague ideas into one recommended product mainline, records non-goals and the first closed loop, recommends and confirms one technology stack, then creates `dev-docs/`, architecture owner layers, framework-practice gates, and acceptance evidence before scaffolding code.
- Mid-project adoption: takes over half-built or inherited repos by auditing current truth, establishing agent constitution, creating an internal truth index, and confirming dangerous governance/product-boundary actions before implementation.
- Feature and change work: requires a current audit of code, docs, scripts, tests, and git state before choosing the single owner layer and contract.
- Refactoring and debugging: forces the issue into the right layer, requires reproduction evidence, git-history audits, upstream/GitHub research when relevant, falsifiable hypotheses, and regression gates instead of guess-driven patches.
- Strict verification: maps build, test, contract, browser, live-device, and documentation gates to the actual risk surface.
- Drift control: uses `agent-drift-lock`, Evidence Logs, stop conditions, doc write-back, and a guardrails script to keep the agent on the current source of truth.
- Context handoff: produces copy-paste-ready new-window handoff blocks with git state, validation evidence, runtime state, drift warnings, and next commands.
- Agent handoff: bundles bootstrap templates, a checking script, and a complete feature lifecycle example so another agent can start with concrete structure instead of vague principles.

## When To Use It

Use this skill when:

- You want agents to follow architecture-first and design-first engineering.
- Your repo has `AGENTS.md`, `dev-docs/`, `docs/`, architecture docs, acceptance docs, or an agent constitution.
- The project has not started yet and needs product boundaries, architecture, and acceptance truth before implementation.
- The project is already half-built but lacks `AGENTS.md`, `dev-docs`, a reliable owner map, or a current handoff trail.
- The project is active, but agents often forget current code facts, old decisions, docs indexes, or git boundaries.

Do not use it when:

- You only want disposable one-shot code generation.
- The agent is not allowed to read the current repo truth.
- You expect a script or skill to mathematically guarantee that every model will never drift. This skill can strongly reduce drift, but semantic quality still depends on the agent honestly reading source truth, recording evidence, and running verification.

## Repository Layout

```text
sliver-code-skill/
├── README.zh-CN.md
├── README.md
└── sliver-engineering-workflow/
    ├── SKILL.md
    ├── agents/
    │   └── openai.yaml
    ├── assets/
    │   ├── project-bootstrap/
    │   └── project-adoption/
    ├── examples/
    │   ├── one-feature-lifecycle.md
    │   └── mid-project-adoption-lifecycle.md
    ├── references/
    └── scripts/
        └── check_project_guardrails.py
```

## Install In Codex

From the repository root:

```bash
mkdir -p ~/.codex/skills
cp -R sliver-engineering-workflow ~/.codex/skills/sliver-engineering-workflow
```

If an older local version is already installed, update it in place:

```bash
mkdir -p ~/.codex/skills/sliver-engineering-workflow
cp -R sliver-engineering-workflow/. ~/.codex/skills/sliver-engineering-workflow/
```

Restart Codex after installation so future sessions can load the skill.

## Verify Installation

If your Codex installation includes the official skill validator:

```bash
python3 ~/.codex/skills/.system/skill-creator/scripts/quick_validate.py \
  ~/.codex/skills/sliver-engineering-workflow
```

Check the bundled bootstrap template:

```bash
python3 ~/.codex/skills/sliver-engineering-workflow/scripts/check_project_guardrails.py \
  ~/.codex/skills/sliver-engineering-workflow/assets/project-bootstrap \
  --allow-template
```

Check a real project:

```bash
python3 ~/.codex/skills/sliver-engineering-workflow/scripts/check_project_guardrails.py \
  /path/to/project
```

If the project only has `docs/` and does not yet have `dev-docs/`, use the transitional mode:

```bash
python3 ~/.codex/skills/sliver-engineering-workflow/scripts/check_project_guardrails.py \
  /path/to/project \
  --truth-dir docs
```

For a half-built or inherited project that is being adopted midstream:

```bash
python3 ~/.codex/skills/sliver-engineering-workflow/scripts/check_project_guardrails.py \
  /path/to/project \
  --mode adoption
```

## Usage Examples

Ask Codex to use the skill explicitly:

```text
Use sliver-engineering-workflow to initiate this empty project and define the phase-one architecture.
```

```text
Use sliver-engineering-workflow to audit current truth first, then implement this feature. Do not patch around the owner layer.
```

```text
Use sliver-engineering-workflow to check whether this repo is drifting. Focus on dev-docs, owner boundaries, stop conditions, and verification evidence.
```

```text
Use sliver-engineering-workflow to adopt this half-built repo first: audit current truth, propose AGENTS.md/dev-docs governance, identify dangerous adoption actions, then hand me the first safe task.
```

Cursor and other agent environments can reuse the same files. If `.codex/sessions` and Codex memories are unavailable, use `agent-transcripts/`, chat exports, current diffs, commit history, review comments, and active docs as conversation evidence.

## License

MIT. See [LICENSE](LICENSE).