nono-skills 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +127 -0
- package/bin/cli.js +23 -0
- package/package.json +46 -0
- package/plugin/.codex-plugin/plugin.json +26 -0
- package/plugin/skills/api-design/SKILL.md +40 -0
- package/plugin/skills/api-design/agents/openai.yaml +4 -0
- package/plugin/skills/architecture-review/SKILL.md +40 -0
- package/plugin/skills/architecture-review/agents/openai.yaml +4 -0
- package/plugin/skills/brainstorm/SKILL.md +41 -0
- package/plugin/skills/brainstorm/agents/openai.yaml +4 -0
- package/plugin/skills/database-design/SKILL.md +40 -0
- package/plugin/skills/database-design/agents/openai.yaml +4 -0
- package/plugin/skills/debug/SKILL.md +40 -0
- package/plugin/skills/debug/agents/openai.yaml +4 -0
- package/plugin/skills/estimate/SKILL.md +40 -0
- package/plugin/skills/estimate/agents/openai.yaml +4 -0
- package/plugin/skills/fix-findings/SKILL.md +40 -0
- package/plugin/skills/fix-findings/agents/openai.yaml +4 -0
- package/plugin/skills/implement/SKILL.md +40 -0
- package/plugin/skills/implement/agents/openai.yaml +4 -0
- package/plugin/skills/migration/SKILL.md +40 -0
- package/plugin/skills/migration/agents/openai.yaml +4 -0
- package/plugin/skills/plan/SKILL.md +40 -0
- package/plugin/skills/plan/agents/openai.yaml +4 -0
- package/plugin/skills/refactor/SKILL.md +40 -0
- package/plugin/skills/refactor/agents/openai.yaml +4 -0
- package/plugin/skills/release-readiness/SKILL.md +39 -0
- package/plugin/skills/release-readiness/agents/openai.yaml +4 -0
- package/plugin/skills/review/SKILL.md +39 -0
- package/plugin/skills/review/agents/openai.yaml +4 -0
- package/plugin/skills/security-review/SKILL.md +39 -0
- package/plugin/skills/security-review/agents/openai.yaml +4 -0
- package/plugin/skills/test/SKILL.md +40 -0
- package/plugin/skills/test/agents/openai.yaml +4 -0
- package/scripts/validate.mjs +29 -0
- package/src/cli.js +85 -0
- package/src/codex.js +13 -0
- package/src/commands.js +98 -0
- package/src/doctor.js +40 -0
- package/src/fs-safe.js +38 -0
- package/src/plugin-install.js +135 -0
- package/src/plugin-state.js +82 -0
- package/src/project-init.js +53 -0
- package/src/uninstall.js +50 -0
- package/templates/AGENTS.md +48 -0
- package/templates/docs/agent/decision-log.md +15 -0
- package/templates/docs/agent/findings.md +13 -0
- package/templates/docs/agent/handoff.md +20 -0
- package/templates/docs/agent/plan.md +14 -0
- package/templates/docs/agent/spec.md +20 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 thitikorn.j
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,127 @@
|
|
|
1
|
+
# Nono Skills
|
|
2
|
+
|
|
3
|
+
A lightweight, reasoning-first engineering workflow pack for Codex. It provides 15 namespaced skills built around outcomes, evidence, verification, material decisions, and human escalation.
|
|
4
|
+
|
|
5
|
+
The pack is designed for capable reasoning models such as GPT-5.6 Sol. Skills define intent and guardrails while leaving implementation strategy to the model. They do not impose mandatory approval gates, worktrees, test-first development, or subagent orchestration.
|
|
6
|
+
|
|
7
|
+
## How it works
|
|
8
|
+
|
|
9
|
+
- Codex can select a skill implicitly from its focused trigger description, or you can invoke one explicitly.
|
|
10
|
+
- Each skill defines its purpose, inputs, outputs, rules, decision-log updates, and conditions that require human judgment.
|
|
11
|
+
- Workflow artifacts are optional. Skills update existing artifacts but do not create missing `docs/agent/` files unless you request durable artifacts or run `init`.
|
|
12
|
+
- Decision logs capture costly, contractual, ambiguous, or risk-bearing choices—not routine edits or shell commands.
|
|
13
|
+
- Overlapping intents have explicit boundaries: brainstorm before direction, plan after direction, implement general changes, fix-findings for validated findings, review for general defects, and security-review when security is the primary objective.
|
|
14
|
+
|
|
15
|
+
## Install
|
|
16
|
+
|
|
17
|
+
Requires Node.js 20 or newer and Codex CLI with plugin support.
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
npx nono-skills install
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Start a new Codex task after installation. Skills appear under the `engineering` namespace:
|
|
24
|
+
|
|
25
|
+
```text
|
|
26
|
+
$engineering:plan
|
|
27
|
+
$engineering:implement
|
|
28
|
+
$engineering:review
|
|
29
|
+
$engineering:fix-findings
|
|
30
|
+
$engineering:architecture-review
|
|
31
|
+
$engineering:security-review
|
|
32
|
+
$engineering:test
|
|
33
|
+
$engineering:debug
|
|
34
|
+
$engineering:refactor
|
|
35
|
+
$engineering:release-readiness
|
|
36
|
+
$engineering:brainstorm
|
|
37
|
+
$engineering:estimate
|
|
38
|
+
$engineering:migration
|
|
39
|
+
$engineering:api-design
|
|
40
|
+
$engineering:database-design
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
### Choosing a skill
|
|
44
|
+
|
|
45
|
+
| Intent | Skill |
|
|
46
|
+
|---|---|
|
|
47
|
+
| Explore options before choosing a direction | `$engineering:brainstorm` |
|
|
48
|
+
| Turn defined work into a verifiable execution map | `$engineering:plan` |
|
|
49
|
+
| Build a general software change | `$engineering:implement` |
|
|
50
|
+
| Correct validated findings | `$engineering:fix-findings` |
|
|
51
|
+
| Review a change without editing it | `$engineering:review` |
|
|
52
|
+
| Assess security as the primary objective | `$engineering:security-review` |
|
|
53
|
+
| Evaluate system structure and change cost | `$engineering:architecture-review` |
|
|
54
|
+
| Isolate a root cause from runtime evidence | `$engineering:debug` |
|
|
55
|
+
| Add focused behavioral or regression tests | `$engineering:test` |
|
|
56
|
+
| Improve internal structure without changing behavior | `$engineering:refactor` |
|
|
57
|
+
| Assess merge, release, or deployment readiness | `$engineering:release-readiness` |
|
|
58
|
+
| Estimate effort with ranges and uncertainty | `$engineering:estimate` |
|
|
59
|
+
| Design a reversible transition | `$engineering:migration` |
|
|
60
|
+
| Design a stable consumer contract | `$engineering:api-design` |
|
|
61
|
+
| Design persistent data around invariants | `$engineering:database-design` |
|
|
62
|
+
|
|
63
|
+
## Initialize a project
|
|
64
|
+
|
|
65
|
+
Initialization is optional. Add concise repository guidance and shared agent artifacts to the current project with:
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
npx nono-skills init
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
Preview changes or target another repository:
|
|
72
|
+
|
|
73
|
+
```bash
|
|
74
|
+
npx nono-skills init --dry-run
|
|
75
|
+
npx nono-skills init ../my-project
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
Existing differing files are reported as conflicts and no files are written. To replace them explicitly, create timestamped backups first:
|
|
79
|
+
|
|
80
|
+
```bash
|
|
81
|
+
npx nono-skills init --force
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
Project artifacts include a repository-focused `AGENTS.md` and `docs/agent/` templates for specs, plans, decisions, findings, and handoffs. Without initialization, skills return the same material information in their final response instead of creating workflow files.
|
|
85
|
+
|
|
86
|
+
## Maintain the installation
|
|
87
|
+
|
|
88
|
+
```bash
|
|
89
|
+
npx nono-skills doctor
|
|
90
|
+
npx nono-skills update
|
|
91
|
+
npx nono-skills uninstall
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
Start a new Codex task after install or update so the refreshed skill definitions are loaded.
|
|
95
|
+
|
|
96
|
+
Uninstall preserves project files. Remove only project files that still match their installed checksums with:
|
|
97
|
+
|
|
98
|
+
```bash
|
|
99
|
+
npx nono-skills uninstall --purge-project /path/to/project
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
Modified project files are always preserved.
|
|
103
|
+
|
|
104
|
+
## Moving away from Superpowers
|
|
105
|
+
|
|
106
|
+
Install this plugin, start a new task, and verify the `engineering:*` skills first. Then open `/plugins`, select Superpowers, and press Space to disable it reversibly. After normal work succeeds without it, uninstall Superpowers from the plugin browser. Do not delete Codex plugin cache directories manually.
|
|
107
|
+
|
|
108
|
+
This pack intentionally does not reproduce strict test-first enforcement, automatic worktrees, mandatory design approval gates, or subagent-driven execution. Add separate focused skills for those behaviors when a task genuinely needs them.
|
|
109
|
+
|
|
110
|
+
## Safety model
|
|
111
|
+
|
|
112
|
+
- The installer owns only the `engineering` plugin entry and source files recorded in its checksum manifest.
|
|
113
|
+
- Marketplace edits preserve unrelated entries and metadata.
|
|
114
|
+
- Install and update roll back plugin source and marketplace changes when Codex registration fails.
|
|
115
|
+
- Project files are never overwritten without `--force` and a backup.
|
|
116
|
+
- Skills do not create missing workflow artifacts implicitly.
|
|
117
|
+
- The CLI never disables or removes Superpowers automatically.
|
|
118
|
+
|
|
119
|
+
## Development
|
|
120
|
+
|
|
121
|
+
```bash
|
|
122
|
+
npm test
|
|
123
|
+
npm run validate
|
|
124
|
+
npm pack --dry-run
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
The runtime has no third-party dependencies.
|
package/bin/cli.js
ADDED
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
|
|
3
|
+
import { readFile } from 'node:fs/promises';
|
|
4
|
+
import os from 'node:os';
|
|
5
|
+
import path from 'node:path';
|
|
6
|
+
import { fileURLToPath } from 'node:url';
|
|
7
|
+
|
|
8
|
+
import { run } from '../src/cli.js';
|
|
9
|
+
import { createHandlers } from '../src/commands.js';
|
|
10
|
+
|
|
11
|
+
const packageRoot = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '..');
|
|
12
|
+
const packageJson = JSON.parse(await readFile(path.join(packageRoot, 'package.json'), 'utf8'));
|
|
13
|
+
const context = {
|
|
14
|
+
packageRoot,
|
|
15
|
+
packageVersion: packageJson.version,
|
|
16
|
+
home: os.homedir(),
|
|
17
|
+
cwd: process.cwd(),
|
|
18
|
+
stdout: process.stdout,
|
|
19
|
+
stderr: process.stderr,
|
|
20
|
+
};
|
|
21
|
+
context.handlers = createHandlers(context);
|
|
22
|
+
|
|
23
|
+
process.exitCode = await run(process.argv.slice(2), context);
|
package/package.json
ADDED
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "nono-skills",
|
|
3
|
+
"version": "0.1.0",
|
|
4
|
+
"description": "Install a lightweight engineering workflow plugin for Codex.",
|
|
5
|
+
"author": "thitikorn.j",
|
|
6
|
+
"type": "module",
|
|
7
|
+
"bin": {
|
|
8
|
+
"nono-skills": "bin/cli.js"
|
|
9
|
+
},
|
|
10
|
+
"engines": {
|
|
11
|
+
"node": ">=20"
|
|
12
|
+
},
|
|
13
|
+
"scripts": {
|
|
14
|
+
"test": "node --test",
|
|
15
|
+
"validate": "node scripts/validate.mjs",
|
|
16
|
+
"prepublishOnly": "npm test && npm run validate"
|
|
17
|
+
},
|
|
18
|
+
"files": [
|
|
19
|
+
"bin/",
|
|
20
|
+
"src/",
|
|
21
|
+
"plugin/",
|
|
22
|
+
"templates/",
|
|
23
|
+
"scripts/validate.mjs",
|
|
24
|
+
"README.md",
|
|
25
|
+
"LICENSE"
|
|
26
|
+
],
|
|
27
|
+
"keywords": [
|
|
28
|
+
"codex",
|
|
29
|
+
"skills",
|
|
30
|
+
"plugin",
|
|
31
|
+
"engineering",
|
|
32
|
+
"workflow"
|
|
33
|
+
],
|
|
34
|
+
"license": "MIT",
|
|
35
|
+
"repository": {
|
|
36
|
+
"type": "git",
|
|
37
|
+
"url": "git+https://github.com/nono911/nono-skills.git"
|
|
38
|
+
},
|
|
39
|
+
"homepage": "https://github.com/nono911/nono-skills#readme",
|
|
40
|
+
"bugs": {
|
|
41
|
+
"url": "https://github.com/nono911/nono-skills/issues"
|
|
42
|
+
},
|
|
43
|
+
"publishConfig": {
|
|
44
|
+
"access": "public"
|
|
45
|
+
}
|
|
46
|
+
}
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "engineering",
|
|
3
|
+
"version": "0.1.0",
|
|
4
|
+
"description": "Lightweight, reasoning-first engineering workflows for Codex.",
|
|
5
|
+
"author": {
|
|
6
|
+
"name": "thitikorn.j"
|
|
7
|
+
},
|
|
8
|
+
"homepage": "https://github.com/nono911/nono-skills",
|
|
9
|
+
"repository": "https://github.com/nono911/nono-skills",
|
|
10
|
+
"license": "MIT",
|
|
11
|
+
"keywords": ["codex", "engineering", "skills", "workflow"],
|
|
12
|
+
"skills": "./skills/",
|
|
13
|
+
"interface": {
|
|
14
|
+
"displayName": "Engineering",
|
|
15
|
+
"shortDescription": "Plan, build, review, debug, and release software.",
|
|
16
|
+
"longDescription": "A concise reasoning-first engineering pack centered on outcomes, evidence, verification, material decisions, and human escalation.",
|
|
17
|
+
"developerName": "thitikorn.j",
|
|
18
|
+
"category": "Developer Tools",
|
|
19
|
+
"capabilities": ["Interactive", "Write"],
|
|
20
|
+
"defaultPrompt": [
|
|
21
|
+
"Plan this engineering task.",
|
|
22
|
+
"Implement this change and verify it.",
|
|
23
|
+
"Review the current change for defects."
|
|
24
|
+
]
|
|
25
|
+
}
|
|
26
|
+
}
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: api-design
|
|
3
|
+
description: Use when creating or changing an HTTP, RPC, event, webhook, library, or internal service contract and consumers need a stable, evolvable interface.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# API Design
|
|
7
|
+
|
|
8
|
+
## Purpose
|
|
9
|
+
|
|
10
|
+
Define a consumer-centered contract with precise semantics, failure behavior, authorization, compatibility, and operability before or alongside implementation.
|
|
11
|
+
|
|
12
|
+
## Inputs
|
|
13
|
+
|
|
14
|
+
- Consumer use cases, domain language, invariants, and quality constraints
|
|
15
|
+
- Existing APIs, conventions, clients, schemas, auth model, and versioning policy
|
|
16
|
+
- Expected scale, consistency, latency, and lifecycle needs
|
|
17
|
+
|
|
18
|
+
## Outputs
|
|
19
|
+
|
|
20
|
+
- Contract for operations, messages, fields, errors, auth, pagination, idempotency, and compatibility as applicable
|
|
21
|
+
- Examples for normal, boundary, and failure cases
|
|
22
|
+
- Implementation and migration considerations without speculative internals
|
|
23
|
+
|
|
24
|
+
## Rules
|
|
25
|
+
|
|
26
|
+
- Model domain capabilities, not current database tables or UI screens.
|
|
27
|
+
- Define presence, nullability, units, ordering, time semantics, identifiers, and error meanings explicitly.
|
|
28
|
+
- Design retries, idempotency, concurrency, pagination, rate limits, and partial failure where relevant.
|
|
29
|
+
- Apply least privilege and avoid leaking internal or sensitive data.
|
|
30
|
+
- Prefer additive evolution; identify every known consumer before breaking changes.
|
|
31
|
+
- Do not implement unless requested.
|
|
32
|
+
|
|
33
|
+
## Decision-log updates
|
|
34
|
+
|
|
35
|
+
Record public contract choices, compatibility policy, naming or semantic decisions likely to recur, idempotency and consistency guarantees, and rejected alternatives with consumer impact.
|
|
36
|
+
Use an existing `docs/agent/decision-log.md`. If it is absent, include the decision in the final response; create workflow artifacts only when the user requests them.
|
|
37
|
+
|
|
38
|
+
## Escalate to the human
|
|
39
|
+
|
|
40
|
+
Escalate when consumer requirements conflict, authorization ownership is unclear, semantics imply legal or financial commitments, a breaking change lacks a migration path, or reliability and consistency tradeoffs need product or platform ownership.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: architecture-review
|
|
3
|
+
description: Use when architecture is the primary review objective for boundaries, coupling, ownership, scalability, resilience, maintainability, or long-term change cost.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Architecture Review
|
|
7
|
+
|
|
8
|
+
## Purpose
|
|
9
|
+
|
|
10
|
+
Evaluate whether system structure supports the stated product and operational needs, using repository evidence rather than generic pattern scoring.
|
|
11
|
+
|
|
12
|
+
## Inputs
|
|
13
|
+
|
|
14
|
+
- Goals, constraints, quality attributes, diagrams or proposals
|
|
15
|
+
- Current modules, dependencies, data flows, deployment topology, and ownership boundaries
|
|
16
|
+
- Known scale, failure modes, and change scenarios
|
|
17
|
+
|
|
18
|
+
## Outputs
|
|
19
|
+
|
|
20
|
+
- Current-state model and material architectural findings
|
|
21
|
+
- Tradeoff analysis with prioritized recommendations
|
|
22
|
+
- Explicit assumptions, residual risks, and staged options when change is warranted
|
|
23
|
+
|
|
24
|
+
## Rules
|
|
25
|
+
|
|
26
|
+
- Start from desired capabilities and likely changes, not fashionable architecture.
|
|
27
|
+
- Trace dependency direction, state ownership, contracts, failure propagation, and operational boundaries.
|
|
28
|
+
- Separate structural problems from local code-quality issues.
|
|
29
|
+
- Quantify scale or cost claims when evidence exists; label estimates otherwise.
|
|
30
|
+
- Prefer incremental, reversible improvements and describe migration cost.
|
|
31
|
+
- Remain read-only unless implementation is explicitly requested.
|
|
32
|
+
|
|
33
|
+
## Decision-log updates
|
|
34
|
+
|
|
35
|
+
Record accepted boundaries, ownership, technology choices, quality-attribute priorities, and deliberately accepted coupling or debt. Capture alternatives and migration consequences.
|
|
36
|
+
Use an existing `docs/agent/decision-log.md`. If it is absent, include the decision in the final response; create workflow artifacts only when the user requests them.
|
|
37
|
+
|
|
38
|
+
## Escalate to the human
|
|
39
|
+
|
|
40
|
+
Escalate when priorities conflict, ownership is unclear, a recommendation commits the team to major platform or vendor cost, or missing product and operational constraints prevent a defensible recommendation.
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: brainstorm
|
|
3
|
+
description: Use when a product, feature, technical approach, workflow, or problem space needs distinct options explored before choosing a direction or writing an execution plan.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Brainstorm
|
|
7
|
+
|
|
8
|
+
## Purpose
|
|
9
|
+
|
|
10
|
+
Turn an unclear opportunity into a small set of distinct, evidence-aware options and a recommended direction without prematurely implementing one.
|
|
11
|
+
|
|
12
|
+
## Inputs
|
|
13
|
+
|
|
14
|
+
- Desired outcome, users, constraints, known pain, and prior attempts
|
|
15
|
+
- Relevant repository, product, operational, and market evidence available in scope
|
|
16
|
+
- Decision deadline and reversibility
|
|
17
|
+
|
|
18
|
+
## Outputs
|
|
19
|
+
|
|
20
|
+
- Problem framing and success signals
|
|
21
|
+
- Two to four meaningfully different options with tradeoffs
|
|
22
|
+
- Recommendation, key assumptions, risks, and cheapest next experiment
|
|
23
|
+
- Proposed spec updates only when the direction is accepted or explicitly requested
|
|
24
|
+
|
|
25
|
+
## Rules
|
|
26
|
+
|
|
27
|
+
- Clarify the outcome before generating solutions.
|
|
28
|
+
- Prefer distinct strategies over cosmetic variants.
|
|
29
|
+
- Separate facts, assumptions, and hypotheses.
|
|
30
|
+
- Evaluate user value, complexity, risk, reversibility, and operational cost.
|
|
31
|
+
- Recommend a direction when evidence supports one; do not hide behind an unranked list.
|
|
32
|
+
- Do not implement during exploration unless explicitly asked.
|
|
33
|
+
|
|
34
|
+
## Decision-log updates
|
|
35
|
+
|
|
36
|
+
Record the selected direction, rejected alternatives when the tradeoff may recur, key assumptions to validate, and the next experiment. Keep unselected raw ideas out of the durable log unless they explain a decision.
|
|
37
|
+
Use an existing `docs/agent/decision-log.md`. If it is absent, include the decision in the final response; create workflow artifacts only when the user requests them.
|
|
38
|
+
|
|
39
|
+
## Escalate to the human
|
|
40
|
+
|
|
41
|
+
Escalate when the core user or outcome is unknown, options encode incompatible product strategies, ethical or legal risk is material, or a choice commits significant time, spend, vendor lock-in, or irreversible data design.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: database-design
|
|
3
|
+
description: Use when designing or changing persistent data models, schemas, constraints, indexes, transactions, tenancy, retention, or query patterns.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Database Design
|
|
7
|
+
|
|
8
|
+
## Purpose
|
|
9
|
+
|
|
10
|
+
Create a data model that enforces domain invariants, serves proven access patterns, evolves safely, and has explicit consistency and lifecycle semantics.
|
|
11
|
+
|
|
12
|
+
## Inputs
|
|
13
|
+
|
|
14
|
+
- Domain concepts, invariants, lifecycle, ownership, and access patterns
|
|
15
|
+
- Expected cardinality, volume, growth, concurrency, latency, tenancy, and retention
|
|
16
|
+
- Existing schema, queries, migrations, engine capabilities, and operational constraints
|
|
17
|
+
|
|
18
|
+
## Outputs
|
|
19
|
+
|
|
20
|
+
- Entities, relationships, keys, constraints, indexes, transaction boundaries, and lifecycle rules
|
|
21
|
+
- Query and write-path implications with migration considerations
|
|
22
|
+
- Validation approach for correctness, performance, backup, and recovery
|
|
23
|
+
|
|
24
|
+
## Rules
|
|
25
|
+
|
|
26
|
+
- Start with invariants and access patterns, not a table inventory.
|
|
27
|
+
- Define canonical ownership and avoid duplicated mutable truth without reconciliation.
|
|
28
|
+
- Use database constraints for enforceable invariants where appropriate.
|
|
29
|
+
- Design indexes from real query shapes and write cost; verify with plans or representative data when possible.
|
|
30
|
+
- Make tenancy, authorization boundaries, time zones, precision, deletion, audit, and retention explicit.
|
|
31
|
+
- Separate schema design from authorization to run production migrations.
|
|
32
|
+
|
|
33
|
+
## Decision-log updates
|
|
34
|
+
|
|
35
|
+
Record data ownership, normalization tradeoffs, identifiers, consistency model, transaction boundaries, retention, tenant isolation, and irreversible schema choices. Link migration and rollback implications.
|
|
36
|
+
Use an existing `docs/agent/decision-log.md`. If it is absent, include the decision in the final response; create workflow artifacts only when the user requests them.
|
|
37
|
+
|
|
38
|
+
## Escalate to the human
|
|
39
|
+
|
|
40
|
+
Escalate when domain truth is ambiguous, data classification or retention needs ownership, consistency and availability goals conflict, projected scale lacks evidence, or a design requires destructive migration, downtime, or irreversible data transformation.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: debug
|
|
3
|
+
description: Use when behavior is wrong, failing, flaky, slow, inconsistent, or unexplained and the root cause must be isolated from runtime evidence.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Debug
|
|
7
|
+
|
|
8
|
+
## Purpose
|
|
9
|
+
|
|
10
|
+
Reproduce the symptom, trace the failing path, falsify competing hypotheses, isolate root cause, and verify the requested resolution.
|
|
11
|
+
|
|
12
|
+
## Inputs
|
|
13
|
+
|
|
14
|
+
- Exact symptom, error, payload, timing, environment, and expected behavior
|
|
15
|
+
- Relevant logs, traces, code paths, stored data, configuration, and recent changes
|
|
16
|
+
- Reproduction access and constraints
|
|
17
|
+
|
|
18
|
+
## Outputs
|
|
19
|
+
|
|
20
|
+
- Minimal reproduction or strongest available evidence
|
|
21
|
+
- Root cause with causal chain, not just correlation
|
|
22
|
+
- If fixes are authorized: minimal fix, regression test, and verification
|
|
23
|
+
- If diagnosis-only: recommended next action without source edits
|
|
24
|
+
|
|
25
|
+
## Rules
|
|
26
|
+
|
|
27
|
+
- Start at the observed boundary and trace backward through the real runtime and data path.
|
|
28
|
+
- State hypotheses with evidence that would falsify each one; test the cheapest discriminating check first.
|
|
29
|
+
- Change one variable at a time and preserve useful raw evidence.
|
|
30
|
+
- Do not patch before identifying the causal mechanism unless containing an active incident is explicitly authorized.
|
|
31
|
+
- Reproduce again after the fix and run adjacent regression checks.
|
|
32
|
+
|
|
33
|
+
## Decision-log updates
|
|
34
|
+
|
|
35
|
+
Record confirmed root cause, discarded high-likelihood hypotheses, material diagnostic pivots, chosen remediation tradeoffs, and remaining uncertainty. Avoid logging every command.
|
|
36
|
+
Use an existing `docs/agent/decision-log.md`. If it is absent, include the decision in the final response; create workflow artifacts only when the user requests them.
|
|
37
|
+
|
|
38
|
+
## Escalate to the human
|
|
39
|
+
|
|
40
|
+
Escalate when reproduction risks data or availability, required logs or access need new authority, evidence suggests an active incident or security issue, or multiple fixes imply materially different product behavior.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: estimate
|
|
3
|
+
description: Use when software work needs an evidence-based range for effort, duration, sequencing, risk, staffing, or confidence before commitment.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Estimate
|
|
7
|
+
|
|
8
|
+
## Purpose
|
|
9
|
+
|
|
10
|
+
Provide a transparent range derived from scope, dependencies, uncertainty, and comparable work rather than a false-precision point value.
|
|
11
|
+
|
|
12
|
+
## Inputs
|
|
13
|
+
|
|
14
|
+
- Goal, acceptance criteria, proposed plan, and definition of done
|
|
15
|
+
- Current architecture, team and environment constraints, dependencies, and unknowns
|
|
16
|
+
- Historical evidence when available
|
|
17
|
+
|
|
18
|
+
## Outputs
|
|
19
|
+
|
|
20
|
+
- Optimistic, likely, and pessimistic ranges with confidence
|
|
21
|
+
- Work breakdown at the level needed to explain the range
|
|
22
|
+
- Assumptions, exclusions, critical path, risk drivers, and uncertainty-reduction actions
|
|
23
|
+
|
|
24
|
+
## Rules
|
|
25
|
+
|
|
26
|
+
- Estimate the full delivery boundary requested, including verification, review, migration, rollout, and coordination when applicable.
|
|
27
|
+
- Keep effort and elapsed duration separate.
|
|
28
|
+
- Do not invent team velocity or historical baselines.
|
|
29
|
+
- Express unknowns as ranges or scenarios, not hidden padding.
|
|
30
|
+
- Re-estimate after material scope or evidence changes.
|
|
31
|
+
- State the unit and whether the estimate is for one person, a team, or calendar time.
|
|
32
|
+
|
|
33
|
+
## Decision-log updates
|
|
34
|
+
|
|
35
|
+
Record the committed estimation basis, major assumptions, exclusions, selected scenario, and later changes that materially move the range. Do not log exploratory arithmetic.
|
|
36
|
+
Use an existing `docs/agent/decision-log.md`. If it is absent, include the decision in the final response; create workflow artifacts only when the user requests them.
|
|
37
|
+
|
|
38
|
+
## Escalate to the human
|
|
39
|
+
|
|
40
|
+
Escalate when scope is not bounded enough to produce a useful range, staffing or dependency ownership is unknown, a deadline requires explicit scope tradeoffs, or the estimate will be treated as a commitment despite low confidence.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: fix-findings
|
|
3
|
+
description: Use when validated review, audit, QA, or security findings must be corrected and verified in the current codebase.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Fix Findings
|
|
7
|
+
|
|
8
|
+
## Purpose
|
|
9
|
+
|
|
10
|
+
Resolve accepted findings at their root cause, preserve intended behavior, and produce evidence that each fix closes the reported failure.
|
|
11
|
+
|
|
12
|
+
## Inputs
|
|
13
|
+
|
|
14
|
+
- Findings with evidence, severity, and expected outcome
|
|
15
|
+
- Current code, tests, applicable instructions, and related decisions
|
|
16
|
+
- The user's authorized fix scope
|
|
17
|
+
|
|
18
|
+
## Outputs
|
|
19
|
+
|
|
20
|
+
- Minimal fixes and regression coverage
|
|
21
|
+
- Updated finding states with verification evidence
|
|
22
|
+
- Updated plan or handoff for unresolved items
|
|
23
|
+
|
|
24
|
+
## Rules
|
|
25
|
+
|
|
26
|
+
- Reproduce or independently validate each finding before changing code.
|
|
27
|
+
- Fix the causal path, not only the visible symptom.
|
|
28
|
+
- Handle findings in risk order unless dependencies require another sequence.
|
|
29
|
+
- Keep unrelated refactors separate.
|
|
30
|
+
- Mark `not-reproducible` or `wont-fix` only with evidence or human approval; never close by assertion.
|
|
31
|
+
- Request re-review or perform an independent verification pass after fixes.
|
|
32
|
+
|
|
33
|
+
## Decision-log updates
|
|
34
|
+
|
|
35
|
+
Record chosen remediations when alternatives have meaningful compatibility, security, performance, or operational tradeoffs. Link the decision to finding IDs and record any accepted residual risk.
|
|
36
|
+
Use existing `docs/agent/findings.md` and `decision-log.md` files when present. If they are absent, report state changes and decisions in the final response; create workflow artifacts only when the user requests them.
|
|
37
|
+
|
|
38
|
+
## Escalate to the human
|
|
39
|
+
|
|
40
|
+
Escalate when a finding is disputed and evidence is inconclusive, remediation changes a public contract, fixes conflict, the safe fix requires migration or downtime, or residual risk needs acceptance. Do not broaden authority from “fix” into deploy or production mutation.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: implement
|
|
3
|
+
description: Use for general software implementation from a requirement, spec, issue, or plan; use fix-findings instead when validated findings are the primary work queue.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Implement
|
|
7
|
+
|
|
8
|
+
## Purpose
|
|
9
|
+
|
|
10
|
+
Deliver the smallest complete change that satisfies the contract, preserves unrelated behavior, and is verified in proportion to risk.
|
|
11
|
+
|
|
12
|
+
## Inputs
|
|
13
|
+
|
|
14
|
+
- User request and acceptance criteria
|
|
15
|
+
- Applicable repository instructions and live code paths
|
|
16
|
+
- Existing spec, plan, decisions, findings, and tests
|
|
17
|
+
|
|
18
|
+
## Outputs
|
|
19
|
+
|
|
20
|
+
- Scoped source, test, configuration, migration, or documentation changes
|
|
21
|
+
- Updated existing plan status and handoff when those artifacts are in use and work remains
|
|
22
|
+
- Verification evidence and a concise change summary
|
|
23
|
+
|
|
24
|
+
## Rules
|
|
25
|
+
|
|
26
|
+
- Trace current behavior before editing and follow established project patterns unless evidence justifies a change.
|
|
27
|
+
- Prefer the smallest coherent vertical slice over speculative infrastructure.
|
|
28
|
+
- Keep compatibility unless a breaking change is explicitly authorized.
|
|
29
|
+
- Add or update tests for changed behavior when a viable harness exists.
|
|
30
|
+
- Do not silently weaken tests, validation, security, typing, or error handling to make checks pass.
|
|
31
|
+
- Do not commit, push, deploy, or mutate external systems without explicit authorization.
|
|
32
|
+
|
|
33
|
+
## Decision-log updates
|
|
34
|
+
|
|
35
|
+
Record material implementation choices, deviations from the plan, assumptions that affect behavior, accepted tradeoffs, and why a simpler or established pattern was not used. Include verification or follow-up consequences.
|
|
36
|
+
Use an existing `docs/agent/decision-log.md`. If it is absent, include the decision in the final response; create workflow artifacts only when the user requests them.
|
|
37
|
+
|
|
38
|
+
## Escalate to the human
|
|
39
|
+
|
|
40
|
+
Escalate when acceptance criteria conflict, implementation requires a breaking or destructive change, credentials or production data are required, an external action needs new authority, or the only viable approach materially expands scope. Routine code-level choices do not require escalation.
|