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.
Files changed (51) hide show
  1. package/LICENSE +21 -0
  2. package/README.md +127 -0
  3. package/bin/cli.js +23 -0
  4. package/package.json +46 -0
  5. package/plugin/.codex-plugin/plugin.json +26 -0
  6. package/plugin/skills/api-design/SKILL.md +40 -0
  7. package/plugin/skills/api-design/agents/openai.yaml +4 -0
  8. package/plugin/skills/architecture-review/SKILL.md +40 -0
  9. package/plugin/skills/architecture-review/agents/openai.yaml +4 -0
  10. package/plugin/skills/brainstorm/SKILL.md +41 -0
  11. package/plugin/skills/brainstorm/agents/openai.yaml +4 -0
  12. package/plugin/skills/database-design/SKILL.md +40 -0
  13. package/plugin/skills/database-design/agents/openai.yaml +4 -0
  14. package/plugin/skills/debug/SKILL.md +40 -0
  15. package/plugin/skills/debug/agents/openai.yaml +4 -0
  16. package/plugin/skills/estimate/SKILL.md +40 -0
  17. package/plugin/skills/estimate/agents/openai.yaml +4 -0
  18. package/plugin/skills/fix-findings/SKILL.md +40 -0
  19. package/plugin/skills/fix-findings/agents/openai.yaml +4 -0
  20. package/plugin/skills/implement/SKILL.md +40 -0
  21. package/plugin/skills/implement/agents/openai.yaml +4 -0
  22. package/plugin/skills/migration/SKILL.md +40 -0
  23. package/plugin/skills/migration/agents/openai.yaml +4 -0
  24. package/plugin/skills/plan/SKILL.md +40 -0
  25. package/plugin/skills/plan/agents/openai.yaml +4 -0
  26. package/plugin/skills/refactor/SKILL.md +40 -0
  27. package/plugin/skills/refactor/agents/openai.yaml +4 -0
  28. package/plugin/skills/release-readiness/SKILL.md +39 -0
  29. package/plugin/skills/release-readiness/agents/openai.yaml +4 -0
  30. package/plugin/skills/review/SKILL.md +39 -0
  31. package/plugin/skills/review/agents/openai.yaml +4 -0
  32. package/plugin/skills/security-review/SKILL.md +39 -0
  33. package/plugin/skills/security-review/agents/openai.yaml +4 -0
  34. package/plugin/skills/test/SKILL.md +40 -0
  35. package/plugin/skills/test/agents/openai.yaml +4 -0
  36. package/scripts/validate.mjs +29 -0
  37. package/src/cli.js +85 -0
  38. package/src/codex.js +13 -0
  39. package/src/commands.js +98 -0
  40. package/src/doctor.js +40 -0
  41. package/src/fs-safe.js +38 -0
  42. package/src/plugin-install.js +135 -0
  43. package/src/plugin-state.js +82 -0
  44. package/src/project-init.js +53 -0
  45. package/src/uninstall.js +50 -0
  46. package/templates/AGENTS.md +48 -0
  47. package/templates/docs/agent/decision-log.md +15 -0
  48. package/templates/docs/agent/findings.md +13 -0
  49. package/templates/docs/agent/handoff.md +20 -0
  50. package/templates/docs/agent/plan.md +14 -0
  51. 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,4 @@
1
+ interface:
2
+ display_name: "API Design"
3
+ short_description: "Design stable contracts around consumer needs"
4
+ default_prompt: "Use $api-design to define a stable, evolvable contract for these consumers."
@@ -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,4 @@
1
+ interface:
2
+ display_name: "Architecture Review"
3
+ short_description: "Evaluate boundaries, coupling, ownership, and change cost"
4
+ default_prompt: "Use $architecture-review to assess this design against its real constraints and change scenarios."
@@ -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,4 @@
1
+ interface:
2
+ display_name: "Brainstorm"
3
+ short_description: "Explore distinct options before choosing a direction"
4
+ default_prompt: "Use $brainstorm to frame this problem, compare distinct options, and recommend a direction."
@@ -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,4 @@
1
+ interface:
2
+ display_name: "Database Design"
3
+ short_description: "Design data around invariants and access patterns"
4
+ default_prompt: "Use $database-design to model this data around domain invariants and proven access patterns."
@@ -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,4 @@
1
+ interface:
2
+ display_name: "Debug"
3
+ short_description: "Isolate root causes from runtime evidence and verify fixes"
4
+ default_prompt: "Use $debug to reproduce this symptom, isolate its cause, and verify the resolution."
@@ -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,4 @@
1
+ interface:
2
+ display_name: "Estimate"
3
+ short_description: "Estimate work with ranges and explicit uncertainty"
4
+ default_prompt: "Use $estimate to produce an evidence-based range with assumptions, risks, and 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,4 @@
1
+ interface:
2
+ display_name: "Fix Findings"
3
+ short_description: "Resolve validated findings and prove each correction"
4
+ default_prompt: "Use $fix-findings to correct and verify every accepted finding in scope."
@@ -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.
@@ -0,0 +1,4 @@
1
+ interface:
2
+ display_name: "Implement"
3
+ short_description: "Build the smallest complete, verified software change"
4
+ default_prompt: "Use $implement to deliver this software change with proportionate verification."